Star64: Armbian Installation
#1
Information 
There are quite a few possible variants of the installation process. Below instructions do not require a serial console. All steps are performed on a linux pc and not on the star64.


Code:
schaecsn@pc:~ mkdir riscv && cd riscv


Download armbian from the bottom of this page https://www.armbian.com/star64/, e.g. Armbian Sid CLI or Armbian Sid XFCE desktop.

dd armbian onto a micro sd card. For me, a micro sd card is /dev/sdb. YMMV:

Code:
schaecsn@pc:~/riscv$ xzcat Armbian_23.5.0-trunk.231_Star64_sid_edge_5.15.0.img.xz | sudo dd of=/dev/sdb status=progress


Above image does not boot from the micro sd card - it misses a device tree for the star64.

Even with a device tree, armbian's kernel shuts down all usb ports, e.g. keyboard and mouse. For all this to work, use Fishwaldo's kernel. It can be compiled on a Linux PC.

Install a cross-compiler. That is distribution dependent. On Debian, that would be

Code:
schaecsn@pc:~/riscv$ sudo apt-get install libncurses-dev libssl-dev bc flex bison make gcc gcc-riscv64-linux-gnu


Download Fishwaldo's kernel

Code:
schaecsn@pc:~/riscv$ git clone https://github.com/Fishwaldo/Star64_linux linux
schaecsn@pc:~/riscv$ cd linux


Configure this kernel (CONFIG_SECCOMP is needed by armbian's default systemd service chrony)

Code:
schaecsn@pc:~/riscv/linux$ make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- pine64_star64_defconfig
schaecsn@pc:~/riscv/linux$ scripts/config -e CONFIG_SECCOMP
schaecsn@pc:~/riscv/linux$ scripts/config -d CONFIG_SECCOMP_CACHE_DEBUG


Apply possible patches:


Crosscompile the kernel

Code:
schaecsn@pc:~/riscv/linux$ make -j4 ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu-  bindeb-pkg


Above step creates these files and directories

Code:
schaecsn@pc:~/riscv/linux$ ls -lad ../linux-image-5.15.107-15659-g7943fd6427b0-dirty_5.15.107-15659-g7943fd6427b0-dirty-1_riscv64.deb arch/riscv/boot/Image  debian/linux-image/lib/modules/5.15.107-15659-g7943fd6427b0-dirty/ debian/linux-image/usr/lib/linux-image-5.15.107-15659-g7943fd6427b0-dirty

-rw-r--r-- 1 schaecsn staff 19734212 May 28 22:47 ../linux-image-5.15.107-15659-g7943fd6427b0-dirty_5.15.107-15659-g7943fd6427b0-dirty-1_riscv64.deb
-rwxr-xr-x 1 schaecsn staff 26410944 May 28 22:45 arch/riscv/boot/Image
drwxr-xr-x 3 schaecsn staff    4096 May 28 22:46 debian/linux-image/lib/modules/5.15.107-15659-g7943fd6427b0-dirty/
drwxr-xr-x 4 schaecsn staff    4096 May 28 22:46 debian/linux-image/usr/lib/linux-image-5.15.107-15659-g7943fd6427b0-dirty


The correct way to install Fishwaldo's kernel / modules / device tree would be to run this command on a booted star64 system

Code:
sudo dpkg -i linux-image-5.15.107-15659-g7943fd6427b0-dirty_5.15.107-15659-g7943fd6427b0-dirty-1_riscv64.deb


I'm not awfully familiar with armbian. For some reason, the generated deb does not correctly install itself into the /boot directory. On top of this, we can't boot the current armbian installation as it misses a device tree, anyway.

A workaround is a manual installation of the kernel / modules / device tree.

Find an empty directory, say /mnt/tmp and mount the micro sd card on it:

Code:
schaecsn@pc:~/riscv/linux$ sudo mount /dev/sdb1 /mnt/tmp


Remove symbolic links of the kernel and device tree directory on the micro sd card (there is no need to make changes to the module directory as the old and new module directory names differ)

Code:
schaecsn@pc:~/riscv/linux$ sudo rm /mnt/tmp/boot/Image /mnt/tmp/boot/dtb


Copy over our kernel / modules / device tree on the micro sd card

Code:
schaecsn@pc:~/riscv/linux$ sudo rsync -avzH debian/linux-image/usr/lib/linux-image-5.15.107-15659-g7943fd6427b0-dirty /mnt/tmp/boot/dtb
schaecsn@pc:~/riscv/linux$ sudo rsync -avzH arch/riscv/boot/Image /mnt/tmp/boot/
schaecsn@pc:~/riscv/linux$ sudo rsync -avzH debian/linux-image/lib/modules/5.15.107-15659-g7943fd6427b0-dirty /mnt/tmp/lib/modules


Fix a typo of the device tree name in extlinux

Code:
schaecsn@pc:~/riscv/linux$ sudo sed -i s/jh7110-star64-pine64.dtb/jh7110-pine64-star64.dtb/ /mnt/tmp/boot/extlinux/extlinux.conf


Done

Code:
schaecsn@pc:~/riscv/linux$ sudo umount /dev/sdb1



Next boot the micro sd card on the star64.

Code:
schaecsn@192.168.0.216's password:
____  _              __  _  _ 
/ ___|| |_ __ _ _ __ / /_ | || | 
\___ \| __/ _` | '__| '_ \| || |_
___) | || (_| | |  | (_) |__  _|
|____/ \__\__,_|_|  \___/  |_| 
                                 
Welcome to Armbian 23.05.0-trunk Bookworm with bleeding edge Linux 5.15.107-15659-g7943fd6427b0-dirty

No end-user support: built from trunk

System load:  54%              Up time:      0 min
Memory usage:  1% of 7.73G      IP:            192.168.0.216
CPU temp:      50°C            Usage of /:    23% of 7.2G 
RX today:      44.0 MiB 

[ 0 security updates available, 12 updates total: apt upgrade ]
Last check: 2023-05-21 15:22

Last login: Sun May 21 15:23:30 2023 from 192.168.1.231
schaecsn@star64:~$


Tuning after a first boot:

Code:
[   21.771962] Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8852bu_fw.bin not found

This firmware blob for bluetooth comes from  armbian-firmware-full. Install it

Code:
schaecsn@star64:~$ sudo apt-get remove armbian-firmware
schaecsn@star64:~$ sudo apt-get install armbian-firmware-full

Possibly install GPU firmware as described in https://forum.pine64.org/showthread.php?tid=18301


Our integration of the kernel / module / device tree shortcuts the package management and armbian kernel / modules / device tree updates may overwrite our own versions.

My first try was deinstalling armbian's kernel / modules / device tree package. That turned out to have disadvantages. Packages that modify initrd trigger commands which come with the kernel package and fail updating the initrd.

For now, I can only suggest to manually copy over our kernel / modules / device tree whenever armbian overwrites them with its own versions.

On the long, armbian should better support the star64 and custom kernel / modules /device trees should not be necessary, anymore.

I was also playing around with ubuntu's riscv port. There, custom kernels can be installed with dpkg -i linux-image*.deb. They hook themselves up to grub and peacefully co-exist with the vanilla kernel.


Please post corrections and possible improvements (in particular on how to better make our own kernel co-exist with the package management).
  Reply
#2
OK I cross-compiled the kernel. I'm using a different toolchain, because arm64 Debian's riscv64 gcc is broken.
I'm using this one:
https://github.com/riscv-collab/riscv-gnu-toolchain

I encountered a build error due to a missing file vdso.so.dbg. I changed a script riscv/kernel/vdso/.vdso.so.dbg.cmd and was able to create it. This issue was probably due to my toolchain.

For copying files into Armbian, I didn't see a "dirty" image directory, so I removed that suffix. My commands were these:

sudo rsync -avzH debian/linux-image/usr/lib/linux-image-5.15.107-15659-g7943fd6427b0/ /mnt/boot/dtb
sudo rsync -avzH debian/linux-image/lib/modules/5.15.107-15659-g7943fd6427b0 /mnt/lib/modules
sudo rsync -avzH arch/riscv/boot/Image /mnt/boot/
sudo sed -i s/jh7110-star64-pine64.dtb/jh7110-pine64-star64.dtb/ /mnt/boot/extlinux/extlinux.conf

Then finally I booted it and it worked, albeit with only 4GB of RAM detected, and there were startup errors.
The Armbian welcome screen stayed visible for probably 4 minutes.
There are also almost no packages installed, but luckily Ethernet works fine, so there will be a lot of apt installing tonight.

Caveat 1:
I discovered that because I refused to enter passwords for my root and user accounts, I later couldn't log in to either account. So I'll have to redo the process.

Caveat 2:
I'm finding that if I disconnect the HDMI cable while on a virtual console i.e. not X, so that I can use the monitor with my main computer, the Star64 will have video issues e.g. blanking for a while or indefinitely. This happens whether I'm using Armbian or Fishwaldo's build.
  Reply
#3
For seeing all 8GB, you need to apply this patch https://forum.pine64.org/showthread.php?tid=18263. The "-dirty" suffix probably comes from me having a patch applied.

Yeah, a very few systemd services fail (smartmontools failed as well. I deinstalled it as I don't see a need on a micro sd card based system)

Code:
schaecsn@star64:~$ systemctl --failed
UNIT                        LOAD  ACTIVE SUB
armbian-zram-config.service loaded failed failed Armbian ZRAM
chrony.service              loaded failed failed chrony, an NTP client/
systemd-binfmt.service      loaded failed failed Set Up Additional Binary Formats

After not booting the star64 for some hours, the time was off. I gain the impression there is no RTC and having an NTP client is a must. One should look into the chrony service failure. [Update a few hours later: Kernel config SECCOMP is needed by chrony: I updated the installation instructions][Update a few hours later: armbian-zram-config probably requires kernel option CONFIG_ZRAM - I'm not interested in zram and will simply disable this service].



I noticed one ethernet port is very flanky (the one directly on the board) and the other one works (the one on top of the other). I can't imagine that this is an armbian issue. Did you notice that on Fishwaldo's image as well?

Did you also notice that Xorg is very slow? I just started it once ... and decided to log in via ssh, only.
  Reply
#4
(05-30-2023, 05:08 PM)Der Geist der Maschine Wrote: For seeing all 8GB, you need to apply this patch https://forum.pine64.org/showthread.php?tid=18263. The "-dirty" suffix probably comes from me having a patch applied.

Yeah, a very few systemd services fail (smartmontools failed as well. I deinstalled it as I don't see a need on a micro sd card based system)

Code:
schaecsn@star64:~$ systemctl --failed
UNIT                        LOAD  ACTIVE SUB
armbian-zram-config.service loaded failed failed Armbian ZRAM
chrony.service              loaded failed failed chrony, an NTP client/
systemd-binfmt.service      loaded failed failed Set Up Additional Binary Formats

After not booting the star64 for some hours, the time was off. I gain the impression there is no RTC and having an NTP client is a must. One should look into the chrony service failure. [Update a few hours later: Kernel config SECCOMP is needed by  chrony: I updated the installation instructions][Update a few hours later: armbian-zram-config probably requires kernel option CONFIG_ZRAM - I'm not interested in zram and will simply disable this service].



I noticed one ethernet port is very flanky (the one directly on the board) and the other one works (the one on top of the other). I can't imagine that this is an armbian issue. Did you notice that on Fishwaldo's image as well?

Did you also notice that Xorg is very slow? I just started it once ... and decided to log in via ssh, only.

Xorg is extraordinarily slow, considering how fast Wayland was. As I understand it, X is usually sped up by establishing a shared memory area so that clients can talk to the server quickly and pass a lot of data. Back in the day, the connection to the X server was a stream of bytes. My guess is that the shared memory area wasn't enabled or a library was missing when Xorg was compiled.

Both of my Ethernet ports seem to be working fine. I was able to download many gigabytes on each of them. I did notice however that when I pull the cable out and put it in the other port, there's a one minute wait for the network to start working again.

Another issue I'm seeing is an error on the console where a kworker is blocked for too long.

The JH7110 SoC spec sheet shows that it has an RTC, but looking at the board I don't see a battery for it.

By the way 8GB is working for me now, your fix worked.

I've been updating my system with every package I could think of. The fact that X is too slow to use is the first big problem to tackle. Maybe I'll recompile the Xorg server.
  Reply
#5
(05-31-2023, 02:23 PM)tantamount Wrote: Xorg is extraordinarily slow, considering how fast Wayland was. As I understand it, X is usually sped up by establishing a shared memory area so that clients can talk to the server quickly and pass a lot of data. Back in the day, the connection to the X server was a stream of bytes. My guess is that the shared memory area wasn't enabled or a library was missing when Xorg was compiled.

I can't imagine that no shmem support brings X to such a crawl.

I don't have Xorg installed on Armbian, anymore. That's from another machine. That's how you can check for shmem support

Code:
~$ grep -i shm /var/log/Xorg.0.log
[   123.365] (II) Initializing extension MIT-SHM


Quote:Both of my Ethernet ports seem to be working fine. I was able to download many gigabytes on each of them.

Oh, now both ethernet ports work. I'm not sure what changed. Guess I'm not as tech savvy as I thought Undecided

Quote:Another issue I'm seeing is an error on the console where a kworker is blocked for too long.

I don't see an blocked kworker threads

Code:
root@star64:~# journalctl -b 0| grep kworker
root@star64:~# dmesg | grep kworker
root@star64:~#

Here are my complete boot logs http://corona.crabdance.com/riscv/bootlo...230529.txt

Well, that does not help you that much.
  Reply
#6
I updated my original posting with how to install the bluetooth and gpu firmware. The latter is mostly a reference to https://forum.pine64.org/showthread.php?tid=18301.  @tantamount, do you want to try Xorg with proper GPU support, again?
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  [Star64] Help needed in understanding Yocto and U-boot build process InterestedinFOSS 0 341 04-23-2024, 10:58 AM
Last Post: InterestedinFOSS
  Star64 JH7110 (slarm64, riscv64) mara 2 1,362 10-09-2023, 03:43 AM
Last Post: mara
  Star64: GPU firmware loading on Armbian Der Geist der Maschine 13 5,294 09-29-2023, 05:46 PM
Last Post: mara
  Star64: jtag debugging? bluepill 1 1,178 09-20-2023, 08:26 AM
Last Post: bwooster0
  Star64: 4GB on 8GB boards Der Geist der Maschine 4 2,379 07-27-2023, 12:32 AM
Last Post: balbes150
  Star64: SATA Der Geist der Maschine 1 1,232 07-26-2023, 12:35 PM
Last Post: Gladox114
  Star64: a first benchmark Der Geist der Maschine 0 2,150 05-29-2023, 01:00 PM
Last Post: Der Geist der Maschine
  Star64 first boot (and success) bortzmeyer 1 1,846 05-24-2023, 02:45 AM
Last Post: draintroup
  No WIFI network discovery in any manjaro installation (but works on fedora) pineitup 1 3,024 02-02-2021, 12:13 AM
Last Post: PineSupporter
  Probably stupid question from me re: installation RAK64pine 7 9,462 05-23-2016, 07:50 AM
Last Post: RAK64pine

Forum Jump:


Users browsing this thread: 1 Guest(s)