Linked by Hadrien Grasland on Wed 4th Apr 2012 06:45 UTC
Fedora Core "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."
Permalink for comment 512836
To read all comments associated with this story, please click here.
RE[5]: Comment by EvaTheDog
by d3vi1 on Wed 4th Apr 2012 16:47 UTC in reply to "RE[4]: Comment by EvaTheDog"
Member since:

Would it be feasible to have a shim layer for each ARM variant, but use one ARM kernel?

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.

Reply Parent Score: 2