5p0ng3b0b

If you open terminal in android, what does cat /proc/device-tree/amlogic-dt-id give you? The attached dtb files were extracted from the firmware downloaded from here. x96maxplus_dtbs.zip

I wrote a bash script to extract a dtb file from a boot.img or boot.PARTITION file so no need for termux/python/perl etc. It doesn't even require busybox or root. Just run from terminal emulator app. Open terminal and type: sh /path/to/dtb_extract.sh /path/to/boot.img Script and resulting DTBs attached. Edit: I was completely unaware that the boot image can contain multiple DTB files and I was only extracting the first one found *duh*. I amended the script and extracted 5 dtb files from my box. Also attached is a static dtc command so you can convert DTB files without termux. To get the correct DTB for your device type: cat /proc/device-tree/amlogic-dt-id dtb_extract.sh dtc g12a_u212_1g.dtb g12a_u212_2g.dtb g12a_u212_4g.dtb sm1_ac213_2g.dtb sm1_ac213_4g.dtb

You ask for DTB for X96 max but this is s905x2 SoC. X96 max plus however is s905x3. Maybe this is the problem. Carefully reading the recent posts on this thread should help provide an answer to extracting a stock recovery image, eg trying TWRP and using the backup function. 'How to get stock recovery image?' is a bit off topic IMO. You could try google, or make a new thread in another section asking this question.

Can you supply stock recovery image from box or firmware?

Get DTB file from recovery.PARTITION file. Here is a second take a getting DTB file as extracting via /sys/firmware/devicetree/base using dtc didn't appear to work . This time get DTB from recovery.PARTITION file using termux. Firstly on a PC, download and unzip stock tvbox image. Then unpack firmware.img file with amlogic unpacker. Now transfer the recovery.PARTITION file to termux home folder. The DTB file is embedded in this file so now just extract it. I already installed git, python, perl and wget etc to termux. The resulting file was 76,302 bytes in my case from a magicsee N5 plus box. I still can't test yet because I haven't got it to boot from external storage but can confirm the dtc command worked on it. dtc -I dtb -O dts -o mybox.dts mybox.dtb Update: This also worked from a recovery image file created by dd if=/dev/block/recovery of=recovery.PARTITION so this can be done completely from rooted device and without access to stock firmware. Produced an identicle DTB. n5plus.dtb n5plus.dts

@keynote. Shame the dtb not working . Probably need some python/perl script to parse the dts file Not all boxes are equal, Is there a bootloader partition? This should list all emmc partitions ls $(find /dev/block/platform/ -name "by-name") su dd if=$(find /dev/block/platform/ -name "by-name")/bootloader of=/sdcard/bootloader.img Or try TWRP backup function. Apply zip file using update app or from recovery mode (this will not overwrite your stock recovery). TWRP_3.2.2_Android_9.0.zip

For those that have not found a working dtb yet, you might want to give this method of extracting dtb and dts files a shot (hardware keyboard recommended or setup sshd via termux). Install termux. Open it and type: termux-setup-storage apt update apt install dtc dtc -q -I fs -O dts /sys/firmware/devicetree/base -o /sdcard/mytvbox.dts dtc -q -I fs -O dtb /sys/firmware/devicetree/base -o /sdcard/mytvbox.dtb I am unable to test this method presently due to other issues but I am dying to know if it works. The files generated are larger than the dtb files in the armbian images but they are similar size to the dtb files from coreelec. If the dtb file doesn't work, at least the dts file might give some clues as to why alternative dtb files have wifi or ethernet issues etc. You can also convert other dtb to dts and vice versa so you can open the dts files in a text editor and compare. To convert dtb to dts. dtc -O dts -o tvbox.dts tvbox.dtb To convert dts to dtb. dtc -O dtb -o mytvbox.dtb mybox.dts

Really looking forward to running armbian one day on my S905x3 device but ran into difficulty from the get go running aml_autoscript. I was initially posting here with a cry for help but managed to sort the problem and thought I'd share my solution as this alternative method doesn't appear to be documented anywhere. The problem: Downloaded and burned Armbian_20.02.0-rc1.037_Aml-s9xxx_buster_current_5.5.0-rc6_20200205.img to sdcard. Using the update app that was preinstalled on the android device, I tried loading aml_autoscript from external sd card, usb ports and internal storage but got the same error every time. E:Block map file is too short: 3 E:Map of '@/cache/recovery/block.map' failed E:failed to map file Installation aborted I tried all the above with different sdcards and usb sticks but still no luck. Running aml_autoscript from stock recovery gave a different error: E:mmap(0, R, PRIVATE, 6, 0) failed: Invalid argument E:Map of 'udisk/aml_autoscript.zip' failed E:failed to map file Installation aborted The solution: I didn't want to go down the uart/uboot route as I don't know where the tx/rx points are on this box and my eyesight isn't that great anymore. Plus my soldering days were over many years ago. I was able to boot into a twrp.zip via stock recovery, but there was no setenv command in the twrp console to enter the info manually. Perhaps there is a command I could enter to run the aml_autoscript from here, I have no idea. I decided the way forward was to extract the env partition with twrp (you can just as easily do it with dd or fastboot) and hack it before flashing it back. I opened the file up with a hex editor and could see what looked like a uboot environment with fatload commands etc, a 4 byte header at the start of the file then each command separated by a null byte. I'm looking at yet another brick if I bork it, so I'm not doing this with a hex editor. Convert it to a text file, make the changes and convert the text file back to the original 8mb image format was the plan. All I had to do was trim the trailing zeros and replace the remaining null bytes with a newline. I copied the file to my PC to do the job but it can all be done from a rooted box with busybox installed. cp env.emmc.win env.emmc.bak; cat env.emmc.win | sed '$ s/\x00*$//' | sed "s/\x00/\n/g" > env.txt That one-liner seemed to do the the trick (note backup). The resulting file gave me: So, I delete the 1st 4 characters as it turns out this is a checksum and if it isn't right then everything goes back to default values and it's back to square one. Then amended the exsisting variables (bootcmd and upgrade_step) and added the start_* variables. Note each variable has an '=' before the definition and there are no quotes, so not exactly copy and paste from the aml_autoscript file. I also observed that the environment variables were sort of in alphabetical order and thought it cautious to keep it that way and inserted the new variables between the 'serverip' and 'storeargs' variables. Now it was just a case of saving env.txt and converting the file back. As the 4 byte checksum needs to be there, I had to install uboot-tools as only the mkenvimage command can do this and build the env image. mkenvimage -s 8388608 -p 0x00 -o env.emmc.win env.txt Check the file with; cat env.emmc.win | od -tx1 Burn the file back to the /dev/block/env or $(find /dev/block/platform | grep by-name/env) partition. Remember the file is now modded so the original twrp backup checksum won't work. Recreate it with; md5sum env.emmc.win > env.emmc.win.md5