| Message ID | 20220516110712.178958-1-andrew@mirx.dev |
|---|---|
| Headers | show |
| Series | Build Rockchip final images using binman | expand |
Hi Andrew, On 5/16/22 13:07, Andrew Abbott wrote: > My original goal was to produce SPI images for Rockchip platforms (specifically > for me, ROCKPro64, and in the future ROCK64). Looking into it, it seemed nicer > to just switch the SD/MMC image generation over to binman as well in the > process. > > This is my attempt to move Rockchip final full image generation to binman, > adding the option to make full SPI images as well. > > Other questions: > > - I noticed that ATF generation for ARM64 Rockchip is done via a Python script > instead of binman. I don't currently know how to change that over to binman, > but is that something worth pursuing as part of this? I use this kind of configuration on ROCKPi 4B (U-Boot with TF-A BL31 and OP-TEE), so I could at least run some tests. Please note that I recently sent a patch to fix the OP-TEE support in make_fit_atf.py [1]. That would be needed in binman too for me to able to test. [1] https://lists.denx.de/pipermail/u-boot/2022-May/483917.html > > Please give me your feedback! > > Changes in v2: > - Revert u-boot-rockchip-sdmmc.bin name to u-boot-rockchip.bin, to > keep the name the same as before. > - Fix whitespace issues. > - Remove note from docs about different offsets in SPI flash for > different SoCs - this was a bad assumption on my part, it doesn't work > this way. > - Update name of SD/MMC image in the docs from u-boot-rockchip-sdmmc.bin > to u-boot-rockchip.bin. > > Andrew Abbott (8): > binman: mkimage: Support ':'-separated inputs > rockchip: Add binman definitions for final images > soc: rockchip: Include common U-Boot dtsi file > board: rockchip: Move SPI U-Boot offset to config > rockchip: Remove obsolete Makefile targets > rockchip: Enable binman for ARM64 > doc: rockchip: Update for new binman image generation > board: rockpro64: Enable building SPI image > > Kconfig | 4 +- > Makefile | 31 ++---------- > arch/arm/Kconfig | 2 +- > arch/arm/dts/rk3308-u-boot.dtsi | 2 + > arch/arm/dts/rk3328-u-boot.dtsi | 2 + > arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi | 1 - > arch/arm/dts/rk3368-u-boot.dtsi | 1 + > arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi | 4 -- > arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi | 1 - > arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 4 -- > arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4 -- > arch/arm/dts/rk3568-u-boot.dtsi | 2 + > arch/arm/dts/rockchip-u-boot.dtsi | 53 ++++++++++++++++++-- > arch/arm/mach-rockchip/Kconfig | 7 ++- > arch/arm/mach-rockchip/rk3399/Kconfig | 1 + > configs/lion-rk3368_defconfig | 1 + > configs/pinebook-pro-rk3399_defconfig | 1 + > configs/puma-rk3399_defconfig | 2 +- > configs/roc-pc-rk3399_defconfig | 1 + > configs/rockpro64-rk3399_defconfig | 1 + > doc/board/rockchip/rockchip.rst | 29 +++-------- > tools/binman/etype/mkimage.py | 33 +++++++----- > 22 files changed, 100 insertions(+), 87 deletions(-) >
Hi Jerome, On Tue May 17, 2022 at 1:13 AM AEST, Jerome Forissier wrote: > I use this kind of configuration on ROCKPi 4B (U-Boot with TF-A BL31 and OP-TEE), > so I could at least run some tests. Please note that I recently sent a patch to > fix the OP-TEE support in make_fit_atf.py [1]. That would be needed in binman > too for me to able to test. > > [1] https://lists.denx.de/pipermail/u-boot/2022-May/483917.html Thanks for your offer to test! I'm not actually very familiar with TF-A and OP-TEE and the role they play, but I haven't changed how they are generated/included into U-Boot in this patch set - I'm only using binman to assemble SPL, TPL, and u-boot.itb into a single image, the latter still being generated using make_fit_atf.py. So unless I'm misunderstanding, you should be able to set CONFIG_ROCKCHIP_SPI_IMAGE=y in the ROCKPi 4B defconfig and get a u-boot-rockchip-spi.bin to be generated that would take your patch into account as-is. Thanks, Andrew
On 16/05/2022 14:07, Andrew Abbott wrote: > My original goal was to produce SPI images for Rockchip platforms (specifically > for me, ROCKPro64, and in the future ROCK64). Looking into it, it seemed nicer > to just switch the SD/MMC image generation over to binman as well in the > process. > > This is my attempt to move Rockchip final full image generation to binman, > adding the option to make full SPI images as well. > > Other questions: > > - I noticed that ATF generation for ARM64 Rockchip is done via a Python script > instead of binman. I don't currently know how to change that over to binman, > but is that something worth pursuing as part of this? Simon was working on that in [1] (see patches 22-26 which weren't applied), but images produced by that don't exactly work (see comments on earlier versions [2]). Then, things got stalled/postponed because of various issues in binman AFAICT. The crux of the problem there is the binman-wise design of splitting bl31.elf into parts and putting them into the FIT. I have some weird ideas about generic mechanisms that would allow us to do it nicely, but nothing I could flesh out. Recently I've been thinking we might be able to sidestep it by putting the unsplit ELF directly into FIT (as a new IH_TYPE_ELF for mkimage?) and do the split-loading at runtime. I didn't have time to experiment on that, though. I'd appreciate it if you tried, but don't worry about it if you don't have the time. [1] binman: rockchip: Migrate from rockchip SPL_FIT_GENERATOR script https://lore.kernel.org/u-boot/20220306031917.3005215-1-sjg@chromium.org/ [2] rockchip: Support building the all output files in binman https://lore.kernel.org/u-boot/CAPnjgZ37wnb4r7zkkBMfAeGDir147R4kxMwUWAE0nj6iSYdZBQ@mail.gmail.com/ > Please give me your feedback! > > Changes in v2: > - Revert u-boot-rockchip-sdmmc.bin name to u-boot-rockchip.bin, to > keep the name the same as before. > - Fix whitespace issues. > - Remove note from docs about different offsets in SPI flash for > different SoCs - this was a bad assumption on my part, it doesn't work > this way. > - Update name of SD/MMC image in the docs from u-boot-rockchip-sdmmc.bin > to u-boot-rockchip.bin. > > Andrew Abbott (8): > binman: mkimage: Support ':'-separated inputs > rockchip: Add binman definitions for final images > soc: rockchip: Include common U-Boot dtsi file > board: rockchip: Move SPI U-Boot offset to config > rockchip: Remove obsolete Makefile targets > rockchip: Enable binman for ARM64 > doc: rockchip: Update for new binman image generation > board: rockpro64: Enable building SPI image > > Kconfig | 4 +- > Makefile | 31 ++---------- > arch/arm/Kconfig | 2 +- > arch/arm/dts/rk3308-u-boot.dtsi | 2 + > arch/arm/dts/rk3328-u-boot.dtsi | 2 + > arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi | 1 - > arch/arm/dts/rk3368-u-boot.dtsi | 1 + > arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi | 4 -- > arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi | 1 - > arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 4 -- > arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4 -- > arch/arm/dts/rk3568-u-boot.dtsi | 2 + > arch/arm/dts/rockchip-u-boot.dtsi | 53 ++++++++++++++++++-- > arch/arm/mach-rockchip/Kconfig | 7 ++- > arch/arm/mach-rockchip/rk3399/Kconfig | 1 + > configs/lion-rk3368_defconfig | 1 + > configs/pinebook-pro-rk3399_defconfig | 1 + > configs/puma-rk3399_defconfig | 2 +- > configs/roc-pc-rk3399_defconfig | 1 + > configs/rockpro64-rk3399_defconfig | 1 + > doc/board/rockchip/rockchip.rst | 29 +++-------- > tools/binman/etype/mkimage.py | 33 +++++++----- > 22 files changed, 100 insertions(+), 87 deletions(-) >
On Thu May 19, 2022 at 9:35 PM AEST, Alper Nebi Yasak wrote: > > - I noticed that ATF generation for ARM64 Rockchip is done via a Python script > > instead of binman. I don't currently know how to change that over to binman, > > but is that something worth pursuing as part of this? > > Simon was working on that in [1] (see patches 22-26 which weren't > applied), but images produced by that don't exactly work (see comments > on earlier versions [2]). Then, things got stalled/postponed because of > various issues in binman AFAICT. > > The crux of the problem there is the binman-wise design of splitting > bl31.elf into parts and putting them into the FIT. I have some weird > ideas about generic mechanisms that would allow us to do it nicely, but > nothing I could flesh out. > > Recently I've been thinking we might be able to sidestep it by putting > the unsplit ELF directly into FIT (as a new IH_TYPE_ELF for mkimage?) > and do the split-loading at runtime. I didn't have time to experiment on > that, though. I'd appreciate it if you tried, but don't worry about it > if you don't have the time. > > [1] binman: rockchip: Migrate from rockchip SPL_FIT_GENERATOR script > https://lore.kernel.org/u-boot/20220306031917.3005215-1-sjg@chromium.org/ > > [2] rockchip: Support building the all output files in binman > https://lore.kernel.org/u-boot/CAPnjgZ37wnb4r7zkkBMfAeGDir147R4kxMwUWAE0nj6iSYdZBQ@mail.gmail.com/ Thanks for the information and links to previous attempts. Unfortunately, I don't think I have either the knowledge or the time to be look into the FIT image generation to that extent in the near future (which is why I didn't try to tackle it in this patch set).