Posts by bumerc

Quote from chewitt

If you fork the amlogic-boot-fip repo on GitHub and push a branch with a 'p281' fileset containing that acs.bin and share a link, I can build an image using it.

Okay, I'll do it. After testing it on my old P281 device.

Quote from chewitt

I suspect the FIP files for p212 were generated before the existence of S905W boards; hence the 'wrong' (unknown) chip error. The VIM1 files are newer and thus accomodate the chip, even if the wrong RAM size is being detected.

Hi. Oh yeah, that seems to be it. But the problem is currently with the DDR timing, as two chips are stuck at rank0 (frontside), and the other two at rank1 (backside). Rank1 isn't initialized yet, which is causing the kernel to panic.

Does mainline u-boot work with LE? I made a test build with acs.bin for p281.

Quote from Sniperassault

So sorry fot that! I didn't want to make the post so long and I couldn't think of a better idea than to upload .pdf files.

I tried that image and least now the uart output is ever the same. This code repeats in loop while the box is on:

From what I read in another thread you also participated in, you mentioned that this means the u-boot is partially functional.
Am I correct, or did I misunderstand?

It looks like a fake s905w SoC (S905W) revision 21:b (a2:2). Since the BL30 complains about "Wrong chip a0."

This message also appears on an s905l board when attempting to run a standard boot FIP on it.

An acs.bin for p281 with VIM u-boot should be used here to ensure the 2G of RAM is fully initialized.

Quote from bob276

Hi Bumerc,

The first option sounds ok my end to process.

1). What are the steps to add this source code file commands into which file / folder in the box? I only see the file/folder options from android recovery as per previous photos attached in posts.

Thanks

Bob

Hi.

Please follow the instructions in this PDF file for manual installation. For installation you need these files. Then try to establish the connection to the box via cmd.exe. Hold the reset button and run update.exe identify

I will explain the remaining steps once you have established the connection to the box.

You don't need any files on the box. The update.exe interacts directly with the u-boot via worldcup protocol and the u-boot writes the commands directly into the env partition of the eMMC, as if you were writing directly in the u-boot prompt via uart.

A typical indication that the vendor u-boot is too old. It lacks the ability to run aml_autoscript in the environment.

A more complicated but safe method:

You can install the Amlogic USB Burning Tool on your computer, connect the box to the computer via USB cable and manually add the commands from the source file in the Windows cmd window to the u-boot environment.

Another option would be to upgrade the Android to a higher version, but there is a risk that you will get an unsuitable firmware that will brick the box.

Quote from deimos

Okay. I daily drive linux, so I'll dd it to the card, should that suffice?

Regarding shorting the EMMC, do we know if there's a standard BGA169 to solder pad mapping?

You have 48 pins (right/left) around the chip. In this arrangement, in most cases DAT0/1 bus is connected to pins 29/30. The pins are counted from the INDEX ^

Datasheet

I'm just wondering why the manufacturer has integrated an EMCP chip as DDR memory, but solders an extra EMMC chip on the PCB. Maybe because of the encrypted firmware for this chip variant or for other cost reasons.

edit:

Have you perhaps saved the uart log from the original bootloader? It would make configuration easier for us. The most important point would be the RAW/Column addressing, which must match. Unfortunately, I could not find a datasheet for this chip..

deimos

Here is the archive with new u-boot + diff file with the changes I made for now.

The u-boot sources are for android 7 from this repository

u-boot@p201_lpddr3

Write it to the SD card via DD (Description).

# Find out the name of the block device

lsblk

# /dev/sdX, you have to replace sdX with your block device

dd if=u-boot.bin.sd.bin of=/dev/sdX conv=fsync,notrunc bs=512 skip=1 seek=1
dd if=u-boot.bin.sd.bin of=/dev/sdX conv=fsync,notrunc bs=1 count=440

If you are using Windows, use Amlogic BootCardMaker.

Attach the uart output

Quote from deimos

Hi Bumerc,

Thanks for taking the time to respond - I appreciate it! I'll take a look at the attached link, but yes I would appreciate any assistance in trying to keep this out of becoming e-waste

Ok, I'll try to configure a test version tomorrow, you have to write it to the SD card and start it by shorting the emmc pins 29-30, because the device is currently in bootloop.

Quote from deimos

Here are photos of the PCB. Let me know what you find.

If you can't find a suitable IMG, you can try to configure and compile u-boot for your ddr memory type. You could use this log as a configuration basis for gxbb lpddr3 device. If necessary, we could try it together.

You can't get around it without uart..

Quote from kami911

Do you have idea what I do wrong?

Seems to be due to the dtb configuration for Internal PHY. Your box requires External PHY (RGMII). Look for the appropriate dtb..

Quote from thegooddoctor

Define "hardware problem" and elucidate upon "If you fix that (in hardware) the upstream u-boot works fine."

I've been watching this thread for a long time. You created a hardware problem yourself by removing the emmc module by heating the emmc socket. In reality it is enough to use the test point to completely isolate the emmc from the boot sequence code of the BL1 (ROM). Now for the fact - as long as you have this error (..CHK:F3..) (whether it's emmc, nand or sd boot) it means - the data that was burned to the particular block device is corrupt, miswritten, or there is a problem in the block device itself , in your case sd card.

Quote

GXBB:BL1:08dafd:0a8993;FEAT:EDFD718C;POC:3;RCY:0;EMMC:800;NAND:81;SD:0;READ:0;CHK:F3;USB:8;LOOP:1

Quote from chewitt

bumerc ^ all yours apparently

Problem solved with a little trick. If omar_shipyard wants, he will describe what he did and how he did it 🙂

Quote from chewitt

LarsenIt's unlikely that an S905W box has encrypted boot

Well why..

Thread

X96 mini Amlogic S905W Bricked after wrong update

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…

wae23

September 21, 2021 at 9:38 PM

Hard puzzle.. extract vendor fw and see if the *.ENC files exist. If you find any then your board is encrypted and in this case only using the vendor fw would be possible. Try to narrow down all possible causes.. )

I can't help you without logs

Try dropping BCM4345C0.hcd into /system/etc/bluetooth. I cannot read your log because of the different character encoding. Use UTF-8.

s4shail

Check if BCM4345C0.hcd FW exists in bluetooth folder.

If necessary, you can download it here..

GitHub - LibreELEC/brcmfmac_sdio-firmware: Broadcom SDIO firmware used with LibreELEC

Broadcom SDIO firmware used with LibreELEC. Contribute to LibreELEC/brcmfmac_sdio-firmware development by creating an account on GitHub.

github.com