On 07/14/2017 11:03 AM, Michael Brown wrote: > 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 >
Hello Michael, I guess the information concerning config/nap.h could be added to http://ipxe.org/buildcfg/. My understanding is that the local configuration should go into src/config/local/*.h. You might want to mention this on the same page. With the cpu_nap adjustment iPXE is now working fine for me when starting from U-Boot. I have tested * dhcp * sanhook iSCSI-target * chain http-target * kernel http-target * boot (after calling kernel) * exit * reboot Thanks for the great work. I used a lot of DEBUG options to analyze what was going wrong in U-Boot's UEFI implementation. I could not find a documentation page on this except for comments in the coding. Maybe you want to mention this module wise log level control on the http://ipxe.org/buildcfg/log_level page. DEBUG='efi_acpi,' \ DEBUG+='efi_autoboot,' \ DEBUG+='efi_block,' \ DEBUG+='efi_bofm,' \ DEBUG+='efi_debug,' \ DEBUG+='efi_download,' \ DEBUG+='efi_driver,' \ DEBUG+='efi_entropy,' \ DEBUG+='efi_fbcon,' \ DEBUG+='efi_file,' \ DEBUG+='efi_guid,' \ DEBUG+='efi_image,' \ DEBUG+='efi_init,' \ DEBUG+='efi_local,' \ DEBUG+='efi_pci,' \ DEBUG+='efi_pxe,' \ DEBUG+='efi_reboot,' \ DEBUG+='efi_smbios,' \ DEBUG+='efi_snp_hii,' \ DEBUG+='efi_snp,' \ DEBUG+='efi_strings,' \ DEBUG+='efi_time,' \ DEBUG+='efi_timer,' \ DEBUG+='efi_uaccess,' \ DEBUG+='efi_umalloc,' \ DEBUG+='efi_usb,' \ DEBUG+='efi_utils,' \ DEBUG+='efi_watchdog,' \ DEBUG+='efidrvprefix,' \ DEBUG+='efiprefix,' \ DEBUG+='iscsi,' \ DEBUG+='nii,' \ DEBUG+='open,' \ DEBUG+='scsi,' \ DEBUG+='snp,' \ DEBUG+='snpnet' \ make bin-arm64-efi/snp.efi -j6 EMBED=myscript.ipxe Best regards Heinrich _______________________________________________ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
