Mele_HTPC_20121220_V1.3 SDCard version

I managed to automate the creation of a SDCard bootable version from a stock Android image, under linux.
Of course you will lose your data on SDCard, and you may lose data from your computer if you don't care enough about this infamous X letter!

As an example, here is the latest firmware from Mele (20 December 2012) on which I just modified the partition names (SDCard instead of NAND), changed the default language, and added the /etc/init.d stuff :
- get this: sdcard_Mele_HTPC_20121220_V1.3.tar.bz2
- get a 8GB SDCard (not less, the partitions are created depending on this minimal size)
- uncompress the above archive,
- as root, check the SD-Card device number (/dev/sdX), and perform: make DEV=/dev/sdX
- Optionally, mount /dev/sdX1 to edit uEnv.txt that contains the MAC address. Set it to your usual MAC address if needed.
- Once done, put this SDCard into your device, power-on and enjoy.

The original firmware is here: Mele_HTPC_家庭版_20121220_正式版_v1.3

Notes:
- A slow SDCard gives slow boot process. A Class 10 SDCard gives good results.
- This SDCard image won't modify the flashed firmware, you can revert to your NAND image simply by removing the SDCard, and rebooting.

The details on what it does
The process is quite simple:
1/ create partitions on SDCard
2/ format partitions
3/ fill the partitions with the interesting things (extracted from the Mele firmware).
Mandatory modifications from the original firmware are the nandX->mmcpblk0pX stuff in order to work properly, and to avoid this SDCard firmware to corrupt the flashed firmware .
You can easily modify the created partitions' content for customization.

Booting the Android ICS system from SDCard

Update: from the information below, I recently added the "recovery" partition, so it shifts partition numbers.
The mele flash kitchen_v2 contains scripts to generate the sdcard version, look here:
Mele A2000: my own Linux flash kitchen

Testing new firmwares could be a pain since everything is wiped out at each update.
My idea (an I see some people had the same idea before) is to write the Android partitions on sdcard and boot from it.

There are already Linux distributions that boot from SDCard, like ArchLinux:
http://archlinuxarm.org/platforms/armv7/mele-a100
I have taken this Linux distribution as the base system.

The principle is quite easy: take a SDCard u-boot, give it the Android kernel, create the Android partitions on SDCard, fill them to make Android happy, change all "nandx" references by "mmcblk0px" in init scripts.

The Android system boots and does not need any access to NAND, a good point since I can test firmwares without affecting my flashed one.

Partitioning

Under linux, I have partitioned the SDCard (SDHC class 10, for boot speed) with fdisk.
Here is the resulting partitions:

Note that a free space of 16MB is kept at start of sdcard, it embeds the spl bootloader
I put 4GB for "data" and 10GB for /sdcard (16GB SDCard gives lot of space).
Exact size doesn't matter; if you set to 15,95MB one partition, that's not a big issue. The important thing is the number of partitions, see below.

So the matching nand-sdcard partitions are:

-nand- -sdcard-   -name-      -format-

nanda  mmcblk0p1  bootloader  vfat

nandb  -N/A-      env

nandc  mmcblk0p2  boot        ext4

nandd  mmcblk0p3  system      ext4

nande  mmcblk0p5  data        ext4

nandf  mmcblk0p6  misc        ext4

nandg  -N/A-      recovery

nandh  mmcblk0p7  cache       ext4

nandi  mmcblk0p8  private     vfat 

nandj  -N/A-      sysrecovery

nandk  mmcblk0p9  UDISK       vfat

Note: I just found out that link: http://linux-sunxi.org/Android/partitions
Almost same thing...
Note(2): under linux, mmcblk0p1 is /dev/sdb1, mmcblk0p2 is /dev/sdb2, ...

Filling partitions

Then I formatted partitions using mkfs.vfat for FAT partitions, and mkfs.ext4 for ext4 partitions that need to be formatted (look at the above table for the ones that need to be formatted, the others will be formatted by Android).

Then, from ArchlinuxARM/Mele-Bootloader I did:

# write SPL

dd if=sun4i-spl.bin of=$DRIVE bs=1024 seek=8

# write mele u-boot

dd if=mele-u-boot.bin of=$DRIVE bs=1024 seek=32

where DRIVE is /dev/sdb is sdcard is on sdb.

In the bootloader partition, I put the Mele's script.bin, and the Mele's kernel (the 3.0.8+ one), transformed into a u-boot image using this:

mkimage -A ARM -C none -T kernel -O linux  -a 40008000 -e 40008000 -d zImage uImage

I added uEnv.txt:

boot_mmc=fatload mmc 0 0x43000000 ${fexfile}; fatload mmc 0 0x48000000 ${kernel}; bootm 0x48000000

extraargs=rootwait init=/init mac_addr=00:BA:D0:MA:C0:FF

fexfile=script.bin

The "boot" partition contains the initrd contents of root.fex, and must be in mmcblk0p2 (default root partition of the spl u-boot, you can change it with root=xxx in extraargs variable)

The "system" partitions contents the files of the /system partition (system.fex mounted partition)

That's all.

Changing init scripts

In "boot" partition, you need to edit init.sun4i.rc and uevent.sun4i.rc, to change all "nandX" references into "mmcblk0pN" references conforming to the above table.

grep -r nand * shows you all the files that need to be modified.

In the same manner, change /system:

bin/sop.sh

bin/preinstall.sh

bin/data_resume.sh

etc/vold.fstab

The proof

Here is the mount table from my functional system:

root@android:/ # busybox mount                                                                                                      

rootfs on / type rootfs (rw)                                                                                                        

/dev/root on / type ext4 (ro,relatime,user_xattr,barrier=1,data=ordered)                                                            

devtmpfs on /dev type devtmpfs (rw,relatime,size=156796k,nr_inodes=39199,mode=755)                                                  

tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)                                                                              

devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)                                                                  

proc on /proc type proc (rw,relatime)                                                                                               

sysfs on /sys type sysfs (rw,relatime)                                                                                              

tmpfs on /mnt type tmpfs (rw,relatime,mode=777,gid=1000)                                                                            

tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)                                                                       

tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)                                                                        

/dev/block/mmcblk0p3 on /system type ext4 (ro,relatime,user_xattr,barrier=0,data=ordered)                                           

/dev/block/mmcblk0p5 on /data type ext4 (rw,nosuid,nodev,noatime,user_xattr,barrier=0,journal_checksum,data=ordered,noauto_da_alloc)

/dev/block/mmcblk0p7 on /cache type ext4 (rw,nosuid,nodev,noatime,user_xattr,barrier=0,journal_checksum,data=ordered,noauto_da_alloc

)                                                                                                                                   

/dev/block/mmcblk0p8 on /mnt/private type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=ascii,sh

ortname=mixed,errors=remount-ro)                                                                                                    

/dev/block/vold/179:1 on /mnt/extsd/179_1 type vfat (rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1023,fmask=0702,dmask=0702

,allow_utime=0020,codepage=cp437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)                                            

/dev/block/vold/179:6 on /mnt/extsd/179_6 type vfat (rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1023,fmask=0702,dmask=0702

,allow_utime=0020,codepage=cp437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)                                            

/dev/block/vold/179:8 on /mnt/extsd/179_8 type vfat (rw,nosuid,nodev,noexec,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage

=cp437,iocharset=ascii,shortname=mixed,errors=remount-ro)                                                                           

/dev/block/vold/179:9 on /mnt/extsd/179_9 type vfat (rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1023,fmask=0702,dmask=0702

,allow_utime=0020,codepage=cp437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)                                            

And the storage screenshot:

Handling nand flash to save/recover data using ArchLinuxArm

When booting from SDCard under linux, it is possible to access the NAND partitions.
I use ArchLinux ARM, following this tutorial: Mele A100, the only bootable image that gets correctly the NAND partitions (as under Android ICS). I changed the MAC entry in script.bin in order to have a well-known MAC address for ssh.

Under Android ICS, partitions are defined like this:

-dev-  -name-        -start-       -size-       -mountpoint-


nanda  bootloader  : 1000000       01000000      u-boot
nandb  env         : 2000000       01000000      N/A (u-boot environment)
nandc  boot        : 3000000       02000000      initrd in RAM as / + kernel
nandd  system      : 5000000       20000000      /system
nande  data        : 25000000      60000000      /data
nandf  misc        : 85000000      01000000      "boot-recovery" or 0xff*
nandg  recovery    : 86000000      02000000      N/A (recovery image)
nandh  cache       : 88000000      08000000      /cache
nandi  private     : 90000000      01000000      /mnt/private
nandj  sysrecovery : 91000000      20000000      /mnt/sysrecovery
nandk  UDISK       : b1000000      3b000000      /sdcard

Under Linux, partitions are detected correctly (the following line shows something comparable to the above output):

echo "-dev-  -size-";cat /proc/partitions|while read x y size dev; do echo "$dev  `printf %08x $(( $size * 1024 ))`";done
[...]
-dev-  -size-
[...]
nanda  01000000
nandb  01000000
nandc  02000000
nandd  20000000
nande  60000000
nandf  01000000
nandg  02000000
nandh  08000000
nandi  01000000
nandj  20000000
nandk  3c800000
[...]

As a consequence, you can read/edit/save data from NAND using a linux distribution.

Important note: don't write on Android ICS mounted partitions, you can corrupt data!
Use cases:

1/ list installed application in /data:

mount -o noatime,nosuid,nodev,barrier=0,journal_checksum,noauto_da_alloc /dev/nande /mnt #this is how Android mounts ext4 partitions, look at init.sun4i.rc for special nand mount options.

ls -l /mnt/app/

-rw-r--r-- 1 1000 1000  4707663 Nov  5  2012 com.adobe.flashplayer-1.apk       

[...]

2/ backup a NAND partition locally:

dd if=/dev/nande bs=4096 |bzip2 -c >/root/nande.bz2

3/ backup a NAND partition via ssh (assuming my ssh server is at @192.168.1.124):

dd if=/dev/nande bs=4096 |bzip2 -c | ssh user@192.168.1.124 dd of=/home/user/nande.bz2

4/ restore a NAND partition locally:

bzip2 -cd /root/nande.bz2 | dd of=/dev/nande bs=4096

sync

5/ restore a NAN partition via ssh:

ssh user@192.168.1.124 bzip2 -cd /home/user/nande.bz2 | dd of=/dev/nande bs=4096

6/ make a tar.bz2 archive of a partition contents (for huge partitions, instead of saving raw data):

mount -o noatime,nosuid,nodev,barrier=0,journal_checksum,noauto_da_alloc /dev/nande /mnt
cd /mnt
tar jcf - .|ssh user@192.168.1.124 dd of=/home/user/nande.tar.bz2
cd
umount /mnt

Using these commands, you can save/restore completely some essential partitions before a crash or a new firmware flashing procedure (/data essentially, /sdcard contains user data - movies, ... - that you should save in another place by other means).

Creating a dd-able image (Mele_4.0_V1.3BETA_revised_en_us_4.img.bz2)

I saw the lundman method (see conversation: http://ibot.rikers.org/%23arm-netbook/20120702.html.gz, 03:01.59):
- dd if=/dev/zero of=/dev/sdx bs=4096 count=128000 #an image does not exceed 512MB, and I take 4096 as blocksize for read/write flash speedup.
- flash the firmware on the sdcard using PhoenixCard,
- using fdisk -l /dev/sdx you know the FAT partition begin, and as as consequence, the hidden partition end.
- hexdump the /dev/sdx -s <at supposed end of last partition>, see when it gets some zero, you have the real end of the flash image.
Example, on Mele_4.0_V1.3BETA_revised_en_us_4.img
Result: Mele_4.0_V1.3BETA_revised_en_us_4.ddimg.bz2
I flashed my firmware on my sdcard, that is shown as /dev/sdb.

fdisk -l /dev/sdb shows (I have a 2GB  SDCard):

Disk /dev/sdb: 1967 MB, 1967128576 bytes
1 heads, 62 sectors/track, 61968 cylinders, total 3842048 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *      695166     3839998     1572416+   b  W95 FAT32

Start of the visible partition is at 695166 sector # (means at 695166*512=355924992 bytes):

xxd -a -skip 355924992 /dev/sdb
1536fc00:eb3c 904d 5344 4f53 352e 3000 0208 2000  .<.MSDOS5.0... .
1536fc10:0200 0000 00f0 0000 0000 0000 0000 0000  ................
1536fc20:81fc 2f00 fd0b 0000 0000 0000 0200 0000  ../.............
1536fc30:0100 0600 0000 0000 0000 0000 0000 0000  ................
1536fc40:8000 296f 0000 0020 2020 2020 2020 2020  ..)o...         
1536fc50:2020 4641 5433 3220 2020 0000 0000 0000    FAT32   ......
1536fc60:0000 0000 0000 0000 0000 0000 0000 0000  ................
*
1536fdf0:0000 0000 0000 0000 0000 0000 0000 55aa  ..............U.
1536fe00:0000 0000 0000 0000 0000 0000 0000 0000  ................
*
15373c00:f8ff ffff ffff ffff ffff ff0f 0000 0000  ................
15373c10:0000 0000 0000 0000 0000 0000 0000 0000  ................
*
154f3600:f8ff ffff ffff ffff 0000 0000 0000 0000  ................
154f3610:0000 0000 0000 0000 0000 0000 0000 0000  ................
*
15673000:2020 2020 2020 2020 2020 2008 d0da e18c             .....
15673010:6441 6441 0000 e18c 6441 0000 0000 0000  dAdA....dA......
15673020:0000 0000 0000 0000 0000 0000 0000 0000  ................
*
1576fc00:f8ff ffff ffff ff0f ffff ff0f 0000 0000  ................
1576fc10:0000 0000 0000 0000 0000 0000 0000 0000  ................
*
15943600:f8ff ffff ffff ff0f ffff ff0f 0000 0000  ................
15943610:0000 0000 0000 0000 0000 0000 0000 0000  ................
*
15b17000:2020 2020 2020 2020 2020 2008 0000 0000             .....
15b17010:0000 0000 0000 0000 0000 0000 0000 0000  ................
... and nothing more until a little time.

Remember: I zeroed 4096*128000 bytes, I must find out the end, where there are many zeroes until this limit (4096*128000=0x1f400000).

In this case: 0x15b17010 seems to be the end of my FAT32 partition.

