Mele A2000 - can't boot anything but Android

(crossposted on the arm-netbook mailinglist)

Heya,

a few days ago I recieved my Mele A2000, but I was unable to boot
anything except the stock Android so far. *The stock Android works
perfectly fine.*

There are basically three different scenarios when booting:

• (most of the time) I get something like:
  
  

  Quote
  
  =====================================
  [ BUG: bad unlock balance detected! ]
  -------------------------------------
  swapper/0 is trying to release lock (&(&zone->lock)->rlock) at:
  [<c00ab6bc>] free_hot_cold_page+0x160/0x19c
  but there are no more locks to release!
  <1>Unable to handle kernel paging request at virtual address e1a00164

  
  Logs:
  http://p.cmpl.cc/3e8ce636
  http://p.cmpl.cc/89c6a10a
  http://p.cmpl.cc/db1d1345
• Sometimes it just hangs at:
  

  Quote
  
  <6>Console: colour dummy device 80x30
  Log: http://p.cmpl.cc/14dad45d

• Sometimes it hangs at:
  

  Quote
  
  <6>Total Detected Memory: 512MB with 1 banks
  <6>64 MB reserved for MALI

I already tried a lot of things:

• Tried different images (linaro, archlinuxarm, one or two ubuntu images)
• Tried different kernels (the images' kernels, rm's kernel, hardware packs)
• Tried copying the uImage to /sdcard via android and booting it with the stock uboot using fatload.
• Runned mtest (without arguments) in uboot-mmc the whole night long, without any errors.
• Copied the stock script.bin from NAND to the SD.

My hardware:

• Mele A2000 (duh!)
• Sticker on the side: HMC-G32A01 V1.6
• Sticker near the A10: V1.7
• on the PCB:
  AB10-G32-V1.20-2
  WLBM821-2400120-92
  2011-12-20
  (on the right) 12.22
• Memory: hynix H5TQ2G638FA H9C 218A - NTK8K219H2
  (note the 218A vs. 143AK on http://linux-sunxi.org/Mele_A1000)

The fex extracted from nanda: http://p.cmpl.cc/c3062000

Intrestingly it's very different to the script.bin I got with
archlinuxarm.
diff: http://p.cmpl.cc/e3fbf554

Some other changes compared to another script.bin I got from
http://lundman.net/wiki/index.php/MeLe_A2000 :
diff: http://p.cmpl.cc/5aa24001

So that's all I have for now... and I really have no idea what to do
so I can boot something. I have no use for an Android TV box and I
really don't want to have spent $100 on a thing I can't use :(

Thanks in advance for all help.

Florian

Same here :-(
except i succeed in unknown circumstance to make it boot my own kernel.

http://forum.doozan.com/read.php?6,9414,9462#msg-9462

The v1.7 sticker bug.
I suspect a stack corruption (early load process) somewhere in the kernel branch linux-allwinner-3.0-v2 but i was unable to find it. I'm a poor c user-land developer and sadly not a kernel dev.

That's odd. But the chip you refer to as "Micron" seems to be NAND to me, not RAM. The RAM is under the A10 in this "metal square".

Also I *think* there are other people with a v1.7 where it works fine.

Yes it's the nand ~Memory~ (Micron) ;-)
It was the first difference i've noticed.

I'm not sure v1.7 is working for other people.
I have 2 other a2000 v1.3 working nicely... but not the v1.7.


On the v1.7:
- Ram: hynix chips ending with 218A
- Nand: micron - 29F32G08CBACA

On the two other A2000 v1.3:
- Ram: hynix chips ending with 143AK
- Nand: hynix chip H27UBG8T2ATR - BC 147H

But in your thread you never mentioned you had the same errors as me, right? Did you have the same issues?

And any idea what you did so it booted?

Would you be good enough to try an SD image, or manually made SD with the u-boot from http://a10linux.org, and let me know if that works. If there is a problem with the existing Mele script.bin on the new Mele's it needs to be confirmed so we can get a new one posted for people to use. If the existing script.bin.mele does not work please post a link to a script.bin that does so I can get it in the a10linux download section. That will help everybody. I already know there are SATA issues with the existing script.bin.mele. But I have been waiting for somebody to confirm any type of DDR issue with the new Mele's before I post a new one.
Thx.

Florian,

In my second post in the thread, you will see my ttl boot log with test run between Android ICS and my kernel.
I'm getting the same error as yours like this one:
--
<3>huh, entered softirq 1 TIMER c006795c preempt_count 00000103, exited with 00000000?
<1>Unable to handle kernel paging request at virtual address f10c00a0
<1>pgd = c0004000
<1>[f10c00a0] *pgd=00000000
<0>Internal error: Oops: 5 [#4] PREEMPT
---

I have disable in my kernel many tricky features like cpufreq to check... without any success (this kernel boots flawlessly on v1.3).

When i get the v1.7 to boot (~5% of the time), it is independant of the kernel i try... my debian seems stable.

Also, the SATA was not working, always resetting. I tried:
- to change the SATA cable
- to switch the sata PCB with a working v1.3.
- sw_ahci_platform as a module.
Nothing worked. It's not an hardware problem (android/SATA is working).


Last time, after reflashing with ICS and many kernel retries, the NAND (with ICS on it) seemed corrupted! ICS was not able to boot anymore and i had to reflash it.

With your informations, i'm pretty sure something goes wrong with the stack (? ram related).



GNexus,

As far as i can tell, the script.bin helped a bit the v1.7 kernel Oops.
I tried many things (like using the script.bin of ICS from nanda) as told in my post: http://forum.doozan.com/read.php?6,9414
I was able to boot my kernel 2-3 times and it stopped to work.
I just don't get it and what is going on with this board.

I will try this week-end to make a full test with a nanda boot (if i get it to boot one time on my linux mmc):
Put my uImage in nanda/linux/ and using only the uboot and script.bin from ICS.
At least it will clear the script.bin / uboot from the suspect list.

Regards,
--
Guillaume

Quote
guillaume
In my second post in the thread, you will see my
ttl boot log with test run between Android ICS and
my kernel.
I'm getting the same error as yours like this
one:

At least I'm not the only one. Phew.

Quote
guillaume
I will try this week-end to make a full test with
a nanda boot (if i get it to boot one time on my
linux mmc):
Put my uImage in nanda/linux/ and using only the
uboot and script.bin from ICS.
At least it will clear the script.bin / uboot from
the suspect list.

You could also put uImage to /sdcard in android, and then do this in the android uboot:

fatload nand a 0x48000000 uimage
extraargs=rootwait
bootm 0x48000000

Quote
gnexus
Would you be good enough to try an SD image, or manually made SD with the u-boot from http://a10linux.org, and let me know if that works. If there is a problem with the existing Mele script.bin on the new Mele's it needs to be confirmed so we can get a new one posted for people to use. If the existing script.bin.mele does not work please post a link to a script.bin that does so I can get it in the a10linux download section. That will help everybody.

I can try with an U-Boot from there tomorrow. But as said, I'm unable to provide you with a working configuration, as I can't boot a Linux kernel even with the stock uboot.

Flo

Quote
The Computer
Tried copying the uImage to /sdcard via android and booting it with the stock uboot using fatload.

Quote
The Computer
You could also put uImage to /sdcard in android, and then do this in the android uboot:

Ok... you have already tried it.
thanks for your advise via uboot. need to study a bit of uboot ;-)

Last time, i nearly crashed the board with my keyboard but i will give it a new try tuning some stuff.
If i get a "50% of the time" booting kernel for this v1.7 (Yeah!) i will post it here with its config.
I'm already in a minimalistic kernel config compiled with gcc 4.7 hf... quite a dead end for my kernel skills.

Regards,
--
Guillaume

Florian,

I received today twelve a2000 (yes i'm building a cluster ;-)... All are v1.7 (bad luck). I picked two of them... Exact same bug.

So i worked earlier to get a working kernel.
This one is working for me on the three v1.7 i tried. Don't ask me why.

If you could try it on yours, it will be great.

HERE: http://db.tt/rvZ4BINR

The tgz containing:
working-v1.7-001/
working-v1.7-001/uImage
working-v1.7-001/boot.cmd
working-v1.7-001/config
working-v1.7-001/minicom.cap
working-v1.7-001/info.txt
working-v1.7-001/script.bin
working-v1.7-001/boot.scr

This version:
BRANCH > linux-sunxi-3.4
arm-linux-gnueabi-gcc-4.4

For now, it's my first 'everytime' working kernel for v1.7 + script.bin + kernel version / config.
I have not reduce yet all the parameters.
The script.bin is the one i've took from the android. I didn't fex it yet.

I let you know.

Regards,
--
Guillaume

Quote

BRANCH > linux-sunxi-3.4

Does that also mean the WIP linux-3.4 branch is working well now?

For now, i'm unable to build a fully working kernel like the 2.6 android or the 3.0 android on the v1.7 board.
I don't know why.

Most of the time (99%), the kernel stack explodes with null pointers and Oops.
The 1% working (like the one in my previous post) fails on sw_ahci_platform resetting all the time (non-stop reset).

I tried many combination between:
- gnuabi / gnuabihf: 4.4, 4.5, 4.7 (from emdebian)
- allwinner-v3.0-android-v2 (kernel Oops)
- amery/linux-2.6.36-sun4i with mmc sun4i added (unstable, sata not working)
- linux-sunxi-3.4 (stable with gnuabi but sata not working, gnuabihf kernel Oops)
- uImage 3.0.31 from http://www.lundman.net/ftp/mele/ (kernel Oops)
- rolled back in the allwinner-v3.0-android-v2 the arch/arm/mach-sun4i/* to the upstream android version (kernel Oops)

perhaps i will try to mess around gcc arm options...

Re-using the 2.6 android kernel (with its .ko and trying to add mine) seems to be my only alternative to have stable kernel and a working sata.

My new twelve v1.7 were shipped from hipboi.
I think this problem of compiled kernel from amery git will spread around.
I repeat the v1.3 board is working perfectly with every kernel i have compiled... this is sad.

Need help ;-)

Heya,

I'm relieved I'm not the only one who has this problem, so at least there is some hope some more skilled people than me will try fixing it ;)
I was a bit busy over the weekend, but I hope I can try your kernel tomorrow evening.

The other question would obviously be what changed hardware-wise between 1.3 and 1.7. It seems the NAND is now Micron, not Hynix, and the RAM is a slightly different IC, but the timing seems to be the same. So I really have no idea.

Florian

Gnexus,

a10linux.org is nice.
You have done a great job. We should move this thread to it if possible.

uboot multi seems awesome.
I have tried the kernel 3.0.39+ and u-boot multi. Same effect on the V1.7 board. kernel Oops. Sorry :-(


Tom Cubie replied about the problem after i asked him for help about this thread:

Quote
Tom
this is interesting.
you can try boot the kernel you compiled with the stock u-boot in nanda
and boot the stock kernel with u-boot you compiled. There is a bug in u-boot
spl that the clock is set to 1G that the voltage is not enough, but it
can boot in most chips. i don't know if it's related. if you can boot
the kernel you compiled with stock u-boot, the kernel is ok. then it's
the problem of u-boot spl.

Tried and failed:
- stock kernel + my u-boot => Working
- my kernel + stock u-boot => Not working.


Yesterday, i have moved to exactly the same compiler as Allwinner used:
Codesourcery arm-2010.09-50-arm-none-linux-gnueabi
(i had to chroot a 32bit debian ... i'm sick now)

No success with any kernel

I have tried:
allwinner-v2.6.36-android + sun4i_crane_defconfig

I just don't know what (TF) to do to make a kernel boot properly.
A cc option ?

Guillaume.

I've now tried guillaume's kernel (working-v1.7-001) with the newest uboot from a10-linux.org, without luck. Still getting random freezes, Oops or nullpointers.

If I can do anything to help you guys, let me know.
If anyone gets it to work, you are my hero and will probably receive a little donation if you want to.

Having a $100 paperweight (I don't need an android! :P) kinda sucks, and I have no idea what else to try.

The Compiler

Hi, this is strange.
I tried the working one on many a2000 and it is working.
You sometimes have to try 2-3 times to get a boot.
Despite this, the kernel is useless, i can not reproduce it.



I'm as stuck as you. Only the stock android kernel works (2.6 and 3.0).


I just need 3 thinks working:

- Wemac (always working)
- SATA (working on the stock kernel)
- IP_VS (tcp/udp, i'm unable to get a compatible module from sun4i_crane)

If someone could at least help me on the last item ;)

---- Original module working
# modinfo drv/sw_ahci_platform.ko
filename: /lib/modules/2.6.36-android/drv/sw_ahci_platform.ko
alias: platform:sw_ahci
license: GPL
author: Daniel Wang <danielwang@allwinnertech.com>
description: SW AHCI SATA platform driver
depends: libahci
vermagic: 2.6.36-android preempt mod_unload modversions ARMv7
----
---- My module compiled with sun4i crane, same chaintool, same all (i have tuned the name)
modinfo kernel/net/netfilter/ipvs/ip_vs.ko
filename: /lib/modules/2.6.36-android/kernel/net/netfilter/ipvs/ip_vs.ko
license: GPL
depends:
vermagic: 2.6.36-android preempt mod_unload modversions ARMv7
parm: conn_tab_bits:Set connections' hash size (int)
----

insmod -f kernel/net/netfilter/ipvs/ip_vs.ko
[ 756.490000] ip_vs: disagrees about version of symbol module_layout
Error: could not insert module kernel/net/netfilter/ipvs/ip_vs.ko: Invalid module format

???

Quote
The Compiler
If anyone gets it to work, you are my hero and will probably receive a little donation if you want to.

Same here ;)

GOT IT.

Tom is the man ! ;-) Thank you so much.

Quote
Tom
hi, can you do a modification of u-boot when booting from sd card with the u-boot
and kernel you compiled?

https://github.com/hno/uboot-allwinner/blob/sun4i/arch/arm/include/asm/arch-sunxi/clock.h#L141

change
#define PLL1_FACTOR_N 21
to
#define PLL1_FACTOR_N 16

It works for me now. 100% boot success with any kernel.
This is great. I'm relieved.

Seems to be finally the clock set too high in u-boot making the Mele act crazy and corrupting the stack.

Gnexus,
I tried uboot-multi-allwinner with the patch, it works too.

I think it should be pushed in amery git and could save hours to every one.

Florian,
Could you test the patch on yours ?

(For the Sata, still no magic... android working but not self compiled kernel - always resetting)

Quote

I have tried the kernel 3.0.39+ and u-boot multi. Same effect on the V1.7 board. kernel Oops. Sorry :-(

That sucks. . . I wish I could help more, but I (thankfully) don't have a 1.7 device to do testing on.

I am really starting to get the feeling Mele is not exactly supportive (to put it mildly) of the use of open source software on their devices. The latest Mele Android ICS upgrade has the NAND disabled in Linux. The NAND partitions show up in u-boot, and they are still formatted in ext4, but they are now hidden and will not mount in Linux. I had to revert to the original ICS image again. But there are no major changes in the new Mele images anyway.

The Cubieboard is looking better every day. But afaik they don't have any NAND at all.

Still, it is rather strange that the Android kernels work, and the others do not. I would first isolate out the script.bin and u-boot. Use the older Linux ones in Android to see if that affects the Android. If it does not then you can at least rule out those two things as having any effect, although that already seems fairly certain at this point.

Another thought is that maybe, just maybe, it has something to do with booting from MMC. So maybe you should try installing Linux to NAND and see if that makes a difference.

Gnexus,

Read my last post ;) it works !

Great news!

Looks like Hipboi may have managed to save his Mele business. . . ;)

Looks like our posts got crossed somehow. Mine should have been above yours.

I will also try to patch u-boot-multi with the above patch. It needs an Linux on NAND patch anyway. So that way I can kill two items before pushing out a new version.

(For the Sata, still no magic... android working but not self compiled kernel - always resetting)

I also had that issue, but for me it seems to have been resolved with the script.bin from the recent Mele Android. I think the issue varies with different drives. So you may want to try another drive or another script.bin.

Hello. Fresh Mele A2000 user and Linux/Android newbie (clueless)

I recieved my Mele A2000 yesterday and I want to install Linux on it. Ubuntu preferably since it's more noob friendly.
What I want from i box? well mainly to be able to use a torrent client to seed a few torrents from an external usb HDD. Speed is not very important since my upload is limited by ISP to 500KB/s.
I tried from the default Android that ships with the box, but clients are buggy and they reset torrent list upon device reboot. Kinda painful to check 100gigs of torrents (2-3big torrent packs) on every reboot.

Being a newbie in Linux I saw some nifty Linux SD card images on a10linux.org so I thought it will go smooth, but they don't seem to work (tried both Ubuntu and Debian). I "burned" them on SD card using win32diskimager.
What happens? With the device turned off I insert the SD card and power on. Blue led shows up and that's it...TV shows no signal and the blue led stays on. If I remove the SD card, after a few seconds the device proceeds to it;s normal Android boot.

My device is v. 1.7 so I see that there are some problems, but I saw that you guys managed to fix them so Linux could work on v.1.7 devices aswell?
If so is the case, any plans for an updated Ubuntu image that works?

Quote
ithanium2
If so is the case, any plans for an updated Ubuntu image that works?

The root image does not change a bit.

You just have to get a new u-boot.bin or wait for the gnexus update.
Here is mine (mmc single, not the great multi u-boot from gnexus): http://db.tt/6QB7geWV
And a sun4i-spl.bin just in case: http://db.tt/vANm95EH

Quote
Gnexus
Looks like Hipboi may have managed to save his Mele business. . . ;)

Seems to ;-)

Ok...so I am abit hard headed.
I thought I only have to burn that image to SD card plug it into Mele and presto...Linux box.

Can you explain what do i have to do with that u-boot.bin?

Quote
ithanium2
I thought I only have to burn that image to SD card plug it into Mele and presto...Linux box.

Ok, take a SD card. Burn the image to SD (/dev/mmcblk0 ? or any sdX - type 'dmesg' to be sure after plugging your SD) and do this (replace ${DEV} with your SD device) :

wget -nd http://db.tt/6QB7geWV -O u-boot.bin
wget -nd http://db.tt/vANm95EH -O sun4i-spl.bin

dd if=sun4i-spl.bin of=/dev/${DEV} bs=1024 seek=8
dd if=u-boot.bin of=/dev/${DEV} bs=1024 seek=32

it should do the trick with a single u-boot usage.

Screw the SD card.

I don't even bother with the SD anymore. . .

Besides:

mount /dev/nanda /mnt/misc
cp u-boot.bin /mnt/misc/linux

is much simpler to do!

Edit:
But you do need the NAND u-boot version (no patch yet for Mele 1.7).



Edited 1 time(s). Last edit at 09/14/2012 11:01AM by gnexus.

Quote

What happens? With the device turned off I insert the SD card and power on. Blue led shows up and that's it...

If you have a Mele then it makes zero sense not to have a serial console connected. It's a $2 cable. . .

Speaking of the NAND u-boot. . . I had an idea about all this early on:

Since it was a hardware issue, and it worked in Android, maybe boot1 in NAND (vs. MMC SPL) could be the cause.

Boot 1 is the Allwinner SPL for NAND. It initializes the hardware and loads u-boot on the NAND. Since the SPL is not used on a NAND boot it is a good possibility that the existing NAND u-boot multi-boot from a10linux may work.

Would somebody please test to confirm that existing multi-boot NAND u-boot does/does not work on 1.7?

And to go even further with the idea. The SPL in the MMC u-boot multi is actually from current uboot-allwinner. Since the new patch mainly affects the SPL it may be possible to use the new patched SPL with the existing MMC uboot-multi. I also need somebody to give that a try. Only takes a few seconds to dd the u-boot to an SD card. I would appreciate it greatly, and it would save waiting on a patched version if it works. . .



Edited 1 time(s). Last edit at 09/14/2012 11:20AM by gnexus.

Quote
gnexus
Since it was a NAND issue, and it worked in Android, ...

The u-boot / v1.7 issue solved by Tom was a clock PLL1 problem in u-boot.
PLL1 is the core PLL.

It is not linked at all with nand... at least as far as i know ;-)

Quote

The u-boot / v1.7 issue solved by Tom was a clock PLL1 problem in u-boot.
PLL1 is the core PLL.

I already know all that from the prior posts. . .

What I was noting is that the clock PLL initialization is mostly done in the SPL, and not in the main u-boot binary itself. So it may be possible to use the patched SPL with the existing u-boot, or vice-versa.

There are two parts to the MMC u-boot. There is the SPL which inits the hardware, and then u-boot itself which loads the kernel. Those are two separate things, and in uboot-multi they use separate code. If it is only the SPL that gets patched then the NAND u-boot will already work, and the current MMC u-boot will work with your existing patched SPL. If the patch affects the main u-boot binary then neither will work. Got it?

If you want me to get a new patched u-boot version I need answers to my questions above. I do not have a Mele 1.7 to test.
Thus I cannot do anything until my questions are answered on whether the existing u-boot works with the new SPL.

It is up to you, a Mele 1.7 owner, to test the existing uboot-multi with a patched SPL. . .
You can test either MMC or NAND, or preferably both. Also please test your patched u-boot with an old SPL.

Once that is done, and I know the results, I will implement a patch in u-boot multi.

No answers = no patched u-boot.

Even better would be to get the uboot-multi code and then patch it, and then submit the patch. But since I don't have 1.7 I can't do much until the questions are answered or a patch is submitted.

uboot-multi-allwinner is forked from uboot-allwinner, i have difficulties to understand the problem with patching directly uboot-allwinner and pull the patch in uboot-multi-allwinner.
This clock bug seems to generate huge unpredictible instabilities in the linux kernel.
It will be more secure to regenerate both u-boot.bin and spl in your a10linux.org pack just to be sure.

start.S (_start) -> start.S (reset) -> start.S (cpu_init_crit) -> lowlevel_init.S (lowlevel_init) -> board.c (s_init) -> clock.c (clock_init) -> PLL1_FACTOR_N
... seems to me in use in both SPL and u-boot.bin

My a2000 are working now (u-boot and sata), i'm not living 24/7 with them anymore ;-)
I will only be able to test it on monday in my office.
For the a2000 science and your friendly call for test, i will try this:
- multi u-boot with patched spl
- u-boot with patched spl
- patched multi u-boot with spl
- patched u-boot with spl

If you need a different test protocol, please tell me.

For now, all i can say is:
patched multi u-boot with patched spl : is working
patched u-boot with patched spl : is working