8 8
TonyMac32

RK3328 Kernel

Recommended Posts

Thread to keep track of the RK3328. 

 

Boards supported with this kernel:

  • Pine64 Rock64 (multiple hardware revs, will need board identification in case of problems)
    • Rev1 and Rev2
    • Rev3
  • Libre Computer Renegade/Firefly ROC-RK3328-CC (same board)

 

Current events:

 

  • Rock64 Rev 3 appears to need some u-boot tweaks.
  • time to re-assess mainline support
    • Boards have USB3, ethernet, HDMI all working.
    • needed:  Renegade at least capped to 1.3 GHz somehow
    • No 4K
    • Renegade sound not set up yet, should be easy enough

 

Share this post


Link to post
Share on other sites

Thanks for your hard work.

 

Just started using Armbian on my Rock64 rev 2.  Pleased with performance and resource usage.   I did notice that it updated from 5.73 to 5.75 during an upgrade but when I login, it still shows 5.73....

I read that Rock64 rev 3 with POE will be released in the coming months.

Share this post


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

I read that Rock64 rev 3 with POE will be released in the coming months.

Yes, I saw that too.  We'll have to start keeping a matrix, I have an engineering sample of rev 1, so I should probably look for a newer one to make sure testing is representative.

Share this post


Link to post
Share on other sites

I'd like to think that pine64 would send you the current and popular selling rev 2 which I've had for 9 months as well as rev 3 when it comes out as you as well as every other dev on Armbian is helping make the rock64 more reliable and useful :)

Share this post


Link to post
Share on other sites
15 minutes ago, Thewonderer said:

I'd like to think that pine64 would send you the current and popular selling rev 2

 

If you saw the number of boards I have you'd either be excited or dismayed.  The rev 1 to rev 2 changes weren't so big, so I didn't bother trying to get another.  :-)  Their team is very supportive of the community of developers.  As for me, I've had a minor role, many others here have done as much or more, the distro around the board support is where all the really important stuff happens.  Thank you for the praise regardless!

Share this post


Link to post
Share on other sites

@suberimakuri:

 

 ____                                 _
|  _ \ ___ _ __   ___  __ _  __ _  __| | ___
| |_) / _ \ '_ \ / _ \/ _` |/ _` |/ _` |/ _ \
|  _ <  __/ | | |  __/ (_| | (_| | (_| |  __/
|_| \_\___|_| |_|\___|\__, |\__,_|\__,_|\___|
                      |___/

Welcome to ARMBIAN 5.76 user-built Ubuntu 18.04.2 LTS 4.20.13-rockchip64
System load:   0.02 0.17 0.11   Up time:       8 min
Memory usage:  14 % of 1998MB   IP:            10.0.0.47
CPU temp:      48°C
Usage of /:    12% of 15G

[ General system configuration (beta): armbian-config ]

So that works, although missing a USB port (bottom USB2 is not with us).

Share this post


Link to post
Share on other sites

@jpegxguy  For the mainline ethernet tx/rx delays, were those just copied from the Rock64 or were they empirically determined?  They're caused by trace impedance/etc, so they're tied to the specific hardware.  I'll dig up the thread/tool Ayufan and Tkaiser were using and see what I get, there might be some more to gain there, since obviously the default ones are fairly bad.

 

@Igor Any argument against moving Ayufan's RK3328 mainline to "next" and putting true mainline at "dev"?  I think it's to the point that 5.1/5.2 are nearly to RK3288 levels of support in mainline.

 

[edit]  Fixed the lower USB port on Renegade.

Share this post


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

@jpegxguy  For the mainline ethernet tx/rx delays, were those just copied from the Rock64 or were they empirically determined?  They're caused by trace impedance/etc, so they're tied to the specific hardware.  I'll dig up the thread/tool Ayufan and Tkaiser were using and see what I get, there might be some more to gain there, since obviously the default ones are fairly bad.

 

@Igor Any argument against moving Ayufan's RK3328 mainline to "next" and putting true mainline at "dev"?  I think it's to the point that 5.1/5.2 are nearly to RK3288 levels of support in mainline.

 

