On Fri, Nov 08, 2013, Stanley Pilton wrote: > For our dreamplugs, we want to have an identical bootloader > configuration on each device, and have the behaviour of the system > from the OS up defined by the content of the removable SD card, not > the internal card. In other words, we would like to be able to change > the SD cards over between two of the devices, and have the whole > system, including the kernel and initrd, come across. > > Having the kernel on internal storage and the rest of the system on > external storage does not allow us to do this.
That's fine; there are other similar cases where the most common default is SD/MMC, such as Beagle/Panda, despite some revisions having NAND. When I referred to flash being used for the kernel/initrd, it wasn't anything mandatory, just something commonly witnessed (I guess it is often why NAND was included in the device in the first place!). > > Which devices would this be particularly useful on right now and what > > formats do we want to support first and foremost? How do we detect the > > device U-Boot will look after? > > We are quite happy with constraints such as "it must be an ext2 > filesystem directly on a partition of the card", as long as this is > clearly documented. To be clear, the ext2 requirement typically comes down from U-Boot; ideally, we'd instead allow users to install their kernel / initrd anywhere and have a bootloader as clever as GRUB find them by scanning all block devices and figuring out complex RAID/LVM/filesystem setups, but we don't have this luxury on ARM. So the device manufacturer usually picks a bootloader (often U-Boot) and some supported filesystem (often vfat or ext2) and loads from that, then Debian tools like flash-kernel try to cope with whatever setup was chosen. > I think a key point is that the installer and any other software > managing the boot files should know where to write based on where > /boot is. In other words, I wouldn't expect the user to have to tell > the OS twice where the boot partition is - this is already configured > by the /boot mountpoint, isn't it? 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. For instance, you need to keep /boot mounted all the time as to allow upgrades of the linux-image-* packages which ship files under /boot, but if there's an unclean shutdown, your filesystem is unclean and your device might not come up. Using /boot to store boot related file, but then having flash-kernel mount some "firmware area", copy just the right boot files into it, then unmount said area has advantages. > Working out what /boot corresponds to in bootloader terms, and thus > configuring the bootloader correctly, then becomes the problem. But I > think the problem should be stated this way round. In simple cases it > should be easy. If it can't be deduced, this error needs to propogate > up to the user. Sure, we can put the burden on the bootloader, but we typically dont have much control over it and it's often limited. I'm all for using a bootloader as capable as GRUB on ARM, but I don't think this is possible yet? -- Loïc Minier -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131109211033.ga11...@bee.dooz.org
