[U-Boot-Users] minimum bdi config to read flash on 85xx

[U-Boot-Users] minimum bdi config to read flash on 85xx

[robert lazarski]

Hi all,

On our custom 8548 board, we can't read our flash correctly. We have
one 1Gb bank of spansion S29GL01GP flash and we get:

atum>mdh 0xf8000000
0_f8000000 : f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7 f9f7

The big problem we have now: is this a hardware issue or a bdi config
issue? Aside from the flash we have 1GigaByte of DDR ram. Can anyone
help us track our flash issues down to be hardware, config file, or
some combination? The hardware guys think the board is fine. We've
been deep into the manuals of both the 8548 and the bdi and can't find
anything wrong. Here's the config, thanks for any help!

;bdiGDB configuration file for ATUM 8548
;---------------------------------------------------
;
[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      0x00000000      ;LAWBAR0 : @0x00000000
WM32    0xe0000C10      0x80f0001d      ;LAWAR0  : DDR 1GB
WM32    0xe0000C28      0xf8000000      ;LAWBAR1 : @0xf8000000
WM32    0xe0000C30      0x8040001a      ;LAWAR1  : Local Bus  128MB
for S29GL01GP
;
; Setup Flash chip select
WM32    0xe0005000      0xf8001001      ;BR0
WM32    0xe0005004      0xf8000E65      ;OR0

; CS0_BNDS
WM32 	0xe0002000 0x0000000f ; DDR CS0

; CS0_CONFIG
WM32 	0xe0002080 0x80000102

; TIMING_CFG_0
WM32	0xe0002104 0x00260802

; TIMING_CFG_1
WM32	0xe0002108 0x38355322

; TIMING_CFG_2
WM32	0xe000210C 0x039048c7

; DDR_SDRAM_MODE
WM32	0xe0002118 0x00000432

; DDR_SDRAM_INTERVAL
WM32	0xe0002124 0x05150100

; DDR_SDRAM_CFG2
WM32	0xe0002114 0x24000000

; DDR_SDRAM_CLK_CNTL
WM32	0xe0002130 0x03000000

DELAY 200

; enable the memory interface
; DDR_SDRAM_CFG
; enable the memory interface
WM32	0xe0002110 0xc3000000

;================= 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

[REGS]
FILE        $reg8548.def


[HOST]
IP          10.101.43.10
FILE        vmlinux.8548
FORMAT      ELF
LOAD        MANUAL      ;load code MANUAL or AUTO after reset
DUMP        e500.bin
PROMPT      atum>

[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

[U-Boot-Users] minimum bdi config to read flash on 85xx

[David Hawkins]

Hi Robert,

> The big problem we have now: is this a hardware issue or a bdi config
> issue? Aside from the flash we have 1GigaByte of DDR ram. Can anyone
> help us track our flash issues down to be hardware, config file, or
> some combination? The hardware guys think the board is fine.

Have you checked that the Flash is getting accessed?

I'm working with an 83xx based board, so the 85xx will
be slightly different, but here's what I'd look for.
When the processor boots, it reads a hardware configuration
word (HCW) that tells it where to boot from. The pin strapping
can be set to tell it to use Flash. Assuming the HCW
is read correctly, you should be able to see the
CE# line on the Flash assert when the processor boots.

So, assuming you convince yourself that the hardware
configuration words are being read, you should be able
to confirm that the Flash is being accessed after
reset.

You might have to try this with the JTAG/COP disconnected.

Cheers,
Dave

[U-Boot-Users] minimum bdi config to read flash on 85xx

[Ben Warren]

David Hawkins wrote:
> Hi Robert,
>
>   
>> The big problem we have now: is this a hardware issue or a bdi config
>> issue? Aside from the flash we have 1GigaByte of DDR ram. Can anyone
>> help us track our flash issues down to be hardware, config file, or
>> some combination? The hardware guys think the board is fine.
>>     
>
> Have you checked that the Flash is getting accessed?
>   
Very good point. I know you've made many changes since your initial 
setup Robert. Did any of them make the chip select strobe?
> I'm working with an 83xx based board, so the 85xx will
> be slightly different, but here's what I'd look for.
> When the processor boots, it reads a hardware configuration
> word (HCW) that tells it where to boot from. The pin strapping
> can be set to tell it to use Flash. Assuming the HCW
> is read correctly, you should be able to see the
> CE# line on the Flash assert when the processor boots.
>
>   
Also, on the 83xx you can set the RCW values directly from the BDI-2000, 
using an entry like the following in the TARGET section:

RCW 0x8060a000 0x04230000

This lets you set a lot of boot options. Maybe the 8548 can do this too?
> So, assuming you convince yourself that the hardware
> configuration words are being read, you should be able
> to confirm that the Flash is being accessed after
> reset.
>
> You might have to try this with the JTAG/COP disconnected.
>
> Cheers,
> Dave
>
>
> -------------------------------------------------------------------------
> 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] minimum bdi config to read flash on 85xx

[robert lazarski]

On 9/4/07, Ben Warren <bwarren@qstreams.com> wrote:
> David Hawkins wrote:
> > Hi Robert,
> >
> >
> >> The big problem we have now: is this a hardware issue or a bdi config
> >> issue? Aside from the flash we have 1GigaByte of DDR ram. Can anyone
> >> help us track our flash issues down to be hardware, config file, or
> >> some combination? The hardware guys think the board is fine.
> >>
> >
> > Have you checked that the Flash is getting accessed?
> >
> Very good point. I know you've made many changes since your initial
> setup Robert. Did any of them make the chip select strobe?

We now see the CE on the flash chip going from 3.3v to 0 on reset of
the 8548. We also see the same behavior when issuing a mdh command on
the bdi - however, we cannot see any activity whatsoever on the Ax
pins on the spansion flash chip when trying read via the bdi and mdh.

Getting deep into 8548, the "pin strapping" I believe is controlled by
the POR Boot Mode Status Register (PORBMSR) in "20.4.1.2" in:

http://www.freescale.com/files/32bit/doc/ref_manual/MPC8548ERM.pdf

Reading the register PORBMSR we get: 0x86370000 which I'm reading as:

1 0000 110 00 11 0 11 100 00000000000000

0         BCFG = 1 The CPU is allowed to start fetching boot code.
1-4      reserved
5-7      ROM_LOC = 110 Local bus GPCM:16-bit (our local bus is 16bit)
8-9      reserved
10-11   BSCFG = 11 Boot sequencer disabled
12       reserved
13-15   Host/agent = PCI1/PCI-X and Serial RapidIO agent mode
16-31   reserved.

Our flash is 128MB and we think we set the LAW correctly in the bdi
config file as F8000000 .  In 4.3.1.3 however, it defaults to FF80000
and says:

 "If translation is to be performed to a page outside the default boot
ROM address range defined in the MPC8548E (8 Mbytes at 0x0_FF80_0000
to 0x0_FFFF_FFFF as defined in Section 4.4.3.3, "Boot ROM Location"),
the external host or boot sequencer must then also set up a local
access window to define the routing of the boot code fetch to the
target interface that contains the boot code, because the BPTR defines
only the address
translation, not the target interface."

Perhaps we're not doing that right?

> > I'm working with an 83xx based board, so the 85xx will
> > be slightly different, but here's what I'd look for.
> > When the processor boots, it reads a hardware configuration
> > word (HCW) that tells it where to boot from. The pin strapping
> > can be set to tell it to use Flash. Assuming the HCW
> > is read correctly, you should be able to see the
> > CE# line on the Flash assert when the processor boots.
> >
> >
> Also, on the 83xx you can set the RCW values directly from the BDI-2000,
> using an entry like the following in the TARGET section:
>
> RCW 0x8060a000 0x04230000

I did see RCW while googling, but that appears not to be present on
the 85xx as I couldn't find it in the 85xx bdi manual or the freescale
manual. Anyone know the equivalent?

Thanks all!
Robert

[U-Boot-Users] minimum bdi config to read flash on 85xx

[Ben Warren]

robert lazarski wrote:
> On 9/4/07, Ben Warren <bwarren@qstreams.com> wrote:
>   
>> David Hawkins wrote:
>>     
>>> Hi Robert,
>>>
>>>
>>>       
>>>> The big problem we have now: is this a hardware issue or a bdi config
>>>> issue? Aside from the flash we have 1GigaByte of DDR ram. Can anyone
>>>> help us track our flash issues down to be hardware, config file, or
>>>> some combination? The hardware guys think the board is fine.
>>>>
>>>>         
>>> Have you checked that the Flash is getting accessed?
>>>
>>>       
>> Very good point. I know you've made many changes since your initial
>> setup Robert. Did any of them make the chip select strobe?
>>     
>
> We now see the CE on the flash chip going from 3.3v to 0 on reset of
> the 8548. We also see the same behavior when issuing a mdh command on
> the bdi - however, we cannot see any activity whatsoever on the Ax
> pins on the spansion flash chip when trying read via the bdi and mdh.
>
>   
That's cool. Getting closer... You don't see activity on any of the 
address pins? You of course remember the goofy way that PowerPC bits are 
reversed, right? (i.e. local bus A30 should be wired to A0 on the flash 
chip, since it's a 16-bit device, A29 to A1 etc.)
> Getting deep into 8548, the "pin strapping" I believe is controlled by
> the POR Boot Mode Status Register (PORBMSR) in "20.4.1.2" in:
>
> http://www.freescale.com/files/32bit/doc/ref_manual/MPC8548ERM.pdf
>
> Reading the register PORBMSR we get: 0x86370000 which I'm reading as:
>
> 1 0000 110 00 11 0 11 100 00000000000000
>
> 0         BCFG = 1 The CPU is allowed to start fetching boot code.
> 1-4      reserved
> 5-7      ROM_LOC = 110 Local bus GPCM:16-bit (our local bus is 16bit)
> 8-9      reserved
> 10-11   BSCFG = 11 Boot sequencer disabled
> 12       reserved
> 13-15   Host/agent = PCI1/PCI-X and Serial RapidIO agent mode
> 16-31   reserved.
>
> Our flash is 128MB and we think we set the LAW correctly in the bdi
> config file as F8000000 .  In 4.3.1.3 however, it defaults to FF80000
> and says:
>
>  "If translation is to be performed to a page outside the default boot
> ROM address range defined in the MPC8548E (8 Mbytes at 0x0_FF80_0000
> to 0x0_FFFF_FFFF as defined in Section 4.4.3.3, "Boot ROM Location"),
> the external host or boot sequencer must then also set up a local
> access window to define the routing of the boot code fetch to the
> target interface that contains the boot code, because the BPTR defines
> only the address
> translation, not the target interface."
>
> Perhaps we're not doing that right?
>   
More fun than a barrel of monkeys. Maybe you should just pretend your 
device is only 8MB for now.

regards,
Ben

[U-Boot-Users] minimum bdi config to read flash on 85xx

[David Hawkins]

> We now see the CE on the flash chip going from 3.3v to 0 on reset of
> the 8548. We also see the same behavior when issuing a mdh command on
> the bdi

Great. Thats encouraging :)

> however, we cannot see any activity whatsoever on the Ax
> pins on the spansion flash chip when trying read via the bdi and mdh.

What about when the processor boots?

 > http://www.freescale.com/files/32bit/doc/ref_manual/MPC8548ERM.pdf

p233 of the PDF:

   When the e500 core comes out of reset, its MMU has one 4-Kbyte
   page defined at 0x0_FFFF_Fnnn. The core begins execution with
   the instruction at effective address 0x0_FFFF_FFFC. To get this
   instruction, the core?s first instruction fetch is a burst read
   of boot code from effective address 0x0_FFFF_FFE0.

So the address bus LSBs should be changing during this burst,
whereas the MSBs would be high.

 > I did see RCW while googling, but that appears not to be present on
 > the 85xx as I couldn't find it in the 85xx bdi manual or the freescale
 > manual. Anyone know the equivalent?

It looks like the 85xx ditches the RCW method in favor of the
boot sequencer, which the 83xx also supports. As far as I understand
the processor comes out of reset, holds the core in reset, reads
register settings from an I2C EEPROM, programs the registers,
and then releases the core. Basically you can override any (some?)
default register settings.

p233 states:
   the default boot ROM address range defined in the MPC8548E
  (8 Mbytes at 0x0_FF80_0000 to 0x0_FFFF_FFFF

which is the same as one of the defaults for the MPC8349.

I'm pretty sure that you should be able to power up the processor,
and the BDI-2000 can play in this default address-space, i.e.,
accesses between 0xFF800000 and the end of 4GB space should
decode to the Flash.

Do you have a Freescale evaluation board for comparison tests?

Cheers,
Dave

[U-Boot-Users] minimum bdi config to read flash on 85xx

[robert lazarski]

On 9/4/07, David Hawkins <dwh@ovro.caltech.edu> wrote:
>
>
> > We now see the CE on the flash chip going from 3.3v to 0 on reset of
> > the 8548. We also see the same behavior when issuing a mdh command on
> > the bdi
>
> Great. Thats encouraging :)
>
> > however, we cannot see any activity whatsoever on the Ax
> > pins on the spansion flash chip when trying read via the bdi and mdh.
>
> What about when the processor boots?
>
>  > http://www.freescale.com/files/32bit/doc/ref_manual/MPC8548ERM.pdf
>
> p233 of the PDF:
>
>    When the e500 core comes out of reset, its MMU has one 4-Kbyte
>    page defined at 0x0_FFFF_Fnnn. The core begins execution with
>    the instruction at effective address 0x0_FFFF_FFFC. To get this
>    instruction, the core's first instruction fetch is a burst read
>    of boot code from effective address 0x0_FFFF_FFE0.
>
> So the address bus LSBs should be changing during this burst,
> whereas the MSBs would be high.

Excellent idea - can I please clarify it? On the spansion flash chip
we have LBA5 to LBA30 - where LBA30 is the LSB. On reset, should we be
seeing changes on these LSB's while the MSB's remain high?

>
>  > I did see RCW while googling, but that appears not to be present on
>  > the 85xx as I couldn't find it in the 85xx bdi manual or the freescale
>  > manual. Anyone know the equivalent?
>
> It looks like the 85xx ditches the RCW method in favor of the
> boot sequencer, which the 83xx also supports. As far as I understand
> the processor comes out of reset, holds the core in reset, reads
> register settings from an I2C EEPROM, programs the registers,
> and then releases the core. Basically you can override any (some?)
> default register settings.
>
> p233 states:
>    the default boot ROM address range defined in the MPC8548E
>   (8 Mbytes at 0x0_FF80_0000 to 0x0_FFFF_FFFF
>
> which is the same as one of the defaults for the MPC8349.
>
> I'm pretty sure that you should be able to power up the processor,
> and the BDI-2000 can play in this default address-space, i.e.,
> accesses between 0xFF800000 and the end of 4GB space should
> decode to the Flash.

We tried doing an mdh on 0xff800000 but still see bad data, even after setting:

WM32    0xe0005000      0xff801001      ;BR0
WM32    0xe0005004      0xff806e65      ;OR0

One more question please, since 83xx is the same here. What's the
register that needs to be changed to move the boot location from
FF800000 to F8000000 ? I've been getting deep into the boot sequencer
and PORBMSR, but I'm having a hard time determining what and where to
change the boot location address. We don't have an I2C eeprom, but the
hardware guys tell me we can strap the pins to set the register once
we know which one it is.

>
> Do you have a Freescale evaluation board for comparison tests?
>

Freescale lent us the EP8548, though the CDS is a closer fit and we
don't have it. We'll be comparing the pins of the EP8548 and our board
today.

> Cheers,
> Dave
>
>

Thanks again all!
Robert

[U-Boot-Users] minimum bdi config to read flash on 85xx

[David Hawkins]

Hi Robert,

>>> however, we cannot see any activity whatsoever on the Ax
>>> pins on the spansion flash chip when trying read via the bdi and mdh.
>> What about when the processor boots?
>>
>>  > http://www.freescale.com/files/32bit/doc/ref_manual/MPC8548ERM.pdf
>>
>> p233 of the PDF:
>>
>>    When the e500 core comes out of reset, its MMU has one 4-Kbyte
>>    page defined at 0x0_FFFF_Fnnn. The core begins execution with
>>    the instruction at effective address 0x0_FFFF_FFFC. To get this
>>    instruction, the core's first instruction fetch is a burst read
>>    of boot code from effective address 0x0_FFFF_FFE0.
>>
>> So the address bus LSBs should be changing during this burst,
>> whereas the MSBs would be high.
> 
> Excellent idea - can I please clarify it? On the spansion flash chip
> we have LBA5 to LBA30 - where LBA30 is the LSB. On reset, should we be
> seeing changes on these LSB's while the MSB's remain high?

Here's some notes I wrote a while back

http://www.ovro.caltech.edu/~dwh/powerpc_mpc8349e.pdf

Figure 5, p33, shows LA[27:31] toggling during boot from Flash.
Note that the asynchronous memory interface (GPCM) changes
address pins LA[27:31] during byte-wise access *not* the
LAD[27:31] multiplexed address/data bus that. So if the
board design connects up the wrong pins to the Flash,
it won't work. In your case, since you talk about LBA30
as being your LSB, it sound like you have 16-bit Flash.
The same comment applies though; LA[27:30] are the bits
that should be connected to the Flash for booting.

 From the block diagram in Ch 13 of the 8548 reference manual,
it looks like the local bus controller setup is the same.

Note: if your Flash is connected to the wrong address pins,
it might be possible using the boot sequencer to change the
boot address to a UPM controlled area, and then use the
UPM to read the flash. But of course that requires having
the I2C EEPROM on the board to enable the boot sequencer.

>> I'm pretty sure that you should be able to power up the processor,
>> and the BDI-2000 can play in this default address-space, i.e.,
>> accesses between 0xFF800000 and the end of 4GB space should
>> decode to the Flash.
> 
> We tried doing an mdh on 0xff800000 but still see bad data, even after setting:

But the Flash chip-select asserts, OE# asserts, and data is driven
out of the Flash? How about the address pins?

> WM32    0xe0005000      0xff801001      ;BR0
> WM32    0xe0005004      0xff806e65      ;OR0

Yeah, I wouldn't both changing registers until you get the
default state working.

> One more question please, since 83xx is the same here. What's the
> register that needs to be changed to move the boot location from
> FF800000 to F8000000 ? I've been getting deep into the boot sequencer
> and PORBMSR, but I'm having a hard time determining what and where to
> change the boot location address. We don't have an I2C eeprom, but the
> hardware guys tell me we can strap the pins to set the register once
> we know which one it is.

If your hardware guy knows of the pin strapping, then he should
know the register setting :)

p233 says that it is the boot sequencer that can be used to
change the boot address.

However, I wouldn't bother with trying to change the boot address
until you've got the flash working.

Any particular reason you want to change the address range?
It really isn't that important what the memory map is during
boot versus running u-boot. For example, the 83xx u-boot
code first used the high-boot address, and then switched to
low-boot (which is nice as it puts the boot code at the
start of Flash). The Flash itself can be viewed after boot
at a user-defined address. See the document notes at the
link above.

Cheers,
Dave

[U-Boot-Users] minimum bdi config to read flash on 85xx

[robert lazarski]

On 9/5/07, David Hawkins <dwh@ovro.caltech.edu> wrote:
> Hi Robert,
>
> >> p233 of the PDF:
> >>
> >>    When the e500 core comes out of reset, its MMU has one 4-Kbyte
> >>    page defined at 0x0_FFFF_Fnnn. The core begins execution with
> >>    the instruction at effective address 0x0_FFFF_FFFC. To get this
> >>    instruction, the core's first instruction fetch is a burst read
> >>    of boot code from effective address 0x0_FFFF_FFE0.
> >>
> >> So the address bus LSBs should be changing during this burst,
> >> whereas the MSBs would be high.
> >
> > Excellent idea - can I please clarify it? On the spansion flash chip
> > we have LBA5 to LBA30 - where LBA30 is the LSB. On reset, should we be
> > seeing changes on these LSB's while the MSB's remain high?
>
> Here's some notes I wrote a while back
>
> http://www.ovro.caltech.edu/~dwh/powerpc_mpc8349e.pdf
>
> Figure 5, p33, shows LA[27:31] toggling during boot from Flash.
> Note that the asynchronous memory interface (GPCM) changes
> address pins LA[27:31] during byte-wise access *not* the
> LAD[27:31] multiplexed address/data bus that. So if the
> board design connects up the wrong pins to the Flash,
> it won't work. In your case, since you talk about LBA30
> as being your LSB, it sound like you have 16-bit Flash.
> The same comment applies though; LA[27:30] are the bits
> that should be connected to the Flash for booting.

Bingo! Excellent notes as it seems to describe our exact problem. The
way you describe it must be done - using pins LA[27:30] in our case -
is _not_ how our board is. It was that way in the prototype phase but
had a spurious signal on the bus so the hardware guys say. So it was
changed to the way you say it can't be done - via LAD[27:30]
multiplexed address/data bus.

>
>  From the block diagram in Ch 13 of the 8548 reference manual,
> it looks like the local bus controller setup is the same.
>
> Note: if your Flash is connected to the wrong address pins,
> it might be possible using the boot sequencer to change the
> boot address to a UPM controlled area, and then use the
> UPM to read the flash. But of course that requires having
> the I2C EEPROM on the board to enable the boot sequencer.
>

We don't have an I2C EEPROM , so its jumper wire time.

>
> > One more question please, since 83xx is the same here. What's the
> > register that needs to be changed to move the boot location from
> > FF800000 to F8000000 ? I've been getting deep into the boot sequencer
> > and PORBMSR, but I'm having a hard time determining what and where to
> > change the boot location address. We don't have an I2C eeprom, but the
> > hardware guys tell me we can strap the pins to set the register once
> > we know which one it is.
>
> However, I wouldn't bother with trying to change the boot address
> until you've got the flash working.
>
> Any particular reason you want to change the address range?
> It really isn't that important what the memory map is during
> boot versus running u-boot. For example, the 83xx u-boot
> code first used the high-boot address, and then switched to
> low-boot (which is nice as it puts the boot code at the
> start of Flash). The Flash itself can be viewed after boot
> at a user-defined address. See the document notes at the
> link above.
>

This is really a side issue now, but since I asked it I might as well
finish up on it. The two 8548 boards I've looked at - EP8548 and CDS -
both have 8MB of flash starting at FF800000. What relation does that
have to the 8548 boot rom location of FF800000 ? Since I have 128MB of
flash starting at F8000000 in my or0 / br0 registers and LAW's in my
u-boot code, do I not need to change the boot rom location? Does this
effect the location to load the u-boot.bin file, 0xFFF80000 in the two
8548 examples?

Thanks a bunch!
Robert

[U-Boot-Users] minimum bdi config to read flash on 85xx

[David Hawkins]

Hi Robert,

>> Here's some notes I wrote a while back
>>
>> http://www.ovro.caltech.edu/~dwh/powerpc_mpc8349e.pdf
>>
>> Figure 5, p33, shows LA[27:31] toggling during boot from Flash.
>> Note that the asynchronous memory interface (GPCM) changes
>> address pins LA[27:31] during byte-wise access *not* the
>> LAD[27:31] multiplexed address/data bus that. So if the
>> board design connects up the wrong pins to the Flash,
>> it won't work. In your case, since you talk about LBA30
>> as being your LSB, it sound like you have 16-bit Flash.
>> The same comment applies though; LA[27:30] are the bits
>> that should be connected to the Flash for booting.
> 
> Bingo! Excellent notes as it seems to describe our exact problem. The
> way you describe it must be done - using pins LA[27:30] in our case -
> is _not_ how our board is. It was that way in the prototype phase but
> had a spurious signal on the bus so the hardware guys say. So it was
> changed to the way you say it can't be done - via LAD[27:30]
> multiplexed address/data bus.

I'm glad we've found your problem, but I'm sorry to hear
the cause. Life now becomes more difficult for you :(

>> Note: if your Flash is connected to the wrong address pins,
>> it might be possible using the boot sequencer to change the
>> boot address to a UPM controlled area, and then use the
>> UPM to read the flash. But of course that requires having
>> the I2C EEPROM on the board to enable the boot sequencer.
>>
> We don't have an I2C EEPROM, so its jumper wire time.

Its worth trying. My assumption would be that if you use
the I2C boot sequencer to setup the boot address (however that
is done), and then setup the memory controller that decodes
that address to trigger the use of a UPM, where the UPM is
setup correctly to read the Flash, then it will boot
correctly. Of course I've never done this, or heard of a
board that does it, so let us know how you go :)

> This is really a side issue now, but since I asked it I might as well
> finish up on it. The two 8548 boards I've looked at - EP8548 and CDS -
> both have 8MB of flash starting at FF800000. What relation does that
> have to the 8548 boot rom location of FF800000 ?

Read the explanation on p31 for the 83xx
http://www.ovro.caltech.edu/~dwh/powerpc_mpc8349e.pdf

The thing to get your head around is that (for an 83xx);

On reset the processor setups up a basic memory map
where the processor boots from either 0xFFF00100 or
0x00000100, i.e., it boots from 1MB lower than the
highest 32-bit address or it boots from address 0.

The processor sets up an 8MB memory window that decodes to
that Flash, eg. 0xFF800000 is the default base address
of that Flash, or 0x0000000 is the default.
(Assuming of course the config words say to boot from
local bus flash).

When you have an 8MB flash, either boot base-address works
fine. However, when you have a larger flash, high-boot
requires the boot code reside about 8MB into your Flash.
Thats a bummer, as it splits your useable Flash in two,
so using low-boot works nicer.

Regardless of which boot method is used, once u-boot code
runs, it sets up the decode region for the flash to be
whereever it wants to be. In some boards, I am sure the
Flash just gets left where it is, with perhaps the memory
window being opened wider if there was a larger flash.
In that case, the u-boot code for a high-boot image would
still be found about 8MB into that decode region (for
high-boot).

Basically, shortly after the processor boots you setup the
memory map as you'd like to see it.

 > Since I have 128MB of
 > flash starting at F8000000 in my or0 / br0 registers and LAW's in my
 > u-boot code, do I not need to change the boot rom location? Does this
 > effect the location to load the u-boot.bin file, 0xFFF80000 in the two
 > 8548 examples?

It depends :)

If your processor boot sequence depended on the default FF800000
window, and high-booted, then u-boot would live about 8MB into
your 128MB Flash, and without changing the or0/br0, you'd only
see the lower 8MB of the Flash. U-Boot would be linked with the
FF800000 base address (or whatever U-boot needs regarding addresses).
Once U-boot executes, and I think has setup the DDR and moved
over to run from DDR, its no longer executing from Flash, so the
location of the Flash can be moved. In that case, you'd change
the base address to be F8000000 and viola, you can access all
128MB.

If however you use the I2C boot sequencer to setup the 128MB
flash as 128MB starting at F8000000, and boot that way, the
u-boot image will sit about 1MB from the end of the 128MB
Flash, not 8MB from the start of the flash. However, the processor
reset vector, and hence u-boot code, will execute from FFFF0100
in either case.

I haven't looked at the 85xx manual in enough detail to see if
all this applies, but thats the basics :)

If you can get the 85xx to boot from 00000000, then it won't
matter if you setup an 8MB window or 128MB window, just so long
as the window starts at address 00000000 after reset. Then you
can move it to F8000000 after boot. Then you'll only have code
at the start of Flash, not starting 8MB into it (or 1MB from
the end).

Cheers,
Dave

[U-Boot-Users] minimum bdi config to read flash on 85xx

