10 10
jock

CSC Armbian for RK3288 TV Box boards (Q8)

Recommended Posts

Yes you are right. I forgot that point about double boot which is not possible with jock image due to outdated uboot not able to boot from sdcard. I have no solution for you.

Share this post


Link to post
Share on other sites
On 5/12/2019 at 3:13 PM, paulludwig17 said:

Now I was trying to boot the image for the xt-q8l-v10, box but the display remains dark.

Is there a possibiliy by pressing any keys, to display a bootlog for further analysis ?

You have to open the box to find the uart pins and use an usb2ttl device to connect to another computer with a serical console software.

 

Share this post


Link to post
Share on other sites
On 5/12/2019 at 3:13 PM, paulludwig17 said:

If I understand instructions right, then I've to erase the firmware to boot from the SD card ?

But then, I will loose  android OS in general, what I would like to avoid.

Is there a dual boot firmware available, which will boot from

SD card and switch to internal memory only in case, there is no bootable sd card installed ?

 

At the moment, I have installed a firmware called "wasser 4.0.11", which is an android 6.0.1 version.

In the past I had a ugoos linux version (14.xx) on a SD card, which was able to boot with this firmware.

 

Now I was trying to boot the image for the xt-q8l-v10, box but the display remains dark.

Is there a possibiliy by pressing any keys, to display a bootlog for further analysis ?

 

best regards, Paul

 

Hello,

unfortunately there isn't a dual boot feature: the main reason is that the u-boot version originally shipped with the box is from 2014. It is quite outdated and it is able to boot Android boot images only.

 

When I started the project I made the design choice to support mainline u-boot to best support Armbian. In theory the original u-boot can boot from an external SD card, but the kernel, initramfs and other bits should be "mangled" to fit into an Android boot image, something I never experimented with.

 

The bootlog is available only from the serial port, so no way to show it up on screen.

If you take a look to the Armbian downloads page you can download the CSC official image and found the instructions to backup and restore the existing eMMC image.

 

Share this post


Link to post
Share on other sites

I have tried  https://dl.armbian.com/xt-q8l-v10/archive/Armbian_5.75_Xt-q8l-v10_Ubuntu_bionic_next_4.19.20_desktop.7z  image and, alas, the problem with vertical magenta strip at the left display edge and resulting no sound output is still there.

 

In a sense for me it's a deal breaker - because not only I am going to use the whole gig at home, and it's not an option to ask a non-technical person to disconnect and then to connect the HDMI cable. Besides that, unplugging and plugging HDMI cable means unnecessary contact wear.

 

If I understand correctly, disconnecting and then connecting HDMI cable somehow re-initializes video and audio systems. So probably the same can be achieved by program means. So, what drivers one needs to unload/load and/or what scripts/daemons one needs to restart in order to achieve the same results ?

 

I have also looked into /var/log/kern.log file, and I didn't notice any new messages resulting from unplugging and plugging again the HDMI cable, though maybe I wasn't looking too well.

 

...

 

Maybe one can by program means set wrong and then again correct display resolution and this will work around the problem ? If yes, or if it's worth trying, what is the command sequence to try this ?

 

...

 

Maybe somebody has a link to another Linux image which works out of the box ?

Share this post


Link to post
Share on other sites

@Sergei SteshenkoThe purple line is a bug in the kernel HDMI driver. It appears in all rk3288 devices.

Plugging and unplugging is a solution, but you can also turn the monitor off and on or use xrandr to switch resolution, for example:

xrandr --output HDMI-1 --mode 1920x1080

The purple line appars every other time HDMI change status, so a software solution with xrandr you have to switch to another resolution, then to a third resolution and finally back to your native resolution. You can easily make a script to automatize the workaround.

Share this post


Link to post
Share on other sites

@jock  thanks for the 'xrandr' suggestion - I will try it.

 

Another observation. Using the XFCE GUI entries I tried to change the refresh rate from 60 to 30 - not changing the resolution. This screwed up X11 - it failed to start after the change. However the change also caused appearance of that infamous vertical magenta strip in text mode as Linux boots. There was no vertical magenta strip before my change.

 

So, it seems, some X11 setting isn't quite right - because intentional changing of refresh rate causes the same defect.

Share this post


Link to post
Share on other sites

I am playing with display modes - no good news (yet ?).

 

However, turning monitor off and then on indeed solves the problem. When X11 screen look OK after turning monitor off and on, virtual consoles (i.e. text mode) display the infamous magenta stripe.

Share this post


Link to post
Share on other sites

Still no good news with 'xrabdr'. Fundamentally, my monitor supports only one mode, so other modes have no effect when I use 'xrandr'. I.e. the whole thing always reverts to default.

 

Another strange thing happened. I was doing 'rmmod' and then 'modprobe' of several kernel module in the hope to reinitialize the and thus maybe change the system behavior. I wasn't changing any configuration file on the way. After a number of attempts sound reproduction disappeared completely - regardless of presence of the vertical magenta strip. There were no error messages during 'modprobe' operations.

 

So, in order to restore sound I simply re-flashed the SD card - now I again have sound. Very strange.

Share this post


Link to post
Share on other sites

@Sergei Steshenko Yeah, the bug of the purple line appears in text mode too, because (I guess) it's somewhere in the HDMI kernel driver, so it is not happening in X only. I don't really remember, but it was there (sort-of) in the legacy 4.4 rockchip kernel too, but I'm not totally sure.

 

It's curious your monitor supports only one mode. Usually monitors expose via EDID a list of modes and one mode is "preferred", which is usually the native resolution. Did you try your monitor on a regular PC to check if it really supports just one mode? @pro777 had issues with resolution modes because his box was not reporting any EDID at all, maybe yours has the same issue.

 

Both your issues with the refresh rate and sound are quite strange: changing the refresh rate should not make X crash at boot. Sometimes, expecially with older (<4.20) kernels, it may happen that sound disappears even without the purple line: my guess is that it is the very same problem in the HDMI driver of the purple line, something like bad clocks or bad parameters.

Share this post


Link to post
Share on other sites

I didn't try this monitor with a regular PC - it's physically inconvenient for me to try. The monitor is a "no-name" - I got it as a present, its IR control (it was used by the original owners as TV screen) stopped working, so the original owners bought a new monitor.

 

The good news is that when I use optical out, sound is not affected by presence/absence of the magenta stripe. And my "production" use means using optical out.

 

"Sometimes, expecially with older (<4.20) kernels, it may happen that sound disappears even without the purple line" - appears to be that way. I.e. I have an impression that sound sometimes disappears even without the magenta stripe. With optical out it appears to be more stable. The image I'm using has a 4.19.20 kernel, i.e. a version that can be affected according to your statement. I don't official Armbian images with newer kernel exist.

 

Anyway, is the buggy kernel driver being worked on ? Or it's a closed source part and everything depends on Rockchip ?

Share this post


Link to post
Share on other sites
2 minutes ago, Sergei Steshenko said:

The good news is that when I use optical out, sound is not affected by presence/absence of the magenta stripe. And my "production" use means using optical out.

 

Anyway, is the buggy kernel driver being worked on ? Or it's a closed source part and everything depends on Rockchip ?

That's an HDMI problem, so optical output is always fine (maybe you're interested in giving the sound devices the right names, check this)

The bug, as far as I know, is not being actively worked on. @Myy imported some patches that tweaked the HDMI clocks which got into newer kernels, but the problem was not solved.

Share this post


Link to post
Share on other sites

Another set of questions.

 

I want to use an external USB drive (to be exact, an HDD with USB adapter) to host the system. I've read  https://docs.armbian.com/User-Guide_Getting-Started/#how-to-install-to-emmc-nand-sata-usb  and if I understand correctly my best option is 3 - "boot from SD - system on SATA or USB". The perfect option would be to also boot from SATA or USB.

 

So, do I have to partition the USB drive myself and the 'nand-sata-install' script imposes its partitioning ?

 

When I deal with desktop/laptop Linux distros, I partition the drive myself.

 

If 'nand-sata-install' script partitions the drive, will it be possible for me afterwards to change partitions adding, for example, swap partition ? I mean if I do not destroy data changing partitions will the whole boot mechanism find needed for booting data ?

Share this post


Link to post
Share on other sites

"maybe you're interested in giving the sound devices the right names," - @jock, IIRC, earlier in this thread you've proposed a workaround. I haven't implemented it yet. I've been studying pulse audio in general, made some simple adjustments on my desktop PC, etc.

 

My final goals include adding some LADSPA stuff of mine to pulse audio, so I have more things to learn. Or taking usage scenarios I might decide to dump pulse audio altogether using pure ALSA - which IIRC also allows to use LADSPA stuff.

Share this post


Link to post
Share on other sites
4 minutes ago, Sergei Steshenko said:

Another set of questions.

 

I want to use an external USB drive (to be exact, an HDD with USB adapter) to host the system. I've read  https://docs.armbian.com/User-Guide_Getting-Started/#how-to-install-to-emmc-nand-sata-usb  and if I understand correctly my best option is 3 - "boot from SD - system on SATA or USB". The perfect option would be to also boot from SATA or USB.

 

So, do I have to partition the USB drive myself and the 'nand-sata-install' script imposes its partitioning ?

 

When I deal with desktop/laptop Linux distros, I partition the drive myself.

 

If 'nand-sata-install' script partitions the drive, will it be possible for me afterwards to change partitions adding, for example, swap partition ? I mean if I do not destroy data changing partitions will the whole boot mechanism find needed for booting data ?

Mmmh, truly I don't know exactly. I guess the script does everything to setup the whole thing, but I never tried.

 

 

Share this post


Link to post
Share on other sites
3 minutes ago, Sergei Steshenko said:

"maybe you're interested in giving the sound devices the right names," - @jock, IIRC, earlier in this thread you've proposed a workaround. I haven't implemented it yet. I've been studying pulse audio in general, made some simple adjustments on my desktop PC, etc.

 

My final goals include adding some LADSPA stuff of mine to pulse audio, so I have more things to learn. Or taking usage scenarios I might decide to dump pulse audio altogether using pure ALSA - which IIRC also allows to use LADSPA stuff.

Yeah I remember the workaround (it was about editing pulseaudio conf files).

This other solution is not a workaround: it's about of making ALSA aware of HDMI and SPDIF devices. This information is then used by Pulseaudio to properly label the devices. It's much better and it is the proper way to do it. The previous workaround is not needed anymore.

 

BTW, ALSA and Pulseaudio do different things. ALSA is an abstraction layer over the hardware, but also has some "software" capabilities, like support for plugins, mixing, etc... Pulseaudio is an audio server which has the same software capabilities of ALSA, but also does something more.

It looks to me that ALSA is quite messy, it just does too many things without a clear separation of concepts. I studied it a bit to grasp the bits to understand how to solve the label problem, still I don't understand how it is possible the solution I found works <_<

Share this post


Link to post
Share on other sites

"It looks to me that ALSA is quite messy" - your characterization is quite mild. The probably most fundamentally wrong thing about ALSA is that its configuration files are not debuggable. I.e. there is no way to find what is wrong, even from the point of view of syntax. At least, this was the case years ago - I got confirmation of this statement from ALSA developers.

 

...

 

Regarding 'nand-sata-install.sh' - here is the source: https://github.com/pfoo/armbian-lib/blob/master/scripts/nand-sata-install/usr/lib/nand-sata-install/nand-sata-install.sh  . The destination drive is formatted by the script. I do not see the word 'swap' in the script. Some device names are explicitly checked and adjustments are made. Which means that some adjustments might be necessary for RK3288. I will try the script - I have a drive from somebody else's Windows machine, so I'll first let the script do with it whatever it wants. I am not a shell programmer, so it's not clear to me what happens after the script is run and then the destination drive is not connected. Will the source SD card be still bootable in the sense that the whole system can start from it ? Anyway, I haven't done much configuration on the SD card. I haven't even installed updates and the media script (the main goal of the whole thing is audio anyway).

