• Content Count

  • Joined

  • Last visited

About ejolson

  • Rank

Recent Profile Visitors

613 profile views
  1. I found the file rk3328_ddr_400MHz_v1.16.bin at https://github.com/rockchip-linux/rkbin/...r/bin/rk33 which mitigates the performance loss a little bit compared to the 333 MHz setting. Stability still seems fine.
  2. This is a followup post to to confirm that the Rock64 board that was experiencing segmentation faults with the default 786 MHz memory clock on Armbian is now stable with the uboot-initialized 333 MHz setting. On a selection of computational benchmarks performance is about 77 percent of the original setting; for compilations with gcc more than 80 percent of the original performance is retained with the added advantage that the system doesn't crash and the compiler doesn't create segmentation faults. As far as I'm concerned this problem is solved and I'll try to mark it as such. Al
  3. Here is a performance comparison between the original 786MHz memory clock and the reduced 333MHz clock when running John McCalpin's stream memory bandwidth benchmark. The performance reduction for the scale operation was measured to be about 2.26 times which is slightly less than the expected 786/333=2.36 factor loss expected by just dividing out the clocks. In real world applications much of this performance reduction might be mitigated by cache memory; however, it would seem having a 600MHz setting might be a better compromise between super slow and super unstable.
  4. It seems patching the SD card is not very difficult. I downloaded rk3328_ddr_333MHz_v1.16.bin rk3328_miniloader_v2.46.bin Then I followed the instructions on http://opensource.rock-chips.com/wiki_Boot_option typed as root # mkimage -n rk3328 -T rksd -d rk3328_ddr_333MHz_v1.16.bin idbloader16.img # cat rk3328_miniloader_v2.46.bin >>idbloader16.img # dd if=idbloader16.img of=/dev/mmcblk0 seek=64 conv=notrunc # sync and then rebooted. I'll report back later how much slower everything is later and whether the
  5. My understanding is that this is a common problem with the Rock64 v2 boards and simply the result of some optimistic overclocking that should never have been done in the first place. While such overclocking appears to be necessary to meet the minimum performance needed for playing back certain high-definition video, my usage for the Rock64 is not watching television but for it to function as a computer. This is essentially a new board that sat in storage for six months due to certain shelter at home rules. As returning it is not an option, I would instead like to reduce the memor
  6. I have two Rock64 single-board computers running Focal Fossa. One is stable and the other gets segmentation faults when compiling and sometimes a kernel oops. After some searching, my understanding is this can be fixed by slowing down the memory speed by installing rk3328_ddr_333MHz_v1.13.bin from the ayufan-rock64 GitHub repository into uboot along with possibly rk3328_miniloader_v2.46.bin as well. Unfortunately, I'm clueless how to do this. I'm running the latest Armbian Focal Fossa Server from August 19 with the 5.7.17 kernel. Do I need to build a new image or can I patch an
  7. Woohoo! It worked. I now have wireguard installed and an iSCSI block device mounted over wireguard with a swap partition and a big /usr/local and my home directory. I'll report some performance results soon. Thanks!
  8. Thanks for your reply. Sorry for starting this thread after the one of the FriendlyARM website. It took me a long time before figuring out that iSCSI support was missing from the kernel. It seems the errors produced by iscsid and systemd are not very clear what's wrong--probably the wrong logging level somewhere. At any rate, after a day and a half of installing Ubuntu in a QEMU session and running the suggested build script on my local desktop (an dual-core AMD A6-5400K APU), I have the files armbian-config_20.05.0-trunk_all.deb armbian-firmware_20.05.0-trunk_all.deb armbian-firm
  9. I am trying to set up Armbian as an iSCSI initiator using open-iscsi. The result is Mar 15 03:07:13 matrix iscsid[2207]: iSCSI logger with pid=2208 started! Mar 15 03:07:13 matrix systemd[1]: iscsid.service: Failed to parse PID from file /run/iscsid.pid: Invalid argument Mar 15 03:07:13 matrix iscsid[2208]: iSCSI daemon with pid=2209 started! Mar 15 03:07:13 matrix iscsid[2208]: can not create NETLINK_ISCSI socket Mar 15 03:08:43 matrix systemd[1]: iscsid.service: Start operation timed out. Terminating. Mar 15 03:08:43 matrix systemd[1]: iscsid.service: Failed with result 'timeout'.
  10. I can partially confirm your claim that 12 Gflops is possible with a more efficient heatsink+fan. In particular, I'm currently testing the M3's bigger brother the FriendlyArm NanoPi T3 which has the same 8-core SOC but a different heatsink. Following the same build_instructions, I obtained 12.49 Gflops with version 2.2 of the linpack benchmark linked against version 0.2.19 of the OpenBLAS library. My cooling arrangement looks like this. With the cover on the heat is trapped and the system throttles; however, upon removing the cover and due to the giraffe the system runs at full spe
  11. These concerns are why I have asked here if any one has one, how it works and whether they can run any benchmarks. I agree that heatsinks with fans are likely required for any parallel algorithm scaling studies. The CPU in the Banana Pi M3 and the pcDuino8 contain v7 cores. The improved floating point/NEON hardware of the v8 cores in the NanoPi M3 are preferable for numerical work. The work stealing algorithms used by the Cilk programming language should balance loads fairly well on the big.LITTLE architecture. At the same time all cores the same is better. At anyrate, maybe someone
  12. It is definitely possible to introduce parallel processing with a quad core. My thread on the Raspberry Pi forum discusses compiling new versions on gcc with support for the MIT/Intel Cilk parallel programming extensions on ARM devices. The compiler is tested with parallel algorithms for sorting, prime number sieves, fast Fourier transforms, computing fractal basins of attractions for complex Newton methods, numerical quadrature and approximating solutions to high-dimensional systems of ODEs. It is of practical interest how well the implementation of each algorithm scales on physical ha