Librecomputer Renegade RK3328

[tkaiser]

9 minutes ago, JMCC said:

Are you aware of this change?

 

Hmm... at least reverting back to the original tx/rx delay settings might be worth a look. But am running out of spare time this week. Wrt DRAM timings and this dmc stuff I've not the slightest idea how this works (ayufan several times tried to educate me already about this but to no avail  ) -- I only queried /sys/bus/platform/drivers/rockchip-dmc/dmc/devfreq/dmc/trans_stat and got the numbers from there.

 

 

[TonyMac32]

What did you do to solve it? I'm also getting ro filesystem, with two different SD cards.

My system was still building old images, why? Good question. I'll double check today though, I also can't get Le Potato to boot at all on 4.17, which doesn't make any sense, it looks like DVFS is hanging it, which also doesn't make sense.

Sent from my Pixel using Tapatalk

[tkaiser]

7 hours ago, chwe said:

at least the patch is there: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-rk3328-default/add_fdtfile_dt_overlays.patch

 

Now I remember: 2 of 3 u-boot patches failed or generated a warning (size_support_ddr4.patch and add_fdtfile_dt_overlays.patch IIRC).

[tkaiser]

8 hours ago, tkaiser said:

reverting back to the original tx/rx delay settings might be worth a look

 

No difference in numbers when trying out

                tx_delay = <0x25>;
                rx_delay = <0x11>;

So i hope we get DT overlays working to be able to test through all reasonable combinations soon. Without DT overlays this would require a huge amount of reboots  

 

Edit: as a reference Rock64 numbers: https://forum.pine64.org/showthread.php?tid=4668

[tkaiser]

Another benchmark number using https://github.com/tkinjo1985/cpuminer-multi (prerequisit on Stretch: 'apt install libcurl4-openssl-dev libgmp-dev libgmpxx4ldbl libjansson-dev pkg-config zlib1g-dev').

 

I get 3.94 kH/s running on the CPU cores at 1392 MHz (no throttling). And 3.95 kH/s when switching both cpufreq and memory (dmc) governor to performance. As a reference RK3399: https://forum.armbian.com/topic/6496-odroid-n1-not-a-review-yet/?do=findComment&comment=49425

 

I hoped for some slightly better numbers due to faster DDR4 RAM here.

 

[chwe]

6 hours ago, tkaiser said:

So i hope we get DT overlays working to be able to test through all reasonable combinations soon. Without DT overlays this would require a huge amount of reboots  

reboot might be needed anyway? Or do we have 'on the fly' capable DT overlay drivers? Did you ever check why add_fdtfile_dt_overlays.patch fails? As far as I can see, the overlay stuff is also there in the bootscript, so it might be 'not that hard' to get it working. I don't have any rk3328 board at hand to test this things properly - don't trust my self to do this without having a board to test it after its, this always ends in a mess. 

[tkaiser]

1 hour ago, chwe said:

reboot might be needed anyway? Or do we have 'on the fly' capable DT overlay drivers?

 

The latter. That's the main difference between @ayufan's attempt and mine. And no, haven't had a look at the patch failures and am currently away from any build host... or to be more precise from the SSD carrying the VM and all the cached stuff:

[JMCC]

I keep getting fs errors, that cause root fs to be mounted read only, after just a few writes on the SD card. Tried with different cards. All these cards work perfectly in the board with Firefly's image.

 

It surprises me that you guys are not getting these errors. Can you post here make and model of the SD cards you are using? Thanks.

[TonyMac32]

Let me try it again, the image from Igor had no issues of that type, but I haven't tried to rebuild myself in a day or two.

Sent from my Pixel using Tapatalk

[tkaiser]

On 7/2/2018 at 12:32 PM, tkaiser said:

When testing with iperf3 I got the usual 940 Mbits/sec in RX direction but only 845 Mbits/sec TX. So most probably TX/RX delays need a little adjustment.

 

Or it's just an RK3328 limit? Tested again with Rock64 (but an early developer sample) and got 835 Mbits/sec in TX direction: https://pastebin.com/raw/cwqag6e8

[tkaiser]

On 7/4/2018 at 2:12 PM, JMCC said:

Can you post here make and model of the SD cards you are using?

SanDisk Extreme A1 32GB

[tkaiser]

On 7/3/2018 at 8:59 AM, tkaiser said:

I get 3.94 kH/s running on the CPU cores at 1392 MHz (no throttling). And 3.95 kH/s when switching both cpufreq and memory (dmc) governor to performance.

 

Tested also with Rock64 (slightly slower memory). We get there 3.63 kH/s with our old setting limiting Rock64 to 1.3 GHz. After lastest commit at 1.4 GHz Rock64 scores 3.88 kH/s as expected (little bit slower compared to Renegade due to different DRAM)

[JMCC]

22 hours ago, tkaiser said:

 

Or it's just an RK3328 limit? Tested again with Rock64 (but an early developer sample) and got 835 Mbits/sec in TX direction: https://pastebin.com/raw/cwqag6e8

Anyway, those numbers are not any bad, as long as the connection is totally stable.

 

I'm still struggling with the sd card problem. I think it has to do with voltage. Tweaking the regulator settings, I get the system to be stable at least for some minutes. I'm uploading here a link to 'armbianmonitor -u' output, for my own future reference: http://ix.io/1g8E; http://ix.io/1gdF

[JMCC]

Some progress: in a Firefly image, you can see a line like the following in kern.log:

dwmmc_rockchip ff500000.dwmmc: Successfully tuned phase to 140

But that does not appear in Armbian's kern.log. I think this is what is causing the trouble. Well, now I only need to figure out why Armbian is not able to tune the SD card phase, while having exactly the same device tree as Firefly.

 

[EDIT: No, we are not using the same device tree as the Firefly images, but the same as the last commit in their repo. Using the .dtb from a Firefly on Armbian, causes the SD card init problem we had before. So it's probably some new issue that has appeared with recent versions of the kernel, and is not appearing in Firefly's images because they are older.]

[JMCC]

Got a brand new Samsung Evo+ 64Gb, and same failure: FS corruption after a few writes. 

 

My board only has 1Gb RAM, that is the only difference I can think of with the rest of your boards. So @tkaiser do you think there is any chance that the new ZRAM implementation can be causing this problem? I've seen nothing in the logs that may suggest something like that, but if you can have a look: http://ix.io/1g8E

[Igor]

35 minutes ago, JMCC said:

the new ZRAM implementation can be causing this problem?

Edit /etc/default/armbian-zram and disable it.

[JMCC]

1 hour ago, Igor said:

Edit /etc/default/armbian-zram and disable it.

Thanks for the hint. Disabled both zram and ramlog, with no difference. I'm still trying to figure out why I'm the only one experiencing the problem. Could be a defective unit, but then why does it work with Firefly's image?

 

[JMCC]

On 7/1/2018 at 11:35 PM, switch said:

Let me know if there's anything else you'd like me to check or test

Can you please do somethings that performs intensive SD card I/O, like for example:

$ sudo apt install libreoffice

And then, post here the output of:

$ sudo armbianmonitor -u

 

[Igor]

3 minutes ago, JMCC said:

but then why does it work with Firefly's image?

They probably use a patch somewhere we don't have. Do we have the same u-boot / kernel? Perhaps trying with the same kernel config, device tree, ...

[JMCC]

4 minutes ago, Igor said:

They probably use a patch somewhere we don't have. Do we have the same u-boot / kernel? Perhaps trying with the same kernel config, device tree, ...

Here's the situation:

• I tried using their device tree (which is very similar to the one we were using before I made the last PR), but that makes our kernel unable to initialize SD card, as happened before that last PR I mentioned.
• So I was assuming that a recent kernel like ours introduced some incompatibility with the old device tree. But, now that you mention, it can also be that they are using some patch we don't have. If I am able to pinpoint that patch, it can be introduced per-board without affecting Rock64, can't it?

[Igor]

If we are talking about u-boot patch then yes. It can be per board, for kernel it has to be inside board dt or via some hack. But first we need to find out where

Wrote on mobile

[switch]

On 7/7/2018 at 9:17 PM, JMCC said:

Can you please do somethings that performs intensive SD card I/O,

Here you go: 
For reference the card is a SanDisk Ultra 8gb HC I class 10 (at least that's what's printed on it).

 

PS I previously stated that my board shows 4GB but I'd just like to confirm.. 'free -m' shows 3924, which is normal for 4GB right?

[JMCC]

17 minutes ago, switch said:

 'free -m' shows 3924, which is normal for 4GB right?

It seems like a normal number to me.

[switch]

Just wanna check if anyone has successfully gotten full disk encryption to work for the Renegade? I've been following a couple different tutorials but mostly this tutorial in the forum: 

which is for Armbian on Orange Pi (was hoping the process would be same or similar for the Renegade). Nonetheless I've been unsuccessful in my attempts, the board won't boot with the SD card with the encrypted partition. Does anyone have any ideas?

[chwe]

10 minutes ago, switch said:

Just wanna check if anyone has successfully gotten full disk encryption to work for the Renegade? I've been following a couple different tutorials but mostly this tutorial in the forum: 

you may go though this PR: https://github.com/armbian/build/pull/948

never did it, never test it.. but for sure more recent than yours.. 

[switch]

Thanks but I've seen that pull request. The post-install script posted in the thread is kind of a mess because of the author's special use case (sata drive with dedicated root and data dirs) which further complicates an already-confusing process. At least I was having difficulty making sense of it when I was trying to get it to work and eventually gave up, I'm not as experienced with these things as some of you guys.

 

I suppose my only option would be to try building an image of my own with the cryptsetup build options configured. I'll be following the instructions in the Armbian docs but is there anything in particular I should be doing when building for the Renegade? (I'm not clear on if the board is officially supported or not)

[tkaiser]

On 7/5/2018 at 2:20 PM, tkaiser said:

Or it's just an RK3328 limit? Tested again with Rock64 (but an early developer sample) and got 835 Mbits/sec in TX direction: https://pastebin.com/raw/cwqag6e8

 

Feeling a bit stupid now since by looking through this thread I found my own test numbers made with Firefly image/kernel/settings: 940 Mbits/sec in both directions. So we have a problem somewhere in either Armbian or ayufan's kernel/settings.

[JMCC]

9 hours ago, tkaiser said:

So we have a problem somewhere in either Armbian or ayufan's kernel/settings.

We have other problems too with Ayufan's kernel on Renegade, like the SD card related I experience in my board. Firefly's kernel is basically a Rockchip kernel from February 24 2018 plus about a dozen patches, while our current Ayufan kernel seems to be remotely based on a Rockchip kernel from May 2017, with hundreds of patches on top. I know the SD card problems are not in any Armbian patch (I tried disabling them all), but locating the problem in the Ayufan's history seems extremely difficult. Probably the network speed problem will be difficult too.

 

Just in case, to make sure the problem is not in our Device Tree patches, you may want to try your tests with the Firefly image and the attached DTB.

rk3328-roc-cc.dtb

[Da Xue]

On 7/2/2018 at 1:24 AM, tkaiser said:

 

Which storage media did you test with iozone?

 

 

Seems like @Da Xue has better settings: https://forum.armbian.com/topic/6772-tinymembench-on-renegade-roc-rk3328-cc-1gb/

 

I am seeking an resolution to all the MicroSD card issues. This is why I don't touch BSPs. They are terrible and utterly unusable. Sorry about all the wasted time.

[JMCC]

11 hours ago, Da Xue said:

I am seeking an resolution to all the MicroSD card issues.

Have you figured out if it is something specific for certain hardware configs / board revision numbers? Mine is 1Gb RAM, rev ROC-RK3328-CC-V1.0-A, and I am experiencing the SD card issues that can be observed in the logs posted here.

 

It seems like in this post, @switch confirmed that he was not having SD card issues (he posted a link for "armbianmonitor -u "results, but now he deleted it, probably privacy concerns?). He has a 4Gb board.

 

@Da Xue Would it be useful if we all posted here our board RAM size and revision number, together with a succint statement saying whether we have card problems or not?