jpegxguy

Ok, it turns out that lz4 is actually much faster. /etc/apt/apt.conf.d/02-armbian-compress-indexes has to be removed from the official packages, it's a bad idea. The gz indexes are slooow

Yeah, I'll try making a PR. We'll use the old ways make time

Hi, I see linux 5.15 is in the beta repo. It would be cool if we enabled the ntfs3 and ksmbd kernel modules. I'd like to test ksmbd, though the corresponding userland tools don't seem to be available in the debian repos, so we would compile those

Just for anyone reading this, this might be related. Someone suggested prioritizing gzip in order to escape the slowness of LZ4 on ARM platforms. Here is the solution, which was also merged in Armbian itself:

I just want to say, thanks for this. LZ4 was REALLY slow on my Renegade board, and it kept popping up. I added that line and did not touch any other file. Good to see it merged, too.

Easiest way is to boot Armbian SD card and flash armbian to emmc from the board itself, honestly (It will show up as /dev/mmcblk0 - the one with the boot0 and boot1 sections) Librecomputer doesn't provide an easy external way to access the emmc. (Like SD adapter or something) I have noticed something very useful. If your u-boot supports it you can use ums command to get Renegade to act like a usb stick and access the emmc. But if you're asking how to flash, you'll probably be ok with the first option

In light of a recent change of role for this Renegade board (It'll be a small headless server on a different location from me), I've switched it to Armbian! The changes I've made besides the usual config are: GPT (Not necessary: I just like the checksumming + backup partition table) and U-Boot switch to legacy channel because that channel has the ums U-Boot command. I figured Armbian would be less risky for stability, especially for kernel upgrades on a device I don't have physical access to. The armbian-config and relevant utilities are nice too.

Yeah, I just like the Arch way of things. I started with Ubuntu like most people, and I do run Debian on one of the machines, but on my laptop I use Arch™ As for Debian being "better" I mean in the sense of "even being doable",. I brought the U-Boot upstreaming topic here because this distro does care to bring U-Boot and the like to more boards than other distros, especially ones that are not ARM-specific. As I mentioned, I didn't even know some defconfig for Renegade had been upstreamed! It was only Rock64 before, haha

That's true, and I think Armbian is essentially the only way if you plan on using these boards' hardware, like hardware acceleration e.t.c. I do look around in the armbian build repo and there are always nice patches and fixes in the patch/ directory. I have SD cards with Armbian, Arch and other distros, and I only stick to Arch on headless because I'm less familiar with debian packaging. If I wanted to run anything more damanding than SMB or a torrent client I'm pretty sure Armbian is the only distro with support for these ARM boards' quirks. Generic distros like Debian, or Ubuntu or Arch are better suited for hardware with good upstream (Rockchip in this case) support

There would be a lack of maintenance because 5.7 is not an lts version. 5.4 does exist though which is nice. Wait, why for 2 weeks? I was thinking I wouldn't be able to boot anything past 5.8.0.

Armbian's kernels are fine! What I mean is that with the rockchip U-Boot I had before, I would not be able to run kernels past 5.8, at least on the distro I run on that card (Arch), which would be a problem for security in the future. I'd be stuck on 5.7 for example, with 5.10 being out... (e.t.c)

Thinking longterm, I don't want to be stuck to legacy kernels. Of course I like the ums in the legacy uboot, it's just my solution for now

Thanks. Well for my headless needs, performance is fine, so I'll keep the mainline U-Boot to boot Linux 5.8

I definitely agree that it's not your concern if it's an Arch issue. I wanted to post because the whole mainline experiment with U-Boot. I really appreciate this project and its efforts with these funky Rockchip boards! So UMS is not an upstream thing? Is it that it needs a lot of board-specific patches? EDIT: # grep ddr /sys/kernel/debug/clk/clk_summary clk_ddrmon 0 0 0 24000000 0 0 50000 pclk_ddrphy 1 1 0 75000000 0 0 50000 pclk_ddr 3 3 0 150000000 0 0 50000 pclk_ddr_grf 1 1 0 150000000 0 0 50000 pclk_ddrstdby 0 0 0 150000000 0 0 50000 pclk_ddr_mon 1 1 0 150000000 0 0 50000 pclk_ddr_msch 1 1 0 150000000 0 0 50000 pclk_ddrupctl 0 0 0 150000000 0 0 50000 clk_ddr 2 2 0 664000000 0 0 50000 aclk_ddrupctl 0 0 0 664000000 0 0 50000 clk_ddrupctl 1 1 0 664000000 0 0 50000 clk_ddrmsch 1 1 0 664000000 0 0 50000 Which clock do i care about?

Thanks for the answer! Yes it would be awesome if UMS was enabled! cat: /sys/class/devfreq/dmc/trans_stat: No such file or directory Specifically, there is nothing under the devfreq directory. I'm running Linux 5.8 on ArchLinuxARM. The guys on the archlinuxARM forum are having (at least one of them) the same issue of getting stuck in "Starting kernel..." when using Rock64 and Linux 5.8, so it's not isolated to Renegade Maybe it has something to do with that distro's specific Linux 5.8 version?

It seems the Linux kernel 5.8+ on aarch64 is incompatible with the U-Boot from 2017, at least on the RK3328 boards. This apparently affects the Rock64 as well as my own Renegade. Essentially U-Boot gets stuck on "Starting kernel..." In this post https://archlinuxarm.org/forum/viewtopic.php?f=23&t=14657&start=10 they fix it by recompiling u-boot, newer version from upstream In addition to the existing rock64 defconfig, it seems that the defconfig for the Renegade was finally upstreamed on May! https://github.com/u-boot/u-boot/commit/bab972948e152e468fa5ab34764769fc4cddcaab No more 2017 U-Boot from rockchip for me, perharps... I modified https://archlinuxarm.org/packages/aarch64/uboot-rock64/files/PKGBUILD for the renegade and actually got a system that can boot Linux 5.8. (flashed the loader1 and an .itb file) I have 2 (possibly 1) issue: 1) Like the current branch in the armbian build, uboot is missing the ums (USB mass storage) command which is really useful to modify the emmc from a pc. 2) The 2020 uboot i compiled shows DDR4 333 in the first stage, instead of the older DDR4 786Mhz. Does that mean the RAM gets initialized at a lower speed? Maybe, but at least I can boot newer kernels now. Also Maybe the Rock64 and Renegade armbian packages should actually use the upsteam uboot instead of rockchip's 2017 version. I don't know if you already do this in the build tools, but it would be cool!

Have you tried the upstream kernel or are you using the vendor 4.4.something? Sorry if the question's been answered before

I gotta be honest with you, I do like the finicking! Plus I'm tight on money. So I'll play around with uboot and its commands any day. I just found out that USB Mass Storage emulation works fine for playing around with the emmc from a PC! I never mentioned Armbian in my post. Armbian is very important and I'm thankful it exists. As far as I'm aware armbian is the only ready out-of-the-box experience for this board (the ones from Firefly are old and they crash a lot) I'm using an Armbian U-Boot with Archlinux on this board for months now. I was talking about Rockchip specifically. Armbian is a community distro

I just want to mention this happens regularly. I thought I'd found a version that doesn't do it but now I have no idea how to escape it. Maybe it's random. All I know is perhaps I should buy an RPi 4 to use as a NAS and have this just to play with. It's not supported at all by the guys that sell it, while all the non-Rockchip boards in the LibreComputer lineup have fine support. It's a shame

I've been using Arch Linux Arm with the generic linux-aarch64 kernel for a while now on my LibreComputer Renegade. Works nicely and I don't have to stay with an outdated vendor kernel. That said, I use it as a headless server. I don't know what limitations there would be when it comes to graphics performance.

It was mentioned to me by email that the ethernet TX issue I describe here plagues this board as well (my board is the LibreComputer Renegade). It seems like the exact parameters might depend on each specific device, in which case the "best" solution would be some kind of "autoconfiguration" for the PBL, but that is in a future TODO. More about the issue andthe discussion here: https://patchwork.kernel.org/patch/10880481/ Eventually this patch was merged for the Renegade upstream: https://patchwork.kernel.org/patch/11017833/

Status update on the ethernet TX issue (iperf tests ending abruptly with some kilobytes transferred and the like) The cause has been known for a while to be some error in the hardware offloading of TX checksumming. (TX is when the board sends bits out) One way to avoid that issue is to disable TX checksumming (getting the CPU itself to handle that) e.g.: using ethtool introducing a flag in the dts that among other things, does just that or by disabling it dynamically for certain devices with a new flag But disabling that offloading seems to come with a performance hit. There's some discussion going on about a different approach, which is to tweak the PBL value for TX. https://lkml.org/lkml/2019/4/1/1382 Recently I've been using U-Boot's handy fdt commands to test stuff on my Renegade, and introducing a certain change in txpbl, replacing force_thresh_dma_mode if it is there: fdt rm /ethernet@ff540000 snps,force_thresh_dma_mode fdt set /ethernet@ff540000 snps,txpbl <0x21>

There's been a bit of discussion on this in the mainline mailing lists. Try sticking this in your boot.cmd temporarily, immediately after fdt resize: (dont forget to mkscr) fdt rm /ethernet@ff540000 rockchip,bugged_tx_coe fdt rm /ethernet@ff540000 snps,force_thresh_dma_mode fdt set /ethernet@ff540000 snps,txpbl <0x21> and reboot. Then go about your day or do an iperf test if you have another gigabit capable device.

Yeah, sorry. I was just really bummed myself. I'll be looking more to actual mainline for mainline stuff, as it should be