[edit]  Fixed the lower USB port on Renegade.

It would be very cool if you did! I have no objection to that kernel arrangement either

Share this post


Link to post
Share on other sites

I don't use an sd card, but I did try with mmc0 too. It seems to work for me, K 4.20 and 5.0 from archlinuxARM. The gpio-controller thing seems to be there in upstream as well

Share this post


Link to post
Share on other sites

On another note, if the 8ma changes for SD card that are in armbian sources aren't upstream and you consider them better, definitely do send patch upstream! Good work

Share this post


Link to post
Share on other sites

Right, I'm getting a statement that the gpios on the rk805 don't exist from the driver, see debugging is in order there if I have time.  The Rock64 patches look the same, I'll test that when I can. 

 

For the drive level, I'm hoping to capture the waveforms with my oscilloscope to demonstrate the differences beyond theory and some rectified boot failures, then I'll set them up as overrides in the individual dts's as Robin rightly pointed out on a similar topic that the increased drive level will cause increased EMI from the board, some users won't be fan. 

Share this post


Link to post
Share on other sites
On 3/4/2019 at 4:35 PM, TonyMac32 said:

@jpegxguy

@Igor Any argument against moving Ayufan's RK3328 mainline to "next" and putting true mainline at "dev"?  I think it's to the point that 5.1/5.2 are nearly to RK3288 levels of support in mainline.

 

[edit]  Fixed the lower USB port on Renegade.

 

On last look Ayufan stripped all the modules out after 4.4 which ran Ubuntu plus rock ones.

 

I've got a v3 on the way and can do some testing of 5.x.

Share this post


Link to post
Share on other sites
(edited)
On 3/4/2019 at 4:35 AM, TonyMac32 said:

For the mainline ethernet tx/rx delays, were those just copied from the Rock64 or were they empirically determined?

Firefly added some patches to adjust tx/rx delays(ref), as well as for disabling UHS modes that were causing trouble and lowering dmc and sdmmc frequencies and some other tweaks. I patched all of them into the mainline DTB, that was the one we added to rockchip64-Default in the early stages of our Renegade support.

 

I later patched that same Default DTB to add  1.5 GHz CPU freq, and to improve the LED's functions. and that's the one we are using right now for 4.4.y Default. So we can probably just use our Default DTB patches for mainline too.

 

--------------------

 

Besides that, I am planning to find some time to double-check the SD card thing, probably re-enabling UHS and adding some necessary kernel configs for them to work. The main reason for that is the fact that my Renegade hangs on shutdown (not on reboot), and in the next system boot it makes a fsck on the SD card. So I am suspecting that disabling the sd regulators causes some trouble here, and I want to try to re-enable them.

 

However, I am waiting for some Renegade sample from @Da Xue, just to make sure those problems are not exclusive to my particular unit, which has shown to be "special" in other occasions regarding SD cards.

 

Edited by JMCC
Edited: not use the patched Default DTB for mainline, but apply the Default DTB patches to mainline

Share this post


Link to post
Share on other sites

Okay, I just had a look at the commit history, and the history of "/patch/kernel/rockchip64-default/Add_dts_rk3328-roc-cc.patch" was lost when it was merged into a commit for creating the rockchip64 family: now only the tiny LED patch that I applied recently is appearing. So it will be harder to figure out which patches I applied in the first place to make the board work. I'll try to figure it out.

 

[EDIT]: Nevermind, I just figured out the directory containing the patches changed the name. Now I found the original DTS. @Igor please ignore the question I just deleted, in case you got to read it.

Share this post


Link to post
Share on other sites
On 3/4/2019 at 4:35 AM, TonyMac32 said:

Any argument against moving Ayufan's RK3328 mainline to "next" and putting true mainline at "dev"?  I think it's to the point that 5.1/5.2 are nearly to RK3288 levels of support in mainline.

Then why not directly pushing 5.2 into "next", if it has better support than ayufan's 4.20 :P ? In any case, if that's gonna be too much hassle, +1 for adding something to "next", even if it's ayufan's 4.20. Having just default for these boards is boring.

Share this post


Link to post
Share on other sites

