Proof of concept - Realtek 1295


Staars
 Share

9 9

Recommended Posts

Armbian is a community driven open source project. Do you like to contribute your code?

5 hours ago, danman said:

Wow! That is awesome! Do you have a detail of the main chip ? Or more pictures? What X-ray device was used?

It is captured with an digital x-ray-system using digital image plates. Spatial resolution is limited, we can only zoom digitally. More pictures do not really make sense here.

Link to post
Share on other sites

Just a small update on the kernel side.

 

I uploaded all my latest local changes for the kernel tree 4.19.y (= 4.19.55), so you can build it (DEV) from my repo. But don't get too excited, it will not really work.

This is only meant for further developing and hopefully some more skilled kernel-hackers can take look. There are some backports (for instance android/staging) and all API-changes were done according to the compiler output and the following internet search, so the process included traces of cargo-cult-programming. Expect stupid bugs here and there.

 

Expected behaviour:

A boot-log with surprisingly few errors but the inability to have a root device :angry:. The console output will stop and after while you should see a kernel error.

Disabling usb or ahci or sd or mmc drivers (or combinations) will change the error slightly. It seems, as if there is always a DMA-problem, but that might be coincidence.

 

I simply do not know, if there is just one wrong line of code somewhere or if the whole construction is lightyears away from working.

 

Happy hacking!

Link to post
Share on other sites

Using @Staars u-boot and kernel repo's I managed to create a basic image using the LibreELEC build system (using Armbian's would require an old dog to learn new tricks). I know little about u-boot, but I appear to have created an SD card image that fails and ends up in the 2015 u-boot that was compiled from sources:

BPI-W2> version
U-Boot 2015.07 (Aug 01 2019 - 04:17:12 +0000)
aarch64-libreelec-linux-gnueabi-gcc-8.3.0 (GCC) 8.3.0
GNU ld (GNU Binutils) 2.32
BPI-W2>

As you can see/guess, this is on W2, the switch is set to boot from SD card.


Full boot log:

Spoiler

 


...Banana Pi BPI-W2(SPI ROM:20180907)

C1:80000000
C2
?
C3h
SD card is detected !!
C4
BPI: try bootcode_from_sdcard !! 
.BPI: support boot from sdcard
Command 0x00000000
.interrupt 0x98010424 = 0x00000002
.Command pass 
.response 0x98010589 = 0x000000A0
.response 0x9801058A = 0x00000000
.response 0x9801058B = 0x00000000
.response 0x9801058C = 0x00000000
.response 0x9801058D = 0x00000000
.response 0x9801058E = 0x00000000
Command 0x00000008
.interrupt 0x98010424 = 0x00000002
.Command pass 
.response 0x98010589 = 0x00000008
.response 0x9801058A = 0x00000000
.response 0x9801058B = 0x00000000
.response 0x9801058C = 0x00000001
.response 0x9801058D = 0x000000AA
.response 0x9801058E = 0x00000013
Command 0x00000037
.interrupt 0x98010424 = 0x00000002
.Command pass 
.response 0x98010589 = 0x00000037
.response 0x9801058A = 0x00000000
.response 0x9801058B = 0x00000000
.response 0x9801058C = 0x00000001
.response 0x9801058D = 0x00000020
.response 0x9801058E = 0x00000083
AppCommand 0x00000029
.interrupt 0x98010424 = 0x00000002
.Command pass 
.response 0x98010589 = 0x0000003F
.response 0x9801058A = 0x00000000
.response 0x9801058B = 0x000000FF
.response 0x9801058C = 0x00000080
.response 0x9801058D = 0x00000000
.response 0x9801058E = 0x000000FF
Command 0x00000037
.interrupt 0x98010424 = 0x00000002
.Command pass 
.response 0x98010589 = 0x00000037
.response 0x9801058A = 0x00000000
.response 0x9801058B = 0x00000000
.response 0x9801058C = 0x00000001
.response 0x9801058D = 0x00000020
.response 0x9801058E = 0x00000083
AppCommand 0x00000029
.interrupt 0x98010424 = 0x00000002
.Command pass 
.response 0x98010589 = 0x0000003F
.response 0x9801058A = 0x00000000
.response 0x9801058B = 0x000000FF
.response 0x9801058C = 0x00000080
.response 0x9801058D = 0x00000000
.response 0x9801058E = 0x000000FF
Command 0x00000037
.interrupt 0x98010424 = 0x00000002
.Command pass 
.response 0x98010589 = 0x00000037
.response 0x9801058A = 0x00000000
.response 0x9801058B = 0x00000000
.response 0x9801058C = 0x00000001
.response 0x9801058D = 0x00000020
.response 0x9801058E = 0x00000083
AppCommand 0x00000029
.interrupt 0x98010424 = 0x00000002
.Command pass 
.response 0x98010589 = 0x0000003F
.response 0x9801058A = 0x00000000
.response 0x9801058B = 0x000000FF
.response 0x9801058C = 0x00000080
.response 0x9801058D = 0x00000000
.response 0x9801058E = 0x000000FF
Command 0x00000037
.interrupt 0x98010424 = 0x00000002
.Command pass 
.response 0x98010589 = 0x00000037
.response 0x9801058A = 0x00000000
.response 0x9801058B = 0x00000000
.response 0x9801058C = 0x00000001
.response 0x9801058D = 0x00000020
.response 0x9801058E = 0x00000083
AppCommand 0x00000029
.interrupt 0x98010424 = 0x00000002
.Command pass 
.response 0x98010589 = 0x0000003F
.response 0x9801058A = 0x00000000
.response 0x9801058B = 0x000000FF
.response 0x9801058C = 0x00000080
.response 0x9801058D = 0x00000000
.response 0x9801058E = 0x000000FF
Command 0x00000037
.interrupt 0x98010424 = 0x00000002
.Command pass 
.response 0x98010589 = 0x00000037
.response 0x9801058A = 0x00000000
.response 0x9801058B = 0x00000000
.response 0x9801058C = 0x00000001
.response 0x9801058D = 0x00000020
.response 0x9801058E = 0x00000083
AppCommand 0x00000029
.interrupt 0x98010424 = 0x00000002
.Command pass 
.response 0x98010589 = 0x0000003F
.response 0x9801058A = 0x000000C1
.response 0x9801058B = 0x000000FF
.response 0x9801058C = 0x00000080
.response 0x9801058D = 0x00000000
.response 0x9801058E = 0x000000FF
card powerup status = 0x000000C1
card capacity status = 0x00000001
can switch to 1.8V = 0x00000001
Command 0x0000000B
.interrupt 0x98010424 = 0x00000002
.Command pass 
.response 0x98010589 = 0x0000000B
.response 0x9801058A = 0x00000000
.response 0x9801058B = 0x00000000
.response 0x9801058C = 0x00000003
.response 0x9801058D = 0x00000020
.response 0x9801058E = 0x000000BD
wait 0x98010585[4:0] 0
wait 0x98010585[4:0] done
wait 0x98010585[4:0] 1
wait 0x98010585[4:0] done
Command 0x00000002
.interrupt 0x98010424 = 0x00000012
.Command pass 
.response 0x98010589 = 0x0000000E
.response 0x9801058A = 0x00000090
.response 0x9801058B = 0x000000D2
.response 0x9801058C = 0x00000001
.response 0x9801058D = 0x00000014
.response 0x9801058E = 0x00000067
.CID 0xA0000 = 0x%x
4453033F
.CID 0xA0004 = 0x%x
36314C53
.CID 0xA0008 = 0x%x
0EBB8047
.CID 0xA000C = 0x%x
1401D290
Command 0x00000003
.interrupt 0x98010424 = 0x00000012
.Command pass 
.response 0x98010589 = 0x00000003
.response 0x9801058A = 0x000000E6
.response 0x9801058B = 0x00000024
.response 0x9801058C = 0x00000005
.response 0x9801058D = 0x00000000
.response 0x9801058E = 0x00000087
RCA = 0x0000E624
Command 0x00000007
.interrupt 0x98010424 = 0x00000012
.Command pass 
.response 0x98010589 = 0x00000007
.response 0x9801058A = 0x00000000
.response 0x9801058B = 0x00000000
.response 0x9801058C = 0x00000007
.response 0x9801058D = 0x00000000
.response 0x9801058E = 0x00000075
SD card has been initialized.
Command 0x00000037
.interrupt 0x98010424 = 0x00000012
.Command pass 
.response 0x98010589 = 0x00000037
.response 0x9801058A = 0x00000000
.response 0x9801058B = 0x00000000
.response 0x9801058C = 0x00000009
.response 0x9801058D = 0x00000020
.response 0x9801058E = 0x00000033
AppCommand 0x00000006
.interrupt 0x98010424 = 0x00000012
.Command pass 
.response 0x98010589 = 0x00000006
.response 0x9801058A = 0x00000000
.response 0x9801058B = 0x00000000
.response 0x9801058C = 0x00000009
.response 0x9801058D = 0x00000020
.response 0x9801058E = 0x000000B9
4-bit bus width
SDR12/normal mode.
Command 0x00000006
.interrupt 0x98010424 = 0x00000012
.Command pass 
.response 0x98010589 = 0x00000006
.response 0x9801058A = 0x00000000
.response 0x9801058B = 0x00000000
.response 0x9801058C = 0x00000009
.response 0x9801058D = 0x00000000
.response 0x9801058E = 0x000000DD
DMA finished 
cr_auto_Read_Write_1, cmd_idx = 0x00000012
.Command pass 
.response 0x98010589 = 0x0000000C
.response 0x9801058A = 0x00000000
.response 0x9801058B = 0x00000000
.response 0x9801058C = 0x0000000B
.response 0x9801058D = 0x00000000
.response 0x9801058E = 0x0000007F
.interrupt 0x98010424 = 0x00000012
Command 0x0000000D
.interrupt 0x98010424 = 0x00000002
.Command pass 
.response 0x98010589 = 0x0000000D
.response 0x9801058A = 0x00000000
.response 0x9801058B = 0x00000000
.response 0x9801058C = 0x00000009
.response 0x9801058D = 0x00000000
.response 0x9801058E = 0x0000003F
64b


