[Trisquel-devel] success on arm64 Supermicro ARS-110M-NR

[Jing Luo]

On 2024-07-10 06:45, Simon Josefsson wrote:
> Jing Luo <jing at jing.rocks> writes:
>> formatted the rootfs as btrfs, with linux-generic-64k-hwe-11.0-edge
> 
> What is the benefit of the 64k kernels?  The package description 
> doesn't
> really say one would just them over the other ones.  Are there
> performance differences?

 From what I understand, larger page size means that the memory 
allocation will be less computationally expensive. But so far I don't 
know if there is real, visible difference in performance. However, 
larger page sizes can break compatibility, like Proxmox uses a certain 
Rust jemalloc that only supports 4K page size (so I've heard). Your 
Talos II should default to 64K page size, I remember only seeing the 64K 
option in linux's menuconfig for ppc64el. Also, Raspberry Pi foundation 
ships 16K page size kernel (non-free) with Raspberry Pi 5.

https://en.wikipedia.org/wiki/Page_%28computer_memory%29#TLB_usage

> Right now, I am using linux-libre 6.9.8 on my machine (thanks Jason for
> releasing gnu-2.0 versions in gzip format!) because of a known (mostly
> cosmetic) bug with the mpt3sas driver that also occurs on amd64.  I
> didn't have any issues with the vanilla trisquel kernel before adding
> the LSI card to the machine.  I tried the linux-libre-lts 6.6 packages
> and they work fine on this machine too.

Ah yes! Although from a user's perspective, I usually don't recommend 
using upstream packages directly, be it linux or linux-libre (freesh), 
because they tend to be raw and unrefined. Downstreams like Trisquel (or 
even Debian) have a more refined config/preset and is more suitable for 
day-to-day uses. An example would be the issue you encountered with 
gzipped/uncompressed vmlinuz, Trisquel or Debian didn't break when 
freesh did (no offense to our hero Jason).

>> There are plans to improve the node stack, as Ecne will be adding
>> riscv and more load to arm, but that's is still on it's way. Using
>> community vm/nodes might require to layout some security policies, and
>> some other directives, we'll need to find some time to define those if
>> moving in that direction.
> 
> I am also happy sponsor build machines here, but I understand the
> dilemma about riscv.  Either you purchase some riscv machine and set it
> up yourself (I am happy to donate funding for this), but then as far as
> I understand the requirements, we would need to make sure it runs on
> only free software and no blobs.  I got my Milky-V Pioneer riscv 
> machine
> working via upstream's kernel image and Debian debootstrap.  I have
> tried installing both Debian and linux-libre kernels, but I just get a
> blank screen when booting.  I have been hoping for months that the
> Debian people make progress on a kernel for this hardware, but I don't
> know if there is any known problem or just lack of time.  So we don't
> really know if this machine can ever boot without some non-free blob or
> not.  The alternative is to build in people's VM, and I'm happy to 
> setup
> a VM on the riscv machine I have, but then there are BOTH trust issues
> with the hoster and the uncertainty about freedom of the hardware.
> 
> I don't know of a way to resolve this... I would be unhappy if ecne
> won't ship with riscv due to this.  There are not that many unique
> packages in trisquel, it would be entirely possible to rebuild all of
> them on a new hardware eventually to increase trust in the packages.

I would be happy if Trisquel becomes the first 100% libre distro that 
officially supports riscv64. Before that happens...I'm stuck with debian 
sid.

I think if you build u-boot and linux(-libre) from source for a certain 
board, you should know if that board can boot with only free software. I 
also have a few SBCs that won't boot with upstream or debian's kernel, 
so I ported many patches from "vendor kernel" then build the kernel 
myself. They are buggy, many drivers won't work properly, but at least 
they are libre, unlike the blob-ridden "vendor kernel". However, I have 
a RK3588 based ROCK 5B that requires me to insert a blob when compiling 
u-boot, that was when I realized RK3588 requires non-free software... So 
the conclusion is, if the board can boot with a "clean" u-boot and 
linux-libre, then it doesn't require non-free blobs to boot. However, in 
many cases, HDMI and GPU won't work without blobs, but I gave up on 
those already (who needs framebuffer support anyway? :)

I've heard stories that it's hard to make Milk-V Pioneer boot, but I 
have confidence to make it work :) I plan to buy the board when I save 
enough money and US dollar is not so strong. Anyway, for Pioneer, two 
months ago I looked at upstream linux 6.8 device tree, it seems that the 
support for this board is very minimal: only serial console, CPU and RAM 
are supported. Judging from kernel.org mailing lists and Debian's salsa, 
I don't think anyone is working on it. The manufacturer Milk-V in China 
(located in my hometown actually) doesn't seem to care about upstream 
support at all, like most other SBC manufacturers. But in any cases, if 
I do get this board and make it work this year, I would also like to 
host a node for Trisquel's build farm.

-- 
Jing Luo
About me: https://jing.rocks/about/
GPG Fingerprint: 4E09 8D19 00AA 3F72 1899 2614 09B3 316E 13A1 1EFC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://listas.trisquel.info/pipermail/trisquel-devel/attachments/20240710/e3214aec/attachment.sig>