So I have played with three versionf of linux on the QuaStation so far:
1. The built in stock Android system and Associated Linux Kernel
I haven't played with this much, because command line Android is not a lot of fun. I don't remember what kernel it was, but it's quite old.
Also, if you disable the normal startup mechanism after the kernel boots in order to try to hack it into running something morre Unixy, it will detect this and reboot. (Appears that there is a hardware watchdog that is periodically reset by some part of the stock userspace - so if you disable that user space, it will reboot after a few seconds).
Technically, you can run Ubuntu or whatever overtop of this system using chroot, but there are a lot of limitations, and the device gets quite warm, so the load is high or the power management is very poor.
One interesting thing to note about this was that one enterprising hacker managed to share the framebuffer over the network and see a very bare bones android screen! So yes, it does run Android, and yes it even has a frame buffer (video memory and a graphics chip or some sort on the SoC) - but just no video out. This could make for a really cool networked Android device, I suppose - but I am sure the Android version is quite olf and doesn't include Google Play store.
Honestly, it seems odd that they would choose to use Android on a headless system - but then this SoC was probably developed for headless use, so it may have just been easier for them to take the base system given to them by the SoC manufacturer (RealTek) and make the minimum modifications
2. Ubuntu 16.04.7 LTS /Linux quastation2.local 4.1.17-g9100299-dirty #149 SMP PREEMPT Tue Jun 23 00:31:50 JST 2020 aarch64 aarch64 aarch64 GNU/Linux
This one I received on one of the QuaStations I purchased, the seller had already burned it into an SD card (if I remember correctly). It is stable, but also quite old. The Ubuntu 16 userland was also already installed on the SD card.
I don't mind so much the system being a bit old so long as it supports what I want - but the kernel being old means it doesn't support some of the things I want it to, like the USB3 1Gbps ethernet adaptors. This version of the kernel doesn't support any recent high speed ethernet adaptor I could find, and only works with things like older USB2 dongles for Wii and older Apple Ethernet Dongles such as those for the original Macbook Air.
3. Ubuntu 20.04.3 LTS / Linux quastation0.local 4.9.119-BPI-W2-Kernel #2 SMP PREEMPT Sat Jul 3 01:26:49 PDT 2021 aarch64 aarch64 aarch64 GNU/Linux
This one I have compiled myself based on the BananaPi kernel. (I was able to cross-compile this on a linux PC, and I believe on an M1 Mac as well - bothing using Debian. I was not able to get it to compile on the QuaStation itself - though I suppose it would take a long time anyway).
This kernel seems to be slightly less stable (at least I think so, it's difficult to be sure, since there is no debug output I can see when a machine stops responding to know whether it is the kernel freezing or something else!)
The seller of the machine with the older OS installed mentioned that he recommends the older kernels for stability purposes as well. (He sells these machines to use with digital TV tuners, so I suppose those work with the older kernels).
Where did I get the userland Ubuntu system for this kernel? Well, I simply checked the Ubuntu Wiki page to see what version would support the 4.9 kernel and then installed that in an ARM VM, and stole everything except the kernel.
There may also be a Ubuntu system BananaPi that could be used.
One thing I noticed is that the RAM shows as 1.6GB even though the specs say it has 2GB. I *believe* that this is something to do with the device tree, but I am not an expert on such things.
Future Direction
I was starting to wonder how to handle these machines in the long term, but...
-----
I recently came across this project:
This is a 4.1.17 Kernel, but there is also this project by the same person, which is a 4.9 kernel based on the same Banana Pi Kernel I am using now, but he has made more customizations.
The page is in Japanese (as one would expect for a product only released in Japan) - but he has made some customizations to more properly support the QuaStation, including power management.
The power management situation can be summed up as this:
I have noticed this before, but when you apply power to the device with the serial console connected, either one of two things happens:
1. A message will be printed saying that power status is set to off, and then nothing else will happen unless you press the power button.
2. The system will boot up uboot normally and then try to load the operating system.
Apparently, the board itself does not have a true power off option, just a flag to tell it whether it should boot or not.
This means that when the kernel tries to shut down the system it panics. It should set a flag in the uboot firmware and reboot instead. This is handled by a script in the following project from the same author:
QuaStation Ubuntu
One of the WiFi chips is not working, but this is not a concern to me since I don't use the WiFi. In fact, I suspect that turning on the WiFi would be a congestion ightmare since I have like 20 of these things in close proximity. I also had an issue in the past where different machines seemed to have the same MAC addresses, though that might be because I cloned the eMMC ROMs.
Building the kernel
I used the standard build process for the BananaPi kernel in the past - which did not involve docker.
The author's build process uses docker, so I needed to install docker and docker.io on my PC. The reason he says he uses Docker is because GCC 10 will fail, and GCC 9 or before is needed. I don't know why I didn't have that problem in the past, but perhaps the VM I was using was GCC9.
Once that was done, there were some permissions issues, but eventually I got to this stage:
>make docker-image
Docker image for au kernel build is completed.
>time make build
au kernel (Linux 4.1.17) build is completed.
--------------------------------------------------------------------------------
0.25user 0.30system 1:53.68elapsed 0%CPU (0avgtext+0avgdata 49340maxresident)k
0inputs+0outputs (78major+6229minor)pagefaults 0swaps
The above was for kernel 4.1, the 4.9 from the source
here build took about 2m45s.
Compiling a new kernel is great - but I need a machine to actually test it, and all of the machines I already have are in use.
I will order a new one and play on there. If this kernel is stable and supports the USB3 ethernet dongles I want out of box, I may upgrade. (If not, I should be able to configure it accordingly).
Since there is also a customized Ubuntu project from the same author, I will summarize that in English as well in
this post.
Tsukumijima's build apparently didn't support USB3, as he linked to a form from mt999a which does. This doesn't make much sense to me since this worked on the BPi kernel I compiled, but... in that case I should use the fork because USB3 is important to me. I would imagine it's important to anyone/everyone! Whether you use thing machine to share files over ethernet, rip DVDs, or with a TV tuner to watch TV, USB3 will let everything work faster.
I managed to build the kernel from mt999a
here, and was able to boot the kernel without any issues.
WiFi works, 5 Ghz networks do show up on wlan1 (but not wlan2). I was able to use wpa_supplicant to connect on both devices. One strange thing is that when rebooting, these devices change, sometimes they are wlan0 and wlan3. This makes creating scripts a bit more difficult.
There are plenty of instructions online of how to do this, but a good example is
here.
The kernel configuration also did not include the correct compatibility extensions for iwconfig work, but iw does work. And here I thought the idea was not to break userspace! There is very little drawback to adding this compatibility into the kernel, so if you are going to be modifying the settings and recompiling anyway it might be something to add.
I wanted to format the sata drive, and I was saddened to find that BTRFS support is not included in this kernel build - even as a module. That should simply be illegal in this day and age!
I went back to my PC and used "make config" to edit the kernel config and enable btrfs and recompiled the kernel.
One really nice thing about the QuaStation is that if you are booting from USB, then it is very easy to replace the kernel and reboot. No bootloader building, etc. is required. Simply mount the boot drive, copy the files, and reboot. Uboot will load the new files upon reset. Assuming that the network is working, you can even update over the network. If you install a kernel that doesn't boot or has broken networking, you can of course also remove the USB device and modify it from another PC.
For some reason, when I used "make config" to enable btrfs and booted into that kernel, wifi devices disappeared from the list in "iw". They still showed up under lspci, so this is certainly a software issue. Since the wifi support disappeared. In order to ifix this, I had to go mack into make config, find and enable the rtlwifi support. It is buried quite deep in the config.
This is very strange, since I didn't change anything in the device driver / networking section.
Details on the path to the drivers in the menu can be found
here.
Note: You also have to go inside that setting and put an X for each individual card you want to support.
Since the new BTRFS enabled kernel didn't have a network connection, I swapped back to the non-BTRFS kernel and rebooted to get a connection, so that I could upload the new kernel that should have both.
Comments
Post a Comment