[U-Boot-Users] Flash write crash on MPC8548CDS

[U-Boot-Users] Flash write crash on MPC8548CDS

[ksi at koi8.net]

1.3.2-rc1-gb6f29c84-dirty crashes on the very first attempt to write in
Flash. After that it gets back to the prompt and _ALL_ subsequent writes
work just fine. Only the very first one fails.

Looks like something is not initialized properly. Before I start digging
does anyone has a fix for it? This is quite new platform for me so it could
take time for me to come up with a fix...

Here is what happens on the very first Flash write attempt (original config
with no changes, stock MPC8548CDS with SW2[1..2] set to "off-off", was
"off-on" out of the box for booting Freescale's U-Boot 1.1.something from
alternate Flash.)

=== Cut ===
U-Boot 1.3.2-rc1-gb6f29c84-dirty (Feb 19 2008 - 13:34:21)

CPU:   8548_E, Version: 2.1, (0x80390021)
Core:  E500, Version: 2.2, (0x80210022)
Clock Configuration:
        CPU:1320 MHz, CCB: 528 MHz,
        DDR: 264 MHz, LBC:  66 MHz
L1:    D-cache 32 kB enabled
        I-cache 32 kB enabled
Board: CDS Version 0x13, PCI Slot 1
CPU Board Revision 0.0 (0x0000)
I2C:   ready
DRAM:  Initializing
     SDRAM: 64 MB
     DDR: 256 MB
FLASH: 16 MB
L2 cache 512KB: enabled
     PCI: 64 bit, unknown MHz, async, host, external-arbiter
                Scanning PCI bus 00
PCI on bus 00 - 02

     PCIE connected to slot as Root Complex (base address e000a000)
PCIE on bus 3 - 3
In:    serial
Out:   serial
Err:   serial
Net:   eTSEC0, eTSEC1, eTSEC2, eTSEC3
Hit any key to stop autoboot:  0 
=> saveenv
Saving Environment to Flash...
Un-Protected 4 sectors
Erasing Flash...
.... done
Erased 4 sectors
Writing to Flash... External Interrupt Exception at PC: ffc1e2c, SR: 29200,
vector=500 irq IACK0 at e00600a0=2
NIP: 0FFC1E2C XER: 00000000 LR: 0FFCEBF4 REGS: 0ff5dc50 TRAP: 0500 DAR:
00000000
MSR: 00029200 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 00

GPR00: 00029200 0FF5DD40 0FF9DF78 00010000 00000000 00000555 FF800AAA
32C45D1D 
GPR08: 00000000 FF810000 0FF5DD2B 0FFF5404 0FF5DBA0 40ED2D4B 0FFF5100
00000000 
GPR16: 0FFEC778 0FFEE784 00000000 00000000 00000000 00000000 00000000
00000000 
GPR24: 0FF5DD78 0FF5DD88 00000001 FFFFF146 E4010000 0FF5DD33 0FFF572C
0FFF5404 
Call backtrace: 
0FF5DD33 0FFCEB8C 0FFCF8C8 0FFDD27C 0FFDCCCC 0FFD9B50 0FFDF230 
0FFDE944 0FFDEAB0 0FFD2384 0FFC9810 0FFC15FC 
Skipping current instr, Returning to 0x0ffc1e30
done
Protected 4 sectors
=>
=== Cut ===

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot-Users] Flash write crash on MPC8548CDS

[Andy Fleming]

On Wed, Feb 20, 2008 at 1:13 PM,  <ksi@koi8.net> wrote:
> 1.3.2-rc1-gb6f29c84-dirty crashes on the very first attempt to write in
>  Flash. After that it gets back to the prompt and _ALL_ subsequent writes
>  work just fine. Only the very first one fails.

How did you program u-boot into the flash?

[U-Boot-Users] Flash write crash on MPC8548CDS

[ksi at koi8.net]

On Wed, 20 Feb 2008, Andy Fleming wrote:

> On Wed, Feb 20, 2008 at 1:13 PM,  <ksi@koi8.net> wrote:
>> 1.3.2-rc1-gb6f29c84-dirty crashes on the very first attempt to write
> in
>>  Flash. After that it gets back to the prompt and _ALL_ subsequent
> writes
>>  work just fine. Only the very first one fails.
>
> How did you program u-boot into the flash?

With "tft xx xx; cp.b xx xx xx" :)

It _ONLY_ fails on the first attempt. Crash is _NOT_ fatal so system returns
to U-Boot prompt then you do the second attempt that succeeds. And all
consecutive writes work fine.

And initially I wrote new U-Boot with the original 1.1.something from
Freescale that works OK in that respect.

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot-Users] Flash write crash on MPC8548CDS

[Andy Fleming]

>  It is too late today but tomorrow I will try to write something in Flash
>  with cp.b and check if this still happens.
>
>  Everything works OK with the old U-Boot that came with CDS though...

Ok, I found the problem.  Check my tree (u-boot-mpc85xx.git) now.
It's got a patch
which removes the mappings for INIT_RAM, thus preventing speculative
loads from going out on the bus.

Andy

[U-Boot-Users] Flash write crash on MPC8548CDS

[ksi at koi8.net]

On Wed, 27 Feb 2008, Andy Fleming wrote:

>>  It is too late today but tomorrow I will try to write something in
> Flash
>>  with cp.b and check if this still happens.
>>
>>  Everything works OK with the old U-Boot that came with CDS though...
>
> Ok, I found the problem.  Check my tree (u-boot-mpc85xx.git) now.
> It's got a patch
> which removes the mappings for INIT_RAM, thus preventing speculative
> loads from going out on the bus.

OK, thanks. I will try it tomorrow after our meetings are over...

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot-Users] Flash write crash on MPC8548CDS

[Eran Liberty]

Dear Andy,

I experience the same behavior as ksi described.

I experience this over u-boot-1.3.2-rc3 which should have had this fixed.
I assume you referred to commit	21fae8b2b4e4e6e648796e07e20ab13e9cb18923.

Are there any follow ups on this subject?

Liberty

this is a flash 2 flash example. It happens on ram 2 flash as well.

=> cp.b FF800000 FF000000 80000
Copy to Flash... External Interrupt Exception at PC: 1ffc1dc0, SR: 29200,
vector=500 irq IACK0 at e00600a0=3
NIP: 1FFC1DC0 XER: 00000000 LR: 1FFCEBCC REGS: 1fadbc50 TRAP: 0500 DAR: 00000000
MSR: 00029200 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 00

GPR00: 00029200 1FADBD40 1FADBF8C 0000F103 FF00113A 1FADBD32 000000A0 6F1D9410
GPR08: 00000000 FF000000 00000003 1FFFC4D4 48028024 F7B7BFFF 1FFFB200 20040000
GPR16: 00000000 00000000 00000000 00000000 00000000 1FADBCC8 1FADE338 1FADE240
GPR24: FF07FFFF 00000000 00000001 FF00113A F1030000 1FFEFD70 1FFFB8F4 1FFFC4D4
Call backtrace:
1FFEFD70 1FFCEB50 1FFCF1FC 1FFDD9E8 1FFD8E58 1FFDFABC 1FFE0164
1FFE02CC 1FFD16EC 1FFC9558 1FFC15FC
Skipping current instr, Returning to 0x1ffc1dc4
done

[U-Boot-Users] Flash write crash on MPC8548CDS

[Kumar Gala]

On Mar 10, 2008, at 7:35 AM, Eran Liberty wrote:

> Dear Andy,
>
> I experience the same behavior as ksi described.
>
> I experience this over u-boot-1.3.2-rc3 which should have had this  
> fixed.
> I assume you referred to commit	 
> 21fae8b2b4e4e6e648796e07e20ab13e9cb18923.
>
> Are there any follow ups on this subject?

We pushed a fix and it should be in the 1.3.2 release.

Look for 'Invalidate INIT_RAM TLB mappings'

- k

[U-Boot-Users] Flash write crash on MPC8548CDS

[Eran Liberty]

Kumar Gala <galak <at> kernel.crashing.org> writes:
> 
> 
> On Mar 10, 2008, at 7:35 AM, Eran Liberty wrote:
> 
> > Dear Andy,
> >
> > I experience the same behavior as ksi described.
> >
> > I experience this over u-boot-1.3.2-rc3 which should have had this  
> > fixed.
> > I assume you referred to commit	 
> > 21fae8b2b4e4e6e648796e07e20ab13e9cb18923.
> >
> > Are there any follow ups on this subject?
> 
> We pushed a fix and it should be in the 1.3.2 release.
> 
> Look for 'Invalidate INIT_RAM TLB mappings'
> 
> - k
> 

Exactly my point. I have followed up on the suggested patch, made sure it is
indeed in the latest release u-boot-1.3.2-rc3 (it is), And still I get this
behavior.

It is worth mentioning that:
1. It is much easier to reproduce this in flash to flash copy.
2. I am still not 100% sure that my hardware is not acting funny.

Cheers,
Liberty

[U-Boot-Users] Flash write crash on MPC8548CDS

[Andy Fleming]

On Mon, Mar 10, 2008 at 7:35 AM, Eran Liberty <liberty@extricom.com> wrote:
> Dear Andy,
>
>  I experience the same behavior as ksi described.

Sadly, you are experiencing a slightly different behavior.

>

>  => cp.b FF800000 FF000000 80000
>  Copy to Flash... External Interrupt Exception at PC: 1ffc1dc0, SR: 29200,
>  vector=500 irq IACK0 at e00600a0=3

You are getting source vector 3.  This means the LBC is throwing off
errors, rather than the ECM.  Could you show me the result of running
"md e005000"?  Then we can see what sort of error is causing the
exception.

Andy

[U-Boot-Users] Flash write crash on MPC8548CDS

[Eran Liberty]

Here is my sequence narrated:

U-Boot 1.3.2-rc3 (Mar  6 2008 - 12:00:30)

CPU:   8548, Version: 2.0, (0x80310020)
Core:  E500, Version: 2.0, (0x80210020)
Clock Configuration:
        CPU: 990 MHz, CCB: 396 MHz,
        DDR: 198 MHz, LBC:  49 MHz
L1:    D-cache 32 kB enabled
        I-cache 32 kB enabled
Board: EXSW1600
I2C:   ready
DRAM:  Initializing
     DDR: 512 MB
\*
  * I give less sectors then needed for the flash,
  * forcefully restricting its size....
  * don't think it should matter
  *\
FLASH: ERROR: too many flash sectors
ERROR: too many flash sectors
16 MB
L2 cache 512KB: enabled
     PCI: 64 bit, unknown MHz, async, host, arbiter
                Scanning PCI bus 00
PCI on bus 00 - 00
In:    serial
Out:   serial
Err:   serial
/*
  * My print add-on, so i can calc the address in the objdump file
  */
gd->reloc_off = 0x20040000
/*
  * My board FPGA burn process
  */
FPGA loading
    Image Name:   20080219:1741
    Image Type:   PowerPC Linux Kernel Image (bzip2 compressed)
    Data Size:    415310 Bytes = 405.6 kB
    Load Address: 00000000
    Entry Point:  00000000
    Verifying Checksum ... OK
loading to fpga  done.
Net:   eTSEC0
Hit any key to stop autoboot:  0
/*
  * I don't think you wanted e005000
  */
=> md e005000
0e005000: deadbeef deadbeef deadbeef deadbeef    ................
0e005010: deadbeef deadbeef deadbeef deadbeef    ................
0e005020: deadbeef deadbeef deadbeef deadbeef    ................
0e005030: deadbeef deadbeef deadbeef deadbeef    ................
0e005040: deadbeef deadbeef deadbeef deadbeef    ................
0e005050: deadbeef deadbeef deadbeef deadbeef    ................
0e005060: deadbeef deadbeef deadbeef deadbeef    ................
0e005070: deadbeef deadbeef deadbeef deadbeef    ................
0e005080: deadbeef deadbeef deadbeef deadbeef    ................
0e005090: deadbeef deadbeef deadbeef deadbeef    ................
0e0050a0: deadbeef deadbeef deadbeef deadbeef    ................
0e0050b0: deadbeef deadbeef deadbeef deadbeef    ................
0e0050c0: deadbeef deadbeef deadbeef deadbeef    ................
0e0050d0: deadbeef deadbeef deadbeef deadbeef    ................
0e0050e0: deadbeef deadbeef deadbeef deadbeef    ................
0e0050f0: deadbeef deadbeef deadbeef deadbeef    ................
/*
  * nor e0050000
  */
