[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Feedback from the community -> ARM



On Sat, Jun 12, 2021 at 09:00:34AM +0200, Ralph Aichinger wrote:
> On Sat, 2021-06-12 at 06:17 +0000, Paul Wise wrote:
> > On Fri, Jun 11, 2021 at 7:25 AM Ralph Aichinger wrote:
> > 
> > > Many criticisms of the RPi that were true 5 years ago no longer
> > > hold.
> > 
> > Some of them are still true; the weird GPU-starts-CPU SoC boot
> > process,

Some of them are hugely true: at the time when the first RPi was released, it
was released as ARM v6 with hardware floating point. Almost all Linux 
distributions at that point had agreed on architectures <ARM v7 32 bit as
having software floating point and ARM v7 specs to be hardware floating 
point.

Sounds small: but it's meant that Raspbian was always the odd one out, that 
RPi .debs had to be essentially rebuilt from scratch and you couldn't
just move to stock Debian / Ubuntu or whatever or run software from one 
on the other.. Raspberry Pi OS still preserves this v6-ness and essential
32 bit nature - not just for backward compatibility but because the Soc ine
very Pi Zero is still only ARM v6 and 32 bit.

This is also the reason why Raspberry Pi OS isn't particularly concerned with 
64 bit and a 64 bit Raspberry Pi OS is in paermanent beta, though
you've been able to run 64 bit code on everything since some models of the
Raspberry Pi 2. 

There have also been points when the Raspberry Pi Foundation didn't
talk to the wider ARM Linux community (and where the wider community couldn't
get information/offer advice/help) which hasn't helped the overall situation
or some people's feelings about Raspberry Pi in gneral

Strange booting process: a consequence of the original Broadcom SoC.
It would be _so_ nice if RPi people would just adopt UEFI from here on in
and produce firmware that would default to that.

The details of Raspberry Pi-ness and requests there are subtly different 
to  requests to ARM themselves. The fact that the RPi is very much dominant at
 the moment is also because it's very much available while most of the other 
ARM SBCs are on back order / not currently in production / waiting on chips. 
If that situation continues,then the RPi will become the de facto solution 
for most ARM stuff in the medium term.

Just my €0.02

Andy Cater
> 
> Is this still true for the Raspberry Pi4 with UEFI?
> 
> https://github.com/pftf/RPi4
> 
> Even Debian Wiki says
> 
> https://wiki.debian.org/RaspberryPi
> 
> "All Raspberry Pi models before the 4 (1A, 1B, 1A+, 1B+, Zero, Zero W,
> 2, 3) boot from their GPU"
> 
> So it seems this is no longer true, and exactly what I said.
> 
> >  blobs required for the boot process, 
> 
> If there are Blobs needed to bring up the RPi4 they are included
> in above UEFi firmware (or the stuff used in other boot mechanisms).
> I don't see how this is different from the "blobs" I load when I
> boot my UEFi Asus mainboard.
> 
> > some Linux kernelpatches are not in mainline etc
> 
> What patches do you mean? Patches that are in Debian kernels, but
> not in Linus' upstream kernels? Or patches on top of what Debian
> does? Because if you mean the latter, than I can assure you, that
> the RPi4b runs fine without anything but a stock debian kernel,
> both during installation (there the kernel from recent bullseye arm64 
> netinst works just fine) as in actual use. The kernel I am currently
> running is 
> 
> ii  linux-image-5.10.0-7-arm64          5.10.40-1    arm64        Linux
> 5.10 for 64-bit ARMv8 machines (signed)
> 
> directly from Debian archive.
> 
> And I stand by my statement: What was true 5 years ago (weird GPU boot,
> patched proprietary kernel, architecture that falls right between
> armel/armhf in Debian) is no longer true for kernels after 5.10
> and with RPi4. The RPi4 works with stock Debian kernels (and supposedly
> stock upstream kernels), runs straight arm64 just like other devices
> and boots debian netinstall installation directly as long as you copy
> it over onto an UEFi partiton with the UEFi EDK2 files included.
> 
> > FreedomBox is a Debian blend, so a FreedomBox install *is* a Debian
> > install, there are no custom packages or other hacks. At least that
> > is how it is claimed to be, I haven't tried it.
> 
> I have not tried it either, but I am slightly worried about 
> small variations in the details. And I do not need the extra
> software they install (yes, I could uninstall, of course).
> 
> My most recent Pi4 is used for taking backups with restic over
> wireguard, so I more or less just need restic, wireguard, and
> ssh (plus the usual commandline utilities). It would feel wrong
> to install Freedombox, look what has to be uninstalled, look
> for potential specific configurations etc. 
> 
> > I assume because of the proprietary software needed to boot the
> > RPi4,a lthough there is a WIP libre replacement that isn't yet in
> > Debian, see other comments in the thread about that.
> 
> With "WIP libre replacement" do you mean the tianocore/EDK2/UEFi port
> here?
> 
> https://github.com/pftf/RPi4
> 
> Or something else? 
> 
> /ralph 
> 
> 


Reply to: