Re: using binman fails boot

[Tim Harvey <tharvey@gateworks.com>]

On Sat, Jul 17, 2021 at 7:22 PM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Tim,
>
> On Fri, 16 Jul 2021 at 17:15, Tim Harvey <tharvey@gateworks.com> wrote:
> >
> > On Fri, Jul 16, 2021 at 3:11 PM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > () which has
> > > Hi Tim,
> > >
> > > On Fri, 16 Jul 2021 at 15:43, Tim Harvey <tharvey@gateworks.com> wrote:
> > > >
> > > > On Thu, Jul 15, 2021 at 9:30 PM Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > Hi Tim,
> > > > >
> > > > > On Thu, 15 Jul 2021 at 16:58, Tim Harvey <tharvey@gateworks.com> wrote:
> > > > > >
> > > > > > Greetings,
> > > > > >
> > > > > > I'm taking a look at moving imx8mm-venice to use binman for packaging.
> > > > > > After doing so U-Boot proper fails to boot:
> > > > > >
> > > > > > U-Boot SPL 2021.07-00475-g1126252f40 (Jul 15 2021 - 11:09:02 -0700)
> > > > > > GSC     : v58 0xf098 RST:VIN Thermal Protection Disabled
> > > > > > Model   : GW7300-00-B1B
> > > > > > Serial  : 852420
> > > > > > MFGDate : 10-26-2020
> > > > > > RTC     : 122
> > > > > > PMIC    : MP5416
> > > > > > DRAM    : LPDDR4 1 GiB
> > > > > > WDT:   Not starting
> > > > > > Trying to boot from MMC1
> > > > > > DTB     : imx8mm-venice-gw73xx-0x
> > > > > >
> > > > > >
> > > > > > U-Boot 2021.07-00475-g1126252f40 (Jul 15 2021 - 11:09:02 -0700)
> > > > > >
> > > > > > CPU:   Freescale i.MX8MMQ rev1.0 1600 MHz (running at 1200 MHz)
> > > > > > CPU:   Industrial temperature grade (-40C to 105C) at 43C
> > > > > > Reset cause: POR
> > > > > > Model: Gateworks Venice GW73xx-0x i.MX8MM Development Kit
> > > > > > DRAM:  1 GiB
> > > > > > temp    : 38.3C
> > > > > > vdd_bat : 0.000V
> > > > > > vdd_vin : 15.731V
> > > > > > vdd_adc1: 0.000V
> > > > > > vdd_adc2: 0.000V
> > > > > > vdd_dram: 1.093V
> > > > > > vdd_1p2 : 1.193V
> > > > > > vdd_1p0 : 0.985V
> > > > > > vdd_2p5 : 2.470V
> > > > > > vdd_3p3 : 3.250V
> > > > > > vdd_0p95: 0.948V
> > > > > > vdd_1p8 : 1.799V
> > > > > > vdd_gsc : 3.262V
> > > > > > initcall sequence 000000007ffc4f58 failed at call 0000000040255910 (err=-2)
> > > > > > ### ERROR ### Please RESET the board ###
> > > > > >
> > > > > > Any ideas what this could be?
> > > > >
> > > > > I don't have much idea. What is the initcall that is failing? Can you
> > > > > check u-boot.map ? That might give a clue as to what is failing. I
> > > > > assume the DT is passed to U-Boot somehow from SPL?
> > > > >
> > > >
> > > > Simon,
> > > >
> > > > Thanks for the help!
> > > >
> > > > The initcall addr doesn't match anything in u-boot.map (maybe
> > > > u-boot.map doesn't show what's in lib/binman.o?) but I was able to
> > >
> > > It certainly should show up, but if you have CONFIG_LTO enabled lots
> > > of functions disappear. Still if you get an initcall address I would
> > > expect a function to be present. Make sure you use the unallocated
> > > address.
> >
> > I'm not sure what you mean by 'Make sure you use the unallocated address'
>
> Sorry I mean unrelocated address. After U-Boot relocates the addresses
> change but it still prints out the original addresses.
>
> >
> > >
> > > > track it down to initr_binman() failing due to
> > > > binman_init()->find_image_node(&binman->image)' returning -EINVAL.
> > > > This is because my imx8mm-venice-gw73xx-0x-uboot.dtsi doesn't have a
> > > > binman node (my CONFIG_DEFAULT_DEVICE_TREE did but not my actual
> > > > dtbs). So I have it working now!
> > >
> > > OK good progress! Perhaps we should put an error message in initr_binman() ?
> > >
> >
> > sure - I just sent a patch
> >
> > > >
> > > > > >
> > > > <snip>
> > > > > >
> > > > > > A follow-on question is that I would like to investigate using binman
> > > > > > in the SPL to dynamically access the IMX8M ddr training blobs so that
> > > > > > we don't have to waste padding space taking them onto the end of the
> > > > > > SPL which is currently done. The lpddr4 training blobs I'm using
> > > > > > currently take up 57k without padding compared to 81k with padding.
> > > > > > The location of them is handled in ddr_load_train_firmware.
> > > > > >
> > > > > > If I add the following to my SPL:
> > > > > > diff --git a/board/gateworks/venice/spl.c b/board/gateworks/venice/spl.c
> > > > > > index d0a490b0e6..62eb67fa5e 100644
> > > > > > --- a/board/gateworks/venice/spl.c
> > > > > > +++ b/board/gateworks/venice/spl.c
> > > > > > @@ -3,6 +3,7 @@
> > > > > >   * Copyright 2021 Gateworks Corporation
> > > > > >   */
> > > > > >
> > > > > > +#include <binman_sym.h>
> > > > > >  #include <common.h>
> > > > > >  #include <cpu_func.h>
> > > > > >  #include <hang.h>
> > > > > > @@ -252,6 +253,8 @@ static int power_init_board(void)
> > > > > >         return 0;
> > > > > >  }
> > > > > >
> > > > > > +binman_sym_declare(ulong, blob_1, image_pos);
> > > > > > +
> > > > > >  void board_init_f(ulong dummy)
> > > > > >  {
> > > > > >         struct udevice *dev;
> > > > > > @@ -291,6 +294,8 @@ void board_init_f(ulong dummy)
> > > > > >         gpio_request(PCIE_RSTN, "perst#");
> > > > > >         gpio_direction_output(PCIE_RSTN, 0);
> > > > > >
> > > > > > +       printf("%s: blob_1:0x%0lx\n", __func__, binman_sym(ulong,
> > > > > > blob_1, image_pos));
> > > > > > +
> > > > > >         /* GSC */
> > > > > >         dram_sz = gsc_init(0);
> > > > > >
> > > > > > I get 'blob_1:0x0' which is not what I expected.
> > > > > >
> > > > > > If I understand correctly binman is using linker symbols to determine
> > > > > > where things are in the image? What I don't quite understand is what
> > > > > > symbols are valid to use assuming my dtsi above. The binman.rst docs
> > > > > > talk use 'u_boot_any' as an example which apparently can match
> > > > > > 'u-boot.bin', 'u-boot.img', and 'u-boot-nodtb.bin' but I can't find
> > > > > > the code that somehow translates this meaning.
> > > > >
> > > > > Actually any symbol can be used. It basically depends on the name of
> > > > > the entry in your image description. So here it would be
> > > > > blob-ext@1...I think that translates to blob_ext_1 but I'm not sure
> > > > > about the @. You could try blob-ext-1 instead. It does not know about
> > > > > phandles or labels.
> > > > >
> > > > > If you pass BINMAN_VERBOSE=4 to the build you should see it talking
> > > > > about writing symbols into the SPL image.
> > > > >
> > > >
> > > > For the following:
> > > >          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-ext@1 {
> > > >                         filename = "lpddr4_pmu_train_1d_imem.bin";
> > > >                         size = <0x8000>;
> > > >                 };
> > > >
> > > >                 blob-ext@2 {
> > > >                         filename = "lpddr4_pmu_train_1d_dmem.bin";
> > > >                         size = <0x4000>;
> > > >                 };
> > > >
> > > >                 blob-ext@3 {
> > > >                         filename = "lpddr4_pmu_train_2d_imem.bin";
> > > >                         size = <0x8000>;
> > > >                 };
> > > >
> > > >                 blob-ext@4 {
> > > >                         filename = "lpddr4_pmu_train_2d_dmem.bin";
> > > >                         size = <0x4000>;
> > > >                 };
> > > >         };
> > > >
> > > > I tried 'blob_ext_1' and 'blob_ext1' and both formats resolve to 0x0.
> > > > The 'ext-blob' is an entry type supported by binman so if I had
> > > > multiple they must be called blob-ext@1, blob-ext@2, ... right?
> > > >
> > > > The entry_name used in binman_sym_declare/binman_sym certainly can't
> > > > support non C varname characters so '-' and '@' characters must get
> > > > translated somewhere. Where would that be done in order to figure out
> > > > what to use?
> > >
> > > If you want to look at the internals, see section.py LookupSymbol().
> > >
> > > It takes the ELF symbol and replaces _ by - but does not (cannot)
> > > replace _ with @. So I think you'll have to use - instead of @
> > >
> > > I suppose we could do the search in the other direction (take the
> > > entry and try to find the symbol that matches it), but I'd need to
> > > think about it. A simple translation is easier.
> > >
> > > In this case binman should really give an error for your chosen entry
> > > name (blob-ext@4) but it doesn't know you are using it as a symbol. I
> > > think it should complain about this (see the Warning in section.py
> > > LookupSymbol()) but apparently it does not in your case.
> >
> > But isn't blob-ext@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.
>

Here are the syms getting passed to LookupAndWriteSymbols:

syms: OrderedDict([('zimage.c.482a543f', Symbol(section='.debug_info',
address=9039, size=0, weak=True)), ('image.c.f5c25828',
Symbol(section='.debug_info', address=149598, size=0, weak=True)),
('image_fdt.c.d0cf71b8', Symbol(section='.debug_info', address=158369,
size=0, weak=True)), ('image_fit.c.c45e696c',
Symbol(section='.debug_info', address=162759, size=0, weak=True)),
('spl_parse_image_header', Symbol(section='.text', address=8308244,
size=100, weak=False)), ('fit_image_get_address',
Symbol(section='.text', address=8317036, size=136, weak=False)),
('spl_fit_image_get_os', Symbol(section='.text', address=8317172,
size=92, weak=False)), ('spl_fit_get_image_node',
Symbol(section='.text', address=8318196, size=180, weak=False)),
('spl_load_fit_image', Symbol(section='.text', address=8329124,
size=552, weak=False)), ('spl_mmc_load_image', Symbol(section='.text',
address=8331700, size=796, weak=False)), ('spl_sdp_load_image',
Symbol(section='.text', address=8334688, size=2052, weak=False)),
('.binman_sym', Symbol(section='.binman_sym', address=8392576, size=0,
weak=False)), ('_binman_u_boot_any_prop_image_pos',
Symbol(section='.binman_sym', address=8392576, size=8, weak=False)),
('_binman_blob1_prop_image_pos', Symbol(section='.binman_sym',
address=8392584, size=8, weak=False)),
('_binman_blob2_prop_image_pos', Symbol(section='.binman_sym',
address=8392592, size=8, weak=False)),
('_binman_blob3_prop_image_pos', Symbol(section='.binman_sym',
address=8392600, size=8, weak=False)),
('_binman_blob4_prop_image_pos', Symbol(section='.binman_sym',
address=8392608, size=8, weak=False)),
('_u_boot_list_2_spl_image_loader_2_BOOT_DEVICE_BOARD0spl_sdp_load_image',
Symbol(section='.u_boot_list', address=8396392, size=24, weak=False)),
('_u_boot_list_2_spl_image_loader_2_BOOT_DEVICE_MMC10spl_mmc_load_image',
Symbol(section='.u_boot_list', address=8396416, size=24, weak=False)),
('_u_boot_list_2_spl_image_loader_2_BOOT_DEVICE_MMC20spl_mmc_load_image',
Symbol(section='.u_boot_list', address=8396440, size=24, weak=False)),
('_u_boot_list_2_spl_image_loader_2_BOOT_DEVICE_MMC2_20spl_mmc_load_image',
Symbol(section='.u_boot_list', address=8396464, size=24, weak=False)),
('.image_copy_end', Symbol(section='.image_copy_end', address=8398288,
size=0, weak=False)), ('_image_binary_end', Symbol(section='.end',
address=8398288, size=0, weak=False))])

Tim