Bug 237808

Summary:	Ampere eMAG efibootmgr stuck when creating a new entry
Product:	Base System	Reporter:	Emmanuel Vadot <manu>
Component:	arm	Assignee:	freebsd-arm (Nobody) <freebsd-arm>
Status:	Closed Works As Intended
Severity:	Affects Some People	CC:	emaste, joneill, tphan, tuexen
Priority:	---
Version:	CURRENT
Hardware:	arm64
OS:	Any

Description Emmanuel Vadot freebsd_committer

2019-05-09 11:08:43 UTC

Ting Ngyuen and John O'Neill reported that the installer is stuck when it creates the boot entry with efibootmgr(8) on their Osprey hardware.
I managed to confirm this on the Lenovo HR350A at emaste@'s office.
Step to reproduce (runned from the pxe booted system) :
root@:~ # mount_msdosfs /dev/ada0p1 /mnt/
root@:~ # mkdir -p /mnt/EFI/freebsd
root@:~ # cp /boot/loader.efi /mnt/EFI/freebsd/
root@:~ # efibootmgr --create --activate --label FreeBSD --loader /mnt/EFI/freebsd/loader.efi 

Then efibootmgr is stuck and isn't interruptable.
I'll look at this.

Comment 1 Emmanuel Vadot freebsd_committer

2019-05-09 13:08:40 UTC

System hang when we call the runtime SetVariable, since it is a developement firmware and that getvariable/gettime works that could be it ...

Comment 2 Emmanuel Vadot freebsd_committer

2019-05-09 13:29:20 UTC

The bootservice setvariable works.
From a loader compiled with ENABLE_UPDATES defined:
OK efi-set 45cf35f6-0d6e-4d04-856a-0370a5b16f53 Blah Blih
OK efi-show
...
45cf35f6-0d6e-4d04-856a-0370a5b16f53 NV,BS,RS Blah = Blih
...

Comment 3 Tuan Phan 2019-05-25 05:23:42 UTC

I found a bug in our UEFI FW that not map memory correctly during SetVariable service. The interesting part is FreeBSD using 1:1 mapping for EFI Runtime memory which trigger the bug while other OSs not using 1:1 mapping.

So the latest FW for Packet should fix this issue.

Comment 4 Emmanuel Vadot freebsd_committer

2019-05-25 11:11:49 UTC

Great news Tuan,
Could you send me the fw so I can update the Lenovo unit at Ed's office ?

Comment 5 Tuan Phan 2019-05-26 19:36:58 UTC

(In reply to Emmanuel Vadot from comment #4)

I put the FW to https://1drv.ms/u/s!Ap60pRB5Jt2RiDRsRakEOxK_jB7T 

This is the developer build, thus it has no warranty or QS test cycle. Please make sure you can access BMC in case of something wrong.

To upgrade: 
- Copy the CapsuleApp.efi and *.cap to EFI partition
- Boot to EFI Shell.
- Enter command: CapsuleApp.efi hve104idev_107.cap
- Reboot.

Please let me know how it going with this FW.

Thanks,

Comment 6 Michael Tuexen freebsd_committer

2019-05-29 09:18:43 UTC

(In reply to Tuan Phan from comment #5)
Trying to do this:
tuexen@bsd6:~ % sudo mount -t msdosfs /dev/ada0p1 /mnt
tuexen@bsd6:~ % cd /mnt/
tuexen@bsd6:/mnt % ls
EFI
tuexen@bsd6:~ % cd
tuexen@bsd6:~ % ls -l
total 17164
-rw-r--r--   1 tuexen  tuexen    61440 May 26 21:19 CapsuleApp.efi
-rw-r--r--   1 tuexen  tuexen     3756 May 28 09:25 D20347.diff
-rw-r--r--   1 tuexen  tuexen     2096 May 28 09:25 D20348.diff
-rw-r--r--   1 tuexen  tuexen      896 May 28 09:25 D20349.diff
-rw-r--r--   1 tuexen  tuexen  8734720 May 29 10:42 TestUEFIFW.tar
drwxr-xr-x  25 tuexen  tuexen     1024 May 28 16:32 head
-rw-r--r--   1 tuexen  tuexen  8670936 May 26 21:20 hve104idev_107.cap
tuexen@bsd6:~ % sudo cp CapsuleApp.efi hve104idev_107.cap /mnt/
tuexen@bsd6:~ % cd /mnt/
tuexen@bsd6:/mnt % ls -l
total 8529
-rwxr-xr-x  1 root  wheel    61440 May 29 10:43 CapsuleApp.efi
drwxr-xr-x  1 root  wheel      512 May 28 08:24 EFI
-rwxr-xr-x  1 root  wheel  8670936 May 29 10:43 hve104idev_107.cap
tuexen@bsd6:~ % sudo umount /mnt
tuexen@bsd6:~ % shutdown -r now

After booting to the EFI Shell I get:

Shell> CapsuleApp.efi hve104idev_107.cap
CapsuleApp: capsule image (hve104idev_107.cap) is not found.

What am I doing wrong?

Comment 7 Michael Tuexen freebsd_committer

2019-05-29 10:01:33 UTC

(In reply to Michael Tuexen from comment #6)
I was missing that I have to switch to the disk...

So doing
Shell> fs0:
fs0:\> CapsuleApp.efi hve104idev_107.cap
works.

Sorry for the noise.

Comment 8 Emmanuel Vadot freebsd_committer

2019-05-29 15:50:37 UTC

I confirm that 1.07 solve the efi_set_var problem.
Thanks Tuan.
I close this bug since it's not a FreeBSD issue.