On Tue, Jun 14, 2011 at 8:21 AM, Patrick Doyle wrote: > OK, I've got 3 options here, and I really need to move on from this. > > 1) Enable CONFIG_MTD_PHYSMAP and live with the change in mtd blocks. > Change the linuxargs bootldr param to point to the new root partition > (in NAND) and get on with life. > > 2) Apply the ridiculous ugly, WRONG WAY TO DO THIS, patch (see > attached) which preserves the partition order by virtue of calling the > platform specific 'balloon3_nor_init()' procedure (defined in > arch/arm/pxa-270/balloon3.c) from the NAND driver code procedure > 'balloon3_nand_init()' (defined in drivers/mtd/nand/balloon3.c. > > 3) Arrange somehow for the NAND partition to be probed, recognized, > and loaded from within balloon3_init().  I'm having trouble figuring > out how to make this work.  Simply calling 'balloon3_nand_init()' (the > one defined in drivers/mtd/nand/balloon.c, not the confusingly > identically named one from within baloon3.c) doesn't work, probably > because other stuff has not yet been initialized. > Err.... this is somewhat embaressing... It turns out that the solution is really quite simple... just enable CONFIG_MTD_PHYSMAP as a loadable module rather than as a compiled-in module (which is what I started with). The NAND flash gets assigned to partitions mtd0 and mtd1 first; then, once the root fs is mounted (from mtd1), we can simply insmod the physmap.ko file to gain access to the NOR flash. In fact, through some magic I don't fully comprehend yet, the physmap.ko module gets automatically loaded anyway during the boot process. Attached is my patch that defines the partitions to match those defined in my bootldr. I am a little concerned that the partitions scheme in bootldr could change and my patch would know nothing about that, but I don't really know how to synchronize the two partition schemes otherwise. I've done my best to make this as safe as possible -- requiring CONFIG options to enable writes to the partitions, so hopefully this should be pretty benign. --wpd