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."
Thread beginning with comment 512817
To view parent comment, click here.
To read all comments associated with this story, please click here.
Bill Shooter of Bul
Member since:
2006-07-14

[Right now I don't think that Fedora on ARM is doable but I applaud their attempt to make it happen.


Agree. They need to figure out how to reduce the compile time for the ARM ports. From the article it says it takes over a day as compared to an hour and a half for x86. By the time they solve that problem, I imagine a standardized ARM architecture should emerge. I just hope all of the systems are not secure boot locked out of booting anything other than win 8.

Reply Parent Score: 3

RE[4]: Comment by EvaTheDog
by Alfman on Wed 4th Apr 2012 14:06 in reply to "RE[3]: Comment by EvaTheDog"
Alfman Member since:
2011-01-28

Bill Shooter of Bul,

"I just hope all of the systems are not secure boot locked out of booting anything other than win 8."

One step forward, a hundred steps back.

I know there's no bios standard for ARM platforms, but does any know just how different the arm variants are in practice? Is it just a matter of missing the platform configuration tables to initialize the system, or are things really that incompatible in the kernel/drivers that we'd need dozens of different kernels?

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

Reply Parent Score: 3

RE[5]: Comment by EvaTheDog
by d3vi1 on Wed 4th Apr 2012 16:47 in reply to "RE[4]: Comment by EvaTheDog"
d3vi1 Member since:
2006-01-28

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