Hey
(Just noticed this bug; thanks for the heads up Hector)
On Mon, Apr 09, 2012, Martin Michlmayr wrote:
> * Ian Campbell <i...@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
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120411164624.ga2...@bee.dooz.org
