Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751838AbbKJWb6 (ORCPT ); Tue, 10 Nov 2015 17:31:58 -0500 Received: from lkcl.net ([217.147.94.29]:53145 "EHLO lkcl.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751284AbbKJWb5 convert rfc822-to-8bit (ORCPT ); Tue, 10 Nov 2015 17:31:57 -0500 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 10 Nov 2015 22:31:48 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: devicetree live reconfigureable hardware (eoma68) From: Luke Kenneth Casson Leighton To: Pantelis Antoniou Cc: Linux Kernel Mailing List , Grant Likely Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 8243 Lines: 191 On Tue, Nov 10, 2015 at 8:30 PM, Pantelis Antoniou wrote: > >> On Nov 7, 2015, at 19:36 , Luke Kenneth Casson Leighton wrote: >> >> hi folks, >> > > Hi Luke, > > This is a quite lengthy treatise you wrote here. apologies, i've been working in insolation [mostly hardware] but thinking about the dynamic configureability issue [since 2011], i therefore needed to lay out the whole logical reasoning chain. sorry about that > I was not very familiar with EOMA68 so I hit the web to read about > it first. At first glance it seems quite reasonable. basically it's like phonebloks except they're tackling smartphones, and i'm [patiently] tackling "everything else". laptops, tablets, mini-desktops, keyboard-computers, media centres etc. etc. anything which doesn't end up too bulky if its main computing is on a 5mm x 54mm x 86mm self-enclosed [formerly PCMCIA] case. end-users are used to the concept of "memory card" being movable and replaceable and upgradeable and sellable: if this is now "computer card" it's not such a hard stretch of imagination. people in the street i tell that to, they like it a lot. > There is no support for hotplug (yet) for beaglebone capes. > There is no real software reason, it’s just that the hardware is not designed > for it. yeah, understood. it's not really safe to do, either, as you might plug the pins in off-by-one whilst the power is on. whereas EOMA68 is basically re-using PCMCIA housings/sockets/assemblies. those *are* designed for hotplugging, and some of the CPU Cards may be OTG-powered. so, live hotplugging, whilst i am nervous about trying it for the first time, is a real possibility. > I would caution against putting the device tree configuration in the > storage of the expansion board. While appealing at first IMHO we are > not at a point where device tree blobs are perfectly forward compatible. i was thinking more along the lines of dts (source) fragments, not dtb (binary blob) fragments.... implications of that being that you may need to activate [i.e. run] the dt compiler from the kernel before you can access hardware. > For some of the messy details about why, please take a look at the excellent > presentation that Thomas Petazzoni made: > > http://free-electrons.com/pub/conferences/2015/elc/petazzoni-dt-as-stable-abi-fairy-tale/petazzoni-dt-as-stable-abi-fairy-tale.pdf > > The identifier can be easily mapped to a device tree blob object from > the filesystem which we can update in lockstep with the kernel. right. thinking out loud, immediate problem is, you don't know whether - or even if - there is a filesystem *at all*. in some cases, CPU Cards may not even have a processor. they could be an FPGA card. or be running the windows OS [at some point.] to get to the point, then, i feel that "device tree fragments" after thinking it was a good idea all these years, probably isn't so good after all. much better, i feel, would be to still have the device-tree fragments on the computing module's internal storage, suitably named with aliases "eoma68_pin_1_as_gpio", and "eoma68_pin_35_as_gpio", then to have a plaintext [or other well-defined] formatted file, stored in the EEPROM, that simply is a list of names indicating what the kernel should pull together to make up the GPIO and functions of the current chassis the computing module's plugged in to. this has the advantage that, in the future, when non-gnu-linux OSes get involved [i have someone who's donated an EOMA68 CPU Card to a FreeBSD developer for example] it's not so hard for those OSes to implement their own dynamic reconfigureability... *without* needing to pull in device-tree interoperability. the only thing that will be a bit of a bitch is RGB/TTL configuration. that's.... well, you need hsync, vsync, blah blah everything basically. all the EDID data and a bit more besides. in fact... in theeoryyyyy... now that i think about it, it might actually be possible to _use_ EDID data as the preferred format... hmmmm :) >> so whereas with the beaglebone it's perfectly fine to just hard-code >> "oh yeah, pin 50 is GPIO but it's also multiplexed with SD CLK line", >> with EOMA68 it is simply flat-out impossible to do that. you simply >> cannot know, in the future, what GPIO will be connected on a CPU Card. >> the *only* information that you have is, "EOMA68 pin 16 is GPIO0 or SD >> Data line 3". you have *NO IDEA* what *actual* GPIO that goes to on a >> particular SoC, especially ones that will be available over the next >> decade. >> >> so that's complication (1). >> > > We are already (me and gcl) trying to design something that will address > this problem. And no, your EOMA68 boards are not the first ones to hit it. ok, that's good to know. > The 96board family has the same problem, all the boards with arduino compatible > headers have the same problem, etc.. ahh ok. oh right, so there are actually boards out there which are running the linux kernel [instead of using sdcc / avr-utils] that have arduino-compatible headers. cool. >> possible solution, here, which solves both complication (1) as well as >> complication (2): a level of abstraction is needed. the abstraction >> is needed because, as mentioned in complication (1) the only >> consistent naming is in the EOMA68 interface, *NOT* in the SoCs >> *BEHIND* the EOMA68 interface. >> > > No, that way is madness. :) > The idea I’m toying with requires the introduction of something called > a ‘connector’ which will deal with all mapping of resources from the > platform agnostic connector format ... e.g. "arduino-connector"... > to the internal SoC/CPU card format. > That includes an extension to the notion of pinmuxing to something that > is more abstracted. > > So the device tree blobs would be the same for each board that supports > the connector and the resources they define will be mapped either statically > or dynamically using the connector ‘object’ as a translating proxy. ok. so. we maay be thinking along similar lines, let me double-check. above, after abandoning the concept of storing dtb blobs [or dts source files] in the EEPROM, i describe instead a list of names, each of which refers to a pre-compiled dtsi, the idea being that these are "stitched together" externally by a little bit of code. so i believe what you call a connector 'object' as a translating proxy would do the same job... perhaps even defined in devicetree fileformat? if so [connector objects stored in dtb format], then question to consider: what's to say that the future binary incompatibility issue mentioned in that pdf won't hit those blobs? >> i have an even more horrible idea of overloading phandles, like >> [....] >> > Nope, don’t do that either :) already blanked from my mind. no drugs needed either :) >> the implications there are that in a relatively short time, beaglebone >> "capes" will likely turn from a 1-to-many scenario into the exact same >> many-to-many scenario as faced by EOMA68 hardware right now. if not >> beaglebone, then something else. >> >> [...] >> > I’m working on it, hope I’ll have something to present before the Christmas vacations, awesome. > but, unfortunately time is limited. as always... :) so. main quick question is the format / specification for connector objects, and what file format they'd be expected to be in. if "plaintext" [or equivalently-simple] i'd be going "yay!". if not, i'd be concerned. btw, to clarify: i don't mean that the *specification* of the actual connector be in plaintext: that should be clear that it should be in devicetree [or devicetree fragments / includes]. it's the *instantiation* of a connector that has me concerned. it really should be nothing more than a list of names, referring to the [multiplexed] available functions listed in the devicetree file[s]. anything more than that has my alarm bells ringing. not entirely sure why... l. -- 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/