[U-Boot] Problem with flash on a MPC5200B board
Jerry Van Baren
gvb.uboot at gmail.com
Fri Oct 10 02:19:29 CEST 2008
Sylvain Lamontagne wrote:
> Hi again everyone
>
> I tried a lot of stuff today but was still unable get it to work.
> Here is my Flash configuration:
>
> /*
> * Flash configuration
> */
> #define CFG_FLASH_BASE 0xFF000000
> #define CFG_FLASH_SIZE 0x1000000
> //#define CFG_ENV_ADDR 0xFFFE0000
> #define CFG_ENV_OFFSET 0x00FE0000
> //#define CFG_FLASH_MAX_SIZE 0x00ffffff
> #define CFG_ENV_ADDR (CFG_FLASH_BASE + CFG_ENV_OFFSET)
> #define CFG_MAX_FLASH_BANKS 1 /* max num of memory banks */
> #define CFG_MAX_FLASH_SECT 128 /* max num of sectors on one chip */
> #define CFG_FLASH_SECT_SIZE 0x20000
> #define CFG_FLASH_ERASE_TOUT 240000 /* Flash Erase Timeout (in ms) */
> #define CFG_FLASH_WRITE_TOUT 500 /* Flash Write Timeout (in ms) */
>
> #undef CONFIG_FLASH_16BIT /* Flash is 8-bit */
> //#define CONFIG_FLASH_16BIT
> #define CFG_FLASH_CFI_DRIVER
> #define CFG_FLASH_CFI
> #define CFG_FLASH_USE_BUFFER_WRITE
> #define CFG_FLASH_BANKS_LIST {CFG_FLASH_BASE}
>
>
> I think the problem may come from the Manufacturer ID and Device ID, from
> the datasheet it's supposed to be:
> Manufacturer ID xx01h/1h
> Device ID, Word 1 227Eh/7Eh
>
> The CFI detection seems to report them as
> manufacturer id is 0x5
> device id is 0x56
>
> How can I force it ?
> Or maybe I'm totally searching in the wrong direction...
There is no force. No Jedi Knights. Sorry.
You need to figure out your hardware and why the CFI detection isn't
working or why it *is* working but the flash you have isn't what you
expected.
My advice is to *manually* do the CFI command sequences to read the QRY
response and the manufacturer's ID info using "mw" (memory write) commands.
Ahh, here are some good instructions:
<www.spansion.com/application_notes/read_debug_using_CFI_an_01e.pdf>
Things I've found by manually probing: byte lanes swapped (gotta love
those hardware folks helping me...), bits swapped end-for-end (not
really - I haven't had this for flash but I have for other h/w grrrr),
chip width and data lane width, misunderstanding of how the data should
look when the chip is in command/status mode, etc.
> Sylvain
>
> 2008/10/8 Sylvain Lamontagne <sylvain.lamontagne at gmail.com>
>
>> Humm ... Nobody can help me ?
>> If you need more informations I can get them, I would really like to
>> understand the debug output I'm seeing.
>>
>> Thank you
>>
>> Sylvain
>>
>> 2008/10/7 Sylvain Lamontagne <sylvain.lamontagne at gmail.com>
>>
>> Hi Everyone
>>> I'm pretty new to U-Boot and Embedded system globally, but in the last few
>>> weeks I have learn a lot and I'm now trying to port correctly U-Boot v 1.3.4
>>> to a custom board based on a Icecube. I'm able to boot a linux kernel with
>>> it when I use the RAM with the bootm command.
>>>
>>> Unfortunately, I must make it work with the FLASH. The chip used for the
>>> flash is a S29GL128 or a S29GL256 from Spansion, they are 16bits chips but
Which specific one are you using on your board, 128 or 256? Are they
really Spansion parts or are the "just like Spansion" parts? How many
are soldered down on the board?
>>> the bus is only 8bits. By reading the datasheet, these chips are supposed to
>>> support the Common Flash Interface so I'm trying to make then work with the
>>> CFI driver of U-Boot.
Your results (below) are indicating that they are CFI.
>>> Here is what I get when booting with DEBUG activated:
>>>
>>> U-Boot 1.3.4 (Oct 7 2008 - 16:39:49)
>>>> CPU: MPC5200B v2.2, Core v1.4 at 378 MHz
>>>> Bus 84 MHz, IPB 84 MHz, PCI 21 MHz
>>>> Board: Icecube Based Board
>>>> I2C: 93 kHz, ready
>>>> DRAM: 64 MB
>>>> Top of RAM usable for U-Boot at: 04000000
>>>> Reserving 551k for U-Boot at: 03f76000
>>>> Reserving 130k for malloc() at: 03f55800
>>>> Reserving 68 Bytes for Board Info at: 03f557bc
>>>> Reserving 60 Bytes for Global Data at: 03f55780
>>>> Stack Pointer at: 03f55768
>>>> New Stack Pointer is: 03f55768
>>>> Now running in RAM - U-Boot at: 03f76000
>>>> FLASH: flash detect cfi
>>>> fwc addr ff000000 cmd f0 f0 8bit x 8 bit
>>>> fwc addr ff000000 cmd f0 f0 8bit x 8 bit
>>>> fwc addr ff000055 cmd 98 98 8bit x 8 bit
>>>> is= cmd 51(Q) addr ff000010 is= 0 51
>>>> fwc addr ff000555 cmd 98 98 8bit x 8 bit
>>>> is= cmd 51(Q) addr ff000010 is= 0 51
>>>> fwc addr ff000000 cmd f0 f0f0 16bit x 8 bit
>>>> fwc addr ff000000 cmd f0 f0f0 16bit x 8 bit
>>>> fwc addr ff0000aa cmd 98 9898 16bit x 8 bit
>>>> is= cmd 51(Q) addr ff000020 is= 5151 5151
>>>> is= cmd 52(R) addr ff000022 is= 5252 5252
>>>> is= cmd 59(Y) addr ff000024 is= 5959 5959
Sorry, I am not sure how to interpret this. Do it by hand and see what
the results are. The address offsets seem to say 2 chips x8, but the
data seems to be saying 4 chips x8.
Get the raw data by hand and dissect it.
>>>> device interface is 2
>>>> found port 2 chip 1 port 16 bits chip 8 bits
>>>> 00 : 51 52 59 02 00 40 00 00 00 00 00 27 36 00 00 06 QRY.. at .....'6...
>>>> 10 : 06 09 13 03 05 03 02 19 02 00 06 00 01 ff 00 00 ................
>>>> 20 : 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 ...............
>>>> fwc addr ff000000 cmd f0 f0f0 16bit x 8 bit
>>>> fwc addr ff001554 cmd aa aaaa 16bit x 8 bit
>>>> fwc addr ff000aaa cmd 55 5555 16bit x 8 bit
>>>> fwc addr ff001554 cmd 90 9090 16bit x 8 bit
>>>> fwc addr ff000000 cmd f0 f0f0 16bit x 8 bit
>>>> fwc addr ff0000aa cmd 98 9898 16bit x 8 bit
>>>> manufacturer is 2
>>>> manufacturer id is 0x5
Are you *sure* you have Spansion parts on the board? Read the brand and
chip number off the chips soldered to your board, don't trust the h/w
engineers, they are out to get you. ;-)
Also, do the ID sequence by hand, don't trust the s/w.
>>>> device id is 0x56
>>>> device id2 is 0x0
>>>> cfi version is 0x3133
>>>> size_ratio 1 port 16 bits chip 8 bits
Seems right.
>>>> found 1 erase regions
>>>> erase region 0: 0x020000ff
Whoops, 1 erase region isn't right.
>>>> erase_region_count = 256 erase_region_size = 131072
>>>> ERROR: too many flash sectors
More badness.
>>>> fwc addr ff000000 cmd f0 f0 8bit x 8 bit
>>>> flash_protect ON: from 0xFFF00000 to 0xFFF43FFF
>>>> flash_protect ON: from 0xFFFE0000 to 0xFFFFFFFF
>>>> 32 MB
>>>> basetask = 0, tasks = 2
>>>> task_org = 0x03fb4c00
>>>> TDT start = 0x00000040, end = 0x000001b8
>>>> PCI: Bus Dev VenId DevId Class Int
>>>> PCI Scan: Found Bus 0, Device 24, Function 0
>>>> 00 18 168c 001b 0200 00
>>>> PCI Scan: Found Bus 0, Device 26, Function 0
>>>> 00 1a 1057 5809 0680 00
>>>> In: serial
>>>> Out: serial
>>>> Err: serial
>>>> U-Boot relocated to 03f76000
>>>> Net: mpc5xxx_fec_init_phy... Begin
>>>> mpc5xxx_fec_init_phy... Done
>>>> FEC ETHERNET
>>>>
>>>> Type "boot" to boot to Linux (default)
>>>> Type "help" for a list of commands
>>>
>>> So I got an "ERROR: too many flash sectors" and a 32 MB size ... I know
>>> for sure that the chip is 16 MB so there is a kind of inconsistency...
>>> I'm also a bit confuse about what "#define" I should use to force my board
>>> to communicate in 8bit even if it's capable of 16bit.
The chips "are capable", but the selection between x8 and x16 is a
hardware selection that was chosen by the h/w engineer when he drew the
schematic. There isn't any "force" nor choice by the time you get the
board. You need to understand his choice and configure for it.
>>> I though that I simply had to "#undef FLASH_CFI_16BIT" but that doesn't
>>> seem to do the trick.
>>>
>>> I'm not sure to understand the debug output I got...
>>> fwc addr ff000000 cmd f0 f0 8bit x 8 bit
>>> ...
>>> fwc addr ff000000 cmd f0 f0f0 16bit x 8 bit
>>>
>>> Also is the value of erase_region_count = 256 should be the number of
>>> sector on the chip ???? Because I know that the ship have a maximum of 128
>>> sectors...
>>> If someone could brief me a bit about the debug output posted above I
>>> would greatly appreciate.
I'm not knowledgeable of the flash debug prints because I've never used
them. I would do the flash probing manually and decode it against the
data sheet.
Cut out the middleman, understand what your hardware is telling you
without the the s/w (debug) interpreting it.
>>> I'm pretty sure I have nearly complete the port except for this FLASH
>>> issue...
>>>
>>> Help/Suggestion/Comments are welcome
>>>
>>> Thank you
>>>
>>> Sylvain
HTH,
gvb
More information about the U-Boot
mailing list