Jump to content

Librecomputer Renegade RK3328


Igor

Recommended Posts

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?

 

 

Spoiler

DDR version 1.06 20170424
In
DDR4
786MHz
Bus Width=32 Col=10 Bank=4 Bank Group=2 Row=16/16 CS=2 Die Bus-Width=16 Size=4096MB
ddrconfig:19
OUT
Boot1 Release Time: 2017-05-18, version: 2.43
ChipType = 0x11, 178
emmc reinit
emmc reinit
SdmmcInit=2 20
SdmmcInit=0 0
BootCapSize=0
UserCapSize=30436MB
FwPartOffset=2000 , 0
StorageInit ok = 59977
Raw SecureMode = 0
SecureInit read PBA: 0x4
SecureInit read PBA: 0x404
SecureInit read PBA: 0x804
SecureInit read PBA: 0xc04
SecureInit read PBA: 0x1004
SecureInit ret = 0, SecureMode = 0
LoadTrustBL
No find bl30.bin
No find bl32.bin
Load uboot, ReadLba = 2000
Load OK, addr=0x200000, size=0xa4968
RunBL31 0x10000
NOTICE:  BL31: v1.3(debug):f947c7e
NOTICE:  BL31: Built : 07:11:00, Jun 16 2018
NOTICE:  BL31:Rockchip release version: v1.3
INFO:    ARM GICv2 driver initialized
INFO:    Using rkfiq sec cpu_context!
INFO:    boot cpu mask: 1
INFO:    plat_rockchip_pmu_init: pd status 0xe
INFO:    BL31: Initializing runtime services
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x200000
INFO:    SPSR = 0x3c9


U-Boot 2017.09-armbian (Jun 30 2018 - 11:43:55 +0000)

Model: Pine64 Rock64
DRAM:  2 GiB
MMC:   rksdmmc@ff520000: 0, rksdmmc@ff500000: 1
SF: unrecognized JEDEC id bytes: ff, ff, ff
*** Warning - spi_flash_probe_bus_cs() failed, using default environment

In:    serial@ff130000
Out:   serial@ff130000
Err:   serial@ff130000
Model: Pine64 Rock64
misc_init_r
cpuid=55524b50303130313400000000110e12
serial=16c3987c7d10a6a
Net:   eth0: ethernet@ff540000
Hit any key to stop autoboot:  0
Card did not respond to voltage select!
mmc_init: -95, time 9
Card did not respond to voltage select!
mmc_init: -95, time 9
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   Core Release: 3.10a
USB3:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning bus 3 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

Device 0: unknown device
ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@ff540000
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/01-9a-b4-1a-ca-e3-57
ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@ff540000
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@ff540000
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@ff540000
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@ff540000
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@ff540000
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@ff540000
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@ff540000
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@ff540000
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@ff540000
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-rockchip
ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@ff540000
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@ff540000
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@ff540000
Config file not found
ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@ff540000
ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@ff540000
=>

 

 

Link to comment
Share on other sites

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

Spoiler

U-Boot 2017.09-armbian (Jun 30 2018 - 11:43:55 +0000)

Model: Pine64 Rock64
DRAM:  510 MiB
MMC:   rksdmmc@ff520000: 0, rksdmmc@ff500000: 1
SF: unrecognized JEDEC id bytes: ff, ff, ff
*** Warning - spi_flash_probe_bus_cs() failed, using default environment

In:    serial@ff130000
Out:   serial@ff130000
Err:   serial@ff130000
Model: Pine64 Rock64
misc_init_r
cpuid=55524b50303630303000000000181b07
serial=41ca158a5bab4cc
Net:   eth0: ethernet@ff540000
Hit any key to stop autoboot:  0 
Card did not respond to voltage select!
mmc_init: -95, time 9
mmc_init: -95, time 1804
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   Core Release: 3.10a
USB3:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning bus 3 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

 

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

Spoiler

U-Boot 2017.09-armbian (Jun 30 2018 - 18:51:49 +0200)

Model: Firefly ROC-RK3328-CC
DRAM:  1022 MiB
MMC:   rksdmmc@ff520000: 0, rksdmmc@ff500000: 1
*** Warning - bad CRC, using default environment

In:    serial@ff130000
Out:   serial@ff130000
Err:   serial@ff130000
Model: Firefly ROC-RK3328-CC
misc_init_r
cpuid=55524b50303630303000000000181b07
serial=41ca158a5bab4cc
Net:   No ethernet found.
Hit any key to stop autoboot:  0 
Card did not respond to voltage select!
mmc_init: -95, time 10
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
2958 bytes read in 31 ms (92.8 KiB/s)
## Executing script at 00500000

 

 

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?

 

Link to comment
Share on other sites

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

 

 

Link to comment
Share on other sites

4 hours ago, TonyMac32 said:

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

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.

Link to comment
Share on other sites

50 minutes ago, constantius said:

