gprovost
-
Posts
580 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by gprovost
-
-
Please contact support at support@kobol.io
-
@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
-
-
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.
-
-
34 minutes ago, barnumbirr said:
I wonder what the rationale is for going with the 4-core RK3568 and still limited to 4GB of RAM instead of the 8-core RK3588 that can support up to 32GB of RAM.
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.
22 minutes ago, Igor said:It is hard to predict more without deep investigation, but users / buyers expect top notch SW support and are willing to pay nothing for that. But someone has to pay that bill. Costs of software support is enormous, much bigger than HW design and that fact doesn't allow such products to happen. That is certainly not fault of a few people that tries to create a wonderful new hardware or folks that supports users on a voluntary basis.
Even with reasonable well supported many years old RK3399 problems are still present in greater way we all would like.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.
16 minutes ago, Igor said:Wish you fast recovery. I also need that
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.
-
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.
-
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.
-
You can change the settings in /etc/default/armbian-zram-config
Maybe the default settings are effectively overkill with 4GB of RAM.
-
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.
-
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 -
14 hours ago, snakekick said:
"Our test successful rate is not as high as we expected. It turned out that our FAT software was a bit too strict resulting in some board failing the FAT while they are actually OK"
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.
-
19 hours ago, Vin said:
I know you are a small team and you had to takle many obstacles to release the Helios64, believe me im a fan of your work, product and armbian in general, i m aware of the effort every involved person puts into this project.
But i would appreciate a bit more news about the current status of developement.
As far as i can see there is no status or developement overview on the current issues, not on your blog nor on twitter.
The only information we get are in various topics across the forum on armbian.
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.
19 hours ago, Vin said:Also I wonder if those issues are genreal rk3399 gonvernor etc. problems, or if it applies specifically for the Helios64?
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.
19 hours ago, Vin said:Mine is still crashing like a clockwork every 24 hours and leaves me generally with a corrupted OS and data.
Are you running from eMMC or SDcard ?
Can you share some crash logs.
-
@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.
-
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 } -
@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.
-
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.
-
On 3/26/2021 at 5:05 PM, ShadowDance said:
My Helios64 PSU is not connected to a grounded wall-outlet. Unfortunately here in my apartment there are only two such outlets in very inconvenient places, but I'll see if it's feasible to test it out on that one. Perhaps this introduces noise into the system? Perhaps other devices are leaking their noise via grounded extension cord (I recently learned that using a grounded extension cord on a non-grounded outlet is not ideal, hadn't even thought to consider it before...
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.
On 3/26/2021 at 5:05 PM, ShadowDance said:I read somewhere that the metal frame of the HDD cases should be connected to device ground, but since we're using plastic mount brackets I doubt this is the case? To be honest I don't know if this is a real issue or not, just something I read on a forum.
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.
-
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.
14 hours ago, ShadowDance said:perhaps there's a noise-factor in play (as well).
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.
-
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
-
1 hour ago, SIGSEGV said:
From the looks of it - Armbian 21.02.03 seems to install the Rockchip Blob.
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
-
@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 2021This is the output with Rockchip blob
QuoteDDR Version 1.24 20191016
In
soft reset
SRX
channel 0
CS = 0
MR0=0x18
MR4=0x1
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0x18
MR4=0x2
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
change freq to 416MHz 0,1
Channel 0: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
Channel 1: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
256B stride
channel 0
CS = 0
MR0=0x18
MR4=0x1
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0x18
MR4=0x2
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
channel 0, cs 0, advanced training done
channel 1, cs 0, advanced training done
change freq to 856MHz 1,0
ch 0 ddrconfig = 0x101, ddrsize = 0x40
ch 1 ddrconfig = 0x101, ddrsize = 0x40
pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD
ddr_set_rate to 328MHZ
ddr_set_rate to 666MHZ
ddr_set_rate to 928MHZ
channel 0, cs 0, advanced training done
channel 1, cs 0, advanced training done
ddr_set_rate to 416MHZ, ctl_index 0
ddr_set_rate to 856MHZ, ctl_index 1
support 416 856 328 666 928 MHz, current 856MHz
OUT
Boot1: 2019-03-14, version: 1.19
CPUId = 0x0
ChipType = 0x10, 322
SdmmcInit=2 0
BootCapSize=100000
UserCapSize=14910MB
FwPartOffset=2000 , 100000
mmc0:cmd8,20
mmc0:cmd5,20
mmc0:cmd55,20
mmc0:cmd1,20
mmc0:cmd8,20
mmc0:cmd5,20
mmc0:cmd55,20
mmc0:cmd1,20
mmc0:cmd8,20
mmc0:cmd5,20
mmc0:cmd55,20
mmc0:cmd1,20
SdmmcInit=0 1
StorageInit ok = 68844
SecureMode = 0
SecureInit read PBA: 0x4
SecureInit read PBA: 0x404
SecureInit read PBA: 0x804
SecureInit read PBA: 0xc04
SecureInit read PBA: 0x1004
SecureInit read PBA: 0x1404
SecureInit read PBA: 0x1804
SecureInit read PBA: 0x1c04
SecureInit ret = 0, SecureMode = 0
atags_set_bootdev: ret:(0)
GPT 0x3380ec0 signature is wrong
recovery gpt...
GPT 0x3380ec0 signature is wrong
recovery gpt fail!
LoadTrust Addr:0x4000
No find bl30.bin
No find bl32.bin
Load uboot, ReadLba = 2000
Load OK, addr=0x200000, size=0xe5b60
RunBL31 0x40000
NOTICE: BL31: v1.3(debug):42583b6
NOTICE: BL31: Built : 07:55:13, Oct 15 2019
NOTICE: BL31: Rockchip release version: v1.1
INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO: Using opteed sec cpu_context!
INFO: boot cpu mask: 0
INFO: plat_rockchip_pmu_init(1190): pd status 3e
INFO: BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
ERROR: Error initializing runtime service opteed_fast
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x200000
INFO: SPSR = 0x3c9 -
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.
-
@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.
SATA trays 1 & 2 dead
in Rockchip
Posted
Please contact support at support@kobol.io for such issue.