iPXE stucks once it tries to wait for user input when loaded by ARM64 U-Boot's bootefi #605
-
|
Recently one of our user had issue using iPXE with our ARM single board computer. In short iPXE stucks inside I'd like to see if there is anyone else uses iPXE on ARM platform, and if there exists some integration tests for iPXE that I can play with locally. By integration test I mean something like QEMU full ARM64 system emulation to load U-Boot/EDK2 and then load iPXE. Thanks. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 7 replies
-
|
I think there is other issues/discussions about input on ARM. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting, iPXE seems to work fine on Raspberry Pi's so there could be something different in the u-boot builds for each |
Beta Was this translation helpful? Give feedback.
-
|
The Raspberry Pi is supported directly by EDK2 and so the UEFI implementation does not involve U-Boot in any way. |
Beta Was this translation helpful? Give feedback.
-
|
Verified with our Radxa Zero 2 (based on Amlogic A311D). Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Confirmed that this issue also takes place on ARMv7 with U-Boot. Should we make NAP_NULL default on arm64 and arm32 builds? What if this also takes place on x86_64 U-Boot? I haven't been able to test that yet. |
Beta Was this translation helpful? Give feedback.
-
|
As stated above, it works as it should on all CPUs but is dependant on firmware implementation. As such it is not a solution to change the default based on CPU. |
Beta Was this translation helpful? Give feedback.
-
|
Found some old issue in iPXE, I'm not sure if this is relevant: |
Beta Was this translation helpful? Give feedback.
-
This is not relevant.
This was cleaned up and became the |
Beta Was this translation helpful? Give feedback.
I think there is other issues/discussions about input on ARM.
If I remember correctly this is due to lack of timing events from the EFI firmware.