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

[Eran Liberty <liberty@extricom.com>]

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