jclsn7 has quit [Quit: Ping timeout (120 seconds)]
jclsn7 has joined #u-boot
jclsn7 has quit [Ping timeout: 250 seconds]
jclsn7 has joined #u-boot
darkapex has quit [Ping timeout: 256 seconds]
darkapex has joined #u-boot
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
fdanis_away is now known as fdanis
guillaume_g has joined #u-boot
monstr has joined #u-boot
mckoan|away is now known as mckoan
<milkylainen>
Stupid question. Did sjg1s code regarding running u-boot as an UEFI-app, while relying on UEFI services.. did it make it to a release?
<xypron>
milkylainen: yes, see e16c47fa3d2e051
<milkylainen>
xypron: Oh. tnx.
lucaceresoli has joined #u-boot
matthias_bgg has joined #u-boot
apritzel has joined #u-boot
camus1 has joined #u-boot
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
prabhakarlad has joined #u-boot
mwalle has quit [Quit: WeeChat 3.0]
mwalle has joined #u-boot
ldevulder has joined #u-boot
ekathva_ has joined #u-boot
ekathva_ has quit [Remote host closed the connection]
camus has quit [Ping timeout: 240 seconds]
camus has joined #u-boot
Harm has quit [Ping timeout: 256 seconds]
Harm has joined #u-boot
<Tartarus>
marex: So that I can be efficient in queuing up CI, is there a u-boot-sh PR coming shortly too?
mmu_man has joined #u-boot
lucaceresoli_ has joined #u-boot
lucaceresoli has quit [Ping timeout: 252 seconds]
<mps>
iiuc u-boot can't load compressed kernel on arm64?
apritzel has quit [Ping timeout: 250 seconds]
<kettenis>
you really should be using the EFI stub on arm64 and there is no compressed kernel support for that for the arm64 kernel
<mps>
yes, I use that now
<mps>
but trying to boot compressed kernel directly with u-boot, uncompressed loads fine but it is about 3 times bigger than compressed and need more time to load from (slow) usb flash drives
<Tartarus>
kettenis: I wonder what we should or shouldn't do about bootefi and compressed image + EFI stub. Since other things like grub will decomp and then boot I'm sure
<Tartarus>
xypron: Thoughts on that?
<kettenis>
Tartarus: EFI purists will not like that but I suppose U-Boot could just load the compressed binary into memory and execute it using bootefi
<xypron>
Tartarus: kettenis: supporting gzip compressed EFI binaries would be helpful. Some distros tend not to decompress vmlinuz.
<Tartarus>
So perhaps adding support for kernel_comp_addr_r/kernel_comp_size, similar to how booti does it, would make sense?
<xypron>
Yes we should use the same env variables
<Tartarus>
I'd also wish distros would stop using gzip and use lz4/lzo, but that's another matter :)
<xypron>
Ubuntu uses zstd for initrd.
<Tartarus>
There's more diversity in initrd/initramfs land, yeah
<xypron>
Linux supports CONFIG_KERNEL_ZSTD
<Tartarus>
but iirc when I checked a year and a half or so ago, lzo or lz4, I forget which, ended up being best for size and speed
<Tartarus>
I forget if zstd was an option
<Tartarus>
Might have been closer to 2 years ago
<Tartarus>
Anyhow
<xypron>
zstd ends up a bit better.
<Tartarus>
It's all in image_decomp atm
<kettenis>
I think distros should just use an actual EFI bootloader, but I can see why embedded folks wouldn't want to do that
<kettenis>
So making it "easier" for those to boot via the kernel EFI stub would be good
camus has quit [Quit: camus]
<kettenis>
the hatred for grub seems to run deep in some circles
<Tartarus>
Almost as deep as the hatred for not-grub in other circles ;)
<apalos>
if it's hatred and grub count me in :D
<kettenis>
Tartarus: btw, thanks for taking the M1 diffs; it means we now have something that is completely usable for almost all setups
<Tartarus>
kettenis: nice
<Tartarus>
I keep wishing I could justify a new/different laptop :)
<Tartarus>
and going back to linux on a mac would be personally hilarious
<Tartarus>
(I started with mklinux back in the day on a performa 6100)
<kettenis>
The diffs me and jannau posted for M1 Pro/Max support only touch board-specific so maybe there is time to get those into 2022.04 as well?
matthias_bgg has quit [Quit: Leaving]
<mps>
Tartarus: thanks, will read
<marex>
Tartarus: no
<mps>
on x86 I used syslinux mostly but now on m1 had to relearn grub, and I boot fine linux with m1n1+u-boot payload (thanks to kettenis and jannau)
<Tartarus>
kettenis: Probably so, yeah
<Tartarus>
marex: ok, thanks
<mps>
but would like to skip grub, and with uncompressed kernel that works
<mps>
Tartarus: ah, thanks again, now I understand, kernel_comp_addr_r is what I need
<mps>
(only don't to what to set it)
Thorn has joined #u-boot
monstr has quit [Ping timeout: 240 seconds]
monstr has joined #u-boot
ladis has joined #u-boot
torez has joined #u-boot
<milkylainen>
uefi app mode. memory obviously from uefi. So I need malloc for loadaddresses. How large can these be?
<milkylainen>
I'm getting a null pointer back from a large memaligned malloc.
<xypron>
milkylainen: The UEFI app allocates memory via AllocatePages() from the EFI host. Only this memory can passed out via malloc(). If you want more memory you will have to find out how the AllocatePages() call is controlled.
<xypron>
milkylainen: lib/efi/efi_app.c:139: ret = boot->allocate_pages(
<xypron>
CONFIG_EFI_RAM_SIZE
<xypron>
defaults to 1 GiB
<milkylainen>
malloc_cache_aligned?
<xypron>
milkylainen: page size aligned = 4096
<xypron>
milkylainen: the allocated memory for the app is 4096 aligned.
<milkylainen>
Yes, but any other restriction on malloc sizes?
<xypron>
Why would you malloc() for load addresses?
<xypron>
milkylainen: what is the alignment?
<milkylainen>
xypron: What do you mean? Where would I place loaded kernels? I have no idea where efi is going to give me memory to play with.
<xypron>
milikylainen: you load the kernel at $load_addr or $kernel_addr_r using the load command. No allocation involved.
<xypron>
milkylainen: EFI is out of the game at that time.
<milkylainen>
I don't follow. U-boot in efi-app mode cannot access whatever memory it chooses? Right? So I get a heap pointer from uefi to use. And I load a kernel/initrd whatever. Who assigns the load_addr? I was under the impression that I take a cake of the allocation, place my loaded blob there and tell the load mechanism where the data is at.
<xypron>
milkylainen: There is the EFI app which uses the UEFI which loaded it as a backend. And there is the EFI payload which ignores the UEFI which loaded it and has full system access.
<xypron>
milkylainen: $load_addr in the sandbox and I guess also in the EFI app is just a virtual address and not a physical one.
<xypron>
it is an offset to the allocated memory
<xypron>
milkylainen: As said the memory used by the EFI app is 4096 aligned. If the virtual address passed to the load command is also 4096 aligned you can be sure that the loaded image is 4096 aligned.
<xypron>
milkylainen: what do you try to develop?
<milkylainen>
xypron: Just trying to load a kernel image when in uefi app mode.
<xypron>
milkylainen: just use the load command: load efi 0:1 $kernel_addr_r /boot/vmlinuz. This should use the first block device offered by the UEFI API of that loaded the app.
<xypron>
I am not sure if it is really called "efi". Just use lsblk
<milkylainen>
xypron: there is no file. It's a data offset in an emmc.
<xypron>
milkylainen: you have no access to eMMC if it is not provided by the underlying UEFI
<milkylainen>
yes, it's efi as block layer. But it's still no file. It's a data offset.
<xypron>
the app uses the block_io_protocol provided by UEFI to access the block devices
jkridner has joined #u-boot
<milkylainen>
"kernel_addr_r=0x1000000\0"
<milkylainen>
How do you even know that it's a sane address if UEFI gave you a heap pointer to use for memory? I would expect that you shouldn't be able to touch memory outside the efi heap pointer?
<milkylainen>
I am loading data at a data offset on a block device. Block device happens to be efi.
<milkylainen>
Provided by efi.
<milkylainen>
I need to go. Maybe there is a irclog somewhere?
<Tartarus>
Or is it because we don't pass -Werror to host tools
<Tartarus>
xypron: Any ideas on what to do about this? I feel like it's not an obvious change since other tooling depends on that struct?
<Tartarus>
xypron: I'm otherwise willing to take this now and raise it to Akashi-san to address in a follow-up
<Tartarus>
assuming nothing else shows up
<xypron>
Tartarus: we should replace WIN_CERTIFICATE hdr; by the relevant fields. Let me fix that patch and resubmit a pull request.
<Tartarus>
xypron: OK
<xypron>
Tartarus: which defconfig made the warning show up?
<Tartarus>
xypron: sandbox
<Tartarus>
and clang, not gcc
<xypron>
ok clang
mripard has quit [Ping timeout: 256 seconds]
mripard has joined #u-boot
sakman_ is now known as sakman
ladis has quit [Ping timeout: 256 seconds]
<xypron>
Tartarus: is there a list of tools that need to be fixed to switch -Werror on?
<Tartarus>
xypron: Only mkeficapsule showed that
<Tartarus>
non-Linux hosts have had some other warnings as seen in azure for forever and aren't urgent to deal with
<xypron>
Tartarus: the diff needed for mkeficapsule was small. Can we fix those warnings in Azure to get the build flag?
<Tartarus>
xypron: A follow up series to address that stuff would be great, yes. Are you going to re-send the EFI PR, or should I jsut fold that change in?