On Tue, Sep 04, 2012 at 02:42:17PM -0500, Rob Herring wrote: > On 09/04/2012 01:34 PM, Robie Basak wrote: > > One additional point that's just come up - we'd also like to know the > > MAC address, which at the point of serving a default.<something> file we > > won't statelessly know if the TFTP server is not in the same ethernet > > segment. How about also hitting something like > > pxelinux.cfg/01-<mac>.arm-<somthing> before pxelinux.cfg/01-<mac> first, > > and then the default fallback behaviour later? This would make my life a > > bit easier by not having to save state in between calls to know the MAC > > address at the time of serving the default file. > > That's really a departure from standard PXELINUX and people have > complained already that u-boot PXE is not standard PXELINUX. :) How is > this specific to ARM?
If U-Boot PXE were identical to pxelinux, it would boot Intel architecture kernels and we wouldn't have a problem :-) Given that it must boot ARM kernels, I think it is reasonable to differ from pxelinux for architecture detection purposes, but still seek parity with pxelinux in all other respects where architecture differences do not prevent it from doing so. With pxelinux, a dynamic TFTP server can, on the first request of pxelinux.cfg/01-<mac>, assume that the machine is an Intel architecture and also know its MAC address, even if the booting machine is in a different ethernet segment. This is what MAAS is doing at the moment. For ARM support with U-Boot, I'd like to determine the architecture and know the machine's MAC address in that same query. If I do it with default.arm-<details>, then the dynamic TFTP server suddenly has to be stateful, store the MAC in a table against the IP address and returning a "404" first to then get architecture details on the default.arm-<details>, which is more difficult (eg. wrt. state cleanup) - but I admit that it is possible. So yes - it is a departure from pxelinux, but one that I think makes sense given that this is an alternative architecture. Do you think this is a step too far? Robie _______________________________________________ cross-distro mailing list [email protected] http://lists.linaro.org/mailman/listinfo/cross-distro
