On 14/07/17 03:39, Heinrich Schuchardt wrote:
I assume that the equivalent is true on ARM, but you should check the
documentation to be sure.
And what do we do if some interrupts are implemented by a platform but
not the ones you are waiting for (console input and timer)?
We don't care about the console input interrupt, since console input is
not latency sensitive.
We already start a 32Hz timer via CreateEvent() and SetTimer(). The
timer interrupt must therefore be running, or the platform will not be
able to trigger our timer event. (In turn, this will prevent various
timeout mechanisms from working, such as TCP retransmission.)
According to
http://dox.ipxe.org/tables_8h_source.html
a solution matching your programming guidelines would be creating a
module for cpu_nap and deciding at link time if we want to use it.
You can already do that if you want. In config/nap.h, use e.g.
#undef NAP_EFIX86
#undef NAP_EFIARM
#define NAP_NULL
Needless to say, this is an incredibly ugly 'solution'. Users are
entitled to reasonably expect that they do not need to learn about this
kind of hackery; an ARM64 iPXE UEFI binary should ideally Just Work if
run on U-Boot without any compilation quirks.
U-Boot needs to provide a working timer via the SetTimer() API, since
this is required in order for TCP and other retransmission mechanisms.
This implies that U-Boot is already using a timer interrupt, in which
case your entire point is moot.
If you somehow have SetTimer() working without being interrupt driven,
then I am prepared to commit a patch to iPXE which avoids halting the
CPU if interrupts are disabled (at the CPU level). You then just need
to ensure that U-Boot explicitly disables interrupts at the CPU level
(rather than leaving them enabled but with no active interrupt sources).
Michael
_______________________________________________
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
