Closed monperrus closed 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
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?
Works for me. Did you forget to type boot
after the chainloader
command?
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?
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.
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?
Oh, you're on the TP370QL. I have only tested Shell.efi
on the Lenovo Yoga C630.
Maybe @jhugo has an idea.
Note: Removing Windows from your machine was probably a really bad idea.
Removing Windows from your machine was probably a really bad idea.
I was not aware of this :-) See #31
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
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.
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.
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)
?
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.
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?
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.
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?