Re: iMX6 EOMA-68 CPU Card

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

On Thu, Feb 28, 2013 at 10:32 PM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
> On Thu, Feb 28, 2013 at 09:54:59PM +0000, Luke Kenneth Casson Leighton wrote:
>>  they do have to be that different.  just changing from a phillips
>> audio chip to an Akai 4641, it's like... utterly, utterly, 100%
>> different.  there *are* no standards.  *everything* is different.
>> even the philips audio chip that was being used in 2 different devices
>> was used by one company with its I2S interface (which of course went
>> onto different I2S interfaces i.e. different pins) but the other
>> company chose to use it in a different mode.
>>
>>  HTC also decided that the standard (internal, non-accelerated
>> frame-buffer) LCD interface was too slow, so they used an Imagination
>> (ATI) accelerated and memory-mapped low-power GPU for a few revisions.
>>  when i contacted people on arm-linux and said "i'm doing kernel
>> development for a PXA270 and am having a bit of trouble bringing up
>> the LCD on the GPU" they went "unf?? wtf??  suuurelyyyy you just
>> initialise the PXA270's LCD lines, riiiight?"
>>
>>  the HTC Universal was just... unbelievable.  there were over 192 GPIO
>> lines.  110 of them were on the PXA270 (every single one of them was
>> needed).  64 on a separate ASIC chip which HTC developed specifically
>> for the purpose of extending the GPIO for processors that had limited
>> pins.  and because even that wasn't enough, an additional *sixteen*
>> GPIO lines which were actually on the GSM/3G Ericsson Radio chipset
>> also had to be used.
>>
>> so if you wanted to set the camera light on, or activate "car phone"
>> audio mode, you had to send an AT command over the USB-serial line in
>> order to do it!  which meant that you actually had to bring up the
>> GSM/3G modem before doing anything with those 16 GPIOs.
>
> I think I am going to pretend cell phones don't exist.

 :)

>  No wonder Android
> updates never happen for most phones when manufacturers make them all
> that different.

 in a word... yeah.  the HTC Universal was pretty unusual, though.  it
was well ahead of its time.  not that there are many clam-shell
smartphones around with swivel-screens even now.  but... five
speakers, two microphones (one on each side of the screen), and at
least five other audio paths including a record function, headset ,
bluetooth, car-phone and stereo media player for goodness sake!  and
that's really kinda normal (other than the twin earpiece and twin mics
because of the swivel screen - one on each side)

now you also see why we as debian-arm developers when we keep getting
asked by users "can y' help me put debian on my phone or my tablet"
the answer pretty much has to be "no, not unless you're prepared to do
a hell of a lot of work, starting from tracking down the linux kernel
source code and toolchain, and then maybe in about 3-4 weeks you
*might* be able to get back to us and ask about the OS that goes on
top of it".

and that's something i'm not really very happy about.  whilst everyone
*can* buy lovely cheap mass-produced hardware, the fact that it's
running a linux kernel is pretty much irrelevant.

hence the reason why i'm pursuing the rhombus tech initiative: i
really do need the help of the debian-arm community, and the
fedora-arm community, and suse, and... everyone, basically.

 ok, let me put that another way: i'm *going* to arrange for
hacker-friendly EOMA-compliant mass-produced hardware to make its way
into the mass-volume marketplace.  without free software developers'
cooperation, it'll most likely end up primarily in china, first. with
their cooperation, it'll end up in the rest of the world a bit
quicker, and also make the job of getting it into china (more diverse
OS support) a bit easier, too.


>  I suppose it would make them cost more to try and make
> them more consistent, and cost matters to such devices more than the
> savings in development time if they were more similar.

 well... you say that, but look at what happened with openmoocow.
some of the chips they wanted to use went end-of-life on them.  mind
you if you take 3 years to develop hardware because you don't listen
to industry-standard advice from R.F. engineers who tell you "don't
put that there because when the GSM starts up it'll cause R.F. feed
back into the microphone", and you try to develop an entire OS from
scratch rather than just release to a developer-driven community
something that uses e.g. gphone or hell even a command-line
phone-dialer or just... compile up minicom for god's sake, then what
do you expect?

 but yes, component cost is critical, but development time is as well.
 and timing.  product release timing, that is.  usually xmas sales for
E.U and U.S., but in the U.S. there's a second target a little bit
earlier of "on the shelves by thanksgiving".


>>  when was the last time *anyone* programmed the GPIO lines of an x86
>> motherboard?  can you get datasheet information from any of the
>> motherboard manufacturers on how to program the GPIO?  do there
>> actually exist any linux kernel drivers that allow you to change or
>> read the state of those internal header pins you see on x86
>> motherboards?  if they do i will fall off my chair [it's quite a long
>> way, it's a bar stool].
>
> Ehm, yes you can, and not very long ago.  Some people have Atom processors
> that have GPIO lines used for things.  I would also suspect a number of
> things in laptops are done with GPIOs, but hidden behind the BIOS/ACPI
> access functions.

 ... sorry - i meant the average person [ok, the average linux user].
so yes, the point is: the use of GPIOs on most x86 systems are simply
unheard-of.  and yes, it's a BIOS function.  you certainly don't get
direct access to the GPIO by poking a memory address!!!

> Whether there are GPIO pins on a normal PC motherboard, well maybe not,
> but there could be.

 there are....  kontron, commell and so on.  it's usually for
industrial PC usage, but the assumption is that they're for use with
windows.  and even if gnu/linux is supported, which is rare, it's done
via a binary proprietary library - no source code.

>>  when was the last time - apart from the fan, battery and temperature
>> sensors - that anyone programmed an I2C bus device driver on linux for
>> an x86 motherboard?
>
> Well eeproms too for memory identification, and DDC for monitor
> identification.

 true.  perhaps I2C wasn't a good example, because it's a bus - and
there's usually only one of them - and the devices on them are usually
set up to be identifiable.  and the pins for that bus are dedicated,
not multiplexed onto a limited number of pins.

 gahh, i forgot about port / pinmux!  that's another thing that
doesn't exist in the x86 world....


> I guess it becomes a conflict between people like me that want a device
> to be supported long term by having it supported in the mainline kernel
> and easy to support with a standard distribution long term, versus the
> cell phone and tablet makers that want to ship a new fancy device as
> quickly as possible and then go on the the next device, after which there
> is no reason for them to give a shit about what the end user might like
> (they should buy the next model after all if they want an upgrade.
> The Phone has the features promised at time of sale after all).

 in a word.... yeah.

> So I can see why makers of cell phones and tablets just don't care.
> There probably isn't much benefit to them.

 absolutely none whatsoever.  in fact, these whining little fucks who
keep on insisting that they give them their secret source code which
is of course entirely owned by them, well fuck that's just profit down
the toilet, isn't it, even to just answer the phone to string them
along, isn't it??

>  On the other hand makers of
> servers and single board computers (who would want other device makers
> to buy their SBC for use in other products), should care since you are
> expecting longer term use and development to take place on such systems,
> and maintaining things outside the Linus's kernel tree is just a huge
> hassle long term.  For those having more consistent methods and less
> random custom stuff would really help.

 yes.  those companies who do long-term support and actually need the
cooperation of their customers, and who are quite likely to need to do
a kernel build or an upgrade, that is an entirely different matter.
much smaller market though...

l.