=> md e0050000
e0050000: 80000000 80000000 80000000 80000000    ................
e0050010: 00000001 00000001 00000001 00000001    ................
e0050020: 80000000 80000000 80000000 80000000    ................
e0050030: 00000001 00000001 00000001 00000001    ................
e0050040: 80000000 80000000 80000000 80000000    ................
e0050050: 00000001 00000001 00000001 00000001    ................
e0050060: 80000000 80000000 80000000 80000000    ................
e0050070: 00000001 00000001 00000001 00000001    ................
e0050080: 80000000 80000000 80000000 80000000    ................
e0050090: 00000001 00000001 00000001 00000001    ................
e00500a0: 80000000 80000000 80000000 80000000    ................
e00500b0: 00000001 00000001 00000001 00000001    ................
e00500c0: 80000000 80000000 80000000 80000000    ................
e00500d0: 00000001 00000001 00000001 00000001    ................
e00500e0: 80000000 80000000 80000000 80000000    ................
e00500f0: 00000001 00000001 00000001 00000001    ................
/*
  * You probably wanted this.
  */
=> md e0005000
e0005000: ff801001 ff806e65 ff001001 ff806e65    ......ne......ne
e0005010: f0001861 fc006901 f8001001 fff00ff7    ...a..i.........
e0005020: 00000000 00000000 00000000 00000000    ................
e0005030: 00000000 00000000 00000000 00000000    ................
e0005040: 00000000 00000000 00000000 00000000    ................
e0005050: 00000000 00000000 00000000 00000000    ................
e0005060: 00000000 00000000 00000000 00000000    ................
e0005070: 00000000 00000000 00000000 00000000    ................
e0005080: 00000000 00000000 00000000 00000000    ................
e0005090: 00000000 00000000 00000000 00000000    ................
e00050a0: 00000000 20000000 00000000 00000000    .... ...........
e00050b0: 00000000 00000000 ffffffff 00000000    ................
e00050c0: 00000000 00000000 00000000 00000000    ................
e00050d0: 00000000 80030008 00000000 00000000    ................
e00050e0: 00000000 00000000 00000000 00000000    ................
e00050f0: 00000000 00000000 00000000 00000000    ................
=> fli

Bank # 1: CFI conformant FLASH (16 x 16)  Size: 8 MB in 64 Sectors
   AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x7E2301
   Erase timeout: 16384 ms, write timeout: 2 ms
   Buffer write timeout: 5 ms, buffer size: 32 bytes

   Sector Start Addresses:
   FF800000        FF820000        FF840000        FF860000        FF880000
   FF8A0000        FF8C0000        FF8E0000        FF900000        FF920000
   FF940000        FF960000        FF980000        FF9A0000        FF9C0000
   FF9E0000        FFA00000        FFA20000        FFA40000        FFA60000
   FFA80000        FFAA0000        FFAC0000        FFAE0000        FFB00000
   FFB20000        FFB40000        FFB60000        FFB80000        FFBA0000
   FFBC0000        FFBE0000        FFC00000        FFC20000        FFC40000
   FFC60000        FFC80000        FFCA0000        FFCC0000        FFCE0000
   FFD00000        FFD20000        FFD40000        FFD60000 
FFD80000 E
   FFDA0000 E      FFDC0000 E      FFDE0000 E      FFE00000 E 
FFE20000 E
   FFE40000 E      FFE60000 E      FFE80000 E      FFEA0000 E 
FFEC0000 E
   FFEE0000 E      FFF00000 E      FFF20000 E      FFF40000 E 
FFF60000 E
   FFF80000   RO   FFFA0000   RO   FFFC0000   RO   FFFE0000   RO

Bank # 2: CFI conformant FLASH (16 x 16)  Size: 8 MB in 64 Sectors
   AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x7E2301
   Erase timeout: 16384 ms, write timeout: 2 ms
   Buffer write timeout: 5 ms, buffer size: 32 bytes

   Sector Start Addresses:
   FF000000 E      FF020000 E      FF040000 E      FF060000 E 
FF080000 E
   FF0A0000 E      FF0C0000 E      FF0E0000 E      FF100000 E 
FF120000 E
   FF140000 E      FF160000 E      FF180000 E      FF1A0000 E 
FF1C0000 E
   FF1E0000 E      FF200000 E      FF220000 E      FF240000 E 
FF260000 E
   FF280000 E      FF2A0000 E      FF2C0000 E      FF2E0000 E 
FF300000 E
   FF320000 E      FF340000 E      FF360000 E      FF380000 E 
FF3A0000 E
   FF3C0000 E      FF3E0000 E      FF400000 E      FF420000 E 
FF440000 E
   FF460000 E      FF480000 E      FF4A0000 E      FF4C0000 E 
FF4E0000 E
   FF500000 E      FF520000 E      FF540000 E      FF560000 E 
FF580000 E
   FF5A0000 E      FF5C0000 E      FF5E0000 E      FF600000 E 
FF620000 E
   FF640000 E      FF660000 E      FF680000 E      FF6A0000 E 
FF6C0000 E
   FF6E0000 E      FF700000 E      FF720000 E      FF740000 E 
FF760000 E
   FF780000 E      FF7A0000 E      FF7C0000 E      FF7E0000 E
/*
  * Here is the first attempt
  */
=> cp.b FF800000 FF000000 80000
Copy to Flash... External Interrupt Exception at PC: 1ffc1dc0, SR: 
29200, vector=500 irq IACK0 at e00600a0=3
NIP: 1FFC1DC0 XER: 00000000 LR: 1FFCEBCC REGS: 1fadbc50 TRAP: 0500 DAR: 
00000000
MSR: 00029200 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 00

GPR00: 00029200 1FADBD40 1FADBF8C 0000F103 FF00113A 1FADBD32 000000A0 
2C4D2B8E
GPR08: 00000000 FF000000 00000003 1FFFC4D4 48028024 FFB7FFFF 1FFFB200 
20040000
GPR16: 00000000 00000000 00000000 00000000 00000000 EFFFF5EF 1FADE338 
1FADE240
GPR24: FF07FFFF 00000000 00000001 FF00113A F1030000 1FFEFD48 1FFFB8F4 
1FFFC4D4
Call backtrace:
/*
  * Tracing the callback indicates the exception happened as soon
  * as enable_interrupts () is called in flash_write_cfiword()
  */
1FFEFD48 1FFCEB50 1FFCF1FC 1FFDD9D4 1FFD8E44 1FFDFAA8 1FFE0150
1FFE02B8 1FFD16D8 1FFC9558 1FFC15FC
Skipping current instr, Returning to 0x1ffc1dc4
done
/*
  * You can see that the flash was copied ok despite the exception.
  * rebooting the machine and re-checking the crc confirms that it
  * was indeed copied to flash (and not ram)
  */
=> crc FF800000 80000
CRC32 for ff800000 ... ff87ffff ==> d5f0d2a3
=> crc FF000000 80000
CRC32 for ff000000 ... ff07ffff ==> d5f0d2a3
=> erase FF000000 ff07ffff
.... done
Erased 4 sectors
/*
  * Second attempt succeeds quietly as in ksi case.
  */
=> cp.b FF800000 FF000000 80000
Copy to Flash... done
=>

[U-Boot-Users] Flash write crash on MPC8548CDS

[Eran Liberty]

Hi Andy,

I am bringing us back online as I think your insights might enlighten 
others who might be googleing for answers. (I know i try my best when 
faced with problems)

Andy Fleming wrote:
> On Tue, Mar 11, 2008 at 3:13 AM, Eran Liberty <liberty@extricom.com> wrote:
> 
>> FLASH: ERROR: too many flash sectors
>>  ERROR: too many flash sectors
>>  16 MB
> 
> You should check that out.
I know exactly why I see this one and I don't think its the problem.

> 
> 
> 
>>  GPR00: 00029200 1FADBD40 1FADBF8C 0000F103 FF00113A 1FADBD32 000000A0
>>  69A60E94
>>  GPR08: 00000000 FF000000 00000003 1FFFC4D4 48028024 F7B7BFFF 1FFFB200
>>  20040000
>>  GPR16: 00000000 00000000 00000000 00000000 00000000 EFBFF5EF 1FADE338
>>  1FADE240
>>  GPR24: FF07FFFF 00000000 00000001 FF00113A F1030000 1FFEFD40 1FFFB8F4
>>  1FFFC4D4
>>  Call backtrace:
>>  1FFEFD40 1FFCEB4C 1FFCF1F8 1FFDD9CC 1FFD8E40 1FFDFAA0 1FFE0148
>>  1FFE02B0 1FFD16D4 1FFC9554 1FFC15FC
> 
> 
> Notice that r27 is 0xf1030000
> 

