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

[Gordan Bobic]

Luke Kenneth Casson Leighton wrote:
> 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*.

So, I should blame the kernel for not reading the EDID on the panel? Can 
you point me at the relevant bit of the kernel code? If you're right, 
then a 720p panel may not be implausible. But my understanding is that 
the screen gets setup by the boot loader, and the Tegra FB driver just 
works based on that, it doesn't configure anything itself. If that is 
the case, then the boot loader itself would likely need to be 
reconfigured, or the TegraFB driver taught to configure the display 
geometry. The latter may be difficult given that nvidia aren't exactly 
renowned for publishing their specs.

>  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.

I just use the recovery kernel partition image to boot non-andorid.

>  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 ;)

Yes, I know how it works. :)

Gordan