[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[Jean-Francois Moine]

This patch enables the ethernet device by default, permitting CM-A510
boards to access the network when an ethernet connector is present.

Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Tested-by: Gabriel Dobato <dobatog@gmail.com>
---
 arch/arm/boot/dts/dove-cm-a510.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dove-cm-a510.dts b/arch/arm/boot/dts/dove-cm-a510.dts
index 50c0d69..404e983 100644
--- a/arch/arm/boot/dts/dove-cm-a510.dts
+++ b/arch/arm/boot/dts/dove-cm-a510.dts
@@ -21,6 +21,8 @@
 &sdio0 { status = "okay"; };
 &sdio1 { status = "okay"; };
 &sata0 { status = "okay"; };
+&eth { status = "okay"; };
+&mdio { status ="okay";};
 
 &spi0 {
 	status = "okay";
-- 
2.1.4

[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[Sebastian Hesselbarth]

[added MVEBU maintainers and Gabriel to Cc]

On 30.01.2015 07:06, Jean-Francois Moine wrote:
> This patch enables the ethernet device by default, permitting CM-A510
> boards to access the network when an ethernet connector is present.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> Tested-by: Gabriel Dobato <dobatog@gmail.com>

Jean-Francois,

great you are helping out Gabriel to get his CM-A510 up and running!

I had a closer look on the Compulab website of the SoM [1] and think
that we'll have to convert it to dove-cm-a510.dtsi and the baseboard
Gabriel is using (maybe SBC-A510 [2]).

The dove-cm-a510.dts was a blind port of what was in mach-dove when
we started with DT, so most of it is probably bogus.

For the ethernet port this patch is about, the PHY (RTL8211) is part
of the SoM, the jack is not. So, we cannot really tell, if that port
can ever be used on a specific baseboard. I suggest to put the
corresponding nodes into the dtsi, but leave them status = "disabled".

The baseboard dts should enable them like your patch does, if the
ethernet jack is available. The same is true for the sdio0 and sata0
nodes you can see below. However, sdio1 is connected to a USI WiFi
module with Marvel 8686 on the SoM.

Can you take over and prepare the necessary patches? That would
be great!

BTW, I wouldn't mind if the cm510 related dts files you are touching
move over to dual-license [3] now :)

Sebastian

[1] http://www.compulab.co.il/products/computer-on-modules/cm-a510/#diagram
[2] www.compulab.co.il/products/sbcs/sbc-a510/
[3] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/389206

> ---
>   arch/arm/boot/dts/dove-cm-a510.dts | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dove-cm-a510.dts b/arch/arm/boot/dts/dove-cm-a510.dts
> index 50c0d69..404e983 100644
> --- a/arch/arm/boot/dts/dove-cm-a510.dts
> +++ b/arch/arm/boot/dts/dove-cm-a510.dts
> @@ -21,6 +21,8 @@
>   &sdio0 { status = "okay"; };
>   &sdio1 { status = "okay"; };
>   &sata0 { status = "okay"; };
> +&eth { status = "okay"; };
> +&mdio { status ="okay";};
>
>   &spi0 {
>   	status = "okay";
>

[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[Jean-Francois Moine]

On Fri, 30 Jan 2015 10:44:07 +0100
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:

> I had a closer look on the Compulab website of the SoM [1] and think
> that we'll have to convert it to dove-cm-a510.dtsi and the baseboard
> Gabriel is using (maybe SBC-A510 [2]).

Sebastian,

I don't understand why the A510 contained in the cm-a510 should be
different from the one of the other boards (I just noticed a second
ethernet and a WiFi device - but, is the Compulab document up to date?).

If it is the same, the dove.dtsi should work (and it seems to work for
Gabriel).

The only difference with the cm-a510 is the presence or not of the
connectors. So, all the Dove devices could be enabled in the DT, and,
if some room is needed in the board, the .config could be adapted
removing the useless drivers and have a minimal kernel.

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[Sebastian Hesselbarth]

On 30.01.2015 11:31, Jean-Francois Moine wrote:
> On Fri, 30 Jan 2015 10:44:07 +0100
> Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:
>> I had a closer look on the Compulab website of the SoM [1] and think
>> that we'll have to convert it to dove-cm-a510.dtsi and the baseboard
>> Gabriel is using (maybe SBC-A510 [2]).
>
> I don't understand why the A510 contained in the cm-a510 should be
> different from the one of the other boards (I just noticed a second
> ethernet and a WiFi device - but, is the Compulab document up to date?).

It is not the SoM that is different, but the baseboard it is attached
to. So, the SoM makes a second layer of dtsi around the SoC but is not
sufficient for a board dts.

Regarding the on-SoM WiFi, that will be available on _any_ cm-a510
equipped to _any_ baseboard, so it can be enabled in the som.dtsi.

The second ethernet comes from a PCIe attached NIC, and as you already
said, we simply don't know (yet) if it is actually wired-up on Gabriel's
baseboard. If it is not wired-up on the baseboard, we definitely want
it disabled in DT, too.

> If it is the same, the dove.dtsi should work (and it seems to work for
> Gabriel).

Of course it does work for Gabriel but we don't want to exclusively
mainline Gabriel's setup. In the best case, we want to provide a
dove-cm-a510.dtsi that can be included in any baseboard somebody is
using.

> The only difference with the cm-a510 is the presence or not of the
> connectors. So, all the Dove devices could be enabled in the DT, and,
> if some room is needed in the board, the .config could be adapted
> removing the useless drivers and have a minimal kernel.

Adapting the .config and removing drivers is actually not an option.
IMHO, introducing DT was meant for a single multi-arch kernel that
can be shipped with common Linux distros. Therefore, DT is the place
you enable/disable available resources. You leave most of the SoC (and
SoM) nodes disabled as long as you cannot tell if there is a
corresponding connector available.

Sebastian

[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[Jean-Francois Moine]

On Fri, 30 Jan 2015 12:00:16 +0100
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:

> Adapting the .config and removing drivers is actually not an option.
> IMHO, introducing DT was meant for a single multi-arch kernel that
> can be shipped with common Linux distros. Therefore, DT is the place
> you enable/disable available resources. You leave most of the SoC (and
> SoM) nodes disabled as long as you cannot tell if there is a
> corresponding connector available.

Well, I don't know too much about the hardware, and less about the
hardware modules (SoM?).

As seen in the Compulab documents, there are a lot of hardware modules.
For the DT, do you mean that there would be as many .dts's as the whole
number of connection possibilities?

I'd have better seen the inverted case as the actual empty cm-board dts:
enable every option in the (generic) .dts and let the vendor/user create
a specific .dts from this one for the board according to the installed
modules.

In any case, any real cm-a510 board should work with the
generic/full .dts even if some hardware modules are lacking. No?

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[Sebastian Hesselbarth]

On 30.01.2015 12:41, Jean-Francois Moine wrote:
> On Fri, 30 Jan 2015 12:00:16 +0100
> Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:
>> Adapting the .config and removing drivers is actually not an option.
>> IMHO, introducing DT was meant for a single multi-arch kernel that
>> can be shipped with common Linux distros. Therefore, DT is the place
>> you enable/disable available resources. You leave most of the SoC (and
>> SoM) nodes disabled as long as you cannot tell if there is a
>> corresponding connector available.
>
> Well, I don't know too much about the hardware, and less about the
> hardware modules (SoM?).

Sorry, SoM is for System-on-Module, i.e. the CM-A510 itself.

You can see from the block diagram that it comprises the Dove SoC,
power circuitry, touch-screen controller, WiFi, GbE PHY for GbE-0, GbE
controller on PCIe for GbE-1, I2S audio codec, RS232 Level Shifter for
UART0, an USB2 Hub, SPI flash, NAND and RAM.

That basically is what will be represented in the som.dtsi. If any of
the functions above and the SoC will be _accessible_ on the baseboard is
another story.

> As seen in the Compulab documents, there are a lot of hardware modules.
> For the DT, do you mean that there would be as many .dts's as the whole
> number of connection possibilities?

Nope. One dove.dtsi, one dove-cm-a510.dtsi, and one baseboard.dts
including dove-cm-a510.dtsi for every baseboard we stumble upon.

> I'd have better seen the inverted case as the actual empty cm-board dts:
> enable every option in the (generic) .dts and let the vendor/user create
> a specific .dts from this one for the board according to the installed
> modules.

That what dtsi's are made for with one exception: the dtsi cannot "run"
on its own but needs at least one baseboard.dts that includes it. We
could create a "bare"-baseboard that represents what is (easily)
accessible on the SoM itself. Given the fact that even UART0 needs a
baseboard that grabs it from the SoM connector, I see no value in that.

> In any case, any real cm-a510 board should work with the
> generic/full .dts even if some hardware modules are lacking. No?

Nope. The cm-a510 is just an add-on for a baseboard, it does not make
a working board. Just think of it as a feature-improved SoC.

Sebastian

[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[Jean-Francois Moine]

On Fri, 30 Jan 2015 13:03:59 +0100
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:

> Nope. The cm-a510 is just an add-on for a baseboard, it does not make
> a working board. Just think of it as a feature-improved SoC.

Well, I understand a bit, but I don't see clearly the physical system,
nor how each part gets its configuration for booting.

As you know better than I, it seems that you are the right person to
create the .dtsi/.dts's :) and to explain Gabriel how to use them!

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[Sebastian Hesselbarth]

On 30.01.2015 13:39, Jean-Francois Moine wrote:
> On Fri, 30 Jan 2015 13:03:59 +0100
> Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:
>> Nope. The cm-a510 is just an add-on for a baseboard, it does not make
>> a working board. Just think of it as a feature-improved SoC.
>
> Well, I understand a bit, but I don't see clearly the physical system,
> nor how each part gets its configuration for booting.

TBH, I completely missed that the cm-a510 can come in different
configurations, e.g. with or without WiFi. Nevertheless, considering
that there are only a handful of configurations available, IMHO the
right thing would be a dtsi with all possible options described by
corresponding but disabled nodes.

The actual physical system has to be determined at runtime in any
way and it should be done by the bootloader. However, even the
bootloader would be happy to find the right nodes to enable instead
of creating them from scratch.

> As you know better than I, it seems that you are the right person to
> create the .dtsi/.dts's :) and to explain Gabriel how to use them!

Well, nothing that should stop you from improving your skills :)

I'd be happy to take over, but I admit that my current lack of spare
time would only allow me to support Gabriel and you.

Let's wait for Gabriel's response on how he can help improving
Dove mainline with his cm-a510 and baseboard.

Sebastian

[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[Sebastian Hesselbarth]

On 01.02.2015 15:16, Gabriel Dobato wrote:
>> I'd be happy to take over, but I admit that my current lack of spare
>> time would only allow me to support Gabriel and you.
>>
>> Let's wait for Gabriel's response on how he can help improving
>> Dove mainline with his cm-a510 and baseboard.
>
> First of all, I would like to give thanks all people like you for all
> your help and support. I really appreciate it.
>
> DT is new for me, I have never worked using this kind of hardware
> description, so I am involving in many issues due to my lack of skills
> in this kind of structure.
>
> At this moment, I am focusing in the update of the version of the kernel
> on the CM-A510 board (from 2.6 to 3.1x)in order to give more features to
> the system, but as I said before, I have lots of problems.
>
> Thanks to the help and support of Jean-Francois Moine, I have achieved
> to boot the kernel completely and to mount the rootfs via NFS. I have a
> prompt, what has been a very big step for me.

Gabriel,

great you can boot a recent kernel. I guess you had to quite heavily
modify current dove-cm-a510.dts? Can you upload the one you use now
to any pastebin and send the link?

>> Nope. One dove.dtsi, one dove-cm-a510.dtsi, and one baseboard.dts
>> including dove-cm-a510.dtsi for every baseboard we stumble upon.
>
> In reference to the structure of .dts and .dtsi files, I agree with this
> kind of structure, of course, nobody as you can consider it better. I
> think the idea of make a dove-cm-a510.dtsi file and different
> baseboards.dts depending of the peripherals used is great. But as I say,
> maybe I am not the right person to decide it, Jean-Froncois Moine and
> you have better criteria.So, whatever you decide I would very happy to help.

You didn't mention if you really use the sb-a510, i.e. the Compulab
reference baseboard. Is it what you are using with your cm-a510?

> At this moment, I am trying to configure the framebuffer, but as Moine
> told me,it seems there is not video driver support for this board in
> DT... :( .

Not quite true. Video is made up of at least 4 different devices:
Framebuffer, GPU, Decode engine, and usually DVI/HDMI transmitter or
VGA.

We do have a driver for the framebuffer (armada_drm) and there is great
work from Russell King and others on the GPU and Decode engine (IIRC).

If you are using the sb-a510, I can see from the manual, that DVI
transmitter is SIL164.. AFAIS there is a driver for it, that maybe
needs some polishing. Nobody ever tested VGA, but it shouldn't be too
hard to add support for it as it is directly supported by the
framebuffer HW.

One quite important driver at least for Dove is a clock source for
video. Internal clock generators for video are way to limited with
respect to frequencies to allow any useful resolution.

I'll see if I can have a look at the dts stuff this weekend.. that
way we'll have at least the basic done before moving to the other
devices.

Sebastian

[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[Jean-Francois Moine]

On Thu, 05 Feb 2015 23:13:58 +0100
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:

> > At this moment, I am trying to configure the framebuffer, but as Moine
> > told me,it seems there is not video driver support for this board in
> > DT... :( .  
> 
> Not quite true. Video is made up of at least 4 different devices:
> Framebuffer, GPU, Decode engine, and usually DVI/HDMI transmitter or
> VGA.
> 
> We do have a driver for the framebuffer (armada_drm) and there is great
> work from Russell King and others on the GPU and Decode engine (IIRC).

Yes, but it has no DT support. Mine has.

> If you are using the sb-a510, I can see from the manual, that DVI
> transmitter is SIL164.. AFAIS there is a driver for it, that maybe
> needs some polishing. Nobody ever tested VGA, but it shouldn't be too
> hard to add support for it as it is directly supported by the
> framebuffer HW.

This asks for some VGA encoder/connector module.

Actually, as Gabriel told me that his screen is directly connected to
the RGB LCD output, I wrote a simple panel for him. This module just
gets the display timings from the DT.

> One quite important driver at least for Dove is a clock source for
> video. Internal clock generators for video are way to limited with
> respect to frequencies to allow any useful resolution.

>From my previous tests with the si5351 in the Cubox, most video modes
should work without external clocks.

> I'll see if I can have a look at the dts stuff this weekend.. that
> way we'll have at least the basic done before moving to the other
> devices.

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[Sebastian Hesselbarth]

On 06.02.2015 08:58, Jean-Francois Moine wrote:
> On Thu, 05 Feb 2015 23:13:58 +0100
> Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:
>>> At this moment, I am trying to configure the framebuffer, but as Moine
>>> told me,it seems there is not video driver support for this board in
>>> DT... :( .
>>
>> Not quite true. Video is made up of at least 4 different devices:
>> Framebuffer, GPU, Decode engine, and usually DVI/HDMI transmitter or
>> VGA.
>>
>> We do have a driver for the framebuffer (armada_drm) and there is great
>> work from Russell King and others on the GPU and Decode engine (IIRC).
>
> Yes, but it has no DT support. Mine has.

Yeah, it would be nice if you two stick together once again and work
that out for mainline?

>> If you are using the sb-a510, I can see from the manual, that DVI
>> transmitter is SIL164.. AFAIS there is a driver for it, that maybe
>> needs some polishing. Nobody ever tested VGA, but it shouldn't be too
>> hard to add support for it as it is directly supported by the
>> framebuffer HW.
>
> This asks for some VGA encoder/connector module.

Hmm, maybe it is just enough to tell the DRM driver to switch to
VGA and what i2c to use for DDC. I'll have to catch up with DRM
and DT.

> Actually, as Gabriel told me that his screen is directly connected to
> the RGB LCD output, I wrote a simple panel for him. This module just
> gets the display timings from the DT.

Ok. That makes it less complicated as there already should be support
for dumb RGB anyway.

>> One quite important driver at least for Dove is a clock source for
>> video. Internal clock generators for video are way to limited with
>> respect to frequencies to allow any useful resolution.
>
>  From my previous tests with the si5351 in the Cubox, most video modes
> should work without external clocks.

Well, this is not about a working corner case.. video modes are (more or
less) standardized and so is the clock frequency. Monitors are allowed
to reject any non-standard modes and it gets worse with TVs.

Ergo, we do want to hit the frequency as close as possible and Dove's
internal PLL simply cannot.

Sebastian

[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[Jean-Francois Moine]

On Fri, 06 Feb 2015 11:05:39 +0100
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:

> >> We do have a driver for the framebuffer (armada_drm) and there is great
> >> work from Russell King and others on the GPU and Decode engine (IIRC).  
> >
> > Yes, but it has no DT support. Mine has.  
> 
> Yeah, it would be nice if you two stick together once again and work
> that out for mainline?

It is not important for me to have something in the mainline: my driver
works fine enough for program development, and I don't need video
streaming. On the other hand, Russell said that his system does not
work well in a DT context...

> > Actually, as Gabriel told me that his screen is directly connected to
> > the RGB LCD output, I wrote a simple panel for him. This module just
> > gets the display timings from the DT.  
> 
> Ok. That makes it less complicated as there already should be support
> for dumb RGB anyway.

I could not find such a module, and, more, these LCD / VGA modules have
to be componentized to work with the armada DRM driver, and same for
mine.

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[Russell King - ARM Linux]

On Fri, Feb 06, 2015 at 11:05:39AM +0100, Sebastian Hesselbarth wrote:
> Yeah, it would be nice if you two stick together once again and work
> that out for mainline?

I don't see that happening, ever.

While I will (and have) taken patches from Jean which are technically
good (for things which I look after like the TDA998x) I see no
reciprocal good will - all I get is this "my driver is better than
yours" crap all the time.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[Russell King - ARM Linux]

On Fri, Feb 06, 2015 at 08:58:55AM +0100, Jean-Francois Moine wrote:
> On Thu, 05 Feb 2015 23:13:58 +0100
> Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:
> 
> > > At this moment, I am trying to configure the framebuffer, but as Moine
> > > told me,it seems there is not video driver support for this board in
> > > DT... :( .  
> > 
> > Not quite true. Video is made up of at least 4 different devices:
> > Framebuffer, GPU, Decode engine, and usually DVI/HDMI transmitter or
> > VGA.
> > 
> > We do have a driver for the framebuffer (armada_drm) and there is great
> > work from Russell King and others on the GPU and Decode engine (IIRC).
> 
> Yes, but it has no DT support. Mine has.

It has partial DT support.  I'm currently waiting for a production Cubox
from SolidRun (Jon Nettleton recently went to Israel, and he and Rabeeh
located one - it's currently with Jon, waiting for him to be well enough
to dispatch it to me.)  Maybe that will put an end to my HDMI problems
with DT kernels.

Until then, I've no interest in DT kernels on Dove hardware; they're
basically not functional for me.

> From my previous tests with the si5351 in the Cubox, most video modes
> should work without external clocks.

Jean, let's put this into perspective.

Different HDMI sinks have different tolerances on the video timing
parameters.  Some HDMI sinks (such as monitors) accept almost any
timing.  Other sinks (such as TVs) are much stricter.

Just because it works for you without using the SI5351 does not make
it a correct implementation.  It probably means that you have a HDMI
sink that will accept wildly wrong timing but still display the image.
Other HDMI sinks may decide to ignore such a wrong signal (and many
seem to.)

You've more or less proved that by your investigations into what your
HDMI sink will accept for audio (which is basically anything) which,
again, is not the general rule.

Taking your case and trying to make believe that it applies everywhere
is wholely wrong.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[Sebastian Hesselbarth]

On 06.02.2015 10:19, Gabriel Dobato wrote:
> On 05/02/15 23:13, Sebastian Hesselbarth wrote:
>> great you can boot a recent kernel. I guess you had to quite heavily
>> modify current dove-cm-a510.dts? Can you upload the one you use now
>> to any pastebin and send the link?
>
> Not, I only had to include eth (as Mr. Moine told me) and mdio because I
> mount rootfs via NFS.

Ok, I think we can work out the most obvious stuff (mmc, pcie), too.

>> You didn't mention if you really use the sb-a510, i.e. the Compulab
>> reference baseboard. Is it what you are using with your cm-a510?
>
> Yes, sorry for that, I am using SB-A510.

Ok. Then for the first some versions, I'll stick with the manual.
That should be sufficient to create a working sb-a510 dts.

FWIW, is there any Compulab kernel or u-boot source available online?
It would help to figure out the GPIO pins and undocumented connections.

> I wonder if it will there be driver support for the second ethernet
> (PCIE attached NIC), and the rest of features remained, for DT...

AFAIR it was some realtek PCIe NIC.. we have PCIe working on Dove, so
I guess it shouldn't be a real problem.

> Before using DT, I tried to boot a simple uImage (without DT), but it
> did not boot
>
> the last ouput in the kernel trade was:
> ...
> /uncompressing linux... done, booting the kernel./
>
> nothing else.... I wonder if there is a problem with the ID machine, I
> don't know...

Hard to tell. Could be anything.

> The U-Boot used was the one provided by Compulab (Maybe the problem is
> on Uboot...)

If you know how to append the dtb to the zImage it should work on any
u-boot. If it doesn't support bootz, you'll have to make a uImage of
the dtb-appended zImage or simply try to "go" to the zImage address.

Sebastian

[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[David Goodenough]

On Friday 30 January 2015 13:03:59 Sebastian Hesselbarth wrote:
> On 30.01.2015 12:41, Jean-Francois Moine wrote:
> > On Fri, 30 Jan 2015 12:00:16 +0100
> > 
> > Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:
> >> Adapting the .config and removing drivers is actually not an option.
> >> IMHO, introducing DT was meant for a single multi-arch kernel that
> >> can be shipped with common Linux distros. Therefore, DT is the place
> >> you enable/disable available resources. You leave most of the SoC (and
> >> SoM) nodes disabled as long as you cannot tell if there is a
> >> corresponding connector available.
> > 
> > Well, I don't know too much about the hardware, and less about the
> > hardware modules (SoM?).
> 
> Sorry, SoM is for System-on-Module, i.e. the CM-A510 itself.
> 
> You can see from the block diagram that it comprises the Dove SoC,
> power circuitry, touch-screen controller, WiFi, GbE PHY for GbE-0, GbE
> controller on PCIe for GbE-1, I2S audio codec, RS232 Level Shifter for
> UART0, an USB2 Hub, SPI flash, NAND and RAM.
> 
> That basically is what will be represented in the som.dtsi. If any of
> the functions above and the SoC will be _accessible_ on the baseboard is
> another story.
> 
> > As seen in the Compulab documents, there are a lot of hardware modules.
> > For the DT, do you mean that there would be as many .dts's as the whole
> > number of connection possibilities?
> 
> Nope. One dove.dtsi, one dove-cm-a510.dtsi, and one baseboard.dts
> including dove-cm-a510.dtsi for every baseboard we stumble upon.
> 
> > I'd have better seen the inverted case as the actual empty cm-board dts:
> > enable every option in the (generic) .dts and let the vendor/user create
> > a specific .dts from this one for the board according to the installed
> > modules.
> 
> That what dtsi's are made for with one exception: the dtsi cannot "run"
> on its own but needs at least one baseboard.dts that includes it. We
> could create a "bare"-baseboard that represents what is (easily)
> accessible on the SoM itself. Given the fact that even UART0 needs a
> baseboard that grabs it from the SoM connector, I see no value in that.
> 
> > In any case, any real cm-a510 board should work with the
> > generic/full .dts even if some hardware modules are lacking. No?
> 
> Nope. The cm-a510 is just an add-on for a baseboard, it does not make
> a working board. Just think of it as a feature-improved SoC.
This sounds like capes on the BeagleBoard.  Are these extension boards
self-identifying?  If so then the approach used with the capes might work
here too.

David
> 
> Sebastian
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[Sebastian Hesselbarth]

[Re-adding the most obvious People to Cc]

On 30.01.2015 13:44, David Goodenough wrote:
> On Friday 30 January 2015 13:03:59 Sebastian Hesselbarth wrote:
>> On 30.01.2015 12:41, Jean-Francois Moine wrote:
>>> On Fri, 30 Jan 2015 12:00:16 +0100
>>> Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:
>> That what dtsi's are made for with one exception: the dtsi cannot "run"
>> on its own but needs at least one baseboard.dts that includes it. We
>> could create a "bare"-baseboard that represents what is (easily)
>> accessible on the SoM itself. Given the fact that even UART0 needs a
>> baseboard that grabs it from the SoM connector, I see no value in that.
>>
>>> In any case, any real cm-a510 board should work with the
>>> generic/full .dts even if some hardware modules are lacking. No?
>>
>> Nope. The cm-a510 is just an add-on for a baseboard, it does not make
>> a working board. Just think of it as a feature-improved SoC.

> This sounds like capes on the BeagleBoard.  Are these extension boards
> self-identifying?  If so then the approach used with the capes might work
> here too.

David,

IMHO capes are a different thing. The BB can run just fine without any
cape installed, the cm-a510 cannot run without a baseboard. Also, once
you have your SoM installed it cannot change over runtime, there is no
need for any dynamic overlays and such.

You can build some 5 or 10 different configurations given the SoM and
a specific baseboard but not hundreds of possible combinations.
Besides, Gabriel is the first in almost 2 years that actually has an
cm-a510 - so, I doubt we'll have to mainline dozens of baseboards
using the cm-a510 in the near future.

Regarding the self-identification, it would be great if the actual SoM
configuration would be stored in the (always available) SPI flash, but
from my experience with the boards I have seen so far, I have a bad
feeling about it ;) A quick look at the sb-a510 (the compulab baseboard
for cm-a510) suggests that there is more configuration available but
by jumpers that (hopefully) can be read out by GPIOs at least.

The best similar board available in mainline I can remember is the
SolidRun Hummingboard, i.e. one baseboard that can be equipped with
3-4 different SoMs.

Sebastian

[PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board

[David Goodenough]

On Friday 30 January 2015 14:07:55 Sebastian Hesselbarth wrote:
> [Re-adding the most obvious People to Cc]
> 
> On 30.01.2015 13:44, David Goodenough wrote:
> > On Friday 30 January 2015 13:03:59 Sebastian Hesselbarth wrote:
> >> On 30.01.2015 12:41, Jean-Francois Moine wrote:
> >>> On Fri, 30 Jan 2015 12:00:16 +0100
> >> 
> >>> Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:
> >> That what dtsi's are made for with one exception: the dtsi cannot "run"
> >> on its own but needs at least one baseboard.dts that includes it. We
> >> could create a "bare"-baseboard that represents what is (easily)
> >> accessible on the SoM itself. Given the fact that even UART0 needs a
> >> baseboard that grabs it from the SoM connector, I see no value in that.
> >> 
> >>> In any case, any real cm-a510 board should work with the
> >>> generic/full .dts even if some hardware modules are lacking. No?
> >> 
> >> Nope. The cm-a510 is just an add-on for a baseboard, it does not make
> >> a working board. Just think of it as a feature-improved SoC.
> > 
> > This sounds like capes on the BeagleBoard.  Are these extension boards
> > self-identifying?  If so then the approach used with the capes might work
> > here too.
> 
> David,
> 
> IMHO capes are a different thing. The BB can run just fine without any
> cape installed, the cm-a510 cannot run without a baseboard. Also, once
> you have your SoM installed it cannot change over runtime, there is no
> need for any dynamic overlays and such.
> 
> You can build some 5 or 10 different configurations given the SoM and
> a specific baseboard but not hundreds of possible combinations.
> Besides, Gabriel is the first in almost 2 years that actually has an
> cm-a510 - so, I doubt we'll have to mainline dozens of baseboards
> using the cm-a510 in the near future.
> 
> Regarding the self-identification, it would be great if the actual SoM
> configuration would be stored in the (always available) SPI flash, but
> from my experience with the boards I have seen so far, I have a bad
> feeling about it ;) A quick look at the sb-a510 (the compulab baseboard
> for cm-a510) suggests that there is more configuration available but
> by jumpers that (hopefully) can be read out by GPIOs at least.
> 
> The best similar board available in mainline I can remember is the
> SolidRun Hummingboard, i.e. one baseboard that can be equipped with
> 3-4 different SoMs.
Ah this sounds like history repeating itself.  I have some old PC-104 
Compulab boards which had pluggable CPUs.  

They were x86 based, so DTS was not a question.  I guess that the
only approach is to start with the plugin, and then add the baseboard
as a standard include.

David
> 
> Sebastian
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel