jpegxguy
-
Posts
38 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jpegxguy
-
-
On 11/13/2021 at 10:37 AM, Igor said:
Just make something like https://github.com/armbian/build/pull/3232 Such things are accepted without questions asked.
Yeah, I'll try making a PR.
On 11/13/2021 at 3:18 AM, ning said:it's meaningless to add ksmbd or ntfs3 to kernel, due to userspace tools are not ready for debian. espicailly for ntfs3, no userspace tool.
even armbian added, you still can't use them.
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: -
On 3/18/2021 at 10:09 AM, lurdan said:
Another solution (tested on armbian buster):
Add this line to /etc/apt/apt.conf.d/02-armbian-compress-indexes:
APT::Compressor::gzip::Cost "10";and remove /var/lib/apt/lists/*.lz4.
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
-
11 hours ago, Igor said:
Latest stable kernel is yet to be stabilised in next weeks / months. And this is not Intel, but ARM Rockchip, which adds complexity. I can assure you that staying on a bleeding edge is asking for troubles - you found one, but there are more, which autotesting can't find - and taking raw kernel from kernel.org is something anyone can do. We add weeks, sometimes months of work on top of that raw material, a lot of fixes yet to come to the mainline are already a part of our kernel. That's what I am trying to point out. Either goes for fixes or for adding features. Mainly we are focused to hardware specifics - exactly what you will miss on a generic kernel. Yes, we can't solve everything, but the end result is usually better, much better. BTW.
Well, for you this is probably not relevant, since you are using distribution that provides generic Linux kernel.We will probably move to 5.8.y soon, but there is no urgency - we already support more important hw specific features/fixes that are in 5.8.y. while general improvements from 5.7 -> 5.8 are too small to bother.
Also we can decide upgrade per hardware family. For one this is good, for another this is bad, one will not boot at all, one have to stay behind ... not all hardware is getting good mainline support.
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
-
42 minutes ago, Igor said:
Problem of security is lack of maintenance.
Perhaps for two weeks. That's really awful.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.
-
6 hours ago, Igor said:
This is what I don't understand. Arch "mainline" 5.8.y kernel is behind our "mainline" 5.7.y and recent u-boot has many disadvantages. In term of user land, ok, its your choice.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) -
5 hours ago, Igor said:
This is what I don't understand. Arch "mainline" 5.8.y kernel is behind our "mainline" 5.7.y and recent u-boot has many disadvantages. In term of user land, ok, its your choice.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
-
14 hours ago, piter75 said:
Last four, but you need to divide them by 2 so it is 333MHz.
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 50000Which 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 directorySpecifically, 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 upstreamIn 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:
-
-
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
My apt search has become super slow recently
in Beginners
Posted
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