On Fri, Jun 24, 2011 at 10:26 PM, Wolfgang Denk wd@denx.de wrote:
Dear Frank,
In message BANLkTindk4f2An2VqhSftPcGuvsEqLY7wQ@mail.gmail.com you wrote:
Difficult to speculate - I don't know your hardware (eventually you have two 16 bit flash chips in parallel to build a 32 bit bus, and have to double the chip's erase block size?), and I don;t know how you created the JFFS2 file system.
...
factory default version). 16 bits databus and each sector is 64k words, ie. 128k bytes. I created the jffs2 images using ELDKs mkfs.jffs2. Thanks for providing me this tool :)
You need to provide the correct parameters to mkfs.jffs2...
Of course, but I don't see how changing from CFI to raw memory accesses on target change the way the jffs2 image should be created. What didn't I understand?
I'm currently using: mkfs.jss2 -U -b -d /${input} -e 0x20000 -o ${output}
No, not sure. I've got two reasons for staying with JFFS2. 1) We normally don't write to flash except when upgrading, so flash performance/duration isn't very critical 2) I discovered UBIFS after I
Hm... JFFS2 is probaly not a good choice anyway. On NOR, where you don't have to deal with bad blocks, you might use ext2 or cramfs or ... - all of them are more efficient than JFFS2 then.
Oh. Thanks for letting me know. I knew cramfs would be more efficient, but surprised that ext2 would be too. Thought ext2 was "heavier".
had JFFS2 working and haven't seen the real need for it yet.
Mount time?
Maybe 1-2 seconds. Haven't measured it yet. Maybe boot-time could've been improved yes.
Did you mean I should adapt the general CFI driver to support our configuration, or... Based on what you say below I'm not sure what you actually mean.
You have two different use cases that require (if we don't want to use a proprietary driver) two different, mutually exclusive drivers. I would load the driver I need as module, and unload it if I need the other one. This is pretty simple in principle, but a bit ore of a challange in your case as you use this as a root file system (including to load the modules from).
When thinking a bit more about this, I realize we don't need to support writing to the current filesystem in use. I've partitioned our device into three region, where each "region" consists of four partitions (dtb, kernel, rootfs and "home"). When upgrading we write a complete "region image" into another flash region, which is not part of the region we're running. So maybe we could have both mtd-ram and cfi-flash running at the same time, since we don't actually need CFI for the flash we're currently booting from.
I currently use mtd-utils' flash_erase to erase, and 'dd if=/dev/mtdX' to write. The mtds is created based on info in the dts.. Regarding DTS: Is it possible to have different partitions within the same physical flash using different drivers? Like this:
flash@0,0 { compatible = "amd,s29gl512n", "cfi-flash", reg = <0x0 0x0 0x4000000>; partition@... }
... into something like this:
flash@0,0 { compatible = "amd,s29gl512n", "cfi-flash", reg = <0x0, 0x0 0x2000000>; partition@.. }
flash@0,2000000 { compatible = "amd,s29gl512n", "mtd-ram", reg = <0x2000000, 0x0, 0x2000000>; partition@ }
In other words, partition a flash to use different drivers when accessing different partitions? I think that could solve the problems.
Me too. Small chances. So we have two options I guess: 1) Ditch hardware write protection and use CFI as it is supposed to be used, or 2) write a custom out-of-tree driver. What would you go for?
If this is an option: 1)
Good to know your opinion on this.
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Do not simplify the design of a program if a way can be found to make it complex and wonderful.
Hehe. Who wrote that?
Best regards, Frank