Hi Simon, On Sun, Dec 3, 2023 at 5:44 PM Simon Glass <s...@chromium.org> wrote: > > Hi Shantur, > > On Sat, 2 Dec 2023 at 16:03, Shantur Rathore <i...@shantur.com> wrote: > > > > Hi Simon, > > > > On Fri, Dec 1, 2023 at 6:44 PM Simon Glass <s...@chromium.org> wrote: > > > > > > Hi Shantur, > > > > > > On Mon, 27 Nov 2023 at 10:27, Shantur Rathore <i...@shantur.com> wrote: > > > > > > > > + Simon as he seems to have done a lot of work in the driver model. > > > > > > > > On Mon, Nov 27, 2023 at 10:12 AM Shantur Rathore <i...@shantur.com> > > > > wrote: > > > > > > > > > > Hi Ilias, > > > > > > > > > > On Mon, Nov 27, 2023 at 7:16 AM Ilias Apalodimas > > > > > <ilias.apalodi...@linaro.org> wrote: > > > > > > > > > > > > Hi Shantur > > > > > > > > > > > > On Sun, 26 Nov 2023 at 12:33, Shantur Rathore <i...@shantur.com> > > > > > > wrote: > > > > > > > > > > > > > > Hi Peter, > > > > > > > > > > > > > > On Sat, Nov 25, 2023 at 6:19 AM Peter Robinson > > > > > > > <pbrobin...@gmail.com> wrote: > > > > > > > > > > > > > > > > Hi Shantur, > > > > > > > > > > > > > > > > On Fri, Nov 24, 2023 at 11:55 PM Shantur Rathore > > > > > > > > <i...@shantur.com> wrote: > > > > > > > > > > > > > > > > > > Hi Ilias, > > > > > > > > > > > > > > > > > > On Fri, Nov 24, 2023 at 10:50 PM Ilias Apalodimas > > > > > > > > > <ilias.apalodi...@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > Hi Shantur > > > > > > > > > > > > > > > > > > > > On Fri, 24 Nov 2023 at 18:51, Shantur Rathore > > > > > > > > > > <i...@shantur.com> wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Heinrich, > > > > > > > > > > > > > > > > > > > > > > I am trying to work out how to enable the SetVariableRT > > > > > > > > > > > service in > > > > > > > > > > > U-Boot and came across your patch [1] which initially had > > > > > > > > > > > the > > > > > > > > > > > SetVariable RT service enabled in EFI but in the final > > > > > > > > > > > patch this was > > > > > > > > > > > removed. > > > > > > > > > > > I am hoping to implement it on top of the SPI Flash EFI > > > > > > > > > > > store [2] to > > > > > > > > > > > be able to set Boot order and boot items from Linux the > > > > > > > > > > > UEFI way. > > > > > > > > > > > > > > > > > > > > > > Can I pick your brain on why it was dropped in the patch? > > > > > > > > > > > Is there any limitation in SetVariableRT service ? > > > > > > > > > > > > > > > > > > > > I recently had a talk about it in Plumbers [0]. Generally > > > > > > > > > > speaking, RT > > > > > > > > > > + hardware owned by the kernel is a very weird combination > > > > > > > > > > since you > > > > > > > > > > can't guarantee exclusive access to the flash or the bus > > > > > > > > > > and you have > > > > > > > > > > to preserve a *lot* of code alive in u-boot. > > > > > > > > > > > > > > > > > > > > I'll respond to your v1 patchset and we can discuss details > > > > > > > > > > there as well. > > > > > > > > > > > > > > > > > > > > [0] https://lpc.events/event/17/contributions/1653/ > > > > > > > > > > > > > > > > > > Thanks for the background and helping me understand the > > > > > > > > > problem. > > > > > > > > > Makes me wonder how things work in the PC world. > > > > > > > > > U-boot being only ~1MB, can we not leave it all in memory and > > > > > > > > > maybe > > > > > > > > > just disable SPI access to Linux. > > > > > > > > > > > > That would work, but you cant guarantee Linux wont enable the SPI > > > > > > flash. > > > > > > > > > > > > > > > > > > > > > > That's basically it, on x86 there's specific HW that's owned by > > > > > > > > firmware, I don't know the exact low level details of how that > > > > > > > > works. > > > > > > > > > > > > > > > > I think x86 devices generally use eSPI for this HW [1] but I > > > > > > > > don't > > > > > > > > know the low level details. The Arm SBSA (Server HW spec) and > > > > > > > > SBBR > > > > > > > > (Server Base Boot Requirements) specs that are key to > > > > > > > > ServerReady may > > > > > > > > go into some details too if you're curious. > > > > > > > > > > > > On X86 the SPI flash is handled entirely by the firmware and SMM. > > > > > > You > > > > > > can find more details here [0] > > > > > > > > > > Thanks for more info. > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > I think the firmware is still accessible to PCs as one could > > > > > > > update the firmware > > > > > > > in Windows so Windows has access to that device. > > > > > > > > > > > > > > I had some try myself and found that setting a variable to memory > > > > > > > backed storage > > > > > > > is doable with SetVariable call but we want to store it in any > > > > > > > non-volatile storage > > > > > > > things really don't look good. > > > > > > > > > > > > > > To be able to write SetVariable to any device, the whole u-boot > > > > > > > driver > > > > > > > model would need > > > > > > > to be kept in memory, might as well just keep the whole u-boot in > > > > > > > memory at this point, it's anyway small. > > > > > > > I don't have much knowledge on how to or pros and cons of doing > > > > > > > this. > > > > > > > > > > > > The major problem here is who owns the hardware. With the SPI flash > > > > > > implementation as well as the RPMB implementation Linux owns that > > > > > > flash. > > > > > > For the RPMB we've introduced a mechanism so the kernel replaces the > > > > > > runtime calls with internal functions [1]. I think we should come > > > > > > up > > > > > > with a similar architecture for SPI. In any case we should keep in > > > > > > mind that setting authenticated EFI variables should be forbidden on > > > > > > the file/SPI backends since they are not really secure. > > > > > > > > > > > > > > > > Thanks, I understand now that we can't use SPI flash for saving secure > > > > > variables and stop Linux from accessing it. > > > > > My requirement is to be able to save non-Secure boot related variables > > > > > ( BootOrder, BootNext and BootOptions ). > > > > > For this purpose as we don't need secure channel and to be compatible > > > > > with current Linux versions I started > > > > > implementing SetVariable in runtime in [1] > > > > > I was able to get it working until it's ready to write stuff into SPI > > > > > Flash. > > > > > > Yes, this makes sense to me and we don't need secure vars for these > > > features. They are really just hints from the OS or user. > > > > > > > > To be able to use SPI Flash, runtime call needs to access the drivers > > > > > and this needs the whole driver-model to be in > > > > > efi runtime memory makes me think would it make sense to keep the > > > > > whole u-boot in efi runtime memory or just > > > > > driver model and all SPI drivers for now and keep adding other drivers > > > > > when needed like RPMB. > > > > > > I don't fully agree with this. The OS is well able to access SPI flash > > > or any other device. There is no need to ask the firmware to do it, > > > unless there is some other reason. I can understand calling into a > > > secure OS, or using a TPM, but for SPI flash this doesn't make much > > > sense to me. > > > > > > > Sure, the OS can write to SPI Flash but the OS won't know what / where to > > write > > that U-Boot will be able to read and use as an EFI variable. > > AFAIK, all UEFI firmwares have some non volatile storage where firmware > > stores > > variables. As U-boot doesn't have its own non-volatile storage we want > > to allow u-boot to > > write EFI variables in SPI. > > This is needed to be able to manage EFI boot entries with efibootmgr in > > Linux. > > We can pass the offset of the vars to the OS using the devicetree, > e.g. using the fixed-partition binding, so then fwupd (or whatever) > can do the update. >
Sure, we could do this but then this would be a non-standard way of managing the EFI variables. > > > > Why does he need it, you might think. > > My aim is to automate OS deployment on ARM boards for which I use > > Canonical MAAS. > > As a netinstall process the boot partition is configured as part of install. > > As EFI/boot/bootxxxx.efi is optional [0], some distros like debian and > > debian based Armbian > > don't install EFI/boot/bootxxxx.efi by default, it tries to set a boot > > entry with efibootmgr > > and can't so I had to disable it. > > Now that update nvram is disabled in grub-install, it doesn't set up a > > boot variable but > > also doesn't install EFI/boot/bootxxxx.efi but EFI/debian/grubxxxx.efi. > > > > I am able to work around by manually forcing grub-install with --removable > > param > > to force it to install EFI/boot/bootxxxx.efi, so it kinda works. > > > > This made me think of improvements we can make in u-boot to allow it > > function more > > like real UEFI firmware where it can. > > OK, I see. > > > > > > > > > > > > > I need some pointers to what would be the best approach accessing > > > > > hardware from runtime. > > > > > > We would need to publish a runtime interface with access to the driver > > > API. I did ask for this when the EFI runtime support was added, but it > > > wasn't done. > > > > > > It would be possible to create a new 'runtime' phase of U-Boot (RPL?), > > > separate from the others. That will be much easier once we get the XPL > > > stuff sorted out., since adding new [hase would be fairly trivial CPL > > > died as another contributor had a series which went in first...then I > > > never got back to it. > > > > > > So for now having the entire U-Boot in runtime space seems reasonable to > > > me. > > > > > > I'll also mention that it would be nice to have s new-style API > > > (replacing the old API U-Boot currently has) which uses more of a > > > module approach. E.g. we could declare that uclass_first_device() is > > > exported and can be called from outside U-Boot. > > > > I think this is way more deep than my current understanding of the u-boot > > and > > boot process. I might be able to implement this if and when RPMB access is > > implemented for OP-TEE based access. > > Yes...it is a tricky area, but perhaps we can copy what Linux does > with the EXPORT_SYMBOL() macro. Anyway, that is for the future > Maybe, I will park this for now and wait for the OP-TEE RPMB solution. Kind regards, Shantur