considering the command I did, cp.b 0xff800000 0xff000000 80000, I 
should have never accessed 0xf1030000.

> 
> 
>>  => md e00050b0
>>  e00050b0: 80000000 00000000 ffffffff 10110201    ................
>>  e00050c0: f1030160 00000000 00000000 00000000    ...`............
> 
> 
> 50b0: 80000000 -- This means you had a bus timeout
> 
> 50bc: 10110201 -- This means the error occurred during a read
> initiated by the processor.
> 50c0: f1030160 -- Notice this address is based off r27.
> 
> My theory (based on very little), is that you have f1030160 mapped for
> some reason, and it's mapped unguarded.  And the LBC thinks it's in
> its address space.  That's probably due to the LAWs.
> 
> So...
> 1) Check your LAWs.  Is f1030160 targeted at Local Bus?
> 2) Check your TLBs.  Is f1030160 mapped?  If you have a bdi2000, it
> can tell you if there are entries in the TLBs for that region.
> 3) If f1030160 actually points at something that might not be ready
> for transactions, you need to mark the region as "Guarded"
> 

I have used mpc8548cds as a reference so my local bus is mapped from 
0xf0000000 - 0xffffffff
law.c will have this line:
====================== law.c snip ======================================
	/* LBC window - maps 256M 0xf0000000 -> 0xffffffff */
	SET_LAW_ENTRY(8, CFG_LBC_SDRAM_BASE, LAW_SIZE_256M, LAW_TRGT_IF_LBC),
========================================================================

but tlb.c will have this for flash:
====================== tlb.c snip ======================================
	/*
	 * TLB 0:	16M	Non-cacheable, guarded
	 * 0xff000000	16M	FLASH
	 * Out of reset this entry is only 4K.
	 */
	SET_TLB_ENTRY(1, CFG_BOOT_BLOCK, CFG_BOOT_BLOCK,
		      MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
		      0, 0, BOOKE_PAGESZ_16M, 1),

========================================================================

So we have local bus window mapping but not tlb mapping, which should be 
ok, because I should have accessed only addresses within the tlb mapped 
range.

so I guess my follow up questions are:
- Why does my u-boot thy to access this non flash address.?
- Why is this a first time problem only?
- Flash is written ok in the end. Why does it not hurt that actual write?

Thanks for all the effort you are putting into my problem. It is 
immensely appreciated.

Liberty

[U-Boot-Users] Flash write crash on MPC8548CDS

[ksi at koi8.net]

On Tue, 11 Mar 2008, Eran Liberty wrote:

Sorry guys for not being able to join you this time, extremely busy making
my programmers' team to meet a delivery deadline... I would've participated
but...

> Hi Andy,
>
> I am bringing us back online as I think your insights might enlighten
> others who might be googleing for answers. (I know i try my best when
> faced with problems)
>
> Andy Fleming wrote:
>> On Tue, Mar 11, 2008 at 3:13 AM, Eran Liberty <liberty@extricom.com>
> wrote:
>>
>>> FLASH: ERROR: too many flash sectors
>>>  ERROR: too many flash sectors
>>>  16 MB
>>
>> You should check that out.
> I know exactly why I see this one and I don't think its the problem.
>
>>
>>
>>
>>>  GPR00: 00029200 1FADBD40 1FADBF8C 0000F103 FF00113A 1FADBD32
> 000000A0
>>>  69A60E94
>>>  GPR08: 00000000 FF000000 00000003 1FFFC4D4 48028024 F7B7BFFF
> 1FFFB200
>>>  20040000
>>>  GPR16: 00000000 00000000 00000000 00000000 00000000 EFBFF5EF
> 1FADE338
>>>  1FADE240
>>>  GPR24: FF07FFFF 00000000 00000001 FF00113A F1030000 1FFEFD40
> 1FFFB8F4
>>>  1FFFC4D4
>>>  Call backtrace:
>>>  1FFEFD40 1FFCEB4C 1FFCF1F8 1FFDD9CC 1FFD8E40 1FFDFAA0 1FFE0148
>>>  1FFE02B0 1FFD16D4 1FFC9554 1FFC15FC
>>
>>
>> Notice that r27 is 0xf1030000
>>
>
> considering the command I did, cp.b 0xff800000 0xff000000 80000, I
> should have never accessed 0xf1030000.
>
>>
>>
>>>  => md e00050b0
>>>  e00050b0: 80000000 00000000 ffffffff 10110201    ................
>>>  e00050c0: f1030160 00000000 00000000 00000000    ...`............
>>
>>
>> 50b0: 80000000 -- This means you had a bus timeout
>>
>> 50bc: 10110201 -- This means the error occurred during a read
>> initiated by the processor.
>> 50c0: f1030160 -- Notice this address is based off r27.
>>
>> My theory (based on very little), is that you have f1030160 mapped for
>> some reason, and it's mapped unguarded.  And the LBC thinks it's in
>> its address space.  That's probably due to the LAWs.
>>
>> So...
>> 1) Check your LAWs.  Is f1030160 targeted at Local Bus?
>> 2) Check your TLBs.  Is f1030160 mapped?  If you have a bdi2000, it
>> can tell you if there are entries in the TLBs for that region.
>> 3) If f1030160 actually points at something that might not be ready
>> for transactions, you need to mark the region as "Guarded"
>>
>
> I have used mpc8548cds as a reference so my local bus is mapped from
> 0xf0000000 - 0xffffffff
> law.c will have this line:
> ====================== law.c snip ======================================
> 	/* LBC window - maps 256M 0xf0000000 -> 0xffffffff */
> 	SET_LAW_ENTRY(8, CFG_LBC_SDRAM_BASE, LAW_SIZE_256M,
> LAW_TRGT_IF_LBC),
> ========================================================================
>
> but tlb.c will have this for flash:
> ====================== tlb.c snip ======================================
> 	/*
> 	 * TLB 0:	16M	Non-cacheable, guarded
> 	 * 0xff000000	16M	FLASH
> 	 * Out of reset this entry is only 4K.
> 	 */
> 	SET_TLB_ENTRY(1, CFG_BOOT_BLOCK, CFG_BOOT_BLOCK,
> 		      MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
> 		      0, 0, BOOKE_PAGESZ_16M, 1),
>
> ========================================================================
>
> So we have local bus window mapping but not tlb mapping, which should be
> ok, because I should have accessed only addresses within the tlb mapped
> range.
>
> so I guess my follow up questions are:
> - Why does my u-boot thy to access this non flash address.?
> - Why is this a first time problem only?
> - Flash is written ok in the end. Why does it not hurt that actual
> write?
>
> Thanks for all the effort you are putting into my problem. It is
> immensely appreciated.
>
> Liberty
>
> ------------------------------------------------------------------------
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> 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
>

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot-Users] Flash write crash on MPC8548CDS

[Andy Fleming]

On Tue, Mar 11, 2008 at 1:30 PM, Eran Liberty <liberty@extricom.com> wrote:
> Hi Andy,
>
>  I am bringing us back online as I think your insights might enlighten
>  others who might be googleing for answers. (I know i try my best when
>  faced with problems)

Oops, yes.  I hit the wrong button.  I meant to keep it on the list, too.


>  > Notice that r27 is 0xf1030000
>  >
>
>  considering the command I did, cp.b 0xff800000 0xff000000 80000, I
>  should have never accessed 0xf1030000.

Yes.  My theory is that it's a speculative load, ie the processor ran
code speculatively, and started a load to memory.  However, it would
only do that if there's a TLB entry for that address.

What is your INIT_RAM_ADDR?


>  I have used mpc8548cds as a reference so my local bus is mapped from
>  0xf0000000 - 0xffffffff
>  law.c will have this line:
>  ====================== law.c snip ======================================
>         /* LBC window - maps 256M 0xf0000000 -> 0xffffffff */
>         SET_LAW_ENTRY(8, CFG_LBC_SDRAM_BASE, LAW_SIZE_256M, LAW_TRGT_IF_LBC),

So that's definitely why the LBC is involved.  But I'm pretty sure
there needs to be a TLB entry before the core will put the transaction
on the bus.


