Re: archdetect guessing on arm* != armel
On Thu, Jan 02, 2014 at 10:52:38PM +0000, Ian Campbell wrote:
> 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.
I agree with that - my reasoning for making the changes I did was to
be able to *blacklist* certain subarchitectures which need to behave
different than the default. For instance, knowing that a certain
subarch uses u-boot/flash-kernel vs. grub-efi... which will be the
case for at least one platform. Though perhaps subarch detection is an
incorrect mechanism for this and we should instead look for the
existance of efi interfaces?
-dann
> 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: