[Arm-netbook] Good netbook based on Cortex-A9

[Gordan Bobic]

On 07/30/2012 05:20 PM, lkcl luke wrote:
> On Mon, Jul 30, 2012 at 3:58 PM,<freebirds at fastmail.fm>  wrote:
>> On Mon, Jul 30, 2012, at 07:11 AM, Gordan Bobic wrote:
>>>>> Raspberry pis are preinstalled with Fedora.
>>>
>>> I thought they come bare without even the SD card.
>>
>> RS sells Raspberry Pi model B board: "Boots from SD card, running the
>> Fedora version of Linux."
>> http://uk.rs-online.com/web/generalDisplay.html?id=raspberrypi
>>
>> RS is also selling the Debian "squeeze" release on their website. The
>> ordering number number is 763-1030.
>>
>>> But images of most Linux distros are available for download, including Fedora, RedSleeve, Debian, Ubuntu, etc.
>>
>> The tutorials I have read on installing Linux on many ARM and MIPS
>> devices is much more complicated that simply dd image to SD card.
>
>   yes.  that's because of the difference between ARM or MIPS and the
> x86 system, with its BIOS and the much more prevalent use of dynamic
> buses such as PCI, PCIe, USB and so on.
>
>   let's take a look, as an example:
>
>   * the IBM original x86 PC: dynamic bus (XT), and a BIOS
>   * 386s from 1991: an upgrade of the XT bus to 16-bit: still dynamic,
> and still with a BIOS.
>   * 486s, 586s, 686s, P4s - all upgrades of the original XT bus: still
> dynamic, and still with a BIOS.
>
> so no matter what you get, with very few exceptions you can pretty
> much download any x86 distribution from any vendor and have the
> majority of the hardware work out-of-the-box.  i heard a story a while
> ago - it's probably not true any more - that you could even take a
> linux 1.0 kernel and stand a good chance of running modern
> applications on it.
>
> by contrast, let's take a look at e.g. the GPL-violating CT-PC89e:
>
> * a USB bus which we had to look up in the samsung 2.6.24 sources how it works
> * two GL850G hubs which we had no idea how to power up, because the
> GPIO pins were hard-wired to specific functions on the Samsung CPU
> * USB devices which we also had no idea how to power up, because again
> the GPIO and Reset pins were hard-wired to specific functions on the
> Samsung CPU
> * an LCD panel which we had no idea how to power up or even how to get
> it to function, or how to vary the brightness, nor what frequency it
> operated at, because it was directly hard-wired to the Samsung CPU and
> the information on how to control it was hard-wired into the
> GPL-violating kernel.
>
> so it took about 3 weeks of reverse-engineering, and me passing that
> information over to frans pop for him to write proper drivers in a
> clean-room fashion.  at the end of this 3 weeks there was NOTHING OF
> ANY VALUE TO ANY OTHER HARDWARE OTHER THAN THAT ONE SPECIFIC LAPTOP.
>
> and the reason for this should be very very clear: in ARM and MIPS
> products, there *is* no BIOS, and all the hardware is directly
> connected to the SoC.  when you get to the next product, the
> hard-wiring is often completely different.
>
> i've written about this before, but it's worth repeating: any
> GNU/Linux distro that is to run on ARM or MIPS hardware basically
> needs the linux kernel to be severely and heavily customised, because
> effectively the linux kernel *is* the BIOS for that device.

Not always the case. Reputable, Linux supportive SoC manufacturers like 
Marvell do upstream proper support for generic buses for their SoCs, 
which means you can take your *Plug, CuBox, etc and plug in a USB device 
or a SATA disk and it will "just work". It's GPL violating manufacturers 
who produce cheap and nasty throw-away SoCs that will last a year in the 
market at most that are the cause of the problem. There is a reason 
Marvell ARMs are so popular (apart from Calxeda, Marvell are the only 
other SoC manufacturer that have their chips in the upcoming high 
density ARM blade servers).

IMO, if the SoC manufacturer cannot be bothered to ensure support for 
their SoCs is upstreamed in a timely manner (timely in this case means 
before the SoCs ship into full production), there is no point in using 
their chips in any hardware you are making. It doesn't matter how 
cheap/good their SoC is, the amount of resources it's going to take to 
upstream kernel support is going to make it to expensive to bother with, 
unless you are only planning to bodge stuff for a one-off product and 
disappear before anybody actually asks for any kind of support.

> this is what is making it so damn difficult for enthusiasts.  first
> the reverse-engineering, then the attempts to run that
> heavily-customised linux distro on some completely unsuitable hardware
> (often with disastrous results - many people have bricked their
> expensive MIPS-based Linux TVs by trying to upload the wrong
> firmware), then *finally*, often just as the product becomes
> end-of-life, someone makes a decent "easy-to-install" firmware... but
> it's too late: nobody can buy that product any more, and the cycle has
> to start all over again.

So you agree, then - the solution is to not touch even with a very long 
barge pole any SoC that hasn't already got mainlined support.

> this is incredibly disempowering and it's why the rhombus tech
> initiative exists, to break this stupid cycle and to provide another
> way that is enriching for both the companies that subscribe to the
> EOMA initiative as well as to the software (libre) developers who also
> support it.

Do any/all of the SoCs planned for use in EOMA cards already have full 
mainlined kernel support?

Gordan