Re: iMX6 EOMA-68 CPU Card
On Thu, Feb 28, 2013 at 7:41 PM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
> On Thu, Feb 28, 2013 at 01:33:14PM -0600, Bill Gatliff wrote:
>> Part of me regrets being as positive about DT as I was on LAK back
>> when the decision was made. But I had just come off of a PowerPC
>> project, and it worked pretty well there and so I figured, "why not?".
>
> Yes on powerpc devicetree really does work very well.
... and how many powerpc fabless semiconductor companies are there?
one? no, i can think of two: there's... ahh... freescale and there's
IBM.
> I really don't
> see why it couldn't work that well on ARM.
... 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?
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.
>> I do think that DT is a good idea, and the runtime overhead is a
>> manageable problem. But it's a good idea because it creates the
>> opportunity for post-compile-time flexibility, which CAN make some
>> board files go away. Not nearly as many as some of us thought they
>> would however, and not without effort.
>
> I don't see any overhead other than maybe a tiny bit when the driver
> starts to determine what IRQ or GPIO line to use for a given device.
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.
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.
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.
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.
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.
Reply to: