A2000 V1.6/1.7 Micron Memory Chip

Hello,

I received on Friday one new Mele A2000 (new version V1.6 on the PCB reference sticker and another sticker alone "V1.7" near the A10).
The only difference seems to be the memory chip: Micron.

The script.fex need to be modified to work, as the one decompiled from the nanda (just removing some info):

[dram_para]
dram_baseaddr = 0x40000000
dram_clk = 360
dram_type = 3
dram_rank_num =
dram_chip_density =
dram_io_width =
dram_bus_width =
dram_cas = 6
dram_zq = 0x7b
dram_odt_en = 0
dram_size =
dram_tpr0 = 0x30926692
dram_tpr1 = 0x1090
dram_tpr2 = 0x1a0c8
dram_tpr3 = 0x0
dram_tpr4 = 0x0
dram_tpr5 = 0x0
dram_emr1 = 0x0
dram_emr2 = 0x0
dram_emr3 = 0x0


It's backward compatible at least with V1.3 (my other board).


For now, the sata refuses to work on the V1.6/1.7 (work flowlessly on the V1.3)

Well loaded:
[ 551.090000] err: gpio count < =0 ,gpio_count is: 0
[ 551.090000] sw_ahci sw_ahci.0: controller can't do PMP, turning off CAP_PMP
[ 551.110000] sw_ahci sw_ahci.0: forcing PORTS_IMPL to 0x1
[ 551.120000] sw_ahci sw_ahci.0: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl platform mode
[ 551.130000] sw_ahci sw_ahci.0: flags: ncq sntf pm led clo only pio slum part ccc
[ 551.150000] scsi0 : sw_ahci_platform
[ 551.160000] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port 0x100 irq 56
[ 551.530000] ata1: SATA link down (SStatus 0 SControl 300)

But continiously reseting the link (sata works with android):

[ 583.400000] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen
[ 583.420000] ata1: irq_stat 0x00000040, connection status changed
[ 583.430000] ata1: SError: { DevExch }
[ 583.430000] ata1: hard resetting link
[ 585.670000] ata1: SATA link down (SStatus 1 SControl 300)
[ 585.670000] ata1: EH complete
[ 585.680000] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen
[ 585.690000] ata1: irq_stat 0x00000040, connection status changed
[ 585.700000] ata1: SError: { DevExch }
[ 585.710000] ata1: limiting SATA link speed to 1.5 Gbps
[ 585.720000] ata1: hard resetting link
[ 587.960000] ata1: SATA link down (SStatus 1 SControl 310)
[ 587.960000] ata1: EH complete
[ 587.980000] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen
[ 587.990000] ata1: irq_stat 0x00000040, connection status changed
[ 588.000000] ata1: SError: { DevExch }
[ 588.010000] ata1: limiting SATA link speed to 1.5 Gbps
[ 588.020000] ata1: hard resetting link
[ 590.260000] ata1: SATA link down (SStatus 1 SControl 310)
[ 590.260000] ata1: EH complete
[ 590.270000] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen
[ 590.280000] ata1: irq_stat 0x00000040, connection status changed
[ 590.290000] ata1: SError: { DevExch }
[ 590.300000] ata1: limiting SATA link speed to 1.5 Gbps
[ 590.310000] ata1: hard resetting link
[ 592.550000] ata1: SATA link down (SStatus 1 SControl 310)
[ 592.550000] ata1: EH complete
[ 592.560000] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen
[ 592.570000] ata1: irq_stat 0x00000040, connection status changed
[ 592.580000] ata1: SError: { DevExch }
[ 592.590000] ata1: limiting SATA link speed to 1.5 Gbps
[ 592.600000] ata1: hard resetting link
....

Any idea?

Regards,
--
Guillaume

Quote

But continiously reseting the link (sata works with android):

The SATA problem is a known issue. On my Mele/WD5000BEVT it resets down to 1.5Gbps but it works.

Quote

The only difference seems to be the memory chip: Micron.

Since your script.bin DDR config is shown I assume you are referring to the DDR. But "memory" can also refer to NAND in some people's posts. So it would help to be more specific on that in your posts.

I don't see how a change of DDR would neccessitate a new script.bin. From the look of your script.bin section it seems that may be the case. But if that is true then any of the Mele upgrade Android images might "brick" the device. So I can't see it.

Would you please d/l and verify that the script.bin from here does not work with your device.

Thanks.



Edited 1 time(s). Last edit at 08/27/2012 02:21PM by gnexus.

Hello,

Sorry for the lack of info, i was blind.
I have a usb-ttl now... and a third A2000 to test.

I think the first A2000 is broken.
The two others work perfectly with my custom kernel (nand partitionning and without sdcard now!).

Here is the full minicom log of the "broken" one (sticker v1.7): http://db.tt/xile3Mlc

Line 1: homlet4.0 reset
Line 684: android first boot: ok
Line 1684: android second boot: still ok
Line 2680: my kernel first boot on SD... panic
Line 2949: my kernel second boot on SD... panic a bit after
Line 3293: android boot still ok
Line 4289: my kernel third boot on SD... seems to start properly and freeze
Line 4661: android boot still ok
Line 5404: my kernel boot on SD... panic elsewhere.


This is the same kernel which is working perfectly on the two other A2000.
During another test, android (the nand?) got corrupted and refused to load (no backtrace on the UART).

My kernel config is here: http://db.tt/LrgdIgST
(wireless/cpufreq desactivated, sw_ahci_platform in module and some network ipv4 stuff activated like ipvs).
Nothing should harm.

Compiled with the vanilla git linux-allwinner and arm-linux-gnueabihf-gcc-4.7 (cross compiled on debian amd64).

I hope this could help. I'm a bit stuck with this one.

Regards,
--
Guillaume

gnexus

hi

there are likely problems with certain SATA drives with drivers/libata etc at around linux 2.6 (so thats where the stuff on GIT came from) .. same issues happened with MX53 .. I have posted this plus a bit of empirical testing on the GIT

https://github.com/amery/linux-allwinner/issues/40#issuecomment-8019254

Guillaume, try putting mele's android 4 on it and you will hopefully find it works, if you put hipboi's android 4 (based on the drivers etc from the GIT codebase) it wont work and likewise if you try whats on GIT it wont work

it is perhaps becuase GIT and hippboi used a lot of 2.6 codebase, libata etc wheras mele have used later drivers and codebase which (like other arm platforms dealt with it) .. one of the issues (on other arm platforms) was the introduction @ around linux 2.6.x of hot swapping which the 2.6.x drivers/libata etc couldnt eal with and so they saw the same messages and process as I (and you are likely seeing) .. so trying at half speed and then forgets about the drive .. recent (last couple of years) WD 2.5 drives are reported a common drive that has problems with 2.6.x

I tried with 2 different drives (a recent 640GB WD and also a old small toshiba 2.5) and same problem .. as i said they work absolutely perfectly with meles android 4 so theres no issue with the board or drive its a software issue, perhaps a config issue but more likely an issue with the old drivers/linux 2.6.x bits and pieces used in GIT

hope it helps

rgds

ian