gprovost

  • Posts

    580
  • Joined

  • Last visited

4 Followers

Profile Information

  • Gender
    Male
  • Location
    Singapore

Contact Methods

  • Website URL
    http://kobol.io

Recent Profile Visitors

9717 profile views

gprovost's Achievements

  1. Please contact support at support@kobol.io for such issue.
  2. Please contact support at support@kobol.io
  3. @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
  4. @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
  5. 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.
  6. https://forum.armbian.com/topic/17772-kobol-team-is-taking-a-short-break/
  7. 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 a long way to go compared to NXP, Marvell, etc... but I think Chinese SoC manufacturer has finally understood that for a wider adoption (beside TV set-up box) they will need to put more emphasis on documentation and SDK. Thanks. Yes I'm sure we are unfortunately all wear down by the previous year and 2021 is not really giving us a break either.
  8. 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 prices surge and crazy lead time, it’s even harder to have business visibility in an already challenging market. In light of the above, we decided to go on a full break for the next 2 months, to recharge our battery away from Kobol and come back with a refocused strategy and pumped up energy. Until we are back, we hope you will understand that communication on the different channels (blog, wiki, forum, support email) will be kept to a minimum for the next 2 months. Thanks again all for your support.
  9. 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.
  10. You can change the settings in /etc/default/armbian-zram-config Maybe the default settings are effectively overkill with 4GB of RAM.
  11. 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.
  12. 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(cbc(aes),sha256) driver : essiv(cbc(aes-generic),sha256-generic) module : essiv priority : 100 refcnt : 1 selftest : passed internal : no type : skcipher async : no blocksize : 16 min keysize : 16 max keysize : 32 ivsize : 16 chunksize : 16 walksize : 16 [...] name : cbc(aes) driver : mv-cbc-aes module : marvell_cesa priority : 300 refcnt : 1 selftest : passed internal : no type : skcipher async : yes blocksize : 16 min keysize : 16 max keysize : 32 ivsize : 16 chunksize : 16 walksize : 16
  13. 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.
  14. 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.
  15. @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 fix that in next revision. We will see if the new SATA controller firmware has any impact but we doubt that. I think the only solution for current revision is to limit ATA speed to 3Gbps when using btrfs or zfs.