9 9
Igor

Librecomputer Renegade RK3328

Recommended Posts

@JMCC I'm not sure I understand the issue you're experiencing but I had an instance when I was unable to write (to /boot/ iirc), despite using sudo. Solved it by using the root account instead.

 

Also, I am experiencing some speed hiccups (temporary freezing) but I cannot recreate it at will. I do suspect things run snappier on my Raspberry Pi (e.g. during apt install) and I find myself a bit disappointed with the speed of the Renegade. Also in xfce. I do not know if this is due to the card itself (slow r/w which causes temporary freezing), or bugs in the Armbian image, or whatever else.

Share this post


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

I do suspect things run snappier on my Raspberry Pi (e.g. during apt install)

 

Random IO performance of the rootfs is usually the problem. I would use the iozone call from here, test SD card performance and report back.

Share this post


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

 

Random IO performance of the rootfs is usually the problem. I would use the iozone call from here, test SD card performance and report back.

 

I ran 'iostat 5' in a separate ssh sesh but I don't know how to identify anomalies. I also don't know how to interpret if there are any issues with the iozone results but here's the output:
 

SanDisk Ultra 8gb

Spoiler

    Include fsync in write timing
    O_DIRECT feature enabled
    Auto Mode
    File size set to 102400 kB
    Record Size 4 kB
    Record Size 16 kB
    Record Size 512 kB
    Record Size 1024 kB
    Record Size 16384 kB
    Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
    Output is in kBytes/sec
    Time Resolution = 0.000001 seconds.
    Processor cache size set to 1024 kBytes.
    Processor cache line size set to 32 bytes.
    File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4     2132     2224     7632     7648     6723      803                                                          
          102400      16     7335     6989    15353    15359    14942       98                                                          
          102400     512    10399     8716    23070    23060    20331     2336                                                          
          102400    1024    11002    11727    23244    23237    23062     4767                                                          
          102400   16384    11045    10120    23407    23405    21016     9174                                                          

iozone test complete.
 

image.png.436300b8e0c92e7709422c6a1db8ba24.png

 

 

 

 

SanDisk Extreme 32gb

Spoiler

    Include fsync in write timing
    O_DIRECT feature enabled
    Auto Mode
    File size set to 102400 kB
    Record Size 4 kB
    Record Size 16 kB
    Record Size 512 kB
    Record Size 1024 kB
    Record Size 16384 kB
    Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
    Output is in kBytes/sec
    Time Resolution = 0.000001 seconds.
    Processor cache size set to 1024 kBytes.
    Processor cache line size set to 32 bytes.
    File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4     3232     3316    10065     9965     9276     4512                                                          
          102400      16     8299     8482    17180    17186    17069    10857                                                          
          102400     512    21183    21135    23120    23130    23141    20726                                                          
          102400    1024    22535    22556    23286    23298    23292    21853                                                          
          102400   16384    22243    22289    23462    23451    23451    22479                                                          

iozone test complete.
 

image.png.5cbdc529c87047eb7c98e4648b6108f5.png

 

Share this post


Link to post
Share on other sites
12 hours ago, switch said:

I also don't know how to interpret if there are any issues with the iozone results but here's the output

 

Yesterday you only showed numbers and picture of a 'normal' SanDisk 8GB card. Those are horribly slow when it's about random IO especially at 16K block size (the SanDisk Extreme you tested later is over 100 times faster here). Usually just this makes the difference when comparing 'apt install' or 'apt update/upgrade' performance since apt does a lot of random reads and writes (and issues sync calls with the latter to ensure changes are committed to storage in the appropriate order so a crash while installing or updating won't screw up the whole package management).

 

See here for another nice report about 'random IO storage performance making the real difference'.

Share this post


Link to post
Share on other sites

Thanks for the explanation, @tkaiser. I'm assuming manufacturers do not provide data about the random IO performance of their cards, hence why we're left to test them ourselves.. :angry:  

 

It looks like the Extreme card that I tested even outperforms the Extreme Pro in your tests. but I suppose it also depends on the device used for testing. Perhaps a positive data point if we're trying to determine the Renegade's sd card read/write capabilities?

Share this post


Link to post
Share on other sites
24 minutes ago, switch said:

I'm assuming manufacturers do not provide data about the random IO performance of their cards, hence why we're left to test them ourselves.. :angry:  

 

Not relevant any more since it's 2018 (and we can buy A1 or even A2 rated cards). I added a dynamic link to the thread and adjusted first post accordingly:

 

 

Wrt Renegade: Currently our settings prevent using the faster modes so we're stuck on DDR50 (that's where the ~23 MB/s max originate from). Once SD card issues are resolved we can enable the faster modes and then those better cards will perform way better with the Renegade (only a few other SBC implement higher speed modes, e.g. Tinkerboard, the ODROIDs or Le Potato). Please keep in mind that my SanDisk Extreme Pro from almost 4 years ago can not be compared to something called 'SanDisk Extreme' from 2018 (since all this stuff improves)

Share this post


Link to post
Share on other sites

Just an observation. The SD card performance is not part of why I bought this board.  I have a cheap old 8 gig card (years old 10 rating?) and it works well enough to install Armbian and boot Armbian from my USB3.0 thumb drive.   A  32gig USB memory stick cost $10.  Even tough you need an SD card also, it seems the faster, cheaper way to go. I'm impressed with the speed of the memory stick . 15 second boot and lightning fast upgrade  Unless SD cards can match eMMC or USB3.0 it seems like a waste IMHO.  All you need it for is booting USB3.0

 

 Tomorrow my USB 3.0 SSD dock+built in USB 3.0 Hub will arrive.  Hope it will boot from that too.  I'll let you know if anyone cares.

Share this post


Link to post
Share on other sites
6 hours ago, EndtheFED said:

I'm impressed with the speed of the memory stick

 

Care to provide numbers from a quick iozone benchmark as described here: https://forum.armbian.com/topic/954-sd-card-performance/?

 

I tested some 'quality' pendrives last year and was highly disappointed about the performance after some time or usage. Nice performance when starting to use them but after some time or amounts of write performance really started to suck. The only 'pendrive' working flawlessly so far looks like this for me:

TS120GMTS420_JMS578.jpg

 

JMS578_M2.jpg

 

A real M.2 SATA SSD with heatsinks to prevent overheating/throttling on a JMS578 adapter. Without heatsink and with enclosure closed also unusable since the SSD overheats too much (sequential transfers then drop from 400 MB/s to ~30 MB/s)

 

6 hours ago, EndtheFED said:

All you need it for is booting USB3.0

 

 

Why should everybody have the same needs? Users might want to attach a HDD to the USB3 port then 'booting from USB3' is not an option any more as long as you want the HDD to spin down. Putting an USB hub between host and disk is always a great idea to introduce problems.

Share this post


Link to post
Share on other sites

I see your point. My hope was always for booting SSD.  Both worked without new problems so far. The memory stick was a test, before I spent $30 on a dock.

 

I'd be glad to test the SanDisk Ultra  32Gig USB 3.0 stick (It has no heatsink so, looks like a problem).  Should the test be run headless? Also should I run iozone in auto? I'm a noob, who can follow directions well. 

 

I only have 2 no name and 2 PNY SD cards. The no name are over 3 years old and, second hand.  The 1 PNY is at least a year old . The other is 2 years old. So I'm sure you don't want any those. 

Share this post


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

I'd be glad to test the SanDisk Ultra  32Gig USB 3.0 stick (It has no heatsink so, looks like a problem).  Should the test be run headless?

 

If you boot off the stick already then it's as easy as

cd $HOME
cpufreq-set -g performance
iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

I bought 3 different SanDisk pendrives last year (all USB3) and they showed nice sequential performance that dropped after few minutes of use since the things started to throttle down. And with random IO (which is the important metrics on SBC or computers in general) they all sucked horribly after some time.

 

I then tested on macOS putting some virtual machines on the fastest stick and attached it to an USB3 port of a MacBook Pro. Unusable since all my 3 sticks are simply overwhelmed by increased random IO workloads.

Share this post


Link to post
Share on other sites

You are right! Performance dropped quick. It's taking a couple of min to do a line now. I killed the test, as it was going way too slow. I don't want to burn anything up. SSD had no problems with iozone testing. I also notice instability in all installs. SSD seems constant but not right.eg. desktop is off until enabled in config or startx command. Sound works on start of desktop unlike SD and USB stick installs

 

Sorry I bothered you lol. You taught me a lot. Keep up the good work! Being a noob I will just observe from now on, unless I see a way to help.

Share this post


Link to post
Share on other sites
18 hours ago, tkaiser said:
19 hours ago, EndtheFED said:

I'd be glad to test the SanDisk Ultra  32Gig USB 3.0 stick (It has no heatsink so, looks like a problem).  Should the test be run headless?

 

If you boot off the stick already then it's as easy as


cd $HOME
cpufreq-set -g performance
iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

Running correctly now. I ran iozone -a only lol. I'll post on the right thread when it's done. 

 

Share this post


Link to post
Share on other sites
On 7/18/2018 at 10:22 AM, tkaiser said:

Wrt Renegade: Currently our settings prevent using the faster modes so we're stuck on DDR50 (that's where the ~23 MB/s max originate from). Once SD card issues are resolved we can enable the faster modes and then those better cards will perform way better with the Renegade (only a few other SBC implement higher speed modes, e.g. Tinkerboard, the ODROIDs or Le Potato).

Is there anything I can do to assist in this, e.g. reach out to Firefly and ask them for certain settings? I would need to know exactly what to ask them.

 

To everyone: besides the SD issues, do all other functions seem to be running smoothly on the Renegade with this image, in your testing? or is there anything else I should ask Firefly when I contact them.

 

Thx guys

Share this post


Link to post
Share on other sites
On ‎8‎/‎14‎/‎2018 at 10:45 AM, switch said:

reach out to Firefly and ask them for certain settings

Precisely the lines in the dtb that disable fast SD card modes are taken from recent Firefly's kernel patches (see here and here). As a matter of fact, I am using the official Firefly image, that was compiled before they pushed those patches, and SD card works perfectly with it. I'm not sure why they did it, but it seems like in Armbian it makes the image bootable, though some people (like me) are unable to use the system more than a few seconds before SD card starts failing.

 

My findings point in the direction that, for some reason, voltage selection is not working in our images. Could be a u-boot problem, or some patch from Ayufan that is not in the original Rockchip image that Firefly uses. I tried to troubleshoot it in the past, with no luck. Right now, I am a bit absent from Armbian due to personal reasons, but it seems like @Da Xue is also working on the issue.

Share this post


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

Precisely the lines in the dtb that disable fast SD card modes are taken from recent Firefly's kernel patches (see here and here). As a matter of fact, I am using the official Firefly image, that was compiled before they pushed those patches, and SD card works perfectly with it. I'm not sure why they did it, but it seems like in Armbian it makes the image bootable, though some people (like me) are unable to use the system more than a few seconds before SD card starts failing.

 

My findings point in the direction that, for some reason, voltage selection is not working in our images. Could be a u-boot problem, or some patch from Ayufan that is not in the original Rockchip image that Firefly uses. I tried to troubleshoot it in the past, with no luck. Right now, I am a bit absent from Armbian due to personal reasons, but it seems like @Da Xue is also working on the issue.

S905X and RK3328 both suffer from some issues with SD cards in UHS mode. When driving them at UHS speeds of more than 100MHz, the SoCs cannot drive enough current to bring the voltages up and down enough. You see degradation of the signal and some cards are more accommodating to this than others. S905X does not have reset lines for power cycling MicroSD cards which becomes an issue when you reboot and the board tries to go back to UHS mode from non-UHS. Samsung cards that I've tested will plain drop dead while Sandisk will not re-enter UHS mode. A board power cycle becomes necessary. The SoC was designed for SD cards to be pushed in and out and did not really consider using them as boot devices. eMMC is the way to go for these SoCs.

Share this post


Link to post
Share on other sites
9 hours ago, Da Xue said:

S905X and RK3328 both suffer from some issues with SD cards in UHS mode. When driving them at UHS speeds of more than 100MHz, the SoCs cannot drive enough current to bring the voltages up and down enough.

 

On the RK3288 boards, if I am remembering correctly, the drive level is modified in the dts to avoid this issue.  Is that possible with the RK3328 at least?  I think the mmc IP is the same, but don't quote me on that.

 

[edit] 

https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3328.dtsi#L1432

 

This part of the dtsi shows the default 4 mA drive levels for the pins.

 

Tinker Board sets the equivalent RK3288 pins to 8 mA: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/rk3288-tinker.dts#L429

 

It would stand to reason you could do the same with RK3328: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3328.dtsi#L979

 

 

Share this post


Link to post
Share on other sites
On ‎8‎/‎15‎/‎2018 at 11:37 PM, TonyMac32 said:

It would stand to reason you could do the same with RK3328

Worth giving a try, but RK3328's DT seems more complex when it comes down to sdmmc: 

https://github.com/torvalds/linux/blob/df2def49c57b4146520a1f4ca37bc3f494e2cd67/arch/arm64/boot/dts/rockchip/rk3328.dtsi#L1371

 

Would you change all the entries? I'm not sure whether the SoC supports multiple SD cards, or it is just that the DT needs to have different entries for the one card reader.

Share this post


Link to post
Share on other sites

It's applied per pin associated with the peripheral, so unless there's some drive strength multiplexing you should only define it for the desired SD pins. I haven't had an issue with mine, but I also haven't stressed it so I'll give it a look some time. (Next couple days I am a slave to my company, it will be 14 hours/day).

Sent from my Pixel using Tapatalk

Share this post


Link to post
Share on other sites

In roc-rk3328-cc board, the signal voltage of sdmmc is supplied by the vcc_sdio regulator, which is a mux between 1.8V and 3.3V, controlled by a special output only gpio pin labeled "gpiomut_pmuio_iout", corresponding bit 1 of the syscon GRF_SOC_CON10.

https://patchwork.kernel.org/patch/10550013/

original kernel also changed the file drivers/regulator/gpio-regulator.c in commet https://github.com/rockchip-linux/kernel/commit/b989ade19312ecf57f993120b9668b9d1d3fd380

 

Share this post


Link to post
Share on other sites
6 hours ago, arkua233 said:

In roc-rk3328-cc board, the signal voltage of sdmmc is supplied by the vcc_sdio regulator, which is a mux between 1.8V and 3.3V, controlled by a special output only gpio pin labeled "gpiomut_pmuio_iout", corresponding bit 1 of the syscon GRF_SOC_CON10.

https://patchwork.kernel.org/patch/10550013/

original kernel also changed the file drivers/regulator/gpio-regulator.c in commet https://github.com/rockchip-linux/kernel/commit/b989ade19312ecf57f993120b9668b9d1d3fd380

 

Well, there are some kernel configs in the first commit referenced here, that we are not enabling. They may very likely be the cause for the board not booting when you enable vcc_sdio. 

I think it is worth giving a try. But someone else will have to test it in a Rock64 to make sure these configs don't affect it, since I only have the Renegade.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
9 9