On Thu, Jun 23, 2011 at 5:21 PM, Wolfgang Denk <w...@denx.de> wrote: > 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"? >
Good question. When reading Intels CFI manual I was referring to something called "read array" which used bus write commands. I guess normal byte/word read access don't utilize this then. >> 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. > Right, and thanks for the explanation. What I've done to U-Boot is bypass the probing which uses the command mode and thus avoid getting problems with bus write accesses when flash protection is on. > 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. > Yes, well I tried to fool Linux's CFI driver too, but no luck so far. It was after this I started reading about CFI and came to the (wrong) conclusion that CFI uses bus write operations during read accesses too. >> 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. > Ok. So you recommend I stop "hacking" the CFI probing and instead write a custom flash map driver? Best regards, Frank _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
