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

Frank Svendsbøe frank.svendsboe at gmail.com
Fri Jun 24 15:59:24 CEST 2011


>> Ok. So you recommend I stop "hacking" the CFI probing and instead
>> write a custom flash map driver?
>
> No.  Never write new drivers when you can use existing ones :-)
>
> Describe the flash memory as "mtd-ram" (instead of "cfi-flash") in
> the device tree and select the physmap driver in your kernel config.
>

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?

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?

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..
But isn't that harder than write a custom map driver?

Best regards,
Frank


More information about the U-Boot mailing list