RK3328 Kernel

[TonyMac32]

This only affects seeing the u-boot output before the kernel takes over, it's of very little impact. On kernel 4.4 there is a question as to whether it will work properly, but it needs investigated while we fix the kernel

Sent from my Pixel using Tapatalk

[TonyMac32]

Igor and I've put in a bit of time on the 4.19 LTS kernel in Dev, nightlies are being built: https://dl.armbian.com/tinkerboard/nightly/

 

I've been running one all day, so far works like a charm.  Wifi/BT/HDMI/USB hotplug/onboard audio all seem to work, if we can get some testing by others to verify it would be greatly appreciated, the goal will be to roll this out to Next once any bugs are squashed

[jock]

Is audio via HDMI working? I'm having issues on my non-tinkerboard rk3288 box, kernel 4.19.6, and I can't figure it out.

Also bluetooth is not working (it was on 4.18, broadcom chip attached to /dev/ttyS0).

Apparently the DMA Controller (dmac_bus_s) is somehow complaining

[maurizio_69]

On 12/3/2018 at 4:32 AM, TonyMac32 said:

Igor and I've put in a bit of time on the 4.19 LTS kernel in Dev, nightlies are being built: https://dl.armbian.com/tinkerboard/nightly/

 

I've been running one all day, so far works like a charm.  Wifi/BT/HDMI/USB hotplug/onboard audio all seem to work, if we can get some testing by others to verify it would be greatly appreciated, the goal will be to roll this out to Next once any bugs are squashed

 

Great work! No more HDMI boot issue (on certain monitors, in my case Dell SP2309W) on my Tinkerboard S.

Thank you Tony and Igor.

[qume]

Hi All, first thanks for the great work getting Armbian up and running on the Tinkerboard. It's been rock solid for me.

 

In the TinkerOS repo, they have created an overlay for PPS (1 pulse per second from GPS devices for keeping time):

 

https://github.com/TinkerBoard/debian_kernel/blob/develop/arch/arm/boot/dts/overlays/pps-gpio-overlay.dts

 

I spent the day building Armbian using the vagrant build system, which is working well, but I haven't managed to figure out how to get this overlay integrated.

 

I also created a patch with the core change to rk3288.dtsi in the userpatches/kernel directory but it always fails to apply with not enough explanation for me to figure out why, so no luck there.

 

Apologies if this isn't the right place to be asking this as although I'm trying to do this for the Tinkerboard it probably is a general armbian question.

 

 

[dragonlost]

On 12/3/2018 at 4:32 AM, TonyMac32 said:

Igor and I've put in a bit of time on the 4.19 LTS kernel in Dev, nightlies are being built: https://dl.armbian.com/tinkerboard/nightly/

 

I've been running one all day, so far works like a charm.  Wifi/BT/HDMI/USB hotplug/onboard audio all seem to work, if we can get some testing by others to verify it would be greatly appreciated, the goal will be to roll this out to Next once any bugs are squashed

 

is it possible to add the nightly ubuntu  version ? thanks

[qume]

For anyone who lands here from a web search trying to get kernel PPS working with the Tinkerboard on armbian.

 

I failed going the overlay route, and also failed to add a new patch to the /userpatches/kernel/rockchip-next/ directory. In both cases I don't have enough experience here to figure out why.

 

But, I did manage to get the device tree item into rt3288.dtsi file by copying one of the files which modify it from /patches/kernel/rockchip-next into the /userpatches/kernel/rockchip-next directory and modifying it. When copying it over, the build system uses any file with the same name from /userpatches instead of /patches.

 

When I say modifying it, I literally added these lines:

 

pps: pps {

compatible = "pps-gpio";

pinctrl-names = "default";

pinctrl-0 = <&pps_pins>;

gpios = <&gpio5 19 0>;

status = "okay";

};

 

in to one of the patches directly. So you'll need to add +'s to the start of each line then change the number of lines added in the patch chunk header.

 

This is an abomination of course but it worked (along with building the kernel with PPS and PPS GPIO turned on).  Perhaps someone with more experience here might chime in on the proper way of doing this. Every time I created a patch it failed without any reason I could track down.

 

 

 

[gkkpch]

Just a general question, Asus added support to TinkerOS for a number of known DACs from the RPi "audiophile" scene.

(Take "audiophile" with care, not all DACs meet that standard and it is not really clear what that standard would be)

Armbian does not seem to support any of the those, is there a specific reason for not adding that level of device tree overlay support?

 

 

[TonyMac32]

2 minutes ago, gkkpch said:

Armbian does not seem to support any of the those, is there a specific reason for not adding that level of device tree overlay support?

 

To be honest it's because I never learned how to do device tree overlays.  Now that I'm seeing what must be done for mainline thanks to @martinayotte awesomely doing Meson64 and some rockchip64, I can take a stab at Tinker.  

[TonyMac32]

5 minutes ago, gkkpch said:

Take "audiophile" with care, not all DACs meet that standard and it is not really clear what that standard would be

I can think of many objective definitions that could be used, but people who like to sell especially expensive things maintain their claims that a perfectly measured reproduction of frequency, phase, and amplitude can't be trusted...  All while the critics are not understanding what "output impedance" is.

[gkkpch]

For volumio I added our own ES90x8q2m device (which helps the sale of our own Volumio hardware, see volumio.org)

But there are other DACs TinkerOS can support too, I just added an Allo Piano, working on Allo Boss and Allo Digione.

Not integrated in Asus yet, bus upcoming.

 

These are all excellent DACs, 

[gkkpch]

5 minutes ago, TonyMac32 said:

I can think of many objective definitions that could be used, but people who like to sell especially expensive things maintain their claims that a perfectly measured reproduction of frequency, phase, and amplitude can't be trusted...  All while the critics are not understanding what "output impedance" is.

Yep, agree.

And the reason why I  (core Volumio member) take great care not to title just any supported product as "audiophile".

But, there are certain DAC's (and you don't need a pair of specialised ears)  that make a hell of a difference.

I'm an OS developer, not an audiophile, but from all I have come across and tested over the last few years, there is sooo much difference.

And this is why people prefer some products over another.

I happen to  like the Allo products and spent some time getting them integrated, but there are lots of others... 

 

[gkkpch]

28 minutes ago, TonyMac32 said:

To be honest it's because I never learned how to do device tree overlays.  Now that I'm seeing what must be done for mainline thanks to @martinayotte awesomely doing Meson64 and some rockchip64, I can take a stab at Tinker.  

well, Asus did some things to u-boot that enabled them to load an overlay dtb at boot time, very similar to PRi (RPI uses config.txt, Asus uses hw_intf.conf)

Not sure how Armbian manages this.  Using Ayufan's script to load an overlay in runtime? 

[gkkpch]

3 minutes ago, gkkpch said:

well, Asus did some things to u-boot that enabled them to load an overlay dtb at boot time, very similar to PRi (RPI uses config.txt, Asus uses hw_intf.conf)

Not sure how Armbian manages this.  Using Ayufan's script to load an overlay in runtime? 

the hw_intf.conf implementation in u-boot is very much hardcoded with the allowed parameters, be aware of that, but shows a possible way of doing it is a more flexible way.

[TonyMac32]

We support both u-boot overlay and runtime.  U-boot uses the text file like you're thinking.

 

Interestingly the only board I use for Volumio at the moment is my Pi2, some years ago I bought the hifiberry dac+ pro and the nice little case.

 

I also have some "how cheap can you get" nanopi Neo's as remote speakers, they're fun because they're tiny.

[TonyMac32]

14 minutes ago, gkkpch said:

the hw_intf.conf implementation in u-boot is very much hardcoded with the allowed parameters, be aware of that, but shows a possible way of doing it is a more flexible way.

 

Yes, we use the boot script for that purpose, the Asus code is written without worrying too much about other hardware or general extensibility.

 

My thought would be to work this out in mainline, and not fool with Rockchips increasingly crusty kernel.  Unless you think you need video decoding acceleration, everything else works.

[gkkpch]

and last but not least, if you were doing anything with I2S devices, keep clear at the moment.

We have a serious issue with the  Asus/ Rockchip i2s driver (or related components) outputting streams not at the sample rate frequency they are supposed to have.

It is not a huge deviatian, but some people could hear it and reported it.

Tests with kernel version 4.4.71 shows the problem is not there, we now have version 4.4.132+ with the problem being there.

Measurement by externals showed, the problem also includes Armbian.

 

 

 

[gkkpch]

Asus is aware of it and we are working together to get this solved

[gkkpch]

8 minutes ago, gkkpch said:

Asus is aware of it and we are working together to get this solved

this what helped to check the frequency

Frequency counter

[TonyMac32]

Do you know if this includes mainline?  I'm going to be completely honest with you, if it weren't for vdec I'd throw away the 4.4 kernel immediately.

[gkkpch]

We only use the Asus kernel because of DAC support. There were many commits between 4.4.71 and 4.4.132 and I have no idea if any of that went upstream.

Though with Rockchip we have reasonable new kernels (not like the <3.18 many others have), they don't appear reliable all the time. It's not the first thing that went kaputt unnoticed.

 

 

[TonyMac32]

"kaputt".

This is something said only in some places here, and only because the settlements in my region were primarily German long ago and the people did not move around much in the low mountains.

I am working on overlays now, I have good examples from@Martinayotte to work from, I have one last u-boot adjustment to make and I think it is at least ready for testing. I will add it to the 4.19 kernel first since that is dev and is building nightlies.

Sent from my Pixel using Tapatalk

[gkkpch]

living in CH for nearly 40 years obviously rubbed off on me

 

[gkkpch]

Jamess (Asus) located the sample rate issue, seemingly due to an RK commit for a "fix" in the rockchip clock driver. They will now check with RK why that was done.

Good thing: it did not make it into upstream, so with 4.19.y we should be fine for the (time being).

 

 

[TonyMac32]

Rockchip-dev kernel updated, now implements overlays for uarts 1-4, spi0, spi2, spidev0, spidev2.  The default config for Tinker out of box is to have spi2/spidev2, and uarts 1 and 2 enabled.  This puts the basic RPi configuration in place with the debug UART.  

 

Uart2, spi0/2 and spidev0/2 tested.  

[nerdbaggy]

How do I get the rPi Touchscreen to work? I installed desktop mainline kernel 4.14.y and then I switched kernels in armbian-config to get on the latest

[TonyMac32]

22 minutes ago, nerdbaggy said:

How do I get the rPi Touchscreen to work? ... mainline kernel 4.14.y 

There is no support for it in mainline as yet.  I am planning on working on it (no guarantees) after the new year for possible integration with 4.19.  

[kngdmond]

I'm having an issue with an 7" LCD touch screen and hoping someone might be able to give me some insight of where to look for a solution.  I've posted once before but at that time the LCD would not display at all but I've managed to get it to show up with mixed results. 

If I plug the HDMI into a tv, the display works fine.  Plugging into an LCD 7" made for an rPi the screen would be blue with no display.  I edited /boot/armbianEnx.txt and added:
extraargs=drm_kms_helper.edid_firmware=HDMI-A-1:edid/800x480.bin video=HDMI-A-1:800x480@60.  I know the is oddball, but that's the actual size of the display and by adding this line I was able to boot into Armbian with a working display on the 7" screen.  I did try setting the line to 640x480, 1280x720, and 1920x1080.  I'd get no display with those settings.  The only one that would show a display booting was 800x480.  I did go to github and added LCDshow config lines for the LCD7B to armbianEnv.txt.  After adding LCDshow config lines and rebooting, 640x480 still had no display, but 720p, and 1080p booted to a black screen.

What I can't figure out is, if I boot using 800x480 with the 7" LCD I get a display but it breaks anything using SDl.  I get an error saying lvl0: Error initializong SDL! No currently active connector found.
But if I plug in a tv, boot, anything using SDL works.  If I hot swap the HDMI from the tv to the 7" LCD, the display works including SDL.  But the moment you change menu items or anything that requires an interaction with SDL, the screen will go black.  If I hot swap the HDMI back to the tv, I see the SDL error No currently active connector found.  I tested hot swapping from the TV to the 7" with 720p and 1080p and was able to get a display with SDL but with the same results once I change a menu or did something that required interaction with SDL the screen would go black.  Although the screen would not go black using the 800x480, the display would remain on and just present the SDL error.

So my question is why does the LCD display work by hot swapping. I've searched Google to try to find a solution, a file to modify, etc and I come up empty handed.  Any ideas??

Thank you.

[TonyMac32]

On 12/30/2018 at 2:14 PM, kngdmond said:

So my question is why does the LCD display work by hot swapping. I've searched Google to try to find a solution, a file to modify, etc and I come up empty handed.  Any ideas??

I'm afraid not.   :-/  I have an 800x400 hdmi, it's behavior is a bit different from a typical HDMI display, but as to why, I'm afraid I'm in the dark.

[TonyMac32]

Tinkerboard "Next" Stretch and Bionic images available for download using kernel 4.19.

 

Notable changes include the use of device tree overlays.