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

[Frank Svendsbøe]

On Fri, Jun 24, 2011 at 10:26 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Frank,
>
> In message <BANLkTindk4f2An2VqhSftPcGuvsEqLY7wQ at 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 at 0,0 {
   compatible = "amd,s29gl512n", "cfi-flash",
   reg = <0x0 0x0 0x4000000>;
   partition at ...
}

... into something like this:

flash at 0,0 {
   compatible = "amd,s29gl512n", "cfi-flash",
   reg = <0x0, 0x0 0x2000000>;
   partition at ..
}

flash at 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 at 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