In order to recover, I need to short the pin mentioned above, then it is enough to use a normal burnt Coreelec image? Or shall I flash some uboot in boot partition of SD?
Create a recovery uSD with burncardmaker. Insert it into the slot, short eMMC and power on. Keep the short till the recovery is started on screen.
After recovery u can run CE again from uSD with the toothpick method like u used before.
When the recovery is finished and u are able to boot ce again I can give you some commands to try injection again. DON’T USE just the injection, it will break booting again!
Also please post a UART log again when it is recovered and booting into CE.
where can I find the recovery uSD?
Anyhow, the box boot coreelec with s905x3 2g dtb, so I do not think the SoC is fake.
What the inject_bl301 check to understand which blob to flash?
The cpu serial shows SM1 0x2b:
But your bootloader use G12A (0x28). This is not SM1. So your bootloader is not correct configured. inject_bl301 do inject the SM1 blob but the G12A should be in your case.
Search the internet how to recover your device with use of burncardmaker. When your finished we can manually inject the G12A blob of you want.
Ok, @Meiden recovered it, but apparently via an image in the eMMC, even if I do not understand how it is possible
@Meiden I hit your same problem, can you tell me if you have used a recovery firmware?
@Portisch Is it possible to use also USB burning tool for restoring?
Hello mate. I used a sdcard for this and followed the steps described here:
The firmware that I used is this one:
http://www.mediafire.com/file/jenswqit5vpvuvu/%25E4%25B8%25AD%25E6%2580%25A7BZ-TX3-20191130.img/file
I understand that you can burn directly the image using the Amlogic Burncard maker, but as long as I’m using Linux, the first option was more suitable for me.
Then, as I said, exactly as your are explaining, I am not even sure if the sdcard is being used, because in the two recoveries that I’ve made (and you are confirming me that you had same experience), even with the sdcard inserted the system was booted into the emmc and I could access to the old CE installation untouched. The I disabled Bl301 injection directly from the GUI (CoreELEC menu from the settings → Hardware). I don’t have an explanation for this behavior either.
Hope this helps. Please feel free to ask any other specific question that you may have.
PS: @Portisch funny thing about this crap box: I’ve discovered that IR wakeup and shutdown is working OOB, so no need to use Bl301 injection. I understand that this has already a modified u-boot for that purpose and the injection simply doesn’t work and it isn’t needed. LOL.
The how-to clear said:
Some Amlogic devices do have problems with wake-up from suspend/power off by IR remote, CEC or WOL, this is related to a poorly configured bootloader.
This is the reason for the new tool that we have created, inject_bl301!
So if you don’t have any issue with the current configuration the vendor provide just don’t use it!
I took a look into my SM1 device and it also use the ‘g12a’ blob:
Load FIP HDR from eMMC, src: 0x00010200, des: 0x01700000, size: 0x00004000, part: 0
Load BL3X from eMMC, src: 0x00078200, des: 0x01768000, size: 0x00110000, part: 0
bl2z: ptr: 05129330, size: 00001e40
0.0;M3 CHK:0;cm4_sp_mode 0
MVN_1=0x00000000
MVN_2=0x00000000
[Image: g12a_v1.1.3389-92241b5 2019-07-02 17:22:49 luan.yuan@droid15-sz]
OPS=0x10
ring efuse init
2b 0c 10 00 01 2d 16 00 00 01 33 30 43 57 50 50
[1.009550 Inits done]
CoreELEC secure task start!
CoreELEC high task start!
CoreELEC low task start!
run into bl31
NOTICE: BL31: v1.3(release):4fc40b1
NOTICE: BL31: Built : 15:57:33, May 22 2019
NOTICE: BL31: G12A normal boot!
NOTICE: BL31: BL33 decompress pass
But your version is much newer: Image: g12a_v1.1.3394-7d43064d5 2020-05-07 15:37:06 gongwei.chen@droid11-sz
I need to look what I can find if something is changed.
Yes, please. When you have recovered your device just dump it like with
cd ~/backup
dd if=/dev/bootloader of=bootloader.bin
sync
Then share your ~/backup/bootloader.bin somewhere please.
Also a full UART log of the bootloader will help!
I need to get first all newest bootloader blobs to see if something changed about BL301 since 05.2020.
Hi Portisch, thanks for ur great work!
After running inject_bl301 on a “Magicsee N5” the box looped in boot with some error i reminded from the UART like “chip_id wrong”. Unfortunately i forgot to save the log 
Maybe i will brick my box again later 
With “USB Burning Tool” i was able to get back to a running state where i could determine throu “cat /proc/cpuinfo” that my chip seems to be:
Serial : 210dc400cab3aa6b2f1467f5e0e76623
model name : Amlogic S905L rev d
Hardware : Amlogic
Revision : 0400
The attachment is the expected bootloader.bin from dd command of the running box restored with latest factory-firmware: bootloader.bin (4 MB)
BTW do u know running aml-flash-tool for mac or do the linux aml-flash-tool will compile just fine and do the job under mac?
A log would be helpful. Also what dtb you use for this device. Maybe there is something missing for S905L as I never had one.
1 Like
I used the gxl_p212_2g dtb. Bricked it again
Desoldered the UART-Cable just recently
What kind of log u need?
My eMMC-Shortening-Solution:
https://pasteboard.co/JGPWMJk.jpg
Only UART can tell what happens. But I guess it’s better to disable GXL injection at all.
I have no idea, maybe something is customized and this is the reason for a boot loop. But without the source it’s almost impossible to say what’s wrong.
1 Like
Because i am living in a rural area powered with just a diy solar system i heavily depend on standby- and/or hibernation-mode. Under Android the display shows actual time in standby, a feature i would like to see with coreelec.
Here is the working UART-log:
https://pastebin.com/eaxzh7sJ
Now i will brick my device again and add the UART-log here
The beginning of the log is missing.
I remembered something about this N5. And now I see it in your UART log: it have a NAND assembled instead eMMC.
Maybe it never will work, I am not sure about it.
1 Like
I have powered the device throu UART-usb-dongle, but as soon i connect the box the device (/dev/tty.XXXX) reseted itself, so i had to time the start of screen-output after the usb-dongle was connected.
The UART-boot-loop-log after inject_bl301:
https://pastebin.com/u2PuPLtd
Oh no. U mean that little bastard:
https://pasteboard.co/JGRdqph.jpg
Do u think it would work by desolder the nand and replace it with a eMMC? I have a lot laying around.
Or do u think its possible to adapt code to nand? I found: mmc/SD in Linux is /dev/mmcblkx the NAND is /dev/mtdx
I checked the binary blobs and it’s the BL30 blob what is not compatible with your hardware: Wrong chip %x. As this blobs are closed source I think I can not solve this issue.
And no, you can not replace the NAND by eMMC, it wont work.
I upload your picture how to short the eMMC here to have it as backup for other users needing it.
Magicsee N5 short eMMC for debrick:
1 Like
@Portisch I have recovered the box, but the firmware I use (got from 4pda) has an older uboot, the same version of your board, see the bootlog:
And in fact the inject bl301 works now.
So I guess a dump is of no use, but I attach the dump of the “newer” bl301
I managed to patch the precompiled bl30 blob from the AML Pie SDK sources available to me. This solves the problem of the serial id (chip id) check for S905L SoC, P211 (also known under fake names P282, P261, etc.).
If you are interested in the future implementation… I can provide this for you
1 Like