6 6
Staars

Proof of concept - Realtek 1295

Recommended Posts

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

Share this post


Link to post
Share on other sites
15 hours ago, Staars said:

I do not know, which terminal he used.

I was under ubuntu using gtkterm.

 

It's nice to see your experiments even if it has been better that realtek and manufacturers published documentations.

Share this post


Link to post
Share on other sites
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.

Share this post


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!

Share this post


Link to post
Share on other sites
(edited)

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

Share this post


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?

Share this post


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.

Share this post


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?

Share this post


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).

 

 

Share this post


Link to post
Share on other sites

I like that they published complete guide how to use HW encoding with ffmpeg together with a patch and libraries  :)

Share this post


Link to post
Share on other sites

I sort-of object to the word "published" when GPLv2 code is offered from a private repo with docs marked "Realtek Confidential" .. but I guess it's a form of progress?

Share this post


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. :)

 

Share this post


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.

Share this post


Link to post
Share on other sites
6 hours ago, chewitt said:

I will submit the nag via some realtek people I tracked down via LinkedIn.

It was either in this forum or over at SinoVoip where a guy from RT helped in his spare time, but I cannot remember his nickname.

 

Share this post


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

Share this post


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

Share this post


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

Share this post


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.

Share this post


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.

Share this post


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...
6 6