[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board

[robert lazarski]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: atum8548.cfg
Type: application/octet-stream
Size: 4145 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070829/1a1f5f06/attachment.obj 

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board

[Chris Fester]

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 at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board

[Ben Warren]

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

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board

[robert lazarski]

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

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board

[Ben Warren]

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

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board

[Scott Wood]

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

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board

[Ben Warren]

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-)

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board

[Scott Wood]

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

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board

[Ben Warren]

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....

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board

[robert lazarski]

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

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board

[Ben Warren]

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:
>
> http://www.spansion.com/products/S29GL01GP.html
>
>   
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

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board

[robert lazarski]

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:
> >
> > http://www.spansion.com/products/S29GL01GP.html
> >
> >
> 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

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board

[Ben Warren]

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:
>>>
>>> http://www.spansion.com/products/S29GL01GP.html
>>>
>>>
>>>       
>> 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

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board

[robert lazarski]

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

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board

[Ben Warren]

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

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board

[robert lazarski]

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

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board

[Ben Warren]

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

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548board

[Swarthout Edward L-SWARTHOU]

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

[U-Boot-Users] BDI2000 problems flashing virgin custom 8548board

[robert lazarski]

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