[U-Boot-Users] BDI2000 problems flashing virgin custom 8548 board
robert lazarski
- 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
Ben Warren
> 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>
>
>
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
-------------------------------------------------------------------------
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...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Chris Fester
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
robert lazarski
> robert lazarski wrote:
> > atum8548>erase 00000000
> > # Writing to workspace failed
> >
> 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
Ben Warren
> On 8/29/07, Ben Warren <bwa...@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?
>
>
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
> the 17 least significant (from the left) bits
...more commonly known as the "most significant bits". :-P
-Scott
Ben Warren
> 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
>
>
B-)
Scott Wood
> 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
Ben Warren
> 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. :-)
>
robert lazarski
> robert lazarski wrote:
> > atum8548>erase 0
> > Erasing flash at 0x00000000
> > # Erasing flash memory failed
> >
> >
> >
> 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
Ben Warren
> On 8/29/07, Ben Warren <bwa...@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
>
>
> 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 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
>
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
robert lazarski
> robert lazarski wrote:
> > On 8/29/07, Ben Warren <bwa...@qstreams.com> wrote:
> >
> >> robert lazarski wrote:
> >>
> >>> atum8548>erase 0
> >>> Erasing flash at 0x00000000
> >>> # Erasing flash memory failed
> >>>
> >
> > some quick docs:
> >
> > http://www.spansion.com/products/S29GL01GP.html
> >
> >
> You're right. Sorry about that.
> >
> >
> 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
Ben Warren
> On 8/30/07, Ben Warren <bwa...@qstreams.com> wrote:
>
>> robert lazarski wrote:
>>
>>> On 8/29/07, Ben Warren <bwa...@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
>
>
mdh 0xf8000000 ?
regards,
Ben
robert lazarski
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
Ben Warren
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
robert lazarski
>
> 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
Ben Warren
> On 8/30/07, Ben Warren <bwa...@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
>
>
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.
>
>
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
> *
>
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
> */
>
>
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
Swarthout Edward L-SWARTHOU
>
> 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
robert lazarski
> 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