Oldfeller--FSO wrote on 12/13/12 at 04:03:52:

Cool!  At a better price, they should make nice Linux Tablets!

Serowbot wrote on 12/12/12 at 17:50:30:



Oh I'm following along,   I may not be responding to this topic but I have been following it.   I have responded to the other 2 on the Arm processor stuff, and I have been playing around with the Hackberry boards that OF had suggested, plus I have a cubieboard that is now on the way,  confirmed shipping with a delivery date of Dec 19th now.  Might turn that one into a Home automation controller since it has all the GPIO's pulled out to header pins.

I've long been interested in the Arm Arch stuff, just been waiting for them to get powerfull enough to take over the x86 Arch and it looks like that may happen in the next few years for at least some applications at least.  There will still be a need for x86 hardware though for awhile but who knows maybe RISC might just surpass what we have now and allow Arm Arch to be able to process more then x86 hardware can.  Until then I my main development machine will have to stay as a x86 unit with as many cores as I can afford to keep in it.  As far as Winblows goes, screw them, for the most part I can get by without any Microsuck software at all, and for the few things that I need that require a Microsuck OS I'm sure they will run in Wine under Linux.  Linux is what I do most of my development in anyways.  

For the OS on the Microsuck side I'll stick with Win7 unless the version after Win8 comes back to a normal looking OS and not a Tablet or Mobile phone interface

R.F.

Oldfeller--FSO wrote on 12/15/12 at 20:23:20:


Only machine I have that uses Spintel is this lappy,  Everything else is AMD powered.  And yes I know under Winblows it's resource hungry. The processor in this lappy is one of the 3rd gen I7 mobile units though, can't remember which one atm for some reason.  Now my workhorse development machine is one of the AMD 8 core processors running water cooling at 4.3ghz and 16gb of ram.   Reason I have so much ram is for creating a virtual ram drive for when I'm doing code and I load the whole environment up in that drive and do all the compiling in there, combine that with the 8 cores and I can spit out a full clean compile of Android ICS in about 15 mins.  Yes I do all that under Linux as well.

Also I haven't used IE in years, been FF fan for many many years.

Well as I'm typing this on my Laptop, that hasn't been turned off in several days,  the processor is showing 0% use but the Ram usage is just a tad over 4gb, alot of that is because of have several things going on in the background along with all the usual resource heavy crap in the MicroSuck OS.  Not to mention FF is at a high memory use right now because I've been watching Netflix movies all night and need to close FF down and re open it to clear out it's Ram buffer as it just keeps building and building when it uses the silverlight plugin that is required for Netflix streaming.  I normally close out FF about twice a day depending on how much I stream off of Netflix because of that issue.  Also my Ram usage may be alittle higher then most because I disable swap since I use a SSD on both my Lappy and my main development machine as well since I have plenty of Ram.  8Gb on the lappy and 16Gb on the Development machine.

Well, there have been some new Linaro Conferences in Europe this past weekend, where most of the ARM and Linaro dudes were presenting A53 and A57 systems intergration and talking about integrating 64 bits into the Linux kernel and all the various sub systems.

Kernel 3.7.x will come out with all the stock ARM drivers for all of the ARM chipsets all the way up through 64 bit A53/57.

It will come out with all the Mali graphics drivers built in, up through Mali 678 (16 graphics cores).

Big LITTLE is totally cooked now and is already in the kernel, coming out in 3.7.x.

What was discussed in some boring detail was the secret driver boys, specifically VR graphics which are held under total non-disclosure by VR.
   
This sucks for consumerdom, because APPLE uses VR graphics and so do most of the other "retina display" chipsets that have been released to date.    

VR won't play with open source at all as their whole competitive advantage must be kept a total secret or they have no advantage in the marketplace at all.

Linus isn't going to accept those chips into the kernel until the providers offer "comprehensive driver packages" which will enter into the open source agreement just like everybody else does.   VR won't do this.

So, new ARM chipsets running Mali graphics will be fully supported by Linux for updates, etc. right in the kernel updates going out into the future,  chipsets where the vendor won't release his drivers won't be.

Android's upcoming merge back into the mainstream kernel was discussed, with all custom video drivers guys being very pointedly excluded.

Android vendors have been told and shown what they must do to be supported by future releases of Android and Linux.    

Issue becomes that the Chinese simply don't care -- if they can tweek up something to put on a prom that works "good enough" at time of point of sale with their "as shipped custom version of Android" they are not looking back at all (there is no post sale software support in China, period).    We got your money, dude .....

Korean companies are not quite that bad, but close to it.

So, look for a great ARM divide to develop in the future,  between the fully supported and upgradable products and the cheaper "works as shipped" products.

"Linaro Android/Linux Certified" will be come a cert to look for when buying stuff.




==========================   new stuff




A53 and A57 are coming out as a 64 bit "sea of cores" implementation.  You can mix and match ANY mixture of A53 and A57 cores in any quantity your want.  

Things given in the slide show as future examples are kinda scary, one single A53 core and count them (12) A57 cores for a heavy duty video redering workstation was shown as an "completely competitive low cost" system configuration that is supposed to cost 1/4 as much as a current video workstation.

For low energy server farms, an endlessly expandable system of A53 or A57 cores on plug in cards (each card carries the proper support systems memory and I/O chips) --  you just hot plug in whatever mixture of cards you need for your current workload configuration and if the workload shifts or grows on you over time, well you just shift your mix of processor cards accordingly.

A power user with a workstation type set up could add whatever he wanted, so the built in expandability means you could buy into a supercomputer system over time if you wanted to go play that way.   You would never become "obsolete" again.    (yeah, right)

Low end cell phone and tablet systems would be A53 driven, in dual, quad, and octa configurations.    Laptops and desktops would have a mix of a few A53 and some "increasing according to max processing load needs" A57 cores.

Android/Linux will be continuously upgraded to use all the cores using the ARM/Linaro developed core management system, so yes finally multicore computing will get USED properly by software.   This will be the case from kernel 3.7.x forward.


NOT A WORD WAS SAID ABOUT MICROSOFT -- they had no presence at the conference at all.  

Intel was there, to promise ongoing competing processors that would run Android/Linux natively and offer "superior value".   Intel intends to compete, not conform.   But they will offer over complete driver packages to the kernel group in advance of each new product offering.

This means the 6 new chips they promise for 2013 just got moved back into 2014 since once they have build them they have to get the support drivers into the kernel, which gets a major update every six months to a year.  

Or Intel can pre-release the drivers, but then they are rolling craps that the chips will work out exactly as anticipated when the wafer line rolls.

Note:   ARM does this driver pre-release thing, and has hit it on the nail head every time so far for those vendors who have bought their hard macro chip designs.  They do it by a qualification run of that exact design at TSCM on the actual production process it will run on, which is all part of their hard macro design guarantee.    

You buy into an ARM hard macro quad core A15 design with a Mali 678 graphics system, it just works upstream to the Android/Linux software and downstream to the actual TSCM production wafer line.

Problem is your two worst competitors just bought the exact same system and put their processing time order into TSCM before you did -- you lose.

Fastest one to market wins, every time .....