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

[lkcl luke]

On 7/30/12, Gordan Bobic <gordan at bobich.net> wrote:
> 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
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk
>