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
>
_______________________________________________
cross-distro mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/cross-distro
