Boot iPXE from a closed-source bootloader that only allows bzImages

[cocus]

Hi,
I'm working on giving life to a device that uses the dreaded Intel Puma 6 SoC. The bootloader is really bad (CEFDK), but thankfully it allows to boot from bzImages in RAM (either downloaded by ymodem, or from eMMC's partitions). It has tftp support, but the network doesn't seem to work.
As you can see, uploading a kernel (~3MB) through ymodem at 115200bps takes a lot of time; specially if I'm trying to get a newer kernel running there and testing it constantly.
I was wondering if iPXE can be made to produce a bzImage (which I hope will be less than the 3MBs of the kernel's bzImage), to then use tftp or even USB to load my kernel. There are some changes that need to be applied on the x86 code to get the intel puma 6 network working, but I hope that'll be easier and quicker than doing it on the linux kernel.

I'm doing this for fun, to repurpose an old cablemodem. If you have any idea, please let me know. I've also search for "homebrew" hello world bzImages but I could only find kernels, not a simple "hello world" in assembly or C that produces a bzImage.

Thanks!

[NiKiZe]

https://ipxe.org/appnote/buildtargets

The ipxe.lkrn is a "linux kernel" to most boot loaders, but not all.
iPXE can be made to work with i386 (you might be best of trying an older commit of the code if it is that old)

[cocus]

Excellent, that's really good. Now, I'm facing this issue, which it might be beyond my knowledge. This target doesn't have a VGA card, it's all manipulated through serial (in fact, the baudrate divider is different than on a PC, but everything else should be the same).
When loading it, I placed it at 0x200000 and got:

shell> bootkernel -b 0x200000 ""
CMD(0x48000)=''
iiPPXXEE  iinniittiiaalliissiinngg  ddeevviicceess......
Unhandled real mode interrupt!
Vector: 0x1A
CS:IP = 9c20:0159
SS:ESP = 9cb0:000030ce
EAX = 0000564e  EBX = 00000860  ECX = f8e17a8c  EDX = 9c20019d
ESI = 000d2bec  EDI = 00040523  EBP = 00000000  FLG = 00000002
DS  = 9cb0      ES =  9c20      FS  = 9cb0      GS  = 9cb0
Stack:
   0009fbce: 000007cc 00000000 00000000 00000000
   0009fbde: 00000000 00000000 00000000 00000000
   0009fbee: 00000000 00000000 00000000 00000000
   0009fbfe: 53520000 54502044 49132052 4c45544e

It's interesting because the CEFDK doesn't run in realmode (as far as I understand), maybe it switches back to real mode to run the bzImage code?

[mcb30]

Excellent, that's really good. Now, I'm facing this issue, which it might be beyond my knowledge. This target doesn't have a VGA card, it's all manipulated through serial (in fact, the baudrate divider is different than on a PC, but everything else should be the same). When loading it, I placed it at 0x200000 and got:

shell> bootkernel -b 0x200000 ""

Not sure what role the 0x200000 address is playing. There are fixed load addresses for the bzImage format, and the fact that you are seeing any output at all from iPXE indicates that the bzImage must have been loaded to its expected addresses (not 0x200000).

iiPPXXEE  iinniittiiaalliissiinngg  ddeevviicceess......

This kind of duplicated output usually indicates that you have both BIOS serial console redirection and iPXE's CONSOLE_SERIAL enabled at the same time. Since your device has no display and relies on the BIOS serial console output working, you may as well disable iPXE's CONSOLE_SERIAL.

Unhandled real mode interrupt!
Vector: 0x1A
CS:IP = 9c20:0159
SS:ESP = 9cb0:000030ce
EAX = 0000564e  EBX = 00000860  ECX = f8e17a8c  EDX = 9c20019d
ESI = 000d2bec  EDI = 00040523  EBP = 00000000  FLG = 00000002
DS  = 9cb0      ES =  9c20      FS  = 9cb0      GS  = 9cb0

This is INT 1a,564e, which is issued only by pxe_activate() in arch/x86/interface/pxe/pxe_call.c:

ipxe/src/arch/x86/interface/pxe/pxe_call.c

Lines 292 to 299 in 17882e7

	/* Notify BIOS of installation */
	__asm__ __volatile__ ( REAL_CODE ( "pushw %%cs\n\t"
	"popw %%es\n\t"
	"int $0x1a\n\t" )
	: "=a" ( discard_a ), "=b" ( discard_b ),
	"=d" ( discard_d )
	: "0" ( 0x564e ),
	"1" ( __from_text16 ( &pxenv ) ) );

This code is not needed at all in your setup: it exists only to support some OEM use cases involving docking stations and MAC address passthrough. Almost all BIOSes should just treat it as unimplemented and therefore return with the carry flag set, but it seems as though your BIOS decides instead to crash the system!

You can safely delete those lines of code (or put a return; on line 291).

It's interesting because the CEFDK doesn't run in realmode (as far as I understand), maybe it switches back to real mode to run the bzImage code?

It must be: iPXE relies on the real-mode code in the bzImage prefix executing correctly, and you're definitely getting further than that code.

[cocus]

Thanks for your answer! That actually made the process go further. I think I don't have CONSOLE_SERIAL enabled, and I made sure to add a simple #error guarded by a #if defined(CONSOLE_SERIAL), and didn't get an error. I'm still seeing double characters on every single printed character.
In any case, it got a little bit further, but failed to process a command. This caused the iPXE to "leave", which requests the int 0x18, which is also unhandled on this environment.

iiPPXXEE  iinniittiiaalliissiinngg  ddeevviicceess......ookk



iiPPXXEE  11..2211..11++  ((gg1177888822ee77))  ----  OOppeenn  SSoouurrccee  NNeettwwoorrkk  BBoooott  FFiirrmmwwaarreg
FFeeaattuurreess::  DDNNSS  HHTTTTPP  iiSSCCSSII  TTFFTTPP  SSRRPP  VVLLAANN  AAooEE  EELLFF  MMBBOOOOTT  PPXXEE  bbzzIT
::  ccoommmmaanndd  nnoott  ffoouunndd

Unhandled real mode interrupt!
Vector: 0x18
CS:IP = 9c20:0130
SS:ESP = 9cb0:000030d0
EAX = 00009c20  EBX = 00009cb0  ECX = 00000000  EDX = 00007bf0
ESI = 00000000  EDI = 00000000  EBP = 00000000  FLG = 00000046
DS  = 9cb0      ES =  0000      FS  = 4000      GS  = 4000
Stack:
   0009fbd0: 00000000 00000000 00000000 00000000
   0009fbe0: 00000000 00000000 00000000 00000000
   0009fbf0: 00000000 00000000 00000000 00000000
   0009fc00: 20445352 20525450 544e4913 02204c45

Regarding the 0x200000 and the bootkernel command, I can only tell you that address is the memory address where the binary was placed when downloading it through ymodem. I expect CEFDK to move it wherever it needs to be. CEFDK is closed source, and some leaks exist, but haven't read them yet.

[cocus]

Well, some updates. I've disabled the CONSOLE_PCBIOS and kept the CONSOLE_SERIAL. Since this SoC's maximum baudrate for the UART isn't 115200 but rather 921600, I modified the UART_MAX_BAUD. Not only that, but I also added a "reboot" on the main function instead of just returning.
The bootkernel command from the bootloader not only starts the bzImage but also sets the cmdline, and that surely works (because it works with my test kernels). However, iPXE knows there's a cmdline set, but it's "null".
Regardless, the system was being rebooted because first_image() was returning something, thus not letting me enter the shell. I don't know if this is okay or not. In any case, here's the output. I haven't figured out if this actually works or not.
There are some changes from Intel about the embedded e1000 and the phys, will have a look at them to port them.

iPXE initialising devices... ok



iPXE 1.21.1+ (g17882e7) -- Open Source Network Boot Firmware -- https://ipxe.org
Features: DNS HTTP iSCSI TFTP SRP VLAN AoE ELF MBOOT PXE bzImage Menu PXEXT

net0: 00:50:f1:64:cb:63 using cemedia on 0000:01:0c.0 (Ethernet) [open]
  [Link:up, TX:0 TXE:0 RX:0 RXE:0]
Configuring (net0 00:50:f1:64:cb:63)................. No configuration methods succeeded (https://ipxe.org/040ee119)
No more network devices

iPXE>

In any case, how can I know if any USB storage devices are being recognized by iPXE? I'd rather copy the kernel I'm working on to a usb stick and let iPXE boot from there.

Thanks!

[NiKiZe]

There is no filesystem support in iPXE, you can enable USB, but that won't do you any good in terms of booting from usb flash.

I would run ifstat in your current shell and check for TXE RX and RXE values.
From your output It does use a cemedia nic https://github.com/ipxe/ipxe/blob/master/src/drivers/net/intel.c#L1195

When you have network, use http to fetch your kernel and any other files.

[cocus]

Well, I'm trying to figure out what to change from the intel driver vs what the e1000 changes were applied to an old kernel to support the cemedia board (liwei/asustor-linux-3.4.26@d1f6dac#diff-ea329a9ee0c1ce19ff20fbe3a8e8715de6c713d902fe982fd2529d24562e421e). I have verified that the iPXE can send DHCP requests fine, but it doesn't receieve anything in return (validated with wireshark and the syslog of the router). This "cemedia" interface is connected DIRECTLY to a switch that has been pre-configured by the CEFDK bootloader (I think it's all in bridge mode, no vlans involved).
In any case, I tried again with vlan 100 and some other numbers, and it doesn't receieve anything. In fact, the ifstat show 0 on RX and RXE (but some positive numbers on TX).

iPXE> ifstat
net0: 00:50:f1:64:cb:63 using cemedia on 0000:01:0c.0 (Ethernet) [open]
  [Link:up, TX:26 TXE:0 RX:0 RXE:0]

Also in my openwrt router:

Sat Mar 16 13:57:47 2024 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(switch.1) 00:50:f1:64:cb:63
Sat Mar 16 13:57:47 2024 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(switch.1) 192.168.1.55 00:50:f1:64:cb:63

I was able to read some other info from the e1000 from within iPXE that validates what I was seeing on linux, so I assume the PCI and IRQs are "fine"

[mcb30]

Well, some updates. I've disabled the CONSOLE_PCBIOS and kept the CONSOLE_SERIAL. Since this SoC's maximum baudrate for the UART isn't 115200 but rather 921600, I modified the UART_MAX_BAUD. Not only that, but I also added a "reboot" on the main function instead of just returning. The bootkernel command from the bootloader not only starts the bzImage but also sets the cmdline, and that surely works (because it works with my test kernels). However, iPXE knows there's a cmdline set, but it's "null". Regardless, the system was being rebooted because first_image() was returning something, thus not letting me enter the shell. I don't know if this is okay or not.

The .lkrn command line is handled by being treated as though it were an embedded image, which would explain why first_image() is returning something. I'm not sure how you're ending up with an empty command line image, though: there is logic in cmdline_init() to strip out whitespace and then register the image only if non-empty. You could try building with DEBUG=runtime to see what iPXE thinks it is being given.

I was able to read some other info from the e1000 from within iPXE that validates what I was seeing on linux, so I assume the PCI and IRQs are "fine"

Yes, the fact that iPXE has recognised the NIC and is able to transmit packets shows that PCI enumeration has succeeded, and the NIC is responding to register writes and successfully performing DMA in both directions.