<MWelchUK>
sjg1 Using a second config file seems like a bit of a hack to me - but no, I don't think that "fallback" is part of the standard file format, however I'm not sure what is considered the official format. Looking at the documentation from the syslinux project, they document the labels being in all caps. It notes that lilo uses a syntax that is lower
<MWelchUK>
case with equals signs used between the labels and values. The version used by U-Boot seems to be between these...
naoki has joined #u-boot
persmule has quit [Remote host closed the connection]
<apalos>
MWelchUK: how do you boot? an EFI image or not>?
<MWelchUK>
apalos: By EFI, I assume you mean using GPT partitioning with an EFI partition having the correct GUID?
<apalos>
no, I mean using bootefi commands even via the bootmeth
<apalos>
so bootmeth, when using UEFI, either calls bootefi + an image or the efi boot manager directly,
<apalos>
the latter has the functionality you want, you can define multiple boot options and if something fails it can fallback to thenext one
glaroque has joined #u-boot
<MWelchUK>
apalos: Right, so no, we're using the the extlinux approach via bootmeth_extlinux, not bootmeth_efi.
<apalos>
ah ok
<MWelchUK>
But it's interesting to know there's a fallback option implemented somehow in the EFI support.
<apalos>
EFI defines its own boot manager, so when bootmeth is trying to boot that, it doesnt reimplement any logic
<apalos>
it just starts the manager and assumes it's going to take care of the rest
<MWelchUK>
Right, so that's more a part of EFI than support baked into U-Boot.
<apalos>
u-boot does support a lot of efi
<apalos>
basically all the functionality to boot BSDs and Linux similarly, -- e.g you can install a distro nowadays
<apalos>
well as long as the distro has all the driver you board needs
<apalos>
drivers your*
<apalos>
there's an easy way to test it actually,
<apalos>
Assuming you compiled u-boot with it,
<apalos>
type 'eficonfig' and add your GRUB or kernel as a boot option
<apalos>
oh and then either configyre bootmeth to use that, or type 'bootefi bootmgr'
<MWelchUK>
How does that config get stored?
<apalos>
which one? the eficonfig?
<MWelchUK>
Yeah
<apalos>
It gets stored as 'EFI variables'
<apalos>
so you 2 options, either in a file or an RPMB assuming your board has one
<apalos>
In the 'file' case there are some restricitons wrt to security, but you can prebuilt u-boot with variables
<apalos>
lemme find an overview I wrote once
<MWelchUK>
Right, so what I'd see as the "EFI" directory on x86 based devices?
<apalos>
yes and in that dir, you'll find a file with the variables
<apalos>
that secure boot specific, but still explains the weirdness of variables
<MWelchUK>
I suspect this would be a bot too much of a change at the moment and would have wider implications that would need to be carefully concidered.
<apalos>
no idea what your architecture looks like
<apalos>
but generally speaking, u-boot implements only a small portion of EFI
<apalos>
what's absolutely needed to boot an OS, so its not that big.
<MWelchUK>
We support x86, multiple arm32 and arm64 platforms...
<apalos>
yea well that's the entire of EFI
<apalos>
that regardless of the architecture you boot an identical image, that has identical security entry points to the OS etc
<apalos>
well identical, minus the architecture ISA :>
<MWelchUK>
Hmm, so with the EFI in U-Boot, secureboot variables would need to be baked into the U-Boot binary?
<apalos>
yes
<apalos>
well unless you have an eMMC & RPMB
<apalos>
in that case you can manage those as you do in an x86 system
<apalos>
the tl;dr is that you need secure storage, and if you dont have we dont allow you to write them
<apalos>
You can update them, by updating the entire binary
<apalos>
you *can* update non security critical variables even on the file though. We only prohibit the variables that control secure boot to be tampered with
<MWelchUK>
I think in a number if instances we have the U-Boot binary installing in SPI flash or similar...
<apalos>
you can update u-boot pretty rialbly from EFI
<apalos>
there's this notion of capsules updates which basically updates the fw
<apalos>
and this even ties to the OS nowadays -- e.g you can trigger it with feupd
<apalos>
fwupd*
<MWelchUK>
It's been a while since I looked at the details of how secureboot is implemented for us.
<MWelchUK>
Realistically at this point, it's too big a change right now.
<apalos>
yea it is
<apalos>
but this is another thing you gain
<apalos>
secure boot is identical across all hardware in EFI
<apalos>
so it do it once and forget. At least from the loader to booting the OS
<MWelchUK>
Well, I assume that's once you've got to U-Boot loading :-)
<apalos>
exactly
sugoi has joined #u-boot
sugoi has quit [Ping timeout: 265 seconds]
___nick___ has joined #u-boot
___nick___ has joined #u-boot
mmu_man has quit [Ping timeout: 260 seconds]
mmu_man has joined #u-boot
naoki has quit [Quit: naoki]
Net147 has quit [Quit: Quit]
Net147 has joined #u-boot
Net147 has quit [Changing host]
Net147 has joined #u-boot
persmule has joined #u-boot
sugoi has joined #u-boot
sugoi has quit [Ping timeout: 276 seconds]
Knogle has joined #u-boot
rvalue has quit [Remote host closed the connection]
rvalue has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
Stat_headcrabed has joined #u-boot
tepperson has joined #u-boot
sugoi has joined #u-boot
sugoi has quit [Ping timeout: 276 seconds]
monstr has quit [Remote host closed the connection]
prabhakalad has quit [Quit: Konversation terminated!]
___nick___ has quit [Ping timeout: 252 seconds]
___nick___ has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
redbrain has joined #u-boot
alan_o has quit [Ping timeout: 246 seconds]
sugoi has joined #u-boot
sugoi has quit [Ping timeout: 260 seconds]
prabhakalad has joined #u-boot
<prabhakalad>
Hi, when switching to upstream dts I see no u-boot banner printed, for this to work I maually have to add 'bootph-all' property for required nodes. Is the way moving formward?