Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752835Ab3EFGxR (ORCPT ); Mon, 6 May 2013 02:53:17 -0400 Received: from mail-ia0-f175.google.com ([209.85.210.175]:65423 "EHLO mail-ia0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752423Ab3EFGxQ (ORCPT ); Mon, 6 May 2013 02:53:16 -0400 MIME-Version: 1.0 In-Reply-To: <51872CF6.5070409@gmail.com> References: <51872CF6.5070409@gmail.com> Date: Mon, 6 May 2013 07:53:15 +0100 X-Google-Sender-Auth: rC-7iPxeysOIabmInvzsc4QtTMQ Message-ID: Subject: Re: device tree not the answer in the ARM world [was: Re: running Debian on a Cubieboard] From: Luke Kenneth Casson Leighton To: Robert Hancock Cc: David Goodenough , debian-arm@lists.debian.org, Linux Kernel Mailing List , Linux on small ARM machines Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 7058 Lines: 147 On Mon, May 6, 2013 at 5:09 AM, Robert Hancock wrote: >> and that's just within *one* of the fabless semiconductor companies, >> and you have to bear in mind that there are *several hundred* ARM >> licensees. when this topic was last raised, someone mentioned that >> ARM attempted to standardise on dynamic peripheral publication on the >> internal AXI/AHB bus, so that things like device tree or udev could >> read it. what happened? some company failed to implement the >> standard properly, and it was game over right there. > > > Admittedly without knowing much background on the situation, that seems like > a bit of a cop-out. i don't either - i may have the details / reasons wrong. it's probably more along the lines of "as a general solution, because so few people adopted it plus because those who did adopt it got it wrong plus because it was too little too late everybody gave up" > In the PC world there are a bunch of devices that don't > follow standards properly (ACPI, PCI, etc.) and we add quirks or workarounds > and move on with life - people don't decide to abandon the standard because > of it. in this case i believe it could be more to do with it being added some 15 years *after* there had been over 500+ ARM licensees who had already created huge numbers of CPUs, each of which is highly specialised but happens to share an instruction set. > >> >> >> are you beginning to see the sheer scope of the problem, here? can >> you see now why russell is so completely overwhelmed? are you >> beginning to get a picture as to why device tree can never solve the >> problem? > > > I think part of the answer has to come from the source of all of these > problems: there seems to be this culture in the ARM world (and, well, the > embedded world generally) where the HW designers don't care what kind of > mess they cause the people who have to write and maintain device drivers and > kernels that run on the devices. in a word... yes. i think you summed it up nicely - that there's simply too much diversity for linux to take into account all on its own. and u-boot. and the pre-boot loaders [spl, part of u-boot]. but the question you have to ask is: why should the HW designers even care? they're creating an embedded specialist system, they picked the most cost-effective and most available solution to them - why _should_ they care? and the answer is: they don't have to. tough luck. get over it, mr software engineer. hardware cost reductions take priority. > In the PC world designers can't really do > many crazy things as the people doing drivers will tell them "What is this > crap? There's no way we can make this work properly in Windows". In the > embedded world the attitude is more like "Hey, it's Linux, it's open, we > know you can put in a bunch of crazy hacks to make this mess we created work > reasonably". So the designers have no reason to make things behave in a > standardized and/or sane manner. > > Obviously this is a longer-term solution what is? what solution? you mean device tree? i'm still waiting for someone to put a comprehensive case together which says that device tree is a solution *at all*. yes, sure, as someone on #arm-netbooks pointed out, device tree has helped them, personally, when it comes to understanding linux kernel source code and for porting of drivers to other hardware, because the GPIO to control the signals is separated out from the source code. but that only helps in cases where that one specific piece of hardware is re-used: we're talking THOUSANDS if not TENS of thousands of disparate pieces of hardware [small sensors with only 3 pins, all the way up to GPIO extender ICs with hundreds], where the majority of those device drivers never see the light of day due either to GPL violations, burdensome patch submission procedures and so on. and in such cases, where the chances of code re-use are zero to none, what benefit does device tree offer wrt code re-use? none! > and won't help with existing > devices, but in the long run device designers may need to realize the kind > of mess they're creating for the poor software people and try to achieve > some more standardization and device discoverability. the economics of market forces don't work that way. profit-maximising companies are pathologically and *LEGALLY* bound to enact the articles of incorporation. so you'd need to show them that it would hurt their profits to continue the way that they are going. fortunately, the linux kernel isn't bound by the same corporate rules, so if there *was* a solution, it would be possible to apply that solution and thus move everyone forward, kicking and screaming over a long period and turn things around. > Given the market > dominance of Linux in many parts of the embedded world, one thinks this > should be achievable. working against that is the fact that there are only a few SoC companies with the expertise, they work in secret *without* consulting the linux kernel developers [as we well know], and the ODMs and factories simply run with whatever-the-SoC-vendors-put-their-way. in fact, the factories usually have zero expertise: as far as they're concerned they might as well be making socks or jumpers rather than laptops or tablets and in some cases the owners of the factories really *do* have their staff making socks, jumpers or handbags as well as laptops or tablets [*1] anyway, my point is that the problem which device tree set out to solve - that of the diversity in the ARM world - is an almost unsolvable problem in software. i won't say "completely unsolvable". device tree solves *some* problems, and generally makes things nice in certain cases, but it doesn't *actually* solve the problem it was originally designed to solve. i'm still waiting to hear from someone - anyone - who recognises this, and i'm also still waiting to hear from people who may have an alternative solution or process which actually and truly helps solve the problem. preferably on-list so that it can be discussed and properly reviewed. l. [*1] one day the factory owner woke up, probably around christmas five years ago when the UK's retail sector cartels Next, Top Shop etc. complained about Asda's George range of cheap clothing prices and demanded a monopolies review, causing huge shipping containers to sit outside of the UK in international waters for months] and went "my cash is all in clothing! i must diversify! i know, i'll buy some PCB printing equipment and some plastics moulding stamps, and make electronics appliances!". this tells you everything you need to know about e.g. the problems that the KDE Plasma Vivaldi Spark Tablet has been having, as well as why there is a 98% GPL violations rate on low-cost tablet hardware. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/