New ROM MTD format AML8726-MX (Jynxbox M6)

[shaunmt]

Hmmmm.... I don't see a spi_MX.bin in any of the ROMs I have downloaded EXCEPT the Linux ROM I downloaded for the Mygica TV520.

It looks to be a boot loader looking at it with a hex editor. I think I will binwalk this and try to see what it is.
It maybe what is needed on SDcard to boot a recovery from SDcard!

Bob

I wonder if the stock bootloader on your device has been modified to not load recovery from SD?

[Finless]

SHIT!

OK so the key to all this is the .ubt file.

I downloaded the Linux ROM and noticed it had a spi_MX.bin and a factory_update_param.ubt file.

Then I downloaded a zip called "How to revert back to 4.1". The intructions are for how to reflash back to ANdroid from Linux. It also had a uImage_recovery and a .ubt file.

I looked at the .ubt file and it is not just a script! There is a binary header to it.
So I put these to files and a uImage_recovery on SDcard and sure as shit, it booted with no LED on for the power button. I had a blank screen and wondered.... "OK I must need some other files too".

I unplugged the unit.... Now it will not power on. I get no LED on the power button.

I just freakin hosed my boot loader by unplugging too soon I think! I AM NOW FULLY BRICKED

CRAP!

Bob

[niabi]

OK so the key to all this is the .ubt file.

I downloaded the Linux ROM and noticed it had a spi_MX.bin and a factory_update_param.ubt file.

Then I downloaded a zip called "How to revert back to 4.1". The intructions are for how to reflash back to ANdroid from Linux. It also had a uImage_recovery and a .ubt file.

I looked at the .ubt file and it is not just a script! There is a binary header to it.
So I put these to files and a uImage_recovery on SDcard and sure as shit, it booted with no LED on for the power button. I had a blank screen and wondered.... "OK I must need some other files too".

I unplugged the unit.... Now it will not power on. I get no LED on the power button.

I just freakin hosed my boot loader by unplugging too soon I think! I AM NOW FULLY BRICKED

CRAP!

Bob

sorry to hear that, but this happened to me once.

on the "How to revert back to 4.1" it says something like:

3.Insert TF card into the box;
4.Press and hold the upgrade button, plug in power adapter;
5.Hold the button for about 10 seconds£¬until you can see the flashing light;
6.Loose the upgrade button, wait for 1-2 minutes(screen has no display at this time),
and then normally you will see robot screen,it is updating the firmware;
7.After finished, the box will restart.


but on my tests, I've had to wait up to 5 minutes for any info to show on the screen.
I don't own a Jynbox, but does it have a reset button? if so, insert the SD card with the files on it, and try pressing it before you put power on it, then release a couple of seconds after you plug it in, that's how I got my device working again.

[Finless]

I just tried all that and no go. I waited for 10 minutes... NOTHING!
The boot loader is hosed.
I unplugged too soon!

I have to see if I can make a recovery bootable SDcard now.

I have been through this on AML before and the bootable SDcard trick always recovered it.

Yes this has a reset/power button... You hold it for 10 seconds and this is how you flash ROMs manually via recovery with a factory AML script or not. Needless to say when the boot loader (u-boot) gets wasted, your screwed and forced to make a special SDcard. Without a boot loader in NAND it will not try to recover from SDcard. Boot loader is the key to all of this!

I am doing that now to see what I can do to fix this hard brick!

Bob

[Finless]

FYI, no power light (LED) EVER on the box's button usually means you have hosed the boot loader. That was the same for the Tronsmart MX box I have.

However the Tronsmart really didn't have a reset button (it did but did not recover from hard brick).... You had to short NAND pins to force it to boot from SD. I hope I do not have to do that with this box too....

Bob

[Finless]

HELL YES! I recovered from a hard brick!

Yea baby! I just recovered from a blown boot loader (hard brick)!!!

It is a little different than previous AML formats but here are some facts.

1) On the older AML ROM format you used u-boot.bin to make the special bootable SDcard.
Well for this new format or this box anyway, u-boot.bin is in fact spi_MX.bin. You use that to make the bootable SDcard boot sector like Christian Troy talks about.
So spi_MX.bin is the boot loader!!!! Please notice that on old ROM format u-boot.bin was about 400K. This new version is 2.5 megs! So huge difference in the boot loader on this new ROM format!

2) This new boot loader REQUIRES another file to be on SDcard called factory_update_param.ubt.
Please note: This is not just a script. There is a binary header in it that I have no clue what it does. However if you do not have this on SDcard when you boot the boot loader from SDcard, nothing happens!

