On 08/29/2012 11:42 PM, Robie Basak wrote:
Hi,
We (MAAS upstream) are having some issues figuring out how to effectively detect the architecture of a system booting using U-Boot pxelinux emulation in order to send back an appropriate kernel and initrd.
In short, we'd like a mechanism that is separate from the DHCP vendor option which I believe is the only way to differentiate at the moment.
I proposed an alternative mechanism in https://launchpad.net/bugs/1041092 (description copied below) and it was suggested to me that I could get feedback from this list.
...
pxelinux emulation on other architectures breaks this assumption. So I propose that all alternative architecture pxelinux emulators (eg. U-Boot) fall back to "default.<arch>-<subarch>" and then "default.<arch>" before further falling back to "default" as usual.
<arch> and <subarch> must be defined in a new pxelinux emulator namespace, and MAAS will consequently need to map this namespace to Ubuntu's architecture and kernel flavour names. But to start with, they'll probably match 1-1.
For the values of <arch> and <subarch>, does it make sense to use the U-Boot variables from boards.cfg, which are also exposed as #defines CONFIG_SYS_ARCH, CONFIG_SYS_CPU, & CONFIG_SYS_SOC, and also as shell environment variables arch, cpu, & soc (if CONFIG_ENV_VARS_UBOOT_CONFIG is defined)? I wonder if a 3-level fallback might not be useful (i.e. involving all of those variables)?