
"The ARM architecture is growing in popularity and is expected to expand its reach beyond the mobile and 'small embedded' device space that it currently occupies. Over the next few years, we are likely to see ARM servers and, potentially, desktops. Fedora has had at least some ARM support for the last few years, but always as a secondary architecture, which meant that the support lagged that of the two primary architectures (32 and 64-bit x86) of the distribution. Recently, though, there has been
discussion of 'elevating' ARM to a primary architecture, but, so far, there is lots of resistance to a move like that."
Member since:
2006-01-28
Yes, it's called a firmware. It's not only about the platform configuration tables (ACPI & others that 99% of existing ARM implementations don't actually offer). It's also about having a scan-able bus architecture for discovering devices (like a PCI bus on most systems) which would allow the starting of the required drivers (compiled in the kernel). It really is what Plug and Play really offered. Until Plug and Play appeared YOU had to know what devices you had and what settings they used (I/O ports, IRQ, DMA, etc.). After plug and play, you only had to provide the driver, the discovery and basic configuration was done by the OS or firmware and the Bus.
My point is that most ARM implementations actually are missing that plug and play part that normal PCs always offer. If upon booting the Linux kernel doesn't find a VGA class PCI device it will not display anything, even if there is a certain memory range available as a frame buffer. How can Linux know about that?
Now regarding Secure Booting in UEFI. There are 3 things to look at when you're talking about it:
1) The actual UEFI. A good thing as it might allow a single Linux kernel for all hardware.
2) The secure boot locking. This is what everyone is complaining about. Microsoft requires that a user can't change the keys for booting a system. It's a bad thing.
3) The secure boot keys. Microsoft does not require that the locked keys are only the ones that the provide. So, in theory, an OEM could include the keys from RedHat or Ubuntu. It's certainly incompatible with a GPLv3 boot loader, but it would still work with any other license both technically and legally. It might work for us if we pressure the vendors to include a single CA (OSS CA). Then again, it beats the purpose of the Secure Booting initiative as also a hacker could get stuff signed by it.