[PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman

[Simon Glass]

Hi Kever,

On Sat, 8 Aug 2020 at 05:32, Kever Yang <kever.yang at rock-chips.com> wrote:
>
> Hi Simon,
>
>      Sorry for reply late.
>
>      It's OK to use binman to generate firmware for 32bit SoCs which
> only 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 get
> correct 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 all
> the 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 the
> beginning and end of disk;
>
>      space between idbloader and u-boot.itb may have some useful vendor
> data;

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 to
> implement 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 at chromium.org> wrote:
> >> Hi Bin,
> >>
> >> On Sun, 19 Jul 2020 at 19:12, Bin Meng <bmeng.cn at gmail.com> wrote:
> >>> Hi Simon,
> >>>
> >>> On Mon, Jul 20, 2020 at 3:56 AM Simon Glass <sjg at 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
> >
>
>