[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board
Hi all, here's what I got from the bdi2000 shell:
- TARGET: processing user reset request - BDI asserts HRESET - Reset JTAG controller passed - JTAG exists check passed - IDCODE is 0x0003901D - SVR is 0x80390020 - PVR is 0x80210020 - CCSRBAR is 0x0_ff700000 - BDI removes HRESET - TARGET: Target PVR is 0x80210020 - TARGET: resetting target passed atum8548>info Target CPU : MPC85xx (e500v2 rev.2) Target state : running atum8548>era 0 # Writing to workspace failed atum8548>erase 00000000 # Writing to workspace failed atum8548>prog 0 /tftpboot/u-boot.bin Programming /tftpboot/u-boot.bin , please wait .... # Writing to workspace failed atum8548>
This is of course probably due to my bdi2000 cfg file - I've annexed it in this email. I've tried to keep the file bare bones though this is my first time writing this config. I've got one flash bank, a 128MB spansion S29GL01GP . Here's my flash #DEFINE's :
#define CFG_BOOT_BLOCK 0xf8000000 /* boot TLB block */ #define CFG_FLASH_BASE CFG_BOOT_BLOCK /* start of FLASH 128M */
#define CFG_BR0_PRELIM 0xf8001001
#define CFG_OR0_PRELIM 0xff806e65
#define CFG_FLASH_BANKS_LIST {CFG_FLASH_BASE} #define CFG_MAX_FLASH_BANKS 1 /* number of banks */ #define CFG_MAX_FLASH_SECT 1024 /* sectors per device */ #undef CFG_FLASH_CHECKSUM #define CFG_FLASH_ERASE_TOUT 512000 /* Flash Erase Timeout (ms) */ #define CFG_FLASH_WRITE_TOUT 8000 /* Flash Write Timeout (ms) */
The hardware engineer I'm working with tells me our first challenge is to write the u-boot.bin file to flash. Can any anyone please help? Robert
I had the same problem with an mpc8641. After emailing the Abatron folks they set me straight.
There's probably a line in your bdi config file like this:
WORKSPACE 0x00002000 ;workspace in SDRAM
Comment that out. The BDI uses a little chunk of the processor's RAM to speed up flashing and whatnot if you include that line. But if you don't have a valid RAM configuration then you're going to get workspace errors. The BDI will still be able to work without the workspace RAM, it's just slower.
Hope that helps, Chris Fester
On Wed, 2007-08-29 at 16:27 -0400, robert lazarski wrote:
Hi all, here's what I got from the bdi2000 shell:
- TARGET: processing user reset request
- BDI asserts HRESET
- Reset JTAG controller passed
- JTAG exists check passed
- IDCODE is 0x0003901D
- SVR is 0x80390020
- PVR is 0x80210020
- CCSRBAR is 0x0_ff700000
- BDI removes HRESET
- TARGET: Target PVR is 0x80210020
- TARGET: resetting target passed
atum8548>info Target CPU : MPC85xx (e500v2 rev.2) Target state : running atum8548>era 0 # Writing to workspace failed atum8548>erase 00000000 # Writing to workspace failed atum8548>prog 0 /tftpboot/u-boot.bin Programming /tftpboot/u-boot.bin , please wait .... # Writing to workspace failed atum8548>
This is of course probably due to my bdi2000 cfg file - I've annexed it in this email. I've tried to keep the file bare bones though this is my first time writing this config. I've got one flash bank, a 128MB spansion S29GL01GP . Here's my flash #DEFINE's :
#define CFG_BOOT_BLOCK 0xf8000000 /* boot TLB block */ #define CFG_FLASH_BASE CFG_BOOT_BLOCK /* start of FLASH 128M */
#define CFG_BR0_PRELIM 0xf8001001
#define CFG_OR0_PRELIM 0xff806e65
#define CFG_FLASH_BANKS_LIST {CFG_FLASH_BASE} #define CFG_MAX_FLASH_BANKS 1 /* number of banks */ #define CFG_MAX_FLASH_SECT 1024 /* sectors per device */ #undef CFG_FLASH_CHECKSUM #define CFG_FLASH_ERASE_TOUT 512000 /* Flash Erase Timeout (ms) */ #define CFG_FLASH_WRITE_TOUT 8000 /* Flash Write Timeout (ms) */
The hardware engineer I'm working with tells me our first challenge is to write the u-boot.bin file to flash. Can any anyone please help? Robert
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
robert lazarski wrote:
Hi all, here's what I got from the bdi2000 shell:
- TARGET: processing user reset request
- BDI asserts HRESET
- Reset JTAG controller passed
- JTAG exists check passed
- IDCODE is 0x0003901D
- SVR is 0x80390020
- PVR is 0x80210020
- CCSRBAR is 0x0_ff700000
- BDI removes HRESET
- TARGET: Target PVR is 0x80210020
- TARGET: resetting target passed
atum8548>info Target CPU : MPC85xx (e500v2 rev.2) Target state : running atum8548>era 0 # Writing to workspace failed atum8548>erase 00000000 # Writing to workspace failed atum8548>prog 0 /tftpboot/u-boot.bin Programming /tftpboot/u-boot.bin , please wait .... # Writing to workspace failed atum8548>
Workspace is RAM. If your memory controller isn't set up, you can't use the workspace. From your config file it looks like you're planning on using some kind of cache for SRAM. I'd just skip this for now. Delete the WORKSPACE line and you should be able to write to flash. It'll be dog-slow, though.
This is of course probably due to my bdi2000 cfg file - I've annexed it in this email. I've tried to keep the file bare bones though this is my first time writing this config. I've got one flash bank, a 128MB spansion S29GL01GP . Here's my flash #DEFINE's :
For my 64Mb Spansion GL flash I use:
CHIPTYPE MIRRORX16 ;Flash type: Spansion CHIPSIZE 0x800000 ;The size of one flash chip in bytes BUSWIDTH 16 ;The width of the flash memory bus in bits (8 | 16 | 32 | 64)
Yours will probably be the same, but size will be 0x1000000. I'm assuming your flash is 128Mb and not 128MB, but I apologize if this is wrong.
#define CFG_BOOT_BLOCK 0xf8000000 /* boot TLB block */ #define CFG_FLASH_BASE CFG_BOOT_BLOCK /* start of FLASH 128M */
#define CFG_BR0_PRELIM 0xf8001001
#define CFG_OR0_PRELIM 0xff806e65
#define CFG_FLASH_BANKS_LIST {CFG_FLASH_BASE} #define CFG_MAX_FLASH_BANKS 1 /* number of banks */ #define CFG_MAX_FLASH_SECT 1024 /* sectors per device */ #undef CFG_FLASH_CHECKSUM #define CFG_FLASH_ERASE_TOUT 512000 /* Flash Erase Timeout (ms) */ #define CFG_FLASH_WRITE_TOUT 8000 /* Flash Write Timeout (ms) */
The hardware engineer I'm working with tells me our first challenge is to write the u-boot.bin file to flash. Can any anyone please help
Robert
regards, Ben
On 8/29/07, Ben Warren bwarren@qstreams.com wrote:
robert lazarski wrote:
atum8548>erase 00000000 # Writing to workspace failed
Workspace is RAM. If your memory controller isn't set up, you can't use the workspace. From your config file it looks like you're planning on using some kind of cache for SRAM. I'd just skip this for now. Delete the WORKSPACE line and you should be able to write to flash. It'll be dog-slow, though.
Thanks! I commented out the cache settings. Now I'm getting closer. I getting:
atum8548>unlock Unlocking flash passed atum8548>erase 0 Erasing flash at 0x00000000 # Erasing flash memory failed atum8548>erase FF000000 Erasing flash at 0x00000000 # Erasing flash memory failed atum8548>erase 0x01000000 Erasing flash at 0x01000000 # Erasing flash memory failed
What chip do you have? What did you start erasing?
This is of course probably due to my bdi2000 cfg file - I've annexed it in this email. I've tried to keep the file bare bones though this is my first time writing this config. I've got one flash bank, a 128MB spansion S29GL01GP . Here's my flash #DEFINE's :
For my 64Mb Spansion GL flash I use:
CHIPTYPE MIRRORX16 ;Flash type: Spansion CHIPSIZE 0x800000 ;The size of one flash chip in bytes BUSWIDTH 16 ;The width of the flash memory bus in bits (8 | 16 | 32 | 64)
Yours will probably be the same, but size will be 0x1000000. I'm assuming your flash is 128Mb and not 128MB, but I apologize if this is wrong.
That makes sense - I'm trying that but got the erase errors above. Any more ideas?
Thanks! Robert
robert lazarski wrote:
On 8/29/07, Ben Warren bwarren@qstreams.com wrote:
robert lazarski wrote:
atum8548>erase 00000000 # Writing to workspace failed
Workspace is RAM. If your memory controller isn't set up, you can't use the workspace. From your config file it looks like you're planning on using some kind of cache for SRAM. I'd just skip this for now. Delete the WORKSPACE line and you should be able to write to flash. It'll be dog-slow, though.
Thanks! I commented out the cache settings. Now I'm getting closer. I getting:
atum8548>unlock Unlocking flash passed atum8548>erase 0 Erasing flash at 0x00000000 # Erasing flash memory failed atum8548>erase FF000000 Erasing flash at 0x00000000 # Erasing flash memory failed atum8548>erase 0x01000000 Erasing flash at 0x01000000 # Erasing flash memory failed
What chip do you have? What did you start erasing?
I'm not much of an expert on this, but I believe the BDI-2000 will execute the INIT section before handing control over to you. Your flash chip is on chip select 0, so the BR0/OR0 registers determine where you will see it. On my CPU (MPC8349) and probably yours too, the 17 least significant (from the left) bits of BR0 determine where the chip select ends up. In your case, this is 0xff80. I expect your flash chip will start at 0xff800000.
I highly recommend reading up on these registers - the Freescale reference manuals are excellent. There are a lot of options, and for NOR flash, at least at startup, you should make sure all the timings are fully relaxed (maximum wait states etc.).
This is of course probably due to my bdi2000 cfg file - I've annexed it in this email. I've tried to keep the file bare bones though this is my first time writing this config. I've got one flash bank, a 128MB spansion S29GL01GP . Here's my flash #DEFINE's :
For my 64Mb Spansion GL flash I use:
CHIPTYPE MIRRORX16 ;Flash type: Spansion CHIPSIZE 0x800000 ;The size of one flash chip in bytes BUSWIDTH 16 ;The width of the flash memory bus in bits (8 | 16 | 32 | 64)
Yours will probably be the same, but size will be 0x1000000. I'm assuming your flash is 128Mb and not 128MB, but I apologize if this is wrong.
That makes sense - I'm trying that but got the erase errors above. Any more ideas?
Thanks! Robert
Hopefully with the right address and the registers set up correctly you will be able to write to flash. One way or the other, we'll get there!
regards, Ben
Scott Wood wrote:
On Wed, Aug 29, 2007 at 05:52:18PM -0400, Ben Warren wrote:
the 17 least significant (from the left) bits
...more commonly known as the "most significant bits". :-P
-Scott
Ah yes, 0 > 31... No wonder I was never much of a mathlete
B-)
On Wed, Aug 29, 2007 at 06:06:43PM -0400, Ben Warren wrote:
Scott Wood wrote:
On Wed, Aug 29, 2007 at 05:52:18PM -0400, Ben Warren wrote:
the 17 least significant (from the left) bits
...more commonly known as the "most significant bits". :-P
-Scott
Ah yes, 0 > 31... No wonder I was never much of a mathlete
Just because they number them backwards doesn't change which ones are more significant. :-)
-Scott
Scott Wood wrote:
On Wed, Aug 29, 2007 at 06:06:43PM -0400, Ben Warren wrote:
Scott Wood wrote:
On Wed, Aug 29, 2007 at 05:52:18PM -0400, Ben Warren wrote:
the 17 least significant (from the left) bits
...more commonly known as the "most significant bits". :-P
-Scott
Ah yes, 0 > 31... No wonder I was never much of a mathlete
Just because they number them backwards doesn't change which ones are more significant. :-)
Riiiigggghhhht....
On 8/29/07, Ben Warren bwarren@qstreams.com wrote:
robert lazarski wrote:
atum8548>erase 0 Erasing flash at 0x00000000 # Erasing flash memory failed
What chip do you have? What did you start erasing?
I'm not much of an expert on this, but I believe the BDI-2000 will execute the INIT section before handing control over to you. Your flash chip is on chip select 0, so the BR0/OR0 registers determine where you will see it. On my CPU (MPC8349) and probably yours too, the 17 least significant (from the left) bits of BR0 determine where the chip select ends up. In your case, this is 0xff80. I expect your flash chip will start at 0xff800000.
I highly recommend reading up on these registers - the Freescale reference manuals are excellent. There are a lot of options, and for NOR flash, at least at startup, you should make sure all the timings are fully relaxed (maximum wait states etc.).
Thanks Ben and all. I really do have 1Gb / 128MB of flash - here's some quick docs:
http://www.spansion.com/products/S29GL01GP.html
Here's the way I came up with my BR0 / OR0 :
/* * FLASH on the Local Bus * based on flash chip S29GL01GP * One bank, 128M, using the CFI driver. * Boot from BR0 bank at 0xf800_0000 * * BR0: * Base address 0 = 0xF8000000 = BR0[0:16] = 1111 1000 0000 0000 0 * Port Size = 16 bits = BRx[19:20] = 10 * Use GPCM = BRx[24:26] = 000 * Valid = BRx[31] = 1 * * 0 4 8 12 16 20 24 28 * 1111 1000 0000 0000 0001 0000 0000 0001 = f8001001 BR0 * * OR0: * Addr Mask = 128M = ORx[0:16] = 1111 1000 0000 0000 0 * Reserved ORx[17:18] = 00 * CSNT = ORx[20] = 1 * ACS = half cycle delay = ORx[21:22] = 11 * SCY = 6 = ORx[24:27] = 0110 * TRLX = use relaxed timing = ORx[29] = 1 * EAD = use external address latch delay = OR[31] = 1 * * 0 4 8 12 16 20 24 28 * 1111 1000 0000 0000 0000 1110 0110 0101 = f8000E65 ORx */
Here's what I now have in my bdi config:
; Setup Flash chip select WM32 0xe0005000 0xf8001001 ;BR0 WM32 0xe0005004 0xf8000E65 ;OR0
[FLASH] CHIPTYPE MIRRORX16 ;AM29LV641D , is equivalent with S29GL01GP ? CHIPSIZE 0x128000 ;The size of one flash chip in bytes BUSWIDTH 16 ;The width of the flash memory bus in bits (8 | 16 | 32) FILE /tftpboot/u-boot.bin FORMAT BIN 0xFF000000 ERASE 0xFF000000 ;erase sector 0 ERASE 0xFF010000 ;erase sector 1 ERASE 0xFF020000 ;erase sector 2 ERASE 0xFF030000 ;erase sector 3
And this is where I get stuck:
atum8548>unlock Unlocking flash passed atum8548>erase 0xf8000000 Erasing flash at 0xf8000000 # Erasing flash memory failed
Anyone got a clue-by-four ? ;-) . Thanks! Robert
robert lazarski wrote:
On 8/29/07, Ben Warren bwarren@qstreams.com wrote:
robert lazarski wrote:
atum8548>erase 0 Erasing flash at 0x00000000 # Erasing flash memory failed
What chip do you have? What did you start erasing?
I'm not much of an expert on this, but I believe the BDI-2000 will execute the INIT section before handing control over to you. Your flash chip is on chip select 0, so the BR0/OR0 registers determine where you will see it. On my CPU (MPC8349) and probably yours too, the 17 least significant (from the left) bits of BR0 determine where the chip select ends up. In your case, this is 0xff80. I expect your flash chip will start at 0xff800000.
I highly recommend reading up on these registers - the Freescale reference manuals are excellent. There are a lot of options, and for NOR flash, at least at startup, you should make sure all the timings are fully relaxed (maximum wait states etc.).
Thanks Ben and all. I really do have 1Gb / 128MB of flash - here's some quick docs:
You're right. Sorry about that.
Here's the way I came up with my BR0 / OR0 :
/*
- FLASH on the Local Bus
- based on flash chip S29GL01GP
- One bank, 128M, using the CFI driver.
- Boot from BR0 bank at 0xf800_0000
- BR0:
- Base address 0 = 0xF8000000 = BR0[0:16] = 1111 1000 0000 0000 0
- Port Size = 16 bits = BRx[19:20] = 10
- Use GPCM = BRx[24:26] = 000
- Valid = BRx[31] = 1
- 0 4 8 12 16 20 24 28
- 1111 1000 0000 0000 0001 0000 0000 0001 = f8001001 BR0
- OR0:
- Addr Mask = 128M = ORx[0:16] = 1111 1000 0000 0000 0
- Reserved ORx[17:18] = 00
- CSNT = ORx[20] = 1
- ACS = half cycle delay = ORx[21:22] = 11
- SCY = 6 = ORx[24:27] = 0110
- TRLX = use relaxed timing = ORx[29] = 1
- EAD = use external address latch delay = OR[31] = 1
- 0 4 8 12 16 20 24 28
- 1111 1000 0000 0000 0000 1110 0110 0101 = f8000E65 ORx
*/
Here's what I now have in my bdi config:
; Setup Flash chip select WM32 0xe0005000 0xf8001001 ;BR0 WM32 0xe0005004 0xf8000E65 ;OR0
[FLASH] CHIPTYPE MIRRORX16 ;AM29LV641D , is equivalent with S29GL01GP ? CHIPSIZE 0x128000 ;The size of one flash chip in bytes
CHIPSIZE 0x8000000
BUSWIDTH 16 ;The width of the flash memory bus in bits (8 | 16 | 32) FILE /tftpboot/u-boot.bin FORMAT BIN 0xFF000000 ERASE 0xFF000000 ;erase sector 0 ERASE 0xFF010000 ;erase sector 1 ERASE 0xFF020000 ;erase sector 2 ERASE 0xFF030000 ;erase sector 3
You might as well fill these in properly. I think they're only used if you use the 'erase' command without arguments, though.
And this is where I get stuck:
atum8548>unlock Unlocking flash passed atum8548>erase 0xf8000000 Erasing flash at 0xf8000000 # Erasing flash memory failed
Anyone got a clue-by-four ? ;-) . Thanks! Robert
Whenever I use the erase command, I specify the sector size and the number of sectors to erase. Have you tried:
erase 0xf8000000 0x20000 1 (erase 1 sector sized 128kB)
Can you read from the chip using the mdh command? Everything should be 0xFFFF. You can also try unlocking the chip manually. For my chip the sequence is:
; Enable flash programming WM16 0xfe000000 0x0060 ;clear flash lock-bits WM16 0xfe000000 0x00d0 DELAY 1000 WM16 0xfe000000 0xffff
I haven't looked at the memory map of your chip, but it may be different.
Another fun thing to do is to try querying the chip's CFI registers to see if it responds. This is documented in section 12.2 of the Spansion spec.
regards, Ben
On 8/30/07, Ben Warren bwarren@qstreams.com wrote:
robert lazarski wrote:
On 8/29/07, Ben Warren bwarren@qstreams.com wrote:
robert lazarski wrote:
atum8548>erase 0 Erasing flash at 0x00000000 # Erasing flash memory failed
Thanks Ben and all. I really do have 1Gb / 128MB of flash - here's some quick docs:
You're right. Sorry about that.
CHIPSIZE 0x128000 ;The size of one flash chip in bytes
CHIPSIZE 0x8000000
Did you mean to say I should have 'CHIPSIZE 0x8000000' ? Is 0x128000 for 1Gb (128MB) not correct? I tried that but still get the same error.
Whenever I use the erase command, I specify the sector size and the number of sectors to erase. Have you tried:
erase 0xf8000000 0x20000 1 (erase 1 sector sized 128kB)
Tried that:
atum8548>erase 0xf8000000 0x20000 1 # Erasing flash memory failed
I think my unlocking is incorrect...
Can you read from the chip using the mdh command? Everything should be
No, I get: atum8548>mdh # SAP: read access failed
0xFFFF. You can also try unlocking the chip manually. For my chip the sequence is:
; Enable flash programming WM16 0xfe000000 0x0060 ;clear flash lock-bits WM16 0xfe000000 0x00d0 DELAY 1000 WM16 0xfe000000 0xffff
I haven't looked at the memory map of your chip, but it may be different.
I tried that to no effect - will be looking at docs to confirm mine is the same later today.
Another fun thing to do is to try querying the chip's CFI registers to see if it responds. This is documented in section 12.2 of the Spansion spec.
I'll look at that too - thanks for the help! Robert
robert lazarski wrote:
On 8/30/07, Ben Warren bwarren@qstreams.com wrote:
robert lazarski wrote:
On 8/29/07, Ben Warren bwarren@qstreams.com wrote:
robert lazarski wrote:
atum8548>erase 0 Erasing flash at 0x00000000 # Erasing flash memory failed
Thanks Ben and all. I really do have 1Gb / 128MB of flash - here's some quick docs:
You're right. Sorry about that.
CHIPSIZE 0x128000 ;The size of one flash chip in bytes
CHIPSIZE 0x8000000
Did you mean to say I should have 'CHIPSIZE 0x8000000' ? Is 0x128000 for 1Gb (128MB) not correct? I tried that but still get the same error.
128 MB = 128 * 1024 * 1024 = 134217728 = 0x8000000
Whenever I use the erase command, I specify the sector size and the number of sectors to erase. Have you tried:
erase 0xf8000000 0x20000 1 (erase 1 sector sized 128kB)
Tried that:
atum8548>erase 0xf8000000 0x20000 1 # Erasing flash memory failed
I think my unlocking is incorrect...
Can you read from the chip using the mdh command? Everything should be
No, I get: atum8548>mdh # SAP: read access failed
Did you try mdh 0xf8000000 ? regards, Ben
On 8/30/07, Ben Warren bwarren@qstreams.com wrote:
Did you try mdh 0xf8000000 ?
Well after playing a bunch of option bingo I got here:
5ep8548a>mdh 0xf8000000 0_f8000000 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f8000010 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f8000020 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f8000030 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f8000040 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f8000050 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f8000060 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f8000070 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f8000080 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f8000090 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f80000a0 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f80000b0 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f80000c0 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f80000d0 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f80000e0 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f80000f0 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................
Is that actually a read from our flash - are those numbers believable? We put a scope on the chip select of the flash chip put couldn't trigger a signal, so we're in doubt.
I still can't erase or write the flash even though I tried your unlock commands. I am trying to figure out if those addresses work for the S29GL01GP - I don't think you mentioned your exact chip - could you please let me know your spansion model number?
Still trying to dig into the 12.2 spec section ;-) .
Thanks! Robert
Hi Robert,
robert lazarski wrote:
On 8/30/07, Ben Warren bwarren@qstreams.com wrote:
Did you try mdh 0xf8000000 ?
Well after playing a bunch of option bingo I got here:
5ep8548a>mdh 0xf8000000 0_f8000000 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f8000010 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f8000020 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f8000030 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f8000040 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f8000050 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f8000060 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f8000070 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f8000080 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f8000090 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f80000a0 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f80000b0 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f80000c0 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f80000d0 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f80000e0 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................ 0_f80000f0 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 ................
Is that actually a read from our flash - are those numbers believable? We put a scope on the chip select of the flash chip put couldn't trigger a signal, so we're in doubt.
That's pretty ugly. If you don't see CS0 toggle, you're not reading the chip. If you can, probe the nOE pins directly on the flash chip (hopefully not BGA :-( ). Maybe you have other chip selects that overlap in address space? Just to be safe set the valid bit to 0 on all other chip selects. But before you do that...
One other thing I just thought of - you need to make sure the Local Bus Access Windows are set properly. My chip has separate ones for DDR and for Local Bus, and yours may as well. The config file you sent has the LAWBAR for local bus set to 0x000c0000, when it should be 0xf8000000, I think. If this is set wrong, I don't think you'll be able to access the memory range. Info is in the 'System Configuration' section of your reference manual.
I still can't erase or write the flash even though I tried your unlock commands. I am trying to figure out if those addresses work for the S29GL01GP - I don't think you mentioned your exact chip - could you please let me know your spansion model number?
We're using S29GL064M (just a baby)
Still trying to dig into the 12.2 spec section ;-) .
Thanks! Robert
Fun stuff, eh?
Ben
On 8/30/07, Ben Warren bwarren@qstreams.com wrote:
One other thing I just thought of - you need to make sure the Local Bus Access Windows are set properly. My chip has separate ones for DDR and for Local Bus, and yours may as well. The config file you sent has the LAWBAR for local bus set to 0x000c0000, when it should be 0xf8000000, I think. If this is set wrong, I don't think you'll be able to access the memory range. Info is in the 'System Configuration' section of your reference manual.
Which manual? I tried
This part I'm having problems understanding. This is what I have for the config of MPC8548CDS board - what I'm using as a reference:
; Initialize LAWBAR's WM32 0xe0000C08 0x00000000 ;LAWBAR0 : @0x00000000 WM32 0xe0000C10 0x80f0001b ;LAWAR0 : DDR/SDRAM 256MB WM32 0xe0000C28 0x000c0000 ;LAWBAR1 : @0xc0000000 WM32 0xe0000C30 0x8040001d ;LAWAR1 : Local Bus 1GB
In what manual is this explained in, ie the 0xe0000 addresses? I can't seem to tie together the LAW's in my init.S and the LAW's here.
/* * LAW(Local Access Window) configuration: * * 0x0000_0000 0x7fff_ffff DDR 2G * 0x8000_0000 0x9fff_ffff PCI1 MEM 512M * 0xa000_0000 0xbfff_ffff PCIe MEM 512M * 0xc000_0000 0xdfff_ffff PCI2 MEM 512M * 0xe000_0000 0xe000_ffff CCSR 1M * 0xe200_0000 0xe10f_ffff PCI1 IO 1M * 0xe280_0000 0xe20f_ffff PCI2 IO 1M * 0xe300_0000 0xe30f_ffff PCIe IO 1M * 0xf800_0000 0xffff_ffff FLASH (boot bank) 128M * * Notes: * CCSRBAR and L2-as-SRAM don't need a configured Local Access Window. * If flash is 8M at default position (last 8M), no LAW needed. * * LAW 0 is reserved for boot mapping */
.section .bootpg, "ax" .globl law_entry law_entry: entry_start
.long (4f-3f)/6 3: .long 0 .long (LAWAR_TRGT_DDR | (LAWAR_SIZE & LAWAR_SIZE_128M)) & ~LAWAR_EN
.long (CFG_PCI1_MEM_PHYS>>12) & 0xfffff .long LAWAR_EN | LAWAR_TRGT_PCI1 | (LAWAR_SIZE & LAWAR_SIZE_512M)
.long (CFG_PCI1_IO_PHYS>>12) & 0xfffff .long LAWAR_EN | LAWAR_TRGT_PCI1 | (LAWAR_SIZE & LAWAR_SIZE_1M)
.long (CFG_PCI2_MEM_PHYS>>12) & 0xfffff .long LAWAR_EN | LAWAR_TRGT_PCI2 | (LAWAR_SIZE & LAWAR_SIZE_512M)
.long (CFG_PCI2_IO_PHYS>>12) & 0xfffff .long LAWAR_EN | LAWAR_TRGT_PCI2 | (LAWAR_SIZE & LAWAR_SIZE_1M)
.long (CFG_PCIE1_MEM_PHYS>>12) & 0xfffff .long LAWAR_EN | LAWAR_TRGT_PCIE | (LAWAR_SIZE & LAWAR_SIZE_512M)
.long (CFG_PCIE1_IO_PHYS>>12) & 0xfffff .long LAWAR_EN | LAWAR_TRGT_PCIE | (LAWAR_SIZE & LAWAR_SIZE_1M) 4: entry_end
Fun stuff, eh?
For sure ;-). Robert
robert lazarski wrote:
On 8/30/07, Ben Warren bwarren@qstreams.com wrote:
One other thing I just thought of - you need to make sure the Local Bus Access Windows are set properly. My chip has separate ones for DDR and for Local Bus, and yours may as well. The config file you sent has the LAWBAR for local bus set to 0x000c0000, when it should be 0xf8000000, I think. If this is set wrong, I don't think you'll be able to access the memory range. Info is in the 'System Configuration' section of your reference manual.
Which manual? I tried
The reference manual for your CPU. Probably has a Freescale part number of MPC8548ERM or something like that.
This part I'm having problems understanding. This is what I have for the config of MPC8548CDS board - what I'm using as a reference:
; Initialize LAWBAR's WM32 0xe0000C08 0x00000000 ;LAWBAR0 : @0x00000000 WM32 0xe0000C10 0x80f0001b ;LAWAR0 : DDR/SDRAM 256MB WM32 0xe0000C28 0x000c0000 ;LAWBAR1 : @0xc0000000 WM32 0xe0000C30 0x8040001d ;LAWAR1 : Local Bus 1GB
In what manual is this explained in, ie the 0xe0000 addresses? I can't seem to tie together the LAW's in my init.S and the LAW's here.
All internal registers are mapped according to a register named IMMRBAR, which typically is set to 0xe0000000 by the CPU bootstrap process, which is dictated by some other registers called Reset Configuration Words. So anything you see that begins with 0xe0000000 is an internal register. There's a chapter of the reference manual called, fittingly enough, 'Memory Map', that outlines all of these registers and cross references to other parts of the manual. The addresses shown in the memory map table are offsets from IMMRBAR. Confused yet?
/*
- LAW(Local Access Window) configuration:
- 0x0000_0000 0x7fff_ffff DDR 2G
- 0x8000_0000 0x9fff_ffff PCI1 MEM 512M
- 0xa000_0000 0xbfff_ffff PCIe MEM 512M
- 0xc000_0000 0xdfff_ffff PCI2 MEM 512M
- 0xe000_0000 0xe000_ffff CCSR 1M
- 0xe200_0000 0xe10f_ffff PCI1 IO 1M
- 0xe280_0000 0xe20f_ffff PCI2 IO 1M
- 0xe300_0000 0xe30f_ffff PCIe IO 1M
- 0xf800_0000 0xffff_ffff FLASH (boot bank) 128M
Looks like a nice memory partition according to function. You can see here that 1MB starting at 0xe0000000 is reserved for internal registers, and everything else is allocated for memory and busses.
- Notes:
- CCSRBAR and L2-as-SRAM don't need a configured Local Access Window.
- If flash is 8M at default position (last 8M), no LAW needed.
- LAW 0 is reserved for boot mapping
*/
At initial bootup, things are a bit different. Since the CPU has no inherent knowledge of what type of boot device you have, it initializes Chip Select 0 to the entire 4GB range, and likely LAW0 as well. That's probably what this refers to. Once you start hitting things with your BDI-2000 INIT section, this no longer applies.
I recommend you set LAW0 to cover 0xf8000000 to 0xffffffff (your 128MB flash) and don't set any of the other access windows. This should at least let you access the flash chip.
Well, that's enough fun for one day. Time to go home.
cheers, Ben
From: robert lazarski
Which manual? I tried
See Chapter 2. "Memory map" and "4.4.3.3 Boot ROM Location" in:
http://www.freescale.com/files/32bit/doc/ref_manual/MPC8548ERM.pdf
Without the BDI configuration, you get a 8M window to the boot device of your choice. This is controlled by three configuration pins.
You also get a 1M window into the configuration space at ff70_0000. This typically is moved to e000_0000 in u-boot.
-EdS
On 8/30/07, Swarthout Edward L-SWARTHOU ed.swarthout@freescale.com wrote:
From: robert lazarski
Which manual? I tried
See Chapter 2. "Memory map" and "4.4.3.3 Boot ROM Location" in:
http://www.freescale.com/files/32bit/doc/ref_manual/MPC8548ERM.pdf
Without the BDI configuration, you get a 8M window to the boot device of your choice. This is controlled by three configuration pins.
You also get a 1M window into the configuration space at ff70_0000. This typically is moved to e000_0000 in u-boot.
-EdS
Another day all, thanks for helping.
Here's what we don't understand about the manual and the CDS example in respect to our flash - both I and the hardware engineer are in doubt here. In Table 2-8. LAWARn we have for bits 8-11:
0000 PCI1/PCI-X 0001 PCI2 0010 PCI Express 0011 Reserved 0100 Local bus memory controller 0101–1011Reserved 1100 RapidIO 1101–1110Reserved 1111 DDR SDRAM
So what we see is that the CDS example is putting 1GB on the local bus - is this for the flash?
WM32 0xe0000C28 0x000c0000 ;LAWBAR0 : @0xc0000000 WM32 0xe0000C30 0x8040001d ;LAWAR0 : Local Bus 1GB
Do we have to assign a LAW to our flash in order to write to it? Ben suggested assigning a LAW from 0xf8000000 to 0xffffffff (our 128MB flash) . How would we go about doing that on the 8548 ? We tried:
WM32 0xe0000C08 0xF8000000 ;LAWBAR0 : @0xc0000000 WM32 0xe0000C10 0x8040001d ;LAWAR0 : Local Bus 1GB
atum>mdh 0xf8000000 # SAP: read access failed
Here's the current config we are trying to use, please help!
;bdiGDB configuration file for Atum's 8548A ;--------------------------------------------------- ; [INIT] ; ; use the following two lines for STARTUP HALT WSPR 63 0xffff0000 ;IVPR to boot core WSPR 415 0x0000f000 ;IVOR15 : Debug exception ; ; ;================= setup for flash programming =============== ; Move CCSRBAR to 0xe0000000 WM32 0xff700000 0x000e0000 ;CCSRBAR to 0xe0000000 ; ; Initialize LAWBAR's WM32 0xe0000C08 0x000c0000 ;LAWBAR1 : @0xc0000000 WM32 0xe0000C10 0x8040001d ;LAWAR1 : Local Bus 1GB ; ; Setup Flash chip select WM32 0xe0005000 0xf8001001 ;BR0 WM32 0xe0005004 0xf8006E65 ;OR0
; Enable flash programming WM16 0xfe000000 0x0060 ;clear flash lock-bits WM16 0xfe000000 0x00d0 DELAY 1000 WM16 0xfe000000 0xffff ;
;================= end flash programming ===================== ;
[TARGET] CPUTYPE 8548 ;the CPU type JTAGCLOCK 0 ;use 16 MHz JTAG clock ;STARTUP STOP 5000 ;let U-boot code setup the system STARTUP HALT ;halt core while HRESET is asserted BREAKMODE HARD ;SOFT or HARD, HARD uses PPC hardware breakpoint STEPMODE HWBP ;JTAG or HWBP, HWBP uses a hardware breakpoint WAKEUP 500 ;give reset time to complete POWERUP 5000 ;start delay after power-up detected in ms
[HOST] IP 10.101.43.10 FILE vmlinux.8548 FORMAT ELF LOAD MANUAL ;load code MANUAL or AUTO after reset DUMP dump PROMPT 3ep8548a>
[FLASH] CHIPTYPE MIRRORX16 ;S29GL01GP CHIPSIZE 0x8000000 ;The size of one flash chip in bytes - 1Gb BUSWIDTH 16 ;The width of the flash memory bus in bits (8 | 16 | 32) FILE u-boot.bin FORMAT BIN 0xF8000000 ERASE 0xF8000000 ;erase sector 0
[REGS] FILE $reg8548.def
participants (5)
-
Ben Warren -
Chris Fester -
robert lazarski -
Scott Wood -
Swarthout Edward L-SWARTHOU