01:43 <crb> Each zynq board should probably have it's own ps7_init_gpl.c do the board in xilinx_zynq_virt_defconfig all share a common ps7_init_gpl.c?

02:57 <marex> crb: yes, that file comes from vivado, it's a generated file

03:44 <crb> yes it comes from vivado but all the boards in the xilinx_zynq_virt_defconfig share a common version don't they or am I mistaken?

11:59 <xypron> Tartarus: $filesize is set when loading a binary. If you use the load or loady command to load an EFI binary function efi_set_bootdev() is called which remembers the size and file path of the last UEFI binary. You only need to specify the filesize for the bootefi command if you load the EFI binary via JTAG or some other trickery.

13:19 <Tartarus> xypron: Right, but I'm asking if there's something in the EFI header that would also tell us how large the file is instead, so we don't have to rely on $filesize being set

13:20 <Tartarus> I don't know if it came in via qfw which could I imagine also set filesize, or something else

16:01 <xypron> Tartarus: you can parse the section header. But this does not tell you if an initd or other content has been appended.

16:02 <Tartarus> Reasonable fall-back option you think?

16:02 <Tartarus> Or just do a better error message in general when no $filesize set nor passed?

16:03 <xypron> Tartarus: isn't injecting sn EFI binary without load a border case?

16:04 <Tartarus> Depends on how many people start trying to boot with QEMU

16:04 <Tartarus> Which could get pretty big

16:05 <xypron> Tartarus: In what strange way is QEMU invoked that does not load GRUB from the ESP?

16:48 <xypron> dormito: enabling CONFIG_DEBUG_UART could give you earlier feedback.

16:56 <Tartarus> xypron: When not booting grub and passing in -kernel, etc and using qfw to load them, I guess?

16:57 <xypron> Tartarus: -kernel is meant to be used for booting via Linux's legacy entry point not for UEFI booting?

16:58 <Tartarus> No? It's meant for passing in a kernel to boot

16:58 <Tartarus> And since "everyone" wants to use the kernel EFI stub..

16:58 <xypron> Tartarus: this is not what QEMU documents.

16:59 <xypron> On RISC-V -bios OpenSBI -kernel U-Boot

16:59 <Tartarus> Yes, imho "kernel" is just a legacy name

16:59 <Tartarus> Since we're not "the kernel"

17:00 <xypron> If you want to load a kernel from the file system use semi-hosting.#

17:00 <Tartarus> Anyhow, I would think a better error message at minimum when trying to boot an EFI payload without $filesize set is a reasonable sanity check

17:00 <xypron> We already check the headers in that case.

17:00 <Tartarus> But -kernel has been documented as how to pass "the kernel" for 15 years, more or less

17:01 <Tartarus> afk lunch

17:01 <xypron> efi_check_pe()

17:01 <xypron> 15 years of booting x86 without EFI

18:57 <mps> anyone knows is somewhere guide/tutorial about using uEnv.txt

18:57 <mps> I have problem on setting some parameters on riscv visionfive SBC

21:53 <bq> Just sanity checking my research so far: if I use TFA before U-Boot, generally this replaces the SPL right? With regards to performing DRAM init and such

23:21 <apritzel> bq: I'd say that depends more on the design, not on how you "use

23:21 <apritzel> *"use it"

23:22 <apritzel> some platforms initialise DRAM externally, by some management processor, so before the first code ever runs on the application processor

23:23 <apritzel> bq: some other platforms run the SPL first (to indeed initialise DRAM, for instance), then TF-A, then U-Boot proper

23:31 <bq> Ah ok. That makes sense

23:31 <bq> I'm looking at for example freescale's LS1 platform, where the defconfig (comparing ls1043ardb_sdcard_defconfig vs ls1043ardb_tfa_defconfig) seems to switch SPL out for TF-A

23:33 <bq> this seems to carry to the LS1046 too, but like you say I guess it's technically possible to do it in any order

23:35 <apritzel> bq: I think Freescale is an exception (for historic reasons), typically you either *need* the SPL, or you don't have it, having an actual choice is rare

23:36 <bq> I haven't dug too deep into the SPL on this platform but AFAIK at minimum it has to initialise DRAM and load big U-Boot

23:37 <bq> So the choice is between SPL and "no SPL but something that inits DRAM and loads something into it" as I understand

23:37 <bq> I guess other platforms require more of the SPL, so you might be forced to do e.g. SPL -> TFA -> Big U-Boot?

23:38 <apritzel> yes, many platforms just use the *runtime* component of TF-A (BL31), so the loading is entirely in U-Boot's (SPL's) hands

23:38 <bq> Oh neat. So they get U-Boot to load BL31?

23:39 <apritzel> yes, that is typically part of a FIT image, containing BL31, some DTs, and U-Boot proper

23:40 <apritzel> not to be confused with using a FIT image to bundle a Linux kernel, initrd, DT

23:40 <bq> Makes sense. I didn't realise SPL can load FITs

23:40 <bq> sane enough container for it though

23:41 <apritzel> CONFIG_SPL_LOAD_FIT

23:41 <apritzel> container> indeed, and we have libfdt parsing code already

23:42 <bq> true. Device tree all the way down