[U-Boot] [U-Boot-DM] List of offending drivers

[Mike Frysinger <vapier@gentoo.org>]

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
> 
> 1) 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
>
> 2) 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120731/6d6cff13/attachment.pgp>