Jump to content

Librecomputer Renegade RK3328

Igor

By Igor
in Libre Renegade

 Share

Recommended Posts

TonyMac32

TonyMac32

Posted
Posted

There is something gone wrong with the U-boot setup, it's going into a loop n ethernet

@JMCC, were there some U-boot patches that should have been included?

 

 

  Reveal hidden contents

 

0
JMCC

JMCC

Posted
Posted

OK, so here is the head of the bootlog from the images we just uploaded:

  Reveal hidden contents

And this is the bootlog head from an image I just built from the master branch:

  Reveal hidden contents

 

So it looks like there was some problem in the config when running the build script. Possible causes I can think of:

  • Mistakenly chose the wrong board
  • Used the "development" branch instead of "master". All the u-boot and kernel patches were merged directly into master.

@Igor Can you please double check these?

 

0
TonyMac32

TonyMac32

Posted
Posted

I see the patches in there, let me verify by building it myself.  Building a Rock64 at the moment to see if there was a different issue entirely, but that seems not to be the case

 

I can boot the one I build myself.

 

[edit]   ...buuuut it seems to like to lock down the filesystem midstream.  let me get some monitoring hardware set up and see if I've found a bad cable or if the SD slot perhaps does not support the modes it claims to...

 

SD cards in question: 

 

  • 128 GB Samaung EVO select
  • 32 GB SanDisk Extreme U3 A1

 

 

0
JMCC

JMCC

Posted
Posted
  On 6/30/2018 at 5:33 PM, TonyMac32 said:

the SD slot perhaps does not support the modes it claims to...

Expand  

If you notice, the dts patch includes some stuff related to disabling high-speed SD card modes, probably because of lack of reliability. Actually, it was SD card initialization failure that was causing the board not to boot.

 

I have tested the board for a while, with a Toshiba Class 10 HC I, but couldn't do much because of the bug I am experiencing in my build system that makes "crippled" images. That's why I wanted to get the images built by the Armbian server, so I could do more intensive testing.

0
constantius

constantius

Posted
Posted

on Saturday I saw a single board Renegade. As not supported. But there was an img file to download. Now I see that it is removed. There is a renegade.wip file on github. But you can not build a img of it. Do you have to wait a little longer?

0
Igor

Igor

Posted
  • Author
Posted
  On 7/1/2018 at 2:49 PM, constantius said:

There is a renegade.wip

Expand  


There is no support for WIP so your questions will be/are ignored anyway. And you have no right to create any pressure on developers. (not the first time)

0
TonyMac32

TonyMac32

Posted
Posted

@Igor was the image uploaded actually and accidentally a renamed Rock64 image? That could explain (part of) the issue with that image. For the filesystem issue, I haven't gotten any farther debugging unfortunately.

Sent from my Pixel using Tapatalk

0
Igor

Igor

Posted
  • Author
Posted
  On 7/1/2018 at 4:32 PM, TonyMac32 said:

@Igor was the image uploaded actually and accidentally a renamed Rock64 image?

Expand  


Nope. It was Renegade. I rebuild for Rock64 this afternoon after this and it works/boots fine. (it was broken too)

0
TonyMac32

TonyMac32

Posted
Posted
  On 7/1/2018 at 4:44 PM, Igor said:

Nope. It was Renegade. I rebuild for Rock64 this afternoon after this and it works/boots fine. (it was broken too)
Strange, since even the U-boot message said Rock64, I built the roc-whatever recipe and it was labelled correctly. That's interesting. I had a Rock64 built and yes, it was panic-on-boot, wheras the renegade wasn't finding the boot script/environment at all.

Sent from my Pixel using Tapatalk

0
Igor

Igor

Posted
  • Author
Posted
  On 7/1/2018 at 5:08 PM, TonyMac32 said:

Strange, since even the U-boot message said Rock64

Expand  


Well, I didn't test it :) and I can only wait that someone builds it and confirm. Then I'll do it again.

0
Staars

Staars

Posted
Posted

I think, it could be the board specific ddr4-patch, which was made for the "old" board name and now resides in the incorrect subdir.

 

0
JMCC

JMCC

Posted
Posted
  On 7/1/2018 at 5:30 PM, Igor said:

Well, I didn't test it :) and I can only wait that someone builds it and confirm. Then I'll do it again.

Expand  

I built the new renegade.wip from "master" branch, and it boots and works. As Tony and me could confirm, yesterday the former roc-rk3328-cc.csc from "master" also worked, so I'm pretty sure the problem was that the download image was built from "development", which was still pointing to an old config using the rock64 u-boot. But now, since the file "renegade.wip" is only in master, I think there cannot be any possibility of the same confusion happening again. :thumbup:

 

On the other hand, I have noticed that with today's image my board shows only 510 MiB of RAM, while yesterday it showed the full 1 GiB. I want to troubleshoot this, but for that I need a fully working image. And, as I said, my images are buggy because of the name resolution bug some of us are experiencing in the build script.

 

So @Igor , in case you are not going to restore the download link for Renegade images yet to the download page, would you mind building and image and sending me the link? That way, I can use it as a base, and only build u-boot and kernel for my tests.

0
Igor

Igor

Posted
  • Author
Posted
  On 7/1/2018 at 7:40 PM, JMCC said:

And, as I said, my images are buggy because of the name resolution bug some of us are experiencing in the build script.

Expand  

 

Is this still present? This looks like a temporally (upstream) network related bug.

  On 7/1/2018 at 7:43 PM, TonyMac32 said:

I think it is the patches in the wrong subfolder as mentioned earlier. I'll check it out now

Expand  

 

Yes. Fixed. Now it is also clear why u-boot was from Rock64 ... I haven't notice error while compiling ... and since u-boot was already present (not cleaned properly) ... it didn't break the compilation. I'll remake it and put to the server.

3
JMCC

JMCC

Posted
Posted
  On 7/1/2018 at 7:52 PM, Igor said:

Is this still present? This looks like a temporally (upstream) network related bug.

Expand  

Yes, I also think so. That's why I'm not caring to look for a solution, because I'm waiting for upstream devs to fix it. In case that fix doesn't come, we'll have to try and look for a workaround.

0
switch

switch

Posted
Posted

The new image boots successfully! Great job guys, thanks for your work.

 

PS: It shows 4gb RAM for my board, as it should. Let me know if there's anything else you'd like me to check or test and I'll do my best to help.

2
TonyMac32

TonyMac32

Posted
Posted

I need to look into my board, I'm getting a read-only FS again, even with new images...
 

Update, nothing to be concerned about, everything is good.

0
TonyMac32

TonyMac32

Posted
Posted

Some "numbers without meaning" for people to look at since it's running.  Kernel 4.4, Ayufan Edition:

 

tinymembench, since DDR4 and multiple channels are at play.

  Reveal hidden contents

 iozone -e -I -a -s 100M -r 1k -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

  Reveal hidden contents

Hmmm.

 

7-zip 

CPU Freq:   897  1283  1288  1288  1289  1288  1288  1288  1288

RAM size:    3924 MB,  # CPU hardware threads:   4
RAM usage:    882 MB,  # Benchmark threads:      4

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:       2080   312    649   2024  |      54016   377   1222   4608
23:       2064   320    657   2104  |      48891   352   1201   4230
24:       2033   330    662   2186  |      40864   304   1178   3587
25:       1983   339    668   2264  |      38180   298   1142   3398
----------------------------------  | ------------------------------
Avr:             325    659   2144  |              333   1186   3956
Tot:             329    922   3050

[edit] I'm only getting 1296 MHz according to armbianmonitor, haven't looked at the dts just yet

0
tkaiser

tkaiser

Posted
Posted
  On 7/2/2018 at 3:24 AM, TonyMac32 said:

 iozone -e -I -a -s 100M -r 1k -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

Expand  

 

Which storage media did you test with iozone?

 

  On 7/2/2018 at 3:24 AM, TonyMac32 said:

tinymembench, since DDR4 and multiple channels are at play

Expand  

 

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

 

0
TonyMac32

TonyMac32

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

Which storage media did you test with iozone?

Expand  

 

The 32 GB eMMC that can be purchased with one.

 

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

Seems like @Da Xue has better settings: 

Expand  

 

Agreed, although there was a question about HDMI connected vs not.  In my case it was connected.  Will be good to see what is different.

0
tkaiser

tkaiser

Posted
Posted
  On 7/2/2018 at 3:24 AM, TonyMac32 said:

I'm only getting 1296 MHz according to armbianmonitor, haven't looked at the dts just yet

Expand  

 

https://github.com/armbian/build/commit/5eaa80faa2b39e1237177dcbbd0aaedbd14c0818 should fix it on future images (for now /etc/defaults/cpufrequtils needs a modification). I believe for the individual boards the DT contents should determine cpufreq/dvfs details and our cpufrequtils settings allow for a reasonable maximum.

 

Wrt your iozone numbers... did you ensure you were running at 1296 MHz then too (switching temporarly to performance governor)?

0
tkaiser

tkaiser

Posted
Posted
  On 7/2/2018 at 5:32 AM, TonyMac32 said:

 

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

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

 

Expand  

 

Agreed, although there was a question about HDMI connected vs not.  In my case it was connected.  Will be good to see what is different.

Expand  

 

I allowed the board to clock at up to 1.4 GHz and now numbers look better: 7-zip scores at 3600 and tinymembench numbers are closer to @Da Xue's: https://pastebin.com/raw/fXS5yynq

 

The iozone numbers (as expected up to 400 MB/s) below were made with an ext4 formatted Samsung EVO840 in an ASM1153 enclosure (to compare here numbers with NanoPC T4): 

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    17990    29229    20183    19710    18707    25283
          102400      16    53238    77145    64954    65276    64100    75384
          102400     512   290307   325750   306785   316503   316440   314954
          102400    1024   333578   343750   330396   341635   340211   340705
          102400   16384   383959   387502   372153   384013   384206   389908
         1024000   16384   401165   404221   380780   383637

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.

 

'armbianmonitor -u' output: http://ix.io/1fIV

0
tkaiser

tkaiser

Posted
Posted
  On 7/2/2018 at 10:32 AM, tkaiser said:

tinymembench numbers are closer to @Da Xue's: https://pastebin.com/raw/fXS5yynq

Expand  

 

And here are the numbers after doing the below (for details see here): https://pastebin.com/raw/d61z7YY1 

echo performance > /sys/bus/platform/drivers/rockchip-dmc/dmc/devfreq/dmc/governor

If I understood correctly the result was switching from 1024 timing to 1066: 

root@renegade:~# cat /sys/bus/platform/drivers/rockchip-dmc/dmc/devfreq/dmc/trans_stat
   From  :   To
         :78600000080000000085000000093300000010240000001066000000   time(ms)
 786000000:       0       0       0       0       1       0         1
 800000000:       0       0       0       0       0       0         0
 850000000:       0       0       0       0       0       0         0
 933000000:       0       0       0       0       0       0         0
 1024000000:       0       0       0       0       0       1   5985353
*1066000000:       0       0       0       0       0       0    903822
Total transition : 2

 

Wrt TX/RX delay adjustments here is a script made by ayufan to check through a specific range: https://github.com/ayufan-rock64/linux-build/commit/d32a459705afdcc43e2e3f129e9b37577bf13962 (also useful to learn how to use DT overlays with RK's 4.4 BSP kernel). The settings we currently use as follows: https://github.com/teacupx/build/blob/98100bf764235e153bb6ce6fe558fc3a06f4aa39/patch/kernel/rk3328-default/Add_dts_rk3328-roc-cc.patch#L735-L736

 

But the script doesn't work for whatever reasons.

0
JMCC

JMCC

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

The settings we currently use

Expand  

Yes, I noticed in the patch I applied there was some other stuff not directly related to sdcard initialization, which was the bigger problem and the main reason why I moved to Firefly's device tree. But, for sure, there are many things to tweak. I had in my checklist that one regarding tx/rx delays, because the patch changed them WRT the dts we were using before, and the fact is that ethernet doesn't work too well in Firefly images.

 

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

the script doesn't work for whatever reasons

Expand  

I'm not sure DT overlays are functional in Renegade, I saw some errors about it in the u-boot log but didn't get to it yet.

 

  On 7/1/2018 at 11:03 PM, TonyMac32 said:

Update, nothing to be concerned about, everything is good.

Expand  

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

0
chwe

chwe

Posted
Posted
  On 7/2/2018 at 9:16 PM, JMCC said:
  On 7/2/2018 at 12:06 PM, tkaiser said:

the script doesn't work for whatever reasons

Expand  

I'm not sure DT overlays are functional in Renegade, I saw some errors about it in the u-boot log but didn't get to it yet.

Expand  

 

From the kernelconfig side... It should.. from the u-boot side I didn't check it (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 ).. May need testing.. I started this stuff once for the rockchip-default (rk3288) kernel but it messes up with the ISP driver (https://github.com/rockchip-linux/kernel/issues/98#issuecomment-396422765). Let's hope this isn't true for other RK drivers.. :P 

 

 

0

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.

×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept