Re: iMX6 EOMA-68 CPU Card
On Thu, Feb 28, 2013 at 10:18:09PM +0000, Luke Kenneth Casson Leighton wrote:
> ... and how many powerpc fabless semiconductor companies are there?
> one? no, i can think of two: there's... ahh... freescale and there's
> IBM.
Sure, each of thich makes lots of chips, used on many boards with
different features enabled and pins connected differently.
> ... you recall that i mentioned that there are over 600 ARM
> licensees? how are you going to get that many companies, who are
> focussed *already* on the next product not on what the linux kernel
> developers feel has to be The One True Way Forward, to pay attention
> and talk to each other?
If some of the larger ones did get together, perhaps they could work
something out. Linaro to some extent looks like a promising method of
bringing some sanity to the state of linux on arm. If the rest want to
continue to waste their own (and everybody elses) time reinventing the
wheel again and again for no good reason, well that's their problem.
> Allwinner Tech actually developed their own alternative to
> devicetree, which should tell you everything you need to know about
> devicetree and how successful it's going to be in the ARM world.
Well I would love to see something better than devicetree. But machine
specific bring up code for each system in the kernel is just awful.
> lennart, you're missing the point. it's the sheer overwhelming
> number of different I2C, AC97, I2S, UART, RS423, LCD and other devices
> [*1] which are normally hidden from x86 developers behind something
> called "a BIOS" that is the issue.
And to those of us working with powerpc boxes, they are not hidden, and
devicetree handles dealing with them just fine in my experience so far.
> the assumption by the muppets that came up with device tree was that
> there would be some actual code which could be shared across multiple
> identical devices, each of which would of course just maybe be at
> different IRQs and maybe use different GPIO lines.
>
> the fact remains however that the average embedded hardware product
> requires something like TWENTY custom peripherals, where each
> peripheral chip, picked at random from an overwhelmingly large list
> many of which are under NDA or are only really available from
> face-to-face local meetings, are completely and utterly different for
> EVERY product that uses an ARM processor.
Parts with specs under NDA is a problem. Why so many part makers think
their chip is so special that they can't tell people what the register
map to use it is, I will never understand.
> the return on investment for any one hardware development team in
> deploying a "kitchen-sink interchangeable ratchet spanner set"
> solution like devicetree, when no two ARM embedded boards share any of
> the parts, and even if they did they're being developed in secret and
> then the source code dropped into the public some three to thirty six
> months *after* the product first hit the shelves, is utterly utterly
> negligable.
I don't think I am willing to believe nothing shares any parts.
There isn't an infinite number of part choices out there.
Of course if all they care about is getting a working product out the
door for which they never intend to do any updates, then creating an
unmaintainable mess doesn't matter to them. They don't seem to care
much about potential GPL violations either for that matter it seems.
> devicetree really is the wrong solution for such a disparate and
> disjoint environment.
>
> a workable solution would actually be to reduce the linux kernel down
> to about 200k lines of code, i.e. to *entirely* remove *all* device
> drivers from the linux kernel tree and have those as a completely
> separate project. forks could be maintained for each architecture of
> the core linux kernel code.
I see no reason that would solve anything, and lots of reasons it would
cause lots of problems.
> this would of course go down like a lead balloon on lkml, so we have
> to let the train wreck called device tree continue its way whilst 600+
> dis-coordinated ARM fabless semi companies all go theirs.
>
> l.
>
> [*1] note that i didn't include USB, PCI, PCIe, SATA, ethernet or any
> other buses in that? the reason's very simple: all of those have
> device identification protocols over the bus itself, and they're
> designed for removeable devices.
--
Len Sorensen
Reply to: