search

andreiw / RaspberryPiPkg

DEPRECATED - DO NOT USE | Go here instead ->
https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi3
744 stars 143 forks source link

pseudo-NVRAM doesn't flush on EFI application/loader image loading another EFI app/loader image #47

Closed esnowberg closed 5 years ago

esnowberg commented 5 years ago

If I use one of the pre-built images the pseudo-NVRAM works fine. However, if I follow the build instructions within the readme. The new RPI_EFI.fd image I built works, with the exception of the pseudo-NVRAM. Are there additional build steps to get that to work?

andreiw commented 5 years ago

What are the exact steps and what behavior are you seeing exactly? An attached serial log from a debug build will be useful.

A

On Jul 5, 2018, at 4:12 PM, Eric Snowberg notifications@github.com wrote:

If I use one of the pre-built images the pseudo-NVRAM works fine. However, if I follow the build instructions within the readme. The new RPI_EFI.fd image I built works, with the exception of the pseudo-NVRAM. Are there additional build steps to get that to work?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

esnowberg commented 5 years ago

I'm trying to set the System BootOrder and add a Boot Entry. It will persist with your prebuilt image. But it doesn't with the one I built.

Debug log attached. nvram-problem.txt

andreiw commented 5 years ago

Fun.

esnowberg commented 5 years ago

There isn't any other media present. The only thing connected is the micro sd card and the serial cable.

The BOOTAA64.EFI program is really fbaa64.efi, so it creates the boot entries and then jumps to shim. This time once shim loaded GRUB2 Instead of booting into Linux, I rebooted from the GRUB2 shell. This brought me back to UEFI. I was then going to reset the system. But first I looked at the Boot Manager Menu and saw my variable set. Instead of resetting the system, I just booted into Linux. Now the two variables persist.

To reproduce the problem if I do: UEFI -> BOOTAA64.EFI (which sets variables) -> shim -> GRUB2 -> Linux The variables created do not persist.

If I do: UEFI -> BOOTAA64.EFI (which sets variables) -> shim -> GRUB2 -> reboot The variables persist.

andreiw commented 5 years ago

Yeah I see now.

Okay, thanks for the report. I’ll share a test build with you soon (attached to this ticket)

A

On Jul 6, 2018, at 11:35 AM, Eric Snowberg notifications@github.com wrote:

There isn't any other media present. The only thing connected is the micro sd card and the serial cable.

The BOOTAA64.EFI program is really fbaa64.efi, so it creates the boot entries and then jumps to shim. This time once shim loaded GRUB2 Instead of booting into Linux, I rebooted from the GRUB2 shell. This brought me back to UEFI. I was then going to reset the system. But first I looked at the Boot Manager Menu and saw my variable set. Instead of resetting the system, I just booted into Linux. Now the two variables persist.

To reproduce the problem if I do: UEFI -> BOOTAA64.EFI (which sets variables) -> shim -> GRUB2 -> Linux The variables created do not persist.

If I do: UEFI -> BOOTAA64.EFI (which sets variables) -> shim -> GRUB2 -> reboot The variables persist.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

andreiw commented 5 years ago

Soon. Sorry, a little overwhelmed right now with other stuff.