RK3328 Kernel

[Igor]

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.

[dragonlost]

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?

[Igor]

5 minutes ago, dragonlost said:

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

https://github.com/armbian/config/blob/master/debian-config-functions#L597-L665

[JMCC]

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.

[Igor]

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  

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.

[TonyMac32]

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

[JMCC]

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 

[TonyMac32]

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

[chwe]

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.. We expect a fix in the next 2 days..

 

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?

VERSION = 4
PATCHLEVEL = 4
SUBLEVEL = 138

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

[JMCC]

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

[Kwiboo]

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.

[root]

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

[TonyMac32]

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.

[sfx2000]

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.

[AuerE]

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.

 

[JMCC]

Well, going back to the kernel: Do we want to use the frozen version I referenced above? If so, I'll start working on adding the remaining patches (though, as I said, I'll need a little help with that). @Igor @TonyMac32 what do you think?

[Igor]

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.

[Tido]

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*

 

[Igor]

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.

[Tido]

19 minutes ago, Igor said:

powered via GPIO

sadly yes, since my Micro-USB no longer works and I didn't dare to use the heat-gun by now to heat up that section :)

What does UMS stand for ?

It did reboot, but the cold start fails 

[Igor]

1 minute ago, Tido said:

What does UMS stand for ?

https://tinkerboarding.co.uk/wiki/index.php?title=Setup#What_is_UMS_mode

[Tido]

Thanks

What about the recent update to u-Boot  2018-05 ?

[Igor]

32 minutes ago, Tido said:

Thanks

What about the recent update to u-Boot  2018-05 ?

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

[TonyMac32]

Hmm, I haven't either.  I'll be looking at this here in a little bit.

[Tido]

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

-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

[TonyMac32]

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.

[Tido]

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.

 

[TonyMac32]

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.

 

[JMCC]

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.

[TonyMac32]

Fair. I need to do a build and take a look at where it lies.

Sent from my Pixel using Tapatalk