Bug#667681: flash-kernel: Please add support for Dreamplug / Marvell Kirkwood FDT

[Loïc Minier <lool@dooz.org>]

        Hey

 (Just noticed this bug; thanks for the heads up Hector)

On Mon, Apr 09, 2012, Martin Michlmayr wrote:
> * Ian Campbell <ijc@hellion.org.uk> [2012-04-06 09:49]:
> > Good question. Some DT stuff gets exported in /proc/device-tree.
> > $ echo $(cat /proc/device-tree/model)
> > Globalscale Technologies Dreamplug

 But that doesn't say whether the DT was passed to the kernel or whether
 it was appended to the kernel image?  It's good that we can identify
 the actual board though.

> In that case, I believe you should modify your flash-kernel patch to
> check this file so the code your proposed will only run on the
> Dreamplug and not on other Kirkwood DT devices which might require
> different behaviour.

 Right; IIUC we want to do these things:
 a) if /proc/device-tree/model exist, read machine from it rather than
    using Machine: in cpuinfo
 b) add support for either appending the DT to the kernel image, or for
    installing the DT (e.g. writing to flash or copying it to a specific
    SD partition etc.)

 b) depends on the way the boards we care about boot; for instance if
 Debian provides SD card d-i images which contain u-boot with a certain
 behavior, this is typically the behavior we would rely on; however it
 might be important to align this with what u-boot does in devices
 coming out of the factory.

 I don't like requiring people to replace their bootloader if it's not
 on user-swappable media.  If it's on user-swappable media, I prefer if
 it's included from the start in Debian images and updated regularly
 (with each u-boot package upgrade).  But none of that exists sadly.

 Concerning appending the DT vs. copying it, it would be ideal if we
 could do the same thing for all boards; I guess appending the DT is
 universal and would work all the time, but it does require turning on a
 specific option in the kernel config.  At the very least, we should
 attempt to check that the relevant config is turned on and break if we
 notice it's not.

 Another final question is where the DT comes from; I expect it's ship
 pre-built in the linux-image package, just like vmlinuz, but per board.
 In Ubuntu, these are shipped as e.g.:
    /boot/dt-2.6.38-1002-linaro-omap/omap3-overo.dtb
 we need to be really careful that these are stable names (e.g. if linux
 upstream splits dreamplug.dtb into dreamplug-v1.dtb and
 dreamplug-v2.dtb, it will break flash-kernel).

 (There's another question in the back of my mind with DT: I think we
 can set things like cmdline args via DT; we could use that to set
 root= instead of using the initrd, but that's not supported in Debian
 right now and it's not obvious to me that we can post-process .dtb
 files easily to do this at the right time.)


 Next steps:
 * could we assume Debian-ish kernels for your plaform will provide the
   .dtb in a reliable location and use that as the .dtb file to install?
   what's the name of the .dtb file and is this available in Debian
   .debs?
 * could we assume Debian-ish kernels for your plaform turn on DTB
   append in the config?
 * I see your patch adds an entry which requests generation of
   uImage/uInitrd, but the default upstream u-boot config doesn't
   include loading an initrd or a DT; what can we assume out of factory?
 * can we ship u-boot in Debian images so that we can assume which
   features/config u-boot has?
 * you request installation of uImage/uInitrd into /boot; that's what
   other similar platforms do, but my preference would be to use a
   partition device name instead (Boot-Device:) just like for
   "OMAP4 Panda board"; I find this is a bit nicer for multiple reasons:
   + it allows /boot to be on any device to store possibly large and
     numerous vmlinuz files
   + it doesn't require support for e.g. symlinks in the filesystem used
     for firmware files such as uImage/uInitrd (if it's mounted as /boot
     and you request /boot/initrd.img and /boot/vmlinuz symlinks on a
     filesystem which doesn't support symlinks, things break)
   + this doesn't keep the filesystem mounted all the time
   - there is a drawback that fsck might not be run automatically for
     that filesystem, but since it's shared with the bootloader it's
     probably a good idea
   so I'd prefer if you could use Boot-Device: whatever,
   Boot-Kernel-Path: uImage and Boot-Initrd-Path: uInitrd

 Hope this helps,

    Cheers,
-- 
Loïc Minier