| Message ID | 20200104083806.3930-1-jagan@amarulasolutions.com |
|---|---|
| Headers | show |
| Series |
|
| Related | show |
Add Wadim in cc, Hi Jagan, After this patch set apply, the phycore-rk3288 board's SPL size is overflow: arm: + phycore-rk3288 +Error: SPL image is too large (size 0x9000 than 0x8000) +Error: Bad parameters for image type Maybe we need to enable the TPL for this board? @Wadim Thanks, - Kever On 2020/1/4 下午4:38, Jagan Teki wrote: > This is v6 set for Binman support in rockchip, [1] here is > previous patchset. > > This series add single boot image with binman for arm32 and > pad_cat for arm64 rockchip platforms both TPL + SPL and SPL-alone > targets. > > Changes for v6: > - drop idbloader.img filename change patch > - update rockchip.rst to include, rockchip TPL, SPI boot as TODO > Changes for v5: > - collect kever review tag > - drop idbloader.img from clean target > Changes for v4: > - support all rockchip platforms > - add new patches for dtsi changes > - update documentation > - format proper commit message > - rebase on master > Changes for v3: > - rebase on master > - add binman for rk3288, rk3328, rk3368, rk3399 > - added rst documentation for rockchip > Changes for v2: > - Add few clean target patches > - update bl31.elf env handling code, with logging > - support puma itb, via BL31 and PMUM0 env > - enable BUILD_TARGET for ROCKCHIP_RK3399 > > [1] https://patchwork.ozlabs.org/cover/1216263/ > > Any inputs? > Jagan. > > Jagan Teki (6): > Makefile: Add rockchip image type > Makefile: rockchip: Suffix platform type with tpl name > Makefile: rockchip: Support SPL-alone mkimage > arm: dts: rk3036: Add rk3036-u-boot.dtsi > rockchip: Add Single boot image (with binman, pad_cat) > doc: boards: Add rockchip documentation > > Makefile | 36 ++++++-- > arch/arm/Kconfig | 1 + > arch/arm/dts/rk3036-sdk-u-boot.dtsi | 2 + > arch/arm/dts/rk3036-u-boot.dtsi | 6 ++ > arch/arm/dts/rk3288-u-boot.dtsi | 2 + > arch/arm/dts/rockchip-u-boot.dtsi | 21 +++++ > doc/board/rockchip/index.rst | 10 +++ > doc/board/rockchip/rockchip.rst | 130 ++++++++++++++++++++++++++++ > include/configs/rockchip-common.h | 3 + > 9 files changed, 206 insertions(+), 5 deletions(-) > create mode 100644 arch/arm/dts/rk3036-u-boot.dtsi > create mode 100644 arch/arm/dts/rockchip-u-boot.dtsi > create mode 100644 doc/board/rockchip/index.rst > create mode 100644 doc/board/rockchip/rockchip.rst >
Hi, On 07.01.20 10:59, Kever Yang wrote: > Add Wadim in cc, > > Hi Jagan, > > After this patch set apply, the phycore-rk3288 board's SPL size is > overflow: > > arm: + phycore-rk3288 > +Error: SPL image is too large (size 0x9000 than 0x8000) > +Error: Bad parameters for image type > > Maybe we need to enable the TPL for this board? @Wadim I would like it to keep the SPL for the phyCORE board. In this thread [1] I pointed out that you can drop the phycore_init() function that was sometimes blowing up the size of the phyCORE SPL image. So if there is no new other feature that increases the SPL size, we can just remove the code and the SPL should fit again. If you like I can take a look at this next week. [1] https://lists.denx.de/pipermail/u-boot/2019-July/378112.html Regards, Wadim > > > Thanks, > > - Kever > > On 2020/1/4 下午4:38, Jagan Teki wrote: >> This is v6 set for Binman support in rockchip, [1] here is >> previous patchset. >> >> This series add single boot image with binman for arm32 and >> pad_cat for arm64 rockchip platforms both TPL + SPL and SPL-alone >> targets. >> >> Changes for v6: >> - drop idbloader.img filename change patch >> - update rockchip.rst to include, rockchip TPL, SPI boot as TODO >> Changes for v5: >> - collect kever review tag >> - drop idbloader.img from clean target >> Changes for v4: >> - support all rockchip platforms >> - add new patches for dtsi changes >> - update documentation >> - format proper commit message >> - rebase on master >> Changes for v3: >> - rebase on master >> - add binman for rk3288, rk3328, rk3368, rk3399 >> - added rst documentation for rockchip >> Changes for v2: >> - Add few clean target patches >> - update bl31.elf env handling code, with logging >> - support puma itb, via BL31 and PMUM0 env >> - enable BUILD_TARGET for ROCKCHIP_RK3399 >> >> [1] https://patchwork.ozlabs.org/cover/1216263/ >> >> Any inputs? >> Jagan. >> >> Jagan Teki (6): >> Makefile: Add rockchip image type >> Makefile: rockchip: Suffix platform type with tpl name >> Makefile: rockchip: Support SPL-alone mkimage >> arm: dts: rk3036: Add rk3036-u-boot.dtsi >> rockchip: Add Single boot image (with binman, pad_cat) >> doc: boards: Add rockchip documentation >> >> Makefile | 36 ++++++-- >> arch/arm/Kconfig | 1 + >> arch/arm/dts/rk3036-sdk-u-boot.dtsi | 2 + >> arch/arm/dts/rk3036-u-boot.dtsi | 6 ++ >> arch/arm/dts/rk3288-u-boot.dtsi | 2 + >> arch/arm/dts/rockchip-u-boot.dtsi | 21 +++++ >> doc/board/rockchip/index.rst | 10 +++ >> doc/board/rockchip/rockchip.rst | 130 ++++++++++++++++++++++++++++ >> include/configs/rockchip-common.h | 3 + >> 9 files changed, 206 insertions(+), 5 deletions(-) >> create mode 100644 arch/arm/dts/rk3036-u-boot.dtsi >> create mode 100644 arch/arm/dts/rockchip-u-boot.dtsi >> create mode 100644 doc/board/rockchip/index.rst >> create mode 100644 doc/board/rockchip/rockchip.rst >> > >
On Wed, Jan 8, 2020 at 5:04 PM Wadim Egorov <w.egorov@phytec.de> wrote: > > Hi, > > On 07.01.20 10:59, Kever Yang wrote: > > Add Wadim in cc, > > > > Hi Jagan, > > > > After this patch set apply, the phycore-rk3288 board's SPL size is > > overflow: > > > > arm: + phycore-rk3288 > > +Error: SPL image is too large (size 0x9000 than 0x8000) > > +Error: Bad parameters for image type > > > > Maybe we need to enable the TPL for this board? @Wadim > > I would like it to keep the SPL for the phyCORE board. In this thread > [1] I pointed out that you can drop the phycore_init() function that was > sometimes blowing up the size of the phyCORE SPL image. So if there is > no new other feature that increases the SPL size, we can just remove the > code and the SPL should fit again. If you like I can take a look at this > next week. If not, maybe we can disable BINMAN for this board? I'm sure it can revert since there would be a need to move TPL in future.
On Wed, Jan 8, 2020 at 5:04 PM Wadim Egorov <w.egorov@phytec.de> wrote: > > Hi, > > On 07.01.20 10:59, Kever Yang wrote: > > Add Wadim in cc, > > > > Hi Jagan, > > > > After this patch set apply, the phycore-rk3288 board's SPL size is > > overflow: > > > > arm: + phycore-rk3288 > > +Error: SPL image is too large (size 0x9000 than 0x8000) > > +Error: Bad parameters for image type > > > > Maybe we need to enable the TPL for this board? @Wadim > > I would like it to keep the SPL for the phyCORE board. In this thread > [1] I pointed out that you can drop the phycore_init() function that was > sometimes blowing up the size of the phyCORE SPL image. So if there is > no new other feature that increases the SPL size, we can just remove the > code and the SPL should fit again. If you like I can take a look at this > next week. This won't help much, but one possibility is to use SPL_OF_PLATDATA (I've verified). Can you help us to try as quickly as possible? or do you want us to try? Jagan.
Hi Jagan, On 09.01.20 14:59, Jagan Teki wrote: > On Wed, Jan 8, 2020 at 5:04 PM Wadim Egorov <w.egorov@phytec.de> wrote: >> Hi, >> >> On 07.01.20 10:59, Kever Yang wrote: >>> Add Wadim in cc, >>> >>> Hi Jagan, >>> >>> After this patch set apply, the phycore-rk3288 board's SPL size is >>> overflow: >>> >>> arm: + phycore-rk3288 >>> +Error: SPL image is too large (size 0x9000 than 0x8000) >>> +Error: Bad parameters for image type >>> >>> Maybe we need to enable the TPL for this board? @Wadim >> I would like it to keep the SPL for the phyCORE board. In this thread >> [1] I pointed out that you can drop the phycore_init() function that was >> sometimes blowing up the size of the phyCORE SPL image. So if there is >> no new other feature that increases the SPL size, we can just remove the >> code and the SPL should fit again. If you like I can take a look at this >> next week. > This won't help much, but one possibility is to use SPL_OF_PLATDATA > (I've verified). Can you help us to try as quickly as possible? or do > you want us to try? Or we can simply disable CONFIG_SPL_I2C_SUPPORT and CONFIG_SPL_POWER_SUPPORT in the phycore-rk3288_defconfig. What do you want me to do now? Testing your patches with SPL_OF_PLATDATA=y on our board? If so, I can help you next week with testing.
On Thu, Jan 9, 2020 at 8:58 PM Wadim Egorov <w.egorov@phytec.de> wrote: > > Hi Jagan, > > On 09.01.20 14:59, Jagan Teki wrote: > > On Wed, Jan 8, 2020 at 5:04 PM Wadim Egorov <w.egorov@phytec.de> wrote: > >> Hi, > >> > >> On 07.01.20 10:59, Kever Yang wrote: > >>> Add Wadim in cc, > >>> > >>> Hi Jagan, > >>> > >>> After this patch set apply, the phycore-rk3288 board's SPL size is > >>> overflow: > >>> > >>> arm: + phycore-rk3288 > >>> +Error: SPL image is too large (size 0x9000 than 0x8000) > >>> +Error: Bad parameters for image type > >>> > >>> Maybe we need to enable the TPL for this board? @Wadim > >> I would like it to keep the SPL for the phyCORE board. In this thread > >> [1] I pointed out that you can drop the phycore_init() function that was > >> sometimes blowing up the size of the phyCORE SPL image. So if there is > >> no new other feature that increases the SPL size, we can just remove the > >> code and the SPL should fit again. If you like I can take a look at this > >> next week. > > This won't help much, but one possibility is to use SPL_OF_PLATDATA > > (I've verified). Can you help us to try as quickly as possible? or do > > you want us to try? > > Or we can simply disable CONFIG_SPL_I2C_SUPPORT and > CONFIG_SPL_POWER_SUPPORT in the phycore-rk3288_defconfig. This seems fixed, sent the patches please test the same, thanks!
Hi, On Tue, 7 Jan 2020 at 22:59, Kever Yang <kever.yang@rock-chips.com> wrote: > > Add Wadim in cc, > > Hi Jagan, > > After this patch set apply, the phycore-rk3288 board's SPL size is overflow: > > arm: + phycore-rk3288 > +Error: SPL image is too large (size 0x9000 than 0x8000) > +Error: Bad parameters for image type > > Maybe we need to enable the TPL for this board? @Wadim We should look at why it is too large. Enabling BINMAN should not increase the code size of SPL, so perhaps there is a bug? Regards, Simon