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

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 <[email protected]>

Tested-by Gabriel Dobato <[email protected]>

---
  arch/arm/boot/dts/dove-cm-a510.dts | 2 ++
  1 file changed, 2 insertions(+)

arch/arm/boot/dts/dove-cm-a510.dts +2 -0

index 50c0d69..404e983 100644
@@ -21,6 +21,8 @@
  &sdio0 { status = "okay"; };
  &sdio1 { status = "okay"; };
  &sata0 { status = "okay"; };
+&eth { status = "okay"; };
+&mdio { status ="okay";};
 
  &spi0 {
  	status = "okay";

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]).

Quoted 3 lines · On Fri, 30 Jan 2015 10:44:07 +0100 Sebastian Hesselbarth…

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?).

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.

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.

Quoted 6 lines · On Fri, 30 Jan 2015 12:00:16 +0100 Sebastian Hesselbarth…

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?

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.

Quoted 2 lines · On Fri, 30 Jan 2015 13:03:59 +0100 Sebastian Hesselbarth…

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!

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

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 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

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

Quoted 5 lines

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.

Quoted 2 lines

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.

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... :( .

Quoted 3 lines

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.

From my previous tests with the si5351 in the Cubox, most video modes

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.

Quoted 4 lines · On Thu, 05 Feb 2015 23:13:58 +0100 Sebastian Hesselbarth…

Quoted 3 lines

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... :( .

Quoted 6 lines

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.

Quoted 5 lines

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.

Quoted 3 lines

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.

Quoted 4 lines

Quoted 2 lines

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?

Quoted 3 lines

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.

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

Quoted 4 lines · On Thu, 05 Feb 2015 23:13:58 +0100 Sebastian Hesselbarth…

Quoted 3 lines

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... :( .

Quoted 6 lines

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.

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

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?

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?

Quoted 3 lines · Sebastian Hesselbarth

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.

Quoted 2 lines

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.

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

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...

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

Quoted 10 lines · Jean-Francois Moine

On Fri, 30 Jan 2015 12:00:16 +0100

Quoted 6 lines · Sebastian Hesselbarth

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.

Quoted 2 lines

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.

Quoted 3 lines

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.

Quoted 4 lines

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.

Quoted 2 lines

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

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

Quoted 12 lines · On Friday 30 January 2015 13:03:59 Sebastian Hesselbarth wrote:

Quoted 2 lines · Jean-Francois Moine

On Fri, 30 Jan 2015 12:00:16 +0100
Sebastian Hesselbarth <[email protected]> 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.

Quoted 2 lines

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

Quoted 2 lines

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.

[Re-adding the most obvious People to Cc]

Quoted 14 lines · David Goodenough

Quoted 13 lines · On Friday 30 January 2015 13:03:59 Sebastian Hesselbarth wrote:

Quoted 3 lines · Jean-Francois Moine

On Fri, 30 Jan 2015 12:00:16 +0100

Sebastian Hesselbarth <[email protected]> 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.

Quoted 2 lines

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

Quoted 6 lines

Quoted 2 lines

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

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