On Friday 27 July 2012 00:41:45 Wolfgang Denk wrote:
Marek Vasut wrote:
Check the following list, it's the list of drivers scattered (misplaced) across the tree. The list is not complete and might be inaccurate. But it should give a good impression of what I'm going to break soon:
board/bf533-ezkit/flash.c
- old versions of flash drivers that predate the cfi flash implementation, so they could be replaced by the CFI driver (if there was someone to test this)
yep. this driver is wicked old, and has since languished for a few reasons: - the people who wrote it originally were (are) not exactly great programmers. in fact, they were pretty terrible. - this particular board is one of the first Blackfins to see a real open source port, but the board itself isn't terribly developer friendly, so no one pays too much attention to it. - the flash does not support the CFI query command which means none of the stock CFI code would work out of the box (it does use the AMD CFI commandset though). - the flash is funky -- it's two chips in a single package which leads to quite a bit of confusion, and it also has SRAM areas on it ! - the Blackfin maintainers who took over weren't terribly familiar with the CFI spec (i would say i only have a little familiarity at a higher level).
at any rate, i was able to figure out the JEDEC probe logic in Linux somewhat recently to make it work there, and so i ported that to u-boot which means we can drop this old driver (patches already posted). seems to probe/read/erase/write just fine, so ship it ;).
board/bct-brettl2/gpio_cfi_flash.c board/cm-bf527/gpio_cfi_flash.c board/cm-bf537e/gpio_cfi_flash.c board/cm-bf537u/gpio_cfi_flash.c board/tcm-bf537/gpio_cfi_flash.c
- very special versions of flash drivers dealing with board specific details that prevent the use of the CFI flash driver, in which case they should remain in the board directories.
yep. these are merely glue to support the flashes on these boards that use GPIO's for additional address lines. they actually use the common CFI code already.
there is a thread from a while ago discussing how to make these work better in the larger u-boot framework (NOR flashes which are not fully directly mapped), but i honestly don't think i'll ever get around to implementing that idea. i have no job that requires it, and only had a passing interest in implementing it ;). -mike