[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Lee, Tommy]

Hi Buildroot Busybox,

My host is Ubuntu-14.04 LTS. My Buildroot release is 2015.05. I made the former meet the latter's requirements. My target is Marvell ARMADA A385 (ARM-Cortex-A9) DB-88F6820-GP.

While resolving my BuidrootLinux-4.0.4 VLAN trunk reachability issue, I discovered that Buildroot-2015.05 supports Marvell's MV78x000 based  ARMADA XP Family, not the DB-88F6820-GP board I am currently using.

With the current board, I have three approaches to resolve the trunk problem on it, from top to bottom:


1.      Pick "Marvell MV78xx0", from the Buildroot-2015.05 "make linux-menuconfig" ARM system type list, for ARMADA A385 to create our .config file.

2.      Upgrade Buildroot-2015.05 to 2015.08 to see whether the ARMADA A38x family is included in the ARM system type list.

3.      Get back to buildroot-2012.11-2015_T1.0 which Marvell built their system successfully. Follow Marvell's procedures to build my system.

I hope you would comment on the above approaches.

Tommy

________________________________
This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's e-mail System Administrator.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150921/6fb14d35/attachment.html>

[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Arnout Vandecappelle]

On 21-09-15 20:20, Lee, Tommy wrote:
> Hi Buildroot Busybox,
> 
>  
> 
> My host is Ubuntu-14.04 LTS. My Buildroot release is 2015.05. I made the former
> meet the latter?s requirements. My target is Marvell ARMADA A385 (ARM-Cortex-A9)
> DB-88F6820-GP.
> 
>  
> 
> While resolving my BuidrootLinux-4.0.4 VLAN trunk reachability issue, I
> discovered that Buildroot-2015.05 supports Marvell?s MV78x000 based  ARMADA XP
> Family, not the DB-88F6820-GPboard I am currently using.

 I think you're confusing buildroot with Linux. Buildroot doesn't have a
defconfig for Armada XP as far as I know.

 So you'll have to configure buildroot yourself. Start with selecting
BR2_cortex_a9 for the architecture, configure the toolchain as you like. Then
for the kernel, select an in-tree defconfig and fill in "mvebu_v7" for the
defconfig name. Also select an in-tree device tree and fill in armada-388-gp.

 Thomas Petazzoni actually worked on this board I think. Thomas, why didn't you
submit a defconfig? :-P


 Regards,
 Arnout

> 
>  
> 
> With the current board, I have three approaches to resolve the trunk problem on
> it, from top to bottom:
> 
>  
> 
> 1.      Pick ?Marvell MV78xx0?, from the Buildroot-2015.05 ?make
> linux-menuconfig? ARM system type list, for ARMADA A385 to create our .config file.
> 
> 2.      Upgrade Buildroot-2015.05 to 2015.08 to see whether the ARMADA A38x
> family is included in the ARM system type list.
> 
> 3.      Get back to buildroot-2012.11-2015_T1.0 which Marvell built their system
> successfully. Follow Marvell?s procedures to build my system.
> 
>  
> 
> I hope you would comment on the above approaches.
> 
>  
> 
> Tommy
> 
> 
> --------------------------------------------------------------------------------
> This e-mail message is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. Any unauthorized review, use,
> disclosure or distribution is prohibited. If you are not the intended recipient,
> please contact the sender by reply e-mail and destroy all copies of the original
> message. If you are the intended recipient, please be advised that the content
> of this message is subject to access, review and disclosure by the sender's
> e-mail System Administrator.
> 
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Lee, Tommy]

Arnout,



Please view my in-line relies.



Tommy



