Re: Debian 7.0 on Dreamplug basic installation and booting system external sd card

[Martin Michlmayr <tbm@cyrius.com>]

* Loïc Minier <loic.minier@dooz.org> [2013-11-09 22:10]:
> Well, you'd think this is what /boot is for, but if you add the
> constraint that the bootloader needs to be able to read /boot and that
> the bootloader only speaks vfat / ext2, you might face painful
> situations.

So here's how I see things.  In my opinion, there are two separate
classes of devices: off the shelve devices that are not easily
hackable (i.e. in this case, don't have a serial console by default
nor an easy way to recover via JTAG) and other devices that are
hackable.

The QNAP devices are examples of the first class.  While you can add a
serial console, it's not there by default and voids your warranty.
Furthermore, there's no easy way to recover the system if the
bootloader is broken.  Therefore, our policy is not to touch the boot
loader at all (neither the binary nor the configuration) and live with
what we have.  This leads to certain hacks in flash-kernel, such as
overriding the root device passed to the kernel from the u-boot
environment.

On the other hand, there are devices like the SheevaPlug, which are
made to be hackable.  You can easily recover if you flash a broken
u-boot.  Therefore, we require users to upgrade u-boot and set
specific environment variables.  Because the SheevaPlug is hackable, I
was never interested in supporting other plug devices (like the
PogoPlug), which are not.  The GuruPlug and DreamPlug are somewhat
inbetween since the JTAG module is external because my assumption is
that anyone who wants to install Debian will get the JTAG module.
Therefore, I think we can expect users to install a specific version
of u-boot and set the u-boot environment.

As such, I feel that we don't need hacks in flash-kernel that assume
that people are running an u-boot that only supports FAT.  We can
simply tell people to install a different version of u-boot.

Of course we can support devices that are restricted, e.g. need the
kernel in a specific location.  In that case, I don't mind
flash-kernel mounting /dev/sda1 and writing stuff there.  We can also
support devices that need the kernel on a specific partition.  In that
case, we can even include checks in d-i to ensure that /boot is on
that partition.

However, I don't think this is the right solution for the DreamPlug,
as I consider it a hackable device.

-- 
Martin Michlmayr
http://www.cyrius.com/