RTD1296 failed to boot

Banana pi BPI-W2
1

Hi BananaPi forum!

This is kind of off topic, but I have no idea where I could ask something like this. And the W2 is based on the RTD1296 which I have some problems with…

Basically I have a device which is based on the CPU in question, it has 2GB of DDR4 memory, some IO and a 8MB SPI flash, however it fails to boot with the following on UART0:

C1:80000000
C2
?
C3h
hwsetting size: 00000B94
C4
f
5-5verify fsbl fail
0000003BC7
C1:80000000
C2
?uu3-1

Based on the “verify fsbl fail” message I figured that the first stage bootloader verification fails. I think the first stage bootloader should be the UBoot from the SPI memory. I have no idea what the verification process is, or what is checks so if somebody could give me some pointers on what I should look for that would be nice.

I dumped the SPI flash, and the contents seem fine. I also have the UBoot binary and I compared it with the one in the flash memory, and they are the same, so that should be fine.

I also looked at the SPI communication between the CPU and the memory using an oscilloscope (yeah not a logic analyser and it wasn’t easy to capture all the data) and the communication seems to be fine. The CPU loads some bytes from 2 areas then loads the UBoot area, and it fails afterwards.

I also managed to get into the “d/g/r>” on-chip recovery terminal. Using the peek command I could probe around the memory space, using available documentation I managed to figure out the location of the SPI flash and I read it using this console, and it works just fine. So the CPU can read the correct data from the flash.

However I did not manage to find where the RAM is located, I had some ideas from previous experience, but reading/writing those areas always fail. Which in combination with the FSBL verification failure might point to RAM error in my opinion. So I also tried to “reflow” (as in reheat the RAM and CPU) chips to try and fix any joints that might have failedm, but it didn’t do anything.

Btw the device in question is a NAS (DS218), it ran fine for 3 years 0-24, until it decided to just fail. The board also has a PIC MCU, but I guess that has nothing to do with the boot process.

Again sorry for the off-topic post…

If anybody could tell me what the fsbl verification process is, that would be great!

Thanks for reading.

Cheers, Bence.

2

After messing around a lot with the built in recovery terminal. I figured that the verify checks an SHA256 hash of the boot loader and it seems like one of the 4 RAM chips is faulty.

The FSBL is loaded to 0x1010000, by writing 0xFFFFFFFF to that address I get 0x00FFFFFF, writing 0xABABABAB, gives 0x54ABABAB, which is interesting because the first byte always flips.

3

Thank you for this valuable information, I was also wondering why this is happening, but thanks to you I already know, thank you very much

4

Sorry for bumping :slight_smile:

Update on this post: After figuring out which RAM chip is faulty through poking around in the 32bit memory space, I’ve replaced the two RAM chips connected to Channel0 on the DDR controller. And the NAS lives again :slight_smile:

I’ve uploaded all my findings here for future use: https://github.com/robot9706/DS218

Cheers, Bence.