-----Original Message-----
From: Arnout Vandecappelle [mailto:arnout at mind.be]
Sent: Monday, September 21, 2015 12:58 PM
To: Lee, Tommy; buildroot at busybox.net
Cc: Thomas Petazzoni
Subject: Re: [Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue



On 21-09-15 20:20, Lee, Tommy wrote:

> Hi Buildroot Busybox,

>

>

>

> My host is Ubuntu-14.04 LTS. My Buildroot release is 2015.05. I made

> the former meet the latter's requirements. My target is Marvell ARMADA

> A385 (ARM-Cortex-A9) DB-88F6820-GP.

>

>

>

> While resolving my BuidrootLinux-4.0.4 VLAN trunk reachability issue,

> I discovered that Buildroot-2015.05 supports Marvell's MV78x000 based

> ARMADA XP Family, not the DB-88F6820-GPboard I am currently using.



I think you're confusing buildroot with Linux. Buildroot doesn't have a defconfig for Armada XP as far as I know.



I noticed that Buildroot has its own .config file which is created by the "make menuconfig" command. I have created this .config file and am using it for my work.



So you'll have to configure buildroot yourself. Start with selecting

BR2_cortex_a9 for the architecture, configure the toolchain as you like. Then for the kernel, select an in-tree defconfig and fill in "mvebu_v7" for the defconfig name. Also select an in-tree device tree and fill in armada-388-gp ".



My Buildroot .config file has following six lines relevant to this subject:



BR2_ENDIAN="LITTLE"

BR2_cortex_a9=y

BR2_LINUX_KERNEL_USE_DEFCONFIG=y

BR2_LINUX_KERNEL_DEFCONFIG="mvebu_v7"

BR2_LINUX_KERNEL_USE_INTREE_DTS=y

BR2_LINUX_KERNEL_INTREE_DTS_NAME="armada-385-db-ap"



My built kernel zImage has a root file system integrated. My U-Boot "bootz 0x02000000 - 0x01000000' command successfully booted my board. However, to enable VLAN for my work, the network interface connected to a local segment, used as the VLAN trunk, cannot ping out to a peer system on the segment.



I booted up my board using Marvell's kernel zImage and DTB. There exists no such VLAN trunk reachability problem at all.



Marvells totally gave me three DTB files, I tried my zImage and all them, one at time. Unfortunately the VLAN trunk problem still exists. With the belief that the problem is in the configuration of my kernel, Last week I used the "make linux-menuconfig" command and created my kernel .config file using the following two lines replacing the above DECONFIG lines.



BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y

BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/armada385/.config"



Because of the discovery I mentioned in my preceding email, I quit the "make linux-menuconfig" process and reported the issue this morning.



Taking your suggestion, I will rebuild my kernel zImage and DTB with "BR2_LINUX_KERNEL_INTREE_DTS_NAME="armada-388-db-ap" setting, to see whether the VLAN trunk reachability problem can be resolved.



Thomas Petazzoni actually worked on this board I think. Thomas, why didn't you submit a defconfig? :-P





Regards,

Arnout



>

>

>

> With the current board, I have three approaches to resolve the trunk

> problem on it, from top to bottom:

>

>

>

> 1.      Pick "Marvell MV78xx0", from the Buildroot-2015.05 "make

> linux-menuconfig" ARM system type list, for ARMADA A385 to create our .config file.

>

> 2.      Upgrade Buildroot-2015.05 to 2015.08 to see whether the ARMADA A38x

> family is included in the ARM system type list.

>

> 3.      Get back to buildroot-2012.11-2015_T1.0 which Marvell built their system

> successfully. Follow Marvell's procedures to build my system.

>

>

>

> I hope you would comment on the above approaches.

>

>

>

> Tommy

>

>

> ----------------------------------------------------------------------

> ---------- This e-mail message is for the sole use of the intended

> recipient(s) and may contain confidential and privileged information.

> Any unauthorized review, use, disclosure or distribution is

> prohibited. If you are not the intended recipient, please contact the

> sender by reply e-mail and destroy all copies of the original message.

> If you are the intended recipient, please be advised that the content

> of this message is subject to access, review and disclosure by the

> sender's e-mail System Administrator.

>

>

> _______________________________________________

> buildroot mailing list

> buildroot at busybox.net<mailto:buildroot@busybox.net>

> http://lists.busybox.net/mailman/listinfo/buildroot

>





--

Arnout Vandecappelle                          arnout at mind be

Senior Embedded Software Architect            +32-16-286500

Essensium/Mind                                http://www.mind.be

G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven

LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle

GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

________________________________
This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's e-mail System Administrator.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150921/52464201/attachment.html>

[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Arnout Vandecappelle]

On 22-09-15 00:28, Lee, Tommy wrote:
[snip]
> My Buildroot .config file has following six lines relevant to this subject:
> 
>  
> 
> BR2_ENDIAN="LITTLE"
> 
> BR2_cortex_a9=y
> 
> BR2_LINUX_KERNEL_USE_DEFCONFIG=y
> 
> BR2_LINUX_KERNEL_DEFCONFIG="mvebu_v7"
> 
> BR2_LINUX_KERNEL_USE_INTREE_DTS=y
> 
> BR2_LINUX_KERNEL_INTREE_DTS_NAME="armada-385-db-ap"
> 
>  
> 
> My built kernel zImage has a root file system integrated. My U-Boot ?bootz
> 0x02000000 ? 0x01000000? command successfully booted my board. 

 Your original mail sounded like you didn't even manage to boot the board.


> However, to
> enable VLAN for my work, the network interface connected to a local segment,
> used as the VLAN trunk, cannot ping out to a peer system on the segment.     

 So what does that mean? VLAN doesn't work? Or networking doesn't work at all?
Does mvebu_v7 have VLAN enabled?


> I booted up my board using Marvell?s kernel zImage and DTB. There exists no such
> VLAN trunk reachability problem at all.
> 
> Marvells totally gave me three DTB files, I tried my zImage and all them, one at
> time. Unfortunately the VLAN trunk problem still exists. 

 If it's just VLAN and not networking in general, it sounds like a kernel config
issue and not a dts issue.


> With the belief that
> the problem is in the configuration of my kernel,

 Exactly :-)

