[U-Boot-Users] Unable to write to flash..

[U-Boot-Users] Unable to write to flash..

[rags]

Hi,
We've been having a strange problem during our board bringup. I have given a
brief description about our board, the problem we are facing and
investigation done so far. Would appreciate any comments/pointers for
further investigations..
I apologize in advance for the long post that follows..:-)

Regards
Vijay

Board description:
This is a MPC8360E based board with a S29GL01GP12T (16 bit) flash
(size=128MB) and 256 MB DDRRam + other peripherals. We have a BDI2000 JTAG
debugger connected to the board. Relevant sections of our BDI config file
are given below,

[INIT]
; init core register
WREG    MSR             0x00001002      ;MSR  : ME,RI

; Move MBAR to 0xe0000000
WM32    0xff400000      0xe0000000      ;MBAR to 0xe0000000

; Initialize LAWBAR's
WM32    0xe0000020      0xf8000000      ;LBLAWBAR0 : Flash
WM32    0xe0000024      0x8000001a      ;LBLAWAR0  : *
WM32    0xe00000A0      0x00000000      ;DDRLAWBAR0: DDR Main SODIMM
WM32    0xe00000A4      0x8000001b      ;DDRLAWAR0 : 256M

...

WM32    0xe0005000      0xf8001001      ;BR0 : Flash
WM32    0xe0005004      0xf80069f7      ;OR0 : Flash 32M

...

[TARGET]
BOOTADDR    0xfff00100                  ;boot address used for start-up
break
RCW         0x84600000 0x04030006       ;override reset configuration words

...

[FLASH]
CHIPTYPE    MIRRORX16   ;Flash type: Spansion S29GL01GP
CHIPSIZE    0x08000000  ;The size of one flash chip in bytes
BUSWIDTH    16          ;The width of the flash memory bus in bits (8 | 16 |
32 | 64)
;WORKSPACE   0x00200000  ;workspace in DDR RAM 


With this the processor halts at 0xFFF00100 on reset. We are able to read
the system configuration registers at the relocated IMMR address and able to
access the DDR Ram (starting at 0x00000000) and Flash starting at
(0xF8000000). The flash contains some data that was pre-programmed (First
sector contains HRCW and a U-boot image is also burned at another location).

Problem description:
We are able to read the contents of the flash, but unable to erase or
program it (we have tried several combinations of sectors). We can confirm
the read because of the pre-programmed content (HRCW + U-boot image). 

Is it possible to isolate this to a HW/SW(config file) issue??

Investigation done so far:
We have done the following so far,

1. We have probed the address and data lines along with other control
signals (Chip select etc..). Also we have made sure that the  write protect
remains high for the flash. All the address lines are toggling and data
lines seem to be ok (since we are able to read stuff ok from the flash).
Also chip select is getting issued properly at the correct time. (All these,
as per our hw guys).

2. We have tried mapping the flash at different addresses with the same
result

3. We used the same flash on a Freescale MDS reference board (with the same
configuration for Flash) and are able to read and write successfully. Also
the U-boot image burned in the flash comes up.

4. We tried using the protocol defined in the datasheet to read the
'manufacturer id' using BDI MM/MD commands. But this seems to fail in both
our board and the MDS board.

-- 
View this message in context: http://www.nabble.com/Unable-to-write-to-flash..-tf4451149.html#a12699172
Sent from the Uboot - Users mailing list archive at Nabble.com.

[U-Boot-Users] Unable to write to flash..

[Jerry Van Baren]

rags wrote:
> Hi,
> We've been having a strange problem during our board bringup. I have given a
> brief description about our board, the problem we are facing and
> investigation done so far. Would appreciate any comments/pointers for
> further investigations..
> I apologize in advance for the long post that follows..:-)
> 
> Regards
> Vijay
> 
> Board description:
> This is a MPC8360E based board with a S29GL01GP12T (16 bit) flash
> (size=128MB) and 256 MB DDRRam + other peripherals. We have a BDI2000 JTAG
> debugger connected to the board. Relevant sections of our BDI config file
> are given below,

