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