8 8
TonyMac32

RK3328 Kernel

Recommended Posts

1 minute ago, ketominer said:

Thank you for your answer, will test the beta very quick and let you know how it goes. I will have to figure out how to safely push that to our users without breaking everything


When you confirm beta kernel is working well for you, I can update main repository and all they will need to do is: apt update && apt upgrade

Share this post


Link to post
Share on other sites

It's probably a matter of updating Armbian's kernel config to reflect ayufan's changes. I cannot test with Rock64 since I don't have one, just a Renegade.

Share this post


Link to post
Share on other sites
32 minutes ago, JMCC said:

It's probably a matter of updating Armbian's kernel config to reflect ayufan's changes. I cannot test with Rock64 since I don't have one, just a Renegade.

Probably, I've even got a kernel package from him that "should" work on armbian but I've broken everything trying to install it...

Share this post


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


When you confirm beta kernel is working well for you, I can update main repository and all they will need to do is: apt update && apt upgrade

no luck so far, I've updated previous post (maybe not a good thing to do)

Share this post


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

no luck so far, I've updated previous post (maybe not a good thing to do)


OK. Please provide a link to the working kernel and as much technical information as possible: logs (armbianmonitor -u) with a bad kernel and at least dmesg from a good one.

Share this post


Link to post
Share on other sites
3 hours ago, Igor said:


OK. Please provide a link to the working kernel and as much technical information as possible: logs (armbianmonitor -u) with a bad kernel and at least dmesg from a good one.

 

Info from "bad" kernel (freshly updated armbian bionic but it's the same for 6 months):
https://transfer.nodl.it/fJ3wP/armbianmonitor.bad.txt
(used my own transfer side because the one used by default by armbianmonitor -u doesn't show any url after upload)

 

Info from "good" distro (that works on the "bad" boards is):
http://ix.io/1HKS (somehow worked on this one)

 

Distribution used is
bionic-minimal-rock64-0.8.0rc9-1120-arm64.img.xz
from
https://github.com/ayufan-rock64/linux-build/releases

 

The kernel is
linux-headers-4.4.167-1169-rockchip-ayufan-g3cde5c624c9c:arm64  install
linux-image-4.4.167-1169-rockchip-ayufan-g3cde5c624c9c:arm64    install
u-boot-rockchip-rock64-2017.09-rockchip-ayufan-1045-g9922d32c04 install
and board package
board-package-rock64-0.8-126                    install

 

This leads to the correct dependencies:
https://github.com/ayufan-rock64/linux-build/releases/download/0.8.0rc9/linux-rock64-0.8.0rc9_arm64.deb

 

please note that the rc10 of ayufan's distro breaks again what rc9 was fixing...

 

Hope that helps :)
 

Share this post


Link to post
Share on other sites

Another idea for test - start from a stable repository or new image and use oldest kernel we have in repository -> armbian-config -> system -> alternative kernels.

Share this post


Link to post
Share on other sites
2 hours ago, Igor said:


A little. It seems quite a mess. Try kernel below if that makes any difference for you .... I am seeing this weird thingy in the syslogs:

May  1 18:38:25 localhost kernel: [ 1416.059127] zram: Decompression failed! err=-22, page=40
 

linux-image-rockchip64_5.83_arm64.deb

linux-dtb-rockchip64_5.83_arm64.deb

no luck. I'm starting to wonder if this is all not about something someone mentioned earlier, being that it's the u-boot settings slowing down the RAM that fix the problem...

 

https://transfer.nodl.it/4bgnD/armbianmonitor.txt

Share this post


Link to post
Share on other sites
On 5/1/2019 at 10:48 PM, ketominer said:

no luck. I'm starting to wonder if this is all not about something someone mentioned earlier, being that it's the u-boot settings slowing down the RAM that fix the problem...

 

https://transfer.nodl.it/4bgnD/armbianmonitor.txt

 

OK definitely not u-boot related as rc9 and rc10 has the exact same one. So the answer is somewhere in the kernel... digging deeper.

Share this post


Link to post
Share on other sites
(edited)
4 minutes ago, ketominer said:

 

OK definitely not u-boot related as rc9 and rc10 has the exact same one. So the answer is somewhere in the kernel... digging deeper.

 

and when browsing the differences between the kernels, I come up with this which looks pretty promising... https://github.com/ayufan-rock64/linux-kernel/commit/063c10147b3cfc326adda195f004b130dbd11ff6 -- scrap that, it's for the 3399 so not related :(

Edited by ketominer

Share this post


Link to post
Share on other sites
On 5/1/2019 at 10:52 AM, ketominer said:

These fixes are available for example in Ayufan's rc9 bionic distribution and all the boards that fail with armbian   work perfectly well with Ayufan kernel.

Let's go back to your original point, above. Can you reproduce the situation where everything works?

 

Share this post


Link to post
Share on other sites

OK after a long and painful investigation with pine64 and other people doing distributions for them + members of the community, the problem is that by default the memory runs "full" speed which is way above specs, as it should be running at 800 MHz max. We need the dmc driver and being able to setup the max clock for the memory to run these boards in good conditions.

Share this post


Link to post
Share on other sites

Actually even the stable armbian is way better, it now has dmc and the ram is clocked at 768*2! Just double checked with a few fresh installs + upgrade

Share this post


Link to post
Share on other sites

Hello,

 

I received a Rock64 board 2G two days ago and suffered the most impressive failure ever : panic, freeze, failed restart, segfault ...

I tried all I was able 2 think off : 3 different PSU, 3 SD card and an USB drive, 3 armbian version (and the last from yesterday) and an openelec image ...

Someone got an idea - an old kernel ? -  or should I consider the board defective and throw it away ?

 

The board was sold by "ameridroid" and is labeled :ROCK64_V2.0 2017-0713 (Quite old no ...)

Share this post


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

The board was sold by "ameridroid" and is labeled :ROCK64_V2.0 2017-0713 (Quite old no ...)

Not that old, although the V3 is out.  Which image did you use?

Share this post


Link to post
Share on other sites

Armbian_5.88_Rock64_Debian_stretch_default_4.4.180.7z

Armbian_5.75_Rock64_Debian_stretch_default_4.4.174.7z

LibreELEC-RK3328.arm-9.1.001-rock64.img.gz

Armbian_5.88_Rock64_Ubuntu_bionic_default_4.4.180.7z

Armbian_5.90_Rock64_Ubuntu_bionic_default_4.4.182.7z

 

The last one "seemed" a bit more stable but freezed and needed reset for rebooting and finally it crashed with mundane stack dump.

 

One symptom is that after a crash, or just a shutdown, the board enter an endless loop of panic at startup - needs reset? or cool down? or unplug/discharge? I even cannot find a safe method to restart the board !

Share this post


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

Armbian_5.88_Rock64_Debian_stretch_default_4.4.180.7z

Armbian_5.75_Rock64_Debian_stretch_default_4.4.174.7z

LibreELEC-RK3328.arm-9.1.001-rock64.img.gz

Armbian_5.88_Rock64_Ubuntu_bionic_default_4.4.180.7z

Armbian_5.90_Rock64_Ubuntu_bionic_default_4.4.182.7z

 

The last one "seemed" a bit more stable but freezed and needed reset for rebooting and finally it crashed with mundane stack dump.

 

One symptom is that after a crash, or just a shutdown, the board enter an endless loop of panic at startup - needs reset? or cool down? or unplug/discharge? I even cannot find a safe method to restart the board !

 

Try going with the 4.4.180, it's the one that gives me the best results (although not on 100% of the boards)

Share this post


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

 

Try going with the 4.4.180, it's the one that gives me the best results (although not on 100% of the boards)

 

The board is gone to the bin ...

 

I already try 4.4.180. Last, I tryed ayufan strech version from pine.org links : constant reboot ! Very frustrating ! From now on, never anyone of those buggy hardware anymore : raspberry or espressif. Thanks and bye at everybody !

Share this post


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

(although not on 100% of the boards)

@Igor  :-/

 

@arox speaking personally (not "for Armbian") the Rock64 is a troubled piece of hardware, there are 3 revisions in the wild, each one with differences not addressed by the vendor to work together.  Other options with more consistency and a bit more conservative release approach will yield better results.

Share this post


Link to post
Share on other sites

Hi all.

Need help.

Updated today from 4.4.180 -> 4.4.182

 

Now getting permanent problem with bypassing network interface to LXC container (worked flawlessly on 4.4.180).

 

sudo lxc-device -n tbng add wlx0092d00ddb46
command failed: Operation not supported (-95)
lxc-device: tbng: tools/lxc_device.c: main: 172 Failed to add wlx0092d00ddb46 to tbng

Same for trying to pass phy0 to network namespace

 

zno@armbox:~/_working_kernel$ sudo iw phy phy0 set netns 7094
command failed: Operation not supported (-95)

 

I will definately try with another non-realtek dongle, since I see only one difference - driver in dmesg has prefix RTW for debug messages. Previously it was 8188 or RT8188 (not sure).

 

Thanks in advance for your help. 

Share this post


Link to post
Share on other sites
4 hours ago, znoxx said:

I will definately try with another non-realtek dongle, since I see only one difference - driver in dmesg has prefix RTW for debug messages. Previously it was 8188 or RT8188 (not sure).


Driver for 8188 was changed with this commit. It should be better but I guess it could also be as step back :(

Share this post


Link to post
Share on other sites
3 hours ago, Igor said:


Driver for 8188 was changed with this commit. It should be better but I guess it could also be as step back :(

Igor, thanks for confirmation.

Looks like pure driver issue.

I put good old ralink 5370. Works like charm and my macos started to connect to AP, instead of password loop on Realtek 8188EU.

One small thing, not indeed rockchip related - diode on ralink usb wifi does not blink =).

 

Bad thing - my heap of unused Realtek 8188eu adapters just got bigger. :)

 

 

 

Share this post


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

Bad thing - my heap of unused Realtek 8188eu adapters just got bigger.

 

I try to keep wireless support as good as possible, but time to play with is always a problem. I am happy that most of my test devices work quite well and I will check if something can be done regarding 8188EU when time permits.

Perhaps its time to make an upgrade to AC capable 8812 or at least 8811 ? :) 

Share this post


Link to post
Share on other sites
3 hours ago, Igor said:

 

I try to keep wireless support as good as possible, but time to play with is always a problem. I am happy that most of my test devices work quite well and I will check if something can be done regarding 8188EU when time permits.

Perhaps its time to make an upgrade to AC capable 8812 or at least 8811 ? :) 

Well, my "demand" is quite exotic. Not so many people use wifi dongle inside LXC container. Not sure one should invest his own time into _such_ investigation.

Regarding the speed - container runs "TorBox" (http://tbng.ml), and TOR does not give you super-fast connection.  But well, indeed it's time for upgrade to something more 2019 related. 

 

Share this post


Link to post
Share on other sites

Sharing a bit of feedback:

 

I tried nightly buster minimal build with 5.3 kernel for Rock64 rev2.0 and it does not reach the state when it is accessible over the network. Both LEDs on the ethernet connector are off. I did not connected the HDMI display and moved on to other things.

 

Hope this helps.

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