[snip - I'm going to assume the BDI config is OK, I don't have time or 
expertise to check it]

> With this the processor halts at 0xFFF00100 on reset. We are able to read
> the system configuration registers at the relocated IMMR address and able to
> access the DDR Ram (starting at 0x00000000) and Flash starting at
> (0xF8000000). The flash contains some data that was pre-programmed (First
> sector contains HRCW and a U-boot image is also burned at another location).

Good.

> Problem description:
> We are able to read the contents of the flash, but unable to erase or
> program it (we have tried several combinations of sectors). We can confirm
> the read because of the pre-programmed content (HRCW + U-boot image). 

Read - good.  Not able to program - likely not using the right 
addresses, data.  Possibly hardware problems, but lower probability.

> Is it possible to isolate this to a HW/SW(config file) issue??

Yes.  ;-)

> Investigation done so far:
> We have done the following so far,
> 
> 1. We have probed the address and data lines along with other control
> signals (Chip select etc..). Also we have made sure that the  write protect
> remains high for the flash. All the address lines are toggling and data
> lines seem to be ok (since we are able to read stuff ok from the flash).
> Also chip select is getting issued properly at the correct time. (All these,
> as per our hw guys).

I presume the WR* line is toggling properly too???

> 2. We have tried mapping the flash at different addresses with the same
> result

Not useful.

> 3. We used the same flash on a Freescale MDS reference board (with the same
> configuration for Flash) and are able to read and write successfully. Also
> the U-boot image burned in the flash comes up.

Good, you have something to compare your hardware to.

> 4. We tried using the protocol defined in the datasheet to read the
> 'manufacturer id' using BDI MM/MD commands. But this seems to fail in both
> our board and the MDS board.

You need to figure this out.  If you figure this out, you will have the 
answer to your problem (99.98% probability).

Figure out how it works on the MDS board first, since that is know 
working, then do the same on your custom hardware.

Note the addresses (byte vs. word) in the 29GL10 data sheet (I'm looking 
at <http://www.spansion.com/datasheets/s29gl-p_00_a5_e.pdf>)
   Table 7.4 Autoselect Entry in System
Important points:
1) You need to use the word addresses column in the table.
2) You need to use the correct BDI command modifier to generate word (16 
bit) writes - this is VERY IMPORTANT.

The following is invalid syntax, but illustrates what I'm saying:
   mw.w Basex555 00aa
   mw.w Basex2AA 0055
   mw.w Basex555 0090
If that doesn't work, try a byte swap:
   mw.w Basex555 aa00
   mw.w Basex2AA 5500
   mw.w Basex555 9000

Good luck,
gvb

[U-Boot-Users] Unable to write to flash..

[rags]

My responses are inlined with '==>'



Jerry Van Baren wrote:
> 
> rags wrote:
>> Hi,
>> We've been having a strange problem during our board bringup. I have
>> given a
>> brief description about our board, the problem we are facing and
>> investigation done so far. Would appreciate any comments/pointers for
>> further investigations..
>> I apologize in advance for the long post that follows..:-)
>> 
>> Regards
>> Vijay
>> 
>> Board description:
>> This is a MPC8360E based board with a S29GL01GP12T (16 bit) flash
>> (size=128MB) and 256 MB DDRRam + other peripherals. We have a BDI2000
>> JTAG
>> debugger connected to the board. Relevant sections of our BDI config file
>> are given below,
> 
> [snip - I'm going to assume the BDI config is OK, I don't have time or 
> expertise to check it]
> 
>> With this the processor halts at 0xFFF00100 on reset. We are able to read
>> the system configuration registers at the relocated IMMR address and able
>> to
>> access the DDR Ram (starting at 0x00000000) and Flash starting at
>> (0xF8000000). The flash contains some data that was pre-programmed (First
>> sector contains HRCW and a U-boot image is also burned at another
>> location).
> 
> Good.
> 
>> Problem description:
>> We are able to read the contents of the flash, but unable to erase or
>> program it (we have tried several combinations of sectors). We can
>> confirm
>> the read because of the pre-programmed content (HRCW + U-boot image). 
> 
> Read - good.  Not able to program - likely not using the right 
> addresses, data.  Possibly hardware problems, but lower probability.
> 
>> Is it possible to isolate this to a HW/SW(config file) issue??
> 
> Yes.  ;-)
> 
>> Investigation done so far:
>> We have done the following so far,
>> 
>> 1. We have probed the address and data lines along with other control
>> signals (Chip select etc..). Also we have made sure that the  write
>> protect
>> remains high for the flash. All the address lines are toggling and data
>> lines seem to be ok (since we are able to read stuff ok from the flash).
>> Also chip select is getting issued properly at the correct time. (All
>> these,
>> as per our hw guys).
> 
> I presume the WR* line is toggling properly too???
> 
> ==> Yes, as per our hardware folks the WR* line is toggling properly too..
> 
>> 2. We have tried mapping the flash at different addresses with the same
>> result
> 
> Not useful.
> 
>> 3. We used the same flash on a Freescale MDS reference board (with the
>> same
>> configuration for Flash) and are able to read and write successfully.
>> Also
>> the U-boot image burned in the flash comes up.
> 
> Good, you have something to compare your hardware to.
> 
>> 4. We tried using the protocol defined in the datasheet to read the
>> 'manufacturer id' using BDI MM/MD commands. But this seems to fail in
>> both
>> our board and the MDS board.
> 
> You need to figure this out.  If you figure this out, you will have the 
> answer to your problem (99.98% probability).
> 
> Figure out how it works on the MDS board first, since that is know 
> working, then do the same on your custom hardware.
> 
> Note the addresses (byte vs. word) in the 29GL10 data sheet (I'm looking 
> at <http://www.spansion.com/datasheets/s29gl-p_00_a5_e.pdf>)
>    Table 7.4 Autoselect Entry in System
> Important points:
> 1) You need to use the word addresses column in the table.
> 2) You need to use the correct BDI command modifier to generate word (16 
> bit) writes - this is VERY IMPORTANT.
> 
> The following is invalid syntax, but illustrates what I'm saying:
>    mw.w Basex555 00aa
>    mw.w Basex2AA 0055
>    mw.w Basex555 0090
> If that doesn't work, try a byte swap:
>    mw.w Basex555 aa00
>    mw.w Basex2AA 5500
>    mw.w Basex555 9000
> 
> Good luck,
> gvb
> 
> ==> We are currently trying to figure this out..Will post once I have a
> update..Meanwhile, pls let me know if there is anything else that could be
> checked..
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 
> 

-- 
View this message in context: http://www.nabble.com/Unable-to-write-to-Spansion-flash-on-MPC8360-based-board..-tf4451149.html#a12771751
Sent from the Uboot - Users mailing list archive at Nabble.com.

[U-Boot-Users] Unable to write to flash..

[Wolfgang Denk]

In message <12771751.post@talk.nabble.com> you wrote:
> 
> My responses are inlined with '==>'

Please read http://www.netmeister.org/news/learn2quote.html

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
To be is to program.

[U-Boot-Users] Unable to write to flash..

[rags]

 >We are currently trying to figure this out..Will post once I have an
update..Meanwhile, pls let me know if there is anything   >else that could
be checked..

Thanks for all your support, we were able to narrow the issue down to the
RCW. The Local bus 'LALE' signal timing bit in HRCW was being set to 0 (it
needed to be '1' for our board). The kicker was that as per the latest
MPC8360e manual that specific bit is marked as 'RESERVED' and hence
cleared!!
-- 
View this message in context: http://www.nabble.com/Unable-to-write-to-Spansion-flash-on-MPC8360-based-board..-tf4451149.html#a12899729
Sent from the Uboot - Users mailing list archive at Nabble.com.