Re: [U-Boot-Users] Flash write crash on MPC8548CDS
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...
- Check your LAWs. Is f1030160 targeted at Local Bus?
- 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
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...
- Check your LAWs. Is f1030160 targeted at Local Bus?
- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
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
participants (3)
-
Andy Fleming -
Eran Liberty -
ksi＠koi8.net