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 > > > + > > > + -- <[email protected]> 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://[email protected]/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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
