The first thing to do is wire up a UART cable to the board. The pads are in a row of four at the top-right of the board in the upper photo. The square pad is ground, the next two are TX/RX, then +3.3v which doesn't need to be wired. The UART runs at 115200 8/n/1 and allows you to see what happens during boot. Without this you are flying blind and the only response to further posts asking for help and/or saying "that didn't work" is
If the eMMC storage is fully erased you can write an AMLGX 'board' image for another GXL/GXM hardware device., e.g VIM1, VIM2, LePotato, etc. to an SD card and see if any of them will boot; first edit the exlinux.conf file to use the p212 device-tree which should work (enough) with any Android box. If the image doesn't boot, try another. The goal is to find an image with u-boot compiled with an acs.bin (which contains RAM spec info) that works with the board. The board has SSV6051P sdio WiFi which is the cheapest of cheap WiFi modules and that normally implies low-spec (low-bin) RAM that's less likely to match against an SBC manufactured with better quality components. Experimenting is free though, and over time I've found quite a few Android boxes that will boot using e.g. LePotato or VIM2 images. If you can boot an image, then you can download the same image to /storage, uncompress it and then 'dd' the image to the /dev/mmcblk1 (eMMC) device and the box should then boot from eMMC again.
If the board has traces of a wrong u-boot on eMMC (only visible with UART output) then you will need to desolder the eMMC chip to run the u-boot experiments as the bootrom always attempts boot from eMMC first, and the BGA packacing prevents you from doing the normal 'short pins' method (sounds like you figured that out already). The board will then be stuck booting from SD card as resoldering will reinstate the wrong u-boot, but perhaps with the BGA package removed you can see traces and figure out another way to temp short/disable the chip. If you can disable it and boot from SD then you can 'release' the short post boot. The chip can then be detected and becomes something you can erase/overwrite from the console.
Thanks for sharing your knowledge Chewitt! From what I've seen, you're a master in theses stuff. I'm going to proceed as you said. First, I'll have to get a USB TTL converter. As soon as I get one, I'll post the output logs, since I don't know what they mean.
Thank you soo much for joinig into the thread.
