RPi architecture

[jake5253]

I believe you can change the ARCH that RPi reports while doing PXEBoot.

This value is stored in the /boot/bootcode.bin file. I accidentally found it while searching for a way to enable UART during early boot stages. I haven't tested it, but that's most certainly the value that would be sent to DHCP during a PXE Boot request scenario

Below, this sed command would change the string of DHCP Option #93 (client-arch) to indicate that it's an ARM32_EFI architecture. You may wish to use Arch:00011 for ARM64_EFI, or any integer greater than or equal to 12 to indicate a custom CSA. You would then be able to dhcp-match the client-arch (and remove the MAC address matching):

dnsmasq.conf

..... dhcp-match=set:arm32, option:client-arch, 10 dhcp-match=set:aarch64, option:client-arch, 11 dhcp-match=set:rpi2b, option:client-arch, 42

dhcp-boot=tag:arm32,ipxe/ipxe-arm32.efi dhcp-boot=tag:aarch64,ipxe/ipxe-aarch64.efi dhcp-boot=tag:rpi2b,ipxe/ipxe-rpi32.efi .....

sed -i -e 's/PXEClient:Arch:00000:UNDI:002001/PXEClient:Arch:00010:UNDI:002001/' /boot/bootcode.bin

You can get the latest compiled bootcode.bin from here To see what PXEClient ARCH is set: strings /boot/bootcode.bin | grep PXEClient

From the DNSMASQ man pages: under the reference: pxe-service= ..... CSA is client system type, only services of the correct type will appear in a menu. The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86, Intel_Lean_Client, IA32_EFI, x86-64_EFI, Xscale_EFI, BC_EFI, ARM32_EFI and ARM64_EFI; an integer may be used for other types.

[beta-tester]

thank you for your hint, but i am not sure what you mean exactly.

the ISO images are all made for x86/amd64 architecture clients.

or do you mean PXE-boot for a raspberry pi as client? i didn't follow that option for a very long time. i even don't know if my project is still able to serve that case.

as far as i know the RPi3 and RPi3B+ has no option to change its SD-card-less PXE-boot firmware. and as i remember from the past, its PXE-boot firmware were all sending a 0 (or 00000) as architecture code that is x86PC.

i don't know why a raspberry pi is identifying itself as x86PC arch during sd-card-less PXE-boot.

that's the reason why i have to use the VENDOR codes of the MAC addresses to figure out if the client is a Raspberry Pi and see if it is a RPi3 or RPi4. it is possible the RPi4 behaves different in the meantime and send its correct arch code to the PXE-server. and maybe there are other different vendor codes available for Raspberry Pi's i don't have in the dnsmasq config file.

unfortunately i can not test it, because my only RPi4 device i have is the PXE-server,

[jake5253]

or do you mean PXE-boot for a raspberry pi as client?

Yes.
If the Raspberry Pi IS the client, then it sends 0 as its architecture. The sed command I mentioned "should" (in theory) change that in the DHCP request the Pi is sending to the DHCP server.

As I understand, the RPi3 and variants, have bootcode.bin "baked in" (so can be booted with no SD), however, if an SD is inserted, and that SD contains the latest bootcode.bin (from above), then it would use the SD bootcode.bin instead of the built-in version. Altering the SD version of bootcode.bin should then allow RPi3 (and others) to send a correct architecture to the DHCP server, so that matching against the MAC address would no longer be required.

And i just realized, my original post is incorrect: I believe that sending the RPi an .efi file may be a problem, as it would be expecting the server to give it yet another bootcode.bin file, followed by a config.txt, which would then have the rpi fetch the efi file (or kernel) from the tftp server.

RPi 4 actually defines itself, correctly(!!), as architecture 11 -- ARM64_EFI. Sadly, my RPi4 died the other day, releasing its "magic smoke". It is survived by it's much older sibling, RPi2b v1.1. R.I.P.

[beta-tester]

ok, now i understand.

i only was thinking about sd-card-less pxe-booting and forgot the alternative with a sd-card inserted. in my opinion this is more a specific modification the "end-user" has to do (if wanted) than a general purpose modification.

the end-user can use this informaion of this issue in case there is a need.

RPi 4 actually defines itself, correctly(!!), as architecture 11 -- ARM64_EFI.

when that is the case, i have to think about the matching conditions for the ARM_RPI tag. i should remove the condition ARCH_0 for that.