[U-Boot-Users] [PATCH] use CFI-Flash and board depended driver together
yotam at marvell.com
Tue Dec 5 12:30:54 CET 2006
The callback function which obtains the portwidth,
chipwidth is the prefer option for a more generic solution.
The driver will then support the none CFI devices as well.
Call for a board specific function to setup the flash_info_t for that
bank will cause a code duplication for auto detect of none CFI devices.
From: Tolunay Orkun [mailto:listmember at orkun.us]
Sent: Tuesday, December 05, 2006 2:56 AM
Cc: Stefan Roese; Jens Scharsig; Andrew Dyer; Rui Sousa; Timur Tabi;
Yotam Admon; matvejchikov at gmail.com
Subject: Re: [U-Boot-Users] [PATCH] use CFI-Flash and board depended
Tolunay Orkun wrote:
> Jens Scharsig wrote:
>> i need to use cfi and board flash driver together. This Patch
>> simple way to do this with a minimun changes at cfi_flash.c. All
>> will only enable if CFG_FLASH_BOARD_DRIVER defined.
>> * Rename flash_print_info, flash_erase, write_buff and
>> flash_real_protect to cfi_xxxx, if CFG_FLASH_BOARD_DRIVER is
>> defined. This will allow use cfi driver together with board a
>> dependent flash driver (see README.board-dependent-flash for
>> an example)
> I have to object to this patch. I will be providing a testing patch
> tonight or tomorrow that will address this issue properly which is
> teaching cfi_flash driver to deal with non-cfi flash. There is no need
> to have two flash drivers...
I've started with this patch but ran into some roadblocks so it did not
happen last Friday as promised. I have been thinking better solutions
avoids two sets of flash drivers.
Basically, I was trying to detect the port and chip width by using a
technique similar to flash_detect_cfi() but instead of checking for
combinations of Q R Y etc., I was trying to see there was a change in
first 16 bytes of flash. Well that seemed workable until I actually
the modified code :( The probe this way failed miserably with Intel
responding to 0x90 in either in upper or lower byte even in 16-bit mode!
Thus, if the flash is not detected by CFI method the portwidth and
will have to be set manually for even jedec ids to be read properly. If
jedec probe worked, the jedec ids could be used to lookup a static list
proper configuration of info structure.
I have not given up yet. I would like to start over and take a simpler
approach. Here is the idea:
The CFI driver will do CFI probe. If the probe is not successful and
configuration has defined a macro, CFI driver will call a board specific
function to setup the flash_info_t for that bank.
I will pass the bank number to the function as argument. If the function
returns non-zero, I will assume that board has setup the info structure
successfully (hopefully) and move on. This still avoids driver code
duplication by only passing the responsibility of setting up the info
structure to the board.
A variation of this could be the callback function obtains the
chipwidth (and possibly the command set) for the specific bank and do
flash_read_jedec_ids to get the ids and lookup the values from a
compiled list like I originally intended. This list would be compiled in
compiled only if this feature is enabled, say CFG_FLASH_CFI_JEDEC.
of a callback we could use the flash_base address list and augment the
to an array of structures which include base, portwidth and chipwidth
that would require a change in all boards that uses CFI driver. A
to the board supplied function is the least invasive way in my opinion.
In either method, to cut the compiled image size a bit if there is
definitely no cfi compliant flash on any bank we can omit the cfi
and other cfi related setup code using a macro like
(or something like that).
I would like to hear opinions regarding which choices looks more
More information about the U-Boot