On 09/03/2012 04:44 AM, Robie Basak wrote:
Responding to both Rob's and Stephen's comments at once, since I think they're essentially the same issue.
On Fri, Aug 31, 2012 at 07:51:21PM -0500, Rob Herring wrote:
On 08/30/2012 01:42 AM, Robie Basak wrote:
<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.
So: default.arm-highbank default.arm-armadaxp default.arm-omap4
For the DHCP string, we're currently using armv7 as part of it. Is arm too generic? With "single" kernels, we will have armv4/5, armv6/7, armv7, armv7-pae and armv8 kernels. Or will subarch just become v4, v7, v8, etc.?
On Sat, Sep 01, 2012 at 07:12:19PM -0700, Stephen Warren wrote:
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)?
I think this is a bigger question than I first imagined. I don't really mind what the exact outcome is provided that we all agree.
I reached "arm" because I was thinking about the Debian architectures armel and armhf, but dropped off the el and hf as they {aren't relevant/are equivalent} at the bootloader stage. I think OS architecture definitions are relevant here because the OS kernels available will always belong to an OS-defined architecture.
I got to "highbank" because we need to distinguish the kernels and "highbank", "armadaxp" etc. are the existing Ubuntu kernel flavour names.
That's a very short sighted view. In 3.7, we will likely multi-platform kernels starting with Versatile Express, Highbank and mvebu (Armada XP). Perhaps OMAP will happen too. Assuming you wanted to support all these platforms from a single kernel build, how would you manage it?
Perhaps you always keep separate platforms and just symlink things back to a common kernel? You could also argue that the command line options will always be different, so we'll always need to have per platform directories.
We could make the directory list be an environment variable to iterate thru then it's not fixed in the bootloader. We'd still need to come up with defaults though.
Rob
I assumed that the ISA distinctions would be covered with just "arm" and "aarch64", with further distinctions within <subarch> since the SoC decides which ISA features are implemented and each one will need a different kernel anyway. So default.armv7.highbank would be a bit redundant because I would expect the "highbank" part of the name to change for a future v7-pae SoC, and again for a v8 SoC. In other words, "highbank" implies v8 (or does it not?) and thus also encoding this in <arch> would be redundant.
But whichever way we have it, the important thing for me is that I can distinguish between the current existing SoCs right now. I need to know that this is the way forward ASAP so that I can implement this inside MAAS. From my point of view the exact strings aren't hard to change before release provided that the general mechanism is agreed upon (and it sounds like it is).
So with that, may I step out of the loop and let Rob, Stephen and anyone else relevant decide what the exact names should look like? I'll happily accept whatever you come up with, provided it leads to a different default.<...> fallback per required kernel/initrd.
Thanks,
Robie