EL8 for the raspberry pi

[Tim West]

Hi,

I've been using using Redsleeve el7 on a number of Pi for a few years
and it's great.
I'm now looking to upgrade a clusterHat cluster to EL8, but I can't find
a release for the pi only a rootfs from 2019, which I've tried to get
working, but had no luck.

Have a missed something?
I'm willing to help getting it working or testing if that will help.

Tim

[Jacco Ligthart]

Hi Tim,


Thanks for reaching out, it has been on my list to write some update
about RSEL8 for much too long.


I'm sorry to hear that the rootimage does not work for you. As far as I
remember did I test them on pi's version zero, 1, 2 and 3. The first
thing that comes to mind is "give it a couple of minutes". I am not able
to create images with selinux contexts, so on the very first boot the
system will create it's own selinux contexts, which might take some time.

I think I build most of CentOS 8.2 for armv5. After that covid came
along and my workload at $dayjob went up. When that returned to normal,
CentOS announced that they would stop supporting 'regular' CentOS and
start at some time in the future 'streams'. At the same time was it my
personal analysis that armv5 is probably mostly dead. armv7 has quite
good support, there are other rebuilding efforts for that. My conclusion
is that probably the best thing to do is rebuild all for armv6, which is
still quite much in use, especially on pi's version 1 and zero.

So, I have recently rebuild whole of CentOS 8.3 for armv6, but never
came round to publishing ...


In my mind, it breaks down to making choices, before continuing:

- what to follow? CentOS stream? RedHat code from git (might be more
complex than following a SRPM repo) or another rebuild effort (Rocky?
another?)

- If we are going to follow another rebuild, we could try to merge our
efforts. If we contact Rocky and they like the idea, we could publish
under their name and save on rebranding effort.

- armv6? or armv5? (or both?)


I'd appreciate other peoples views and ideas.


Jacco

[Gordan Bobic]

I no longer own any ARMv5, ARMv6 or ARMv7 without NEON 

(e.g. Nvidia Tegra) devices, so don't really have a personal stake 

in this matter. So take what I say with a healthy dose of pragmatism. :-)

With that out of the way, I think it makes sense to continue targeting 

ARMv5. There are no other EL options available for all of the remaining 

users of all the Sheeva / Guru / Dream Plugs, and I think there are 

still a fair few of these out there.

Pi v1 is ARMv6 and has a FPU and there are a LOT of them 

out there, but the performance difference between soft-float 

ARMv5 code and hard-float ARMv6 code is rather limited 

outside of a handful of rather narrow uses (Quake 3?).

Various hard-float EL variants do not quite work properly on 

Tegras and other NEON-less ARMv7s (particularly Xorg 

and GUI related things), and most Tegras are used with GUIs.

If we assume for a moment that the target user base of 

RS is people who use one of these devices, i.e.:

- ARMv5 (e.g. Sheva / Guru / Dream Plugs, various Marvell Kirkwood based NAS-es)

- ARMv6 (e.g. Raspberry Pi v1)

- ARMv7 without Neon (e.g. Nvidia Tegra: TrimSlice, Toshiba AC100)

Everybody with ARMv7+NEON has CentOS as an option.

The question then becomes one of what do we gain with whatever 

compromise is chosen:

1) What is gained by targeting ARMv6 instead of ARMv5?

2) How many people still use ARMv5 devices?

Point 2 can be difficult to answer. It could be a small number of 

users with large deployments in all kinds of monitoring or automation 

applications. I simply don't know. They do still seem to be available 

to buy new, though generally come pre-installed with Debian.

On a separate note, most boot issues are down to bootloaders and kernels. 

If you are getting nothing on the screen / serial console, there is something 

wrong with either the bootloader or the kernel, since by the time the kernel 

and initrd have loaded, you should definitely be getting output.

RS has traditionally be the userspace part, and we still largely rely 

on upstream / manufacturer provided bootloaders, kernels and 

associated binary blobs because many of these older ARM devices 

predate standardisation efforts. There are some workarounds 

available, e.g. two-stage bootloading - the built in bootloader 

is used to boot modern u-boot with EFI support, and from there 

the standard EFI grub takes over, but it doesn't work for all 

devices. So - coming up with a unified boot image is unfortunately 

tricky, and I am not sure how much scope there may be for 

uniformity.

[Jacco Ligthart]

Pi v1 is ARMv6 and has a FPU and there are a LOT of them 

out there, but the performance difference between soft-float 

ARMv5 code and hard-float ARMv6 code is rather limited 

outside of a handful of rather narrow uses (Quake 3?).

The issue is not as much performance as it is compatibility. There are a couple of low-level packages that just don't support armv5, but do support v6. From the top of my head that would be at least valgrind, clang, llvm, rust. And those are needed to build others. I expect that firefox/thunderbird will work on v6 but not on v5 ...

Jacco

[Gordan Bobic]

There are two questions arising from this:

1) Do they require ARMv6 or ARMv6 hard-float?

If they require hard-float, then that means we are effectively dropping all ARMv5 and possibly some ARMv6 devices (are there any ARMv6 devices in wide circulation other the Raspberry Pi v1?)

2) Do these packages require merely hard-float or do they require NEON?

I vaguely recall (and this is from a while back, so forgive me if I am wrong) that last time I was trying to build Firefox for RS, it failed because it required NEON. This was a couple of years ago, so I don't know how accurate it still is.

And if we are going to raise the bar to hard-float NEON, then we might as well not bother doing anything because that is the entry point for CentOS.

[Jacco Ligthart]

I am only aware that they need armv6. For instance:
https://intel.github.io/llvm-docs/clang/UsersManual.html#arm

On RSEL 7 firefox had indeed building issues with NEON. I remember that we often got it to work after some tinkering. This was until the whole build became dependent on clang. from there on we were not able to build any more. the package is now no longer in redsleeve.

I manged to bootstrap the armv6 build. At that time I choose 'armv6hl', which is "-march=armv6 -mfloat-abi=hard -mfpu=vfp", So this is hard float, but no NEON.

Jacco

--
You received this message because you are subscribed to the Google Groups "redsleeve-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redsleeve-use...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/redsleeve-users/CAMx4oe28eWKTt0YXN%2BD_3fu4wwjRY42E_e0uu%2BScnHy5CcwUug%40mail.gmail.com.

[Gordan Bobic]

On Sat, Sep 25, 2021 at 5:30 PM Jacco Ligthart <ja...@redsleeve.org> wrote:

On 9/25/21 11:58, Gordan Bobic wrote:

On Sat, Sep 25, 2021 at 12:47 PM Jacco Ligthart <ja...@redsleeve.org> wrote:

Pi v1 is ARMv6 and has a FPU and there are a LOT of them 

out there, but the performance difference between soft-float 

ARMv5 code and hard-float ARMv6 code is rather limited 

outside of a handful of rather narrow uses (Quake 3?).

The issue is not as much performance as it is compatibility. There are a couple of low-level packages that just don't support armv5, but do support v6. From the top of my head that would be at least valgrind, clang, llvm, rust. And those are needed to build others. I expect that firefox/thunderbird will work on v6 but not on v5 ...

There are two questions arising from this:

1) Do they require ARMv6 or ARMv6 hard-float?

If they require hard-float, then that means we are effectively dropping all ARMv5 and possibly some ARMv6 devices (are there any ARMv6 devices in wide circulation other the Raspberry Pi v1?)

2) Do these packages require merely hard-float or do they require NEON?

I vaguely recall (and this is from a while back, so forgive me if I am wrong) that last time I was trying to build Firefox for RS, it failed because it required NEON. This was a couple of years ago, so I don't know how accurate it still is.

And if we are going to raise the bar to hard-float NEON, then we might as well not bother doing anything because that is the entry point for CentOS.

I am only aware that they need armv6. For instance:
https://intel.github.io/llvm-docs/clang/UsersManual.html#arm

On RSEL 7 firefox had indeed building issues with NEON. I remember that we often got it to work after some tinkering. This was until the whole build became dependent on clang. from there on we were not able to build any more. the package is now no longer in redsleeve.

I manged to bootstrap the armv6 build. At that time I choose 'armv6hl', which is "-march=armv6 -mfloat-abi=hard -mfpu=vfp", So this is hard float, but no NEON.

Fair enough. I guess that will make future RS builds only useful for Raspberry Pi 1 and Tegra <= Tegra2 based devices like the TrimSlice and Toshiba AC100. But if critical packages are failing to build for ARMv5, I guess there is no other viable option.