TonyMac32 Posted June 30, 2018 Posted June 30, 2018 I own the board, give me some time to get it set upSent from my Pixel using Tapatalk 1 Quote
TonyMac32 Posted June 30, 2018 Posted June 30, 2018 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 => 0 Quote
JMCC Posted June 30, 2018 Posted June 30, 2018 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? 0 Quote
TonyMac32 Posted June 30, 2018 Posted June 30, 2018 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 Quote
JMCC Posted June 30, 2018 Posted June 30, 2018 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. 0 Quote
constantius Posted July 1, 2018 Posted July 1, 2018 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 Quote
Igor Posted July 1, 2018 Author Posted July 1, 2018 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) 0 Quote
TonyMac32 Posted July 1, 2018 Posted July 1, 2018 @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 Quote
Igor Posted July 1, 2018 Author Posted July 1, 2018 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) 0 Quote
TonyMac32 Posted July 1, 2018 Posted July 1, 2018 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 Quote
Igor Posted July 1, 2018 Author Posted July 1, 2018 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. 0 Quote
Staars Posted July 1, 2018 Posted July 1, 2018 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 Quote
JMCC Posted July 1, 2018 Posted July 1, 2018 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. 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 Quote
TonyMac32 Posted July 1, 2018 Posted July 1, 2018 I think it is the patches in the wrong subfolder as mentioned earlier. I'll check it out nowSent from my Pixel using Tapatalk 0 Quote
Igor Posted July 1, 2018 Author Posted July 1, 2018 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. 3 Quote
TonyMac32 Posted July 1, 2018 Posted July 1, 2018 4 minutes ago, Igor said: Yes. Fixed. Says Igor clone #4, apparently. I couldn't make it into my basement and start an SSH session before he fixed it... ;-) 1 Quote
JMCC Posted July 1, 2018 Posted July 1, 2018 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. 0 Quote
Igor Posted July 1, 2018 Author Posted July 1, 2018 1 hour ago, JMCC said: in case you are not going to restore the download link for Renegade Restored. 2 Quote
switch Posted July 1, 2018 Posted July 1, 2018 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 Quote
TonyMac32 Posted July 1, 2018 Posted July 1, 2018 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 Quote
TonyMac32 Posted July 2, 2018 Posted July 2, 2018 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 0 Quote
tkaiser Posted July 2, 2018 Posted July 2, 2018 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/ 0 Quote
TonyMac32 Posted July 2, 2018 Posted July 2, 2018 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. 0 Quote
tkaiser Posted July 2, 2018 Posted July 2, 2018 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)? 0 Quote
tkaiser Posted July 2, 2018 Posted July 2, 2018 5 hours ago, TonyMac32 said: 5 hours ago, tkaiser said: Seems like @Da Xue has better settings: https://forum.armbian.com/topic/6772-tinymembench-on-renegade-roc-rk3328-cc-1gb/ 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 0 Quote
tkaiser Posted July 2, 2018 Posted July 2, 2018 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. 0 Quote
JMCC Posted July 2, 2018 Posted July 2, 2018 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. 0 Quote
JMCC Posted July 2, 2018 Posted July 2, 2018 9 hours ago, tkaiser said: the result was switching from 1024 timing to 1066 Are you aware of this change? It's also in my possible tweaks checklist. I'll get into it once I get past the read-only filesystem problem. 0 Quote
chwe Posted July 2, 2018 Posted July 2, 2018 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.. 0 Quote
Recommended Posts
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.