Jump to content

RK3328 Kernel


Peba

Recommended Posts

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

Link to comment
Share on other sites

Armbian & Khadas are rewarding contributors

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

Link to comment
Share on other sites

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 :angry:

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

 

 

 

Link to comment
Share on other sites

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?

 

 

Link to comment
Share on other sites

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.  

Link to comment
Share on other sites

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

:lol: 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.

Link to comment
Share on other sites

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, 

Link to comment
Share on other sites

5 minutes ago, TonyMac32 said:

:lol: 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... 

 

Link to comment
Share on other sites

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? 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

 

 

Link to comment
Share on other sites

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.

 

 

Link to comment
Share on other sites

"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

Link to comment
Share on other sites

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

 

 

Link to comment
Share on other sites

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.  

Link to comment
Share on other sites

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.  

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines