Dear Frank, In message <banlktinfma7fn-bd7z2-zyat+-ubwn7...@mail.gmail.com> you wrote: > > A few weeks ago, I applied this change and everything worked fine in > U-Boot. However, I didn't succeed doing the same hack in Linux. I've > done some hardcoding experiments in drivers/mtd/chips/cfi_probe.c, but > so far no success. After reading some CFI manuals, it seems CFI > will/should use bus write operations even during CFI read operations.
What exactly do you mean by "CFI read operations"? > Can you confirm this? Then my next question is how come U-Boot read > operations works by just hardcoding the flash geometry. It seems > U-Boot utilize just plain localbus accesses to read flash data, ie. > not the "CFI protocol". What did I miss here.. ? It seems you misunderstand the different modes. In command mode, you will use the specific command sequences defined in the CFI protocol to talk to the controller poart of the flash chip. In this mode, you can read for example query information, flash geometry data, status information, etc. Yes, any such command sequence includes write operations to the flash device, even when you actually want to read some specific data. In data mode, flash is working just as normal real-only memory. No specific protocol is used, you just use plain read accesses to read the user data programmed into the flash chip. Any kind of probing, auto-identification etc. of the flash chip will need to use CFI command sequences, and thus write access to the device. As long as you just want to read the data or execute code from the flash no write accesses are needed. > Now I'm considering two options: 1) Either write a custom flash map > driver, and access the flash the same way U-Boot does, or 2) try to > convince the FPGA designers that our way of forcing write protection > is not according the the CFI specifications, and should be done > otherwise. What do you think is the best solution? Linux can also read from ROM memory. You just have to make sure that you do not try to run the normal CFI flash drivers on your flash devices - these will not work, because they will try to probe the flash chips. > Is there anybody else out there supporting hardware write protection > on CFI devices? CFI flash chips with the level of write protection you implemented have to be dealt with in the same way as other ROM memory. Normal CFI driver are not appropriate here. 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: w...@denx.de And now remains That we find out the cause of this effect, Or rather say, the cause of this defect... -- Hamlet, Act II, Scene 2 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