So you can suppose that the end of image (including the fat32 partitions) is at 0x15b17010.

0x15b17010 makes in decimal: 88856 blocks of 4096 bytes (rounded up).

dd if=/dev/sdb bs=4096 count=88856 |bzip2 -9 > Mele_4.0_V1.3BETA_revised_en_us_4.ddimg.bz2

The resulting file is a compressed dd-able image.

To write this dd-able image, you can perform:

bzip2 -cd Mele_4.0_V1.3BETA_revised_en_us_4.ddimg.bz2|dd of=/dev/sdx bs=4096

Mele_HTPC_0929_BETA_V1.3 Revised version: en_US v4

Another release that fixes the "reboot never ends" bug after having launched Google Play:
Mele_4.0_V1.3BETA_revised_en_us_4.img

On 4shared:
Mele_4.0_V1.3BETA_revised_en_us_4.img(4shared)
Mele_4.0_V1.3BETA_revised_en_us_4.ddimg.bz2(4shared)

Edit: md5sum=70aee0c6ae9c375e72d3f87bed594ef0  Mele_4.0_V1.3BETA_revised_en_us_4.img 
        dd-able image: Mele_4.0_V1.3BETA_revised_en_us_4.ddimg.bz2
        md5sum=ea14dab60e131feac04f20a7947291e9  Mele_4.0_V1.3BETA_revised_en_us_4.ddimg.bz2

Precision: this release disables the Google Play updates automatically (via a /etc/init.d/ script), that makes the bug occur. You don't need to perform the steps mentioned hereafter if you take it.

I hope this will be the last under Android 4.0 (next will be 4.1 JellyBean when Mele decides to release it).
After many tries (copy Vending.apk from old firmware, revert all /system/app and /system/framework, ...), nothing solved the "reboot never ends" issue.

