Hi Kever,
On Sat, 8 Aug 2020 at 05:32, Kever Yang kever.yang@rock-chips.com wrote:
Hi Simon,
Sorry for reply late. It's OK to use binman to generate firmware for 32bit SoCs whichonly have optee.bin
which is easy replacement.
I still have some confuse(I'm sure I've ask before but I can't find now, sorry):
to support feature like this(Jagan asked in anoter thread):
tools/mkimage -n rk3399 -T rksd -d
tpl/u-boot-tpl.bin:spl/u-boot-spl.bin idbloader.img
Note that there are 2 inputs instead of 1 so that we can getcorrect size for each of them in the header.
What I suggest is to add two subnodes to the mkimage node, one with each file. At present this means to combine the two files into one and pass them to mkimage with '-d'. So perhaps add a new property to the mkimage node, like 'multi-input' and change mkimage.py to read that property and behave differently in ObtainContents() in that case.
- bl31.elf parse which including multi binaries, we need to split them
first, and also sign them into u-boot.itb
See elf.py which has Elf parsing. The cbfs_util.py file calls DecodeElf() which should be helpful. You can create a new rockchip-atf type to do what you want, if the Rockchip code is speical.
arch/arm/mach-rockchip/make_fit_atf.py
If the feature in this script can be replaced by binman, them allthe rockchip platform can use binman.
Yes and it is written in Python too, so some of the code can move over into binman etypes.
For rockchip platform we need separate idbloader.img and u-boot.itb
In many case, people don't want to erase the space which are not
the space for idbloader.img and u-boot.itb
eg. space at offset 0 is gpt, there should be available gpt in thebeginning and end of disk;
space between idbloader and u-boot.itb may have some useful vendordata;
Well you can perhaps output an image that has everything in one file as well as a few other files that contain the pieces. Then you can cover both options.
I can have a try if you can help give me some guide about how toimplement these features with binman,
them I can make it available to all other rockchip boards if all these features are available.
That sounds good. I am happy to help!
Regards, Simon
Thanks,
- Kever
On 2020/7/24 下午10:48, Simon Glass wrote:
Hi Kever (and other Rockchip people),
Are there any more comments on this series? I can pick it up via -dm but I would like to get more comments if possible. I'd also like to see if someone can take on removing the other ad-hoc Rockchip script.
Regards, Simon
On Sun, 19 Jul 2020 at 21:07, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 19 Jul 2020 at 19:12, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Jul 20, 2020 at 3:56 AM Simon Glass sjg@chromium.org wrote:
Rockchip-based Chromebooks support booting from SPI flash. It is annoying to have to manually build the SPI image when the SD image is built automatically.
This feature is already available for x86 devices, so the existing mechanism is reused. Briefly, this allows a BUILD_ROM environment variable to be provided to indicate that any required binary blobs are present and it is safe to build the ROM.
A new 'mkimage' type is added to binman to support building binaries containing mkimagem using a binman definition to configure it. This avoids Makefile/shell/Python code to do the same thing.
This series also migrates some rockchip boards to use binman to produce their FIT as well, resulting in removing the fit_spl_optee.sh script.
Other archs and the rest of rockchip could be migrated too.
This series uses binman to produce a ROM image on two selected Chromebooks, Bob (RK3399) and Jerry (RK3388).
Changes in v4:
- Add a new CONFIG_ROCKCHIP_SPI_IMAGE to control SPI-image generation
- Use CONFIG_ROCKCHIP_SPI_IMAGE to select the image
- Update for changes to arch/arm/mach-k3/config.mk
- Move the .itb output to a separate rockchip-optee.dtsi file
- Add a check for CONFIG_FIT before building the .its
Changes in v3:
- Add a comment about CONFIG_SPL_FRAMEWORK
- Drop rockchip changes which should not be in this patch
- Move in the rockchip changes mistakenly in the earlier x86 patch
- Drop use of rk322x.dtsi
- Add changes to rk3288-u-boot.dtsi instead
- Drop leftover debugging
It looks you have applied part of the v3 in u-boot-dm, and sent the remaining patches as v4?
I re-assigned this series to you in patchwork.
Yes I applied the binman patches and those that were reviewed.
I am not sure if this shold be an x86 or rockchip series, or perhaps we just wait until people have had a look.
Regards, Simon