[Luiz Neto]

Hi David,

This is Luiz and I'm working with Robert in this project. Actually, I'm a
hardware guy. I read your messages and it seems you're right. However,
before introducing these changes on the board, we decided to verify all
flash circuitry and we noticed the following:

CE# is OK!
WE# is OK!
OE# is OK!

We verified it using a scope and triggering CE# pin. After that, we tried to
write to flash through BDI2000 using "mm" command. Again with a scope we
checked each address line and apparently everything is fine with the
address. We also checked the data being written, and it's ok too. After
that, in order to validate the written, we read the same address we had just
written. But we got a different value. Therefore we are not writing
correctly to flash.

Ok, after all, we fixed our board following your tips. We connected
LA[27:30] to A[3:0] and A[4:25] to LBA[26:5]. But we got the same bad
result. I mean we read a wrong data.

After, we changed flash access time, decreasing it. And the problem
persisted. We changed flash chip and nothing happened.

Actually I'm afraid because I can't see what else we can verify on hardware.

My opinion is we have mistakes on configuration file. I'm not sure if we are
configuring all registers correctly.

Do you think it would be helpful if I send you our flash schematic and our
configuration file?

Thanks in advance!
Luiz.

2007/9/5, David Hawkins <dwh@ovro.caltech.edu>:
>
> Hi Robert,
>
> >> Here's some notes I wrote a while back
> >>
> >> http://www.ovro.caltech.edu/~dwh/powerpc_mpc8349e.pdf
> >>
> >> Figure 5, p33, shows LA[27:31] toggling during boot from Flash.
> >> Note that the asynchronous memory interface (GPCM) changes
> >> address pins LA[27:31] during byte-wise access *not* the
> >> LAD[27:31] multiplexed address/data bus that. So if the
> >> board design connects up the wrong pins to the Flash,
> >> it won't work. In your case, since you talk about LBA30
> >> as being your LSB, it sound like you have 16-bit Flash.
> >> The same comment applies though; LA[27:30] are the bits
> >> that should be connected to the Flash for booting.
> >
> > Bingo! Excellent notes as it seems to describe our exact problem. The
> > way you describe it must be done - using pins LA[27:30] in our case -
> > is _not_ how our board is. It was that way in the prototype phase but
> > had a spurious signal on the bus so the hardware guys say. So it was
> > changed to the way you say it can't be done - via LAD[27:30]
> > multiplexed address/data bus.
>
> I'm glad we've found your problem, but I'm sorry to hear
> the cause. Life now becomes more difficult for you :(
>
> >> Note: if your Flash is connected to the wrong address pins,
> >> it might be possible using the boot sequencer to change the
> >> boot address to a UPM controlled area, and then use the
> >> UPM to read the flash. But of course that requires having
> >> the I2C EEPROM on the board to enable the boot sequencer.
> >>
> > We don't have an I2C EEPROM, so its jumper wire time.
>
> Its worth trying. My assumption would be that if you use
> the I2C boot sequencer to setup the boot address (however that
> is done), and then setup the memory controller that decodes
> that address to trigger the use of a UPM, where the UPM is
> setup correctly to read the Flash, then it will boot
> correctly. Of course I've never done this, or heard of a
> board that does it, so let us know how you go :)
>
> > This is really a side issue now, but since I asked it I might as well
> > finish up on it. The two 8548 boards I've looked at - EP8548 and CDS -
> > both have 8MB of flash starting at FF800000. What relation does that
> > have to the 8548 boot rom location of FF800000 ?
>
> Read the explanation on p31 for the 83xx
> http://www.ovro.caltech.edu/~dwh/powerpc_mpc8349e.pdf
>
> The thing to get your head around is that (for an 83xx);
>
> On reset the processor setups up a basic memory map
> where the processor boots from either 0xFFF00100 or
> 0x00000100, i.e., it boots from 1MB lower than the
> highest 32-bit address or it boots from address 0.
>
> The processor sets up an 8MB memory window that decodes to
> that Flash, eg. 0xFF800000 is the default base address
> of that Flash, or 0x0000000 is the default.
> (Assuming of course the config words say to boot from
> local bus flash).
>
> When you have an 8MB flash, either boot base-address works
> fine. However, when you have a larger flash, high-boot
> requires the boot code reside about 8MB into your Flash.
> Thats a bummer, as it splits your useable Flash in two,
> so using low-boot works nicer.
>
> Regardless of which boot method is used, once u-boot code
> runs, it sets up the decode region for the flash to be
> whereever it wants to be. In some boards, I am sure the
> Flash just gets left where it is, with perhaps the memory
> window being opened wider if there was a larger flash.
> In that case, the u-boot code for a high-boot image would
> still be found about 8MB into that decode region (for
> high-boot).
>
> Basically, shortly after the processor boots you setup the
> memory map as you'd like to see it.
>
> > Since I have 128MB of
> > flash starting at F8000000 in my or0 / br0 registers and LAW's in my
> > u-boot code, do I not need to change the boot rom location? Does this
> > effect the location to load the u-boot.bin file, 0xFFF80000 in the two
> > 8548 examples?
>
> It depends :)
>
> If your processor boot sequence depended on the default FF800000
> window, and high-booted, then u-boot would live about 8MB into
> your 128MB Flash, and without changing the or0/br0, you'd only
> see the lower 8MB of the Flash. U-Boot would be linked with the
> FF800000 base address (or whatever U-boot needs regarding addresses).
> Once U-boot executes, and I think has setup the DDR and moved
> over to run from DDR, its no longer executing from Flash, so the
> location of the Flash can be moved. In that case, you'd change
> the base address to be F8000000 and viola, you can access all
> 128MB.
>
> If however you use the I2C boot sequencer to setup the 128MB
> flash as 128MB starting at F8000000, and boot that way, the
> u-boot image will sit about 1MB from the end of the 128MB
> Flash, not 8MB from the start of the flash. However, the processor
> reset vector, and hence u-boot code, will execute from FFFF0100
> in either case.
>
> I haven't looked at the 85xx manual in enough detail to see if
> all this applies, but thats the basics :)
>
> If you can get the 85xx to boot from 00000000, then it won't
> matter if you setup an 8MB window or 128MB window, just so long
> as the window starts at address 00000000 after reset. Then you
> can move it to F8000000 after boot. Then you'll only have code
> at the start of Flash, not starting 8MB into it (or 1MB from
> the end).
>
> Cheers,
> Dave
>
>
>
>
>
> -------------------------------------------------------------------------
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20070906/d300d4bf/attachment.htm 

[U-Boot-Users] minimum bdi config to read flash on 85xx

[Ben Warren]

Hi Luiz,

Luiz Neto wrote:
>
> Hi David,
>
> This is Luiz and I'm working with Robert in this project. Actually, 
> I'm a hardware guy. I read your messages and it seems you're right. 
> However, before introducing these changes on the board, we decided to 
> verify all flash circuitry and we noticed the following:
>
> CE# is OK!
> WE# is OK!
> OE# is OK!
>
> We verified it using a scope and triggering CE# pin. After that, we 
> tried to write to flash through BDI2000 using "mm" command. Again with 
> a scope we checked each address line and apparently everything is fine 
> with the address. We also checked the data being written, and it's ok 
> too. After that, in order to validate the written, we read the same 
> address we had just written. But we got a different value. Therefore 
> we are not writing correctly to flash.
>
> Ok, after all, we fixed our board following your tips. We connected 
> LA[27:30] to A[3:0] and A[4:25] to LBA[26:5]. But we got the same bad 
> result. I mean we read a wrong data.
>
> After, we changed flash access time, decreasing it. And the problem 
> persisted. We changed flash chip and nothing happened.
>
> Actually I'm afraid because I can't see what else we can verify on 
> hardware.
>
> My opinion is we have mistakes on configuration file. I'm not sure if 
> we are configuring all registers correctly.
>
> Do you think it would be helpful if I send you our flash schematic and 
> our configuration file?
>
> Thanks in advance!
> Luiz.
>
I'm not sure if this has been mentioned or not.  You should be able to 
read/write the flash from the BDI-2000, regardless of whether you 
connect the LA or LBA address bits.  The difference comes into play when 
you want to boot from the flash chip.  During the very early boot 
process, only the special LSbits toggle.  On one spin of our board we 
missed this as well, and had to do some funny business with an I2C 
EEPROM to boot the board.  Thankfully it was easy with our CPU (MPC8349) 
because it only involved programming a couple of configuration words and 
no UPM programming like Dave H. has suggested.  It looks like it may not 
be as simple for you. :-(

If you're able to white-wire the LA bits, that's cool because ultimately 
you'll need that to boot the board.  You're right that something else is 
screwy.

Have you tried asking Freescale for help through their website?  I've 
found their tech support in these matters to be responsive and useful.  
You can send me your schematic & config if you want, although I can't 
guarantee to be of much use.

regards,
Ben

[U-Boot-Users] minimum bdi config to read flash on 85xx

[David Hawkins]

Hi Luiz,

> This is Luiz and I'm working with Robert in this  project.

Glad to hear he's got someone to grow grey hairs
with ... if it hasn't fallen out yet.

> Actually, I'm a hardware guy.

So am I ... this week :)

> I read your messages and it seems you're right. However, 
> before introducing these changes on the board, we decided
> to verify all flash circuitry and we noticed the following:
> 
> CE# is OK!
> WE# is OK!
> OE# is OK!
> 
> We verified it using a scope and triggering CE# pin. After that, we 
> tried to write to flash through BDI2000 using "mm" command. Again with a 
> scope we checked each address line and apparently everything is fine 
> with the address.

I think that after the processor boots LAD[0:31] activate
for each address access, its only during boot that LAD[27:31]
do not toggle, and you have to use LA[27:31]. So its
that confirmation of the address toggles in this case just
confirms that the LAD[27:31] bits toggle.

On the bright-side, it sounds like you have the bit
ordering correct ([27:30])... just not the right bits
(LAD vs LA).

> We also checked the data being written, and it's ok 
> too. After that, in order to validate the written, we read the same 
> address we had just written. But we got a different value. Therefore we 
> are not writing correctly to flash.

Have you tried using simple CFI flash commands;
read the manufacturer ID, read the device ID,
read the sector protection? Don't bother with
BDI Flash commands just yet, just use memory
read/write commands.

> Ok, after all, we fixed our board following your tips.
> We connected LA[27:30] to A[3:0] and A[4:25] to LBA[26:5].
> But we got the same bad result. I mean we read a wrong data.
> 
> After, we changed flash access time, decreasing it. And the
> problem persisted. We changed flash chip and nothing happened.
> 
> Actually I'm afraid because I can't see what else we can verify
> on hardware.
> 
> My opinion is we have mistakes on configuration file. I'm not sure if we 
> are configuring all registers correctly.
> 
> Do you think it would be helpful if I send you our flash schematic and 
> our configuration file?

Sure, no guarantees, you can send me a copy, or send
a link to the group. I'm not too knowledgeable on BDI
config files yet, as I don't have my custom hardware.
However, I have looked at a few hardware designs, so
perhaps I'll spot something on the schematic. The
peripherals seem to be pretty similar between the
PowerQUICCs, so I'll dig up a working configuration
file, and look at the difference in register settings.

What is your Flash? Eg. if its say a Spansion device,
do you have WP# tied high, BYTE# tied low/high, etc?
Are there any address pins left floating?

Do you have a logic analyzer available? If you did,
you'd be able to look at the flash controls and write-data
and convince yourself that your Flash programming
sequence was correct.

The best advice at the moment, is to access your Flash
configuration using manual read/write sequences.

Cheers,
Dave

[U-Boot-Users] minimum bdi config to read flash on 85xx

[David Hawkins]

Hi Ben,

> I'm not sure if this has been mentioned or not. 
> You should be able to read/write the flash from
> the BDI-2000, regardless of whether you connect
> the LA or LBA address bits.  The difference comes
> into play when you want to boot from the flash chip.
> During the very early boot process, only the special
> LSbits toggle.

Yeah, I'd read that in some corner of the processor
reference manual, and fired up the MDS board with a
logic analyzer just to confirm it. I wondered at the
time how many people would miss that subtle requirement!

> On one spin of our board we missed this as well, and
> had to do some funny business with an I2C EEPROM to boot
> the board.  Thankfully it was easy with our CPU (MPC8349) 
> because it only involved programming a couple of
> configuration words and no UPM programming like Dave H.
> has suggested.

Ah-ha, so it is possible - cool :)

(crossed fingers it won't happen to me though ...)

> Have you tried asking Freescale for help through their
> website?  I've found their tech support in these matters
> to be responsive and useful.  

Yep, I second that. Freescale's design support is
great. Sometimes they confirm what you don't want to
hear ... but they do respond quickly :)

Cheers,
Dave

[U-Boot-Users] minimum bdi config to read flash on 85xx

[Clemens Koller]

Hi there!

Luiz Neto schrieb:
> My opinion is we have mistakes on configuration file. I'm not sure if we 
> are configuring all registers correctly.
> 
> Do you think it would be helpful if I send you our flash schematic and 
> our configuration file?

I'm working with the MPC8540 doing lots of hardware stuff with flash
and fpga on the local bus. I think I cannot help you much with the
config file but I can compare your schematics with the stuff we have
in house, if you want.

Regards,
-- 
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm-technology.com
Phone: +49-89-741518-50
Fax: +49-89-741518-19

[U-Boot-Users] minimum bdi config to read flash on 85xx

[Luiz Neto]

Hi David/Ben/Clemens,

First of all, thanks for helping us!!! You are amazing guys!

Yes, we want to boot from flash. But firstly, we want to validate our
hardware :)

So, let me see if I understood you synchronizing some points:

1- In order to validate my flash circuitry, I don't need LA pins. I'm able
to validate it using just simple FCI commands. Am I right?

I'm not familiar with these command. Probably Robert knows it. But he is out
of the office until tuesday. Can you please give some examples?

2- LA pins are necessary just in case I want to boot from flash. Is it?

3- Our flash is a S29GL01GP MirrorBit. I'm send you our flash schematic and
datasheet. There you can see that WP# is tied high, BYTE# is tied high,
RESET# is high (a FPGA controls this pin) and that there is no address pin
floating.

Thanks in advance!
Luiz


2007/9/6, David Hawkins <dwh@ovro.caltech.edu>:
>
> Hi Luiz,
>
> > This is Luiz and I'm working with Robert in this  project.
>
> Glad to hear he's got someone to grow grey hairs
> with ... if it hasn't fallen out yet.
>
> > Actually, I'm a hardware guy.
>
> So am I ... this week :)
>
> > I read your messages and it seems you're right. However,
> > before introducing these changes on the board, we decided
> > to verify all flash circuitry and we noticed the following:
> >
> > CE# is OK!
> > WE# is OK!
> > OE# is OK!
> >
> > We verified it using a scope and triggering CE# pin. After that, we
> > tried to write to flash through BDI2000 using "mm" command. Again with a
> > scope we checked each address line and apparently everything is fine
> > with the address.
>
> I think that after the processor boots LAD[0:31] activate
> for each address access, its only during boot that LAD[27:31]
> do not toggle, and you have to use LA[27:31]. So its
> that confirmation of the address toggles in this case just
> confirms that the LAD[27:31] bits toggle.
>
> On the bright-side, it sounds like you have the bit
> ordering correct ([27:30])... just not the right bits
> (LAD vs LA).
>
> > We also checked the data being written, and it's ok
> > too. After that, in order to validate the written, we read the same
> > address we had just written. But we got a different value. Therefore we
> > are not writing correctly to flash.
>
> Have you tried using simple CFI flash commands;
> read the manufacturer ID, read the device ID,
> read the sector protection? Don't bother with
> BDI Flash commands just yet, just use memory
> read/write commands.
>
> > Ok, after all, we fixed our board following your tips.
> > We connected LA[27:30] to A[3:0] and A[4:25] to LBA[26:5].
> > But we got the same bad result. I mean we read a wrong data.
> >
> > After, we changed flash access time, decreasing it. And the
> > problem persisted. We changed flash chip and nothing happened.
> >
> > Actually I'm afraid because I can't see what else we can verify
> > on hardware.
> >
> > My opinion is we have mistakes on configuration file. I'm not sure if we
> > are configuring all registers correctly.
> >
> > Do you think it would be helpful if I send you our flash schematic and
> > our configuration file?
>
> Sure, no guarantees, you can send me a copy, or send
> a link to the group. I'm not too knowledgeable on BDI
> config files yet, as I don't have my custom hardware.
> However, I have looked at a few hardware designs, so
> perhaps I'll spot something on the schematic. The
> peripherals seem to be pretty similar between the
> PowerQUICCs, so I'll dig up a working configuration
> file, and look at the difference in register settings.
>
> What is your Flash? Eg. if its say a Spansion device,
> do you have WP# tied high, BYTE# tied low/high, etc?
> Are there any address pins left floating?
>
> Do you have a logic analyzer available? If you did,
> you'd be able to look at the flash controls and write-data
> and convince yourself that your Flash programming
> sequence was correct.
>
> The best advice at the moment, is to access your Flash
> configuration using manual read/write sequences.
>
> Cheers,
> Dave
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20070906/4fa29ba1/attachment.htm 

[U-Boot-Users] minimum bdi config to read flash on 85xx

[David Hawkins]

Hi Luiz,

> First of all, thanks for helping us!!! You are amazing guys!

There is a saying 'what goes around, comes around ...'.

So by helping you now, I hope someone helps me later :)

> Yes, we want to boot from flash. But firstly, we want to
> validate our  hardware :)

Always helps to walk before running :)

> So, let me see if I understood you synchronizing some points:
> 
> 1- In order to validate my flash circuitry, I don't need LA pins. I'm 
> able to validate it using just simple FCI commands. Am I right?

Yes.

0. Scope out the pins and check the chip-select and write
    pulse timing matches that specified by the Flash.

1. Try reading the manufacturer info.

> I'm not familiar with these command. Probably Robert knows it. But he is 
> out of the office until tuesday. Can you please give some examples?

Its in the data sheet. See comments below.

> 2- LA pins are necessary just in case I want to boot from flash. Is it?

Yes. LA[27:31] need to be connected to the boot Flash.

> 3- Our flash is a S29GL01GP MirrorBit. I'm send you our flash schematic 
> and datasheet. There you can see that WP# is tied high, BYTE# is tied 
> high, RESET# is high (a FPGA controls this pin) and that there is no 
> address pin floating.

Ok. I plan to use the same part.

Download the data sheet; eg. I seem to have a copy called
s29gl-p_00_a5_e.pdf

Look near the end of the document for the 'Memory Array Command
Definitions' table, x16.

Eg. to read the manufacturer ID perform the following sequence,
where wm.b means write memory byte, but you'll need to replace
this with the BDI2000 equivalent, which I can't recall at the
moment :) (and the 0x might be optional too). The point is
this will help you understand how to use the table:

  wm.b 0x555 0xAA
  wm.b 0x2AA 0x55
  wm.b 0x555 0x90
  wm.b 0x000 0x01

and then read say 8 bytes from the flash

  md.b 8

Somewhere in the data sheet it'll tell you what the Spansion
manufacturer ID is supposed to be.

The 0x555 0xAA 0x2AA 0x55 is called the unlock sequence,
the remaining bytes are then command codes.

If you get the low-level routines to give you valid results,
then you can try higher-level Flash commands to see where
you get differing results.

You can use this method to program Flash bytes too.

Cheers,
Dave

[U-Boot-Users] minimum bdi config to read flash on 85xx

[David Hawkins]

Hi Luiz,

> I've just noticed that I've forgotten to send you files
> regarding flash circuitry.

What is the file format; *.schdoc?

Just send a PDF version of the schematic,
that'll be easier to read. No need to send
it to everyone on the u-boot list. Since the
board currently doesn't work, its not like
anyone will want to copy it ;)

Just send a copy to the few people who indicated
they'd take a look.

> David, I'll follow your recommendations and report
> you later.

The data sheet you sent in the zip file has the
command table on p66 for the x16 interface.

Cheers,
Dave

[U-Boot-Users] minimum bdi config to read flash on 85xx

[robert lazarski]

On 9/6/07, David Hawkins <dwh@ovro.caltech.edu> wrote:

> Eg. to read the manufacturer ID perform the following sequence,
> where wm.b means write memory byte, but you'll need to replace
> this with the BDI2000 equivalent, which I can't recall at the
> moment :) (and the 0x might be optional too). The point is
> this will help you understand how to use the table:
>
>   wm.b 0x555 0xAA
>   wm.b 0x2AA 0x55
>   wm.b 0x555 0x90
>   wm.b 0x000 0x01
>
> and then read say 8 bytes from the flash
>
>   md.b 8
>
> Somewhere in the data sheet it'll tell you what the Spansion
> manufacturer ID is supposed to be.
>
> The 0x555 0xAA 0x2AA 0x55 is called the unlock sequence,
> the remaining bytes are then command codes.

Thanks all for the help so far. I'm going to jump back in the
discussion at this part in the thread. We ran out of S29GL01GP chips
so we temporarily moved to the S29GL512P 64MB chip, with a chip size
of 4000000. The good news is after jumpering the board to the correct
addresses we can do a "mdf 0xfc000000" and get all F's . We can also
do a "erase 0xfc000000 CHIP" and the command completes successfully.

When we do a "prog 0xfc000000 uboot.bin bin" however, we get
""Programming flash memory failed" . Our questions at this point are:

1) If we can do an erase as shown above does that mean our unlocking
sequence has been performed correctly?

What's confusing us here is that the "0x555 0xAA 0x2AA 0x55" sequence
seems to be the same for our current S29GL512P, the S29GL01GP, Ben's
S29GL064M, and the MPC8548CDS chip , the AM29LV641D. Maybe some CFI
standard thing? Anyways. Ben's sequence and an example I found for the
CDS board is this:

; Enable flash programming
WM16 0xfe000000 0x0060 ;clear flash lock-bits
WM16 0xfe000000 0x00d0
DELAY 1000
WM16 0xfe000000 0xffff

In our case 0xfe000000 becomes 0xfc000000.  We found a 8540ads with
the same code.  In the 8548cds case they seem to use the equivalent
for 0xFF800000 with WM32. In all these examples where not sure where
these addresses come from as they don't seem to be clearly from the
respective manuals.

We also can execute the unlock command successfully, with this entry
in our config files:

ERASE 0xFc000000 CHIP; Erase whole Chip

2) Any other ideas on why we can read and erase but not write our flash?

Thanks all, been quite a ride but I think we're almost ready to get
into debugging our u-boot code.

Robert

[U-Boot-Users] minimum bdi config to read flash on 85xx

[David Hawkins]

Hi Robert,

> Thanks all for the help so far. I'm going to jump back in the
> discussion at this part in the thread. We ran out of S29GL01GP chips
> so we temporarily moved to the S29GL512P 64MB chip, with a chip size
> of 4000000. The good news is after jumpering the board to the correct
> addresses we can do a "mdf 0xfc000000" and get all F's . We can also
> do a "erase 0xfc000000 CHIP" and the command completes successfully.
> 
> When we do a "prog 0xfc000000 uboot.bin bin" however, we get
> ""Programming flash memory failed" . Our questions at this point are:

Before assuming an address that reads 0xFFFFFFFF is really
your flash, you did double-check that the Flash CE# and OE#
signals are active for those accesses correct?

> 1) If we can do an erase as shown above does that mean our unlocking
> sequence has been performed correctly?

As I have commented before; if you're unsure, *do it manually*,
read the manufacturer ID first, and sector protection, or
whatever.

> What's confusing us here is that the "0x555 0xAA 0x2AA 0x55" sequence
> seems to be the same for our current S29GL512P, the S29GL01GP, Ben's
> S29GL064M, and the MPC8548CDS chip , the AM29LV641D. Maybe some CFI
> standard thing?

Don't be confused; read the data sheet :)

Yes, its a CFI thing. However, non-CFI JEDEC flash has something
similar.

> Anyways. Ben's sequence and an example I found for the
> CDS board is this:
> 
> ; Enable flash programming
> WM16 0xfe000000 0x0060 ;clear flash lock-bits
> WM16 0xfe000000 0x00d0
> DELAY 1000
> WM16 0xfe000000 0xffff

I don't see an unlock sequence here though. Perhaps there
is an unlock-bypass command earlier on.

> In our case 0xfe000000 becomes 0xfc000000.  We found a 8540ads with
> the same code.  In the 8548cds case they seem to use the equivalent
> for 0xFF800000 with WM32. In all these examples where not sure where
> these addresses come from as they don't seem to be clearly from the
> respective manuals.

I explained earlier the fact that the processor starts off
with a default memory map that you can then override.
So 0xFF800000 is the default map with an 8MB window at
the top of memory, while 0xFE000000 is a 32MB window setup
by writes to the local bus registers (OR/BR or whatever
they're called).

> We also can execute the unlock command successfully, with this entry
> in our config files:
> 
> ERASE 0xFc000000 CHIP; Erase whole Chip

If the chip started out with 0xFFFFFFFF, then you can't
really say you've had success :)

> 2) Any other ideas on why we can read and erase but not write our flash?
> 
> Thanks all, been quite a ride but I think we're almost ready to get
> into debugging our u-boot code.

Go back to basics first;

1. Confirm that accesses to the addresses you believe the
    Flash are located generate CE# and OE#

    (I'm sure you did this, but you didn't re-state it)

2. Use memory commands to read the manufacturer ID

3. Use memory commands to write a word

4. Use memory commands to erase that sector

5. Repeat 3

6. Use memory commands to erase the chip

Then try the software equivalents.
Then try programming U-boot.

Cheers,
Dave

[U-Boot-Users] minimum bdi config to read flash on 85xx

[Jerry Van Baren]

David Hawkins wrote:
> Hi Robert,

[snip]

> Go back to basics first;
> 
> 1. Confirm that accesses to the addresses you believe the
>     Flash are located generate CE# and OE#
> 
>     (I'm sure you did this, but you didn't re-state it)

David missed three steps here:
   2. Read the flash data sheets, especially the command interface
   3. ReRead the flash data sheets, especially the command interface
   4. ReReRead the flash data sheets, especially the command interface

Robert's statement "Maybe some CFI standard thing?" betrays him.

If you (Robert) don't understand what those 0x55 and 0xAA magic numbers 
are, and especially if you don't understand how your hardware is wired 
up (one chip, two chips, four chips, 8x wide, 16x wide, 32x wide - note 
this is a lot of possible combinations), any success will be pure luck.

> 5. Use memory commands to read the manufacturer ID
> 
> 6. Use memory commands to write a word
> 
> 7. Use memory commands to erase that sector
> 
> 8. Repeat ****2****
> 
> 9. Use memory commands to erase the chip
> 
> Then try the software equivalents.
> Then try programming U-boot.
> 
> Cheers,
> Dave

Good luck, ;-)
gvb

[U-Boot-Users] minimum bdi config to read flash on 85xx

[David Hawkins]

Hi Jerry,

> David missed three steps here:
>   2. Read the flash data sheets, especially the command interface
>   3. ReRead the flash data sheets, especially the command interface
>   4. ReReRead the flash data sheets, especially the command interface
> 
> Robert's statement "Maybe some CFI standard thing?" betrays him.

Yeah, I guess I was being too kind.

Thanks for having my back Jerry.

:)

[U-Boot-Users] minimum bdi config to read flash on 85xx

[David Hawkins]

One other thing:

>> Then try the software equivalents.
>> Then try programming U-boot.

Don't even bother trying to boot U-boot until you
know your SDRAM is setup correctly.

But thats another set of data sheets, and processor
reference manual chapters ....

:)

[U-Boot-Users] minimum bdi config to read flash on 85xx

[Jerry Van Baren]

David Hawkins wrote:
> 
> One other thing:
> 
>>> Then try the software equivalents.
>>> Then try programming U-boot.
> 
> Don't even bother trying to boot U-boot until you
> know your SDRAM is setup correctly.
> 
> But thats another set of data sheets, and processor
> reference manual chapters ....
> 
> :)

Should we tell him how much simpler flash configuration is than SDRAM?

Designated curmudgeon of the day,  ;-)
gvb

[U-Boot-Users] minimum bdi config to read flash on 85xx

[David Hawkins]

> Should we tell him how much simpler flash configuration is than SDRAM?

Again, I was trying to be kind ;)

[U-Boot-Users] minimum bdi config to read flash on 85xx

[robert lazarski]

On 9/12/07, David Hawkins <dwh@ovro.caltech.edu> wrote:
>
> > Should we tell him how much simpler flash configuration is than SDRAM?
>
> Again, I was trying to be kind ;)
>

OK guys I have a sense of humour and you all have indeed been very
kind in your help. Everyone was a newbie at one point of course. David
has already identified a hardware problem for us in which we are quite
grateful. I've been reading almost every patch and email on this list
for several months trying to understand it all. All I can do in return
is say thanks and supply patches once we finally get our board up.
That and help those like myself someday - which I do often on the
topics I know something about.