There is a renegade.wip


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)

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

15 minutes ago, TonyMac32 said:

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


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

Link to comment
Share on other sites


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

Link to comment
Share on other sites

14 minutes ago, TonyMac32 said:

Strange, since even the U-boot message said Rock64


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

Link to comment
Share on other sites

2 hours ago, 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.

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.

Link to comment
Share on other sites

7 minutes ago, 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.

 

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

8 minutes ago, TonyMac32 said:

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

 

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.

Link to comment
Share on other sites

4 minutes ago, Igor said:

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

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Spoiler

tinymembench v0.4.9 (simple benchmark for memory throughput and latency)

==========================================================================
== Memory bandwidth tests                                               ==
==                                                                      ==
== Note 1: 1MB = 1000000 bytes                                          ==
== Note 2: Results for 'copy' tests show how many bytes can be          ==
==         copied per second (adding together read and writen           ==
==         bytes would have provided twice higher numbers)              ==
== Note 3: 2-pass copy means that we are using a small temporary buffer ==
==         to first fetch data into it, and only then write it to the   ==
==         destination (source -> L1 cache, L1 cache -> destination)    ==
== Note 4: If sample standard deviation exceeds 0.1%, it is shown in    ==
==         brackets                                                     ==
==========================================================================

 C copy backwards                                     :   1569.2 MB/s (0.9%)
 C copy backwards (32 byte blocks)                    :   1582.9 MB/s (0.9%)
 C copy backwards (64 byte blocks)                    :   1586.1 MB/s (0.5%)
 C copy                                               :   1585.5 MB/s (0.6%)
 C copy prefetched (32 bytes step)                    :   1408.4 MB/s (0.5%)
 C copy prefetched (64 bytes step)                    :   1649.0 MB/s
 C 2-pass copy                                        :   1732.5 MB/s
 C 2-pass copy prefetched (32 bytes step)             :   1331.0 MB/s (0.4%)
 C 2-pass copy prefetched (64 bytes step)             :   1261.9 MB/s
 C fill                                               :   6543.0 MB/s (2.8%)
 C fill (shuffle within 16 byte blocks)               :   6533.1 MB/s
 C fill (shuffle within 32 byte blocks)               :   6543.7 MB/s (1.1%)
 C fill (shuffle within 64 byte blocks)               :   6541.1 MB/s
 ---
 standard memcpy                                      :   1542.4 MB/s
 standard memset                                      :   6545.5 MB/s (1.1%)
 ---
 NEON LDP/STP copy                                    :   1758.4 MB/s
 NEON LDP/STP copy pldl2strm (32 bytes step)          :   1445.2 MB/s (0.6%)
 NEON LDP/STP copy pldl2strm (64 bytes step)          :   1647.1 MB/s
 NEON LDP/STP copy pldl1keep (32 bytes step)          :   1825.8 MB/s
 NEON LDP/STP copy pldl1keep (64 bytes step)          :   1835.3 MB/s
 NEON LD1/ST1 copy                                    :   1706.1 MB/s (0.7%)
 NEON STP fill                                        :   6547.4 MB/s
 NEON STNP fill                                       :   2315.8 MB/s (0.7%)
 ARM LDP/STP copy                                     :   1758.3 MB/s (0.8%)
 ARM STP fill                                         :   6535.3 MB/s
 ARM STNP fill                                        :   2316.0 MB/s (0.7%)

==========================================================================
== Framebuffer read tests.                                              ==
==                                                                      ==
== Many ARM devices use a part of the system memory as the framebuffer, ==
== typically mapped as uncached but with write-combining enabled.       ==
== Writes to such framebuffers are quite fast, but reads are much       ==
== slower and very sensitive to the alignment and the selection of      ==
== CPU instructions which are used for accessing memory.                ==
==                                                                      ==
== Many x86 systems allocate the framebuffer in the GPU memory,         ==
== accessible for the CPU via a relatively slow PCI-E bus. Moreover,    ==
== PCI-E is asymmetric and handles reads a lot worse than writes.       ==
==                                                                      ==
== If uncached framebuffer reads are reasonably fast (at least 100 MB/s ==
== or preferably >300 MB/s), then using the shadow framebuffer layer    ==
== is not necessary in Xorg DDX drivers, resulting in a nice overall    ==
== performance improvement. For example, the xf86-video-fbturbo DDX     ==
== uses this trick.                                                     ==
==========================================================================

 NEON LDP/STP copy (from framebuffer)                 :    348.8 MB/s
 NEON LDP/STP 2-pass copy (from framebuffer)          :    339.4 MB/s (0.3%)
 NEON LD1/ST1 copy (from framebuffer)                 :     95.7 MB/s
 NEON LD1/ST1 2-pass copy (from framebuffer)          :     94.7 MB/s (0.3%)
 ARM LDP/STP copy (from framebuffer)                  :    185.0 MB/s
 ARM LDP/STP 2-pass copy (from framebuffer)           :    181.9 MB/s

==========================================================================
== Memory latency test                                                  ==
==                                                                      ==
== Average time is measured for random memory accesses in the buffers   ==
== of different sizes. The larger is the buffer, the more significant   ==
== are relative contributions of TLB, L1/L2 cache misses and SDRAM      ==
== accesses. For extremely large buffer sizes we are expecting to see   ==
== page table walk with several requests to SDRAM for almost every      ==
== memory access (though 64MiB is not nearly large enough to experience ==
== this effect to its fullest).                                         ==
==                                                                      ==
== Note 1: All the numbers are representing extra time, which needs to  ==
==         be added to L1 cache latency. The cycle timings for L1 cache ==
==         latency can be usually found in the processor documentation. ==
== Note 2: Dual random read means that we are simultaneously performing ==
==         two independent memory accesses at a time. In the case if    ==
==         the memory subsystem can't handle multiple outstanding       ==
==         requests, dual random read has the same timings as two       ==
==         single reads performed one after another.                    ==
==========================================================================

block size : single random read / dual random read, [MADV_NOHUGEPAGE]
      1024 :    0.0 ns          /     0.0 ns
      2048 :    0.0 ns          /     0.0 ns
      4096 :    0.0 ns          /     0.0 ns
      8192 :    0.0 ns          /     0.0 ns
     16384 :    0.0 ns          /     0.0 ns
     32768 :    0.1 ns          /     0.1 ns
     65536 :    5.3 ns          /     9.1 ns
    131072 :    8.1 ns          /    12.5 ns
    262144 :   11.1 ns          /    16.6 ns
    524288 :   59.4 ns          /    93.8 ns
   1048576 :   88.7 ns          /   126.3 ns
   2097152 :  104.5 ns          /   139.9 ns
   4194304 :  117.9 ns          /   151.0 ns
   8388608 :  125.6 ns          /   157.5 ns
  16777216 :  130.8 ns          /   162.4 ns
  33554432 :  134.6 ns          /   166.1 ns
  67108864 :  147.2 ns          /   189.3 ns

block size : single random read / dual random read, [MADV_HUGEPAGE]
      1024 :    0.0 ns          /     0.0 ns
      2048 :    0.0 ns          /     0.0 ns
      4096 :    0.0 ns          /     0.0 ns
      8192 :    0.0 ns          /     0.0 ns
     16384 :    0.0 ns          /     0.0 ns
     32768 :    0.1 ns          /     0.1 ns
     65536 :    5.3 ns          /     9.0 ns
    131072 :    8.1 ns          /    12.7 ns
    262144 :   11.0 ns          /    16.6 ns
    524288 :   59.4 ns          /    93.8 ns
   1048576 :   88.7 ns          /   126.2 ns
   2097152 :  103.5 ns          /   138.6 ns
   4194304 :  110.7 ns          /   143.7 ns
   8388608 :  114.4 ns          /   145.9 ns
  16777216 :  116.1 ns          /   147.0 ns
  33554432 :  116.9 ns          /   147.5 ns
  67108864 :  117.3 ns          /   147.7 ns

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

Spoiler

              kB  reclen    write  rewrite    read    reread    read     write     
          102400       1     5756     8859     5920     6248     4938     4678
          102400       4    16137    22192    18109    18139    15328    22350
          102400      16    30712    35262    32439    32496    30135    34529
          102400     512    42981    43903    44643    44719    44737    43834
          102400    1024    43623    43978    44994    45001    44998    44156
          102400   16384    44480    44466    45478    45477    45476    44473

 

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

Link to comment
Share on other sites

1 hour ago, 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

 

Which storage media did you test with iozone?

 

1 hour ago, TonyMac32 said:

tinymembench, since DDR4 and multiple channels are at play

 

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

 

Link to comment
Share on other sites

6 minutes ago, tkaiser said:

Which storage media did you test with iozone?

 

The 32 GB eMMC that can be purchased with one.

 

6 minutes ago, tkaiser said:

Seems like @Da Xue has better settings: 

 

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.

Link to comment
Share on other sites

2 hours ago, TonyMac32 said:

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

 

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

Link to comment
Share on other sites

5 hours ago, TonyMac32 said:

 

5 hours ago, tkaiser said:

 

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.

 

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

Link to comment
Share on other sites

1 hour ago, tkaiser said:

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

 

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.

Link to comment
Share on other sites

9 hours ago, tkaiser said:

The settings we currently use

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.

 

9 hours ago, tkaiser said:

the script doesn't work for whatever reasons

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.

 

22 hours ago, TonyMac32 said:

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

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

Link to comment
Share on other sites

12 minutes ago, JMCC said:
9 hours ago, tkaiser said:

the script doesn't work for whatever reasons

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.

 

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 

 

 

Link to comment
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...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines