Search the Community

Fire219 just got his board and ran a GbE test using ayufan's latest image (only tx-offloading enabled by default) with performance governor. Rock64 (client) --> Thinkcentre (server) [ 4] local 192.168.0.120 port 49148 connected to 192.168.0.85 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 104 MBytes 868 Mbits/sec 0 2.39 MBytes [ 4] 1.00-2.00 sec 108 MBytes 904 Mbits/sec 0 2.39 MBytes [ 4] 2.00-3.00 sec 108 MBytes 902 Mbits/sec 0 2.67 MBytes [ 4] 3.00-4.00 sec 108 MBytes 902 Mbits/sec 0 2.67 MBytes [ 4] 4.00-5.00 sec 105 MBytes 880 Mbits/sec 0 3.63 MBytes [ 4] 5.00-6.00 sec 110 MBytes 921 Mbits/sec 0 3.63 MBytes [ 4] 6.00-7.00 sec 105 MBytes 883 Mbits/sec 0 3.63 MBytes [ 4] 7.00-8.00 sec 110 MBytes 923 Mbits/sec 0 3.63 MBytes [ 4] 8.00-9.00 sec 106 MBytes 891 Mbits/sec 0 5.45 MBytes [ 4] 9.00-10.00 sec 106 MBytes 891 Mbits/sec 0 5.45 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.04 GBytes 896 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 1.04 GBytes 894 Mbits/sec receiver iperf Done. Thinkcentre (client) --> Rock64 (server) [ 4] local 192.168.0.85 port 54468 connected to 192.168.0.120 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 111 MBytes 931 Mbits/sec 0 450 KBytes [ 4] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 0 474 KBytes [ 4] 2.00-3.00 sec 112 MBytes 937 Mbits/sec 0 474 KBytes [ 4] 3.00-4.00 sec 111 MBytes 929 Mbits/sec 0 474 KBytes [ 4] 4.00-5.00 sec 112 MBytes 940 Mbits/sec 0 474 KBytes [ 4] 5.00-6.00 sec 111 MBytes 933 Mbits/sec 0 474 KBytes [ 4] 6.00-7.00 sec 112 MBytes 938 Mbits/sec 0 474 KBytes [ 4] 7.00-8.00 sec 112 MBytes 942 Mbits/sec 0 474 KBytes [ 4] 8.00-9.00 sec 112 MBytes 936 Mbits/sec 0 474 KBytes [ 4] 9.00-10.00 sec 112 MBytes 936 Mbits/sec 0 474 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.09 GBytes 936 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 1.09 GBytes 934 Mbits/sec receiver iperf Done.

@TonyMac32 I have to find out, but iirc it is the same. I did some more test and basic writing/reading with mtd-utils seems to work now, just read back a block after power cycling: root@rock64:/home/rock64# nanddump -l500 -f test.bin /dev/mtd0 ECC failed: 0 ECC corrected: 0 Number of bad blocks: 0 Number of bbt blocks: 0 Block size 4096, page size 1, OOB size 0 Dumping data starting at 0x00000000 and ending at 0x000001f4... root@rock64:/home/rock64# cat test.bin Hello World! I am a SPI Flash! This is a test! root@rock64:/home/rock64#

@zador.blood.stained, thanks, I think this is at least a workaround, since I have no longer garbage on the flash and the kernel doesnt seem to crash anymore: root@rock64:/home/rock64# ubiformat /dev/mtd0 ubiformat: mtd0 (nor), size 16777216 bytes (16.0 MiB), 4096 eraseblocks of 4096 bytes (4.0 KiB), min. I/O size 1 bytes libscan: scanning eraseblock 4095 -- 100 % complete ubiformat: 132 eraseblocks have valid erase counter, mean value is 0 ubiformat: 3526 eraseblocks are supposedly empty ubiformat: 4 corrupted erase counters ubiformat: warning!: 434 of 4096 eraseblocks contain non-UBI data ubiformat: continue? (y/N) y ubiformat: warning!: only 132 of 4096 eraseblocks have valid erase counter ubiformat: erase counter 0 will be used for all eraseblocks ubiformat: note, arbitrary erase counter value may be specified using -e option ubiformat: continue? (y/N) y ubiformat: use erase counter 0 for all eraseblocks ubiformat: formatting eraseblock 4095 -- 100 % complete root@rock64:/home/rock64# sudo ubiattach -m0 [ 653.955360] ubi0: attaching mtd0 [ 656.405192] ubi0: scanning is finished [ 656.445646] ubi0: attached mtd0 (name "spi32766.0", size 16 MiB) [ 656.446297] ubi0: PEB size: 4096 bytes (4 KiB), LEB size: 3968 bytes [ 656.447003] ubi0: min./max. I/O unit sizes: 1/256, sub-page size 1 [ 656.447686] ubi0: VID header offset: 64 (aligned 64), data offset: 128 [ 656.448371] ubi0: good PEBs: 4096, bad PEBs: 0, corrupted PEBs: 0 [ 656.449029] ubi0: user volume: 0, internal volumes: 1, max. volumes count: 23 [ 656.449799] ubi0: max/mean erase counter: 0/0, WL threshold: 4096, image sequence number: 89590605 [ 656.450755] ubi0: available PEBs: 4092, total reserved PEBs: 4, PEBs reserved for bad PEB handling: 0 [ 656.451754] ubi0: background thread "ubi_bgt0d" started, PID 704 UBI device number 0, total 4096 LEBs (16252928 bytes, 15.5 MiB), available 4092 LEBs (16237056 bytes, 15.5 MiB), LEB size 3968 bytes (3.9 KiB) root@rock64:/home/rock64#

Good to hear that ATF built from source works. Did Tl send your Rock64 via EMS?

Replacing the prebuilt rk3328_bl31_v1.34.bin with a custom built bl31.elf from latest upstream ATF source seems to work, and my device have survived past the old ~15-20 minute lockup limit. The generated bl31.bin ends up being 4GiB for some reason, using the bl31.elf instead of bl31.bin as input to the trust_merger tool seems to work. This was tested on a RK3328 tv box as my ROCK64 shipment seems to have been lost in transit :/

My opinion on this board (apart from that I see zero use cases for me): http://www.cnx-software.com/2017/06/30/libre-computers-le-potato-amlogic-s905x-development-board-goes-for-25-and-up-crowdfunding/#comment-543488 It looks like LoveRPi is somewhat involved which is a good sign but Micro USB to power the board is a no-go criteria anyway. Let's see how 'Le Fly' (another ROCK64 competitor) will look like soon but please skip support nightmares. Edit: Now read the Kickstarter page, it must be LoveRPI (since 'ssvb's cpuburn-a53' mentioned).

Ok, I added a flash node inside the spi node for the flash with a driver that should work since the basic flash commands seem to be the same: spi@ff190000 { compatible = "rockchip,rk3328-spi", "rockchip,rk3066-spi"; reg = <0x0 0xff190000 0x0 0x1000>; interrupts = <0x0 0x31 0x4>; #address-cells = <0x1>; #size-cells = <0x0>; clocks = <0x2 0x20 0x2 0xd1>; clock-names = "spiclk", "apb_pclk"; dmas = <0xb 0x8 0xb 0x9>; #dma-cells = <0x2>; dma-names = "tx", "rx"; pinctrl-names = "default"; pinctrl-0 = <0x30 0x31 0x32 0x33>; status = "okay"; w25q128@0 { #address-cells = <0x1>; #size-cells = <0x0>; compatible = "winbond,w25q128", "jedec,spi-nor"; reg = <0x0>; spi-max-frequency = <40000000>; status = "okay"; }; }; That gives me: rock64@rock64:~$ dmesg | grep spi [ 1.172285] m25p80 spi32766.0: w25q128 (16384 Kbytes) rock64@rock64:/dev$ mtdinfo Count of MTD devices: 1 Present MTD devices: mtd0 Sysfs interface supported: yes rock64@rock64:/proc$ sudo flash_erase /dev/mtd0 0 0 Erasing 64 Kibyte @ ff0000 -- 100 % complete rock64@rock64:~$ sudo dd if=/dev/mtd0 of=test.bin status=progress 16642560 bytes (17 MB, 16 MiB) copied, 30.0011 s, 555 kB/s 32768+0 records in 32768+0 records out 16777216 bytes (17 MB, 16 MiB) copied, 30.4636 s, 551 kB/s So I guess something works... Edit: The MTD device hangs at random points during write/read operations, I tried to create an ubi volume for testing purposes, but formatting the flash just hangs during the process... root@rock64:/home/rock64# ubiformat /dev/mtd0 ubiformat: mtd0 (nor), size 16777216 bytes (16.0 MiB), 4096 eraseblocks of 4096 bytes (4.0 KiB), min. I/O size 1 bytes libscan: scanning eraseblock 4095 -- 100 % complete ubiformat: 1 eraseblocks are supposedly empty ubiformat: warning!: 4095 of 4096 eraseblocks contain non-UBI data ubiformat: continue? (y/N) y ubiformat: warning!: only 0 of 4096 eraseblocks have valid erase counter ubiformat: erase counter 0 will be used for all eraseblocks ubiformat: note, arbitrary erase counter value may be specified using -e option ubiformat: continue? (y/N) y ubiformat: use erase counter 0 for all eraseblocks ubiformat: formatting eraseblock 477 -- 11 % complete I tried to reduce SPI clock to 25Mhz bus still hangs at random points...

And it continues: https://forum.odroid.com/viewtopic.php?f=146&t=26016&start=200#p194654 Another user reports general XU4 USB3 receptacle issues as 'UAS problems' for unknown reasons. The symptoms are exactly those user @Kosmatikreported with his defective Cloudshell 2 cable when blacklisting UAS (see two quoted links above). So if @joaofl would really use UAS he would run in the same errors but this time of course not having reset SuperSpeed USB device number 3 using xhci-hcd in the logs but various occurences of 'uas_eh_abort_handler' and 'uas_zap_pending' (same problem, different driver --> different dmesg output). What do we see happening in is this funny micro community creating their own micro reality over there? A user not using UAS reporting an XU4 problem (USB3 receptacle troubles) gets the recommendation to 'DIsable UAS'. And at the same time the usual suspects still run their insanely stupid 'UAS is broken in Linux everywhere' campaign in ODROID forum. Why I'm mentioning this? Since situation with ROCK64 is very promising also in this area. We're currently in touch with Rockchip engineers since I reported UAS trouble regarding 'ERROR Transfer event for disabled endpoint or incorrect stream ring' --> http://sprunge.us/HURC A Rockchip engineer almost immediately confirmed being able to reproduce (only with RK3328 but not RK3399 -- same xHCI host controller as RK3328 but different USB3 PHY). Currently they're buying USB-to-SATA bridges we recommended for testing and I hope to be able to soon report some progress.

I am just trying to see if I can set up the SPI flash on the Rock64 as an mtd(block) device. I enabled the SPI node in the dts and made a new kernel with mtd layer enabled. Now I have to see what else is needed. It looks like I need to either describe the flash in devicetree or pass that info to the kernel on boot... has anyone before configured an SPI flash as mtd device?

Thank you for that. That's a great move into the right direction but why so late? You have a repo with code and hardware documentation (device tree files are essentially just that) since over 4 months now and with this commit here (24 Feb: 'add mt7623n-bpi-r2.dts for bpi-r2') you would've immediately had to open the Github repo if you would take 'OPEN SOURCE' seriously (at least the software part, nobody expects from you doing 'open source hardware' even if you claim this again and again for no reason). Doesn't it look absolutely stupid if you're claiming doing 'OPEN SOURCE' all day long when we as community have to waste insane amounts of time poking you again and again just to get you OPENING SOURCES?! Ok, looked quickly in the repo (looks a bit strange since structure of an Allwinner BSP while this is MTK stuff) but I checked it out and running build.sh created successfully u-boot/kernel archives (log). So what's next? Your usual approach is now combining the created archives containing bootloader, kernel and modules with one of your many rootfs (Raspbian, Ubuntu, this and that). All your OS images are essentially the same just with exchanged bootloader/kernel without any device specific tweaks. All these rootfs suffer from suboptimal settings which lead to poor performance and even strange behaviour. For example your Ubuntu rootfs still enables Ubuntu's unpatched irqbalanced which is plain stupid on ARM since this daemon does nothing useful but due to a memory leak only eats up all available DRAM over time until the board finally crashes after weeks/months depending on DRAM size. Breaking news? No, 'told you so'! Many, many times (do a web search for 'irqbalanced site:forum.banana-pi.org', we told you also in your old forum below bananapi.com:80/index.php/forum which you shut down last year being responsible for destroying a lot of information/knowledge collected/developed by YOUR OWN COMMUNITY). Why is that? Since you installed a perfect way to be cushioned against anything that happens outside. Talking to the guy known as 'sinovoip bpi team' in your forum is like talking to a wall. The level of ignorance there is unbelievable high and also the reason why there's no 'vendor community' existing and everything has to happen outside of your territory. Care to remember how software support situation evolved with R1? At the end of 2014 you started to sell a paperweight with no useable OS images, incorrect/missing information/specifications, no schematics released. All work has been done by community with you actively hindering community trying to do your work. It took you one and a half years to provide first working OS images in summer 2016 relying on Armbian's build system, settings and tools. In the meantime all users had no other choice than using either Bananian, Armbian or David Bentham's OpenWRT. This will not happen again even if you're enthusiastic now about 'try to get support from community'. Why/how community should support you? You ignore suggestions, you ignore support requests, you ignore community telling you where information/specification are wrong, you don't provide correct information (please look at this insane BS you collected below https://bananapi.gitbooks.io/bpi-m2-ultra-open-source-single-board-computer/content/allbananapiproduct.html), you refuse to release schematics and sources (timely). It needs insane amounts of efforts and time for community to get even most basic stuff from you EVERY TIME you release something new. That's the reason why almost every part of open source community already gave up on you. Since most importantly you even fail to understand what's happening (ignorance). That's the real problem (maybe it's just the filter you installed in form of your official voice known as 'sinovoip bpi team'). Back to the basics. I asked 9 days ago for 3 simple things: http://forum.banana-pi.org/t/bpi-r2-ubuntu-16-04-with-kernel-4-4-70-function-test/3393/8 'release schematics as early as possible': 5 days ago you delivered, that's not entirely 'as early as possible' but great! 'release sources (release early, release often)': Delivering few hours ago after being poked way too many times is neither early nor often but... great! You did it! 'start to write technical documentation': what about hiring someone who is able to do so? I know you even wanted to pay for community support but this CAN NOT WORK based on this insane mess you create. It's impossible to support you if you fail to provide correct information/specification. So I hope in a few weeks you also address this problem which simply would be great! And then also please try to address the mess in your forum (especially censorship happening -- every occurence documented BTW -- that will successfully prevent people sharing knowledge there since they know that it gets deleted due to your staff behaving absolutely stupid. For example this guy will never be told how to use hdparm command). I could now elaborate lengthy how much fun it was yesterday to improve network settings for ROCK64, identifying problems and possible tweaks and improving network throughput from 150 Kbits/sec to 942 MBits/sec while at the same identifying what's still missing and what we need from the hardware vendor. I save you from this but it's basically having correct information/specifications, not always talking to a wall, sources available. Please try to improve and stop behaving like a brain damaged retard. You can do! Thanks.

I fixed that one and there might be one or two with the same problem. I don't recall to do more of such adjustments. Edit: we mixed this link too Don't know how to fix. @pfeerick don't worry. You didn't know and I also forgot to note you about those problems / features. https://blog.hackster.io/first-thoughts-on-the-new-rock64-board-f994fd3a04c4

How good does the GbE interface on Tinkerboard work? On Rock64 there are big variances in GbE performance atm, but we have not tuned anything yet...

Another update wrt upcoming ROCK64 board. It's still not decided whether Armbian will support this board anytime soon or at all but NAS results already look promising. USB3 performance is excellent (outperforming ODROID-XU4 easily) but currently we have discovered a few network issues while testing/evaluating the board (most probably we need to tweak so called TX/RX GbE delay settings). But even without this tweak it already looks as follows: These are the 'Enterprise network settings' (test size is 3GB and transmission block size 1MB): These are 'Gigabit Ethernet' settings with just 300 MB filesize and 128KB blocksize: It's pretty obvious that there's something wrong with network settings when we look at the sequential transfer speeds. Just compare with Pine64 above where USB2 storage is the bottleneck: there the test with 300 MB filesize runs entirely in RAM and Pine64 scores 66/78 MB/s write/read, with the Enterprise settings speeds drop down to storage performance: ~38MB/s in both directions. With ROCK64 all tests run entirely in RAM (I test with the 4GB model) and there's a significant drop in transfer speeds if we compare 1MB with 128KB blocksize. My settings (TCP/IP offloading deactivated, eth0 IRQs on cpu3, USB3 IRQs on cpu2, performance governor, Receive Packet Steering enabled): root@rock64:~# tail /etc/rc.local echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor for i in 1 2 3 ; do echo 4 >/proc/irq/$(awk -F":" "/xhci/ {print \$1}" </proc/interrupts | sed 's/\ //g')/smp_affinity echo 8 >/proc/irq/$(awk -F":" "/eth0/ {print \$1}" </proc/interrupts | sed 's/\ //g')/smp_affinity done echo 7 >/sys/class/net/eth0/queues/rx-0/rps_cpus echo 32768 >/proc/sys/net/core/rps_sock_flow_entries echo 32768 >/sys/class/net/eth0/queues/rx-0/rps_flow_cnt exit 0 root@rock64:~# cat /etc/network/interfaces.d/eth0 allow-hotplug eth0 iface eth0 inet dhcp offload-tx off offload-rx off hwaddress ether 42:40:08:16:da:2b The good news: This all is still WiP (work in progress) and I'm pretty confident that we see a performance boost in both directions soon (15-20 MB/s more each -- with Windows Explorer throughput numbers exceeding 100 MB/s should already be possible with appropriate OMV/Samba settings -- see here for an example and here for an explanation why Explorer performs better)

Ayufan currently uses the partitioning scheme that is created by the https://github.com/rockchip-linux/build system too... (https://github.com/ayufan-rock64/linux-build/releases)

Thank you for confirming! In other words: you totally missed what's that all about. I was talking about current situation (everyone with commit rights to Armbian repo decides on his own when to start supporting a new board) and I proposed a change to that. A developer (not forum moderator) wanting to add support for a new board should requires him to outline the reasons why he wants to support a new board and which level of support he thinks the device deserves collects available resources so other devs save some time so they don't have to search the net first weighs pros/cons from both a developer and 'average Armbian user' perspective And the main reason to start with something like that is not to ease board bring up BUT EXACTLY THE OPPOSITE! Establish a process/protocol a dev has to follow that requires at least some thoughts why it's worth the efforts especially if we should decide that the board deserves full support status later. And you're asking for templates! You can't substitute the results of using your brain with templates (same with this boilerplate BS you're constantly recommending to me). It's all about understanding/consensus and nothing can be handled with templates (that's why I titled the ROCK64 thread with 'Example' since it could look like this if another dev wants to propose adding a new board but of course it can also look like this depending on the thoughts and what the purpose is) You calling yourself the agile sprint type (the 'doer') most probably won't notice that running in the wrong direction isn't really smart (same with you having the ability to edit posts -- a person who doesn't even get why there is something written should really never ever edit stuff. Same with your personal reaction to this -- again a proof that you've not the slightest idea what's going on!) For the others: We could have another 'SD card was the issue' result: https://organicmonkeymotion.wordpress.com/2017/06/25/setup-for-house-server/ And zero responses to 'preventing boards to boot when rootfs is read-only and executing cpuburn-a7 or cpuburn-a53 as part of firstrun crashing/freezing underpowered boards' reminds me why I consider this babbling here a waste of time.

I was refering to this https://forum.armbian.com/index.php?/topic/4578-example-support-proposal-for-rock64/ and maybe in the same thread or another where we were discussing about improvements - could have been nightly. Any way, was just an example

Woohoo! Nice to know it will that easy... my chinglish android eEMMC install might die a sudden death now and be reborn with linux... after a backup, of course! I still find the android OS handy for usage as dumb TV box! This is the pinout document for the rock64 - hopefully it's all correct! The boot sequence on the RK3328 is external eMMC, SPI Nor Flash, SPI Nand Flash(not fitted to rock64), external SDMMC card, USB (FEL/OTG). So unfortunately eMMC before SD I hate to ruin my uptime of 1 day, 4:16, 2 users, load average: 0.00, 0.00, 0.00, but needs must. I usually use the eMMC jumpter to boot from the SD instead of the eMMC, but I just unplugged the eMMC, removed the jumper, and tried a clean boot of the rock64, and it's up again, so I'm not sure what's going in with yours not booting when you have the eMMC removed and not booting from the microSD. This is with the 2GB model. As far as the partition layout, mine (running 0.2.0) is:

Now, my trouble is that I don't know the root password ... EDIT : I've find it on Release page : rock64/rock64

I use the minimal image atm from ayufan's github repo and that works so far, I have removed the eMMC module from the board atm. https://github.com/ayufan-rock64/linux-build/releases/download/0.2.1/xenial-minimal-rock64-0.2.1-29-armhf.img.xz The partition scheme comes right out of the rootfs build scripts from RK...

You can at least change u-boot and kernel (see https://github.com/ayufan-rock64/u-boot/commit/924a2efc7939cdbfc075e1124ad417dd7e15ed2e) but the miniloader always talks 1.5Mb...

@Xalius, do you know if the debug serial on those Rock64 should be UART2 (pin 8 and 10) on header ? Using either mate or minimal 0.2.1 images, I've only got few garbage characters and nothing else. I presumed it should be at 115200. Maybe the board I've received doesn't work at all ...

I have a short update on the latest patches RK sent to BSP upstream. As of this morning we have a Rock64 image that doesnt lock up anymore after 20 minutes and ayufan found a hotfix for the GbE issues by turning off tx-offloading (no TX/RX paramters tuned yet) and that seems to work well at least for him (930Mbit both directions) with one CPU core loaded since integrity calculations are now done on the CPU. Currently we boot the 2GB and 4GB with one firmware loader at 768Mhz DRAM frequency. The u-boot patches to autodetect DRAM size seem to work so far, havent heard back from someone with a 1GB board yet. RK also should push a DRAM init blob for 933Mhz soon... https://github.com/ayufan-rock64/linux-build/releases - new images and deb packages for system upgrade

Yeah I am following the mainlining process for some time now, and some new things went into 4.12.x , we'll see at what pace that continues. As for the documentation there are only the datasheets (SOC+RK805), Part 1 of the user manual and the schematics right now. Tl is trying to get the Part 2 of the user manual released, but I am not sure what is actually in there. RK just today provided some more patches for the 4.4.x BSP, maybe the Rock64 can now stay up longer than 20 minutes :-) On the hardware front Tl was looking for last suggestions regarding schematic changes or board layout changes, I think the plan is to go into production as soon it is confirmed that 933Mhz DRAM works on all three (1/2/4GB) variants... @TonyMac32 I can ask Tl if he can send you a board sample if you like

Speaking of vendors changing hardware, we have Beelink X2 listed as a "supported" device even though if I remember correctly they changed wireless chip model in later revisions. Getting back on topic, I received the Rock64 some time ago (thanks TL Lim), but current software situation to me looks like "blobs, blobs everywhere" + not a lot of low-level documentation + not a lot of mainlining progress, so I probably won't try to integrate it in Armbian for some time.

By the way, I'm for support of rk3328 Rock64. I already use Armbian ubuntu on amlogic s905x tv box Nexbox A95x. It's great, it works well. Friends have a shock :-)