[S912] Mecool M8S Pro L 3/16 GB

    Hi folks,

    since atvx and freaktab forum looks kinda broken to me (can't register with 3 different mail providers), i am here with a question regarding amlogic S912 chip. I flashed my device via USB Burning Tool as usual (altough it is tough to bring this board in recovery mode)

    But serial output looks kinda sad. It is not possible anymore to flash via USB-cable, USB Flash Drive or SD Card. Even a kbd is not recognized anymore.



    Does anyone here have enough knowledge to unbrick this device? Would be kinda sad to loose the board. my new order with an S905X5 does not look much faster than the ancient S912

    • Best Answer

    It fails at the second stage of boot (BL2) and never reaches the third stage (u-boot) where vendor u-boot versions for Android have support for flashing with Amlogic burning tool etc. implemented. Possible causes:

    a) You flashed a ROM image built with the wrong RAM timing data, triggering reset.

    b) The eMMC chip on the board is failing and boot fails because more data cannot be read, triggering reset.

    It's fiddly to recover from this situation as the first stage (BL1) always attempts to load BL2 boot from eMMC first, and in your case BL2 is found but then fails (boot loop). The couple of times I had to self-recover from this scenario I've shorted pins on the eMMC chip with a small screwdriver to disable the chip at power-on to ensure BL1 does not find BL2 code on eMMC, allowing it to be found on an SD card. I've then experimented with various LE images for GXL/GXM boards until I hopefully find one with compatible RAM timing so that boot reaches Linux userspace or at least the u-boot console; where I can run commands to erase the eMMC device ensuring the board will alway boot from SD card, which gives me a start point for further recovery.

    For me the next stages are then simple because I'm only interested in booting LE and LE boot code can be flashed to both SD card and eMMC storage. Restoring Android ROM's is trickier because LE images use upstream u-boot which doesn't support proprietary stuff like Amlogic burning tool, and ROM files are packaged using proprietary tools that modern Linux doesn't support, and boot code in the images (once tools are found to extract/dump it out) is designed only for eMMC installation so you cannot test it easily from SD cards. Nothing is unsurmountable, but it becomes fiddly, there is no simple HOWTO guide writen up in the wiki, and most users do not have the aptitude for figuring things out themselves. I can't speak for others, but I'm not that interested in trying to spoon-feed instructions on this as it's never fun. If you do have the right aptitude; there's enough info and hints above ^ for you to make progress.

    Thank you very much for your detailed reply chewitt and the time and effort you put in to help others. It helps me understanding my SBCs issue much better, than i could until now!
    Before asking here, i (ofc) already searched a lot and read about shorting emmc but didn't succeed. Based on your post i tried again.

    Since i found no documentation nor datasheet for my ForeSee NCEMASG-16G NAND/EMMC, i probed all pins to ground since shorting pin pairs didn't seem to do anything.

    atvx (Sadly i can't get the image due to registration issues) suggests short pin pairs 28/29 or 29/30 if i pull those pins to ground i get the following output. Does this look like the right sequenz to to get stage 2 from SD?


    IMHO it looks like the board is not reseting anymore but stage1 BL is looping cause it can not read stage2 from emmc (as before). At the same time my SD seems not in a valid condition.

    I'll answer myself since there is no edit function:

    Yes that is the pattern you're looking for when shorting emmc :)
    Noticed that AML USB Burn recognizing the board while the pattern showed, but was unable to flash. (download ddr...)
    A SD with AML burn SD Card Tool was able to install an android rom. (Be quick removing the short before SD card tries to write to emmc)

    But since we're here in libreelec forum: I also tried generic AML box image burned with baleetcher with q201.dtb (which i already used some years ago for armbian) but i was unable to boot from SD. Don't know what i missed in your reply, but now that we have working u-boot i can prep an usb-stick and boot from that.

    Quote

    I've then experimented with various LE images for GXL/GXM boards until I hopefully find one with compatible RAM timing so that boot reaches Linux userspace or at least the u-boot console

    An example of what boot firmware is compiled from: https://github.com/LibreELEC/amlo…ter/khadas-vim2

    The acs.bin file contains RAM timing data. The main challenge with Android STB hardware is they frequently use cheap (low-bin) RAM parts that are cheap because they are out of spec, so the box manufacturer 'tweaks' the default timing data to suit the chips used in a production run, and this effectively causes the ROM to become unique to that batch of devices. You can then roll dice on whether that ROM will/won't work with any other devices.

    The AMLGX "box" image doesn't contain a working u-boot, it assumes vendor u-boot is present and working. You need to try what I'd call "board" files, e.g. VIM2, or such that have full boot firmware. If you can find one that works (not guaranteed) the advantage will be that you can write the image to eMMC and boot from there.

    If you have working vendor u-boot on the device you should at least be able to use the "box" image to boot LE. Android boxes will normally boot from SD but if that's a problem and USB works; go with the flow.