> Last week I used the ?make
> linux-menuconfig? command and created my kernel .config file using the following
> two lines replacing the above DECONFIG lines.
> 
>  
> 
> BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
> 
> BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/armada385/.config"
> 
>  
> 
> Because of the discovery I mentioned in my preceding email, I quit the ?make
> linux-menuconfig? process and reported the issue this morning.  

 What discovery?

> 
>  
> 
> Taking your suggestion, I will rebuild my kernel zImage and DTB with
> ?BR2_LINUX_KERNEL_INTREE_DTS_NAME="armada-388-db-ap? setting, to see whether the
> VLAN trunk reachability problem can be resolved.

 Well, that's what you tried before, no?



 Regards,
 Arnout

 PS We prefer non-HTML mails on this list, and also proper quoting in replies.


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Lee, Tommy]

Arnout,



Please view my in-line replies.



Tommy



-----Original Message-----
From: Arnout Vandecappelle [mailto:arnout at mind.be]
Sent: Monday, September 21, 2015 3:50 PM
To: Lee, Tommy; buildroot at busybox.net
Cc: Thomas Petazzoni
Subject: Re: [Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue



.....



So what does that mean? VLAN doesn't work? Or networking doesn't work at all?



VLAN cannot be enabled. The error messages are:



# vconfig add eth0 1

vconfig: ioctl error for add: Package not installed



I see it not the basic issue. My board has eth2 and eth0. The former is DHCP enabled on my corporate network, while the latter has a static IP address in the /etc/network/interfaces file:



Auto eth0

address 192.168.1.5

netmask 255.255.0.0



Once I enabled it by the "ifup eth0" command, the error messages came up as:



# ifup eth0

[  679.334836] mvneta f1030000.ethernet eth0: could not find the PHY

[  679.340948] mvneta f1030000.ethernet eth0: cannot probe MDIO bus

ip: SIOCSIFFLAGS: No such device

ip: RTNETLINK answers: Network is unreachable



Though the IP address can be assigned to it. This address cannot be reached by a peer system on the 192.168.0.0 segment.



# ifconfig -a

eth0      Link encap:Ethernet  HWaddr 00:50:43:48:16:4D

          inet addr:192.168.1.5  Bcast:0.0.0.0  Mask:255.255.255.0

          BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:532



.....



Does mvebu_v7 have VLAN enabled?



It originally has no VLAN enabled. Last week I added following three lines:



CONFIG_CFG8021Q=y

CONFIG_MACVLAN=y

CONFIG_IPVLAN=y



The vconfig messages are still same.



.....



What discovery?



The discovery is depicted as below:



ARM system type (Marvell PXA168/910/MMP2)  --->

       ( ) Marvell Dove

       ( ) Marvell MV78xx0

-----

Marvell PXA168/910/MMP2 Implmentations  --->

    [*] Marvell DB-78x00-BP Development Board (NEW)

    [ ] Marvell RD-78x00-mASA Reference Design (NEW)



There is no implementation for the A385 board but the MV78xx0-based ARMADA XP boards.



.....



Well, that's what you tried before, no?



This is my first time of using the "BR2_LINUX_KERNEL_INTREE_DTS_NAME="armada-388-db-ap" setting.



Regards,

Arnout



________________________________
This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's e-mail System Administrator.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150921/68e8238c/attachment.html>

[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Thomas Petazzoni]

Hello,

On Mon, 21 Sep 2015 21:57:32 +0200, Arnout Vandecappelle wrote:

>  So you'll have to configure buildroot yourself. Start with selecting
> BR2_cortex_a9 for the architecture, configure the toolchain as you like. Then
> for the kernel, select an in-tree defconfig and fill in "mvebu_v7" for the
> defconfig name. Also select an in-tree device tree and fill in armada-388-gp.
> 
>  Thomas Petazzoni actually worked on this board I think. Thomas, why didn't you
> submit a defconfig? :-P

I actually did a bit more than working on this board, since we (Free
Electrons) did the support for the Armada 38x SoC in the mainline Linux
kernel.

The reason why I didn't submit a defconfig is because there is no
full-featured publicly available bootloader for these platforms. The
bootloader provided by Marvell is not publicly available (you have to
be a customer, and use an account to access their Extranet and download
the U-Boot sources). There is now some U-Boot support in the mainline
U-Boot, but I haven't tried it yet.

So I could submit a huge bunch of defconfigs for all the Armada 370,
XP, 375, 38x and 39x platforms that I have (it would probably be 15 to
20 defconfigs), but they would only differ by the name of the Device
Tree in the defconfig. All the rest would be exactly the same. So I
wasn't sure it was really worth adding 15 to 20 more defconfigs for a
configuration that doesn't include the bootloader and where all
configurations would be almost identical.

That being said, if there is some interest in this, I can definitely do
it.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Lee, Tommy]

Thomas,



Please view my in-line replies.



Tommy



-----Original Message-----
From: Thomas Petazzoni [mailto:thomas.petazzoni at free-electrons.com]
Sent: Wednesday, September 23, 2015 8:06 AM
To: Arnout Vandecappelle
Cc: Lee, Tommy; buildroot at busybox.net
Subject: Re: [Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue



Hello,



On Mon, 21 Sep 2015 21:57:32 +0200, Arnout Vandecappelle wrote:



>  So you'll have to configure buildroot yourself. Start with selecting

> BR2_cortex_a9 for the architecture, configure the toolchain as you

> like. Then for the kernel, select an in-tree defconfig and fill in

> "mvebu_v7" for the defconfig name. Also select an in-tree device tree and fill in armada-388-gp.

>

>  Thomas Petazzoni actually worked on this board I think. Thomas, why

> didn't you submit a defconfig? :-P



I actually did a bit more than working on this board, since we (Free

Electrons) did the support for the Armada 38x SoC in the mainline Linux kernel.



I received from my project management the Marvell's A385 package in July. Then I started the work on the board in the package - DB-88F6820-GP. What I have achieved is the success of building and booting the Linux-4.0.4 system on the DB-88F6820-GP board. The system is built with mvebu_v7_defconfig and armada-385-db-ap.dts.



My current problem, as I mentioned in my preceding email, is that the eth0 and eth1 interfaces cannot be enabled, but eth2 at the boot time.



The interest point is that the kernel and DTB images in Marvell's USB storage device can enable these two interfaces: eth0 at the boot time; eth1 via the /etc/network/interfaces editing and the "ifup eth1" process.



The reason why I didn't submit a defconfig is because there is no full-featured publicly available bootloader for these platforms. The bootloader provided by Marvell is not publicly available (you have to be a customer, and use an account to access their Extranet and download the U-Boot sources). There is now some U-Boot support in the mainline U-Boot, but I haven't tried it yet.



Up to now I am just a user of the U-Boot-1.73 on the DB-88F6820-GP board. Once I receive the board from my project management I definitely need to build one which is specific to the board.



So I could submit a huge bunch of defconfigs for all the Armada 370, XP, 375, 38x and 39x platforms that I have (it would probably be 15 to

20 defconfigs), but they would only differ by the name of the Device Tree in the defconfig. All the rest would be exactly the same. So I wasn't sure it was really worth adding 15 to 20 more defconfigs for a configuration that doesn't include the bootloader and where all configurations would be almost identical.



There are three DTB files in Marvell's USB storage device. I have tried all of them with my 4.0.4 system zImage. However, the problem of the network interfaces still occurs. The reason for my tries is that Marvell must use one of them to succeed in the eth0 boot-time enabling.



That being said, if there is some interest in this, I can definitely do it.



I am trying to resolve the problem now with Marvell's package as reference. I believe the problem is on the kernel configuration, not DTB.



Listed here are contents of Marvell's package:



ARMADAsoftware

ARMADAsoftware.rar

DB-88F6820-GP

DB-88F6820-GP.rar

gcc-linaro-arm-linux-gnueabihf-4.8-2013.05_linux

gcc-linaro-arm-linux-gnueabihf-4.8-2013.05_linux.tar.bz2

linux-3.10.70-2015_T1.1.tar.gz

net-snmp-5.7.3

net-snmp-5.7.3.tar

RN_Linux_3.10_2015_T1.1_PQ.pdf

u-boot-2013.01

u-boot-2013.01.tar.bz2



You probably like to know the details of them partially.



Best regards,



Thomas

--

Thomas Petazzoni, CTO, Free Electrons

Embedded Linux, Kernel and Android engineering http://free-electrons.com

________________________________
This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's e-mail System Administrator.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150923/f3b28485/attachment.html>

[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Lee, Tommy]

Thomas,

FYI, I found the fourth DTB file in Marvell's USB device. I tried it with my mvebu_v7_defconfig zImage. The eth0 is surprisingly enabled at the boot time. The reason is that I set following lines in my .config file as:

BR2_SYSTEM_DHCP="eth0"
BR2_PACKAGE_DHCPCD=y
BR2_PACKAGE_DHCPDUMP=y

The eth0 interface can reach other PC on a corporate network. I am seeing this result a progress.

I will try to make the eth1 interface work on a local segment.

Tommy

From: Lee, Tommy
Sent: Wednesday, September 23, 2015 10:58 AM
To: 'Thomas Petazzoni'
Cc: buildroot at busybox.net; Arnout Vandecappelle
Subject: RE: [Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue


Thomas,



Please view my in-line replies.



Tommy



-----Original Message-----
From: Thomas Petazzoni [mailto:thomas.petazzoni at free-electrons.com]
Sent: Wednesday, September 23, 2015 8:06 AM
To: Arnout Vandecappelle
Cc: Lee, Tommy; buildroot at busybox.net<mailto:buildroot@busybox.net>
Subject: Re: [Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue



Hello,



On Mon, 21 Sep 2015 21:57:32 +0200, Arnout Vandecappelle wrote:



>  So you'll have to configure buildroot yourself. Start with selecting

> BR2_cortex_a9 for the architecture, configure the toolchain as you

> like. Then for the kernel, select an in-tree defconfig and fill in

> "mvebu_v7" for the defconfig name. Also select an in-tree device tree and fill in armada-388-gp.

>

>  Thomas Petazzoni actually worked on this board I think. Thomas, why

> didn't you submit a defconfig? :-P



I actually did a bit more than working on this board, since we (Free

Electrons) did the support for the Armada 38x SoC in the mainline Linux kernel.



I received from my project management the Marvell's A385 package in July. Then I started the work on the board in the package - DB-88F6820-GP. What I have achieved is the success of building and booting the Linux-4.0.4 system on the DB-88F6820-GP board. The system is built with mvebu_v7_defconfig and armada-385-db-ap.dts.



My current problem, as I mentioned in my preceding email, is that the eth0 and eth1 interfaces cannot be enabled, but eth2 at the boot time.



The interest point is that the kernel and DTB images in Marvell's USB storage device can enable these two interfaces: eth0 at the boot time; eth1 via the /etc/network/interfaces editing and the "ifup eth1" process.



The reason why I didn't submit a defconfig is because there is no full-featured publicly available bootloader for these platforms. The bootloader provided by Marvell is not publicly available (you have to be a customer, and use an account to access their Extranet and download the U-Boot sources). There is now some U-Boot support in the mainline U-Boot, but I haven't tried it yet.



Up to now I am just a user of the U-Boot-1.73 on the DB-88F6820-GP board. Once I receive the board from my project management I definitely need to build one which is specific to the board.



So I could submit a huge bunch of defconfigs for all the Armada 370, XP, 375, 38x and 39x platforms that I have (it would probably be 15 to

20 defconfigs), but they would only differ by the name of the Device Tree in the defconfig. All the rest would be exactly the same. So I wasn't sure it was really worth adding 15 to 20 more defconfigs for a configuration that doesn't include the bootloader and where all configurations would be almost identical.



There are three DTB files in Marvell's USB storage device. I have tried all of them with my 4.0.4 system zImage. However, the problem of the network interfaces still occurs. The reason for my tries is that Marvell must use one of them to succeed in the eth0 boot-time enabling.



That being said, if there is some interest in this, I can definitely do it.



I am trying to resolve the problem now with Marvell's package as reference. I believe the problem is on the kernel configuration, not DTB.



Listed here are contents of Marvell's package:



ARMADAsoftware

ARMADAsoftware.rar

DB-88F6820-GP

DB-88F6820-GP.rar

gcc-linaro-arm-linux-gnueabihf-4.8-2013.05_linux

gcc-linaro-arm-linux-gnueabihf-4.8-2013.05_linux.tar.bz2

linux-3.10.70-2015_T1.1.tar.gz

net-snmp-5.7.3

net-snmp-5.7.3.tar

RN_Linux_3.10_2015_T1.1_PQ.pdf

u-boot-2013.01

u-boot-2013.01.tar.bz2



You probably like to know the details of them partially.



Best regards,



Thomas

--

Thomas Petazzoni, CTO, Free Electrons

Embedded Linux, Kernel and Android engineering http://free-electrons.com

________________________________
This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's e-mail System Administrator.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150923/503f3a61/attachment.html>

[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Thomas Petazzoni]

Hello,

On Wed, 23 Sep 2015 10:58:15 -0700, Lee, Tommy wrote:

> Please view my in-line replies.

It would be nicer if you actually used an e-mail client that was
quoting properly the text you're replying to in the plain text version
of the e-mail (and avoid sending an HTML version).

> I received from my project management the Marvell's A385 package in
> July. Then I started the work on the board in the package -
> DB-88F6820-GP. What I have achieved is the success of building and
> booting the Linux-4.0.4 system on the DB-88F6820-GP board. The system
> is built with mvebu_v7_defconfig and armada-385-db-ap.dts.

This is not the correct Device Tree file. Use armada-388-gp.dts for the
DB-88F6820-GP. Using an incorrect Device Tree file might work
partially, but some devices may not work (especially network
interfaces, which are very often not configured in the same way between
different boards).

> My current problem, as I mentioned in my preceding email, is that the
> eth0 and eth1 interfaces cannot be enabled, but eth2 at the boot time.

Two things:

 * Remember what I already told you: the network interfaces are
   "inverted". eth0 is the second network interface, and eth1 is the
   first network interface.

 * Use "setenv fdt_skip_update yes" in U-Boot before booting, to tell
   the Marvell U-Boot to not do any magic fixup in the Device Tree
   before starting the kernel.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Lee, Tommy]

Thomas,

Please view the log below my message.

I just booted my /mvebu_v7_defconfig/armada-388-gp.dts zImage and armada-388-gp.dtb. The eth0 interface cannot be enabled at the boot time or by the subsequent "ifup th0" command. It looks like the DHCP server cannot be found. I probably need to review my output/build/linux-headers-4.0.4/arch/arm/boot/dts/armada-388-gp.dts to try to find out the cause.

Tommy

# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:50:43:48:16:4D
          inet6 addr: fe80::250:43ff:fe48:164d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:532
          RX bytes:0 (0.0 B)  TX bytes:990 (990.0 B)
          Interrupt:35

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

# cat /etc/network/interfaces
# interface file auto-generated by buildroot

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp# ifup eth0
udhcpc (v1.23.2) started
Sending discover...
Sending discover...
Sending discover...
No lease, failing



The eth0 interface cannot be enabled at the boot time.



-----Original Message-----
From: buildroot [mailto:buildroot-bounces at busybox.net] On Behalf Of Thomas Petazzoni
Sent: Thursday, September 24, 2015 12:26 AM
To: Lee, Tommy
Cc: buildroot at busybox.net
Subject: Re: [Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

Hello,

On Wed, 23 Sep 2015 10:58:15 -0700, Lee, Tommy wrote:

> Please view my in-line replies.

It would be nicer if you actually used an e-mail client that was quoting properly the text you're replying to in the plain text version of the e-mail (and avoid sending an HTML version).

> I received from my project management the Marvell's A385 package in
> July. Then I started the work on the board in the package -
> DB-88F6820-GP. What I have achieved is the success of building and
> booting the Linux-4.0.4 system on the DB-88F6820-GP board. The system
> is built with mvebu_v7_defconfig and armada-385-db-ap.dts.

This is not the correct Device Tree file. Use armada-388-gp.dts for the DB-88F6820-GP. Using an incorrect Device Tree file might work partially, but some devices may not work (especially network interfaces, which are very often not configured in the same way between different boards).

> My current problem, as I mentioned in my preceding email, is that the
> eth0 and eth1 interfaces cannot be enabled, but eth2 at the boot time.

Two things:

 * Remember what I already told you: the network interfaces are
   "inverted". eth0 is the second network interface, and eth1 is the
   first network interface.

 * Use "setenv fdt_skip_update yes" in U-Boot before booting, to tell
   the Marvell U-Boot to not do any magic fixup in the Device Tree
   before starting the kernel.

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering http://free-electrons.com _______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's e-mail System Administrator.

[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 > The reason why I didn't submit a defconfig is because there is no
 > full-featured publicly available bootloader for these platforms. The
 > bootloader provided by Marvell is not publicly available (you have to
 > be a customer, and use an account to access their Extranet and download
 > the U-Boot sources). There is now some U-Boot support in the mainline
 > U-Boot, but I haven't tried it yet.

Ok, but I guess missing open u-boot support shouldn't be a deal
breaker. We already have a few defconfigs without bootloader config
(lego_ev3, openblocks_a6, s6lx9_microboard, ..).


 > So I could submit a huge bunch of defconfigs for all the Armada 370,
 > XP, 375, 38x and 39x platforms that I have (it would probably be 15 to
 > 20 defconfigs), but they would only differ by the name of the Device
 > Tree in the defconfig. All the rest would be exactly the same. So I
 > wasn't sure it was really worth adding 15 to 20 more defconfigs for a
 > configuration that doesn't include the bootloader and where all
 > configurations would be almost identical.

Couldn't we just do a single defconfig that builds all the dtb files and
then add a README describing what dtb / how to boot on the various
boards?

-- 
Bye, Peter Korsgaard

[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Lee, Tommy]

Hi,

I do not know any other ARMADA A38x issues hanging there. My issue is the boot-time enabling of two eth interfaces on the DB-88F6820-GP board - eth0 for DHCP; eth1 for static.

Yesterday I used one of four Marvell's DTB files with my 4.0.4 system zImage built with mvebu_v7_defconfig. The boot process automatically enabled only eth0.

Unfortunately I do not have the DTS file for building that DTB file. I am reviewing the relevant DTS files, in the 2015.05 and Marvell's 2012.11 file systems, to try to resolve the eth1 enabling issue now.

Tommy

-----Original Message-----
From: Peter Korsgaard [mailto:jacmet at gmail.com] On Behalf Of Peter Korsgaard
Sent: Thursday, September 24, 2015 2:48 PM
To: Thomas Petazzoni
Cc: Arnout Vandecappelle; buildroot at busybox.net; Lee, Tommy
Subject: Re: Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 > The reason why I didn't submit a defconfig is because there is no  > full-featured publicly available bootloader for these platforms. The  > bootloader provided by Marvell is not publicly available (you have to  > be a customer, and use an account to access their Extranet and download  > the U-Boot sources). There is now some U-Boot support in the mainline  > U-Boot, but I haven't tried it yet.

Ok, but I guess missing open u-boot support shouldn't be a deal breaker. We already have a few defconfigs without bootloader config (lego_ev3, openblocks_a6, s6lx9_microboard, ..).


 > So I could submit a huge bunch of defconfigs for all the Armada 370,  > XP, 375, 38x and 39x platforms that I have (it would probably be 15 to  > 20 defconfigs), but they would only differ by the name of the Device  > Tree in the defconfig. All the rest would be exactly the same. So I  > wasn't sure it was really worth adding 15 to 20 more defconfigs for a  > configuration that doesn't include the bootloader and where all  > configurations would be almost identical.

Couldn't we just do a single defconfig that builds all the dtb files and then add a README describing what dtb / how to boot on the various boards?

--
Bye, Peter Korsgaard

This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's e-mail System Administrator.

[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Thomas Petazzoni]

Hello,

On Thu, 24 Sep 2015 23:48:12 +0200, Peter Korsgaard wrote:

>  > So I could submit a huge bunch of defconfigs for all the Armada 370,
>  > XP, 375, 38x and 39x platforms that I have (it would probably be 15 to
>  > 20 defconfigs), but they would only differ by the name of the Device
>  > Tree in the defconfig. All the rest would be exactly the same. So I
>  > wasn't sure it was really worth adding 15 to 20 more defconfigs for a
>  > configuration that doesn't include the bootloader and where all
>  > configurations would be almost identical.
> 
> Couldn't we just do a single defconfig that builds all the dtb files and
> then add a README describing what dtb / how to boot on the various
> boards?

Right, we could do that. But it's really as simple as taking some
random mainline kernel version and build mvebu_v7_defconfig. It's not a
defconfig that has a lot of added-value.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Stefan Peter]

Hi Tommy

Am 25.09.2015 um 00:53 schrieb Lee, Tommy:
> Hi,
> Yesterday I used one of four Marvell's DTB files with my 4.0.4 system zImage built with mvebu_v7_defconfig. The boot process automatically enabled only eth0.
> 
> Unfortunately I do not have the DTS file for building that DTB file. I am reviewing the relevant DTS files, in the 2015.05 and Marvell's 2012.11 file systems, to try to resolve the eth1 enabling issue now.

dtc, the device tree compiler, can decompile dtb to dts. If memory
serves right, you can use something along

dtc -I DTB -O DTS yourfile.dtb

With kind regards

Stefan Peter

[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

>> Couldn't we just do a single defconfig that builds all the dtb files and
 >> then add a README describing what dtb / how to boot on the various
 >> boards?

 > Right, we could do that. But it's really as simple as taking some
 > random mainline kernel version and build mvebu_v7_defconfig. It's not a
 > defconfig that has a lot of added-value.

Ok, and the Marvell u-boot supports zImage / separate dtb or do you need
to play tricks with appended dtb? Anything related to the bootloader
that is worthwhile documenting?

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Thomas Petazzoni]

Hello,

On Fri, 25 Sep 2015 09:41:50 +0200, Peter Korsgaard wrote:

> >> Couldn't we just do a single defconfig that builds all the dtb files and
>  >> then add a README describing what dtb / how to boot on the various
>  >> boards?
> 
>  > Right, we could do that. But it's really as simple as taking some
>  > random mainline kernel version and build mvebu_v7_defconfig. It's not a
>  > defconfig that has a lot of added-value.
> 
> Ok, and the Marvell u-boot supports zImage / separate dtb or do you need
> to play tricks with appended dtb?

Depends on the version of the bootloader. On modern ones (375, 38x)
there's no problem (except you need to set some magic fdt_skip_update
U-Boot variable to prevent the vendor U-Boot from doing nasty FDT
updates). On Armada 370/XP, the situation is a bit more complicated:
very old vendor bootloaders map registers at a different address than
recent bootloaders, and they don't all support FDT booting, so you have
to use appended DTB.

> Anything related to the bootloader that is worthwhile documenting?

Lots :)

Actually, I've been thinking for some time doing some kind of
eLinux.org portal/page about the Marvell EBU boards, because there's
quite a few tricks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

>> Ok, and the Marvell u-boot supports zImage / separate dtb or do you need
 >> to play tricks with appended dtb?

 > Depends on the version of the bootloader. On modern ones (375, 38x)
 > there's no problem (except you need to set some magic fdt_skip_update
 > U-Boot variable to prevent the vendor U-Boot from doing nasty FDT
 > updates). On Armada 370/XP, the situation is a bit more complicated:
 > very old vendor bootloaders map registers at a different address than
 > recent bootloaders, and they don't all support FDT booting, so you have
 > to use appended DTB.

That kind of stuff would be useful for in a README ;) Also where the
bootloader searches for the files / SD card partitioning and so on.


 >> Anything related to the bootloader that is worthwhile documenting?

 > Lots :)

 > Actually, I've been thinking for some time doing some kind of
 > eLinux.org portal/page about the Marvell EBU boards, because there's
 > quite a few tricks.

Ok, that's also good. The Buildroot readme can also just refer to that
page.

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

[Lee, Tommy]

Stefan,

Thanks for sharing your experience. I will do it when I get back to this work.

Tommy

-----Original Message-----
From: buildroot [mailto:buildroot-bounces at busybox.net] On Behalf Of Stefan Peter
Sent: Friday, September 25, 2015 12:40 AM
To: buildroot at busybox.net
Subject: Re: [Buildroot] Building system for the Marvell's ARMADA A385 borad to resolve the VLAN trunk issue

Hi Tommy

Am 25.09.2015 um 00:53 schrieb Lee, Tommy:
> Hi,
> Yesterday I used one of four Marvell's DTB files with my 4.0.4 system zImage built with mvebu_v7_defconfig. The boot process automatically enabled only eth0.
>
> Unfortunately I do not have the DTS file for building that DTB file. I am reviewing the relevant DTS files, in the 2015.05 and Marvell's 2012.11 file systems, to try to resolve the eth1 enabling issue now.

dtc, the device tree compiler, can decompile dtb to dts. If memory serves right, you can use something along

dtc -I DTB -O DTS yourfile.dtb

With kind regards

Stefan Peter

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's e-mail System Administrator.