On Fri, Jun 24, 2011 at 4:26 PM, Wolfgang Denk <w...@denx.de> wrote: > Dear =?ISO-8859-1?Q?Frank_Svendsb=F8e?=, > > In message <banlktimt0lyxr-b5par1oneaeowkcye...@mail.gmail.com> you wrote: >> >> Hi Wolfgang, I did as you recommended and replaced cfi-flash with >> mtd-ram in the device tree. I also defined CONFIG_MTD_PHYSMAP_OF, >> CONFIG_MTD_MTDRAM, CONFIG_MTDRAM_TOTAL_SIZE according to our >> specifications. The default erase-size was 128k, which is what we have >> too, so I didn't touch that. Now when I boot the kernel recognizes all >> the partitions I've defined in the dts. But, when mounting a >> jffs2-filesystem, it ends with a jffs2_scan_eraseblock(): Magic >> bitmask 0x1985 not found... >> >> Do you have any other tips? > > 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. >
Yes I know, and I don't expect you to find the answer based on so little data. FYI: We have two flash chips yes, but not to build a 32-bit bus, we have two for redundancy issues (one is storing a 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 :) > Are you sure you want to use JFFS2? UBIFS is considered to be a > better choice these days... > 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 had JFFS2 working and haven't seen the real need for it yet. >> When working with this, I realised that if I could get it to work we'd >> still might have a problem. You see, we need write access for one of >> the flashes when upgrading software. We can't treat this as a simple >> ROM. So do we need CFI working in order to set the device into >> write-mode, erase flash sectors, etc.? Or do mtd-ram handle flash >> write operations too? > > mtd-ram provides a pure memory interface, i. e. you cannot use this to > erase or program any blocks in a CFI flash device. To do so, you need > the CFI driver. > Right. mtd-ram is thus a dead-end solution for our purpose. We need to be able to write in some specific cases. >> In theory, I guess I could unmount the root fs, unload the mtd module, >> insert the cfi-flash module, mount the filesystem, then write, etc.. > > Yes, or you could start with the CFI driver in the first place. > That's what I did before you started interrupting me about mtd-ram... No, just kidding :-) 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. >> But isn't that harder than write a custom map driver? > > I consider your chances to get such a customdriver into mainline to be > epsilon. And you don't really want to use any out of tree drivers. > 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? I'll consider if and how to get things into mainline once we have things working as we want. If my port isn't accepted I will at least learn why. Maybe the next will :) Best regards, Frank _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
