Jump to content

RK3328 Kernel


Peba

Recommended Posts

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.

Link to comment
Share on other sites

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
Link to comment
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?

 

Link to comment
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.

Link to comment
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 ...)

Link to comment
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 !

Link to comment
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)

Link to comment
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 !

Link to comment
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.

Link to comment
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. 

Link to comment
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 :(

Link to comment
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. :)

 

 

 

Link to comment
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 ? :) 

Link to comment
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. 

 

Link to comment
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.

Link to comment
Share on other sites

On 9/27/2019 at 1:55 PM, lomady said:

I tried nightly buster minimal build with 5.3 kernel for Rock64 rev2.0

 

Sigh...  My guess (entirely guessing, I have not looked yet), is that we or Mainline fixed the Rev 3, which broke the Rev 2.  I am not entirely pleased at the significant hardware changes made by Pine in this case, it is causing problems...

Link to comment
Share on other sites

Anyone has  a reliable kernel version for the rock64? Any I have tried are kernel panicking like crazy I cannot have it up longer than a few minutes.  The most stable kernel I have 4.4.133 but even that does intermittently during (heavy) IO on the USB3. Power is supplied through the power supply from pine.org so that should be good.

 

This is driving me crazy!

Link to comment
Share on other sites

17 hours ago, Tamás Faragó said:

This is driving me crazy!

Which revision ?

Mine, which is Rev 1.1, is now up since 60 days with kernel 5.2.0, although not running much applications.

I'm planning to upgrade to 5.4.0-rc1 soon ...

 

EDIT: The upgrade to 5.4.0-rc1 is now done ...

Link to comment
Share on other sites

19 hours ago, Tamás Faragó said:

Anyone has  a reliable kernel version for the rock64?

 

For which OS? I have a Rock64 V2 running 24/7 Ubuntu Bionic with kernel 4.4.192 (Armbian Bionic 5.98), which I have recompiled myself to add back a driver, and it seems pretty stable as of now. With the previous versions I used to have some sporadic zram0 errors, but it's now two days of uptime since my last reboot and I haven't seem them.

Link to comment
Share on other sites

Thanks guys. Any debian-based distribution would be fine, be it armbian, or ayufan version or even Ubuntu. 

I tried in the past to update to kernel 5 but it failed to recognize my usb3 hdd so I went back to version 4.

I'll have to check the version of the board when I get home but I remember it saying v2 on the back (I bought it in March 2018). 

Link to comment
Share on other sites

I've been using Arch Linux Arm with the generic linux-aarch64 kernel for a while now on my LibreComputer Renegade. Works nicely and I don't have to stay with an outdated vendor kernel. That said, I use it as a headless server. I don't know what limitations there would be when it comes to graphics performance.

Link to comment
Share on other sites

Thanks a lot, this helped immensely.

I installed the latest ubuntu-bionic 5.90 headless version which was 4.4.182 kernel. After a system update it went up to 4.4.192 and things seem quite stable. Although during heavy USB3 disk access - like resilio-sync scanning - there is the occasional kernel panic, but the machine is usable.

 

Oct 23 00:08:26 hattusa kernel: [  307.008233] zram: Decompression failed! err=-22, page=31
Oct 23 00:08:26 hattusa kernel: [  307.008290] zram: Decompression failed! err=-22, page=31
Oct 23 00:08:26 hattusa kernel: [  307.008463] zram: Decompression failed! err=-22, page=31
Oct 23 00:08:26 hattusa kernel: [  307.008483] Buffer I/O error on dev zram0, logical block 31, async page read
Oct 23 00:08:51 hattusa kernel: [  332.477720] zram: Decompression failed! err=-22, page=31
Oct 23 00:08:51 hattusa kernel: [  332.477738] Buffer I/O error on dev zram0, logical block 31, async page read
Oct 23 00:09:00 hattusa kernel: [  340.704780] zram: Decompression failed! err=-22, page=31
Oct 23 00:09:00 hattusa kernel: [  340.704799] Buffer I/O error on dev zram0, logical block 31, async page read

 

Link to comment
Share on other sites

Not much luck even with armbian. With any process that involves heavy IO (on the USB) the board just panics and dies. And by heavy IO I mean something like syncthing or resilio sync indexing my shared albums.

 

I get this during boots

ERROR:   suspend_mode_handler: unhandled sip (0x1)
ERROR:   suspend_mode_handler: unhandled sip (0x4)

Is there anyway I can debug this, or at least find out what the cause is?

When the sbc dies:

Spoiler

 

 

and again

Spoiler

 

 

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