Then I had the idea to revert the Market update (go to Paremeters->Applications->All->"Google Play"->"Uninstall updates".
And yes, it works. The Market update is what makes the system fail.

So the solution is to disable the Market update definitely. I don't know the consequences on a long term period, but for this release, no more "reboot never ends" issue.
In order to disable the Market update, see this thread: (How-to) prevent Android Market app from updating itself, that says:

Do "uninstall updates" on the market app (in "manage applications").
Open the terminal app.
Run "su" to become root.
Run: touch /data/app/com.android.vending-1.apk
Run: chattr +i /data/app/com.android.vending-1.apk

You can perform only "uninstall updates" step, but you will have to do that at each reboot.

In the above image, there is a init.d script that performs the required touch+chattr operations automatically.
I also removed the last Chinese application (sorry for them).

Note for Chinese people: this fix should apply on the Chinese firmware, but you have to add these lines in the init.rc script (on post-fs-data) since there is no init.d system in the original firmware.

Mele_HTPC_0929_BETA_V1.3 Revised version: en_US v3

Here is a new firmware version:
Mele_4.0_V1.3BETA_revised_en_us_3.img

Update: please forget this firmware, look at: http://tmerle.blogspot.fr/2012/11/melehtpc0929betav13-revised-version.html

What is fixed:

- fixed the reboot bug. Many thanks to tuscanman from the Russian forum 4pda.ru that gave the solution. Google Market did not get the right permissions, fix inside android.policy.jar: http://4pda.ru/forum/index.php?showtopic=342683&st=1420

- added the xpad.ko kernel module (/system/vendor/modules/xpad.ko, http://melea1000.blogspot.co.uk/2012/08/xbox-360-controller-errors.html )

- added the /etc/init.d/ facility. At boot, all scripts inside this directory will be called. This allows the user to run custom commands at boot (look at the script 99test that writes a test file at boot). You can add commands in this script or clone it to add some other commands (like insmod /system/vendor/modules/xpad.ko)

- called mksh where busybox sh is not really necessary in startup scripts. Abuse of busybox eats memory, well this gives minor effect.

Edit: the reboot bug stilll persist, I still get a system hang at reboot... sadly.
Edit(2): I just saw that on the serial console you have a login. Here is the logcat output, need to analyse it now...: logcat_reboot_fail.log

Mele_HTPC_0929_BETA_V1.3 Revised version: en_US [again]

To be short, don't use the firmware in my previous post, generated a firmware from the update.zip provided on this site: http://bbs.mele.cn/showtopic-1102.aspx
Use this one:
Mele_4.0_V1.3BETA_revised_en_us_2.img
The reboot bug is still present (reboot never ends). Here is a typical console log: minicom_fail.cap

For the long story:
The previous firmware was buggy:
Mele_HTPC_0929_BETA_V1.3 Revised version: en_US is easy
Bugs:
1/ Going back from sleep mode, with F10 remote plugged-in, CPU consumption gets to 100% due to system_server.
The root cause is an additional library (that was not present in firmware 1.1), that adds some event capabilities to the F10 remote. But adds so many spurious events that it makes the system behave slowly.
The events can be seen doing "adb logcat".
Example:

D/Sensors ( 155): Sensor data: t x,y,z: 0.000000 0.000000, 0.000000, 0.000000
D/Sensors ( 155): Sensor data: t x,y,z: 3387016.000001 0.000000, 0.000000, 0.000000
...
I/EventHub( 155): Removing device '/dev/input/js0' due to inotify event
I/EventHub( 155): Removing device '/dev/input/event4' due to inotify event

The additional library is: /system/lib/hw/sensors.exDroid.so

2/ Some users burned this firmware, but it does not go further than the boot animation step.
I experienced this issue, but not at first boot (after several installs).
On the serial console you can see the consequence of this bug (I did not record the logs but should look like this):
init: waitpid returned pid 139, status = 00000009
init: process 'netd', pid 139 exited
init: process 'media', pid 140 exited
... in a loop.
It comes most probably from memory shortage at start. When memory is needed, Android kills background processes. But if background processes are essential to the system start... it fails.

As a consequence, in this _2 firmware image:
1/ renamed /system/lib/hw/sensors.exDroid.so into /system/lib/hw/sensors.exDroid.so_deactivated so that the system does not load it
2/ busybox is relatively huge:

size system/bin/busybox
   text   data    bss    dec    hex filename
1457781   2496  18304 1478581 168fb5 system/bin/busybox

compared to toolbox:

size system/bin/toolbox
   text    data     bss     dec     hex filename
  90234    7552   21348  119134   1d15e system/bin/toolbox
and mksh:

size system/bin/mksh
   text   data    bss    dec    hex filename
 143144   3184  19572 165900  2880c system/bin/mksh



So I re-applied the "toolbox" symlinks to minimize the busybox impacts,and replaced
/system/bin/sh -> busybox
by
/system/bin/sh -> mksh
Also, I replaced in /system/bin/preinstall.sh the shell:
#!/system/bin/busybox sh
by
#!/system/bin/sh
so that it loads mksh instead of busybox (for just a if [ ] then elif, should be sufficient).

Hope it works...

Mele_HTPC_0929_BETA_V1.3 Revised version: en_US is easy

The 1.3 beta revised version (http://tmerle.blogspot.fr/2012/10/melehtpc0929betav13-revised-version.html) comes as an update.

It contains the original launcher as expected (at start, you have the choice in the launcher), with Google Play, and busybox commands are symlinked.

Edit: here is the equivalent PhoenixCard image, customized in en_US:
Mele_4.0_V1.3BETA_revised_en_us.img
Edit(2): Look at my updated firmware, fixing the CPU hog bug: http://tmerle.blogspot.fr/2012/10/melehtpc0929betav13-revised-version_22.html

Since this is an update.zip, no more PhoenixCard flashing process is needed, just a vfat formatted sdcard as a base media is sufficient.

From the archive, put on your sdcard:

- MeleTool.apk

- recovery.img (this is a CWM recovery image with Mele F10 recognition)

- bootloader.img (choose your flavor depending on the desired output VGA, HDMI,...)

- update.zip

You can edit system/build.prop in update.zip at your convenience. For example, you can setup the updated system in en_US directly.

So my customization is only a modified build.prop that you can put into update.zip (be careful to put it in system/)

Insert the SDCard in the device, install MeleTool.apk

Then launch the MeleTool.

Choose the option #4 talking about "Recovery" (wait a little so that the recovery img is written in nandg flash)

Choose the option #5 talking about "bootloader", the device will reboot after having written down in flash the nanda bootloader.

At this stage the device is stuck since it tries to boot on SD, remove SD, remove power, put power.

You should enter into CWM recovery. Insert again the SD.

Choose "apply sdcard:update.zip" (wipe data/cache before if needed)

After that, reboot and you are done.

Mele_HTPC_0929_BETA_V1.3 Revised version

Another version of the V1.3 Beta release:
http://bbs.mele.cn/showtopic-1102.aspx
Direct link to firmware: Mele_HTPC_0929_BETA_V1.3 Revised version
With a new package: Mele tools: http://bbs.mele.cn/attachment.aspx?attachmentid=1525
This application enables in order:
- shutdown,
- reboot in normal mode,
- reboot in recovery mode,
- write recovery img from SDCard
- write bootloader.img from SDCard
- go on the weibo site (don't know what for)

I found here: http://www.hdpfans.com/thread-156730-1-1.html some explanations about this newest firmware modifications, seems to be rebased on the V1.1 version instead of the V1.2 version, and based on the v1.1 launcher.

I experienced system latencies with the previous v1.3 beta and now it refuses to boot.
Downloading to see if it works better...

Mele Android 4.0.4 ICS firmware v1.3 en_US customized

New Mele firmware: http://www.slatedroid.com/topic/36614-mele-a1000a2000-install-cwm-cm9aokp-all-mods/page__view__findpost__p__437531
Its name is Mele_HTPC_0929_BETA_V1.3.rar
but the changelog does not show many improvements...

Nevertheless I customized this one here: Mele_4.0_V1.3BETA_custom_en_us_apex.img

I made the same customizations:
- replacing the stock /system/app/Launcher2.apk by ApexLauncher
- removing /system/app/Mele_Launcher.apk
- adding /system/app/Vending.apk (Google Play)
- removing preinstalled applications (7StationGame_v1.1.15_DXsigned.apk 360buy_TV_v1.0.1_meleTV.apk Googlepinyin.apk MELE4.0_wasu_1.0.0.6_0906.apk QQ_1.9.1.apk VoolePlayV1.0SP4_mailea10_20251.apk AdobeFlashPlayer11.1.112.60.apk)
- adding service.adb.tcp.port=5555 in build.prop

- adding adobe flash player (http://forum.xda-developers.com/showthread.php?t=1288287)

- adding Andrew patch 1.0.apk 

This time I managed to preinstall these things automatically at first start. A script named /system/bin/preinstall.sh is here to perform that, I just patched it in order to load packages from /system/preinstall/ instead of /sdcard/preinstall.

Mele A2000: my own Linux flash kitchen

Here it is, my own linux flash kitchen that I used to generate customized ROM images for my Mele HTPC.
Mele flash kitchen for ICS, here: mele_flash_kitchen_2.tgz
This runs only on linux (Slackware, but should work on Ubuntu and so on).

It is based on the A10 flash kitchen v2, with adaptations to run on linux, and based on this topic on Miniand
I have chosen to strip down this kitchen into a packer_ics only version for Mele since this is the one I was interested in.
You still need Windows to flash on SDcard the resulting output.img, using Phoenixcard (the only tool that I was not able to run under linux with wine)

My scripts are derived from the .bat scripts found in A10 flash kitchen (e.g. extract_image.bat is now img_e1xtract.sh) that run under Windows, but I feel safe to perform all the required operations in only one operating system.
You will find a README.txt at the root directory of the extracted archive.

v2: I added the sdcard bootable kitchen.
After having put the original.img file (PhoenixCard source image), run "make build_sdcard" as root and it should create everything needed to generate the sdcard bootable image in sdcard/
Then, you will have to cd sdcard/ , then run make DEV=/dev/sdX (where X is the device letter of your sdcard).
Read this post for more information on that: Booting the Android ICS system from SDCard

Requirements:
wine, in order to extract/build the flash image.
root access, for scripts other than img_1extract.sh/img_2build.sh.
The script will create /system in your root directory. This is necessary if you make symbolic links in "system" filesystem.
Of course, you need an original image (that you will rename as original.img) to start hacking.

Many thanks to Sztupy for the A10 flash kitchen, and to Miniand Tech for the detailed tutorial!

New new Mele ICS 4.0.4 firmware released: mele_HTPC_120909_V1.2 blue sky

Again a new Mele firmware:
mele_HTPC_120909_V1.2 blue sky UI
from its name I suspect a more out-of-China friendly firmware (i.e. without the specific frontend).

Here is the original forum: http://bbs.mele.cn/showtopic-925.aspx


"Andrews patch 1.0.apk" patch in order to get sound in some videos:
http://pan.baidu.com/share/link?uk=3123134845&shareid=2544&fr=104317572&fa=104317572

Edit: this is an update.zip and not a complete firmware.
From the bbs.mele.cn site, you must follow this tutorial:

http://bbs.mele.cn/showtopic-941.aspx
(click on the first link in the post)
but I guess the slatedroid.com method should work:
Mele A1000/A2000 install CWM & CM9/AOKP. All mods.

Mele Android 4.0.4 ICS firmware v1.2 en_US customized

Well, I managed to create a custom rom:
- replacing the stock /system/app/Launcher2.apk by ApexLauncher
- removing /system/app/Mele_Launcher.apk
- adding /system/app/Vending.apk (Google Play)
- removing preinstalled applications (7StationGame_v1.1.15_DXsigned.apk 360buy_TV_v1.0.1_meleTV.apk Googlepinyin.apk MELE4.0_wasu_1.0.0.6_0906.apk QQ_1.9.1.apk VoolePlayV1.0SP4_mailea10_20251.apk AdobeFlashPlayer11.1.112.60.apk)
- adding service.adb.tcp.port=5555 in build.prop
And everything seems to run fine!

I changed the localization: en/US so that the first start is quite easy for everyone.

The file is here Mele_4.0_V1.2_custom_en_us_apex.img

Edit: you still need to run the "Andrews patch 1.0.apk" patch in order to get sound in some videos:
http://pan.baidu.com/share/link?uk=3123134845&shareid=2544&fr=104317572&fa=104317572

New Mele ICS firmware v1.2

As JP noticed, a new official Mele firmware has been released:
http://www.reddit.com/r/Mele/comments/znrbz/official_mele_ics_rom_v12_released_9812/
I found out a discussion on Mele on reddit:
http://www.reddit.com/r/Mele

As usual, the Phoenix firmware software contained in this archive is still 3.0.3 so be careful to find out the 3.0.6 version under Windows 7.

MELE_android_4.0_vision 1.1 flash failure on Windows 7, bad PhoenixCard version!

In the previous post (New Mele A1000/A2000 ICS Android 4.0.4 firmware released) I announced a new firmware.
Seems that it fails to be flashed with PhoenixCard 3.0.3 on Windows 7 (thanks to JP for pointing it out, see the old post comments)
On mele.cn forum: http://bbs.mele.cn/showtopic.aspx?topicid=751&page=end someone has the same issue.
I never noticed this since I flashed from a Windows XP virtual machine.
The solution is to upgrade to PhoenixCard 3.0.6 on Windows 7, or run the tool on Windows XP.

I made a video from a Mele A2000 flash failure process. I got that when I was tweaking my firmware (missing DISKFS file):
Mele A1000/A2000  flash failure

Flash success sequence, for reference: Mele A1000/A2000 flash success.

New Mele A1000/A2000 ICS Android 4.0.4 firmware released

I was quite happy with the latest official Mele firmware except blank screens on Youtube/Flash/video (for example in MxPlayer).
A new firmware has been released to fix this issue, and to enhance some other things:
Mele.cn Download center for 2012-08-10 4.0.4 firmware

(archive name: MELE_android_4.0_vision 1.1.rar)
Additional note: there is an issue with Windows 7 PhoenixCard (thanks to JP for pointing it out), see my next post.

Mele A2000 custom firmware failure... fixed!

Indeed, the sole issue was the missing "DISKFS_000000000" file in image.cfg.

In a10_flash_kitchen_v2, here is the complete diff with the original file:

diff -uN files/image.cfg.orig files/image.cfg
--- files/image.cfg.orig 2012-02-15 13:15:08.000000000 +0100
+++ files/image.cfg 2012-08-09 13:33:47.264226709 +0200
@@ -58,17 +58,18 @@

     {filename = INPUT_DIR .. "_output\\bootfs.fex",           maintype = ITEM_ROOTFSFAT16, subtype = "BOOTLOADER_00000",},
     {filename = INPUT_DIR .. "_extract\\RFSFAT16_ENVIROMENT_00000.fex",           maintype = ITEM_ROOTFSFAT16, subtype = "ENVIROMENT_00000",},
+    {filename = INPUT_DIR .. "_extract\\RFSFAT16_DISKFS_000000000.fex",           maintype = ITEM_ROOTFSFAT16, subtype = "DISKFS_000000000",},
     {filename = INPUT_DIR .. "_input\\root.fex",   maintype = ITEM_ROOTFSFAT16, subtype = "BOOT_00000000000",},
     {filename = INPUT_DIR .. "_input\\system.fex", maintype = ITEM_ROOTFSFAT16, subtype = "SYSTEM_000000000",},
     {filename = INPUT_DIR .. "_input\\recovery.fex",   maintype = ITEM_ROOTFSFAT16, subtype = "RECOVERY_0000000",},
-    {filename = INPUT_DIR .. "_extract\\RFSFAT16_OEM_000000000000.fex", maintype = ITEM_ROOTFSFAT16, subtype = "OEM_000000000000",},
+;    {filename = INPUT_DIR .. "_extract\\RFSFAT16_OEM_000000000000.fex", maintype = ITEM_ROOTFSFAT16, subtype = "OEM_000000000000",},

     {filename = INPUT_DIR .. "_output\\vboot.fex", maintype = ITEM_ROOTFSFAT16, subtype = "VBOOTLOADER_0000",},
     {filename = INPUT_DIR .. "_extract\\RFSFAT16_VENVIROMENT_0000.fex",           maintype = ITEM_ROOTFSFAT16, subtype = "VENVIROMENT_0000",},
     {filename = INPUT_DIR .. "_output\\vroot.fex", maintype = ITEM_ROOTFSFAT16, subtype = "VBOOT_0000000000",},
     {filename = INPUT_DIR .. "_output\\vsystem.fex", maintype = ITEM_ROOTFSFAT16, subtype = "VSYSTEMFS_000000",},
     {filename = INPUT_DIR .. "_output\\vrecovery.fex", maintype = ITEM_ROOTFSFAT16, subtype = "VRECOVERYFS_0000",},
-    {filename = INPUT_DIR .. "_extract\\RFSFAT16_VOEM_00000000000.fex", maintype = ITEM_ROOTFSFAT16, subtype = "VOEM_00000000000",},
+;    {filename = INPUT_DIR .. "_extract\\RFSFAT16_VOEM_00000000000.fex", maintype = ITEM_ROOTFSFAT16, subtype = "VOEM_00000000000",},

     {filename = INPUT_DIR .. "_extract\\BOOT    _BOOT0_0000000000.fex",             maintype = ITEM_BOOT,   subtype = "BOOT0_0000000000",},
     {filename = INPUT_DIR .. "_extract\\BOOT    _BOOT1_0000000000.fex",             maintype = ITEM_BOOT,   subtype = "BOOT1_0000000000",},

Now the flash process succeeds, and the Mele HTPC boots succefully.

And I can begin to hack this box!

The sole thing that bothers me is the SDCard flash process that is still under Windows (using PhoenixCard), this is the only operation I need to perform under Windows.

My intention is to keep Android on this box. No linux distribution can boot as fast as Android, and Android is linux, why changing something that works?

Furthermore, it is possible to run linux commands on top of an Android OS (using the "chroot" trick), so my armedslack distribution will be able to run concurrently on this box.

To be continued...

Mele A2000 custom firmware failure... found

The box opening is painless (4 screws under, 2 at the rear - all the same type):

OK, wired the serial TTL-to-USB line, only GND, Rx, Tx, paying attention to cross Rx/Tx lines:

And during the flash operation of my custom image, the last log lines are:

[     130.560] normal type verify
[     131.130] pc sum=0x17135c9f, check sum=0x17135c9f
[     131.130] dl name = sysrecovery
[     131.132] img size = 305738752
[     131.136] part size = 536870912
[     131.139] read start=34816
[     131.142] write start=4630528
[     203.602] dl name = UDISK
[     203.603] sprite update error: fail to open part file DISKFS_000000000
[     203.633] sprite update error: current card sprite failed
[     203.640] now hold the machine

OK, missing UDISK (filename DISKFS_000000000)

Indeed, it does not appear in files/image.cfg from the a10_flash_kitchen_v2/packer_ics directory.

Now I need to repair that.
To be continued...

Mele A2000 custom

Now I want to customize the firmware. At least to start the HTPC in English, or French!
I tried the a10_flash_kitchen_v2 from this source: [TUTORIAL/DEV]Build AOSP Android 2.3.7 for Allwinner A10 tablets (Teclast P76Ti), but for Android 4.0, and without using AOSP (just a working image), and all from linux (with wine for windows programs).

At this stage, the modified firmware is generated, but does not load.
During SDCARD update process, normal led flash is followed by a rapid led flash and does not stop.

When I perform simg2img RFSFAT16_SYSTEM_000000000.fex system.ext4
I get this: "computed crc32 of 0x949435d7, expected 0x00000000"
Perhaps this is the root cause of my problems...


I followed more or less this tutorial:
How to build custom LiveSuit images for flashing internally to MK802 but without Windows except for the flashing utility (and even for that I used the PhoenixCard utility).
I converted the .bat scripts into shell scripts, but I think recent versions of wine are able to handle .bat files.

Based on this firmware named HTPC-Android4.0 - filename is android\ 4.0\ 软件.rar (I retrieved it from an alternate source, same name): Mele's Download Center

Since it fails, I need to wire the TTL-to-USB debug cable (I have a DKU-5 phone data cable that perfectly fits this usage).

To be continued...

New hack: mele A2000

Received this
Mele A1000 is a $70 hackable, Linux-friendly ARM-based PC (the Mele A2000 version, seems that only VGA output position is different, specifications are the same).
I bought also the Mele F10 remote, great that it works via RF and not via IR. This allows to hide the Mele box, and still be able to move the mouse.
My first modification is to install a better firmware, at least under ICS.
I took android_4.0.img following this site: MeLe A2000
With this firmware you already have root access, and busybox.

A weird thing: the IR sensor captures my SAMSUNG TV remote, volume down performs "back" in videos.
Install an Android terminal, and then:
su
rmmod sun4i_ir
removes the IR sensor capability (useless with the F10 remote).
The next annoying thing was the blue LED, too bright from my taste; the red one is better. Sanction:
echo '0' > /sys/devices/platform/gpio_sw.1/gpio_sw/PH20/data
and power on the red one, just in order to see that the device is ON:
echo '1' > /sys/devices/platform/gpio_sw.0/gpio_sw/PH10/data

CIFS module is loaded; you can mount CIFS network shares like this:
su
mkdir -p /mnt/cifs/videos
busybox mount -t cifs -o user=guest,domain=MYGROUP //192.168.2.289/videos /mnt/cifs/videos
(change the parameters with yours).

Enable adb connection via TCP (instead of USB):
su
setprop service.adb.tcp.port 5555
stop adbd
start adbd
ifconfig eth0

Well, I want to automate this by generating my own firmware. The best would be to try on the SD Card before flashing it. http://www.cnx-software.com/2012/06/13/hardware-packs-for-allwinner-a10-devices-and-easier-method-to-create-a-bootable-ubuntu-12-04-sd-card/ shows how to generate a bootable SD Card, but for a linux distribution.

To be continued...