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 -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130228223254.ga20...@csclub.uwaterloo.ca
