Jump to content

Proof of concept - Realtek 1295

Staars

By Staars
in New boards

 Share

Recommended Posts

Staars

Staars

Posted
Posted

Hi,

 

after reading the very entertaining thread regarding the BPI-W2 and the following opening of the bsp-kernel on github, I became curious and when prices dropped for the Lake-1-TV-Box, I decided to play around with it.

 

Without very much documentation there was a bunch of trial and error and still many things are not absolutely clear to me, but finally I could boot an armbian build today: 

 _          _          _ 
| |    __ _| | _____  / |
| |   / _` | |/ / _ \ | |
| |__| (_| |   <  __/ | |
|_____\__,_|_|\_\___| |_|
                         

Welcome to ARMBIAN 5.68 user-built Ubuntu 18.04.1 LTS 4.9.119-rtd1295   
System load:   1.49 0.74 0.31   Up time:       3 min
Memory usage:  4 % of 1631MB    IP:            
CPU temp:      46°C             
Usage of /:    11% of 7.2G      

[ General system configuration (beta): armbian-config ]

New to Armbian? Check the documentation first: https://docs.armbian.com


Thank you for choosing Armbian! Support: www.armbian.com

 

This is still connected over the serial port and completely untested. I had to use the strange chained double-u-boot and load kernel and dtb manually (from raw sd card sectors), so it is not even close to alpha. But it seems, that this can be improved. 

 

I plan to make a repeatable build config, but do not expect some really usable stuff anytime soon.  The situation with the lack of mainline support was already discussed in the other thread and the future does not look very bright here.

This is more or less a personal playground at the moment. But if anyone is interested, you can leave comments or questions here.

 

Sticky part (updated 03-03-2019):

 

RTD1295-Devices:

      Tested: Lake 1 Home Cloud TV Box

      Untested: Beelink SEA 1, Zidoo X9s, Zidoo X8, Zidoo X10,  Probox2 AVA, WD My Cloud Home, ...

 

All development and tests thus far have been done on the Lake-1-TV-Box. It can not be ruled out, that the other boxes have other u-boot-versions/-configurations.

 

Prerequisites:

Mandatory:

Serial connection soldered to the PCB (to reach the u-boot-shell) and a suitable terminal software. Further information here: https://en.opensuse.org/HCL:Lake1 (I can not confirm that „SD rescan“ does not work. Only „fatls“ and „fatload“ never worked for me, that’s why raw sector reads are used.)

 

Easy serial connection without soldering

 

Recommended:

Access to a Windows-PC, a USB-male-to-male-cable and the knowledge to re-flash the device by yourself.

If you are not comfortable in doing this, DON’T DO IT!!! YOU CAN BRICK YOUR DEVICE FOREVER !!

 

Current installation process (booting from SD-Card):

  1. Build a full-OS-image with armbian selecting „lake1“ from this fork: https://github.com/Staars/build. This will create an image with kernel image and dtb written to sectors before the root partition. The u-boot-build of armbian is not used.
  2. Write the image (using etcher) to an SD-card. For the moment we will not touch the eMMC of the target device and therefore will work as non-destructive as possible. This might change in the future and it should be no problem to implement a eMMC-only solution, but at the moment there is no solution in sight, that would let you dual-boot Android and Linux.
  3. Create a terminal connection to the serial pins of your target device and intercept the boot process immediately after power up to reach the first u-boot-shell. Now we have to edit the BOOTCMD the following way:
  • env edit bootcmd
  • sd read $kernel_loadaddr 800 954a; sd read $fdt_loadaddr a440 5d; env set bootargs earlycon=uart8250,mmio32,0x98007800 console=ttyS0,115200 noinitrd root=/dev/mmcblk0p1 rootfs=ext4  init=/sbin/init; b2ndbc; bootr
  • env save

 

           This is a relatively harmless operation and can be reversed with the insertion of 'bootr' in step 2.

           The Android-installation on the eMMC stays untouched.

 

   4. Now at every boot the device will initialize the SD (which can fail!!), load the image and dtb, change the bootargs and call the second u-boot, which then will (hopefully) boot the kernel. 

 

U-boot:

At the moment u-boot will be build, but not used. Because of bootloader encryption this will likely stay that way. We can build the fsbl-parts, but without the proper encryption the boot stops, when the first part (hw_setting) is loaded. 

A separated u-boot-fork at https://github.com/Staars/u-boot-rtd is used for the armbian build, but that does not really matter. We must use the vendor-u-boot and we can not do real scripting (no RUN-command) but only chaining of commands.

 

Kernel:

The starting point from Sinovoip was labeled 4.9.119, but this is very likely not the whole story. Some parts are even newer and some are probably older, given the fact that git-cherry-picking showed possible updates when used with the stable linux-4.9-branch below tag:4.9.119.

The additional phoenix drivers were partly integrated in the kernel-fork on https://github.com/Staars/linux-kernel-rtd/tree/latest_patched as an extra folder to keep them in one place.

If there should be really an adoption of this platform in the future, it might be a good idea to go the other way around and merge the soc-specific parts into a generic linux-4.9.-fork. This is a bit of work, but it should be possible.

The fork is currently patched to 4.9.174

New kernel fork started at https://github.com/Staars/linux-stable/tree/linux-4.19.y (not 4.20 because of LTS) and armbian build config updated.

 

DTS/DTB:

This is a minimal changed version for the banana-pi w2. 

 

Bluecore.audio:

I do not really know if this (audio firmware?) is useful outside of Android. It is written to the SD-Image (directly behind the DTB), but not loaded.

 

What works:

-SATA-port (incl. booting with /root on SSD with bootarg 'root=/dev/sataa1')

-WLAN (onboard 8821AU), but there are very short freezes every few seconds

-simple software install (i.e. OMV)

-reboot/restart works, but can take some time

-bluetooth

 

What does NOT work:

-bluetooth

-halt/restart

 

Things to do:

-waiting for someone, who confirms, that this is repeatable on other setups

-working on the DTS/DTB

-test Ethernet, USB

-HDMI-in/-out or graphics in general (very low priority for me)

-eMMC-only-install (must check first, where it is safe to write data)

-test 4.19 (functional regression expected)

 

Board_Pics:

  Reveal hidden contents

 

2
jock

jock

Posted
Posted

Pretty interesting device! I see from the Internet it has an embedded SATA slot, RTC, 802.11ac wifi, HDMI IN and it has Mali-T860 GPU on a 4-core A53 design, where all other chinese propose outdated GPUs

Also the "legacy" kernel looks recent enough, which is nice to start with.

 

Congratulations and keep it up :thumbup:

 

edit:

bringing u-boot to boot is one of the most difficult tasks, I faced it when I had to deal with it and Chiptrip Q8 RK3288 (xt-q8l-v10) tv box because I had to use the vendor bootloader and chaining it to u-boot SPL which, in turn, boot the real u-boot.

0
Staars

Staars

Posted
  • Author
Posted

Just some additional infos:

 

Starting points were https://en.opensuse.org/HCL:Zidoo_X9S and the "new" repo from the bananapi side.

After soldering some wires directly to the PCB I tried to gain some info on the machine itself,  which has some sort of dual boot to android and a "rescue linux" with kernel 4.1.x.

The chained boot process was already described by afaerber and at least we can save the u-boot-environment on the device, which I only tested with the bootdelay so far, because I do not want to brick anything at the moment.

Then I played with the banana build system, which I am not used too. In parallel I created 2 repos with the kernel and u-boot in order to build it with the armbian build system and I could compile it rather soon. But I could not boot anything at that time.

 

After that came the trial-and-error part, which will continue for some time.

In short:

After trying out the awfully slow ymodem for kernel load, I ended in writing kernel and dtb to the start of a sd card and load it by hand in the "first" u-boot. I adapted the arminian build process to write both things to the image instead of the usual u-boot.

 

So things works like that:

1. Power-on with serial connected, interrupt  first u-boot with ESC.

2. Use the following commands: 

sd read $kernel_loadaddr 800 954a
sd read $fdt_loadaddr a440 5d

fdt addr $fdt_loadaddr
fdt resize
b2ndbc

3. The last line continues the boot process, which must be interrupted again with a key press, then: 

setenv bootargs earlycon=uart8250,mmio32,0x98007800 console=ttyS0,115200 noinitrd root=/dev/mmcblk0p1 rootfs=ext4  init=/sbin/init

bootr

 

That's basically all I know at the moment and the quest continues. If I do not brick/destroy the box (which could happen), I plan to upgrade the kernel repo to 4.9.150 and if this works out, I hope to find a way to create an easier boot process.

0
Staars

Staars

Posted
  • Author
Posted 
Welcome to ARMBIAN 5.71 user-built Ubuntu 18.04.1 LTS 4.9.138-rtd1295   
System load:   1.15 1.02 0.73   Up time:       15 min   
Memory usage:  4 % of 1631MB    IP:            
CPU temp:      46°C             
Usage of /:    6% of 15G

It is somehow patchable, to be continued ...

0
Staars

Staars

Posted
  • Author
Posted 
 _          _          _ 
| |    __ _| | _____  / |
| |   / _` | |/ / _ \ | |
| |__| (_| |   <  __/ | |
|_____\__,_|_|\_\___| |_|
                         

Welcome to ARMBIAN 5.72 user-built Ubuntu 18.04.1 LTS 4.9.151-rtd1295   
System load:   2.25 1.47 0.79   Up time:       9 min
Memory usage:  5 % of 1631MB    IP:            192.168.0.102
CPU temp:      46°C             
Usage of /:    13% of 7.2G      


pi@lake1:~$ iwconfig
wlan1     IEEE 802.11  ESSID:"xxxxxxxxxx"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: 80:EA:96:F1:84:7A   
          Bit Rate=72.2 Mb/s   Tx-Power=12 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=48/70  Signal level=-62 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

lo        no wireless extensions.

eth0      no wireless extensions.

wlxa02c36ec6d34  IEEE 802.11  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=12 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          
pi@lake1:~$

 

Well,  brave little box ;) (yes, it is 4.9.151 now and integrated wifi)

 

But now comes the ugly part ... how to boot automatically?

 

 

0
Staars

Staars

Posted
  • Author
Posted

So, a few days later .....

 

After spending several hours with my box including multiple head-banging on my desk, I found a surprisingly simple solution for an automated boot. But first some infos:

 

1. Many of the RT1295-Boxes seem to have encrypted bootloaders (and kernel images) which makes it close to impossible to build new ones. One notable exception is (according to the firmware images) the Zidoo-line. If I understand correctly, it should be very dangerous to flash a Zidoo-box with another firmware (Lake, Beeling, Probox), because if the filenames containing words like "efuse" have a deeper meaning, then you can never again flash the Zidoo-Firmware. If someone knows more about this topic, I would be very interested to hear about.

 

2. The GitHub-repo from BPI is bizarre, to say the least. They included a bunch of software to build encrypted firmware, which should not be needed for the BPI-W2. I could not get it to work, but maybe some others are able to do it. If someone can succeed, then point 1 shines in another light. At least you can build the dvrboot.bin and dvrboot.exe.bin yourself and I do not understand, why they (the bananapi-guys) describe cumbersome ways in their forum to download all that stuff from somewhere as a binary. I could not test these files on my Lake-1-box because of point 1, so it could be that they do not really work.

 

3. In the end it was relatively simple. In the first u-boot, you can modify and (!!) save the bootcmd and (!!) you can pass multiple commands to it. You have to: 

