Jump to content

gprovost

Members
  • Posts

    580
  • Joined

  • Last visited

Everything posted by gprovost

  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.
  16. 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 }
  17. @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.
  18. Honestly we don't know yet what the root cause of this difference of behavior. Just to say we acknowledge that there are few boards that seems to not show improvement. We are not ignoring the issue and are still looking into it.
  19. That is a valid point you are bringing and actually we did request to some customers to pay attention to this aspect. FYI we decided to make the DC ground connected to AC earth when ordered the AC/DC adapter, which should be the safe and standard approach, but we know many manufacturer don't bother doing it. However if you plug your device on a power extension along other devices you might get impact by the noise of other not well isolated devices. You could try to isolated Helios64 by using for example a travel adapter that would not used the earth pin. Hmmm my expectation would be that the HDD enclosure is connected to the ground of the HDD controller PCB, which in turn is connected via power cable to the ground of the motherboard, which in turn is connected to the ground / eather of the AC / DC PSU.
  20. We will provide soon instruction on how to update SATA controller (JMB585) firmware with the latest version. Let see if it has positive impact or not. For the new revision we will reinforce noise filtering on the SATA controller in case this is part of the root cause in some cases.
  21. Ok that's the correct U-Boot. Hmmm seems to be still stability issue related to the scheduler / DFS. Have you tried to use Performance Schedule ? armbian-config > System > CPU Minimum CPU speed = 1200000 Maximum CPU speed = 1200000 CPU governor = performance
  22. Yes it install the package but doesn't automatically update the bootloader on the target (sdcard or eMMC) For this you will need nand-sata-install -> option 5
  23. @SIGSEGV During boot up, the first messages output on the serial will show if it's U-boot TPL/SPL our Rockchip blob. This is the output with U-boot TPL/SPL U-Boot TPL 2020.10-armbian (Mar 14 2021 - 07:07:37) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB 256B stride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate: change freq to 800000000 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2020.10-armbian (Mar 14 2021 - 07:07:37 +0700) Trying to boot from MMC2 NOTICE: BL31: v2.2(release):a04808c-dirty NOTICE: BL31: Built : 07:07:20, Mar 14 2021 This is the output with Rockchip blob
  24. Sorry didn't see that you needed a like in order to remove the 1 msg / day limitation. Still need to wait 12 hours for it to be lifted. Actually I'm wondering if the U-boot you are using on eMMC is the correct one. Could you post here the early stage boot log of your unit ? You will need serial console connected before you switch on the board.
  25. @dieKatze88 Yes this is already been announced here and there that we will replace the wire harness by a proper PCB backplane. There will still be wire tough connecting the main board to the backplane since we don't want a board that can only be used with a specific backplane. But these wires will be normal SATA cables, so easy to buy new ones anywhere if replacement is needed.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines