Multiplatform Linux kernel 'pretty much done' says Linus Torvalds Linus Torvalds has announced the first release candidate for version 5.19 of the Linux kernel, and declared it represents a milestone in multiplatform development for the project. After first commenting that the development process for this version has been made difficult by many late pull requests, then applauding the fact …
Linus himself uses the quotation marks so I appreciate it's not to be read naively, but in what sense is the generic ARM stuff more 'multiplatform' than Linux has been until now? Is it about supporting something that's a little less cohesive than a traditional hardware platform, i.e. various vendors all providing very similar runtime environments but doing whatever they feel like with regards to startup — boot loaders, device trees, etc?
AIUI it's more or less the opposite: it's about having most ARM devices be able to boot a 'generic' kernel, like x86_64 systems generally can, rather than different ARM platforms needing their own custom kernel builds. https://lwn.net/Articles/496400/ is an article on it from 2012.
I wouldn't say I'm overly familiar with it but from other platforms I gather it is largely about the ARM ServerReady initiative. Historically x86 has had the benefit that essentially everyone follows the rules for IBM PC compatibility. That puts basic devices at known locations, the BIOS provided a uniform boot environment, and later buses (PCI(e) or USB) provided built in enumeration capabilities to pick up the rest.
Historically none of the above has applied to ARM which is why you will e.g. have a Raspberry Pi kernel as opposed to a generic ARM kernel. Linux's structure has traditionally not been ideal either - device drivers are not isolated from the details of the bus they connect to - which results in a fairly thick adaptation layer for any specific platform.
The ServerReady initiative covers the initial boot environment too but that is beyond the scope of the kernel - the kernel only starts once it is already loaded. Ultimately the aim is to permit generic ARM operating systems rather than a bespoke system for each platform.
Historically, ARM systems have always had a very different architecture from IBM/PC/Intel standards. Whether it was the CPU pinout, the motherboard chipset or the various protocols between them, they were incompatible. Even the CPU instruction sets were so different that you needed different source code for the compiler to turn it into an executable binary.
Somebody first hacked a Linux kernel to boot on an ARM system back in the days of the Acorn RISC PC, successor to the Archimedes (back in the late 1980s, IIRC). Then ARM spun off and as its licensing business model took off, systems houses slapped it into their own proprietary architectures and hacked their own versions of ARM Linux plus its toolchain. It all became nigh-on unmaintainable.
Eventually, enough was enough, and the process of unpicking the insanity began, but by bit pulling all the disparate houses into tune and rolling the common standards into the main kernel tree.
What Linus is saying that that this process is now more or less complete. You can now do a regular kernel pull, compile it on something like GCC and, without further faffing around, run it on most ARM systems around today.
The Intel StrongARM was probably the first licensed genie out of Pandora's box, even when ARM was still within Acorn. I don't know the technical details, but evidently it does not play nicely with the modern standards. My guess is that Intel were playing embrace, extend, extinguish but ARM somehow wriggled out of it and left Intel holding a lemon.
The StrongARM implementation originally began at DEC, as they were searching for a low-power design after realizing that a low-power 20164 Alpha wasn't possible.
"According to Allen Baum, the StrongARM traces its history to attempts to make a low-power version of the DEC Alpha, which DEC's engineers quickly concluded was not possible."
https://en.wikipedia.org/wiki/StrongARM
From the commentary on the HPE Baseband Management Controller (known as iLO, Integrated Lights Out), the main feature that all of us need is an option to disable it.
It is unsafe. It has always been unsafe. It has no hope of being safe in the immediate future.
https://www.blackhat.com/us-21/briefings/schedule/index.html#hpe-ilo-firmware-security---go-home-cryptoprocessor-youre-drunk-23398
Malware infecting iLO cannot be removed - junk the server.
https://latesthackingnews.com/2022/01/02/new-ilobleed-rootkit-targets-hp-integrated-lights-out/
It needs an off switch.
Do you see this right here? This means iLO.
'Another item of interest is the beginnings of support for the HPE GXP architecture.
'As explained by HPE chap Nick Hawkins, the architecture uses ARMv7 and the Cortex A9 core and will become a key feature of the company's next-gen servers.
'But not as CPU.
'"The GXP is the HPE BMC SoC that is used in the majority of HPE Generation 10 servers," Hawkins wrote. "Traditionally the ASIC will last multiple generations of server before being replaced."'
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