env edit bootcmd

then You will be asked for the new value and have to insert: 

sd read $kernel_loadaddr 800 954a; sd read $fdt_loadaddr a440 5d; env set bootargs earlycon=uart8250,mmio32,0x98007800 console=ttyS0,115200 noinitrd root=/dev/mmcblk0p1 rootfs=ext4  init=/sbin/init; b2ndbc; bootr

Please keep in mind that you have to use my "special" SD-card, where the kernel image and the dtb a written to the blocks 0x800 and 0xa440.

That's it for the moment.

 

If I find something new, I will update this thread. Feel free to ask.

2
Staars

Staars

Posted
  • Author
Posted (edited)

Just a tiny update. Booting from SSD works as expected:

  Reveal hidden contents

 

It is not completely free of error messages, but it is quite okay'ish.

 

I will try to update my first post in order to gather the most recent information there. 

Edited by Tido
added spoiler - for better reading, please do that yourself next time. thx
3
Staars

Staars

Posted
  • Author
Posted

After some tests I recognized, that reboot works, but it can take some time and so I was simply not patient enough. This is not really new,  but I will update my incorrect observation in the first  post.

0
Staars

Staars

Posted
  • Author
Posted

Okay, let‘s get started!

 

First thing is to solder the UART-connection to the PCB and establish a connection via some kind of terminal software. You must be able to enter the u-boot-shell. 

Are you there already?

 

0
Staars

Staars

Posted
  • Author
Posted

Then you can build an image and see, if this works.

1. Clone my armbian-build-fork

2. Choose ‚lake1‘ , build a full-disk-image and burn it to SD

 

BTW, I am quite sure, that I bricked my box yesterday (in an episode of mental derangement). After losing my grumpy cat face, I will order a new one :wacko:.

0
chwe

chwe

Posted
Posted

@Staars can we remove the 'no board bring up' and move it into 'board bring up'? :lol: Only cause it's there doesn't mean it will ever make it into 'official' armbian (Mt7623 is also only csc and sources there are clearly in a better shape than this one). But due to 'archive reasons' I think people would expect it to find it there.. Your progress is nice, but it clearly shows that this SoC is far away from being 'easy to maintain'.. And it's good to have this documented in case the 'why is RTD1295 not supported by armbian' guys showing up here. :)

@zador.blood.stained, @Igor, @TonyMac32, @tkaiser, @martinayotte, @everybody I forgot any concerns about it?

0
Staars

Staars

Posted
  • Author
Posted

Yes, we can do it that way and I will try to „maintain“ it.

 

Indeed it might me a good idea to show, why this platform is far away from getting official support. Even though I invested a bit of work, I can not really recommend this box with productivity in mind. At the moment it is a very interesting toy.

It is a pity that realteks strategy does not really involve the linux/open source world, but they may have their reasons.

 

Anyway, I‘m curious to see how far we can get here. 

Probably I can not post anything new in the next few weeks, because I have to wait for my new box. I really bricked the first one (and I will explain my stupid error in an extra post).

0
Staars

Staars

Posted
  • Author
Posted

Short update on Wifi/BT:

I switched to the combi-88xx-drivers, which were added to armbian recently. To enable BT I had to create a patch, which turns off the firmware upload in /drivers/bluetooth/btrtl.c.

The behavior should be quite 'vanilla' now and I could scan the BT-(LE)-devices of my neighborhood without problems.

0
  • chwe changed the title to Proof of concept - Realtek 1295
jeanrhum

jeanrhum

Posted
Posted

Hi,

 

I received my box yesterday and was able to build and follow your instructions to get the following system:

  

 _          _          _ 
