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. * ******************************************************************