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.
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.
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.
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.
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.
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 ^
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..
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
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
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.
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.
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..
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.
QuoteGXBB:BL1:08dafd:0a8993;FEAT:EDFD718C;POC:3;RCY:0;EMMC:800;NAND:81;SD:0;READ:0;CHK:F3;USB:8;LOOP:1
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 🙂
LarsenIt's unlikely that an S905W box has encrypted boot
Well why..
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.. )
Check if BCM4345C0.hcd FW exists in bluetooth folder.
If necessary, you can download it here..