09:04 <hramrach> hello,

09:04 <hramrach> how do you chainload u-boot?

09:05 <hramrach> it's the standard way of booting Snow so it's certainly possible but is it documented sonewhere how to do it ???

12:21 <xypron> Tartarus: https://lists.denx.de/pipermail/u-boot/2022-July/487870.html looks release critical to me.

12:22 <Tartarus> xypron: ugh, ok. How about the security fix from siemens?

12:23 <xypron> Tartarus: I did not receive any v2 from Takahiro.

12:24 <xypron> I am currently running Gitlab CI with aforementioned patch and a patch related to reading block devices via the EFI_BLOCK_IO_PROTOCOL and will send you a pull request for both if CI is happy.

12:27 <xypron> Tartarus: '[PATCH] efi_loader: Allow overlapped extra data for PE hashing' is nothing that Ilias and I would like to merge in the current state.

12:41 <Tartarus> OK

13:07 <xypron> Tartarus: shouldn't CONFIG_SYS_64BIT_LBA be the default (at least for 64bit systems)? If we can't get rid of the flag it should live in Kconfig.

13:08 <Tartarus> xypron: It's a bit confusing at times, see the migration patch, sec

13:08 <Tartarus> xypron: aca1f6789aa2e384a58909fa7a9696db9d607675 in next

13:09 <xypron> :+1:

13:09 <Tartarus> I don't think default y if ARM64 helps tho

13:10 <Tartarus> it's not really about CPU bitsize

13:14 <xypron> CONFIG_SYS_64BIT_LBA makes lba_int u64 otherwise it is unsigned long which is also 64bit on 64bit systems. So this flag seems have significance only on 32bit systems.

13:29 <dossalab> Hi! I have a question - what's the strategy for porting u-boot to a memory-restricted SoC? I have about 32K of SRAM in icache and dcache and u-boot doesn't fit there. I think ARM uses SPL, but I never saw it on my arch (SuperH). I'm not really sure why u-boot even tries to relocate itself to RAM that early, why not just run from flash?

13:43 <urja> i think that might be too little to run u-boot properly (even with the code in XIP flash)... and what would you load? where? :P

13:45 <urja> it should be enough for an SPL yep, there are even more restricted SPLs afaik (and that's what you should do if you need to do SDRAM init or such)

13:47 <urja> but yeah a lot of the boot methods u-boot uses (from MMC or SD card or NAND, on a filesystem, many SPI controllers, etc) do not allow code execution..

13:47 <xypron> dossalab: you can only run from NOR flash not from NAND flash. Most devices use NAND flash. Just put your ddrinit into the cache and the code to load SPL or main U-Boot into RAM.

14:03 <dossalab> yeah, the device is booting from NOR. I don't have documentation for that but it seems like it's mapping the NOR into some memory address and just executing from there. There is some DRAM of course, but it has to be bringed up and it's quite convoluted (starting the PLL, switching clocks, issuing some commands) so I would rather much do it in C environment.

14:09 <Forty-Bot> hramrach: in what context

15:03 <hramrach> Forty-Bot: I have u-boot that is slightly deficient and cannot read the system from the medium where it is, and I want to load a new, possibly fixed build

15:04 <Forty-Bot> what can you load from?

15:04 <hramrach> usb(works)/mmc(does not currently)

15:05 <hramrach> I suppose I could load from serial if I really wanted, too

15:05 <hramrach> it's a pretty general thing, I don't understand why it's so difficult

15:06 <hramrach> the code for loading u-boot must exist in the SPL

15:07 <hramrach> https://paste.debian.net/1245973/

16:39 <Forty-Bot> hramrach: edit your fit and change the type of U-Boot's image to kernel

16:49 <hramrach> Forty-Bot: is that something that would work in general and can be changed in the build system or does it have to be different for normal boot and chainload?

16:50 <Forty-Bot> would need to be different

16:50 <Forty-Bot> but as I understand it you just need to do this once?

16:53 <hramrach> it sounds like it would be useful in general to be able to load the u-boot as kernel

17:40 <hramrach> Forty-Bot: https://paste.debian.net/1245988/ changing the image type did not really help but changing the config to list 'uboot' as the kernel did but now it complains that there is no entry point defined

17:41 <Forty-Bot> the entry point should be the same as the load address

17:42 <hramrach> maybe it's better to extract the u-boot image and then jump to it, or use a binary image without the FIT wrapper?

17:43 <Forty-Bot> you can do that too

17:43 <hramrach> also for some reason in this build the ATF image is in the config but is not included :s

17:43 <Forty-Bot> actually, the easiest thing to do here is get your u-boot.bin

17:43 <Forty-Bot> load it to some address

17:43 <Forty-Bot> and then use the go command

17:46 <hramrach> that locked up

17:46 <hramrach> but I cannot boot Linux either so maybe this build is more than slightly broken

17:47 <Forty-Bot> err, the address has to be U-Boot's load address (I forget the symbol name, but you can find it in the elf)

17:47 <Forty-Bot> and if you want to debug things further, try enabling the debug uart

17:49 <hramrach> this? CONFIG_SYS_LOAD_ADDR=0x800800

17:57 <Forty-Bot> yes

17:57 <Forty-Bot> I think?

17:58 <hramrach> hm, does not work either

18:00 <Forty-Bot> look for _start in your u-boot elf

18:03 <hramrach> this ? 0000000000200000 T _start

18:06 <hramrach> yes, this worked, thanks

18:06 <hramrach> nonetheless, the build is broken anyway

18:07 <hramrach> but I at least get the command that switches to the USB download mode with this build so

18:08 <hramrach> I can rewrite the mmc with that