On 07/13/2017 01:35 AM, Michael Brown wrote: > On 12/07/17 19:50, Heinrich Schuchardt wrote: >> On 07/12/2017 08:35 PM, Michael Brown wrote: >>> On 12/07/17 19:15, Heinrich Schuchardt wrote: >>>> Nope. Interrupts are not supported by U-Boot. To get them running every >>>> architecture implementation would have to be changed. >>>> >>>> U-Boot simply uses a call inside the waiting loop to check if new data >>>> is available. >>>> >>>> E.g. in UEFI WaitForEvent it will check if new data becomes >>>> available on >>>> the serial console or on the network interface inside a loop. In >>>> CheckEvent it will do the same. If data becomes available it will fire >>>> the UEFI event. >>> >>> OK. What facility does U-Boot provide to allow the CPU to sleep (i.e. >>> to allow an idling program to avoid running with 100% CPU usage)? >> >> None. U-Boot loads grub or the OS kernel within a few seconds. So why >> bother about reducing CPU load of the only core that is running? >> >> E.g. on the Davinci boards the waiting routine udelay is implemented >> using >> >> while (get_ticks() < endtime) >> ; > > iPXE similarly doesn't bother about reducing CPU load while downloading > the OS since it will generally be finished in under a second, but we do > sleep the CPU when we have nothing to do for long periods of time (e.g. > when waiting for user input, or in the middle of an explicit "sleep" > command). > > You could add code in efiarm_nap.c and/or efix86_nap.c to detect whether > or not it is safe to sleep the CPU. The attached (completely untested) > patch demonstrates this idea: modify the cpu_nap() implementation in > efix86_nap.c to execute "hlt" only if the platform firmware has enabled > interrupts. > > Michael
Why do we need cpu_nap in the keyboard loop at all when we are in an UEFI context. Shouldn't UEFI WaitForEvent be used to care about the idle CPU? Best regards Heinrich _______________________________________________ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel