Jump to content

RK3328 Kernel


Peba

Recommended Posts

38 minutes ago, dragonlost said:

This error only happens on the tinkerboard because on an x86_64 system I do not expect this error on this package from an xubuntu or lubuntu


Well, this is something we need to fix once. Better use our desktop (armbian-config -> system -> install desktop) which is more optimised than generic MATE.

Link to comment
Share on other sites

10 minutes ago, Igor said:


Well, this is something we need to fix once. Better use our desktop (armbian-config -> system -> install desktop) which is more optimised than generic MATE. 

This feature is available on the command line?

What is the simplest technique in shell to be sure to be on armbian?

Link to comment
Share on other sites

On ‎10‎/‎24‎/‎2018 at 2:30 PM, Igor said:

use mainline kernel (4.14+), first two download options, which will soon be the only options for the download. Supporting legacy BSP kernel is getting nowhere

What about the possibility that @TonyMac32 suggested, freezing the 4.4 BSP and only applying security patches? Right now, VPU accel is only available with legacy BSP kernel (and it can be a while before it is ported to mainline), and, judging by the people using the media script, there is a significant userbase that uses the TinkerBoard for media playing.

Link to comment
Share on other sites

46 minutes ago, JMCC said:

freezing the 4.4 BSP and only applying security patches?

 

We tried to freeze it once but failed :) I hope next time there will be more luck. I just hate this Rockchip BSP mess :huh: 

P.S. I remake most of the images yesterday because desktop upgrade was broken. I can't do it for Rockchip without losing some of the functions ... At least not the way we build things now. We plan to enable images rebuilding from kernel which are already stored in repository but there is some build script RFC needed. ASAP.

Link to comment
Share on other sites

True, we tried, but somehow it was a weird botch job. I think if we start off of an Ayufan tag we can succeed, unfortunately my slow summer of coding resulted in my not pushing this one as hard as I should have. The Rockchip guys are also completely uninterested in merging any fixes from outside sources from what I can tell.

Sent from my Pixel using Tapatalk

Link to comment
Share on other sites

I have noticed that all SBC manufacturers just clone the repo at certain point, and then fork it from there, without merging successive upstream changes. It looks to me that's how Rockchip expects their kernel source to be used: They make it work for a certain SoC/board, and after the manufacturers fork it, they forget about that SoC/board and start working in making the necessary changes for the next one, regardless of whether it breaks the previous ones.

 

I'll try to make an experiment of making a fork, though usually all my attempts to do kernel development end up with little success :)

Link to comment
Share on other sites

The Ayufan kernel is simply a fork of Rockchip with fixes applied. One of those release tags should be really close to what we need. There is also a fork maintained by one of the multimedia distributions that has a ton of fixes in it, I'll have to remember whose it is.

Sent from my Pixel using Tapatalk

Link to comment
Share on other sites

1 hour ago, TonyMac32 said:

unfortunately my slow summer of coding resulted in my not pushing this one as hard as I should have

absolutely.. It's your fault that current rk kernel is broken.. :D:ph34r: We expect a fix in the next 2 days.. :lol:

 

Maybe we should reconsider the all rk under one kernel idea. Don't get me wrong, I still like the idea. But not sure if it's workable for all RKs we support, or start to support.

 

I've forked ayufans kernel in August (tried to set up weekly tags, unfortunately my bash script wasn't that mature and it crashed quite soon). But it might be a good starting point now? :P

VERSION = 4
PATCHLEVEL = 4
SUBLEVEL = 138

a 'few things' were broken back then but it might be possible to cherry pick the needed bits.. :P

Link to comment
Share on other sites

Okay, so I created a working fork of RK BSP kernel. It reproduces the status at the end of August, when we created the Default images that are currently available for download. I also modified the buildscript patchset to resemble what it was back then.

 

I have tested Wifi, network, Bluetooth, GPU, VPU, all working.

 

There are two things missing:

  • Security patches after 4.4.132
  • All the features added after August 28 2018 (like some crypto modules, etc.)

I'd appreciate if you guys could lend me a hand with those two things, it can be very easy for you because you already added those patches to 'master' before, but I'm a bit lost about where to start.

 

This is our forked RK kernel: https://github.com/armbian/linux/tree/rockchip-4.4

And this is the working branch of the build script: https://github.com/armbian/build/tree/rockchip-4.4

Link to comment
Share on other sites

For LibreELEC we use latest RK BSP kernel on TinkerBoard, MiQi, RK3328 and RK3399 and it has been pretty "stable" last few months.

 

I do not have a single branch with all changes and instead generate patches based on RK BSP release-4.4 branch.

Each branch mainly contain patches picked from mainline to improve multimedia.

 

Linux tree: https://github.com/Kwiboo/linux-rockchip

Patches: https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Rockchip/patches/linux/rockchip-4.4

 

We are currently using a release-4.4 tag as base that includes the removed rk1808/rk3399pro commits from BSP tree.

 

I usually just merge latest LSK 4.4 android to include the latest 4.4 patches, but anything newer then current RK BSP seems to cause issues for BT/WiFi on my TinkerBoard.

Link to comment
Share on other sites

Slightly unrelated: what's the highest WiFi speed you achieved with the TinkerBoard?

Mine doesn't seem to be able / willing to go beyond ~45 Mbps (access point is 2 meters away, no line-of-sight though - but no massive obstacles either).

Link to comment
Share on other sites

Unsure, I never anticipate having "good" performance on any board with a "chiptenna".  The drivers are also the predictable mess you get from a vendor unwilling to really support open source meaningfully, blobs and really crappy source code cause constant headaches.

Link to comment
Share on other sites

6 hours ago, TonyMac32 said:

Unsure, I never anticipate having "good" performance on any board with a "chiptenna".  The drivers are also the predictable mess you get from a vendor unwilling to really support open source meaningfully, blobs and really crappy source code cause constant headaches.

 

Chip antennas aren't all that bad - most are at best unity gain - or 0 dB - e.g. power in is power out...

 

And that isn't a bad place to be, as the pattern at the antenna isn't very particular about orientation.

 

The major challenge is the RF front-end efficiency - and some are better than others - it's how the WiFi chip or System on Package is implemented on the board. 

 

@root - your observed numbers are consistent with expected results on the Tinker - it's not a great chip on the WiFi module side, but the realtek drivers are known and somewhat stable.

Link to comment
Share on other sites

My personal experience both with Armbian and Tinker OS is that the wireless internet of the Tinker Board S is quite mediocre in particular in stability. There were some tweaks to improve things, but it still is not impressive, while the Gigabit LAN of the Tinker Board works really well. I could imagine that there are issues with both antenna and power supply noise, but I have not investigated the wireless that much. So I guess I join sfx2000 who says your 45 Mbps are what is to be expected for that chip.

 

Link to comment
Share on other sites

17 minutes ago, JMCC said:

Well, going back to the kernel: Do we want to use the frozen version I referenced above?


Currently it's okeish but let Tony decide what to do. Just make sure to include this fix: https://github.com/armbian/build/commit/2ceaa6e8bd89abf576b65a0a60b8356b8b5f74df ... and small kernel config changes.

Link to comment
Share on other sites

I am running the 4.14 release (1. March '18) in Beta mode. It is my "learning to program" Desktop so I am very carefully with updates and I do that approx. every 2 months. Before I start the update, I do a backup as a good citizen.

However, I have done that now twice last Saturday 3. November - I did reboot after the update, but a cold start didn't work.

So this morning, same procedure - restore backup - run update. Do a reboot, fine. Do a cold start - only the red LED.

 

It sits in a housing so I haven't attached UART by now. Did I get the new u-boot that kills it ?

 

I will add here the file structure :

Spoiler

 


-rw-rw-r-- 1 root root  155 Nov 10 08:33 armbianEnv.txt
-rw-rw-r-- 1 root root 1.6K Jan 27  2018 armbian_first_run.txt.template
-rw-rw-r-- 1 root root  38K Jan 27  2018 boot.bmp
-rw-rw-r-- 1 root root 1.4K Jan 27  2018 boot.cmd
-rw-rw-r-- 1 root root 4.8K Jan 27  2018 boot-desktop.png
-rw-rw-r-- 1 root root 1.5K Jan 27  2018 boot.scr
-rw-r--r-- 1 root root 141K Nov  9 08:18 config-4.14.79-rockchip
lrwxrwxrwx 1 root root   20 Nov 10 08:32 dtb -> dtb-4.14.79-rockchip/
drwxr-xr-x 2 root root 4.0K Aug  2 21:53 dtb-4.14.50-rockchip/
drwxr-xr-x 2 root root 4.0K Nov 10 08:31 dtb-4.14.79-rockchip/
lrwxrwxrwx 1 root root   20 Aug  2 21:56 dtb.old -> dtb-4.14.59-rockchip
-rw-r--r-- 1 root root 4.4M Nov 10 08:32 initrd.img-4.14.79-rockchip
-rw-r--r-- 1 root root    0 Nov 10 08:32 .next
-rw-r--r-- 1 root root 3.5M Nov  9 08:18 System.map-4.14.79-rockchip
lrwxrwxrwx 1 root root   24 Nov 10 08:33 uInitrd -> uInitrd-4.14.79-rockchip
-rw-r--r-- 1 root root 4.4M Nov 10 08:33 uInitrd-4.14.79-rockchip
-rwxr-xr-x 1 root root 8.2M Nov  9 08:18 vmlinuz-4.14.79-rockchip*
lrwxrwxrwx 1 root root   24 Nov 10 08:32 zImage -> vmlinuz-4.14.79-rockchip*

 

Link to comment
Share on other sites

2 hours ago, Tido said:

I did reboot after the update, but a cold start didn't work.

 

You have a normal Tinkerboard and powered via GPIO? What is relatively new is UMS support, but that should not act this way. Hmm. Will try to reproduce when possible.

Link to comment
Share on other sites

I will restore the backup, do kernel freeze, I guess I have to leave it on Beta (nightly) otherwise too much might change    and run the update & upgrade again. Because a restore to a state after 20180802 (August,  after that backup, I ran the update).

Now I am in restored system,  it says: Armbian 5.54 180730 nightly - my last known working configuration with kernel upgrades.   Looks like it was more than 2 months.. time flies :rolleyes:

-rwxrwx--- 1  plugdev 3.1G Mai 20 13:03  Armbian_programmier_umgebung-20180520_125932.img*
-rwxrwx--- 1  plugdev 3.1G Jun 18 09:24  Armbian_programmier_umgebung-20180618_092043.img*
-rwxrwx--- 1  plugdev 3.1G Aug  2 21:17  Armbian_programmier_umgebung-20180802_211254.img*
-rwxrwx--- 1  plugdev 3.1G Okt 28 21:49  Armbian_programmier_umgebung-20181028_214523.img*

 

 

Update after the software upgrade.. but not the kernel:

Armbian 5.54 180730 nightly obviously. Reboot works, Cold start works.  Well, I was on nightly so the problem stays with me.

I have already started to rebuild my "learning to program" Desktop on the 4.4.152, my display resolution 1280x1024 has arrived there as well :)

Link to comment
Share on other sites

10 hours ago, Igor said:

Than this UMS was added. We need to look into this closely. I haven't noticed this problem yet.

 

There are 2 video related updates in the last 5 months in u-boot, one was a patch from ASUS doubtless for Rockchip's fork of U-boot, which does mess with the ddc channel:

https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-rockchip/board_tinkerboard/0017-Fix-HDMI-some-issues.patch

 

Specifically:

@@ -340,7 +340,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, u32 mpixelclock)

 	hdmi_phy_i2c_write(hdmi, hdmi->mpll_cfg[i].cpce, PHY_OPMODE_PLLCFG);
 	hdmi_phy_i2c_write(hdmi, hdmi->mpll_cfg[i].gmp, PHY_PLLGMPCTRL);
-	hdmi_phy_i2c_write(hdmi, hdmi->mpll_cfg[i].curr, PHY_PLLCURRCTRL);
+	hdmi_phy_i2c_write(hdmi, 0x0000, PHY_PLLCURRCTRL);

 	hdmi_phy_i2c_write(hdmi, 0x0000, PHY_PLLPHBYCTRL);
 	hdmi_phy_i2c_write(hdmi, 0x0006, PHY_PLLCLKBISTPHASE);
@@ -560,8 +560,8 @@ static int hdmi_read_edid(struct dw_hdmi *hdmi, int block, u8 *buff)
 	u32 n;

 	/* set ddc i2c clk which devided from ddc_clk to 100khz */
-	hdmi_write(hdmi, hdmi->i2c_clk_high, HDMI_I2CM_SS_SCL_HCNT_0_ADDR);
-	hdmi_write(hdmi, hdmi->i2c_clk_low, HDMI_I2CM_SS_SCL_LCNT_0_ADDR);
+	//hdmi_write(hdmi, hdmi->i2c_clk_high, HDMI_I2CM_SS_SCL_HCNT_0_ADDR);
+	//hdmi_write(hdmi, hdmi->i2c_clk_low, HDMI_I2CM_SS_SCL_LCNT_0_ADDR);
 	hdmi_mod(hdmi, HDMI_I2CM_DIV, HDMI_I2CM_DIV_FAST_STD_MODE,
 		 HDMI_I2CM_DIV_STD_MODE);

 

And another to simply enable the u-boot bring-up of the video hardware, because the kernel no longer seems to want to take responsibility for that task:

https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-rockchip/board_tinkerboard/101-u-boot-0002-rockchip-tinker-enable-rockchip-video-driver.patch

 

I need to verify I can get the fault, then try to squash.

Link to comment
Share on other sites

I played with @JMCC

 , media script and tinker board would completly shut off! by just clicking around in Chromium's Bookmarks or by opening the Extension menu = Mission Impossible.

Now I found out, the Standard 4.4 release without JMCC's script comes already with that.

 

My 4.14 nightly hadn't have any issue like that.

That said, I would greatly appreciate it if you can spend couple minutes looking into it.

 

Link to comment
Share on other sites

I did a small test on the 4.4 image, it would actually shut down randomly without provocation, so there is something there to work out.  :-/.

 

As for these HDMI issues so far no luck reproducing it, I got a false positive by accidentally using the cable for my Arduino programming (activated UMS).  I'll pull the non-standard resolution one off of my other project and see if that works.

 

Link to comment
Share on other sites

Those problems are not present in the released image, nor if you build with the kernel I froze. I think switching to that kernel would have two important advantages:

  1. Less headache. Everything in the board would work unless we break it.
  2. A solid base to experiment and introduce new features (e.g. the LibreELEC multimedia patches referenced by @Kwiboo, camera ISP driver, new kernel configs, etc.). Right now, if you try something new and the board fails, you are in doubt whether it was because of the change you made or because it broke upstream.
Link to comment
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...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines