Sylvain,
there may be a combination of several faults.
What exact type of flash are you using ->have a look at the suffix like
"TFIR040" to figure out if it's a fixed x8 or x16 or configurable and
how the sector layout is supposed to be (top/bottom boot or uniform
sector flash).
Send me the correct code and I'll have a look.
If it is a configurable width chip you should ask the designer how he
decided to connect the "byte#" pin, i.e. pull-up or pull-down.
Last point is the MPC5200 local bus running in little endian mode since
it's basically designed for PCI - that's a common mistake.
If your byteorder matches and you're running with 16-Bit you should
x-check the byte lanes, i.e. check if upper and lower date byte are
connected to the flash in a proper way.
If you can post the schematic (single page containing the Flash and LPB)
I'll verify it.
regards,
Andre
Jerry Van Baren schrieb:
> 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 <[EMAIL PROTECTED]>
>>
>>
>>> 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 <[EMAIL PROTECTED]>
>>>
>>> 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 [EMAIL
>>>>> PROTECTED]'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
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht:
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