Now the .ubt file does have some info in it.
I think what this does it tell the system how to format NAND memory. It makes the NEW format I talked about in the first post with the different partitions. Here is a clue to what can be read in this new .ubt file:

geniatech auto script x echo upgrade spi ...
if mmcinfo
then
if fatexist mmc 0:1 ${spifile}
then
nand erase 0
run burnspi
reset
fi
fi

Not sure what all this is doing but it is KEY to this new ROM format and boot loader!


Anyway, now that I know how to unbrick I am going to really go after this ROM, Recovery, etc! I have no FEAR now



Bob

[niabi]

Cool!

so can you tell us the steps? did you just put everything on the SDcard?

I've been trying to do stuff on my device, witch is based on the same chip, but I've found it hard to get any info (and I am not an expert on the matter), so I will be happy to know any information you might share for this

you mentioned you repacked a boot.img, do you mind sharing this as well?

Thanks!

[Finless]

you mentioned you repacked a boot.img, do you mind sharing this as well?

Thanks!

In time my friend! I just have to know for sure how stuff works before I share it. Make sense?

FYI a repack of boot will never be the same. On AML I have never been able to repack that without removing a file because it is always too large on the repack. In this ROM there are several initlogo.rle files and all you need to do is remove 1-2 of those (the ones not really used) and it will repack.

But here is a tip, the latest Mygica ROM I used has a 80 byte offset to the header instead of 64. But on repack you can use 64 and it will still work.

Bob

[Finless]

Booting recovery from SD

Well I have just messed with this new boot loader a lot. Seeing as the .ubt file is the key to getting a SDcard to boot rather than from NAND, I tried all kinds of combinations.

Yes you can make a SDcard flash a new recovery and boot it! But I have yet to make it boot a recovery from SDcard alone!
This new setup with spi_MX.bin and the .ubt file seem to ONLY allow you to boot bootloader from SD then it flashes a recovery from SD to NAND. Once done, it reboots and loads recovery from NAND. It will not seem to boot a recovery from SD. I am sure the .ubt file here is the key but with the binary header, who knows at this time.

Even when I mess with this and put a different recovery on SD, it still boots whatever recovery is in NAND! So it seems if a good recovery is in NAND it boots that PERIOD....

Now what is interesting here is if NAND recovery is bad. What it does is boot the loader from SDcard, flashes the recovery found on SDcard to NAND, reboots and you have the recovery again!

Thus it seems to try new recoveries, you have to have them flashed by the .ubt file. You cannot test a recovery from NAND. BUT... this is not so bad as I have stated, the .ubt file and the spi_MX.img handles all this for you. So if you make a bad recovery (like building your own CWM and it doesn't work), you use those files to fix it and put on SDcard the good recovery. This is how you fix a "soft brick".

Bob

[shaunmt]

Yea baby! I just recovered from a blown boot loader (hard brick)!!!

It is a little different than previous AML formats but here are some facts.

1) On the older AML ROM format you used u-boot.bin to make the special bootable SDcard.
Well for this new format or this box anyway, u-boot.bin is in fact spi_MX.bin. You use that to make the bootable SDcard boot sector like Christian Troy talks about.
So spi_MX.bin is the boot loader!!!! Please notice that on old ROM format u-boot.bin was about 400K. This new version is 2.5 megs! So huge difference in the boot loader on this new ROM format!

2) This new boot loader REQUIRES another file to be on SDcard called factory_update_param.ubt.
Please note: This is not just a script. There is a binary header in it that I have no clue what it does. However if you do not have this on SDcard when you boot the boot loader from SDcard, nothing happens!

Now the .ubt file does have some info in it.
I think what this does it tell the system how to format NAND memory. It makes the NEW format I talked about in the first post with the different partitions. Here is a clue to what can be read in this new .ubt file:

geniatech auto script x echo upgrade spi ...
if mmcinfo
then
if fatexist mmc 0:1 ${spifile}
then
nand erase 0
run burnspi
reset
fi
fi

Not sure what all this is doing but it is KEY to this new ROM format and boot loader!


Anyway, now that I know how to unbrick I am going to really go after this ROM, Recovery, etc! I have no FEAR now



Bob

Great news that you can now recover from brick!

I did a little googling about the ubt file earlier... it sounds like a new type of automated install inscript. It may or may not be possible to access the recovery ui from SD on these devices...?

If you can figure out how the ubt file works, modifying could open up a lot of possibilities...

ShaunMT

[shaunmt]

In time my friend! I just have to know for sure how stuff works before I share it. Make sense?

FYI a repack of boot will never be the same. On AML I have never been able to repack that without removing a file because it is always too large on the repack. In this ROM there are several initlogo.rle files and all you need to do is remove 1-2 of those (the ones not really used) and it will repack.

But here is a tip, the latest Mygica ROM I used has a 80 byte offset to the header instead of 64. But on repack you can use 64 and it will still work.

Bob

When I repack a recovery for the Amlogic Nextbook tablets, the CXZ scripts I use almost always report the ramdisk is too large, then attempt to compress it, which almost always works... when it doesn't I remove the boot logo from it which frees up plenty of space.

ShaunMT

[shaunmt]

Well I have just messed with this new boot loader a lot. Seeing as the .ubt file is the key to getting a SDcard to boot rather than from NAND, I tried all kinds of combinations.

Yes you can make a SDcard flash a new recovery and boot it! But I have yet to make it boot a recovery from SDcard alone!
This new setup with spi_MX.bin and the .ubt file seem to ONLY allow you to boot bootloader from SD then it flashes a recovery from SD to NAND. Once done, it reboots and loads recovery from NAND. It will not seem to boot a recovery from SD. I am sure the .ubt file here is the key but with the binary header, who knows at this time.

Even when I mess with this and put a different recovery on SD, it still boots whatever recovery is in NAND! So it seems if a good recovery is in NAND it boots that PERIOD....

Now what is interesting here is if NAND recovery is bad. What it does is boot the loader from SDcard, flashes the recovery found on SDcard to NAND, reboots and you have the recovery again!

Thus it seems to try new recoveries, you have to have them flashed by the .ubt file. You cannot test a recovery from NAND. BUT... this is not so bad as I have stated, the .ubt file and the spi_MX.img handles all this for you. So if you make a bad recovery (like building your own CWM and it doesn't work), you use those files to fix it and put on SDcard the good recovery. This is how you fix a "soft brick".

Bob

Nice work!

That makes sense... an attempt to prevent bad flashes and users from installing / booting custom recovery...
There must be a config in it somewhere for flashing official updates to bootloader, boot, recovery though...

ShaunMT

[Finless]

...
There must be a config in it somewhere for flashing official updates to bootloader, boot, recovery though...

ShaunMT

Not that I can see.

All you need to have on SD is:
spi_MX.bin
factory_update_param.ubt
uImage_recovery

With just this what happens is:
1) It boots with a blank screen for at least 2 minutes.
2) If flashes uImage_recovery to NAND recovery partition.
3) It flashes spi_MX.bin to the boot loader partition
4) It reboots and loads recovery from NAND.

Now if you add the factory_update_param.aml on SDcard in all these other files, it will follow those scripts rather than boot to the recovery UI. In fact if you edit factory_update_param.aml and remove any command that flashes the ROM (e.g. --update_package=), it goes into a recovery reboot loop doing the same thing over and over..... e.g. boot loader from SD, flashes recovery, reboots.

Very interesting!

Bob

[Finless]

In fact no matter how hard I try to make a bad recovery or even u-boot, I cant seem to hard brick this thing!

The only way I hard bricked this thing was to unplug the unit after it booted from SD and it was probably flashing recovery and bootloader when I unplugged! So basically I trashed the boot loader in NAND. That was the only hard brick!

With this setup it seems impossible to hard brick using a SDcard even with a bad ROM on SDcard! In other words, if you screw up, a standard SDcard with the proper files on it always recover! UNLESS you hosed the boot loader in NAND with a power off during SDcard boot. Then you have a hard brick and need to recover with the special AML created SDcard.

Very cool... I think this new setup is to protect people from flashing a bad recovery and u-boot and hard bricking

Bob

[shaunmt]

Not that I can see.

All you need to have on SD is:
spi_MX.bin
factory_update_param.ubt
uImage_recovery

With just this what happens is:
1) It boots with a blank screen for at least 2 minutes.
2) If flashes uImage_recovery to NAND recovery partition.
3) It flashes spi_MX.bin to the boot loader partition
4) It reboots and loads recovery from NAND.

Now if you add the factory_update_param.aml on SDcard in all these other files, it will follow those scripts rather than boot to the recovery UI. In fact if you edit factory_update_param.aml and remove any command that flashes the ROM (e.g. --update_package=), it goes into a recovery reboot loop doing the same thing over and over..... e.g. boot loader from SD, flashes recovery, reboots.

Very interesting!

Bob

Maybe I misunderstood... I thought you mentioned that it only flashes bootloader and / or recovery if it detects a problem with the internal bootloader and / or recovery? Does it actually flash them everytime?

If it only flashes bootloader and / or recovery when bricked, then I was suggesting there must be a configurable option somewhere inside the ubt file for an official bootloader or recovery update.

ShaunMT