[HN Gopher] AArch64 Boards and Perception
___________________________________________________________________
AArch64 Boards and Perception
Author : pabs3
Score : 44 points
Date : 2021-02-22 09:03 UTC (2 days ago)
(HTM) web link (marcin.juszkiewicz.com.pl)
(TXT) w3m dump (marcin.juszkiewicz.com.pl)
| zokier wrote:
| I'm glad there is finally some standardization. The previous
| "Standards in Arm space" articles[1] are good illustration why
| this was needed.
|
| The LBBR spec seems nice, the article does mention that its for
| some hyperscale datacenter stuff but to me it seems like it could
| work well for sbcs too, but I don't know if I'm missing
| something.
|
| [1] https://marcin.juszkiewicz.com.pl/2020/10/12/standards-in-
| ar...
| tyingq wrote:
| I think the Rpi is perhaps the best example of the craziness.
| It's the GPU that actually controls the first few stages of
| booting.
| monocasa wrote:
| Sort of... There's two main architectures in the VideoCore. The
| QPUs are different than the main VideoCore, and the main
| videocore (which is also what runs the boot code) isn't really
| the GPU.
|
| For a long time neither were documented so people just sort of
| assumed they were the same thing.
| tyingq wrote:
| Well, yes, but changing how the initial boot code works still
| means changes in the thing we call the "videocore firmware",
| right?
| monocasa wrote:
| Yeah, but lots of SoCs have special boot and SoC management
| cores with a different ISA. The Tegra X1 in the switch uses
| an ARM7, CortexMs are in vogue in a lot of designs, AMD and
| Intel have the PSP and ME respectively, and even the SiFive
| SoCs have a E core that boots the main core complex of U
| cores.
|
| In none of these cases (including the RPi) is this core the
| GPU.
| tyingq wrote:
| Appreciate the clarification, but your paragraph above is
| exactly what I was getting at. Roughly that "the article
| is right...ARM booting on dev boards is a crazy world".
| As crappy as legacy BIOS and UEFI is, booting on x86/x64
| is more standardized, despite things like PSP and ME.
| egil wrote:
| Imho the most important part of the x86 standardization
| is the IBM pc platform. Arm boards doesn't have an
| equivalent platform to standardize on, so everybody does
| their own thing.
| als0 wrote:
| BSA and BBR specs from Arm fix that. They also have a
| certification program
| https://developer.arm.com/architectures/system-
| architectures...
| monocasa wrote:
| I find it unfortunate though that quite a few of the
| requirements for those standards is "buy more ARM IP
| blocks" rather than asking defining blocks that can be
| implemented by others.
|
| It feels like a self defeating cash grab.
| colejohnson66 wrote:
| There is the device tree[0], which Linux uses to know
| where all the ports are on an SoC. It's become the de
| facto standard for ARM. Even non-Linux OSes like iOS
| adopted it.
|
| [0]:
| https://www.kernel.org/doc/html/latest/devicetree/usage-
| mode...
| monocasa wrote:
| Interestingly, Apple's use of device tree is older than
| even ARM's and Linux's. It was part of OpenFirmware and
| used in almost all of their Macs (and Mac derived lines
| like iOS) since the PowerMacs gained PCI slots. Even
| Intel Macs would use device tree internally too, for
| instance passing the user's password in the FDE unlock
| screen in the bootloader to the main OS via a DT chosen
| variable.
| monocasa wrote:
| The point I'm getting at is that sub cores to boot a main
| core isn't a crazy world, and you're stuck with the same
| thing on almost all x86 designs as well.
|
| It's not where you should be looking at if you want to
| make the ARM booting space any better.
| [deleted]
| StillBored wrote:
| In the end none of that really matters, as evidenced by the
| PFTF* bringing it into compliance with the relevant standards.
| The UEFI/ACPI stack is sufficiently abstract that it has
| allowed x86 to evolve and scale from little embedded devices
| like the atomic pi, to HP superdomes using the same basic OS
| for a couple decades.
|
| So the low level boot mechanisms on Arm SBC's don't really
| matter because they are just used to boot a SBC specific UEFI
| image. The UEFI image then provides a standard mechanism for
| booting your OS of choice. The fact its taken 15+ years for the
| arm ecosystem to notice this, might be an interesting thing to
| study.
|
| * https://github.com/pftf (SBBR-compliant (UEFI+ACPI) AArch64
| firmware for the Raspberry Pi)
| monocasa wrote:
| It's more complex than that. One of the major reasons why
| there isn't a universal ARM standard of booting is that once
| you've gained control of execution, now you just have a bunch
| more per SoC work that needs to happen in the kernel compared
| to x86. ARM is simply far far far more heterogeneous on much
| deeper levels than x86-pc.
|
| "Well, ARM just should be more standardized on it's hardware
| interface then", is a common refrain I hear then, but that's
| just nerfing a major benefit of ARM in the first place, that
| it didn't have all that legacy cruft or an extremely
| heavyweight interface to everything like PCI is.
| monocasa wrote:
| > I heard several rumours about why ACPI. Someone said that ACPI
| was forced by Microsoft. In reality it was decision taken by all
| major distros and Microsoft.
|
| Microsoft went out of their way looking for methods to make ACPI
| not work well with Linux. And Microsoft viewed ACPI as their spec
| that they didn't want Linux "getting for free".
|
| http://antitrust.slated.org/www.iowaconsumercase.org/011607/...
|
| And it's not like the distros had a choice. ACPI is the only way
| to, for instance, enumerate other cores than the boot processor
| on x86. Features as simple as SMP requires ACPI on x86.
| danhor wrote:
| I'm pretty sure it's referring to the use of ACPI on AArch64,
| which came way later and was (probably) primarily implemented
| to run linux.
| ryukafalz wrote:
| I'd like to see phones get to that level of standardization too.
| Maybe wishful thinking. But imagine being able to grab a generic
| GNU/Linux image and slap it on your phone no matter what that
| phone is!
|
| I suppose the only phone manufacturers that are at all likely to
| do something like this are companies like Purism and Pine64.
___________________________________________________________________
(page generated 2021-02-24 23:00 UTC)