Re: iMX6 EOMA-68 CPU Card
On Thu, Feb 28, 2013 at 7:38 PM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
> Of course it would seem that if the HTC phones are that different from
> each other while doing essentially the same things, then the hardware
> designers are designing them wrong. If they don't have to be different,
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.
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].
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?
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.
l.
Reply to: