• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 562 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

New AM3505 silicon?

Jim Grimes
Intellectual 375 points
Other Parts Discussed in Thread: AM3505, AM3517

We recently received boards which aren't booting (linux/Android) from the production line of an existing design. Following information in the console we've realized the earlier prototypes we built were reporting the existence of the SGX accelerator even in an AM3505 ...

*** From Uboot on the "old" prototype ...

"showCpuRawInfo: cpuFamily=0x3500, cpuType=0xcc0, cpuRev=1, skuID=0x0, deviceType=0x3"

*** From Uboot on the "new" production ...

:"showCpuRawInfo: cpuFamily=0x3500, cpuType=0x4cc0, cpuRev=1, skuID=0x0, deviceType=0x3"

*** And then from the Kernel (2.6.36)  - "old" prototype ...

Memory policy: ECC disabled, Data cache writeback
AM3517 ES1.1 (l2cache sgx neon isp )
SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x10000

*** "new" production ...

Memory policy: ECC disabled, Data cache writeback
AM3505 ES1.1 (l2cache neon isp )
SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x10000.

*** The Kernel on the new boards is crashing with the following (3 out of 3 are doing this) ...

adb_open
# davinci_mdio davinci_mdio: resetting idled controller
net eth0: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=ffffffff:01, id=7c0f1)
Unhandled fault: external abort on non-linefetch (0x1008) at 0xd09d8014
Internal error: : 1008 [#1]
last sysfs file: /sys/power/state
Modules linked in: omaplfb pvrsrvkm
CPU: 0    Not tainted  (2.6.37-g06ebbba-dirty #1)
PC is at OSReadHWReg+0xc/0x18 [pvrsrvkm]
LR is at SysFinalise+0x9c/0x118 [pvrsrvkm]
pc : [<bf000220>]    lr : [<bf013a54>]    psr: a0000013
sp : cc1cbe30  ip : cc1cbe40  fp : cc1cbe3c
r10: 00000000  r9 : cc1ca000  r8 : d09d8000
r7 : bf01ff20  r6 : 00000000  r5 : 00000000  r4 : bf01fe60
r3 : 00000002  r2 : 00000000  r1 : 00000014  r0 : d09d8000
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 8c1cc019  DAC: 00000015

SP: 0xcc1cbdb0:
bdb0  00000000 00000000 00000000 bf01ff20 cc163000 00000000 ffffffff cc1cbe1c
bdd0  00000000 bf01ff20 cc1cbe3c cc1cbde8 c047d42c c003d274 d09d8000 00000014
bdf0  00000000 00000002 bf01fe60 00000000 00000000 bf01ff20 d09d8000 cc1ca000
be10  00000000 cc1cbe3c cc1cbe40 cc1cbe30 bf013a54 bf000220 a0000013 ffffffff
be30  cc1cbe6c cc1cbe40 bf013a54 bf000220 cc1cbe64 00000012 cc162048 bf01ff20
be50  cc163000 00000000 cc162000 cc163000 cc1cbe84 cc1cbe70 bf00c538 bf0139c4
be70  cc162000 cc163000 cc1cbea4 cc1cbe88 bf01117c bf00c524 cc1aef00 cc1cbed0
be90  00000045 cc162000 cc1cbecc cc1cbea8 bf01035c bf011130 cc1b0cc0 00000433

*** My suspicion is that we've uncovered a bug in the Kernel or Android where its accessing an SGX register that use to function (even in a AM3505) and TI has now removed that silicon and is generating an exception on access which isn't being handled.

Finally, Questions ...

1. Did the AM3505 use to use the AM3517 die, and has TI changed this recently?

"old" part (which works with 2.6.36) is marked

AM3505AZERA (new line) 15ALKKW GI (new line) 532 ZER

"new" part (crashes during boot)

AM3505AZERA (new line) 1CA5FKW GI (new line) 532 ZER

2. Has anyone else reported this issue? (... and I'm reposting this on the Android site to see if anyone responds)

Thanks ... Jim

  • 0
    Prodigy 110 points

    We have the same lot codes.

    We were having a problem with our kernel (wind river 2.67.34.10) such that the board was not going beyond "Uncompressing Linux... done, booting the kernel.".

    I also noticed the same device code problems when I did a dump of Control Device Status Register 15:0 (Address 0x4800 244C)

    <uboot2> # md.w 0x4800244c 1
     4800244c: 0cc0 ..
    Bits 14:13 are 0, indicating an am3517.
    New board:
    <uboot2> # md.w 0x4800244c 1
     4800244c: 4cc0 .L

    Bits 14:13 are 10, indicating an am3505.


    I don't know if this was the *right* thing to do given what I've seen in the PSP 2.6.7 kernel, but this is the patch I applied that appears to have solved our particular issue of the board not booting:

    commit 21ba9b09432fcc549afd7012e9feeb08a451603d
Author: Sarah Newman <snewman@shotspotter.com>
Date:   Fri Jan 18 13:48:44 2013 -0800

    The only difference between the am3517 and the am3505 is that one has SGX
    and the other does not.  This fixes a place where a clock, sr2_fck, was
    associated with the am3517 rather than the am35xx family.
    
    Signed-off-by: Sarah Newman <snewman@shotspotter.com>

diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c
index 0084acd..e69e6c9 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3502,7 +3502,7 @@ static struct omap_clk omap3xxx_clks[] = {
        CLK(NULL,       "traceclk_src_fck", &traceclk_src_fck, CK_3XXX),
        CLK(NULL,       "traceclk_fck", &traceclk_fck,  CK_3XXX),
        CLK(NULL,       "sr1_fck",      &sr1_fck,       CK_343X),
-       CLK(NULL,       "sr2_fck",      &sr2_fck,       CK_343X | CK_3517),
+       CLK(NULL,       "sr2_fck",      &sr2_fck,       CK_343X | CK_AM35XX),
        CLK(NULL,       "sr_l4_ick",    &sr_l4_ick,     CK_343X),
        CLK(NULL,       "secure_32k_fck", &secure_32k_fck, CK_3XXX),
        CLK(NULL,       "gpt12_fck",    &gpt12_fck,     CK_3XXX),



    Hope this helps someone else.  

    We could have other issues as there has not been enough testing yet but when I looked at the 
    code it seemed like this was the only place where am3517 was being called out, am3505 
    was not, and the reference was not related to sgx.
  • 0 in reply to Sarah Newman
    Intellectual 375 points

    Hey Sarah,

    TI later admitted to us (although I never saw it publicly discussed) that several lots of "AM3517's" shipped which were fused as "AM3505's". The two parts share the same die and the SGX is fused-out (disabled) on the 3517. In our case with Android, we had been unknowingly running with SGX code which mysteriously broke when we received the first batch of 3517's properly fused (i.e. true AM3505's)

    The changes we made are fuzzy for me now - if you have additional issues send another message and I'll put the time in to find them - but I remember we had a change (maybe 2) down in some driver code. It was definitely more than the clock change you mention.

    Good luck! ... Jim