archdetect guessing on arm* != armel
Hi,
In 2010[0,1] support was added to archdetect for guessing the subarch on
armel platforms by looking at the running kernel versions suffix, this
was useful because some armel kernel flavours supported multiple boards
and it meant that support for such platforms could come essentially for
free without having to edit the installer initrd. This is implemented by
di_system_subarch_analyze_guess() in libdebianinstaller and exposed via
"archdetect -g".
However I can't actually find anywhere which uses archdetect -g though,
even for armel, was it never implemented or was it removed? (I couldn't
find it in a grep through the "git log -p" of some plausible repos)
Anyway, armel is what it is but this functionality has now also been
extended to armhf and more recently arm64. I'm not sure this makes sense
going forward -- the upstream kernel folks have been moving towards a
single image "multiplatform" model (i.e. one kernel binary on all new
platforms, driven by Device Tree) and in Debian we have been following
suite in the armhf flavour where we have consolidated into just two
flavours (armmp and armmp-lpae/bigmem). For ARM64 the situation is even
more clear cut, there upstream has been multiplatform from day one and
there will never be multiple platforms.
For armhf and arm64 I think we should be moving away from a model which
requires us to whitelist supported subarchs in the installer towards one
which takes advantage of the upstream progress to work on most
platforms. I've been experimenting with having archdetect return
"armhf/generic" and handling that in kernel.sh, which seems to work
fine.
On the bootloader side we discussed at the ARM sprint in Cambridge
(notes at [2]) chainloading grub-uboot on armhf. On arm64 I expect the
choice will be grub-efi. Both should reduce or eliminate the need for
subarch specific code.
So, I think di_system_subarch_analyze_guess should be disabled for armhf
and arm64, and that map_hardware should not have any new armhf platforms
added to it (or any arm64 ones added at all).
But, I can't quite work out how this infrastructure actually worked in
practice, because I can't see the consumers anywhere. That makes me wary
since I think I might be missing something and I don't want to pull the
rug out on something which is useful.
The only places where I foresee there might be any need for subarch
specific stuff on armhf are:
* grub-installer or flash-kernel: Something needs to arrange to
chainload grub. A default of writing /boot/boot.scr (using
${kernel_addr_r}?) will help keep this to a minimum I think
* grub-installer: On armhf needs to be able to select a load
address for grub (How? TBD, but could look
into /proc/device-tree/memory* or /sys files perhaps, or even
better maybe the upstream discussion[3] will result in a runtime
relocatable grub and eliminate this too)
In all cases this should in any case be based on /proc/device-tree/model
(which is guaranteed to be present for armhf now that we use armmp).
With EFI on arm64 there should be no need for subarch specific code.
WRT the existing guessing on armel, does it actually work usefully? the
list of kernel version suffixes which we match today in order to make a
subarch guess (as opposed to an exact match) from is:
dove
omap (armhf kernel flavour until Wheezy)
omap4
mx51
mx5 (armhf kernel flavour until Wheezy, supported by
flash-kernel, supported by base-installer
kernel.sh)
vexpress (armhf kernel flavour until Wheezy, supported by
base-installer kernel.sh)
AFAICT none of dove, omap4 or mx51 have ever been Debian kernel flavours
or supported by flash-kernel AFAICT. Perhaps they were Ubuntu kernel
flavours? Or old armeb flavours? Only mx5 and vexpress are understood by
the base-installer's kernel selection stuff.
Given that I'm wondering if it might be easiest to just nuke all of this
stuff across the board even for armel.
I've pushed my WIP to the devel/armhf-armmp branches
libdebian-installer.git and base-installer.git under
https://gitorious.org/ijc-debian .
Ian.
[0] https://lists.debian.org/debian-boot/2010/08/msg00641.html
[1] https://lists.debian.org/debian-boot/2010/09/msg00118.html
[2] https://lists.debian.org/debian-devel-announce/2013/12/msg00001.html
[3] http://lists.gnu.org/archive/html/grub-devel/2013-12/msg00415.html
Reply to: