[Arm-netbook] Debian GNU/Linux on tablet hardware

[Luke Kenneth Casson Leighton]

On Sat, Oct 29, 2011 at 1:47 AM, Mark Constable <markc at renta.net> wrote:
> On 2011-10-28 07:50 PM, Luke Kenneth Casson Leighton wrote:
>> ...
>> it's an insane situation - i'm offering Free Software Developers
>> a "way out" of this insanity.
>
> Excellent disclosure of the reality of dealing with Chinese
> manufaturers. So you are suggesting the main problem is matching
> up an OS with the hardware, not the hardware itself.

 nggggggh YES, finally, someone gets it.  [i've done
reverse-engineering of 7 different ARM-based devices.  you do not want
to go there].

> A few months ago I made a plea for a non-netbook tablet solution
> to allow those keen to develop OS options a chance of getting
> something ready NOW while we wait for the "ideal" form factor
> parts to fall into place. Unfortunately the core point of that
> email, "give us something to develop on now", got buried under
> an assertion that any device won't end up in the hands of GPL
> tolerant western developers much under $300 retail/delivered.

 well... let me think....

nope, it's not true.

order 10 of these, you get them for $149 each:
 http://quickembed.com/Tools/Shop/DSP/201105/170.html

get 10 of those into one country in 1 box, sent with individual
shipping labels on each, split automatically once they're through
Customs, you don't have to pay individual shipping costs just to get
the damn things into the country.  franson might squawk at the idea of
having to put individual shipping labels on each item and _then_ put
them inside a larger box (addressed to the Customs Office itself!) but
it's a common enough technique, he may have encountered it before:
you'll have to ask him.

but it's _almost_ true - $149 for only 10of, plus tax, plus shipping,
it starts to approach $200 and a bit more...


but for these, it's definitely not true.

in 1-off prices, these are $99:
 http://quickembed.com/Tools/Shop/ARM/201007/118.html

and this one, split-level design, are $109:
 http://quickembed.com/Tools/Shop/ARM/201102/164.html

you can, in larger quantities, ask for a quote (minimum 3 so as not to
waste franson's time, please)

and they're S3C6410 ARM11s so you'd get a very _very_ approximate idea
of the speed of operating on a system-which-had-an-ARM11-CPU (see
below, please).  in each case, the developers would not need the LCD
screen, so it's obviously not included in the prices, and if any
developer asks you for one, you know they're trying it on, and not to
send them a device.

 note that on EVERY SINGLE PAGE, quickembed supply the GPL source code
with the device.

 but, regardless of cost or availability, i don't see what value
placing such a device into the hands of those developers would
actually bring to the table (see further below)

> Fortunately for all concerned, the Raspberry PI will change this
> situation forever in another 1/2 year (a few months after it hits
> the market) so the plea to get "anything" into the hands of said
> GPL-tolerant developers is about to be solved.

 what exactly are you after that cannot be solved by running arm-qemu?
 (which, btw, is quite tolerable on a dual-core 2ghz xeon).

 please please for god's sake don't tell me you expect the linux
kernel on the raspberrypi to be of any use to man or beast for any
other ARM-based device (including one which has the exact same ARM11
CPU).

 the only possible reason i can think of that _might_ be of benefit is
if the "target" device(s) which were chosen for loading FreedomBox
Software on were:

 * exactly the same CPU (ARM11 TCC8902 i think it is)
 * exactly the same amount and sized RAM
 * exactly the same RAM programmed in software to run at exactly the same speed
 * exactly the same NAND flash hooked up in exactly the same way.

 you would not believe the variation in speed which occurs by making a
change as quotes simple quotes as putting in faster (or slower) RAM or
NAND flash, or by changing the timings parameters on access to the
RAM.  just like in the x86 world, it's not just about "how fast the
CPU is clocked".

 so if you want (wanted) to get an idea of how fast a particular
system will be, then... you need to build that particular system!

 so again, with the greatest of respect i have to ask: what exactly is
the benefit that is gained, which cannot be had by using qemu-arm?

 qemu-arm would, by virtue of being slow, at least teach people to
write efficient code and scripts.  and cut out that god-awful system
that should never have been allowed to escape from the heads of the
people who dreamed it up, known as "d-bus".


> It seems the main block is between Chiness manufacturers and
> various western open source repositories that in most case have
> between 90% and 99.9% of ready-to-use source code.

 i'm... ok, what you're missing is that the last 0.1% (including the
last 0.1% of the 10% that you mention), is absolute hell on earth to
obtain.  the important bits - the absolutely absolutely essential
bits, without even just _one_ part of that last 0.1% and you are
f****d and might as well not have bothered with the _whole_ exercise -
is the platform-specific parts.

 ARM devices are *not* the same as x86 devices.  with ARM devices, the
*entire* knowledge of how to even do something as innocuous as "switch
on the WIFI" or "read the battery voltage" is hard-coded into the
platform-specific linux kernel.

there is *no* BIOS in the ARM devices world.

i repeat.

there *is* no concept of "BIOS" in the ARM devices world.

let's say you know how to program everything except switch on the
backlight, which happens to require that you power up GPIO pin 31
followed by GPIO pin 32 - how the hell are you supposed to know that?
and what happens if you don't do that?  the backlight doesn't work,
and you can't use the device.

let's say you know how to program everything except the WIFI, which
happens to use so much current starting up that you have to power it
on, reset it, switch it off, wait for 10ms, then power it on, wait
1ms, power it off, wait another 1ms, power it on, wait one more ms and
_then_ reset it, and it will then work ok.

if you don't know that sequence, and you don't know that WIFI "power
on" is connected to GPIO pin 27 and WIFI "reset" is connected to GPIO
pin 12, you're screwed.

btw, this sequence really _really_ was needed on one device i
reverse-engineered - it was for the GSM Radio Module not the WIFI
module though.  it needed so much current to power up that this was
the only way the original software developers could get it to start.

it gets even worse if you don't know how to power up the I2C bus, or
you don't know how to power up the USB devices which you're critically
depending on in order to gain access to a root filesystem or something
else... you see how the "oh yes it's just that last 0.1%" has turned
into absolute hell on earth, just over 1 bit or 1 byte?


> How can this blockage be removed

 you can't!  ok, you can, but as you probably got a hint, from the
last paragraph above, the time taken to get results is
disproportionately long.

 to do "active" reverse-engineering, you either the device *or* the
binary-only GPL-violating kernel (or usually both) require
reverse-engineering.  i.e. you need knowledge of the hardware (what
the pins do), you need the datasheets (which you often can't get), you
need to jailbreak the device, you need a license for the proprietary
reverse-engineering software,

 or, you must be prepared to do empirical testing, which takes
absolutely forever, risks blowing up the device, and you need....

 ... you've not done reverse-engineering, have you? :)

 just to give you an example: whilst it only took me 8 weeks to do the
first parts of the ipaq hw6915 reverse-engineering, where i got
virtually every single peripheral up-and-running, i was then stumped
for _three_ weeks trying to work out suspend/resume.  why? because the
parameters that were required to get the device out of "suspend" mode
aren't documented anywhere.

 another example: the HTC Universal (aka O2 XDA-II amongst other
things) took three _years_ to finally get the last piece working.

 oh, and i forgot to mention that in every case where there was a GPL
violation regarding the kernel, there was a GPL violation regarding
the u-boot source code and also witholding of critical information
regarding how to upload u-boot (and where) as well.

 so you if you screw that up, you have to open up the device (if you
haven't already), but worse than that, you have to get a soldering
iron out, or potentially de-solder the main CPU, put in a replacement
for the track or the blown e-fuse which was _deliberately_ placed
under the CPU just to make life hell on earth for anyone prepared to
do hardware-reverse-engineering, so that you can get access to the
JTAG port.

 by now you should appreciate that it's just... not worth the hassle.

 i've _been_ here, mark - not "oh yeah i heard about this
reverse-engineering stuff, surely it can't be that hard??" well i can
tell you it fucking well is.  i spent 12 weeks looking for one mistake
on sending data over SSP to a touchscreen; i've spent 10 weeks looking
for a single bit-change on NT Domains Network traffic.

 you do *not* want to go down this road.


> and/or why are Chinese manufacturers seemingly
> at the mercy of their ODM partners?

 it's not "seemingly".

 * anyone who refuses to sign the GPL-violating NDA simply... won't
get access to the schematics or the GPL source code, and that's the
end of it.  that's from the SoC vendors to the "first line" ODM
partners (!) who quotes misunderstand quotes that they cannot supply
GPL code under NDA, but they can always claim "it was for the
schematics, not the GPL source code.  really".

 * the ODMs then go "aw shit - we must force the manufacturers to sign
an NDA, and also sign the SoC vendor's NDA too, and even then we're
under NDA so we can't give out the GPL source code!"

 * even if they work with a "good" SoC vendor, the ODMs themselves may
"try it on", completely ignoring Copyright Law.

it's _complicated_ in other words.  there are a number of reasons,
because of variations in each case (of which i've dealt with about 50,
to varying levels.  i've learned to give up and not waste my time, i
have better things to do)

> Perhaps it's as simple is the mandatory English-only communication
> channels surrounding the western repositories.

 if that were the case, then those people should just release whatever
they have done, and let other people sort it out (who speak english).
as it turns out, they have to employ people who can at least read and
write english: it's source code, it's in english, and they can also
type "git commit" as it also turns out, because i've seen evidence of
this from tarballs of git repositories that ended up on "megaupload"
or other quotes legal quotes filesharing sites.

 so it's not - it's a cultural thing as well as a "sod you, we're in a
different country" thing, backed up by the inordinate cost of
prosecuting Copyright violations in China (from outside of China)

if you want to enforce GPL compliance across International Boundaries
(which is actually possible) you need to be prepared to pay at least
three legal teams (maybe you can cut the costs down to two, by using
the SFLC for one of them) because:

 * one legal team you will need in the country you're initiating the
lawsuit from
 * one legal team whom you pay for the contacts and also the knowledge
of how to go about suing companies across the specific international
borders that you're crossing.
 * one legal team you will need in the country of the company you're targetting

btw - all of this i mention not to "impress" you or anyone else (*) -
but to underscore and emphasise why it is that i'm saying that the
opportunity i've engineered is the way it is precisely because all
other options - all other paths - are closed, prohibitively expensive,
insane, or all three.

l.

(*) you think i'd be dumb enough to waste my time writing "oo look i
have a big ego, i _really_ want to tell everyone: isn't it impressive
that i did all this work, 3 years reverse-engineering and 2-years
negotiating with factories, and was paid absolutely nothing for it by
anyone to do that research, and got nothing for it - no payment at the
end of all that work whatsoever" you must be, with the greatest of
respect, completely off your trolley.  please get back on it: the men
in white coats will be back shortly.