On Sat, Oct 29, 2011 at 1:47 AM, Mark Constable
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. _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE