Re: iMX6 EOMA-68 CPU Card
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. 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.
> this is why, basically, the development of gnu/linux OSes like debian
> for ARM embedded devices is, um... a bit slow on the uptake, shall we
> say. you start by pulling someone else' kernel code [and spend 2-3
> weeks working through it], or more likely you begin by
> reverse-engineering the hardware [expect that to take 2 to 36 months
> depending on complexity of the device].
>
> development of any board is an absolute 100% custom-job, costing
> usually around $10k for the board (in the EU and the US it's more like
> $50 to $150k) and you can if you are careful get away with around $6k
> for the casework (for a simple device). it could however be more like
> $100k or above (see openpandora for an example as to why that is).
>
> with x86 hardware, we simply don't see any of this. it's behind the
> BIOS, or it's a USB Bus device. or it's a PCI bus device. or it's a
> PCIe bus device.
>
> 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.
gpio-pch.c: Intel EG20T PCH GPIO pin driver. Current chipset for
Atom CPUs.
Whether there are GPIO pins on a normal PC motherboard, well maybe not,
but there could be.
> 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.
> many people - linus included - just have absolutely no f*****g clue
> how hardware-specific ARM embedded development actually is. nor how
> irrelevant one ARM fabless semi's products are to any other fabless
> semi's products, at a kernel level.
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).
So I can see why makers of cell phones and tablets just don't care.
There probably isn't much benefit to them. 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.
--
Len Sorensen
Reply to: