On Sat, Jul 24, 2021 at 3:01 PM Simon Glass <s...@chromium.org> wrote: > > Hi Tim, > > On Fri, 23 Jul 2021 at 16:52, Tim Harvey <thar...@gateworks.com> wrote: > > > > On Fri, Jul 23, 2021 at 2:41 PM Simon Glass <s...@chromium.org> wrote: > > > > > > Hi Tim, > > > > > > On Fri, 23 Jul 2021 at 15:06, Tim Harvey <thar...@gateworks.com> wrote: > > > > > > > > On Thu, Jul 22, 2021 at 8:07 PM Simon Glass <s...@chromium.org> wrote: > > > > > > > > > > Hi Tim, > > > > > > > > > > On Mon, 19 Jul 2021 at 17:23, Tim Harvey <thar...@gateworks.com> > > > > > wrote: > > > > > > > > > > > > On Sat, Jul 17, 2021 at 7:22 PM Simon Glass <s...@chromium.org> > > > > > > wrote: > > > > > > > > > > > > > > > > > [..] > > > > > > > > > > > > > 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. > > > > > > > > > > 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@1,blob-ext@2,blob-ext@3,blob-ext@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
Simon, Thanks - this appears to give me some real offsets: U-Boot SPL 2021.07-00329-gb3d23cad33-dirty (Jul 26 2021 - 11:19:30 -0700) board_init_f: blob_1:0x8038dc board_init_f: blob_2:0x80b8dc board_init_f: blob_3:0x80f8dc board_init_f: blob_4:0x8178dc CONFIG_SPL_TEXT_BASE=0x7e1000 so subtracting that from above matches the offsets of the blobs in u-boot-spl-ddr.map This should work nicely... I'll continue working on my end goal. > > > > > 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@1 { > > > > filename = "lpddr4_pmu_train_1d_imem.bin"; > > > > size = <0x8000>; > > > > }; > > > > > > > > blob_2: blob-ext@2 { > > > > filename = "lpddr4_pmu_train_1d_dmem.bin"; > > > > size = <0x4000>; > > > > }; > > > > > > > > blob_3: blob-ext@3 { > > > > filename = "lpddr4_pmu_train_2d_imem.bin"; > > > > size = <0x8000>; > > > > }; > > > > > > > > blob_4: blob-ext@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. The next step of what I was interested in was to move those blobs outside of the spl binary completely and if I do that the binman solution no longer works as the blobs would be outside of flash.bin so I'm not sure how I could make use of binman there. Tim