Re: devicetree live reconfigureable hardware (eoma68)

[Luke Kenneth Casson Leighton]

On Tue, Nov 10, 2015 at 8:30 PM, Pantelis Antoniou
<pantelis.antoniou@xxxxxxxxxxxx> wrote:
>
>> On Nov 7, 2015, at 19:36 , Luke Kenneth Casson Leighton <lkcl@xxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/