U-Boot 2015.07 (Aug 01 2019 - 04:17:12 +0000)

CPU  : Cortex-A53 Quad Core - AARCH64
Board: Banana Pi BPI-W2 (RTD1296)
DRAM:  2 GiB
Watchdog: Disabled
mapping memory 0x20000000-0x40000000 non-cached
flushing dcache successfully.
MMC:   Initialize eMMC in traditional mmc flow.
RTD1295 eMMC: 0
rsp[0]=0x15010038, 
        .       rsp[1]=0x474d4534, 
        .       rsp[2]=0x5201f67a, 
        .       rsp[3]=0xb8367491
The cid_val is 15.
rsp[0]=0xd0270132, 
        .       rsp[1]=0x0f5903ff, 
        .       rsp[2]=0xf6dbffef, 
        .       rsp[3]=0x8e40400d
mmc->version=0x40000000
version=0x00000004
[LY] cardtype=57, mmc->card_caps=0f
[LY] freq = 00464388, clk diver = 00000080
[LY] speed up emmc at HS-200 
[LY] HS-200 bus width=2
[LY] mmc->boot_caps = 20b
TEMP TX_WINDOW=0x7ffffffe, TX_best=0xf 
RX_WINDOW=0xffffff80, RX_best=0x13 
TX1_WINDOW=0x7fffff80, TX_best=0x12 
[LY] hs200 : 0
[HC] ERASE Unit Size = 133693440 bytes
[HC] WPG_SIZE = 4027056128 bytes
Device: RTD1295 eMMC
Manufacturer ID: 15
OEM: 100
Name: 8GME4 
Tran Speed: 200000000
Rd Block Len: 512
MMC version 4.0
High Capacity: No
Capacity: 7.3 GiB
User Capacity: 7.3 GiB
Boot Capacity: 4 MiB
RPMB Capacity: 512 KiB
Bus Width: 8-bit
Speed: HS200
Factory: SD
------------can't find tmp/factory/000BootParam.h
Set up default values
[logo]src w/h=1920/1080 dst w/h=3840/2160
[ENV] read_env from factory failed
Using default environment

*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
HDMITx_HPD=False
------------can't find tmp/factory/video_rpc.bin
tv_system=13 mode=1
Net:   Realtek PCIe GBE Family Controller mcfg = 0024
dev->name=r8168#0
Checking default environment
Hit Esc or Tab key to enter console mode or rescue linux:  3 
------------can't find tmp/factory/recovery
======== Checking into android recovery === 0 
Start Boot Setup ... 
[Skip A] boot manual mode
[Skip K] boot manual mode (execute "go all")
Start Audio Firmware ...
flushing dcache successfully.
** Bad device sd 0 **
Boot from eMMC
mmc - MMC sub system