| |    __ _| | _____  / |
| |   / _` | |/ / _ \ | |
| |__| (_| |   <  __/ | |
|_____\__,_|_|\_\___| |_|
                         

Welcome to ARMBIAN 5.76 user-built Debian GNU/Linux 9 (stretch) 4.9.157-rtd1295   
System load:   1.31 0.91 0.41  	Up time:       5 min		
Memory usage:  3 % of 1636MB 	IP:            
CPU temp:      52°C           	
Usage of /:    2% of 58G

Great work!

1
Staars

Staars

Posted
  • Author
Posted

Cool!

Can you test Wifi, because I had to finalize the patches after I bricked my box.

For me the easiest way to do this over UART was: 

nmcli device wifi connect SSID-Name password wireless-password

 

0
jeanrhum

jeanrhum

Posted
Posted

I'm currently accessing it through ssh and using a wireless connection. It works well, here is iwconfig result: 

wlxa02c36cad0d2  IEEE 802.11  ESSID:"XXXXXXXX"
          Mode:Managed  Frequency:2.412 GHz  Access Point: XX:XX:XX:XX:XX:XX
          Bit Rate=72.2 Mb/s   Tx-Power=18 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=61/70  Signal level=-49 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

EDIT: I used armbian-config to set up the wifi.

1
jeanrhum

jeanrhum

Posted
Posted

Hi,

Current kernel is 4.9.y, is it possible to get a more recent kernel (4.19.y LTS or 5.0.y mainline)?

 

I tried to build a 4.19 by modifying the board config to have target next and dev as well as the source config. After running compile.sh with target next, I obtain a new image, but when trying to start it I got an error about bad gzipped data early after the second uboot start. I tried to modify the script writting uboot, but without any luck.

 

  Reveal hidden contents

 

Otherwise, I also tried to put a sata disk, but it appears as /dev/sataa and not /dev/sda and it is not recognized as a usable disk (nothing in /dev/disk) and OMV does not show it. It is the first time I see /dev/sataX dev and I don't know how to change that.

0
Staars

Staars

Posted
  • Author
Posted

It is funny, but just hours before your post I started my first steps to work on a 4.19-kernel. 

 

The general problem with vendor kernels is, that it might be possible to port it to a newer mainline kernel, but with every new kernel version the whole thing restarts again. Without upstreaming to mainline nothing is really won in the long term.

 

The current situation with 4.9.-LTS-kernel with support until 2023 is not extremely bad. Do you need a special feature of kernel>4.19?

 

To boot from sata I only had to „clone“ the sd card partition with dd and change the bootargs. 

 

Your log shows, that there is no working DTB loaded. I will my use „box-less“ time to extend the configs in my repo to support 4.19 and report here, when I think that it is ready for a test (or when I have a box again myself).

0
jeanrhum

jeanrhum

Posted
Posted

Thanks for your quick answer.

In fact I looked at the boot folder on my sd card and there only a few files. I think that the write_uboot_platform function is not working correctly since it is written with absolute path for dtb and uboot from your fork. I don't search for a specific feature, I was just curious how to do that since I have mainly a "user" experience of armbian and this device seems interesting to me (however realtek is not the best open source friendly...). I saw that rtd1295 started to be introduced since kernel 4.13 so I hope the recent kernel can be built and run on this soc.

 

For my second question, I'm not searching to boot from sata, but boot from sd and use a sata drive for a nas use case since this soc seems to be used in several nas commercial product.

0
Staars

Staars

Posted
  • Author
Posted

Curiosity is a very good reason ;) (it is basically the only reason for this whole thread)!

 

You are right, the dtb and kernel function in the script is hard coded atm.

 

To be honest, I only tested my SATA drive as boot device (did not spend very much time with it). Can you access it with fdisk?

 

I will use my spare time in the next days to play with the 4.19.-kernel, but do not expect fast results here.

0
jeanrhum

jeanrhum

Posted
Posted

No problem if you don't get any result soon. I wanted to do something, but I don't really know where to start.

 

I will try fdisk this evening when I'll be back home.

0
jeanrhum

jeanrhum

Posted
Posted

With fdisk, the disk appear labelled as sataa: 

Disk /dev/sataa: 465,8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 1807A3EC-C61F-48C2-B54B-A06A8856E92C

Device          Start       End   Sectors   Size Type
/dev/sataa1        40    409639    409600   200M EFI System
/dev/sataa2    409640 391034639 390625000 186,3G Apple HFS/HFS+
/dev/sataa3 391296784 783007583 391710800 186,8G Apple HFS/HFS+
/dev/sataa4 783269888 974675967 191406080  91,3G Linux filesystem
/dev/sataa5 974675968 976773119   2097152     1G Linux filesystem

In dmesg it is also detected correctly: 

[    3.543051] phy-rtk-sata 9803ff60.sata_phy: init phy0 OK
[    6.894037] ahci_rtk 9803f000.sata: masking port_map 0x3 -> 0x1
[    6.894079] ahci_rtk 9803f000.sata: AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x1 impl platform mode
[    6.894086] ahci_rtk 9803f000.sata: flags: ncq sntf pm led clo only pmp fbs pio slum part ccc sadm sds apst
[    6.894099] ahci_rtk 9803f000.sata: port 0 is not capable of FBS
[    7.102013] phy-rtk-sata 9803ff60.sata_phy: power on phy0
[   10.554421] sd 0:0:0:0: [sataa] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[   10.562394] sd 0:0:0:0: [sataa] 4096-byte physical blocks
[   10.568046] sd 0:0:0:0: [sataa] Write Protect is off
[   10.573921] sd 0:0:0:0: [sataa] Mode Sense: 00 3a 00 00
[   10.573972] sd 0:0:0:0: [sataa] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   10.635891]  sataa: sataa1 sataa2 sataa3 sataa4 sataa5
[   10.642417] sd 0:0:0:0: [sataa] Attached SCSI disk

 

0
Staars

Staars

Posted
  • Author
Posted

That looks good. 

 

Is ethernet working for you?

 

BTW, my attempts to create a patched kernel tree (4.19) were not exactly successful and I will have to gain some knowledge before I seriously can expect some results.  At least it does not get boring ;)

0
jeanrhum

jeanrhum

Posted
Posted

Ethernet is working. I deactivated wifi using armbian-config and then ran:

  

sudo dhclient eth0

There were these messages, but I got an IP and was able to access to internet:

  

smbd.service is not active, cannot reload.
invoke-rc.d: initscript smbd, action "reload" failed.
/etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /etc/resolvconf/run/resolv.conf

 

0
Staars

Staars

Posted
  • Author
Posted

Thanx for reporting. But to dig deeper, I really need the actual hardware -_-

 

I am making some progress on the 4.19.-front. There are lots of API changes in the kernel between 4.9 and 4.19,  but I hope to get it done. 

0

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.

×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept