using binman fails boot
Simon Glass
sjg at chromium.org
Sun Jul 25 00:01:18 CEST 2021
Hi Tim,
On Fri, 23 Jul 2021 at 16:52, Tim Harvey <tharvey at gateworks.com> wrote:
>
> On Fri, Jul 23, 2021 at 2:41 PM Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Tim,
> >
> > On Fri, 23 Jul 2021 at 15:06, Tim Harvey <tharvey at gateworks.com> wrote:
> > >
> > > On Thu, Jul 22, 2021 at 8:07 PM Simon Glass <sjg at chromium.org> wrote:
> > > >
> > > > Hi Tim,
> > > >
> > > > On Mon, 19 Jul 2021 at 17:23, Tim Harvey <tharvey at gateworks.com> wrote:
> > > > >
> > > > > On Sat, Jul 17, 2021 at 7:22 PM Simon Glass <sjg at chromium.org> wrote:
> > > > > >
> > > >
> > > > [..]
> > > >
> > > > > > > But isn't blob-ext at 4 a correct name? I can't use 'blob-ext-4' as
> > > > > > > that's an unknown entry type.
> > > > > >
> > > > > > Well you can use any name and specify the type:
> > > > > >
> > > > > > my-name {
> > > > > > type = "blob-ext";
> > > > > > };
> > > > > >
> > > > >
> > > > > Ok - I understand.
> > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > If you can push your tree somewhere (with this problem) I'll see if I
> > > > > > > > can figure out why.
> > > > > > > >
> > > > > > >
> > > > > > > Sure, I pushed it to
> > > > > > > https://github.com/Gateworks/uboot-venice/tree/WIP-venice-binman
> > > > > > > make imx8mm_venice_defconfig
> > > > > > > make
> > > > > >
> > > > > > OK
> > > > > >
> > > > > > >
> > > > > > > > >
> > > > > > > > > BINMAN_VERBOSE=4 indeed prints out a tone of stuff but I'm not seeing
> > > > > > > > > anything for 'blob' below that would seem to indicate one node name vs
> > > > > > > > > another:
> > > > > > > >
> > > > > > > > Oops you need BINMAN_VERBOSE=5 - see elf.py LookupAndWriteSymbols()
> > > > > > > > which has tout.Debug() which is level 5.
> > > > > > > >
> > > > > > >
> > > > > > > LookupAndWriteSymbols ends up doing nothing because
> > > > > > > syms.get('__image_copy_start') returns None.
> > > > > >
> > > > > > Well that is likely the problem.
> > > >
> > > > I sent a patch to make binman report this as an error.
> > > >
> > > > I pushed the resulting tree to:
> > > >
> > > > https://github.com/sjg20/u-boot/tree/try-tim
> > > >
> > > > Now the error is:
> > > >
> > > > binman: Section '/binman/u-boot-spl-ddr': Symbol
> > > > '_binman_u_boot_any_prop_image_pos'
> > > >
> > > > in entry '/binman/u-boot-spl-ddr/u-boot-spl/u-boot-spl-nodtb':
> > > > Entry 'u-boot-any' not found in list
> > > > (u-boot-spl-nodtb,u-boot-spl-dtb,u-boot-spl,blob-ext at 1,blob-ext at 2,blob-ext at 3,blob-ext at 4,main-section)
> > > >
> > > > The problem seems to be that you are asking binman to generate three
> > > > independent images. U-Boot is in a FIT which is not in the same image
> > > > as SPL. So it is not possible to locate the flash offset of U-Boot
> > > > (with in the FIT).
> > > >
> > > > Can you give me a bit more info about your intent here? Is it to load
> > > > U-Boot from the FIT? I so, I suppose it is possible to make binman
> > > > access an independent image, if it is told where it starts.
> > > >
> > > > But why is everything not in one image?
> > > >
> > >
> > > Simon,
> > >
> > > I would rather have 1 image. I was going off of the imx8mm_evk switch
> > > to binman which creates the separate images.
> >
> > Well at present you are loading a FIT into RAM, I think? Is it coming
> > from flash?
> >
> > If you load a FIT containing U-Boot then you don't need the binman
> > symbol stuff, since SPL looks in the FIT for the location of U-Boot.
> > There isn't much benefit in having binman point to U-Boot within the
> > FIT, since we already have code to find it. It might save a few bytes
> > of code, but it would be confusing...I'm not sure if that is worth the
> > hassle.
> >
> > If you want a single image, then you might not want FIT at all...just
> > use binman.
> >
> > It really depends what you want.
>
> Maybe my terminology is all wrong or I'm not making myself clear. I'm
> trying to access data inside the SPL binary in board_init_f() 'before'
> the SPL has done anything at all with FIT.
>
> I'm using FIT because I have multiple board models (ie multiple DTB's)
> supported by a single U-Boot 'board'.
OK I see.
Well in that case the problem is the use of
CONFIG_SPL_RAW_IMAGE_SUPPORT which causes spl_set_header_raw_uboot()
to try to find U-Boot's binman symbol, which doesn't exist.
Also the naming of your sections need a tweak, as mentioned.
I've pushed a new trree to:
https://github.com/sjg20/u-boot/tree/try-tim
>
> So my boot goes like this:
> IMX8M BOOT ROM fetches flash.bin (SPL) from eMMC into OCRAM
> SPL configures PMIC and DRAM based on runtime detection of board model
> - at this point in time SPL is using a generic imx8mm-venice.dts
> that just supports i2c/uart2/emmc which are common to all venice
> boards
> - pmic config is done without dm because we don't have the
> board-specific dtb yet which defines the pmic
> - DRAM config is done based on eeprom bytes that specify the DRAM
> size/density/etc
> - DRAM config includes loading the 'blobs' to the M4 CPU - these are
> the blobs I want to locate in the SPL
> SPL locates FIT and starts chugging through it (I don't claim to fully
> understand this part)
> - board_fit_config_name_match() is called for each DTB found and I
> return a success if the DTB matches the board model found via I2C
> EEPROM
> SPL loads ATF and executes it
> ATF executes? U-Boot (not super clear on all of this either)
> U-Boot Proper runs with the board-specific dtb (not imx8mm-venice.dtb
> but imx8mm-venice-gwxxxx.dtb)
OK, got it.
>
> >
> > >
> > > The whole point of what I'm investigating here has to do with the SPL.
> > > OCRAM is at a premium and the current way the IMX8M is handling DDR
> > > firmware is to tack it on after the code in the SPL image and it gets
> > > padded to make it easy to locate which is a huge waste of space. I
> > > figured we can use binman to locate the blobs without the padding.
> > >
> > > So, if you take 'just' the spl image here:
> > > spl: u-boot-spl-ddr {
> > > filename = "u-boot-spl-ddr.bin";
> > > pad-byte = <0xff>;
> > > align-size = <4>;
> > > align = <4>;
> > >
> > > u-boot-spl {
> > > align-end = <4>;
> > > };
> > >
> > > blob_1: blob-ext at 1 {
> > > filename = "lpddr4_pmu_train_1d_imem.bin";
> > > size = <0x8000>;
> > > };
> > >
> > > blob_2: blob-ext at 2 {
> > > filename = "lpddr4_pmu_train_1d_dmem.bin";
> > > size = <0x4000>;
> > > };
> > >
> > > blob_3: blob-ext at 3 {
> > > filename = "lpddr4_pmu_train_2d_imem.bin";
> > > size = <0x8000>;
> > > };
> > >
> > > blob_4: blob-ext at 4 {
> > > filename = "lpddr4_pmu_train_2d_dmem.bin";
> > > size = <0x4000>;
> > > };
> > > };
> > >
> > > My intention is to remove the size arguments above which are currently
> > > forcing wasted padding and locate the blobs at runtime with binman.
> >
> > Well you can just remove them.
>
> Not right now because the imx8 dram config expects them to be
> following the DDR code and specific sizes... its dumb code that ends
> up wasiting 24K of SPL/OCRAM with padding which is why I want to
> improve that.
>
> see ddr_load_train_firmware
> https://elixir.bootlin.com/u-boot/latest/source/drivers/ddr/imx/imx8m/helper.c#L29
OK well if you can update that code to read the size from a binman
symbol, perhaps that will help.
>
> >
> > >
> > > Based on your other patch it it would seem I'm missing something from
> > > my lds to add __image_copy_start yet in
> > > arch/arm/cpu/armv8/u-boot-spl.lds I see:
> > > .text : {
> > > . = ALIGN(8);
> > > *(.__image_copy_start)
> > > CPUDIR/start.o (.text*)
> > > *(.text*)
> > > } >.sram
> > >
> > > My understanding of linker files is pretty slim so perhaps there's
> > > something missing above.
> >
> > Yes you need to define the value of the __image_copy_start symbol, so:
> >
> > .text: {
> > __image_copy_start = .;
> >
> > See for example arch/arm/cpu/u-boot-spl.lds
> >
>
> Honestly what I 'really' want to do is get the SPL to load all the
> dram config/blobs from flash and completely move them out of the SPL
> that gets loaded into OCRAM so that I don't overflow the OCRAM with
> DRAM configs when we add new boards. So maybe I'll just start focusing
> on that.
>
> I was thinking FIT would be a good approach for that but I haven't dug
> into how the SPL processes the FIT yet...if it requires DRAM to do so
> then I can't really go that route and maybe it's just too complex for
> what I want anyway.
FIT is fine, but I suppose it is also possible to use binman for
everything. But we do encourage FIT since it is a standard boot
method.
Regards,
Simon
More information about the U-Boot
mailing list