On 10/20/2013 01:00 PM, luke.leighton wrote:
the situation that all arm-based gnu/linux distros face is the stark reality of ARM systems having absolutely no concept of a BIOS of any kind in any way. having repeated this enough times in enough forums i think it's finally beginning to be recognised.
The problem isn't the lack of BIOS - the problem is the lack of standards, specifically related to bootstrapping ARM CPUs. Perhaps I am nitpicking, since the two amount to the same thing in practical terms.
there isn't going to be a "solution": the sooner that's accepted the easier things will become for people. they can e.g. pick a particular SoC or a particular piece of harware and get that up-to-scratch for example, rather than going "wtf??".
I'm not so sure that is the case. As is has usually been the case in the past, I suspect the first overwhelmingly popular product will be what sets the standard that everything else is going to have to support in order to be considered.
in the x86 world, the problem goes away by virtue of the x86 world being effectively a total design monopoly: external peripherals, monolithic BIOS and so on. the hilarious irony is that as intel tries to cross over into the ARM world (e.g. the Quark X1000) they apply those "external peripherals" design rules with what will turn out to be disastrous results. i never thought i'd say that a monopoly is actually a good thing, but it is.
I think you are confusing monopoly with consensus.
the alternative is that in any two near-identical bits of ARM-based hardware even when they use the exact same CPUs and even the exact same ICs the chances of them being able to use the exact same kernel is absolutely zero. all it takes is for the designers to have used a different GPIO pin for a different purpose than the other design and that's it, you're f*****d. now multiply that across 650 ARM licensees each making in total thousands of different SoCs, now multiply that across tens of thousands of peripheral ICs many of which do not have publicly-accessible datasheets, and then multiply that across the number of products.
It sounds more like the problem is that the ARM "standard" isn't in fact a standard but more of a guideline that nobody sticks to.
... is it any wonder then, that when reverse-engineering 9 HTC smartphones we ended up with *TWO HUNDRED AND FIFTY* platform-dependent files? the only reason there were *only* as few as 250 files was because the designs all used the same Intel PXA 270 processor and they all used the same external peripheral-extender IC (we called it "ASIC3").
The good old days of the HTC Universal. :)
basically what i'm trying to get across is that if you, fedora-arm, continue to wait until this situation "stabilises", you are going to be waiting for a very very long time. now, i'm dealing with this from a different angle: standardising the hardware via something called EOMA68. we throw a stake in the ground: there are *zero* optional interfaces; you get SATA, Ethernet, USB2, I2C, RGB/TTL and 8 pins of GPIO on a credit-card-sized module (re-using PCMCIA if anyone's interested). on the other side of the interface (I/O boards) you're forced to extend the I/O using e.g. embedded controllers and so on.
I'm not sure this is really related to the previous paragraphs - it doesn't mean that a different EOMA68 card implementing all of the same interfaces will be bootable using the same bootloader or kernel.
Gordan _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
