gprovost

  • Content Count

    578
  • Joined

  • Last visited

4 Followers

About gprovost

  • Rank
    Embedded member

Profile Information

  • Gender
    Male
  • Location
    Singapore

Contact Methods

  • Website URL
    http://kobol.io

Recent Profile Visitors

8665 profile views
  1. @hartraft Yeah you could try to update the uboot on the microSD card using your spare linux computer.(Note: This can mess up your sdcard if you do it wrongly) You will need again to mount the microSD. cd <sdcard-mount>/usr/lib/linux-u-boot-current-helios64* dd if=idbloader.bin of=<sd-card device> seek=64 conv=notrunc dd if=uboot.img of=<sd-card device> seek=16384 conv=notrunc dd if=trust.bin of=<sd-card device> seek=24576 conv=notrunc where <sd-card device> is something like /dev/mmcblk1
  2. @hartraft Could you modify /boot/armbianEnv.txt and add/modify following lines: verbosity=7 console=serial extraargs=earlyprintk ignore_loglevel If you are booting from eMMC, you will need to first boot from a fresh image on microSD, then mount the eMMC to modify /boot/armbianEnv.txt
  3. Maybe check if on Infuse app has some settings to tweak the caching. Did you check on Helios64 if something is happening while streaming those MP4 file ? (use dmesg -w to see if anything wrong happen). You could also try with the 1GbE (eth0) interface this way you can narrow down the issue.
  4. https://forum.armbian.com/topic/17772-kobol-team-is-taking-a-short-break/
  5. The main rational is that we wanted to offer ECC as soon as possible and don't want to wait for RK3588 that has been delayed for quite a while. BTW RK3568 supports 8GB RAM. Since it's not the best time currently to manufacture electronic consumer product, we thought it was an opportunity to already do a refresh of the design which would already answer most of the feature requests listed in the other thread. Doesn't mean we will ignore RK3588 in a later stage. I think Rockchip is making an effort at each new SoC to get better and better at software support. There is sill
  6. It’s been 3 months since we posted on our blog. While we have been pretty active on Armbian/Kobol forum for support and still working at improving the software support and stability, we have been developing in parallel the new iteration of Helios64 around the latest Rockchip SoC RK3568. However things haven’t been progressing as fast as we would have wished. Looking back, 2020 has been a very challenging year to deliver a new product and it took quite a toll on the small team we are. Our energy level is a bit low and we still haven’t really recovered. Now with electronic part price
  7. There are few more brands offering 5 ports 2.5GbE network switch. Most likely they are all based on the same exact network chip. 2.5GbE doesn't require any special high quality component, so my guess it's the build quality is more or less the same of all those models. So end of the day you are just buying the name among all those 5x port 2.5Gbe models. You could also consider maybe a switch with more ports even though some of them might only be 1Gbps. But if you don't have the need for more ports, then any model you listed will do the job.
  8. You can change the settings in /etc/default/armbian-zram-config Maybe the default settings are effectively overkill with 4GB of RAM.
  9. Hi, Yes it's not a problem at all. Both connectors are actually connected to the same power rails, so there is no difference between the 2. The reason we put 2 connectors was to be sure we don't exceed max power rating of the Molex pin, but honestly it was a bit overkill. So technically you could also not bother and just use one of the 2x connectors instead of both.
  10. I observe the same behavior. It seems to be linked to the introduction of the ESSIV kernel module in Linux Kernel 5.4 When creating and opening a new LUKS2 device, I can still see the interrupt of the crypto engine increasing. However when exercising the mounted encrypted device I don't see anymore increase of interrupt. What I realized is that there is this module essiv that get loaded and it seems to suggest it bypass the CESA crypto engine. We need to find a way to force dm-crypt to use marvell_cesa root@helios4:~# cat /proc/crypto name : essiv(c
  11. The issue with our Factory Acceptance Test (FAT) we mentioned was related to PCIe link training. It took us a bit of time to realize that the PCIe device (SATA controller) was getting reset by software twice at boot instead of once which was causing sometimes the SATA controller to fail the link training sequence... therefore failing the FAT test. It's completely unrelated to DFS problem and what fixed within days.
  12. Yes sorry about the lack of centralized news on that stability improvement effort. We don't want to confuse people by posting things when the effort is still ongoing, and that we still don't have a clear understanding why the instability issue only impact some of the boards. It is not an issue that impact all rk3399 boards. However same problems is impacting the NanoPi M4V2, and it's thanks to @piter75 work on the NanoPi that Helios64 stability has improved. Are you running from eMMC or SDcard ? Can you share some crash logs.
  13. @Fred Fettinger Your errors are most likely due too a not stable HDD harness. You can contact us to support@kobol.io to see if replacement of the HDD wire harness is needed. @ShadowDance Thanks for the feedback and at least we can remove grounding issue from the list of possible root causes. Looks like that in the use case of very heavy HDD I/O load arising mainly during scrubbing operation too much noise is generated resulting in those HSM violation. Thanks to all your tests, the issue seem unfortunately to point to noise filtering issue. As previously mentioned, we will
  14. I don't understand how this ended up in your armbianEnv.txt file but clearly the following lines (which are log rotate configuration) shouldn't be there and could mess up your boot. /var/log/alternatives.log { monthly rotate 12 compress delaycompress missingok notifempty create 644 root root }
  15. @dieKatze88 You can setup the highest frequency and the outcome will be most likely the same. The issue is not the frequency speed, is the Dynamic Frequency Scaling (DFS) which constantly change the cpu freq and it seems to create some instability. I recommended 1.2 GHz just to insure the system run cool therefore minimizing fan noise.