New ROM MTD format AML8726-MX (Jynxbox M6)

[Finless]

Guys, I got a new Jynxbox M6 (Same as the Genitech TV500 and MyGica TV400).
This uses a new ROM format.

cat /proc/mtd
dev: size erasesize name
mtd0: 00400000 00400000 "logo"
mtd1: 00800000 00400000 "boot"
mtd2: 20000000 00400000 "system"
mtd3: 1f400000 00400000 "cache"
mtd4: 12c00000 00400000 "backup"
mtd5: 60000000 00400000 "userdata"
mtd6: 4ac00000 00400000 "NFTL_Part"
mtd7: 00008000 00001000 "ubootenv"

Just some info for you and some scary stuff!
What is interesting here is where the hell is recovery? Is it hidden?
The edify update script for the stock ROM does show:
write_raw_image(package_extract_file("recovery.img "), "recovery");
But how can it do this if it is not listed in MTD?

Boot.img is not of Android format but I did figure it out and get it unpacked.
/system and /data are in UBIFS format not EXT4.

Because of all this I am very afraid to ever replace boot loader or recovery. If I did and the SDcard recovery method doesn't work, this box will be dead!

I am sure since it is a AML8726-MX that the box "might" be able to completely flash to the old format but it's just too scary to try... Then could you ever go back?

CWM I think would be out of the question too due to the format differences though if I ever get brave, I might see if I can make a CWM that works. Again though screwing with recovery.img without a know SDcard recovery is just too scary

Much more to learn about this new ROM format even though I have now made a custom ROM for this box

Bob

[shaunmt]

Guys, I got a new Jynxbox M6 (Same as the Genitech TV500 and MyGica TV400).
This uses a new ROM format.

cat /proc/mtd
dev: size erasesize name
mtd0: 00400000 00400000 "logo"
mtd1: 00800000 00400000 "boot"
mtd2: 20000000 00400000 "system"
mtd3: 1f400000 00400000 "cache"
mtd4: 12c00000 00400000 "backup"
mtd5: 60000000 00400000 "userdata"
mtd6: 4ac00000 00400000 "NFTL_Part"
mtd7: 00008000 00001000 "ubootenv"

Just some info for you and some scary stuff!
What is interesting here is where the hell is recovery? Is it hidden?
The edify update script for the stock ROM does show:
write_raw_image(package_extract_file("recovery.img "), "recovery");
But how can it do this if it is not listed in MTD?

Boot.img is not of Android format but I did figure it out and get it unpacked.
/system and /data are in UBIFS format not EXT4.

Because of all this I am very afraid to ever replace boot loader or recovery. If I did and the SDcard recovery method doesn't work, this box will be dead!

I am sure since it is a AML8726-MX that the box "might" be able to completely flash to the old format but it's just too scary to try... Then could you ever go back?

CWM I think would be out of the question too due to the format differences though if I ever get brave, I might see if I can make a CWM that works. Again though screwing with recovery.img without a know SDcard recovery is just too scary

Much more to learn about this new ROM format even though I have now made a custom ROM for this box

Bob

I'm also clueless regarding the internal recovery on that tablet, but if you can run recovery from SD card, then why bother flashing the internal recovery?
Chistian Troy recently posted instructions for running bootloader from SD on Amlogic, which should make it possible to recover from a bad internal bootloader: http://www.slatedroid.com/topic/95977-howto-create-a-rescue-sd-card-for-pretty-much-every-amlogic-8726-mx-device/

I've been able to port Christian Troy's UBIFS CWM from the Ainol series to the Nextbook series. I plan to release it within the next few weeks. It should be possible to get it running on your TV box also.

ShaunMT

[Finless]

tricky!

OK so I had to make my own edify script and then within that run a shell script to dump recovery dmesg and MTD.

YA HOO!

Check out what recovery reports!

I found the missing mounts that the OS kernel will not mount but the recovery kernel will!

dev: size erasesize name
mtd0: 00400000 00400000 "logo"
mtd1: 00800000 00400000 "boot"
mtd2: 20000000 00400000 "system"
mtd3: 1f400000 00400000 "cache"
mtd4: 12c00000 00400000 "backup"
mtd5: 60000000 00400000 "userdata"
mtd6: 4ac00000 00400000 "NFTL_Part"
mtd7: 003fe000 00001000 "spi"
mtd8: 00058000 00001000 "uboot"
mtd9: 00008000 00001000 "ubootenv"
mtd10: 003a0000 00001000 "recovery"


So those partitions do exist to the recovery kernel!

I think this new layout is intended to protect recovery from the Android OS!

More progress being made.....

Shaun, I forgot about running boot and recovery from SDcard. I remember doing that to fix my Prometheus. So now I am going to try that.

Bob

[shaunmt]

OK so I had to make my own edify script and then within that run a shell script to dump recovery dmesg and MTD.

YA HOO!

Check out what recovery reports!

I found the missing mounts that the OS kernel will not mount but the recovery kernel will!

dev: size erasesize name
mtd0: 00400000 00400000 "logo"
mtd1: 00800000 00400000 "boot"
mtd2: 20000000 00400000 "system"
mtd3: 1f400000 00400000 "cache"
mtd4: 12c00000 00400000 "backup"
mtd5: 60000000 00400000 "userdata"
mtd6: 4ac00000 00400000 "NFTL_Part"
mtd7: 003fe000 00001000 "spi"
mtd8: 00058000 00001000 "uboot"
mtd9: 00008000 00001000 "ubootenv"
mtd10: 003a0000 00001000 "recovery"


So those partitions do exist to the recovery kernel!

I think this new layout is intended to protect recovery from the Android OS!

More progress being made.....

Shaun, I forgot about running boot and recovery from SDcard. I remember doing that to fix my Prometheus. So now I am going to try that.

Bob

That is certainly a new and interesting security method on these devices. Nice work!

I'd love to see your modified unpack / repack scripts and your edify update script and dump script sometime.

In case I wasn't clear, you can also run bootloader from SD, but you have to make a "recovery SD" card. The tutorial from Christian Troy that I posted a link to previously is the best one I've seen, although I haven't yet tried it myself.

It's on my todo list. I'm hoping I can make a generic M3 SD card image and an M6/X SD card image with the Nextbook bootloaders for the people who completely erased their NAND with the AML burning tool. After than I'm going to experiment with swapping bootloaders and kernels via SD card for testing without risk of bricking.

ShaunMT

[Finless]

Here is my edify script.
You will need to make a update zip package with a tools folder.
In that put the dump.sh script.

ui_print("Finless recovery mtd dumper");
ui_print("Mounting /system");
mount("ubifs", "UBI", "system", "/system");
show_progress(0.500000, 50);
package_extract_file("tools/dump.sh", "/tmp/dump.sh");
set_perm(0, 0, 0777, "/tmp/dump.sh");
ui_print("run script");
run_program("/tmp/dump.sh");
ui_print("unmount /system");
unmount("/system");
ui_print("Reboot now to continue");


Here is the dump.sh script:
#!/sbin/sh
cat /proc/mtd > /system/mtd.txt
dmesg > /system/dmesg.txt
exit 0

When it's done reboot and dmesg.txt and mtd.txt files will be at the root of /system

Bob

[Finless]

Now I have to go back a learn how to boot recovery from SDcard...
Any pointers so I don't have to go looking ?

Bob

[shaunmt]

Here is my edify script.
You will need to make a update zip package with a tools folder.
In that put the dump.sh script.

ui_print("Finless recovery mtd dumper");
ui_print("Mounting /system");
mount("ubifs", "UBI", "system", "/system");
show_progress(0.500000, 50);
package_extract_file("tools/dump.sh", "/tmp/dump.sh");
set_perm(0, 0, 0777, "/tmp/dump.sh");
ui_print("run script");
run_program("/tmp/dump.sh");
ui_print("unmount /system");
unmount("/system");
ui_print("Reboot now to continue");


Here is the dump.sh script:
#!/sbin/sh
cat /proc/mtd > /system/mtd.txt
dmesg > /system/dmesg.txt
exit 0

When it's done reboot and dmesg.txt and mtd.txt files will be at the root of /system

Bob

Thanks! Seeing this gives me more new ideas!

ShaunMT

[shaunmt]

Now I have to go back a learn how to boot recovery from SDcard...
Any pointers so I don't have to go looking ?

Bob

For boot and recovery, the files just need to be named correctly and placed at the root level of the external SD card. I'm not sure if all devices use the standard Amlogic naming, but recovery is usually uImage_recovery and boot is usually u-boot.bin . The SOC will use the internal bootloader and the external boot / recovery file. An aml-autoscript file is optional. It just automates the wiping and install. I don't like to use it, because it performs those actions without informing the user.