Lol we will have some work to do on new kernel anyway, making it dev.  My goal is to wean us off of the special kernels so we can work on getting rk3399 integrated into a single family, what we're doing right now is insane.

Share this post


Link to post
Share on other sites
6 minutes ago, TonyMac32 said:

getting rk3399 integrated into a single family,

Definitely. Right now, there are "first class" and "second class" RK3399 boards: those under the rk3399 family get all the media fancy stuff, while those in the rockchip64 family don't.

Share this post


Link to post
Share on other sites

IMHO the branch "next" should use the primary sources, branch NEXT Linux with minimal patches. The "dev" branch can use any kernel sources, any patches for the kernel and dtb. In this case, you will know exactly in what state the support for specific processors in the main core is and work on patches to be sent to the main core. After all, the main task is to get full support in the main kernel by default (without additional patches in Armbian itself, except for the patch to build DEB packages).

Share this post


Link to post
Share on other sites

I tried for the third time to get an answer from archlinux's kevin on the usb3 patch for renegade on archlinuxARM on another account (scetchy, I know). Apparently I'm added to the sh*tlist for "blatantly" ignoring his Oh, so important rules that he had to ban me from contributing to the project instead of acting like a normal adult.

 

I sent 2 emails - ignored - and looked over the contributor guidelines again.

I formatted my patch as seen in other merged PRs and the onl response I got was

 

"

Skirting bans from your blatant, irreverent disregard for posted rules and requirements and then continuing that tradition has now ensured your permanent placement on the sh*tlist

"

 

I'm so done with this guy. He thinks he's a god. Just look at the way he talks, jesus christ.

 

Seems like he's allergic to equal support for rk3328 boards. Rock64 has exclusive rights to usb3...

 

 

At least this way I finally got an answer instead of the usual ignore.

Share this post


Link to post
Share on other sites

BTW: The hostility of Arch Linux ARM towards contributions is nothing new:

So many PRs go closed without an answer. Sucks for the distro that the devs run on permanent Red Bull rage

Share this post


Link to post
Share on other sites

Well, let's avoid other distros and their management as far as discussion topics go.  That's  a bummer, and your patches are welcome here.

Share this post


Link to post
Share on other sites

Yeah, sorry. I was just really bummed myself. I'll be looking more to actual mainline for mainline stuff, as it should be

Share this post


Link to post
Share on other sites

What's memory performance like on mainline vs 4.4? I've been catching myself up on the state of mainline Rockchip support this morning and stumbled across this: https://github.com/rockchip-linux/u-boot/issues/34. I don't have an unused board to boot and test myself but if indeed DDR clocks are being set low by u-boot and ram performance is no bueno it might be worth a known issue mention when/if mainline is accepted for support.

Share this post


Link to post
Share on other sites
20 minutes ago, Arglebargle said:

What's memory performance like on mainline vs 4.4? I've been catching myself up on the state of mainline Rockchip support this morning and stumbled across this: https://github.com/rockchip-linux/u-boot/issues/34. I don't have an unused board to boot and test myself but if indeed DDR clocks are being set low by u-boot and ram performance is no bueno it might be worth a known issue mention when/if mainline is accepted for support.

RAM DVFS is broken right now in 4.4 Renegade, it stays at a fixed frequency of 1024 MHz, with the possibility to increase it to ~1050 through sysfs (which is close enough to the theoretical maximum of 1066). The Firefly people themselves lowered the frequency via device tree, to increase stability, right when they also lowered SD card speed.  

 

In the mainline kernel, the SD card frequency is not capped, but there is no info on the device tree about RAM speed. I can try make some tests, and post here the results when done.

Share this post


Link to post
Share on other sites

Status update on the ethernet TX issue (iperf tests ending abruptly with some kilobytes transferred and the like)

The cause has been known for a while to be some error in the hardware offloading of TX checksumming. (TX is when the board sends bits out)

 

One way to avoid that issue is to disable TX checksumming (getting the CPU itself to handle that)

e.g.:

But disabling that offloading seems to come with a performance hit.

 

There's some discussion going on about a different approach, which is to tweak the PBL value for TX.

https://lkml.org/lkml/2019/4/1/1382

 

Recently I've been using U-Boot's handy fdt commands to test stuff on my Renegade, and introducing a certain change in txpbl, replacing force_thresh_dma_mode if it is there:

fdt rm /ethernet@ff540000 snps,force_thresh_dma_mode
fdt set /ethernet@ff540000 snps,txpbl <0x21>

 

Share this post


Link to post
Share on other sites

Hi,

 

We are using hundreds of Rock64 boards for a project and we are facing a lot of unreliabilities due to the kernel Armbian is currently using. After long discussions with Lukasz, Kamil, and Pine64 support, we concluded that some kernel fixes are necessary to have a reliable operation. These fixes are available for example in Ayufan's rc9 bionic distribution and all the boards that fail with armbian (it goes from kernel crash at boot to just some subtle miscalculations during some FPU operations) work perfectly well with his kernel.

 

We are ready to support Armbian by providing v2 and v3 Rock64 4GB boards as well as a monetary support to get a kernel update as quick as possible to "un-brick" the 50-60 boards we currently can't use (and to avoid having to switch to another distribution).

 

Please let us now if you're interested and how we could arrange that.

Share this post


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

Hi,

 

We are using hundreds of Rock64 boards for a project and we are facing a lot of unreliabilities due to the kernel Armbian is currently using. After long discussions with Lukasz, Kamil, and Pine64 support, we concluded that some kernel fixes are necessary to have a reliable operation. These fixes are available for example in Ayufan's rc9 bionic distribution and all the boards that fail with armbian (it goes from kernel crash at boot to just some subtle miscalculations during some FPU operations) work perfectly well with his kernel.

 

We are ready to support Armbian by providing v2 and v3 Rock64 4GB boards as well as a monetary support to get a kernel update as quick as possible to "un-brick" the 50-60 boards we currently can't use (and to avoid having to switch to another distribution).

 

Please let us now if you're interested and how we could arrange that.


One very quick fix would be switching to beta repository:
- apt update and upgrade

- armbian-config -> switch to nightly beta builds

 

Kernel in beta repository should be close or identical to Ayufan's latest build ... but its not tested. Its on you to test it. After you switch to beta and if things works as expected, make a freeze (again in armbian-config -> system) and wait until things are properly tested by us and show up in stable repository. Then rather switch back to stable builds.

Regarding board samples we have to discuss who is willing to join this debug party. I only have Rock64, IIRC its v1 with 4G. That will take some time to arrange due to ongoing holidays. I am shortly back to the office tomorrow and can check if I can do anything in this matter - in case suggestion to beta won't do any good.

 

For monetary support please kindly use donate page, where its possible to choose between anonymous PayPal donation and invoice issued/billed to the company. In case you want a combination with publicly known amount and donor (forum) name, use https://forum.armbian.com/subscriptions/

Share this post


Link to post
Share on other sites
39 minutes ago, Igor said:


One very quick fix would be switching to beta repository:
- apt update and upgrade

- armbian-config -> switch to nightly beta builds

 

Kernel in beta repository should be close or identical to Ayufan's latest build ... but its not tested. Its on you to test it. After you switch to beta and if things works as expected, make a freeze (again in armbian-config -> system) and wait until things are properly tested by us and show up in stable repository. Then rather switch back to stable builds.

Regarding board samples we have to discuss who is willing to join this debug party. I only have Rock64, IIRC its v1 with 4G. That will take some time to arrange due to ongoing holidays. I am shortly back to the office tomorrow and can check if I can do anything in this matter - in case suggestion to beta won't do any good.

 

For monetary support please kindly use donate page, where its possible to choose between anonymous PayPal donation and invoice issued/billed to the company. In case you want a combination with publicly known amount and donor (forum) name, use https://forum.armbian.com/subscriptions/

 

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

 

update: switching to nightly, kernel panic as soon as I run my test program (simple argon2i hashing test + stress-ng running in the background, it tends to be easier to trigger under load on some boards) :( (also subcription done, hopefully moving to the biggest one when we can). Let me know if you want the full test protocol along with some boards.

 

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