[advice sought] EOMA68 kernel support

[advice sought] EOMA68 kernel support

[lkcl luke]

i'm looking for some advice and feedback, and potentially a suitable
mentor for a gsoc 2012 applicant.
http://rhombus-tech.net/gsoc2012/ideas/EOMA68_linux_kernel_support/

some background: http://rhombus-tech.net has been set up as a
UK-registered Community Interest Company to act as a bridge between
China-based Mass-volume Product Manufacturing on one hand and Software
(Libre) Developers on the other.  if you are familiar with the
consequences of the rampant GPL violations that are endemic as a
result of the success of cheap android-based hardware, you'll
understand that rhombus-tech is endeavouring to help solve that by
going back to the root of the problem: create hardware that is sold in
mass-volume yet is GPL compliant and developed in consultation with
Free Software Engineers at every step of the way.

also, as previously described here
(http://lkcl.net/linux/modular.computing.architecture.html) and now
formalised as a specification named EOMA-68 here
(http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68) the
rhombus-tech strategy is to split what was formerly done as a single
"Motherboard" down into to components, one of which is potentially
user hot-swappable: 1) CPU card and 2) I/O Board.

the implications of that split, for the linux kernel source code, are
a bit... scarey :)

1) device-tree on its own isn't enough.  A CPU Card can literally be
removed from one Chassis (a laptop with an SATA Hard Drive, Gigabit
Ethernet, USB WIFI, a USB printer attached and so on) and inserted
into an entirely different Chassis (an LCD monitor with a 1920x1080
screen, with a USB hard drive but maybe no SATA) and then 5 minutes
later removed and put into another (e.g. a MID with a 480x320 LCD, no
Hard Drive and a completely different set of USB WIFI)

2) the EOMA68 interfaces aren't going to change (24-pin RGB/TTL for
LCD, SATA, USB, Ethernet, I2C, 16x GPIO) but there will be *multiple*
types of CPUs some of which will not even exist yet which can plug
into it, none of which we can predict, and they certainly won't all be
ARM processors.

3) the RGB/TTL out has a particular problem associated with it: many
LCD panels simply don't have proper EDID support, but worse than that,
the assumption has always been in the arm-linux kernel and many other
"embedded" systems based around SoCs that there will be one and ONLY
one LCD associated with the product for its entire lifetime, and the
linux kernel support for that product has traditionally reflected that
by hard-coding the LCD panel's parameters into a platform-specific
device driver.  whilst this has moved over to device-tree, device-tree
on its own *still* doesn't help you in this case because the bloody
thing can change!

4) it's worthwhile mentioning that part of the EOMA68 standard
requires that there be an I2C EEPROM (in a fixed address TBD) which
contains the device-tree information that properly describes the
hardware.  but this information not only needs to be read at boot time
but also needs to be read at runtime, dynamically!  it's a removable
card, it's going to get.... removed :)

so... *deep breath*.... where do we even begin to tackle this? :)

as it's - duh - a project which - duh - is intended to be of benefit
to the Software (Libre) Community, obviously (duh) we're asking rather
than telling or working "in secret" which is what would happen with a
Ltd profit-maximising Company.  the priorities are different for a
CIC, so this needs to happen as an open project, but it has _to_
happen.

i figured it would make a great gsoc project, apart from anything
else, and for that to work, it would be great to have an experienced
linux kernel mentor.  bearing in mind that that mentor needs to have a
general overview of the *entire* range of architecture ports for
linux, not just ARM or x86.

thoughts greatly appreciated.

l.

Re: [advice sought] EOMA68 kernel support

[lkcl luke]

On Fri, Mar 9, 2012 at 10:41 PM, lkcl luke <luke.leighton@gmail.com> wrote:

> the implications of that split, for the linux kernel source code, are
> a bit... scarey :)

 ... so, real simple very basic, concrete and necessary question:
where the hell in the linux kernel tree should support for eoma68 be
added??

 * driver support can't be added to drivers/ because although a device
with an EOMA68 CPU card *requires* drivers, it's not *actual* drivers
being added, it's driver *grouping* code that's required, and that
concept simply does... not... exist.

 * architecture support can't be added to arch/ because that contains
code for CPUs not code that is about helping to support multiple CPUs.
 eoma isn't a CPU.

 * adding a top-level directory "eoma" is a bit too "whoa" but i
really don't see any suitable subdirectories.

so.

very basic question.  where the hell should EOMA support source code go?

bearing in mind that the first CPU card is an Allwinner A10, the next
one is likely to be an AMD Fusion, the one after that could be from
icubecorp, the one after that a multi-core SMP xtensa, etc.

l.

Re: [Arm-netbook] [advice sought] EOMA68 kernel support

[Henrik Nordström]

lör 2012-03-10 klockan 06:45 +0000 skrev lkcl luke:

>  ... so, real simple very basic, concrete and necessary question:
> where the hell in the linux kernel tree should support for eoma68 be
> added??

Good question.

There is two parts of eoma68 relevant to this

First, there is the capabilitities of the CPU card itself.

Second, there is the I/O board it gets connected to.

These two parts need to be matched, resulting in a device tree or
similar for the actual system in it's current form, and is something
that may even change dynamically at suspend/resume. The I/O board may
cause different I/O profiles to be selected bu the CPU card. A
theoretical example would be one configuraiton having LCD, the other
doing 10 UARTs on the same lines. This requires the CPU card to adopt in
which hardware devices it activates, something ARM SoCs is quite good at
and A10 in particular.

We do not know yet which I/O profiles of EOMA will be available or used
for. The current profile is based on the expected initial target
systems.

The EOMA connector in itself is a kind of I/O bus.

Regards
Henrik

Re: [advice sought] EOMA68 kernel support

[Alan Cox]

On Sat, 10 Mar 2012 06:45:15 +0000
lkcl luke <luke.leighton@gmail.com> wrote:

> On Fri, Mar 9, 2012 at 10:41 PM, lkcl luke <luke.leighton@gmail.com> wrote:
> 
> > the implications of that split, for the linux kernel source code, are
> > a bit... scarey :)
> 
>  ... so, real simple very basic, concrete and necessary question:
> where the hell in the linux kernel tree should support for eoma68 be
> added??

It sounds to me like a bus.

>  * driver support can't be added to drivers/ because although a device
> with an EOMA68 CPU card *requires* drivers, it's not *actual* drivers
> being added, it's driver *grouping* code that's required, and that
> concept simply does... not... exist.

Actually we stick busses in drivers too (see pci...)

>  * architecture support can't be added to arch/ because that contains
> code for CPUs not code that is about helping to support multiple CPUs.
>  eoma isn't a CPU.

See above.. it's a bus

> very basic question.  where the hell should EOMA support source code go?
> 
> bearing in mind that the first CPU card is an Allwinner A10, the next
> one is likely to be an AMD Fusion, the one after that could be from
> icubecorp, the one after that a multi-core SMP xtensa, etc.

Off the top of my head I suspect you want

drivers/eoma68/

which is the bus interface and glue including reading the device tree
data for the current board you are plugged into and building a device
tree from that.

lib/eoma68

or some similar name, which is the library routines everything using
eoma68 needs

arch/[x86.arm,..]/platform/eoma68/..

probably the platform code for each system.


I don't btw see the problem with your device trees and display. If you've
got a device tree on *both* the CPU card and the I/O boards then you've
got all the data in the right places.

Alan

Re: [advice sought] EOMA68 kernel support

[lkcl luke]

On Sat, Mar 10, 2012 at 1:00 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Sat, 10 Mar 2012 06:45:15 +0000
> lkcl luke <luke.leighton@gmail.com> wrote:
>
>> On Fri, Mar 9, 2012 at 10:41 PM, lkcl luke <luke.leighton@gmail.com> wrote:
>>
>> > the implications of that split, for the linux kernel source code, are
>> > a bit... scarey :)
>>
>>  ... so, real simple very basic, concrete and necessary question:
>> where the hell in the linux kernel tree should support for eoma68 be
>> added??
>
> It sounds to me like a bus.

 *click*... good point!  ok, it's a collection of
decade-long-established Lowest Common Denominator buses.

>>  * driver support can't be added to drivers/ because although a device
>> with an EOMA68 CPU card *requires* drivers, it's not *actual* drivers
>> being added, it's driver *grouping* code that's required, and that
>> concept simply does... not... exist.
>
> Actually we stick busses in drivers too (see pci...)

 ah, doh, of course.  drivers/usb etc.  right, yep - that works.

>> very basic question.  where the hell should EOMA support source code go?
>>
>> bearing in mind that the first CPU card is an Allwinner A10, the next
>> one is likely to be an AMD Fusion, the one after that could be from
>> icubecorp, the one after that a multi-core SMP xtensa, etc.
>
> Off the top of my head I suspect you want
>
> drivers/eoma68/
>
> which is the bus interface and glue including reading the device tree
> data for the current board you are plugged into and building a device
> tree from that.