>         /*
>          * TLB 0:       16M     Non-cacheable, guarded
>          * 0xff000000   16M     FLASH
>          * Out of reset this entry is only 4K.
>          */
>         SET_TLB_ENTRY(1, CFG_BOOT_BLOCK, CFG_BOOT_BLOCK,
>                       MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
>                       0, 0, BOOKE_PAGESZ_16M, 1),

Right, look for any other entries that might be mapping the error address.


>  So we have local bus window mapping but not tlb mapping, which should be
>  ok, because I should have accessed only addresses within the tlb mapped
>  range.
>
>  so I guess my follow up questions are:
>  - Why does my u-boot thy to access this non flash address.?

My guess is it's a speculative load.

>  - Why is this a first time problem only?

The code that reports the exception doesn't actually clear the
condition, so further such events can't cause this problem.  Also, if
it's a speculative load, the address will be fairly random, and so it
just may not hit that window again.

>  - Flash is written ok in the end. Why does it not hurt that actual write?

Interrupts are disabled during the write.  So the write will complete,
then the exception fires.  The speculative load shouldn't cause real
problems since the code is not expecting that read to happen.

Andy

[U-Boot-Users] Flash write crash on MPC8548CDS

[Andy Fleming]

>  Ok closer look revealed this entry.
>  ========================== tlb.c snip ===============================
>         /*
>          * TLB 6:       64M     Cacheable, non-guarded
>          * 0xf000_0000  64M     LBC SDRAM
>          */
>         SET_TLB_ENTRY(1, CFG_LBC_CACHE_BASE, CFG_LBC_CACHE_BASE,
>                       MAS3_SX|MAS3_SW|MAS3_SR, 0,
>                       0, 6, BOOKE_PAGESZ_64M, 1),
>  =====================================================================
>
>  And I don't even have SDRAM :)... but in order to stay as close to my
>  reference, mpc8548cds, I thought the extra tlb entry could not hurt me.
>
>  I have remarked it and the Exception did not occur again.

Excellent!



>  my last unknown / not understood corner... is why the speculative loads
>  occur in the first time.

This is a common fact of CPUs.  In order to improve performance, the
cpu will often start executing code paths before it knows whether
those paths will be taken.  If the path is taken, the results are
committed, and you don't have to wait.  If the path isn't taken, the
results are ignored.  When the path is not taken, it's likely that the
registers aren't in a sensible state, so random addresses can end up
getting loaded.  When things aren't mapped, the loads don't happen
(speculative instructions aren't allowed to cause exceptions).  Also,
pages that are marked "guarded" don't allow speculative access
(reading from IO regions can have side-effects, so it's not allowed to
do so speculatively).

After the first speculative load, either the branch predictor starts
being right from them on, or it just isn't detected because the
subsequent errors are gated behind the LBC interrupt logic, waiting
for someone to clear it.

Andy

[U-Boot-Users] dtc n00bie - Flat device Tree nightmare

[Richard Parsons]

Hi All,

I have the MPC8323EMDS board and trying to get the FDT working - well
trying to understand it.

After all the loading, u-boot gives the error and then resets.

WARNING: could not set linux,stdout-path FDT_ERR_NOTFOUND

The mpc8323xemds config file show that this is linked to an /aliases
somehow in the DTC. There is a #define CONFIG_STDOUT_VIA_ALIAS (close
enough to the name) Where is this alaias set?

Can anyone Give me some pointers what to hit? 

Best Regards,
Richard

[U-Boot-Users] dtc n00bie - Flat device Tree nightmare

[Jon Loeliger]

On Thu, 2008-03-13 at 10:54, Richard Parsons wrote:
> Hi All,
> 
> I have the MPC8323EMDS board and trying to get the FDT working - well
> trying to understand it.
> 
> After all the loading, u-boot gives the error and then resets.
> 
> WARNING: could not set linux,stdout-path FDT_ERR_NOTFOUND
> 
> The mpc8323xemds config file show that this is linked to an /aliases
> somehow in the DTC. There is a #define CONFIG_STDOUT_VIA_ALIAS (close
> enough to the name) Where is this alaias set?
> 
> Can anyone Give me some pointers what to hit? 
> 
> Best Regards,
> Richard

The alias node is a semi-new node in the Device Tree
added to help locate some of the other standard nodes
via well known properties.  For an example, grep around
in the arch/powerpc/boot/dts directory of a modern kernel
tree.

HTH,
jdl