00:27 <dormito> Hmmm anyone familiar with the i.mxrt1170-evk? I have a sw stack the boots off the sdcard, but I am having trouble getting some hw blocks to work, so I built the defconfig (on master), and installed it (according to doc/board/nxp/imxrt1170-evk.rst), however there is no output. When I took a look at the imx boot structs in the SPL image, they seemed to disagree with my own. I think they are pointing

00:27 <dormito> to memory addresses the rom code can't access.

00:32 <dormito> to clarify: I have my own sw stack that rom code boots successfully off the sdcard. I built u-boot wanting to see other code.

00:49 <dormito> Ohhh. I'm pretty sure tools/imximage.c is NOT endian safe. I built on a big endian system

02:48 <Forty-Bot> dormito: yes, that file is not endian safe

02:48 <Forty-Bot> patches welcome

02:48 <Forty-Bot> but you also need to fix the parsing of imximages in U-Boot itself

06:32 <conchuod> Tartarus: those boot failures due to the bloblist array entry that I reported in January are back. I've unfortunately not had a chance to look at it again.

07:23 <dormito> Hmmm. Still no SPL output with (hopefully) endian safe images... It looks like imx header is trying to load the image so that it's straddling the OCRAM1/OCRAM2 boundary (e.g. self at 0x202bf400, but entry at 0x202c0000)... IIRC I wasn't able to get that to work, and had to move mine all into one OCRAM block

07:29 <dormito> (and I'd be happy to send patches, assuming I can get it working/tested enough)

08:18 <dormito> nice. found the last endian-unsafe bit I was missing, now spl complain binman_init failing. But that's a lot easier to debug lol.

08:20 <dormito> for the endian-safe imx_header stuff: My normal approach would be to use gcc's __attribute((scalar_storage_order("little-endian"))) (and "big-endian", since this imx_header ends up using both..). However because mkimage takes a pointer to the size field, this won't work without a refactor.

08:21 <dormito> on the other hand, using htobe32/htole32 (and friends) kills the += operator, and IMHO makes the code a bit more fragile. Does u-boot have policy on how those sorts of things are done?

08:25 <dormito> minor correction: it's u-boot proper (not spl) that has binman issues

13:13 <linfax> hello, I have an old defconfig with the env CONFIG_LOADADDR which is it seems the address to which tftp puts the payload kernel? but now this env is not used any more, which is the new name? thanks

13:16 <Tartarus> No, "loadaddr" is where things are put if there's nothing passed

13:16 <Tartarus> you might try "make u-boot-initial-env" and see what's being set by default in the build

13:36 <linfax> what does it mean 'if there's nothing passed'? Is it the start address of u-boot itself or the payload kernel?

13:41 <linfax> seems that is where the payload kernel starts (kernel_addr_r) but it's only the default address, if I omit a specific address?

14:43 <Tartarus> If you don't tell the command where to put things in memory then loadaddr is used

14:43 <Tartarus> tftp doesn't look at the what you're loading to memory

22:36 <xypron> Tartarus: In https://source.denx.de/u-boot/u-boot/-/jobs/789218 some tests are used due to missing bootgen and fiptool. Ubuntu has a package xilinx-bootgen. Should this be installed in our Dockerimage? fiptool I guess is provided by TF-A.

22:37 <xypron> ... tests are skipped ...

22:38 <Tartarus> Yeah, perhaps. And I'm testing/pushing the series now to have /opt/coreboot/cbfstool always exist, we could add that to PATH and run that