For bootloader, you have to modify the bootloader and partition the SD card to create a "recovery SD card". Then add your boot / recovery files as usual.

ShaunMT

[Finless]

I tell you Shaun, I am still leery about if a SDcard thing will work on this. The method Christen pointed out is very similar to the method for unbricking the Prometheus and I am familiar with it.

But this new ROM layout is different!

1) There is no u-boot.bin file. Now there is a uboot_mx.img. They might be the same darn thing just a different file name. I have to do some binary comparing to see.

2) There is a new partition called ubootenv and a new file that gets flashed there by the updater called env_MX.img. This is actually a text file you can read and is very interesting as I think it controls the bootloader. There are some cool things in here like being able to control partition sizes

3) There is another partition called spi. I have to figure out what that is!

Anyway because of these differences who knows if this unbrick method will work the same!

Bob

[shaunmt]

I tell you Shaun, I am still leery about if a SDcard thing will work on this. The method Christen pointed out is very similar to the method for unbricking the Prometheus and I am familiar with it.

But this new ROM layout is different!

1) There is no u-boot.bin file. Now there is a uboot_mx.img. They might be the same darn thing just a different file name. I have to do some binary comparing to see.

2) There is a new partition called ubootenv and a new file that gets flashed there by the updater called env_MX.img. This is actually a text file you can read and is very interesting as I think it controls the bootloader. There are some cool things in here like being able to control partition sizes

3) There is another partition called spi. I have to figure out what that is!

Anyway because of these differences who knows if this unbrick method will work the same!

Bob

Good points! I haven't seen any other devices with those partitions either.

I suspect the ubootenv configs may be modifiable, but who knows... changing them might make the bootloader or the kernel incompatible...

I'd bet the SPI partition contains the partition layout for the NAND. A quick google search suggests it is definitely involved in the boot process.

This device may require additional files to run bootloader from SD, but I bet it will still happily boot recovery from SD. There's nothing to lose as long you don't flash anything to the internal NAND.

ShaunMT

[Finless]

I am going to make a new script in recovery to dump that spi partition and have a look

Bob

[shaunmt]

I am going to make a new script in recovery to dump that spi partition and have a look

Bob

I wonder if any of those partitions are hidden on other Amlogic devices??? Wish I had time to check right now... but I'm about to get really busy at the office... maybe later tonight...

ShaunMT

[Finless]

OK interesting. spi and uboot partitions are identical!
I notice in the uboot env that it lists both of these.... I think it might be a backup of uboot incase you flash a jacked up ROM and at least one area contains the original uboot.

It seems AMLogic and the hard brick thing might be fixed in this new ROM format.
No script from the stock ROM ever updates the spi partition or even mounts it so that maybe programmed by the factory to allow a recovery from hard brick. That's my bet anyway...

Now on to modify the stock recovery so I can see if it will boot a recovery from SDcard. I am going to change an image in it so I know which is which. Let's see if this new boot environment will boot a recovery from SDcard.... I have a feeling it will be different!

Bob

[shaunmt]

OK interesting. spi and uboot partitions are identical!
I notice in the uboot env that it lists both of these.... I think it might be a backup of uboot incase you flash a jacked up ROM and at least one area contains the original uboot.

It seems AMLogic and the hard brick thing might be fixed in this new ROM format.
No script from the stock ROM ever updates the spi partition or even mounts it so that maybe programmed by the factory to allow a recovery from hard brick. That's my bet anyway...

Now on to modify the stock recovery so I can see if it will boot a recovery from SDcard. I am going to change an image in it so I know which is which. Let's see if this new boot environment will boot a recovery from SDcard.... I have a feeling it will be different!

Bob

I bet it will boot... that's a chip feature.

I'd also bet that spi isn't just a failsafe... I'd bet there is a script somewhere that checks to see if uboot has been modified and copies spi to uboot if it has, just like the internal recovery!

ShaunMT

[Finless]

Trust me... there is no script that does this and I have looked I the ROM.

My bet is this is in the bootloader if it does that. But why would it do that? It would defeat the purpose of keeping a correct uboot handy. More to learn for sure. I will put this on my list once I get to a point I know I can unbrick if I screw with these areas.

Bob