Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
monperrus opened this issue Aug 28, 2019 · 16 comments
Closed

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

monperrus opened this issue Aug 28, 2019 · 16 comments

Comments

@monperrus
Copy link

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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

@monperrus
Copy link
Author

monperrus commented Aug 30, 2019 via email

@lag-linaro
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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

Maybe @jhugo has an idea.

@lag-linaro
Copy link
Collaborator

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

@monperrus
Copy link
Author

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

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

@lag-linaro
Copy link
Collaborator

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
Copy link

jhugo commented Sep 3, 2019

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Contributor

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
Copy link

jhugo commented Dec 13, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants