we are supporting several platforms and have a well established format and set of tools for upgrading our images and rolling back to prior images upon upgrade failure.
that said we'd like to use the same layout for our boot file system and not mtd partitions for kernel, rootfs etc. to boot we read the kernel and a squashfs rootfs and boot them. we'd like to have u-boot do the same. on intel of course our bootfs is a fat file system, on our arm platform we have a spi-(nor)-flash which holds the persistent memory so we'll have to put the boot fs there. like this: device nor0 <is25lp512-flash.0>, # parts = 6 #: name size offset mask_flags 0: SPL 0x00020000 0x00000000 0 1: u-boot 0x00080000 0x00020000 0 2: fdt 0x00020000 0x000a0000 0 3: u-boot-env1 0x00020000 0x000c0000 0 4: u-boot-env2 0x00020000 0x000e0000 0 5: bootfs 0x03f00000 0x00100000 0 we were thinking that jffs2 would be best for the bootfs since we gain the wear leveling. There are really only a few files in the bootfs and not much r/w activity except on upgrades of images and boot, so I don't think we'll have a problem mount time or gc, I looked briefly at ubifs but it seems that uses abotu 10% more space and we are really looking to be close on space so I am avoiding this. of course we could stick w/ fat, but of course that does not give us the wear leveling. My questions: 1) does u-boot support the use of jffs2 on spi-nor-flash? seems like I get the error: get_fl_mem: unknown device type, using raw offset! when I try to read the fsinfo or fsls. if I just remove that error allowing get_fl_mem() to return the offset, then I get all 0 and I don't think its reading the correct data. should I have CONFIG_CMD_FLASH turned on? was thinking that that was for "nor" flash that is direct mapped. rather than spi 2) Is jffs2 still supported or should I be using ubi? or maybe just use the fatfs... if I am largely filling up the flash with my bootfs, then does it really mater if I'm wear leveling? will I run into fragmentation problems w/ fat? _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
