aarch64-laptops / build

Build an Linux OS based image
237 stars 55 forks source link

UEFI add entry in UEFI menu (efi=novamap) #25

Closed monperrus closed 5 years ago

monperrus commented 5 years ago

I want to add a UEFI entry on the native disk of a ASUS NovaGo TP370QL.

With kernel option efi=novamap, I can boot Ubuntu from USB but I cannot modify the UEFI table (cannot write into /sys/firmware/efi/efivars).

Without kernel option efi=novamap, I cannot boot Ubuntu from USB.

Any idea to solve this dilemna?

lag-linaro commented 5 years ago

If you want to play with UEFI, you should use the EFI Shell.

A copy can be downloaded from HERE.

The easiest way to boot into it is to use Grub's chainloader command.

# Add support for GPT & MSDOS partitions and EXT support
grub> insmod part_gpt
grub> insmod part_msdos
grub> insmod ext2

# Which disks are available
#  (if your USB drive has 1 partition, look for disks with 1 partition)
grub> ls

# Does this partition contain 'Shell.efi'?
grub> ls (hdX,gptX)

# If yes, set it as 'root'
grub> set root=(hdX,gptX)

# Chainload into 'Shell.efi'
grub> chainloader Shell.efi
monperrus commented 5 years ago

Thanks a lot, this opens up new perspectives.

This now ends with

/EndEntire
file path: /PCI(0,80)/USB(0,0)/USB(0,0)/HD(2,100800,hexa,2,2)/File()/File(Shell.efi)/EndEntire

(Note that I can see the file Shell.efi with ls in grub, I replaced my.dtb with the correct one, and UEFI SecureBoot is well disabled)

Why does Shell.efi refuse to start?

lag-linaro commented 5 years ago

Works for me. Did you forget to type boot after the chainloader command?

monperrus commented 5 years ago

I did boot.

I notice that Shell.efi is packaged as MSDOS and I was not able to run any UEFI MSDOS tools (tried with refind, etc).

Only "PE32+ executable (EFI application)" executables seem to boot.

Is that possible that the UEFI firmware only accepts PE32+ executable?

lag-linaro commented 5 years ago

The Shell.efi that I liked you to boots or me.

Are you saying that it's not working for you?

Have you updated Windows? There is a firmware update.

monperrus commented 5 years ago

Are you saying that it's not working for you?

Yes, Shell.efi from the repo does not work on my machine

Have you updated Windows?

No. I completely removed Windows from the machine

There is a firmware update.

I have "UEFI Version : Qualcomm Inc. NovaGo TP370QL.254, 04/24/2018", Code base: 1076. Is that the last version?

lag-linaro commented 5 years ago

Oh, you're on the TP370QL. I have only tested Shell.efi on the Lenovo Yoga C630.

Maybe @jhugo has an idea.

lag-linaro commented 5 years ago

Note: Removing Windows from your machine was probably a really bad idea.

monperrus commented 5 years ago

Removing Windows from your machine was probably a really bad idea.

I was not aware of this :-) See #31

lag-linaro commented 5 years ago

Removing Windows from your machine was probably a really bad idea.

I was not aware of this :-) See #31

I think the massive existing warning should be enough:

https://github.com/aarch64-laptops/build#warning---read-this-section-first

jhugo commented 5 years ago

Yeah, removing Windows was a really bad idea. The binary blobs for the GPU, WIFI, and several other things are stored there. You'll probably have to find someone else with the ASUS device to give you copies since they seem to be signed with the OEM's private key.

Does the ASUS have a USB boot option? I've booted a shell.efi (not sure if its exactly the same as Lag's) by dd'ing a ubuntu iso onto a USB stick, then replacing the bootaa64.efi with the shell.efi (and renaming it to bootaa64.efi), and then using the USB boot option on a Lenovo Miix 630.

The efivars are not accessible to Linux due to a FW implementation issue that is unlikely to ever be addressed.

monperrus commented 5 years ago

Does the ASUS have a USB boot option?

yes.

then replacing the bootaa64.efi with the shell.efi (and renaming it to bootaa64.efi)

I think I tried that, but I'll try again, thanks for the tip.

monperrus commented 5 years ago

replacing the bootaa64.efi with the shell.efi (and renaming it to bootaa64.efi)

I confirm that this does not work on "UEFI Version : Qualcomm Inc. NovaGo TP370QL.254, 04/24/2018", Code base: 1076.

The likely explanation is that shell.efi is not a PE32+ executable (EFI application) but a MSDOS.

Any idea on how to get shell.efi as PE32+ executable (EFI application)?

monperrus commented 5 years ago

Extracted the content of the original bootloader https://github.com/monperrus/Asus-NovaGo-TP370QL/

It contains many things incl. a shell, which means many things must be somehow hidden. The question is how to get the complete menu with all options.

shawnguo2 commented 3 years ago

The efivars are not accessible to Linux due to a FW implementation issue that is unlikely to ever be addressed.

Hi @jhugo, so considering UEFI variables can be updated with either Windows or UEFI Shell.efi, this FW implementation issue only impacts Linux? Could you share a bit more details about this issue?

jhugo commented 3 years ago

If I remember the details correctly, the EFI variables are stored on the main storage device in a special partition. Normally, to update the EFI variables, you call an EFI runtime service from the OS. This is documented in the UEFI spec. Of course, if you are within UEFI, you can edit the variables.

On these systems, the firmware does not expose the runtime service to the OS (which may be a spec violation). The rational seems to be that the FW and OS cannot share the UFS device. Since OS doesn't use many of the variables, those values are exposed via different ways.

Its news to me that Windows can access the variables and update them. Assuming that is true, then its possible that some custom code was added to modify the variables in an implementation specific manner. I don't know if the OS can directly access the partition with the variables, or needs to go through TZ.

Frankly, the community seems to be pretty hostile currently to anything that appears to be non-standard from Qualcomm, much less things that are actually non-standard so I'm guessing that if someone reverse engineers whatever Windows is doing, the Linux community will tell the person(s) proposing that solution for Linux to pound sand.