> lib/eoma68

 right - yep: i'd missed lib. that also makes sense.

> or some similar name, which is the library routines everything using
> eoma68 needs
>
> arch/[x86.arm,..]/platform/eoma68/..
>
> probably the platform code for each system.

 yep.  that'd work too.  eyy, sorted!


> I don't btw see the problem with your device trees and display.

 my experience with the linux kernel source dates back to 2.4.20,
2.6.12, 2.6.16, then more recently 2.6.26, so it predates device tree:
i may therefore just be lacking confidence in the ability of device
tree to solve the problem, whereas you're not :)  *takes hat off and
bows with a respectful but cheeky grin* :)

 of particular concern is that a CPU card could be running on (small!)
backup battery / supercapacitor whilst being hot-swapped, and thus
that means that the LCD module (drivers/eoma68/lcd.ko?) would need to
be loaded and unloaded from userspace (udev).  that's not going to be
a problem, is it?  i may just be imagining skeletons in the closet,
here.

 oo, bugger.  backlight control.  damn.  each I/O board is going to
potentially have entirely different backlight control characteristics
and drivers.  if there is one at all.

> If you've
> got a device tree on *both* the CPU card and the I/O boards then you've
> got all the data in the right places.

 yes, that's the plan.

 * for the fixed "bus group" (SATA, ETH, I2C, USB2) there would be a
device-tree (somewhat overkill, but that's ok) which ends up on the
NAND flash of the CPU card.  it's not going to change, that's the main
thing.

 * it's the purposes to which the 16 GPIOs can be put that will be
radically different from one I/O board to the next.  GPIO 0 could be
"powerup for WIFI" on one I/O board, but "lid open/shut switch" on
another.

so, each I/O board needs to have a set of definitions which have
*nothing* to do with the CPU Card which will get plugged into them.

it's all a bit... weird.

but the whole strategy is based around solving this ridiculous
situation of having to create platform-specific drivers for every
single bloody device, irrespective of the CPU being used, N*M where N
= CPU and M = type of computer, and replacing it with an
N+M+small-common-overhead codebase.

thanks alan.

l.

Re: [advice sought] EOMA68 kernel support

[Alan Cox]

>  of particular concern is that a CPU card could be running on (small!)
> backup battery / supercapacitor whilst being hot-swapped, and thus
> that means that the LCD module (drivers/eoma68/lcd.ko?) would need to
> be loaded and unloaded from userspace (udev).  that's not going to be
> a problem, is it?  i may just be imagining skeletons in the closet,
> here.

Your device tree describes devices. Your bus creates them when you
hotplug and it removes them when you hot unplug. The rest is the drivers
problem to behave properly, and refcount right.

>  * it's the purposes to which the 16 GPIOs can be put that will be
> radically different from one I/O board to the next.  GPIO 0 could be
> "powerup for WIFI" on one I/O board, but "lid open/shut switch" on
> another.

It's "GPIO 0 of card X" and providing you remember that, watch your
refcounting and don't remap a new device over the address space of an old
one during a hotplug you should be fine.

Alan

Re: [advice sought] EOMA68 kernel support

[lkcl luke]

On Sat, Mar 10, 2012 at 7:51 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

>>  of particular concern is that a CPU card could be running on (small!)
>> backup battery / supercapacitor whilst being hot-swapped, and thus
>> that means that the LCD module (drivers/eoma68/lcd.ko?) would need to
>> be loaded and unloaded from userspace (udev).  that's not going to be
>> a problem, is it?  i may just be imagining skeletons in the closet,
>> here.
>
> Your device tree describes devices. Your bus creates them when you
> hotplug and it removes them when you hot unplug. The rest is the drivers
> problem to behave properly, and refcount right.


>>  * it's the purposes to which the 16 GPIOs can be put that will be
>> radically different from one I/O board to the next.  GPIO 0 could be
>> "powerup for WIFI" on one I/O board, but "lid open/shut switch" on
>> another.
>
> It's "GPIO 0 of card X" and providing you remember that, watch your
> refcounting and don't remap a new device over the address space of an old
> one during a hotplug you should be fine.

 allright.  thanks alan.  that's clear.

honest opinion sought: is this something that would keep a (good) gsoc
student occupied full-time?  you or i could complete it in a week, 2
weeks, whatever, but i'm concerned that a gsoc student would go "um is
that it??"

yes we'll have by then one or two reference platforms, but that's not
going to be rocket science to get the device drivers for them
up-and-running [non-eoma-compliant].

i guess i'm talking myself out of the proposal, am looking for advocates :)

l.