Usage:
mmc info - display info of the current MMC device
mmc read addr blk# cnt
mmc write addr blk# cnt
mmc erase blk(Reminder: the device will ignore the start <addr> and round the start address to erase_group_size boundary and then erase the erase_group_size instead of #cnt)# cnt
mmc rescan
mmc part - lists available partition on current mmc device
mmc dev [dev] [part] - show or set current mmc device [partition]
mmc list - lists available devices

** Bad device sd 0 **
** Bad device sd 0 **
## Error: "uenvcmd" not defined
** Unrecognized filesystem type **
Start Boot Setup ... 
Wrong Image Format for do_booti command
ERROR: can't get kernel image!
Not raw Image, Starting Decompress Image.gz...


Error: Bad gzipped data
Decompress FAIL!!
ERROR do_booti failed!
Start Boot Setup ... 
Wrong Image Format for do_booti command
ERROR: can't get kernel image!
Not raw Image, Starting Decompress Image.gz...


Error: Bad gzipped data
Decompress FAIL!!
ERROR do_booti failed!
==== boot_rescue_from_usb (secure mode:0)=====
starting USB...
rtk_usb_clock_init:49: Realtek-usb: Enable 1296 u3host clock and power
USB0:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus 0 for devices... Unknown request , typeReq = 0x200c 
1 USB Device(s) found
USB1:   Register 1000140 NbrPorts 1
Starting the controller
USB XHCI 1.10
scanning bus 1 for devices... Unknown request , typeReq = 0x200c 
2 USB Device(s) found
USB2:   USB EHCI 1.00
scanning bus 2 for devices... 1 USB Device(s) found
USB3:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus 3 for devices... Unknown request , typeReq = 0x200c 
Device not responding to set address.

      USB device not accepting new address (error=80000000)
1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

USB device -1: device type unknown
** Bad device usb 0 **
Loading "rescue.emmc.dtb" from USB failed.
Start Boot Setup ... 
Wrong Image Format for do_booti command
ERROR: can't get kernel image!
Not raw Image, Starting Decompress Image.gz...


Error: Bad gzipped data
Decompress FAIL!!
ERROR do_booti failed!
Start Boot Setup ... 
Wrong Image Format for do_booti command
ERROR: can't get kernel image!
Not raw Image, Starting Decompress Image.gz...


Error: Bad gzipped data
Decompress FAIL!!
ERROR do_booti failed!
==== boot_rescue_from_usb (secure mode:0)=====

USB device -1: device type unknown
** Bad device usb 0 **
Loading "rescue.emmc.dtb" from USB failed.
Enter console mode, disable watchdog ...

BPI-W2> version

U-Boot 2015.07 (Aug 01 2019 - 04:17:12 +0000)
aarch64-libreelec-linux-gnueabi-gcc-8.3.0 (GCC) 8.3.0
GNU ld (GNU Binutils) 2.32
BPI-W2> 
BPI-W2>

 

 

 

 

Are any of you hanging around in IRC channels on freenode? .. I could use some help tweaking the boot files/contents to get the kernel working.

Edited by chewitt
Link to post
Share on other sites

Hi,

I think that looks promising.

 

As far as I know, the version of u-boot provided by Sinovoip expects a FAT partition with a certain naming scheme for kernel, DTB and audio firmware. Here is a pastebin from a user of their forums, where at least a kernel is loaded: https://pastebin.com/3MPFDLpS

 

I can only provide some guesswork here, because I do not have an bananapi-w2.

What is the partition/naming scheme of libreelec? Can you access an USB-stick like described some posts ago from the u-boot-console?

Link to post
Share on other sites

LE (on an SD card) uses two partitions. The first is fat (512MB) containing boot files; notably KERNEL (the kernel) and SYSTEM (rest of the OS in a SQUASHFS file). We normally use extlinux to boot board devices that need their own u-boot, but i'm not sure that will be an option here. The second partition is ext4 and provides persistent storage. The overall first partition structure of the Ubuntu image that I downloaded from Sinovoip looks similar to Amlogic (only less organised) where we are using bootm with a uEnv.ini file, and some boot scripts.

Link to post
Share on other sites

Couple of issues solved. First the SD card drivers weren't being built due to CONFIG_SYS_CONFIG_NAME="rtd1295_qa_sd_bananapi" not being set in the u-boot config. Second one of the Sinovoip/Foxcon staff confirmed that u-boot has a 20MB size limit on the kernel. I was using an uncompressed uImage that also contains the LE initramfs that was ~22MB in size. Switching to a gzip KERNEL file dropped size to 10MB and working from the u-boot console I can fatload files etc. to reach this point:

## Booting kernel from Legacy Image at 03000000 ...
   Image Name:   
   Image Type:   AArch64 Linux Kernel Image (gzip compressed)
   Data Size:    11108954 Bytes = 10.6 MiB
   Load Address: 03b00000
   Entry Point:  03b00000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02100000
   Booting using the fdt blob at 0x2100000
   Uncompressing Kernel Image ... OK
   reserving fdt memory region: addr=0 size=100000
   reserving fdt memory region: addr=1f000 size=1000
   reserving fdt memory region: addr=1ffe000 size=4000
   reserving fdt memory region: addr=2200000 size=400000
   reserving fdt memory region: addr=2600000 size=c00000
   reserving fdt memory region: addr=3200000 size=b800000
   reserving fdt memory region: addr=10000000 size=14000
   reserving fdt memory region: addr=14200000 size=9200000
   Using Device Tree in place at 0000000002100000, end 000000000210e694
Bring UP slave CPUs

Starting Kernel ...

but nothing on the console after that point, and I have set 'bootargs' using both the config in the original sinovoip env, and the settings that LE normally uses. The sequence of commands i'm running is effectively this:

setenv bootargs earlycon=uart8250,mmio32,0x98007800 fbcon=map:0 boot=/dev/sda1 disk=/dev/sda2 ssh textmode console=ttyS0,115200n8 console=tty0
setenv fdt_loadaddr 0x02100000
setenv kernel_loadaddr 0x03000000
setenv audio_loadaddr 0x0f900000
setenv kernel KERNEL
setenv dtb_name rtd-1296-bananapi-w2-2GB-HDMI.dtb
setenv audio bluecore.audio
fatload sd 0:1 ${fdt_loadaddr} ${dtb_name}
fatload sd 0:1 ${kernel_loadaddr} ${kernel}
fatload sd 0:1 ${audio_loadaddr} ${audio}
bootm ${kernel_loadaddr} - ${fdt_loadaddr}

I've also experimented with /dev/mmcblk0p1 and /dev/mmcblk0p2 .. and 1p1/1p2 and boot=UUID and boot=LABEL combinations - it's not clear what would be correct.

 

Any suggestions?

Link to post
Share on other sites

you might ask @Lion Wang or @Nora Lee if they can give you access to their newest repository on github.

 

the repo contains a bit of documentation from RTD how the bootloaders are supposed to work (e.g. recovery etc). It seems to contain also the sourcecode for the SPI part of the bootloader (I'm not up to date how much of this code is currently 'in the wild' so please forgive me if it only contains stuff you already know).

 

 

Link to post
Share on other sites

well this part will be for sure off topic but: https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt

Quote

For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

thankfully I don't have to give legal advises but I think you can have a 'confidential' document how to use your GPL derived code (and documentation is somehow a 'how to'). Is it a practice I support, for sure not but it is what it is. Luckily some companies decided to push further into making such stuff public (e.g. rockchip having a wiki, and opened a bunch of their kernelcode so that we can really work with, others like mediatek started to actively push their drivers to mainline as well - I hope others follow this way, it makes their SoCs just more useful in the long term).

 

But back to topic, I might dive into the w2 adventure in the future I just need to sort out a few things cause I'm definitively not up to date here (actually this was some sort of a follow up after my work on the mt7623n which worked quite well in the end - well nobody here was really interested in the work in the end, but I got it more or less properly working with a mainline kernel in the end).

 

As far as I understand the boot-process (and please correct if I'm wrong). There's a 32 bit bootloader (u-boot) supposed to chain-load the 64 bit u-boot somewhere in between the tools from them also provided the pieces of ATF needed (it's not really an isolated atf source right? this must come somewhere out during u-boot building I guess but I didn't dive into those sources right now to figure out what happens here and I'm rather unfamiliar with ATF, ). Finally, the 64 bit u-boot fires up the kernel with current limitations that this has to sit either in a squashfs or fat? (here things get messy in my head :D). And there's some sort of rescue tools if you mess up with the SPI NOR to recover if you mess up there (before I really want to dive into this, I'm a uboot plumber by try and error not by complete understanding and for sure I'll mess it up more than once... :D).

 

For me as a armbian oriented plumber, it's obvious that the final u-boot needs to be able to load a kernel and a rootfs from an ext4 (I assume a 2015 u-boot should be capable to learn this, it's just a bit of tweaking needed (the mediatek u-boot for mt7623 was a 2014 version and finally also able to do this, wasn't that much work, once you figured out how outdated u-boots work). I won't repeat a fat adventure as I did with my experiments with the RPi 4 on 64 bit images built with armbians buildscript (yes, this stuff was never published and Images were never distributed, so no GPL issues here.. :P - and just in case someone asks, it's not gonna happen that I'll push this on github, too much mess in the buildscript to get out a barely working image - probably don't even have the branch anymore).

 

But at least I need some hints how to recover a broken SPI once I'm there before trying heavy modifications on this side. :) So if one of you can summarize this a little bit, I would like to read it. :)

 

Link to post
Share on other sites

I did some diff'ing of u-boot code against the existing public sources back in August and while the total changeset is rather huge, most of the complexity added is associated with the recovery system that Realtek implemented. I think it should be possible (and IMHO beneficial) to isolate the smaller set of changes that provide actual board support and port them to a more modern u-boot (ideally mainline) and then you don't smack your head against the recovery stuff all the time.

 

https://github.com/chewitt/u-boot/commits/bpiw2 has my low-quality u-boot n00b hacking to try and clean-up the boot process to reduce noise and increase comprehension of what's going on. The include/configs/rtd1295_common.h file is where the current u-boot env is set.

 

The single biggest thing that would be useful is git history.. but that's unlikely, although I will submit the nag via some realtek people I tracked down via LinkedIn.

Link to post
Share on other sites

17 hours ago, chewitt said:

https://github.com/chewitt/u-boot/commits/bpiw2 has my low-quality u-boot n00b hacking to try and clean-up the boot process to reduce noise and increase comprehension of what's going on. The include/configs/rtd1295_common.h file is where the current u-boot env is set.

yeah this looks really familiar to u-boot 2014 from MediaTek.. including the common.h :D (I had a lot of fun and a lot more of frustration back then, cause this one at least understands FDT by default.. :D)

 

if you just want to mess around with u-boot (e.g. trying safe bootparameters without recompile u-boot the whole time or hack in the u-boot shell), scriptload (actually the way armbian boots as well) is a great tool.

 

https://github.com/chwe17/u-boot-mt/blob/f5916a4c6d0ad8acf0e9b8fe3f649425272f5e6a/include/configs/mt7623-bpi-r2.h#L393-L397

 

especially cause everything inside this u-boot is defined as fatload even if ext4 should be available from the config you mentioned (there would be a proper way to probe if it's fat or ext but hell, it never worked well enough when I tried it :D). with scriptload you can try to write a proper procedure to boot up your board.

 

 

10 hours ago, Tido said:

It was either in this forum or over at SinoVoip where a guy from RT helped in his spare time,

I think that was the guy from MediaTek sending their adjusted linux drivers upstream to u-boot to get it finally supported by u-boot.

 

17 hours ago, chewitt said:

port them to a more modern u-boot (ideally mainline)

well this would mean to look into the driver sources as well.. :P Something I don't do for more than one reason.. First you'd to check the code license from the code drops you got a bunch of it has no authorship and license headers mentioned. Second, I honestly don't believe it's our job to do the dirty work of getting their stuff upstream. I'm currently fine with a just spend enough time to get it working when it comes to u-boot. Ideally we would have only SoC's with upstream u-boot support but it tends to take to much time for the (more) important stuff (e.g. a proper mainline kernel support.. :P). Any comments on my current understanding how this thing boots? :P

Link to post
Share on other sites

Good news! I have found the BOOTSEL pin on my board :) I connected my logic analyzer to DI pin on SPI header, shorted one suspected pad and saw signals on my analyzer. Then I made a jumper out of 1.27mm pitch pin header and did some fine soldering.

 

Now the question is, what to load to my SPI flash? Does anybody have a full dump from bpi w2 here?

IMG_20190929_125551.jpg

IMG_20190929_125522.jpg

IMG_20190929_124054.jpg

Link to post
Share on other sites

Wow, that would be pretty cool!

 

In comparison to your board, I think the solder points with the blue arrows should be connected, right?

 

I strongly believe, that everything is in the u-boot-folder of the repo from the banana-folks. I do not remember the exact name right now, but it was something like drvboot.exe, which we can build (!=which will work ;)).

 

@danman What do you see on the console, when you use your BOOTSEL? I just want to know, if I am able to replicate this.

 

pcb.jpeg

Link to post
Share on other sites

@Staars it doesn't boot because I don't have the correct image but on the MISO/MOSI/CLK pins of SPI I can see some signals which were not there before attaching jumper.

It doesn't show anything on serial because it doesn't boot :)  It is not even possible to get to d/g/n mode when the jumper is attached (maybe someone with W2 can confirm this behavior?)

I managed to compile some spi images after fixing some bugs in the "SDK" https://github.com/BPI-SINOVOIP/BPI-W2-openwrt-lede/issues/2 but I didn't have time to test them.

You cannot use just any image because they differ per device in "hwsetting" file, ram config, etc...

Still waiting for @chewitt to provide SPI dump from his W2 to compare the layout.

Link to post
Share on other sites

Ahh, I understand.

I had hoped, that at least the initial serial output would show some signs of success. BTW, I just test this an my bricked Lake-box and there is nothing new to be seen. (I used the marked solder points from above)

 

Another little update: On LKML there is some new activity regarding new additions to the soc-family directly from realtek, which sounds good to me, even if this is in the very early stages.

Link to post
Share on other sites

On 10/16/2019 at 10:13 AM, danman said:

provide SPI dump from his W2

I've just get W2 delivered. How could the SPI dump be made?

Being a couple of years Armbian's follower, I share the interest implementing the mainstream kernel build for W2 and ultimately put an Armbian on it.

Link to post
Share on other sites

19 hours ago, y52 said:

I've just get W2 delivered. How could the SPI dump be made?

Being a couple of years Armbian's follower, I share the interest implementing the mainstream kernel build for W2 and ultimately put an Armbian on it.

Hi y52,

 

can you show contents of your /dev/ folder?

Link to post
Share on other sites

It's quite a long list :

root@bpi-iot-ros-ai:~# ls -al /dev |less
total 4
drwxr-xr-x 15 root root       14560 Dec 21 12:39 .
drwxr-xr-x 23 root root        4096 Dec 21 13:52 ..
crw-------  1 root root     10,  55 Dec 21 12:39 ashmem
crw-------  1 root root     10, 235 Dec 21 12:39 autofs
crw-------  1 root root     10,  54 Dec 21 12:39 binder
drwxr-xr-x  2 root root         700 Dec 21 12:38 block
crw-rw----  1 root disk     10, 234 Dec 21 12:39 btrfs-control
drwxr-xr-x  3 root root          60 Jan  1  1970 bus
crw-------  1 root root    246,   0 Dec 21 12:39 cec-0
drwxr-xr-x  2 root root       13920 Dec 21 12:39 char
crw-------  1 root root     10,  59 Dec 21 12:39 chip
crw-------  1 root root      5,   1 Dec 21 12:39 console
lrwxrwxrwx  1 root root          11 Dec 21 12:38 core -> /proc/kcore
crw-------  1 root root     10,  52 Dec 21 12:39 cpu_dma_latency
crw-------  1 root root     10, 203 Dec 21 12:39 cuse
drwxr-xr-x  7 root root         140 Dec 21 12:38 disk
crw-rw-rw-  1 root root     10,  56 Dec 21 12:39 dptx
crw-rw----  1 root video    29,   0 Dec 21 12:39 fb0
lrwxrwxrwx  1 root root          13 Dec 21 12:38 fd -> /proc/self/fd
crw-rw-rw-  1 root root      1,   7 Dec 21 12:39 full
crw-rw-rw-  1 root root     10, 229 Dec 21 12:49 fuse
crw-------  1 root root    254,   0 Dec 21 12:39 gpiochip0
crw-------  1 root root    254,   1 Dec 21 12:39 gpiochip1
drwxr-xr-x  2 root root          60 Dec 21 12:39 graphics
crw-rw-rw-  1 root root     10,  57 Dec 21 12:39 hdmitx
crw-------  1 root root    245,   0 Dec 21 12:39 hidraw0
crw-------  1 root root    245,   1 Dec 21 12:39 hidraw1
drwxr-xr-x  2 root root           0 Dec 21 12:38 hugepages
crw-------  1 root root     10, 183 Dec 21 12:39 hwrng
crw-------  1 root root     89,   0 Dec 21 12:39 i2c-0

crw-------  1 root root     89,   1 Dec 21 12:39 i2c-1
crw-------  1 root root     89,   2 Dec 21 12:39 i2c-2
crw-------  1 root root     89,   3 Dec 21 12:39 i2c-3
crw-------  1 root root     89,   4 Dec 21 12:39 i2c-4
crw-------  1 root root     89,   5 Dec 21 12:39 i2c-5
lrwxrwxrwx  1 root root          12 Dec 21 12:38 initctl -> /run/initctl
drwxr-xr-x  4 root root         180 Dec 21 12:39 input
crw-rw----  1 root video    10,  61 Dec 21 12:39 ion
crw-------  1 root root     10, 107 Dec 21 12:39 jpu
crw-r--r--  1 root root      1,  11 Dec 21 12:39 kmsg
lrwxrwxrwx  1 root root          28 Dec 21 12:38 log -> /run/systemd/journal/dev-log
crw-rw----  1 root disk     10, 237 Dec 21 12:49 loop-control
brw-rw----  1 root disk      7,   0 Dec 21 12:39 loop0
brw-rw----  1 root disk      7,   1 Dec 21 12:39 loop1
brw-rw----  1 root disk      7,   2 Dec 21 12:39 loop2
brw-rw----  1 root disk      7,   3 Dec 21 12:39 loop3
brw-rw----  1 root disk      7,   4 Dec 21 12:39 loop4
brw-rw----  1 root disk      7,   5 Dec 21 12:39 loop5
brw-rw----  1 root disk      7,   6 Dec 21 12:39 loop6
brw-rw----  1 root disk      7,   7 Dec 21 12:39 loop7
crw-------  1 root root     10,  47 Dec 21 12:39 mali0
drwxr-xr-x  2 root root          60 Jan  1  1970 mapper
crw-------  1 root root    249,   0 Dec 21 12:39 mcp_core
crw-------  1 root root     10,  49 Dec 21 12:39 memory_bandwidth
brw-rw----  1 root disk    179,  32 Dec 21 12:39 mmcblk0
brw-rw----  1 root disk    179,  33 Dec 21 12:39 mmcblk0p1
brw-rw----  1 root disk    179,  34 Dec 21 12:39 mmcblk0p2
brw-rw----  1 root disk    179,   0 Dec 21 12:39 mmcblk1

brw-rw----  1 root disk    179,   8 Dec 21 12:39 mmcblk1boot0
brw-rw----  1 root disk    179,  16 Dec 21 12:39 mmcblk1boot1
brw-rw----  1 root disk    179,   1 Dec 21 12:39 mmcblk1p1
brw-rw----  1 root disk    179,  24 Dec 21 12:39 mmcblk1rpmb
drwxrwxrwt  2 root root          40 Jan  1  1970 mqueue
crw-------  1 root root     90,   0 Dec 21 12:39 mtd0
crw-------  1 root root     90,   1 Dec 21 12:39 mtd0ro
drwxr-xr-x  2 root root          60 Jan  1  1970 net
crw-------  1 root root     10,  51 Dec 21 12:39 network_latency
crw-------  1 root root     10,  50 Dec 21 12:39 network_throughput
crw-rw-rw-  1 root root      1,   3 Dec 21 12:39 null
crw-r-----  1 root kmem      1,   4 Dec 21 12:39 port
crw-------  1 root root    108,   0 Dec 21 12:39 ppp
crw-------  1 root root     10,   1 Dec 21 12:39 psaux
crw-rw-rw-  1 root tty       5,   2 Dec 21 18:15 ptmx
drwxr-xr-x  2 root root           0 Dec 21 12:38 pts
crw-------  1 root root      2, 176 Dec 21 12:39 ptya0
crw-------  1 root root      2, 177 Dec 21 12:39 ptya1

....

crw-------  1 root root      2, 174 Dec 21 12:39 ptyze
crw-------  1 root root      2, 175 Dec 21 12:39 ptyzf
brw-rw----  1 root disk      1,   0 Dec 21 12:39 ram0
brw-rw----  1 root disk      1,   1 Dec 21 12:39 ram1
brw-rw----  1 root disk      1,  10 Dec 21 12:39 ram10
brw-rw----  1 root disk      1,  11 Dec 21 12:39 ram11
brw-rw----  1 root disk      1,  12 Dec 21 12:39 ram12
brw-rw----  1 root disk      1,  13 Dec 21 12:39 ram13
brw-rw----  1 root disk      1,  14 Dec 21 12:39 ram14
brw-rw----  1 root disk      1,  15 Dec 21 12:39 ram15
brw-rw----  1 root disk      1,   2 Dec 21 12:39 ram2
brw-rw----  1 root disk      1,   3 Dec 21 12:39 ram3
brw-rw----  1 root disk      1,   4 Dec 21 12:39 ram4
brw-rw----  1 root disk      1,   5 Dec 21 12:39 ram5
brw-rw----  1 root disk      1,   6 Dec 21 12:39 ram6
brw-rw----  1 root disk      1,   7 Dec 21 12:39 ram7
brw-rw----  1 root disk      1,   8 Dec 21 12:39 ram8
brw-rw----  1 root disk      1,   9 Dec 21 12:39 ram9
crw-rw-rw-  1 root root      1,   8 Dec 21 12:39 random
crw-rw-r--  1 root netdev   10,  62 Dec 21 12:39 rfkill
crw-rw-rw-  1 root root    240,   0 Dec 21 12:39 rpc0
crw-rw-rw-  1 root root    240,   1 Dec 21 12:39 rpc1
crw-rw-rw-  1 root root    240, 100 Dec 21 12:39 rpc100
crw-rw-rw-  1 root root    240,   2 Dec 21 12:39 rpc2
crw-rw-rw-  1 root root    240,   3 Dec 21 12:39 rpc3
crw-rw-rw-  1 root root    240,   4 Dec 21 12:39 rpc4
crw-rw-rw-  1 root root    240,   5 Dec 21 12:39 rpc5
crw-rw-rw-  1 root root    240,   6 Dec 21 12:39 rpc6
crw-rw-rw-  1 root root    240,   7 Dec 21 12:39 rpc7
lrwxrwxrwx  1 root root           4 Dec 21 12:39 rtc -> rtc0
crw-------  1 root root    253,   0 Dec 21 12:39 rtc0
crw-------  1 root root     10,  60 Dec 21 12:39 rtk_lockapi

drwxrwxrwt  2 root root          40 Dec 21 12:38 shm
drwxr-xr-x  3 root root         200 Dec 21 12:39 snd
lrwxrwxrwx  1 root root          15 Dec 21 12:38 stderr -> /proc/self/fd/2
lrwxrwxrwx  1 root root          15 Dec 21 12:38 stdin -> /proc/self/fd/0
lrwxrwxrwx  1 root root          15 Dec 21 12:38 stdout -> /proc/self/fd/1
crw-------  1 root root     10,  58 Dec 21 12:39 sw_sync
crw-rw-rw-  1 root tty       5,   0 Dec 21 12:39 tty
crw--w----  1 root tty       4,   0 Dec 21 12:39 tty0
crw--w----  1 root tty       4,   1 Dec 21 12:50 tty1

...

crw-------  1 root root      3, 175 Dec 21 12:39 ttyzf
crw-------  1 root root     10,  48 Dec 21 12:39 uctrl
crw-------  1 root root     10, 239 Dec 21 12:39 uhid
crw-------  1 root root     10, 223 Dec 21 12:39 uinput
crw-------  1 root root    248, 250 Dec 21 12:39 uio250
crw-------  1 root root    248, 251 Dec 21 12:39 uio251
crw-------  1 root root    248, 252 Dec 21 12:39 uio252
crw-------  1 root root    248, 253 Dec 21 12:39 uio253
crw-rw-rw-  1 root root      1,   9 Dec 21 12:39 urandom
crw-------  1 root root    247,   0 Dec 21 12:39 usbmon0
crw-------  1 root root    247,   1 Dec 21 12:39 usbmon1
crw-------  1 root root    247,   2 Dec 21 12:39 usbmon2
crw-------  1 root root    247,   3 Dec 21 12:39 usbmon3
crw-------  1 root root    247,   4 Dec 21 12:39 usbmon4
crw-------  1 root root    247,   5 Dec 21 12:39 usbmon5
crw-------  1 root root    247,   6 Dec 21 12:39 usbmon6
crw-rw----  1 root tty       7,   0 Dec 21 12:39 vcs
crw-rw----  1 root tty       7,   1 Dec 21 12:39 vcs1

...

crw-rw----  1 root tty       7, 134 Dec 21 12:39 vcsa6
crw-------  1 root root    234,  50 Dec 21 12:39 venus_ir
crw-------  1 root root     10,  63 Dec 21 12:39 vga_arbiter
crw-------  1 root root     10, 110 Dec 21 12:39 vpu
crw-------  1 root root     10, 130 Dec 21 12:39 watchdog
crw-------  1 root root    251,   0 Dec 21 12:39 watchdog0
crw-------  1 root root     10,  53 Dec 21 12:39 xt_qtaguid
crw-rw-rw-  1 root root      1,   5 Dec 21 12:39 zero
brw-rw----  1 root disk    253,   0 Dec 21 12:39 zram0

 

Link to post
Share on other sites

root@bpi-iot-ros-ai:~# ls -al /dev/mtd0
crw------- 1 root root 90, 0 Dec 21 21:09 /dev/mtd0
root@bpi-iot-ros-ai:~# dd if=/dev/mtd0 of=dump.dd

doesn't complete.

 

root@bpi-iot-ros-ai:~# journalctl -f

shows a lot of 

Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 17 kernel messages
Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] sb2 get int 0x00000002 from SB2_INV_INTSTAT
Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 8 kernel messages
Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] Invalid access issued by SCPU
Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 11 kernel messages
Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] sb2 get int 0x00000002 from SB2_INV_INTSTAT
Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 12 kernel messages
Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] Invalid access issued by SCPU
Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 11 kernel messages
Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] Invalid access issued by SCPU
Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 14 kernel messages
Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] sb2 get int 0x00000002 from SB2_INV_INTSTAT
Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 16 kernel messages
Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] Invalid access issued by SCPU
Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 18 kernel messages
Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] sb2 get int 0x00000002 from SB2_INV_INTSTAT
Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 8 kernel messages
Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] Invalid access issued by SCPU
Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 14 kernel messages

 

 

root@bpi-iot-ros-ai:~# ls -al /root/dump.dd 
-rw-r--r-- 1 root root 0 Dec 21 21:42 /root/dump.dd

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

9 9