Share this post


Link to post
Share on other sites
10 hours ago, Sergei Steshenko said:

Regarding 'nand-sata-install.sh' - here is the source: https://github.com/pfoo/armbian-lib/blob/master/scripts/nand-sata-install/usr/lib/nand-sata-install/nand-sata-install.sh  . The destination drive is formatted by the script. I do not see the word 'swap' in the script. Some device names are explicitly checked and adjustments are made. Which means that some adjustments might be necessary for RK3288. I will try the script - I have a drive from somebody else's Windows machine, so I'll first let the script do with it whatever it wants. I am not a shell programmer, so it's not clear to me what happens after the script is run and then the destination drive is not connected. Will the source SD card be still bootable in the sense that the whole system can start from it ? Anyway, I haven't done much configuration on the SD card. I haven't even installed updates and the media script (the main goal of the whole thing is audio anyway).

I'll take a look to the script. Never dig into, just tried a couple of times to check if it was working on our tv box.

By the way, there are more options for your setup:

  • use the nand-sata-install script to install armbian on the internal eMMC and then burn a pristine armbian image directly on the hard drive. This way u-boot gets installed in the embedded flash: it is programmed to first check for bootable SD card, then for bootable USB device and, if nothing can be found, tries to boot from embedded flash. (Remember to remove the bootable SD card from the tv box slot)
  • The get a swap partition, you can easily use a tool like gparted and edit the partitions table of the hard drive later. ext4 partitions can easily shrink with no data loss.

Share this post


Link to post
Share on other sites

I've made some progress. The good news is that booting having the system on external HDD works.

 

The needed for my scenario option was '1' in the 'nand-sata-install.sh' script actually present on the SD card. I decided to ago along my original intent of booting from SD card and system on HDD - didn't want to change the TV box internal state.

 

When 'nand-sata-install.sh' works, it sees existing partitions and asks to what partition to copy data. When it copies data, it completely overwrites the partition, i.e. it copies data as image - not file by file. Which, by the way, means that user home directory is copied too.

 

The script also created /etc/fstab, and even though the drive is HDD, the contents of  /etc/fstab are such as if it is tailored for a flash drive. So I later edited the file to make it look like more or less normal desktop Linux PC file.

 

Even after the system is moved to HDD, it still uses ZRAM and RAM logging - I found a couple of posts describing how to disable both.

 

The tricky part was enabling swap partition on the HDD. And the trickiest part was realization that there should be NO entry in /etc/fstab file for swap - unlike on my desktop Linux PC. I.e. UDEV rules automatically take care of swap partitions and if there is an entry on swap in /etc/fstab it is in conflict UDEV resulting in "Dependency failed for swap" message during boot.

 

I think Armbian documentation on 'nand-sata-install.sh' script should be amended to explain all these issues.

 

In my case the USB HDD is connected via a powered USB hub - otherwise there's not enough current to spin it up.

 

 

Share this post


Link to post
Share on other sites

Another issue is that apparently "Log Out" -> "Reboot" and 'sudo reboot' do not work, or, rather, do not work fully. Session is indeed terminated, the control button on the TV box lights first red and then blue - as it should, but new boot doesn't occur.

 

Sometimes I can achieve boot by cycling the button blue -> red -> blue several times, but the easiest and quickest way is to power the whole thing off and then on.

Share this post


Link to post
Share on other sites
23 hours ago, Sergei Steshenko said:

Another issue is that apparently "Log Out" -> "Reboot" and 'sudo reboot' do not work, or, rather, do not work fully. Session is indeed terminated, the control button on the TV box lights first red and then blue - as it should, but new boot doesn't occur.

 

Sometimes I can achieve boot by cycling the button blue -> red -> blue several times, but the easiest and quickest way is to power the whole thing off and then on.

Yeah, that's an issue I partially addressed and it is related to the peculiar PMU integrated circuit controlling the power of the SoC. Without a reference implementation, it is hard to get the job done.

Share this post


Link to post
Share on other sites

@Sergei Steshenko Apparently the purple line and audio issues with HDMI are gone in kernel 5.1! Here is an experimental image (Armbian 5.88 + Kernel 5.1.7) if you want to give it a chance.

Share this post


Link to post
Share on other sites

jock, very thanks for Ubuntu 18.04 with LTS 5.1.7 kernel!

Great work!

How are things going with video and audio playback?

Share this post


Link to post
Share on other sites
On 6/9/2019 at 2:38 PM, pro777 said:

jock, very thanks for Ubuntu 18.04 with LTS 5.1.7 kernel!

Great work!

How are things going with video and audio playback?

It looks like video acceleration is almost there in mainline. I think that in a matter of at most a couple of months rockchip will have some functioning hardware accelerated video decoding for at least h.264. Audio playback is fine at the moment, solving the purple line issue apparently solved the last audio issue I'm aware of. I suggested a patch that is going to be mainlined to armbian to finally have the proper labels to pulseaudio devices HDMI and SPDIF devices (it's just a matter of exchanging /etc/asound.conf with the one proposed in this issue, if you don't want to wait) and maybe it allows also some kind of AC3/DTS passthrough (not sure, have no chance to test it)

Share this post


Link to post
Share on other sites
1 hour ago, Jimmylamz said:

hi

(eMMC friendly) link died. anyone help please

I'll remove the eMMC friendly link. You can use a stable image form the Armbian download page (or, if you feel adventourous, the latest nightly development image above)

Share this post


Link to post
Share on other sites

@jock, thanks for the update.

 

At the moment I have my gig working, and the system is on HDD. Since I'm using optical SPDIF out, I'm not affected by the vertical magenta strip issue at the moment. So there is no real need for me to try a new setup at the moment - I'd rather spend time on "perfecting" my audio stuff. I mean that trying a new image would mean destroying already installed and configured stuff on HDD because of the way 'nand-sata-install.sh' script copies data.

 

...

 

Some more questions. I tried 'gcc -v' and it shows arm-cortex-a7 (or something like this - I'm writing from my desktop PC - not from the TV box), but RK3288 is of ARM-cortex-A17 kind. So, does it mean that the available 'gcc' is not fully optimized for A17, or it's a no issue ?

 

...

 

I have tried 'Suspend' from XFCE menu. Though the session is terminated, I don't have a clue how to resume. Does suspend work ? If yes, how does one resumes the session ?

Share this post


Link to post
Share on other sites
17 hours ago, Sergei Steshenko said:

@jock, thanks for the update.

 

At the moment I have my gig working, and the system is on HDD. Since I'm using optical SPDIF out, I'm not affected by the vertical magenta strip issue at the moment. So there is no real need for me to try a new setup at the moment - I'd rather spend time on "perfecting" my audio stuff. I mean that trying a new image would mean destroying already installed and configured stuff on HDD because of the way 'nand-sata-install.sh' script copies data.

 

...

 

Some more questions. I tried 'gcc -v' and it shows arm-cortex-a7 (or something like this - I'm writing from my desktop PC - not from the TV box), but RK3288 is of ARM-cortex-A17 kind. So, does it mean that the available 'gcc' is not fully optimized for A17, or it's a no issue ?

 

...

 

I have tried 'Suspend' from XFCE menu. Though the session is terminated, I don't have a clue how to resume. Does suspend work ? If yes, how does one resumes the session ?

Got it. I'm trying the box with an HDD attached to the OTG USB port. too

It works wonderfully and it is a perfect desktop replacement to me :)

Are you using the sdcard too? In my setup I have an image installed on the eMMC and, by default, it boots from the USB HDD when it is attached, so no need for the sdcard at all.

Share this post


Link to post
Share on other sites
7 hours ago, jock said:

Got it. I'm trying the box with an HDD attached to the OTG USB port. too

It works wonderfully and it is a perfect desktop replacement to me :)

Are you using the sdcard too? In my setup I have an image installed on the eMMC and, by default, it boots from the USB HDD when it is attached, so no need for the sdcard at all.

Yes, I do use the SDcard too. As I wrote above, I didn't want to risk changing the box internal state yet again, so I decided to keep the SDcard while having the system on HDD.

 

Is there a way to copy what I have on SDcard at the moment to a smaller SDcard ? It's a pity to have a 16GB SDcard just to host the /boot partition, i.e. a 4GB card, or even a smaller one, should suffice.

 

Back to the issue of newer kernels. Probably 2 decades ago I compiled a Linux kernel after making small changes in TV capture card (ironically, I stopped watching TV in 2006 or so). Since with HDD the TV box is a full fledged computer, there shouldn't be a problem to compile the kernel natively. Is there a way to have multi-boot WRT to kernels ? Like on regular x86 boxes GRUB(2).

 

Regarding the USB OTG port - in order to use it as yet another USB master port do I have to configure it somehow or just to plug the drive into it using the appropriate adapter cable ?

 

Could you please have a look into arm-cortex-a7 'gcc' vs arm-cortex-a17 real HW issue mentioned in my previous post ?

Share this post


Link to post
Share on other sites
1 hour ago, Sergei Steshenko said:

Yes, I do use the SDcard too. As I wrote above, I didn't want to risk changing the box internal state yet again, so I decided to keep the SDcard while having the system on HDD.

 

Is there a way to copy what I have on SDcard at the moment to a smaller SDcard ? It's a pity to have a 16GB SDcard just to host the /boot partition, i.e. a 4GB card, or even a smaller one, should suffice.

Technically speaking, the only important part (for you particular setup) of the sd-card is u-boot, which is located starting at sector 64 up to 2048: it is the first megabyte of the sdcard or so. In theory you can just copy the content of those sectors on another sdcard at the same place and it will just boot fine from the USB drive. Such a command would be enough (of course use the proper source and destination devices):

# dd if=/dev/mmcblk0 of=/dev/mmcblk1 bs=512 skip=64 seek=64 count=1984

You could do exactly the same using the eMMC device as destination and you would not need the sdcard at all

 

2 hours ago, Sergei Steshenko said:

Back to the issue of newer kernels. Probably 2 decades ago I compiled a Linux kernel after making small changes in TV capture card (ironically, I stopped watching TV in 2006 or so). Since with HDD the TV box is a full fledged computer, there shouldn't be a problem to compile the kernel natively. Is there a way to have multi-boot WRT to kernels ? Like on regular x86 boxes GRUB(2).

Yes, no problem compiling the kernel directly on the box. I did some time ago, of course the box compiled fine. About multiboot, nothing is stopping to put some kind of boot manager after u-boot. I don't know ant boot manager of sort suitable for ARM machines, but I guess there should be some out there, and indeed there are no technical issues preventing doing such piece of software. U-boot indeed should stay there because it does the initialization of some devices since these boxes lacks a real BIOS/embedded firmware.

2 hours ago, Sergei Steshenko said:

Regarding the USB OTG port - in order to use it as yet another USB master port do I have to configure it somehow or just to plug the drive into it using the appropriate adapter cable ?

Just plug the drive using the adapter and it should work. The OTG port is even faster than the non-OTG ports because it is directly connected to the SoC.

 

2 hours ago, Sergei Steshenko said:

 

Could you please have a look into arm-cortex-a7 'gcc' vs arm-cortex-a17 real HW issue mentioned in my previous post ?

Well I don't think it is a real issue... gcc -v shows you the compilation flags of gcc. Probably all the packages are compiled with the same architecture and tuning options, which is sub-optimal, but I don't think the gain in performance would be great using arm-cortex-a17... The microarchitecture is the same (ARMv7) so the instructions set is the same, you may think that the difference between arm-cortex-a7 and arm-cortex-a17 is around arranging the code in a different way to let the cache, branch predictors, pipelines and so on work a bit better. I don't think you should worry so much about, but if you have spare time you may try compile and do some benchmark to see if it worth it.

PS: to show the gcc default compilation flags: gcc -Q --help=target

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