EL8 for the raspberry pi

2 views
Skip to first unread message

Tim West

unread,
Sep 24, 2021, 1:51:06 PMSep 24
to redslee...@googlegroups.com
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

unread,
Sep 25, 2021, 4:31:52 AMSep 25
to redslee...@googlegroups.com
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

unread,
Sep 25, 2021, 5:20:54 AMSep 25
to redsleeve-users
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

unread,
Sep 25, 2021, 5:47:56 AMSep 25
to redslee...@googlegroups.com


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

unread,
Sep 25, 2021, 5:59:06 AMSep 25
to redsleeve-users
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

unread,
Sep 25, 2021, 10:30:24 AMSep 25
to redslee...@googlegroups.com

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

unread,
Sep 25, 2021, 10:49:08 AMSep 25
to redsleeve-users
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.
Reply all
Reply to author
Forward
0 new messages