In the meantime we'll be spending quality with our manuals. We have OE
and CE toggling on our erase, mm, and prog commands but we cannot read
the values we write with mm. We cannot read the manufactorer id on
oxfc000000. Beyond that the magic numbers are for the first and second
unlock cycles and for autoselect, we cannot understand why bdi configs
use 0x0600 and 0x00d0 for their magic numbers - which are not the same
magic numbers in the manuals best as we can tell. We tried writing the
same magic numbers in the manuals directly via the bdi to seemingly no
effect.

That all being said, our knowledge is slowly getting there - and it
would have exponentially slower without the help so far.

Cheers,
Robert

[U-Boot-Users] minimum bdi config to read flash on 85xx

[David Hawkins]

Hi Robert,

> OK guys I have a sense of humour

Its a pre-requisite; that, and tough skin ;)

> In the meantime we'll be spending quality with our
> manuals. We have OE and CE toggling on our erase, mm,
> and prog commands

Thats definitely a good start.

> but we cannot read the values we write with mm.

Were you able to connect a logic analyzer to the bus
to confirm bus values versus processor values?

> We cannot read the manufactorer id on 0xfc000000.

0xFC00_0000 is 64MB from the end of memory.
If accesses to this address generate Flash CE# and OE#,
then next I would check the timing.

Don't move onto anything until you can read the
manufacturer ID, you've found a problem, so you
need to figure it out here first.

> Beyond that the magic numbers are for the first and second
> unlock cycles and for autoselect, we cannot understand why
> bdi configs use 0x0600 and 0x00d0 for their magic
> numbers - which are not the same magic numbers in the
> manuals best as we can tell.

It depends on how the Flash is wired. As far as data
wires go, Flash[15:0] can connect to Processor[15:0]
or Processor[0:15]. Whatever the processor writes,
it'll read back.

However, the Flash command codes expect the bit pattern
as defined in the command codes table on Flash[15:0].

So you've got lots of board specific cases;

  * bits reversed
  * bytes swapped
  * bits in bytes reversed

and so on ...

If the command code was 0x0006, and the BDI config you
copied shows 0x0600, then they've got bytes swapped.
If the code was 0x0060, and the bus is reversed
then you'll get 0x0600.

When you copy someone elses design without understanding
it, you can end up copying their mistakes.

In your case, you hooked up your Flash correctly, but
you're trying to interpret someone else's design in
the context of your design.

Rather than that, just look at the data sheets and
your specific design. You've gained an understanding
of what the BDI configuration file should contain,
now toss away anyone elses configs ... or look at them
with a 'grain of salt'.

Cheers,
Dave



> We tried writing the
> same magic numbers in the manuals directly via the bdi to seemingly no
> effect.
> 
> That all being said, our knowledge is slowly getting there - and it
> would have exponentially slower without the help so far.
> 
> Cheers,
> Robert
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] minimum bdi config to read flash on 85xx

[Jerry Van Baren]

David Hawkins wrote:
> Hi Robert,
> 
>> OK guys I have a sense of humour
> 
> Its a pre-requisite; that, and tough skin ;)

[snip]

>> Beyond that the magic numbers are for the first and second
>> unlock cycles and for autoselect, we cannot understand why
>> bdi configs use 0x0600 and 0x00d0 for their magic
>> numbers - which are not the same magic numbers in the
>> manuals best as we can tell.
> 
> It depends on how the Flash is wired. As far as data
> wires go, Flash[15:0] can connect to Processor[15:0]
> or Processor[0:15]. Whatever the processor writes,
> it'll read back.
> 
> However, the Flash command codes expect the bit pattern
> as defined in the command codes table on Flash[15:0].
> 
> So you've got lots of board specific cases;
> 
>   * bits reversed
>   * bytes swapped
>   * bits in bytes reversed
> 
> and so on ...
> 
> If the command code was 0x0006, and the BDI config you
> copied shows 0x0600, then they've got bytes swapped.
> If the code was 0x0060, and the bus is reversed
> then you'll get 0x0600.
> 
> When you copy someone elses design without understanding
> it, you can end up copying their mistakes.
> 
> In your case, you hooked up your Flash correctly, but
> you're trying to interpret someone else's design in
> the context of your design.
> 
> Rather than that, just look at the data sheets and
> your specific design. You've gained an understanding
> of what the BDI configuration file should contain,
> now toss away anyone elses configs ... or look at them
> with a 'grain of salt'.
> 
> Cheers,
> Dave

I have limited CFI experience, but my flash experience is that the flash 
chips ignore extra bytes in the data lanes when you send commands. 
Assuming your flash isn't bit-swapped, you should be able to write the 
magic bytes down all four byte lanes and have it work for byte-wide, 
16-bit-wide, and 32-bit-wide chips or paralleled 8-bit or 16-bit wide 
chips.  This neatly solves the byte swap issue as well.

The other critical part is the address you use.  Depending on the width 
of your chip(s) and if more than one paralleled on the bus, you will 
have to add zero "0" bits to the magic 55 / AA addresses in the manual.

For the translation of byte-wide to 16 bit wide:
55 (0101_0101) becomes 0AA (0_1010_1010)
AA (1010_1010) becomes 254 (1_0101_0100)
                                       ^ added '0' bit

For the translation of byte-wide to 32 bit wide:
55 (0101_0101) becomes 154 (01_0101_0100)
AA (1010_1010) becomes 2A8 (10_1010_1000)
                                       ^^ two added '0' bits

Best regards,
gvb

[U-Boot-Users] minimum bdi config to read flash on 85xx

[David Hawkins]

Hi Jerry,

> I have limited CFI experience, but my flash experience is that the flash 
> chips ignore extra bytes in the data lanes when you send commands. 
> Assuming your flash isn't bit-swapped, you should be able to write the 
> magic bytes down all four byte lanes and have it work for byte-wide, 
> 16-bit-wide, and 32-bit-wide chips or paralleled 8-bit or 16-bit wide 
> chips.  This neatly solves the byte swap issue as well.

Nice to know, thanks.

> The other critical part is the address you use.  Depending on the width 
> of your chip(s) and if more than one paralleled on the bus, you will 
> have to add zero "0" bits to the magic 55 / AA addresses in the manual.
> 
> For the translation of byte-wide to 16 bit wide:
> 55 (0101_0101) becomes 0AA (0_1010_1010)
> AA (1010_1010) becomes 254 (1_0101_0100)
>                                       ^ added '0' bit
> 
> For the translation of byte-wide to 32 bit wide:
> 55 (0101_0101) becomes 154 (01_0101_0100)
> AA (1010_1010) becomes 2A8 (10_1010_1000)
>                                       ^^ two added '0' bits

Ooh, thats a sneaky one.

I think (hope) the Spansion chips are 'smarter' than that.
They have a BYTE# pin that configures it to operate
in 8-bit (low) versus 16-bit (high), and in byte mode
DQ15 become A-1 (address bit minus -1). I'm pretty sure
the Spansion data sheet describes the commands in terms
of byte addresses, so there is no ambiguity of byte
versus 'word' (which has so many meanings ...) addresses
in the command codes.

Robert has correctly connected the Flash address and data
signals, so he shouldn't have to massage the address/data
relative to the data sheet command codes.

I'm pretty sure the Altera FPGA boards that I ran some tests
on used Spansion Flash, and I didn't have to shift the
address part of the Flash command.

Nice info though, thanks.
Dave

[U-Boot-Users] minimum bdi config to read flash on 85xx

[Jerry Van Baren]

David Hawkins wrote:
> Hi Jerry,
> 
>> I have limited CFI experience, but my flash experience is that the 
>> flash chips ignore extra bytes in the data lanes when you send 
>> commands. Assuming your flash isn't bit-swapped, you should be able to 
>> write the magic bytes down all four byte lanes and have it work for 
>> byte-wide, 16-bit-wide, and 32-bit-wide chips or paralleled 8-bit or 
>> 16-bit wide chips.  This neatly solves the byte swap issue as well.
> 
> Nice to know, thanks.
> 
>> The other critical part is the address you use.  Depending on the 
>> width of your chip(s) and if more than one paralleled on the bus, you 
>> will have to add zero "0" bits to the magic 55 / AA addresses in the 
>> manual.
>>
>> For the translation of byte-wide to 16 bit wide:
>> 55 (0101_0101) becomes 0AA (0_1010_1010)
>> AA (1010_1010) becomes 254 (1_0101_0100)
>>                                       ^ added '0' bit
>>
>> For the translation of byte-wide to 32 bit wide:
>> 55 (0101_0101) becomes 154 (01_0101_0100)
>> AA (1010_1010) becomes 2A8 (10_1010_1000)
>>                                       ^^ two added '0' bits
> 
> Ooh, thats a sneaky one.
> 
> I think (hope) the Spansion chips are 'smarter' than that.
> They have a BYTE# pin that configures it to operate
> in 8-bit (low) versus 16-bit (high), and in byte mode
> DQ15 become A-1 (address bit minus -1). I'm pretty sure
> the Spansion data sheet describes the commands in terms
> of byte addresses, so there is no ambiguity of byte
> versus 'word' (which has so many meanings ...) addresses
> in the command codes.
> 
> Robert has correctly connected the Flash address and data
> signals, so he shouldn't have to massage the address/data
> relative to the data sheet command codes.
> 
> I'm pretty sure the Altera FPGA boards that I ran some tests
> on used Spansion Flash, and I didn't have to shift the
> address part of the Flash command.
> 
> Nice info though, thanks.
> Dave

The address shifting happens when the hardware guys put down (2) 8-bit 
flash chips to be 16 bits wide, (4) 8-bit flash chips to be 32 bits 
wide, or (2) 16-bit flash chips to be 32 bits wide.  Size, timing, 
availability, and cost reasons usually drive this (and the first three 
are weighted very low).

Back when we had to subtract two '1' bits to make '0's, flashes 
(actully, EEPROMs to really show my age) only came in 8 bit wide 
packages so the address shifting phenomena happened quite often.

gvb

[U-Boot-Users] minimum bdi config to read flash on 85xx

[David Hawkins]

Hi Jerry,

> The address shifting happens when the hardware guys put down (2) 8-bit 
> flash chips to be 16 bits wide, (4) 8-bit flash chips to be 32 bits 
> wide, or (2) 16-bit flash chips to be 32 bits wide.  Size, timing, 
> availability, and cost reasons usually drive this (and the first three 
> are weighted very low).

Ah, I see.

> Back when we had to subtract two '1' bits to make '0's, flashes 
> (actully, EEPROMs to really show my age)

Apparently age and 'curmudgeonliness' go well together

http://www.m-w.com/cgi-bin/dictionary?va=curmudgeon


;)

[U-Boot-Users] minimum bdi config to read flash on 85xx

[robert lazarski]

On 9/12/07, David Hawkins <dwh@ovro.caltech.edu> wrote:
>
> Don't move onto anything until you can read the
> manufacturer ID, you've found a problem, so you
> need to figure it out here first.

After a few days with the docs, we've had some limited success. We
moved back to 128MB of ram and a base address of F8000000 . We think
we may have some timimg issues. To read the manufactor id the docs
say:

*( (UINT16 *)base_addr + 0x555 ) = 0x00AA; /* write unlock cycle 1 */
*( (UINT16 *)base_addr + 0x2AA ) = 0x0055; /* write unlock cycle 2 */
*( (UINT16 *)base_addr + 0x555 ) = 0x0090; /* write autoselect command */
manuf_id = *( (UINT16 *)base_addr + 0x000 ); /* read manuf. id */

So in our case we start with LAD30, so we need to do a shift left:

AAA = 555 << 1;
554 = 2AA << 1;

In the bdi, we executed:

ATUM>mmh 0xf8000AAA 0x00AA
ATUM>mmh 0xf8000554 0x0055
ATUM>mmh 0xf8000AAA 0x0090
ATUM>mmh 0xf8000AAA 0x0090
ATUM>mdh 0xf8000000 1

At which point we got the manufactor id and everything else.
Unfortunately the next day we weren't able to repeat it - can the
manufactor id be erased?

Anyways, we were able to write a word:

ATUM>mmh 0xf8000AAA 0x00AA
ATUM>mmh 0xf8000554 0x0055
ATUM>mmh 0xf8000AAA 0x00A0
ATUM>mmh 0xf8000F00 0xCAFE
ATUM>mdh 0xf8000F00 1
0_f8000f00 : 0xcafe  -13570

We have yet to be able to repeat that feat at any other address. We
can read 0xCAFE from 0xf8000F00 , but only after about a minute after
a bdi boot. We cannot overwrite 0xf8000F00 , nor can we erase the
entire chip via the documented sequence. As I said we think we have
timing issues. Any suggestions? More RTFM? We do have a logic
analyzer.

Thanks all,
Robert

[U-Boot-Users] minimum bdi config to read flash on 85xx

[Jerry Van Baren]

robert lazarski wrote:
> On 9/12/07, David Hawkins <dwh@ovro.caltech.edu> wrote:
>> Don't move onto anything until you can read the
>> manufacturer ID, you've found a problem, so you
>> need to figure it out here first.
> 
> After a few days with the docs, we've had some limited success. We
> moved back to 128MB of ram and a base address of F8000000 . We think
> we may have some timimg issues.

Interaction with RAM size is unexpected.  Time to quadruple check your 
OR/BR?  Read out the registers directly with the BDI, don't trust nobody.

[snip]

> In the bdi, we executed:
> 
> ATUM>mmh 0xf8000AAA 0x00AA
> ATUM>mmh 0xf8000554 0x0055
> ATUM>mmh 0xf8000AAA 0x0090
> ATUM>mmh 0xf8000AAA 0x0090
> ATUM>mdh 0xf8000000 1
> 
> At which point we got the manufactor id and everything else.
> Unfortunately the next day we weren't able to repeat it - can the
> manufactor id be erased?

Whoo-heee!

No, the manufacture ID cannot be erased.  Something odd is happening.

> Anyways, we were able to write a word:
> 
> ATUM>mmh 0xf8000AAA 0x00AA
> ATUM>mmh 0xf8000554 0x0055
> ATUM>mmh 0xf8000AAA 0x00A0
> ATUM>mmh 0xf8000F00 0xCAFE
> ATUM>mdh 0xf8000F00 1
> 0_f8000f00 : 0xcafe  -13570

Whoo-heee!

> We have yet to be able to repeat that feat at any other address. We
> can read 0xCAFE from 0xf8000F00 , but only after about a minute after
> a bdi boot. We cannot overwrite 0xf8000F00 , nor can we erase the
> entire chip via the documented sequence. As I said we think we have
> timing issues. Any suggestions? More RTFM? We do have a logic
> analyzer.

* Works only after waiting a minute?  That's odd.  Does your flash have 
a reset pin?  Do you have a buffer (address or data) between the 
processor and flash with an enable pin?  Are the reset/enables connected 
properly (not floating)?

* Detune (set to maximum delays) all the speed parameters in the BR/OR 
that controls flash.

* Use the logic analyzer to measure timing (tough nowadays with BGAs and 
fine traces).

gvb

[U-Boot-Users] minimum bdi config to read flash on 85xx

[Ben Warren]

robert lazarski wrote:
> On 9/12/07, David Hawkins <dwh@ovro.caltech.edu> wrote:
>   
>> Don't move onto anything until you can read the
>> manufacturer ID, you've found a problem, so you
>> need to figure it out here first.
>>     
<snip>
> We have yet to be able to repeat that feat at any other address. We
> can read 0xCAFE from 0xf8000F00 , but only after about a minute after
> a bdi boot. We cannot overwrite 0xf8000F00 , nor can we erase the
> entire chip via the documented sequence. As I said we think we have
> timing issues. Any suggestions? More RTFM? We do have a logic
> analyzer.
>   
Nice progress! Since you have a logic analyzer, you should definitely 
get a sense of the timing, which may or may not reveal anything. You 
have this chip select really slowed down, and it's asynchronous, so 
something would have to really be out of whack.

I'd be more tempted to look elsewhere. What else do you have on the 
local bus? Are other devices isolated via buffers in the same way that 
the Freescale eval boards are? Is the flash VCC looking good? Is the 
reset signal solid?

regards,
Ben

[U-Boot-Users] minimum bdi config to read flash on 85xx

[David Hawkins]

Hi Robert,

> After a few days with the docs, we've had some limited success. We
> moved back to 128MB of ram and a base address of F8000000 . We think
> we may have some timimg issues. To read the manufactor id the docs
> say:
> 
> *( (UINT16 *)base_addr + 0x555 ) = 0x00AA; /* write unlock cycle 1 */
> *( (UINT16 *)base_addr + 0x2AA ) = 0x0055; /* write unlock cycle 2 */
> *( (UINT16 *)base_addr + 0x555 ) = 0x0090; /* write autoselect command */
> manuf_id = *( (UINT16 *)base_addr + 0x000 ); /* read manuf. id */
> 
> So in our case we start with LAD30, so we need to do a shift left:
> 
> AAA = 555 << 1;
> 554 = 2AA << 1;

Do you really? I would have thought that the address code
was a byte-address, and therefore invariant for this part.
In 16-bit mode the device doesn't see the last bit.
Double-check :)

> In the bdi, we executed:
> 
> ATUM>mmh 0xf8000AAA 0x00AA
> ATUM>mmh 0xf8000554 0x0055
> ATUM>mmh 0xf8000AAA 0x0090
> ATUM>mmh 0xf8000AAA 0x0090
> ATUM>mdh 0xf8000000 1
> 
> At which point we got the manufactor id and everything else.
> Unfortunately the next day we weren't able to repeat it - can the
> manufactor id be erased?

Perhaps the first time you forgot to do the shift and
got it right.

Other things:

1. An oscilloscope probe should be used to checkout waveforms

2. Check the part number. Some parts use VCC=3.3V, and
    VCCIO that can be lower than 3.3V. Perhaps someone
    loaded a lower voltage part and you've damaged it.

Cheers,
Dave

[U-Boot-Users] minimum bdi config to read flash on 85xx

[robert lazarski]

On 9/14/07, David Hawkins <dwh@ovro.caltech.edu> wrote:
> Hi Robert,
>
> > After a few days with the docs, we've had some limited success. We
> > moved back to 128MB of ram and a base address of F8000000 . We think
> > we may have some timimg issues. To read the manufactor id the docs
> > say:
> >
> > *( (UINT16 *)base_addr + 0x555 ) = 0x00AA; /* write unlock cycle 1 */
> > *( (UINT16 *)base_addr + 0x2AA ) = 0x0055; /* write unlock cycle 2 */
> > *( (UINT16 *)base_addr + 0x555 ) = 0x0090; /* write autoselect command */
> > manuf_id = *( (UINT16 *)base_addr + 0x000 ); /* read manuf. id */
> >
> > So in our case we start with LAD30, so we need to do a shift left:
> >
> > AAA = 555 << 1;
> > 554 = 2AA << 1;
>
> Do you really? I would have thought that the address code
> was a byte-address, and therefore invariant for this part.
> In 16-bit mode the device doesn't see the last bit.
> Double-check :)
>

OK guys, its working!!!! YEAH!!!! Last problem turned out to be an
open resistor / bad solder joint on the address bus! We can now erase
the flash chip entirely. I also did the prog command to upload
uboot.bin and can see the uboot version at the base address - so this
stage is now completed!!!! Thanks so much for all the help guys, I
doubt we would have gotten so far without this community and we are
most grateful! I feel so much smarter now ;-) .

Last question before I get into my code finally - and I'll start a new
thread when I start debugging: The bdi docs in the uboot manual seem
to stop at the 'go' command. When I type 'info' I get a running state.
Can I now just power on and attach a terminal via the serial port to
get the uboot shell? To get to that point is the next dragon to slay?

Thanks!!!
Robert

[U-Boot-Users] minimum bdi config to read flash on 85xx

[Ben Warren]

robert lazarski wrote:
<snip>
> OK guys, its working!!!! YEAH!!!! Last problem turned out to be an
> open resistor / bad solder joint on the address bus! We can now erase
> the flash chip entirely. I also did the prog command to upload
> uboot.bin and can see the uboot version at the base address - so this
> stage is now completed!!!! Thanks so much for all the help guys, I
> doubt we would have gotten so far without this community and we are
> most grateful! I feel so much smarter now ;-) .
>
> Last question before I get into my code finally - and I'll start a new
> thread when I start debugging: The bdi docs in the uboot manual seem
> to stop at the 'go' command. When I type 'info' I get a running state.
> Can I now just power on and attach a terminal via the serial port to
> get the uboot shell? To get to that point is the next dragon to slay?
>
> Thanks!!!
> Robert
>   
Congratulations! Now you're equipped to help the next guy/girl.

Hook up your serial cable and with any luck you'll get something!

regards,
Ben

[U-Boot-Users] minimum bdi config to read flash on 85xx

[Jerry Van Baren]

robert lazarski wrote:

[snip]

> OK guys, its working!!!! YEAH!!!! Last problem turned out to be an
> open resistor / bad solder joint on the address bus! We can now erase
> the flash chip entirely. I also did the prog command to upload
> uboot.bin and can see the uboot version at the base address - so this
> stage is now completed!!!! Thanks so much for all the help guys, I
> doubt we would have gotten so far without this community and we are
> most grateful! I feel so much smarter now ;-) .

As do we all. ;-)

> Last question before I get into my code finally - and I'll start a new
> thread when I start debugging: The bdi docs in the uboot manual seem
> to stop at the 'go' command. When I type 'info' I get a running state.
> Can I now just power on and attach a terminal via the serial port to
> get the uboot shell? To get to that point is the next dragon to slay?

Yes.  With the BDI attached you have to type "go" to go (or reset / go 
to start fresh).  With it disconnected, you should be able to simply 
shoot the juice.

Either way, you should have characters coming out the serial port.  If 
you don't it is time to start setting *hardware* breakpoints in the code 
to see how far you are getting.  Note that the BDI can do lots of soft 
breakpoints or a limited (1+) number of hardware breakpoints.  When you 
are executing out of flash, you *must* use hardware breakpoints 
(software breakpoints overwrite the target instruction with a trap, 
which only works in RAM).

> Thanks!!!
> Robert

You are most welcome!!!
gvb

[U-Boot-Users] minimum bdi config to read flash on 85xx

[David Hawkins]

Hi Robert,

> OK guys, its working!!!! YEAH!!!! Last problem turned out to be an
> open resistor / bad solder joint on the address bus! 

This raises another debugging rule:

  'one is never enough'

=> Have multiple copies of the same hardware.

And then Murphy's Law comes into play:

  'the first one you debug will be the bad one'

=> Every damn time too ;)

Glad to hear you've got passed that problem.
Dave

[U-Boot-Users] minimum bdi config to read flash on 85xx

[Leon Woestenberg]

Hello,

On 9/14/07, Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com> wrote:
> robert lazarski wrote:
>
> > OK guys, its working!!!! YEAH!!!! Last problem turned out to be an
>
OK, now, here at our labs we have two rules:

1) when you smoke your hardware, you treat the lab with
candy/icecream/cookies/...
2) when a board-bring-up is succesfull, you treat the lab with
candy/icecream/cookies/...

Regards,
-- 
Leon Woestenberg.

(I think the software guys made the rules up)

[U-Boot-Users] minimum bdi config to read flash on 85xx

[Scott Mann]

--- Jerry Van Baren
<gerald.vanbaren@smiths-aerospace.com> wrote:

> robert lazarski wrote:
> 
> [snip]
> 
> > OK guys, its working!!!! YEAH!!!! Last problem
> turned out to be an
> > open resistor / bad solder joint on the address
> bus! We can now erase
> > the flash chip entirely. I also did the prog
> command to upload
> > uboot.bin and can see the uboot version at the
> base address - so this
> > stage is now completed!!!! Thanks so much for all
> the help guys, I
> > doubt we would have gotten so far without this
> community and we are
> > most grateful! I feel so much smarter now ;-) .
> 
> As do we all. ;-)
> 
> > Last question before I get into my code finally -
> and I'll start a new
> > thread when I start debugging: The bdi docs in the
> uboot manual seem
> > to stop at the 'go' command. When I type 'info' I
> get a running state.

Just a couple hints that may be useful for your next
steps...

If you didn't already know, you can type halt in the
BDI console when you are in a running state and get
whatever is running (e.g., U-Boot) suspended. This 
is handy when you are looking
at lots of debug output in the U-Boot console (you'll
get there ;-)

Also, you can attach gdb through the BDI if you don't
have an extra serial port (you can set up kgdb through
U-Boot via a second serial interface). This has been
real handy for me.

Glad to see you've gotten this far! Continued good
luck.


   -Scott

<snip>

[U-Boot] minimum bdi config to read flash on 85xx

[Monica]

We are using BDI3000 to Burn u-boot.bin to Flash memory. The flash we are
using is Spansion S29GL512S. 

As per the flash datasheet we tried programming 4 bytes( using telnet mmb
command) write buffer programming cycle. We succeeded. 

But when we tried programming a binary file ( u-boot.bin) ,it was failing.
Even though the log shows Flash programming passed but in the location when
we do a mdh there is no u-boot data.

Please find the log captured below.

IMX6#0>
- TARGET: processing reset request
- TARGET: BDI executes scan chain init string
IMX6#0>
IMX6#0>
- TARGET: Bypass check 0x00000001 => 0x00000004
- TARGET: JTAG exists check passed
- Core#0: ID code is 0x4BA00477
- Core#0: DP-CSW  is 0xF0000000
- Core#0: DBG-AP  at 0x82150000
- Core#0: DIDR    is 0x3513702A
- TARGET: Reset sequence passed
- TARGET: resetting target passed
- TARGET: processing target startup ....
- TARGET: processing target startup passed
IMX6#0>
IMX6#0>
IMX6#0>

*********************Flash Erase successful**************************
IMX6#0>mmh 0x08000aaa 0xaaaa
IMX6#0>mmh 0x08000554 0x5555
IMX6#0>mmh 0x08000aaa 0x8080
IMX6#0>mmh 0x08000aaa 0xaaaa
IMX6#0>mmh 0x08000554 0x5555
IMX6#0>mmh 0x08000aaa 0x1010
IMX6#0>erase 0x08000000 chip
Erasing flash at 0x08000000
Erasing flash passed

*********************Write to buffer Flash Programming
successful**************************
IMX6#0>mmb 0x08000aaa 0xaa
IMX6#0>mmb 0x08000555 0x55
IMX6#0>mmb 0x08000000 0x25
IMX6#0>mmb 0x08000000 3
IMX6#0>mmb 0x08000000 0x12
IMX6#0>mmb 0x08000001 0x34
IMX6#0>mmb 0x08000002 0x56
IMX6#0>mmb 0x08000003 0x78
IMX6#0>mmb 0x08000000 0x29
IMX6#0>mdb 0x08000000
08000000 : 12 34 56 78 ff ff ff ff  .4Vx....
08000008 : ff ff ff ff ff ff ff ff  ........
08000010 : ff ff ff ff ff ff ff ff  ........
08000018 : ff ff ff ff ff ff ff ff  ........
08000020 : ff ff ff ff ff ff ff ff  ........
08000028 : ff ff ff ff ff ff ff ff  ........
08000030 : ff ff ff ff ff ff ff ff  ........
08000038 : ff ff ff ff ff ff ff ff  ........
08000040 : ff ff ff ff ff ff ff ff  ........
08000048 : ff ff ff ff ff ff ff ff  ........
08000050 : ff ff ff ff ff ff ff ff  ........
08000058 : ff ff ff ff ff ff ff ff  ........
08000060 : ff ff ff ff ff ff ff ff  ........
08000068 : ff ff ff ff ff ff ff ff  ........
08000070 : ff ff ff ff ff ff ff ff  ........
08000078 : ff ff ff ff ff ff ff ff  ........
IMX6#0>
IMX6#0>mmh 0x08000000 0x00f0
IMX6#0>mmh 0x08000aaa 0x7070
IMX6#0>mmh 0x08000aaa 0x7171
IMX6#0>mmh 0x08000aaa 0xaaaa
IMX6#0>mmh 0x08000554 0x5555
IMX6#0>mmh 0x08000000 0x3030
IMX6#0>mmh 0x08000aaa 0x1010
IMX6#0>erase 0x08000000 chip
Erasing flash at 0x08000000
Erasing flash passed

********************U-boot Programming with Prog command
Failure**************************
IMX6#0>mmh 0x08000aaa 0xaaaa
IMX6#0>mmh 0x08000554 0x5555
IMX6#0>mmh 0x08000000 0x0025
IMX6#0>
IMX6#0>prog 0x08000000 u-boot.bin bin
Programming u-boot.bin , please wait ....
Programming flash passed
IMX6#0>mmh 0x08000000 0x0029
IMX6#0>mdh 0x08000000
08000000 : 000a 004a 000a 004a 000a 004a 000a 004a  ..J...J...J...J.
08000010 : 000a 004a 000a 004a 000a 004a 000a 004a  ..J...J...J...J.
08000020 : 000a 004a 000a 004a 000a 004a 000a 004a  ..J...J...J...J.
08000030 : 000a 004a 000a 004a 000a 004a 000a 004a  ..J...J...J...J.
08000040 : 000a 004a 000a 004a 000a 004a 000a 004a  ..J...J...J...J.
08000050 : 000a 004a 000a 004a 000a 004a 000a 004a  ..J...J...J...J.
08000060 : 000a 004a 000a 004a 000a 004a 000a 004a  ..J...J...J...J.
08000070 : 000a 004a 000a 004a 000a 004a 000a 004a  ..J...J...J...J.
08000080 : 000a 004a 000a 004a 000a 004a 000a 004a  ..J...J...J...J.
08000090 : 000a 004a 000a 004a 000a 004a 000a 004a  ..J...J...J...J.
080000a0 : 000a 004a 000a 004a 000a 004a 000a 004a  ..J...J...J...J.
080000b0 : 000a 004a 000a 004a 000a 004a 000a 004a  ..J...J...J...J.
080000c0 : 000a 004a 000a 004a 000a 004a 000a 004a  ..J...J...J...J.
080000d0 : 000a 004a 000a 004a 000a 004a 000a 004a  ..J...J...J...J.
080000e0 : 000a 004a 000a 004a 000a 004a 000a 004a  ..J...J...J...J.
080000f0 : 000a 004a 000a 004a 000a 004a 000a 004a  ..J...J...J...J.
IMX6#0>

I was able to read the manufacturer ID also .

The Prog command shows it is successful but nothing is written on the base
address if i give the prog command directly without any write to buffer
programming commands  or word programming commands

Kindly help me resolving this issue.





--
View this message in context: http://u-boot.10912.n7.nabble.com/minimum-bdi-config-to-read-flash-on-85xx-tp23684p155716.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] minimum bdi config to read flash on 85xx

[Fabio Estevam]

Hi Monica,

On Mon, May 27, 2013 at 10:01 AM, Monica <monica_s@hcl.com> wrote:
> We are using BDI3000 to Burn u-boot.bin to Flash memory. The flash we are
> using is Spansion S29GL512S.
>
> As per the flash datasheet we tried programming 4 bytes( using telnet mmb
> command) write buffer programming cycle. We succeeded.
>
> But when we tried programming a binary file ( u-boot.bin) ,it was failing.
> Even though the log shows Flash programming passed but in the location when
> we do a mdh there is no u-boot data.
>
> Please find the log captured below.
>
> IMX6#0>

Your email subject mentions 85xx, but the prompt above says mx6.

Which CPU does your board have?

[U-Boot] minimum bdi config to read flash on 85xx

[Monica]

Hi Fabio,

The CPU is imx6 customed processor.

The Prog command shows it passed but the u-boot.bin is not uploaded.

Regards,
Monica.S




From: Fabio Estevam-2 [via U-Boot] [mailto:ml-node+s10912n155717h46 at n7.nabble.com]
Sent: Monday, May 27, 2013 7:08 PM
To: Monica Sampathkumar
Subject: Re: minimum bdi config to read flash on 85xx

Hi Monica,

On Mon, May 27, 2013 at 10:01 AM, Monica <[hidden email]</user/SendEmail.jtp?type=node&node=155717&i=0>> wrote:

> We are using BDI3000 to Burn u-boot.bin to Flash memory. The flash we are
> using is Spansion S29GL512S.
>
> As per the flash datasheet we tried programming 4 bytes( using telnet mmb
> command) write buffer programming cycle. We succeeded.
>
> But when we tried programming a binary file ( u-boot.bin) ,it was failing.
> Even though the log shows Flash programming passed but in the location when
> we do a mdh there is no u-boot data.
>
> Please find the log captured below.
>
> IMX6#0>

Your email subject mentions 85xx, but the prompt above says mx6.

Which CPU does your board have?
_______________________________________________
U-Boot mailing list
[hidden email]</user/SendEmail.jtp?type=node&node=155717&i=1>
http://lists.denx.de/mailman/listinfo/u-boot

________________________________
If you reply to this email, your message will be added to the discussion below:
http://u-boot.10912.n7.nabble.com/minimum-bdi-config-to-read-flash-on-85xx-tp23684p155717.html
To unsubscribe from minimum bdi config to read flash on 85xx, click here<http://u-boot.10912.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=23684&code=bW9uaWNhX3NAaGNsLmNvbXwyMzY4NHw3MDA1NTgxNTM=>.
NAML<http://u-boot.10912.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>


::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

----------------------------------------------------------------------------------------------------------------------------------------------------




--
View this message in context: http://u-boot.10912.n7.nabble.com/minimum-bdi-config-to-read-flash-on-85xx-tp23684p155770.html
Sent from the U-Boot mailing list archive at Nabble.com.