[U-Boot] Reg. CFI flash_init and hardware write protected devices

[Frank Svendsbøe]

On Fri, Jun 24, 2011 at 4:26 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear =?ISO-8859-1?Q?Frank_Svendsb=F8e?=,
>
> In message <BANLkTimt0LYXr-B5PAr1ONEaEoWKCyEHbw at 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