[Arm-netbook] "allwinner's A10" codenamed "sun4i crane", linux kernel v2.6.36 patch available

[Gordan Bobic]

 On Sat, 12 Nov 2011 13:51:48 +0000, Luke Kenneth Casson Leighton 
 <luke.leighton at gmail.com> wrote:
> On Sat, Nov 12, 2011 at 10:47 AM, Gordan Bobic <gordan at bobich.net> 
> wrote:
>> On 11/12/2011 01:09 AM, Luke Kenneth Casson Leighton wrote:
>>
>>> right.  on the basis of future mass-volume production deals, 
>>> allwinner
>>> very graciously released the GPL source code to RH Technology, even
>>> though they did not have to do so (even under the terms of the 
>>> GPL).
>>>
>>> the first cut of a diff/patch is here:
>>> http://hands.com/~lkcl/sun3i_sun4i_crane_2.6.32.patch.bz2
>>>
>>> linus is going to go ballistic at the 17mb size of the patch, but
>>
>> 17MB?! That's the first WTF. Does this include the Android patches 
>> or
>> something?
>
>  noo... it *sigh* includes hex-dumps of firmware for the on-board

 OK, that's not so bad.

>> Also 2.6.32 is positively ancient nowdays.
>
>  ahh, it's actually 2.6.36 :)  my mistake.

 Better. Would still be nice to have something recent enough to include 
 zcache without having to back-port it.

>> What is the
>> supportability/portability of this 17MB patch going to be going 
>> forward?
>
>  my attitude is, "if it works, don't push your luck, work with it
> until you can't".
>
>  this really really is the core of the entire problem associated with
> the platform-specific nature of ARM SoCs.... multiplied by tens to
> hundreds of SoCs multiplied by tens to hundreds of devices *using*
> those SoCs it's a complete nightmare, but we just have to push and
> push until the top of somebody's head unspins.

 It seems to me that the obvious place to push is SoC manufacturers - 
 until a basic standard is established the problem is going to continue 
 getting worse.

>  btw this is a situation that is only going to get worse, not better,
> until linus gets his head out of the cloud called "x86 architecture
> with a nice BIOS on top", accepts reality and accepts potential
> solutions.

 Endless code bloat isn't the solution, even if the SoC manufacturers 
 were to decide to provide long term support/maintenance of their kernel 
 contributions. The obvious solution is to come up with a standard ARM 
 BIOS - but the chances of that happening any time soon (and probably at 
 all) is pretty close to 0.

>  but yeah, in the meantime, you have to bear in mind that the
> discrepancy between "developers" and "industry reality" is a time-lag
> of potentially several years.  people were still using 2.4.19 and
> 2.4.20 in embedded systems up until about 3 years ago!

 The problem is that the "industry" cannot expect to be taken seriously 
 if they exhibit a fire-and-forget attitude. Companies like Marvell and 
 Nvidia are putting a lot of effort into making sure their CPUs are 
 supported in the mainline. In the process of porting RHEL6 to ARM, I 
 have found a LOT of patches from people at Marvell to make various 
 Fedora/RH packages build/work on ARM. A SoC manufacturer that isn't 
 prepared to put in that much effort cannot expect to be taken seriously 
 because it is clear they aren't taking the OSS community seriously. It 
 cuts both ways.

 The problem is that it is the end user that gets screwed because they 
 end up with a futureless device.

>>> * it's a Cortex A8, it takes up to DDR3 800mhz RAM, its external
>>> interface is 16gbits (2gbytes) but there appears to be a limitation
>>> internally of the Cortex A8 memory-mapping which truncates that to 
>>> a
>>> max of 1gbyte of actual RAM... but bizarrely, the NAND Flash
>>> Controller i've just learned can address DDR RAM 32-bit (??) as 
>>> well
>>> (what's _that_ about??)
>>
>> Now that IS interesting. So what would it take to put more RAM 
>> instead
>> of NAND there (probably not 32GB, but multiple GB at least)?
>
>  i have no idea - but given the multiple chip-select lines i think
> it's a definite "wooow" option that would, of course, have a massive
> power penalty.

 Sure, but I find it hard to take a device like this seriously with < 
 1GB of RAM. If these are expected to be servers, too, < 2GB is 
 stretching credibility to the breaking point. Even if this RAM would 
 only be addressable as a block device, having 4GB of extremely fast swap 
 would help a great deal.

>>> * top priority: an EOMA-PCMCIA-compliant and stand-alone computer,
>>> powerable via USB-OTG and having an HDMI interface and Micro-SD, 
>>> with
>>> at least 512mb RAM, 1gb NAND and this Cortex A8 which there are
>>> reports that it's capable of running at up to 1.5ghz.
>>> http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA
>>
>> Is an extra 512MB of RAM going to make THAT much difference to cost?
>
>  we just won't know until we find out what karen can easily get hold
> of.  it may turn out that there's a stock of 512mb ICs in a warehouse
> being cleared out at discount prices; this price *might* be less than
> what you can get the "absolute latest 1gb RAM ICs" at (due to volume
> pricing) but next month, that's it, you're a gonner, you can't get
> 512mb RAM ICs except at 4x the price.
>
>  welcome to "riding the wave"...

 Sure, but the problem there is that you end up with a lot of really 
 great value 512mb devices that nobody actually wants - at which point 
 you have some really expensive paper weights.

>>> the other possible product is to jam as many of these as possible,
>>> with 1gb of RAM each, running as fast as possible (1.5ghz?), into a
>>> 19in rack-mount and call it "the world's first and smallest modern
>>> ARM-based Blade Server" - yes, you may recall someone did an 8-way 
>>> ARM
>>> server oo gods know how long ago, it's somewhere on linuxdevices, 
>>> but
>>> that was... N to 1N years ago. ok the marketing sounds good, at 
>>> least.
>>
>> That was ZT Systems, if you are thinking about the one I'm thinking
>> about.
>
>  that's another one.  this little product was a cube, dating back i
> believe to 2006.

 November 2010:
 http://www.theregister.co.uk/2010/11/23/zt_systems_arm_server/

 The only problem with it a year ago was the price ($20K, including 8 
 Intel SSDs). If the pricing wasn't so outrageous I'd have bought a few 
 by now and wouldn't be partaking in this thread. :)

>>> * blade-like server, up to 32 1.5ghz 1gb RAM hot-swappable machines 
>>> on
>>> a multi-gigabit "hub" backplane in a single 19in Rack-Mounted 
>>> Server,
>>> possibly even with a built-in load balancer just for laughs.  well,
>>> why the heck not?  prototypes can be built out of putting 32
>>> EOMA/PCMCIA-compliant plug computers, together with 32 minimalist
>>> expansion headers to get at the 10/100 and the eSATA, and a 32-port
>>> off-the-shelf Gigabit Switch for goodness sake.
>>
>> You won't get 32 of them into a 1U chassis if you also want 1 2.5" 
>> (or
>> 1.8") SSD port, but this sort of thing sounds awesome.
>
>  ok, make it 16 :)

 Try about 10 if you want front-loading 2.5in disks in 1U. 5 if you want 
 the PCMCIA cards to be front-loaded too.

 Gordan