[U-Boot-Users] Unable to write to flash..
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.
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,
- 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???
- We have tried mapping the flash at different addresses with the same
result
Not useful.
- 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.
- 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
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,
- 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..
- We have tried mapping the flash at different addresses with the same
result
Not useful.
- 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.
- 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:
- You need to use the word addresses column in the table.
- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
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
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!!
participants (3)
-
Jerry Van Baren -
rags -
Wolfgang Denk