X96 mini Amlogic S905W Bricked after wrong update

1st Official Post

    hi all

    i have a new X96 mini Amlogic S905W Bricked after wrong update

    so after try many ways to unbrick it still dead only red flash


    box spec

    Amlogic S905W

    ram 2GB/16GB Rom


    Ram: sec 524 K4B4G0446E ( i think is samsung)

    eMMC: KLMAG1JETD-B041 ( samsung)


    i connect uart and log the box

    i get

    this log only


    LOOP:1;EMMC:0;READ:0;CHK:A7;READ:0;CHK:A7;READ:0;CHK:A7;SD:800;USB:8;

    LOOP:2;EMMC:0;READ:0;CHK:A7;READ:0;CHK:A7;READ:0;CHK:A7;SD:800;USB:8


    and keep same loop with nothing

    after i make some search i find out that U-boot is erased from box

    i try many uboot from many flash on web with no luck

    today i success getting log from box

    i find a uboot i install it on sd card using BootcardMaker tools ( the uboot that work is from this img on web "X96mini Q6X v2.2 17355 чип Samsung")

    and the box give me this log with loop ( i try with sd card recovey using same uboot+factory_update_param.aml+recovery.img+otasoft.zip on sd= nothing on tv )

    log :

    any help plz


    thnk you .

    • Official Post

    The u-boot you found only partially works. It looks to be compatible with the RAM, but there is some form of chip detection going on (from the error) so it's probably been created for another type of GXL device, e.g. S905X not S905W. The one good thing is .. you are experimenting from an SD card. Keep doing this, because if you flash the wrong u-boot to eMMC it becomes a major pain to recover the box (not impossible, but complicated).

    The only mainline u-boot(s) that I have pre-compiled are here: Index of /testing/u-boot/ .. vim/lafrite/lepotato are all GXL devices (S905X, S905X) but the mainline sources don't really have device detection like vendor sources so from SD card they will either work or fail cleanly.

    Quote from chewitt

    The u-boot you found only partially works. It looks to be compatible with the RAM, but there is some form of chip detection going on (from the error) so it's probably been created for another type of GXL device, e.g. S905X not S905W. The one good thing is .. you are experimenting from an SD card. Keep doing this, because if you flash the wrong u-boot to eMMC it becomes a major pain to recover the box (not impossible, but complicated).

    The only mainline u-boot(s) that I have pre-compiled are here: Index of /testing/u-boot/ .. vim/lafrite/lepotato are all GXL devices (S905X, S905X) but the mainline sources don't really have device detection like vendor sources so from SD card they will either work or fail cleanly.

    thank you

    i try most of them not working

    any sugg ?

    Quote from chewitt

    Chase the vendor for the correct ROM image to restore the box, or their u-boot sources (which are GPLv2 .. but good luck with that) or keep experimenting with u-boot(s) from ROM images (as you've been doing, from SD card).

    install same Uboot with different Sd Card that give me log

    i got different log

    Edited once, last by wae23 (September 24, 2021 at 12:43 AM).

    Quote from wae23

    FEAT:BDFC31BC

    Quote from wae23

    aml log : R1024 check fail with ERR = 85 aml log : SIG CHK : 85 for address 0x01700000

    In your case, the box manufacturer has activated secure boot. Information about whether the board is actually encrypted can be extracted from the SEC_AO_SEC_SD_CFG10 register. You can only boot with an encrypted FIP. The error “wrong chip..”: The chip id is defined in BL30 blob (closed source). This id is also used for MAC generation in BL33, u-boot. As long as the chip id is not known, the uboot will perform the reset, which leads to a boot loop. I managed to convert the normal, unencrypted bl30 blob to an ELF binary through small manipulations and to decompile its code into a legible format. With a small change in ELF binary, the fake "s905w" was now running and was recognized as s905l Soc. If you still have one of these encrypted boards where the original u-boot is not damaged, you could read the bl30 dump into a file and compile it into an executable file to create an ELF binary from it..

    It is best to contact the manufacturer regarding original fw :)

    Quote from bumerc

    In your case, the box manufacturer has activated secure boot. Information about whether the board is actually encrypted can be extracted from the SEC_AO_SEC_SD_CFG10 register. You can only boot with an encrypted FIP. The error “wrong chip..”: The chip id is defined in BL30 blob (closed source). This id is also used for MAC generation in BL33, u-boot. As long as the chip id is not known, the uboot will perform the reset, which leads to a boot loop. I managed to convert the normal, unencrypted bl30 blob to an ELF binary through small manipulations and to decompile its code into a legible format. With a small change in ELF binary, the fake "s905w" was now running and was recognized as s905l Soc. If you still have one of these encrypted boards where the original u-boot is not damaged, you could read the bl30 dump into a file and compile it into an executable file to create an ELF binary from it..

    It is best to contact the manufacturer regarding original fw :)


    thnx

    i can get a board from a friend in a couple of days


    for the manufactuer he offer only stock firmware

    Quote from bumerc

    In your case, the box manufacturer has activated secure boot. Information about whether the board is actually encrypted can be extracted from the SEC_AO_SEC_SD_CFG10 register. You can only boot with an encrypted FIP. The error “wrong chip..”: The chip id is defined in BL30 blob (closed source). This id is also used for MAC generation in BL33, u-boot. As long as the chip id is not known, the uboot will perform the reset, which leads to a boot loop. I managed to convert the normal, unencrypted bl30 blob to an ELF binary through small manipulations and to decompile its code into a legible format. With a small change in ELF binary, the fake "s905w" was now running and was recognized as s905l Soc. If you still have one of these encrypted boards where the original u-boot is not damaged, you could read the bl30 dump into a file and compile it into an executable file to create an ELF binary from it..

    It is best to contact the manufacturer regarding original fw :)

    after success install recovery in the box i install a stock firmware

    but i got new error

    wae23

    Looks like this u-boot's loadaddr is wrong. Why are you using the sd card-u-boot version? Try to use the eMMC-U-Boot variant. Unpack the manufacturer's Android IMG and only use the bootloader.PARTITION.. (u-boot.bin.enc).

    Or, you can install the IMG via UBT with the Secure Boot option.

    Quote from bumerc

    wae23

    Looks like this u-boot's loadaddr is wrong. Why are you using the sd card-u-boot version? Try to use the eMMC-U-Boot variant. Unpack the manufacturer's Android IMG and only use the bootloader.PARTITION.. (u-boot.bin.enc).

    Or, you can install the IMG via UBT with the Secure Boot option.

    i use uboot from sd because box dosent accept soft or uboot from burning tools

    i extract this bootloader from other working box my box finally unbricked but working only with sd


    so i try to install stock firmware to fix uboot problem this stock contain not supported dtb

    after install this firmware with uboot i got this problem

    "Synchronous Abort" handler, esr 0x96000210
    ELR: 37ec0168
    LR: 37ec0168
    x0 : 0000000000000000 x1 : 000000000000000c
    x2 : 0000000000000038 x3 : 0000000000009acc
    x4 : 0000000000000070 x5 : 0000000000000069
    x6 : 0000000033ec1bc4 x7 : 0000000000000020
    x8 : 0000000000000001 x9 : 0000000000000000
    x10: 000000000000000f x11: 0000000037f384d8
    x12: 0000000000000000 x13: 0000000000000000
    x14: 0000000000000000 x15: 0000000000000000
    x16: 0000000000000000 x17: 0000000000000000
    x18: 0000000033ea1e28 x19: 0000000033eb7200
    x20: 0000000000000000 x21: 0000000033eb7a00
    x22: 0000000037f61a68 x23: 0000000000080000
    x24: 0000000037f72000 x25: 0000000000000000
    x26: 0000000000004bc8 x27: 0000000000000000
    x28: 0000000033eb6a70 x29: 0000000033e91b70

    Resetting CPU ...

    any way to fix this ?

    dtb is also subject to an RSA signature check. As long as the dtb is not written to emmc, you will have less chance of recovering your device. Put the emmc in acces mode by short-circuiting the pins and start the UBT update

    Quote from bumerc

    dtb is also subject to an RSA signature check. As long as the dtb is not written to emmc, you will have less chance of recovering your device. Put the emmc in acces mode by short-circuiting the pins and start the UBT update

    after long short circuit i success enter acces mode

    then i use update on sd card with ini file its start update and on 2% its reset