piter75
-
Posts
306 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by piter75
-
-
2 hours ago, Glock24 said:
Why did Armbian boot at first but after the update it won't even if I rewrite the same image I used at first?
Is anything printed on the serial console during boot?
-
On 3/5/2022 at 10:15 AM, yellowmgaman said:
After I've flashed latest bullseye or focal I just get sys led blinking green twice every second, and no response from WAN/LAN.
Just tested mine with the latest image (buster / current) with 16GB Sandisk Ultra SD card and it seems to work fine: http://ix.io/3Rxb
It is a 1GB model however.
Any chance to get the bootlog over serial?
-
11 hours ago, Excalibur said:
Hopefully this can be fixed soon.
The truth is I did not test the SPI booting lately. Will give it a shot as soon as I find some spare time.
4 hours ago, mo123 said:How do you build Armbian for RK3399, RockPi4 with edge 5.15/16 kernel instead of current that is 5.10?
It's not merged into master yet: https://github.com/armbian/build/pull/3489
-
On 2/12/2022 at 1:34 PM, Heisath said:
Yeah, I will move the RC branching a few day, also the release will be moved 1-3 days on Igors request.
I did not make it to send the PR yesterday although prepared the switch.
I am totally unsure however how PineBook Pro fares after the switch (the changes are pretty substantial) so we should probably keep rockchip64-current at 5.10 and catch-up after the release.
-
-
13 hours ago, Igor said:
rockchip64 current still needs to be bumped to 5.15.y
I gave it a shot tonight and well... edge and current diverged quite a bit functionally between themselves
during my absence 
.
With as much time as I can spare on it at the moment I am not confident enough that I can synchronise them correctly during the next 1-2 evenings.
@Igor Do we consider keeping rockchip64 current at 5.10.y for this release?
-
-
On 9/3/2021 at 9:17 AM, ebin-dev said:
So far there were at least two observations:
@alchemist observed a month ago, that several Armbian patches did not compile with newer kernels and he assumed that this may have be the reason.
@Igor states that someone may have pushed bad code upstream.
Armbian "current" (5.10.y) compiles without issues.
I second @Igor's opinion that a change somewhere in this diff broke the eMMC.
I tried reverting a few obvious parts of it, like the mmc driver changes, but without success.
However I did find that with the unit I have the issue happens only in hs400{,es} modes.
With those disabled my unit works fine and I can use nand-sata-install to transfer os from SD to eMMC successfully which is not possible with 5.10.60+ and hs400 enabled on eMMC.
If anyone wants to check if switching eMMC to hs200 mode works also on their unit, here is how:
Upgrade the kernel to 5.10.60, but don't reboot yet.
Run:
curl -o rk3399-kobol-helios64.dtb https://users.armbian.com/piter75/helios64/rk3399-kobol-helios64.dtb sudo cp rk3399-kobol-helios64.dtb /boot/dtb/rockchip/rk3399-kobol-helios64.dtb sudo rebootIf this workaround works I will disable hs400{,es} (again) in Armbian until the underlying issue is found.
There will be a performance penalty to that change but keep in mind that Helios64 was originally released with hs200 and only recently gained hs400 back ;-)
Below you can find the comparison between hs400 and hs200 modes using iozone.
Spoileriozone tests with hs400 enabled
Command line used: iozone -e -I -a -s 100M -r 4k -r 512k -r 16M -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 40288 43745 32990 33259 32947 44130 102400 512 55587 55494 199986 200855 217646 55196 102400 16384 55394 55543 244727 246050 245637 55338iozone tests with hs400 disabled
Command line used: iozone -e -I -a -s 100M -r 4k -r 512k -r 16M -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 30373 39757 30250 30432 30187 38770 102400 512 55609 55545 124949 123053 124986 55854 102400 16384 56063 55900 130689 132590 132463 54512 -
On 8/15/2021 at 11:13 PM, Joaho said:
Can't it accept a NO and still do it's job i.e. write to SPI?
Is this a valid suggestion?
You have probably used the option "Boot from SPI - system on SATA, USB or NVMe" which transfers the current system to SSD and needs to clean it.
There is another option - better suited for your case - "Install/Update the bootloader to SPI Flash". It does not touch the existing partitions only writes to SPI Flash.
-
@TCB13 I am a bit late to the party but I figured it may still be needed ;-)
spi-spidev is a special / dynamic overlay. Besides enabling it you need to also configure it and armbian-config cannot currently do that.
For configuration options have a look here:
You can also consult the local README file located in: /boot/dtb/rockchip/overlay/README.rockchip-overlays
-
On 6/5/2021 at 2:07 AM, Thireus said:
Other issue that has been mentioned here: Only the middle USB port works as USB 2.0, the other port doesn't work. Any luck with this issue anyone?
It will be fixed with https://github.com/armbian/build/pull/2877
-
@Chalix You have done quite a research already
Helios64 is Rockchip RK3399 based so you are better off with the theory found here http://opensource.rock-chips.com/wiki_Boot_option as a starter.
U-boot and vendor blob binaries are found in "/usr/lib/linux-u-boot-$BRANCH-helios64_$RELEASE_arm64" folder on your system.
You are probably using "current" $BRANCH and the latest $RELEASE is 21.02.3.
The recipe to write the images to device (more or less) is to be found here.
-
17 minutes ago, pkfox said:
Thanks for the info Nico but I can't visualise what you're suggesting
Something similar to this hat most probably ;-)
-
1 hour ago, Pedro Lamas said:
I've had no issues with my M4V2 since setting the governor to "userspace" and max and min speeds set to "1416000" (and by no issues, I mean no crashes at all and I have an uptime of 20 days now)
With that setting you are actually disabling the DVFS after the short period of time during boot - before cpufrequtils kicks in.
My experience is that you could also set it to min/max 2GHz and it would be just as good.
1 hour ago, Pedro Lamas said:I wonder if your fix is for the issues we've seen with the governor set to "ondemand"?
Yes, this mod/tweak/hack ;-) fixes the behaviour of my boards with ondemand governor.
It seems that the instability of little core's voltage during the voltage change was the issue.
Rockchip has already limited max change per single step for this regulator to 100mV (because of "overshooting") and I did limit it further to 50mV (75mV was still unstable).
It takes a bit longer to switch between frequencies now (at least 456uS vs at least 196uS for full swing between 408MHz and 1512MHz) but it is stable.
-
11 minutes ago, Igor said:
I tend to enforce cleaning activities to save some space
+1 We need to do that from time to time.
9 minutes ago, Igor said:If we need focal image(s) for those boards, someone just add them
I am not particularly missing them ;p
-
2 hours ago, lanefu said:
That would only impact nightlies not the most recent release
I am not sure of that.
My understanding is that we are still building release images from master branch and the removal of this line from targets.conf:
-rockpi-4b legacy focal cli stable yes
means that focal legacy image for rockpi-4b will not be built.
Lack of focal legacy image among 20.02.3 release images (built after the referred commit was merged) seems to corroborate that theory ;-)
-
12 hours ago, lanefu said:
I think we just have a bad mapping in our download tool.
IMHO it's more than that ;-)
There will be older releases in the archive but no new ones.
-
1 hour ago, pumuckl said:
look's like the Download of Rockpi 4 A / B / C Armbian Focal is offline.
Not that it is relevant to SPI/NVMe booting ;-) but it is no longer built for that combination automatically.
You can build it yourself or download focal current and switch kernel to legacy with "armbian-config".
-
@Salvador Liébana I would be very cautious about comparing with results that I don't know how they were obtained. In fact I would avoid it ;-)
We cannot say much about Radxa's benchmarking looking at the presented graph.
Nonetheless below you will find the iozone run I performed with LK 5.10.20:
piter@rockpi-4c:~$ uname -a Linux rockpi-4c 5.10.20-rockchip64 #1 SMP PREEMPT Fri Mar 5 10:47:39 CET 2021 aarch64 GNU/LinuxIt was performed using iozone (429) on EXT4 with ROCK Pi 4C and Corsair Force MP510B 480GB (yes, the model with degraded flash chips):
Spoilerpiter@rockpi-4c:~$ iozone -e -I -a -s 1G -r 4k -r 512k -r 16M -i 0 -i 1 -i 2 Iozone: Performance Test of File I/O Version $Revision: 3.429 $ Compiled for 64 bit mode. Build: linux Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner, Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone, Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root, Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer, Vangel Bojaxhi, Ben England, Vikentsi Lapa. Run began: Thu Mar 25 19:37:30 2021 Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 1048576 kB Record Size 4 kB Record Size 512 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 1G -r 4k -r 512k -r 16M -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 1048576 4 100179 166395 178300 179572 52739 110763 1048576 512 1079229 1073992 903277 903298 902415 1119885 1048576 16384 1493074 1482710 1572587 1577645 1577413 1482543 iozone test complete.As you can see it reaches 1GB+/s speeds both writing and reading with large enough block size, hovers around 1GB/s with medium block size and dives to 50-200MB/s with small blocks.
pcie-gen2 overlay is not needed with ROCK Pi 4C as unsupported gen2 link speed was mainlined for all ROCK Pi 4 boards.
BTW. Is the guy Jeff Geerling (https://github.com/geerlingguy)?
If so then I am actually using the way he was using to compare different SD cards' performance with Raspberry Pi ;-)
https://github.com/geerlingguy/raspberry-pi-dramble/issues/7
-
1 hour ago, jorgesilva said:
Thanks for the help, I guess my question is why is it defaulting to 5GT/s and not 8GT/s
RK3399 officially supports version 1.0 (2.5GT/s) and unofficially 2.0 (5GT/s).
PCIE 3.0 support is needed for 8GT/s. https://en.wikipedia.org/wiki/PCI_Express#History_and_revisions
-
19 hours ago, jorgesilva said:
It makes no difference if I include the pci-gen2 overlay.
True, it makes no difference because the unsupported by Rockchip Gen 2 link speed was mainlined into ROCK Pi 4(a/b/c) device trees so you don't need the overlay ;-)
I am not sure it should be mainlined this way but it's another story.
19 hours ago, jorgesilva said:8.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x2
It confirms that you are indeed running at Gen2 speeds and have 1GiB/s physical bandwidth.
-
14 hours ago, i5Js said:
Up time: 2 days 8:57 and counting
Looks promising.
Glad to hear that.
BTW The fix is now included in Armbian v21.02.3 images
-
47 minutes ago, madmailman said:
Which also means that the XPG SX6000 Lite 128GB PCIe 3D NAND PCIe Gen3x4 M.2 2280 NVMe (ASX6000LNP-128GT-C) works well with this setup.
Thanks for sharing drive details!
I will add it to the opening post.
-
On 3/7/2021 at 10:50 AM, i5Js said:
I'll keep you posted.
Great. Looking forward to hear about your results.
NanoPI R4S Problems reading SD card *after* starting initramfs (after upgrade to linux-image-current-rockchip64=22.02.1)
in NanoPi R4S
Posted
There might also be some variances in components between units (different manufacturers, batches, etc..) that might have been "uncovered" by some minor change in kernel code.
I remember having a unit of Rock Pi 4A (no wifi) that did not boot with eMMC while the other unit 4GB 4B (wifi) did boot without issues.
I consulted other Rock Pi 4A Armbian users and they did not observe such behaviour.
I finally found the cause in the mmc kernel driver and even implemented a patch for it in Armbian, but that did require lots of fiddling and debugging.
Unfortunately at this point I cannot reproduce the issue with my NanoPi R4S unit.