On Thursday 03 September 2009, Siddharth Choudhuri wrote: > > > Heh. My suggestion is to go the other way: just a single > > "bootloader" partition of eight blocks or so. Don't expose > > any of the substructure at all. > > > > Updating U-Boot from Linux seems kind of nice, but on the > > other hand why not just do it from U-Boot? > > If you have a device on field for which a u-boot upgrade is required, > doing it from Linux is easier. You could have a small app that can talk > over the network, fetch an updated u-boot and flash it.
Not with the standard in-kernel partition tables, which make the U-Boot and UBL areas read-only: can't write them from Linux. Plus there's also the annoying problem of needing to make sure the ECC bytes are laid out the way the RBL and/or UBL want them, vs the way Linux reads and writes them. > > Thing is, if details of that boot layout aren't exposed to > > Linux, they can be improved without impacting Linux. Like > > adding backups for UBL or ABL/U-Boot; or for the U-Boot > > environment, for that matter. > > > Makes sense. That "not needing to understand funky ECC/OOB layout rules" falls into the same category. :) > For our use case, having the u-boot partitions exposed to Linux has been > advantageous. However, if this is not the common case, then having a > single partition labeled has boot serves the purpose. > > -sid > > _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
