Bug#695241: linux: Add basic arm64 support
On Mon, 2013-10-14 at 03:38 +0100, Wookey wrote:
> +++ Ben Hutchings [2013-10-13 19:20 +0100]:
> > > diff -urN origs/linux-3.10.11/debian/changelog build/linux-3.10.11/debian/changelog
> > > --- origs/linux-3.10.11/debian/changelog 2013-09-10 14:13:17.000000000 +0100
> > > +++ build/linux-3.10.11/debian/changelog 2013-10-11 04:05:57.380980848 +0100
> > > @@ -1,3 +1,9 @@
> > > +linux (3.10.11-1~arm64) UNRELEASED; urgency=low
> > > +
> > > + * Add arm64 packaging
> > > +
> > > + -- <wookey@debian.org> Sat, 05 Oct 2013 02:24:25 +0100
> > > +
> > > linux (3.10.11-1) unstable; urgency=low
> > >
> > > * New upstream stable update:
> >
> > This should be targetted at 3.11 (trunk in svn).
>
> Hmm. I was working off latest released package in unstable as that's
> the one I get to dowload and build. What do I need to do to 'target
> trunk in svn'? (e.g. where is it?)
https://wiki.debian.org/DebianKernel has some details but I use:
svn+ssh://ijc-guest@svn.debian.org/svn/kernel
subst your own username and add /trunk suffix I think
> > > diff -urN origs/linux-3.10.11/debian/config/arm64/config build/linux-3.10.11/debian/config/arm64/config
> > > --- origs/linux-3.10.11/debian/config/arm64/config 1970-01-01 01:00:00.000000000 +0100
> > > +++ build/linux-3.10.11/debian/config/arm64/config 2013-10-09 16:56:22.585330811 +0100
> > > @@ -0,0 +1,35 @@
> > > +##
> > > +## File arch/arm64/Kconfig
> > > +##
> > > +CONFIG_ARCH_VEXPRESS=y
> > > +CONFIG_CMDLINE="console=ttyAMA0"
> >
> > I don't think it is appropriate to include a command line in a Debian
> > kernel configuration.
>
> We need to specify the default console somehow - is there a better
> way? I just copied that out of existing arm64 kernel configs. Maybe
> it's set in the kernel itself; and this line is not needed?
It is the bootloader's responsibility to populate /chosen/bootargs in
the DTB with the command line. u-boot does this using the content of its
$bootargs env variable for example. If running on models then I think
boot-wrapper-aarch64.git has some runes to insert the necessary bits
into the dtb at compile time.
> > > +##
> > > +## File drivers/block/Kconfig
> > > +##
> > > +CONFIG_BLK_DEV_RAM=y
> >
> > Why?
>
> It was in all the existing arm64 configs, and people I asked said it
> was a good idea. I don't actually have a concrete reason. I believe
> it's needed for initrds, but maybe I'm wrong about that?
This might only be needed for old style initrd rather than modern
initramfs. (Warning: might be talking out my behind here...)
> > > diff -urN origs/linux-3.10.11/debian/config/arm64/config.vexpress build/linux-3.10.11/debian/config/arm64/config.vexpress
> > > --- origs/linux-3.10.11/debian/config/arm64/config.vexpress 1970-01-01 01:00:00.000000000 +0100
> > > +++ build/linux-3.10.11/debian/config/arm64/config.vexpress 2013-10-08 03:12:22.195734618 +0100
> > > @@ -0,0 +1,3 @@
> > > +#
> > > +# All arm64 flavours are intended to use the same kernel config.
> > > +# So nothing in here yet
> > [...]
> >
> > Then why is the flavour called 'vexpress'? I would suggest just 'arm64'.
>
> Everyone calls it that, because that's what the model emulates, and
> that's the only 'hardware' available. But yes, from debian's POV maybe
> 'arm64' is better. Does there have to be a 'flavour' name as well as
> an arch name? Could be arm64mp in line with 32-bit arm? or just
> 'generic'? Having 'arm64' for both arch and flavour seems a bit clumsy.
>
> Does a config/arm64/config.arm64 file do anything if we already have
> config/arm64/config? Or should it just be deleted? None of the other
> arches give an example of a null $flavour. Or do we need to keep it
> arch=arm64, flavour=arm64 so the machinery works?
I think you get config/arm64/config for free and anything else only
takes affect if you name it in in debian/config/arm64/defines in the
configs key for the flavour.
> We will need a per-flavour DTB I guess.
You need a per-hardware platform DTB. arch/arm64/boot/dts is beginning a
collection. On arm we package these into /usr/lib/linux$something and
various bootloader support knows to copy the right one out. You probably
want the same for arm64.
Eventually the hope is that these things will come from the hardware
vendors in the firmware...
Ian.
Reply to: