[Arm-netbook] [fedora-arm] 1ghz ARM Laptop (12in 1280x800 LCD)

[Luke Kenneth Casson Leighton]

On Wed, Feb 2, 2011 at 12:05 PM, Gordan Bobic <gordan at bobich.net> wrote:

> The way forward here would be a SATA port. Anything else doesn't cut it in
> terms of performance, and even on something as low on CPU as an 800MHz A8
> still suffers significant slow-down when working off SD cards. This has a
> massive effect on perceived performance, especially with only 512MB of RAM
> for caching to cover up the deficiency.
>
> Annoyingly, I've not yet seen a production ARM based netbook with a SATA
> port.

 that's why i designed a standard based around having an SATA port,
even if it means converting to SATA.  so, the S5PV210 has CF/ATA (aka
IDE, UDMA Mode 5) and Genesys Logic (not to be confused with
genesi-usa!) have given me a very good quote on an IDE-to-SATA
converter.

>> I agree
>> wholeheartedly (see above..) with the video playback thing. A laptop
>> *only* good as a compiler box won't sell.
>
> Perhaps you can tell us, then, when the Efika MX will have accelerated
> drivers available? The video poing keeps coming up, but Xorg on my Efika MX
> is running off raw fbdev on mine and none of the standard acceleration APIs
> work (e.g. XV).

 *grins*.  gotta love texas instruments.  xorg-video-omapfb _and_ with
xv support he he.  sorry, matt, couldn't help that small dig, there :)


> One of the big problems with ARM SoCs is that a mature implementation (to me
> at least) means having good, stable drivers that are well supported and
> updatable for the rest of the OS stack (i.e. you want to make sure that
> there is a suitable Xorg driver when the distro moves to a new version of
> Xorg with a new ABI.

 this is chicken-and-egg, and it _requires_ someone to make the first
jump, tolerate things for a while and to badger the bloody SoC vendors
to stop with the stupid rules.


>> I'll say it again, if you want 2GHz, dual core, 16GB dual-channel DDR3
>> RAM, 800MHz memory controllers, go buy a PC. You're in the wrong
>> market. Neither ARM nor Freescale or even TI are designing chips for
>> power users;
>
> We're not talking about power use here. We're talking about "good enough".
>
>> the expected panel resolution is 1024x600. It's very
>> common.
>
> Oh come on. 1024x600 isn't really adequate. It only ever took off because of
> the initial rush to the market was driven by products that were as cheap as
> possible.

 the chinese market is ahead of the times (it's far bigger).  the
chinese home market has REJECTED the 1024x600 screen size.  and the
primary reason for that is that 800x480 phone sizes are about as
tolerable as 1024x600 screen sizes, yet the 800x480 fits in a pocket
and is not needed *all the time*.  for the chinese home market, 12in
is now considered to a minimum requirement.  it's only the rest of the
world which haven't yet caught on.

> run Linux on their x86 netbooks. I don't think it's sane to be speccing up a
> low-end system targeting the unclued-up users using unfamiliar software, and
> trying to compete with x86 on price. For the life of me I cannot see that
> being a successful business strategy.

 thaat's why i'm working on a strategy which gets well below the x86
price-point, but where the end-product range is flexible... don't want
to go into too many details.


> functioning mouse buttons. The geeks will likely get together and hack up a
> solution that makes the situation bearable. The rest will either send the
> product back as unfit for purpose, ebay it, or shelve it and never look at
> it again while spreading bad word about the product.

 PRECISELY, and this is why it is so so vital to get _something_ - a
product range that satisfied BOTH markets, so that geeks will begin to
do the work that the vendors themselves cannot even remotely
contemplate doing, or even understand.  geeks who are tolerant enough
of the foibles and who know that, at the end of the day, _after_ their
efforts, they'll have something that they're truly satisfied with.

>> Maybe when the Cortex-A15 is out and we have ARM servers floating
>> around,
>
> ARM servers are already floating around. ZT systems have released such a
> thing. It's not cheap, but if you are up against the wall on data centre
> power consumption and cooling it is well within the realm of plausible when
> it comes to value for money. It has dual core A9s in it (8 of them):
>
> http://www.ztsystems.com/Default.aspx?tabid=1483

 ahh, ha haaaaa, you're a starr, gordon.  i might be able to work with this.

> You may be right about an A15, but a large-screened A9 should be more than
> plausible today. The AC100 has a HDMI output and can (supposedly - haven't
> tested it myself yet) handle outputting a 1080 signal. I tried fitting a
> 720p panel into it, but Toshiba did some firmware "sabotaging" that makes
> higher res panels not work, but I don't have any reason to think this is for
> reasons for any hardware limitations, it's almost certainly a firmware
> issue.

 ARM CPUs don't have the concept of a BIOS, so the screen timings are
hard-coded into the kernel driver.  you *can't* just whop a new screen
in and expect it to work, you *have* to recompile the kernel,
hard-coding the hsync, vsync, offsets, hclock, vclock, pixel rate,
pixel density *everything*.

 fortunately toshiba have complied with GPL requests for the kernel
source code, so you can grab it and recompile.  also fortunately, the
boot loader system is now well-understood, if a little bloody awkward.
 so you can test new kernels booting off of SD-card by holding a key,
and you can blow away android entirely by writing to the internal
/dev/mmcblk0p6 partition.  no you _can't_ write to anything _but_ the
/dev/mmcblk0p6.  get the external boot working first otherwise you'll
be left without a means to recover after blowing away mmcblk0p6 ;)

l.