[Buildroot] [PATCH/next 0/5] Add support for MacchiatoBin board

[Buildroot] [PATCH/next 0/5] Add support for MacchiatoBin board

[Sergey Matyukevich]

Hi all,

This patchset adds support for SolidRun MacchiatoBin board based on
Marvell Armada 8040 SoC. For convenience the following two different
build configurations are added:

- mainline BSP
  mainline Linux v4.13.11 and U-Boot v2017.09

- vendor BSP (enables more hardware)
  BSP from Marvell based on Linux 4.4.52 and U-Boot v2017.03

Patches are rebased on top of next branch.

Regards,
Sergey

Sergey Matyukevich (5):
  armada-firmware: new package
  armada-ddr: new package
  atf: add support for Marvell Armada SoCs
  solidrun/macchiatobin: add new board
  DEVELOPERS: add myself to MacchiatoBin releated packages

 DEVELOPERS                                        |    6 +
 board/solidrun/macchiatobin/genimage.cfg          |   16 +++++
 board/solidrun/macchiatobin/readme.txt            |   70 ++++++++++++++++++++++
 boot/Config.in                                    |    2 
 boot/arm-trusted-firmware/arm-trusted-firmware.mk |   13 ++++
 boot/armada-ddr/Config.in                         |   16 +++++
 boot/armada-ddr/armada-ddr.hash                   |    2 
 boot/armada-ddr/armada-ddr.mk                     |   20 ++++++
 boot/armada-firmware/Config.in                    |   19 +++++
 boot/armada-firmware/armada-firmware.hash         |    2 
 boot/armada-firmware/armada-firmware.mk           |   18 +++++
 configs/solidrun_macchiatobin_mainline_defconfig  |   46 ++++++++++++++
 configs/solidrun_macchiatobin_marvell_defconfig   |   48 +++++++++++++++
 13 files changed, 278 insertions(+)

[Buildroot] [PATCH/next 1/5] armada-firmware: new package

[Sergey Matyukevich]

This package adds SCP BL2 firmware for Marvell Armada 7040 and 8040 SoCs.

Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
---
 boot/Config.in                            |  1 +
 boot/armada-firmware/Config.in            | 19 +++++++++++++++++++
 boot/armada-firmware/armada-firmware.hash |  2 ++
 boot/armada-firmware/armada-firmware.mk   | 18 ++++++++++++++++++
 4 files changed, 40 insertions(+)
 create mode 100644 boot/armada-firmware/Config.in
 create mode 100644 boot/armada-firmware/armada-firmware.hash
 create mode 100644 boot/armada-firmware/armada-firmware.mk

diff --git a/boot/Config.in b/boot/Config.in
index 2f46c8546e..0ffbd7288b 100644
--- a/boot/Config.in
+++ b/boot/Config.in
@@ -17,5 +17,6 @@ source "boot/ts4800-mbrboot/Config.in"
 source "boot/uboot/Config.in"
 source "boot/vexpress-firmware/Config.in"
 source "boot/xloader/Config.in"
+source "boot/armada-firmware/Config.in"
 
 endmenu
diff --git a/boot/armada-firmware/Config.in b/boot/armada-firmware/Config.in
new file mode 100644
index 0000000000..530b5622c8
--- /dev/null
+++ b/boot/armada-firmware/Config.in
@@ -0,0 +1,19 @@
+config BR2_TARGET_ARMADA_FIRMWARE
+	bool "armada-firmware"
+	depends on BR2_aarch64
+	help
+	  Marvell Armada SCP BL2 firmware images.
+
+if BR2_TARGET_ARMADA_FIRMWARE
+
+config BR2_TARGET_ARMADA_FIRMWARE_IMAGE
+	string "Armada SCP BL2 image name"
+	help
+	  Armada SCP BL2 firmware image name.
+
+config BR2_TARGET_ARMADA_FIRMWARE_VERSION
+	string "Armada SCP BL2 image version"
+	help
+	  Armada SCP BL2 firmware image version.
+
+endif
diff --git a/boot/armada-firmware/armada-firmware.hash b/boot/armada-firmware/armada-firmware.hash
new file mode 100644
index 0000000000..5eeca9d6ea
--- /dev/null
+++ b/boot/armada-firmware/armada-firmware.hash
@@ -0,0 +1,2 @@
+# Locally calculated
+sha256 b310443c0d51d07b7c11597548685ae608b8478eee7095925427da6ab71e0168 armada-firmware-binaries-marvell-armada-17.10.tar.gz
diff --git a/boot/armada-firmware/armada-firmware.mk b/boot/armada-firmware/armada-firmware.mk
new file mode 100644
index 0000000000..d75dc7cb6c
--- /dev/null
+++ b/boot/armada-firmware/armada-firmware.mk
@@ -0,0 +1,18 @@
+################################################################################
+#
+# Marvell Armada SCP BL2 firmware images
+#
+################################################################################
+
+ARMADA_FIRMWARE_VERSION = $(call qstrip,$(BR2_TARGET_ARMADA_FIRMWARE_VERSION))
+ARMADA_FIRMWARE_SITE = $(call github,MarvellEmbeddedProcessors,binaries-marvell,$(ARMADA_FIRMWARE_VERSION))
+ARMADA_FIRMWARE_LICENSE = Proprietary
+
+ARMADA_FIRMWARE_INSTALL_IMAGES  = YES
+
+define ARMADA_FIRMWARE_INSTALL_IMAGES_CMDS
+	$(INSTALL) -D -m 0644 $(@D)/mrvl_scp_bl2_7040.img $(BINARIES_DIR)/mrvl_scp_bl2_7040.img
+	$(INSTALL) -D -m 0644 $(@D)/mrvl_scp_bl2_8040.img $(BINARIES_DIR)/mrvl_scp_bl2_8040.img
+endef
+
+$(eval $(generic-package))
-- 
2.11.0

[Buildroot] [PATCH/next 1/5] armada-firmware: new package

[Baruch Siach]

Hi Sergey,

On Sun, Nov 12, 2017 at 11:16:42PM +0300, Sergey Matyukevich wrote:
> This package adds SCP BL2 firmware for Marvell Armada 7040 and 8040 SoCs.
> 
> Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
> ---
>  boot/Config.in                            |  1 +
>  boot/armada-firmware/Config.in            | 19 +++++++++++++++++++
>  boot/armada-firmware/armada-firmware.hash |  2 ++
>  boot/armada-firmware/armada-firmware.mk   | 18 ++++++++++++++++++
>  4 files changed, 40 insertions(+)
>  create mode 100644 boot/armada-firmware/Config.in
>  create mode 100644 boot/armada-firmware/armada-firmware.hash
>  create mode 100644 boot/armada-firmware/armada-firmware.mk
> 
> diff --git a/boot/Config.in b/boot/Config.in
> index 2f46c8546e..0ffbd7288b 100644
> --- a/boot/Config.in
> +++ b/boot/Config.in
> @@ -17,5 +17,6 @@ source "boot/ts4800-mbrboot/Config.in"
>  source "boot/uboot/Config.in"
>  source "boot/vexpress-firmware/Config.in"
>  source "boot/xloader/Config.in"
> +source "boot/armada-firmware/Config.in"
>  
>  endmenu
> diff --git a/boot/armada-firmware/Config.in b/boot/armada-firmware/Config.in
> new file mode 100644
> index 0000000000..530b5622c8
> --- /dev/null
> +++ b/boot/armada-firmware/Config.in
> @@ -0,0 +1,19 @@
> +config BR2_TARGET_ARMADA_FIRMWARE
> +	bool "armada-firmware"
> +	depends on BR2_aarch64
> +	help
> +	  Marvell Armada SCP BL2 firmware images.
> +
> +if BR2_TARGET_ARMADA_FIRMWARE
> +
> +config BR2_TARGET_ARMADA_FIRMWARE_IMAGE
> +	string "Armada SCP BL2 image name"
> +	help
> +	  Armada SCP BL2 firmware image name.

This symbol is not used here, which is quite unusual. Instead, you set this 
symbol in the defconfig, and use it in the ATF package. But since we'll use 
only one of the 7k/8k images (right?), I suggest to add a 7k/8k choice, and 
make BR2_TARGET_ARMADA_FIRMWARE_IMAGE a blink symbol that is set (default) 
according to the choice.

Something like (abbreviated; untested):

choice
    prompt "Armada platform"

config BR2_PACKAGE_ARMADA_8040
    bool "8040"

config BR2_PACKAGE_ARMADA_7040
    bool "7040"

endchoice

config BR2_TARGET_ARMADA_FIRMWARE_IMAGE
    string
    default "mrvl_scp_bl2_8040.img" if BR2_PACKAGE_ARMADA_8040
    default "mrvl_scp_bl2_7040.img" if BR2_PACKAGE_ARMADA_7040

> +config BR2_TARGET_ARMADA_FIRMWARE_VERSION
> +	string "Armada SCP BL2 image version"
> +	help
> +	  Armada SCP BL2 firmware image version.
> +
> +endif
> diff --git a/boot/armada-firmware/armada-firmware.hash b/boot/armada-firmware/armada-firmware.hash
> new file mode 100644
> index 0000000000..5eeca9d6ea
> --- /dev/null
> +++ b/boot/armada-firmware/armada-firmware.hash
> @@ -0,0 +1,2 @@
> +# Locally calculated
> +sha256 b310443c0d51d07b7c11597548685ae608b8478eee7095925427da6ab71e0168 armada-firmware-binaries-marvell-armada-17.10.tar.gz
> diff --git a/boot/armada-firmware/armada-firmware.mk b/boot/armada-firmware/armada-firmware.mk
> new file mode 100644
> index 0000000000..d75dc7cb6c
> --- /dev/null
> +++ b/boot/armada-firmware/armada-firmware.mk
> @@ -0,0 +1,18 @@
> +################################################################################
> +#
> +# Marvell Armada SCP BL2 firmware images
> +#
> +################################################################################
> +
> +ARMADA_FIRMWARE_VERSION = $(call qstrip,$(BR2_TARGET_ARMADA_FIRMWARE_VERSION))

Having a configurable version is an exception of very few packages (linux, 
uboot, ATF). Other packages should set to a static version string or a commit 
id when there is no official version release.

> +ARMADA_FIRMWARE_SITE = $(call github,MarvellEmbeddedProcessors,binaries-marvell,$(ARMADA_FIRMWARE_VERSION))
> +ARMADA_FIRMWARE_LICENSE = Proprietary

These binaries come with no license, so you should also add 
ARMADA_FIRMWARE_REDISTRIBUTE = NO.

> +
> +ARMADA_FIRMWARE_INSTALL_IMAGES  = YES
> +
> +define ARMADA_FIRMWARE_INSTALL_IMAGES_CMDS
> +	$(INSTALL) -D -m 0644 $(@D)/mrvl_scp_bl2_7040.img $(BINARIES_DIR)/mrvl_scp_bl2_7040.img
> +	$(INSTALL) -D -m 0644 $(@D)/mrvl_scp_bl2_8040.img $(BINARIES_DIR)/mrvl_scp_bl2_8040.img
> +endef
> +
> +$(eval $(generic-package))

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] [PATCH/next 1/5] armada-firmware: new package

[Sergey Matyukevich]

Hi Baruch,

Thanks a lot for your thorough review !

> > new file mode 100644
> > index 0000000000..530b5622c8
> > --- /dev/null
> > +++ b/boot/armada-firmware/Config.in
> > @@ -0,0 +1,19 @@
> > +config BR2_TARGET_ARMADA_FIRMWARE
> > +	bool "armada-firmware"
> > +	depends on BR2_aarch64
> > +	help
> > +	  Marvell Armada SCP BL2 firmware images.
> > +
> > +if BR2_TARGET_ARMADA_FIRMWARE
> > +
> > +config BR2_TARGET_ARMADA_FIRMWARE_IMAGE
> > +	string "Armada SCP BL2 image name"
> > +	help
> > +	  Armada SCP BL2 firmware image name.
> 
> This symbol is not used here, which is quite unusual. Instead, you set this 
> symbol in the defconfig, and use it in the ATF package. But since we'll use 
> only one of the 7k/8k images (right?), I suggest to add a 7k/8k choice, and 
> make BR2_TARGET_ARMADA_FIRMWARE_IMAGE a blink symbol that is set (default) 
> according to the choice.
> 
> Something like (abbreviated; untested):
> 
> choice
>     prompt "Armada platform"
> 
> config BR2_PACKAGE_ARMADA_8040
>     bool "8040"
> 
> config BR2_PACKAGE_ARMADA_7040
>     bool "7040"
> 
> endchoice
> 
> config BR2_TARGET_ARMADA_FIRMWARE_IMAGE
>     string
>     default "mrvl_scp_bl2_8040.img" if BR2_PACKAGE_ARMADA_8040
>     default "mrvl_scp_bl2_7040.img" if BR2_PACKAGE_ARMADA_7040

Well, I used string field to specify firmware name because earlier versions
of Armada firmware may have different names. For instance, branch 17.08
contains single firmware blob RTOSDemo-cm3.bin. So if we specify branch of
Armada firmware repository, we have to specify firmware blob name as well.

On the other hand, as you mentioned in subsequent comment, having a
configurable version for this firmware is not a good idea. So if we
set it to the static version (now the latest is 17.10), then we can use
suggested 'choice' menu. Moreover, as you mentioned, it is not really
needed for upstream BSP. I will check if it is needed for Marvell BSP.
If not, then it should be safe to drop this package altogether.

> > new file mode 100644
> > index 0000000000..d75dc7cb6c
> > --- /dev/null
> > +++ b/boot/armada-firmware/armada-firmware.mk
> > @@ -0,0 +1,18 @@
> > +################################################################################
> > +#
> > +# Marvell Armada SCP BL2 firmware images
> > +#
> > +################################################################################
> > +
> > +ARMADA_FIRMWARE_VERSION = $(call qstrip,$(BR2_TARGET_ARMADA_FIRMWARE_VERSION))
> 
> Having a configurable version is an exception of very few packages (linux, 
> uboot, ATF). Other packages should set to a static version string or a commit 
> id when there is no official version release.

Ok, will do.

> > +ARMADA_FIRMWARE_SITE = $(call github,MarvellEmbeddedProcessors,binaries-marvell,$(ARMADA_FIRMWARE_VERSION))
> > +ARMADA_FIRMWARE_LICENSE = Proprietary
> 
> These binaries come with no license, so you should also add 
> ARMADA_FIRMWARE_REDISTRIBUTE = NO.

Ok, will do.

Regards,
Sergey

[Buildroot] [PATCH/next 1/5] armada-firmware: new package

[Arnout Vandecappelle]

On 12-11-17 21:16, Sergey Matyukevich wrote:
> This package adds SCP BL2 firmware for Marvell Armada 7040 and 8040 SoCs.
> 
> Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
> ---
>  boot/Config.in                            |  1 +
>  boot/armada-firmware/Config.in            | 19 +++++++++++++++++++
>  boot/armada-firmware/armada-firmware.hash |  2 ++
>  boot/armada-firmware/armada-firmware.mk   | 18 ++++++++++++++++++
>  4 files changed, 40 insertions(+)
>  create mode 100644 boot/armada-firmware/Config.in
>  create mode 100644 boot/armada-firmware/armada-firmware.hash
>  create mode 100644 boot/armada-firmware/armada-firmware.mk
> 
> diff --git a/boot/Config.in b/boot/Config.in
> index 2f46c8546e..0ffbd7288b 100644
> --- a/boot/Config.in
> +++ b/boot/Config.in
> @@ -17,5 +17,6 @@ source "boot/ts4800-mbrboot/Config.in"
>  source "boot/uboot/Config.in"
>  source "boot/vexpress-firmware/Config.in"
>  source "boot/xloader/Config.in"
> +source "boot/armada-firmware/Config.in"

 Please keep things alphabetic. However, I don't think the boot loader menu is
appropriate. Yes, it's an image that is used by the bootloader, but really it is
a piece of firmware, not really related to booting the SoC.

>  
>  endmenu
> diff --git a/boot/armada-firmware/Config.in b/boot/armada-firmware/Config.in
> new file mode 100644
> index 0000000000..530b5622c8
> --- /dev/null
> +++ b/boot/armada-firmware/Config.in
> @@ -0,0 +1,19 @@
> +config BR2_TARGET_ARMADA_FIRMWARE
> +	bool "armada-firmware"
> +	depends on BR2_aarch64
> +	help
> +	  Marvell Armada SCP BL2 firmware images.

 Could you write a little more help text? Like, that it's the firmware for the
management coprocessor and that it is needed for power management. The first
paragraph of [1] can be a source of inspiration.

 We normally also want an upstream URL. [1] might be usable but I'm not sure.

> +
> +if BR2_TARGET_ARMADA_FIRMWARE
> +
> +config BR2_TARGET_ARMADA_FIRMWARE_IMAGE
> +	string "Armada SCP BL2 image name"
> +	help
> +	  Armada SCP BL2 firmware image name.
> +
> +config BR2_TARGET_ARMADA_FIRMWARE_VERSION
> +	string "Armada SCP BL2 image version"
> +	help
> +	  Armada SCP BL2 firmware image version.
> +
> +endif
> diff --git a/boot/armada-firmware/armada-firmware.hash b/boot/armada-firmware/armada-firmware.hash
> new file mode 100644
> index 0000000000..5eeca9d6ea
> --- /dev/null
> +++ b/boot/armada-firmware/armada-firmware.hash
> @@ -0,0 +1,2 @@
> +# Locally calculated
> +sha256 b310443c0d51d07b7c11597548685ae608b8478eee7095925427da6ab71e0168 armada-firmware-binaries-marvell-armada-17.10.tar.gz
> diff --git a/boot/armada-firmware/armada-firmware.mk b/boot/armada-firmware/armada-firmware.mk
> new file mode 100644
> index 0000000000..d75dc7cb6c
> --- /dev/null
> +++ b/boot/armada-firmware/armada-firmware.mk
> @@ -0,0 +1,18 @@
> +################################################################################
> +#
> +# Marvell Armada SCP BL2 firmware images
> +#
> +################################################################################
> +
> +ARMADA_FIRMWARE_VERSION = $(call qstrip,$(BR2_TARGET_ARMADA_FIRMWARE_VERSION))
> +ARMADA_FIRMWARE_SITE = $(call github,MarvellEmbeddedProcessors,binaries-marvell,$(ARMADA_FIRMWARE_VERSION))

 We try to keep the upstream name as the package name. Is there anything wrong
with binaries-marvell?

> +ARMADA_FIRMWARE_LICENSE = Proprietary
> +
> +ARMADA_FIRMWARE_INSTALL_IMAGES  = YES
> +
> +define ARMADA_FIRMWARE_INSTALL_IMAGES_CMDS
> +	$(INSTALL) -D -m 0644 $(@D)/mrvl_scp_bl2_7040.img $(BINARIES_DIR)/mrvl_scp_bl2_7040.img
> +	$(INSTALL) -D -m 0644 $(@D)/mrvl_scp_bl2_8040.img $(BINARIES_DIR)/mrvl_scp_bl2_8040.img

 I don't think the name is really relevant, is it? So maybe you could always
copy it to the same file in BINARIES_DIR so on the ATF side you don't need to
access variables of this package.

 Regards,
 Arnout

> +endef
> +
> +$(eval $(generic-package))
> 

[1]
http://wiki.macchiatobin.net/tiki-index.php?page=Enable+Power+Management+on+MACCHIATObin#Bootloader



-- 
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] [PATCH/next 1/5] armada-firmware: new package

[Sergey Matyukevich]

Hi Arnout,

Thanks for the review !

> > This package adds SCP BL2 firmware for Marvell Armada 7040 and 8040 SoCs.

...

> > diff --git a/boot/Config.in b/boot/Config.in
> > index 2f46c8546e..0ffbd7288b 100644
> > --- a/boot/Config.in
> > +++ b/boot/Config.in
> > @@ -17,5 +17,6 @@ source "boot/ts4800-mbrboot/Config.in"
> >  source "boot/uboot/Config.in"
> >  source "boot/vexpress-firmware/Config.in"
> >  source "boot/xloader/Config.in"
> > +source "boot/armada-firmware/Config.in"
> 
>  Please keep things alphabetic. However, I don't think the boot loader menu is
> appropriate. Yes, it's an image that is used by the bootloader, but really it is
> a piece of firmware, not really related to booting the SoC.

Will fix the order. However it looks like boot menu is the right place for this
package. This package is similar to versatile-firmware. It is SCP_BL2 image
which is used by ATF to boot SCP coprocessor. A bit more details are available
in ATF design document:
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/firmware-design.rst#scp-bl2-system-control-processor-firmware-image-load

> > diff --git a/boot/armada-firmware/Config.in b/boot/armada-firmware/Config.in
> > new file mode 100644
> > index 0000000000..530b5622c8
> > --- /dev/null
> > +++ b/boot/armada-firmware/Config.in
> > @@ -0,0 +1,19 @@
> > +config BR2_TARGET_ARMADA_FIRMWARE
> > +	bool "armada-firmware"
> > +	depends on BR2_aarch64
> > +	help
> > +	  Marvell Armada SCP BL2 firmware images.
> 
>  Could you write a little more help text? Like, that it's the firmware for the
> management coprocessor and that it is needed for power management. The first
> paragraph of [1] can be a source of inspiration.
> 
>  We normally also want an upstream URL. [1] might be usable but I'm not sure.

Sure, I will add more details about this package.

> > diff --git a/boot/armada-firmware/armada-firmware.mk b/boot/armada-firmware/armada-firmware.mk
> > new file mode 100644
> > index 0000000000..d75dc7cb6c
> > --- /dev/null
> > +++ b/boot/armada-firmware/armada-firmware.mk
> > @@ -0,0 +1,18 @@
> > +################################################################################
> > +#
> > +# Marvell Armada SCP BL2 firmware images
> > +#
> > +################################################################################
> > +
> > +ARMADA_FIRMWARE_VERSION = $(call qstrip,$(BR2_TARGET_ARMADA_FIRMWARE_VERSION))
> > +ARMADA_FIRMWARE_SITE = $(call github,MarvellEmbeddedProcessors,binaries-marvell,$(ARMADA_FIRMWARE_VERSION))
> 
>  We try to keep the upstream name as the package name. Is there anything wrong
> with binaries-marvell?

Ok, makes sense. Will do.

> > +ARMADA_FIRMWARE_LICENSE = Proprietary
> > +
> > +ARMADA_FIRMWARE_INSTALL_IMAGES  = YES
> > +
> > +define ARMADA_FIRMWARE_INSTALL_IMAGES_CMDS
> > +	$(INSTALL) -D -m 0644 $(@D)/mrvl_scp_bl2_7040.img $(BINARIES_DIR)/mrvl_scp_bl2_7040.img
> > +	$(INSTALL) -D -m 0644 $(@D)/mrvl_scp_bl2_8040.img $(BINARIES_DIR)/mrvl_scp_bl2_8040.img
> 
>  I don't think the name is really relevant, is it? So maybe you could always
> copy it to the same file in BINARIES_DIR so on the ATF side you don't need to
> access variables of this package.

This file depends on platform. Now we are adding MacchiatoBin, but another
interesting networking board called EspressoBin from the same vendor is on the
horizon. So it makes sense to keep things a little bit more flexible.

It looks like, together with review comments from Baruch, this brings us
to the following implementation:
- choice submenu for available platforms in armada-firmware config menu
  ..
  config BR2_TARGET_ARMADA_FIRMWARE_IMAGE
    string
    default "mrvl_scp_bl2_8040.img" if BR2_PACKAGE_ARMADA_8040
    default "mrvl_scp_bl2_7040.img" if BR2_PACKAGE_ARMADA_7040

- copy only selected BR2_TARGET_ARMADA_FIRMWARE_IMAGE to BINARIES_DIR

- use the same BR2_TARGET_ARMADA_FIRMWARE_FIRMWARE variable in ATF package
  to specify correct firmware

Regards,
Sergey

[Buildroot] [PATCH/next 1/5] armada-firmware: new package

[Arnout Vandecappelle]

On 15-11-17 22:15, Sergey Matyukevich wrote:
> Hi Arnout,
> 
> Thanks for the review !
> 
>>> This package adds SCP BL2 firmware for Marvell Armada 7040 and 8040 SoCs.
> 
> ...
> 
>>> diff --git a/boot/Config.in b/boot/Config.in
>>> index 2f46c8546e..0ffbd7288b 100644
>>> --- a/boot/Config.in
>>> +++ b/boot/Config.in
>>> @@ -17,5 +17,6 @@ source "boot/ts4800-mbrboot/Config.in"
>>>  source "boot/uboot/Config.in"
>>>  source "boot/vexpress-firmware/Config.in"
>>>  source "boot/xloader/Config.in"
>>> +source "boot/armada-firmware/Config.in"
>>
>>  Please keep things alphabetic. However, I don't think the boot loader menu is
>> appropriate. Yes, it's an image that is used by the bootloader, but really it is
>> a piece of firmware, not really related to booting the SoC.
> 
> Will fix the order. However it looks like boot menu is the right place for this
> package. This package is similar to versatile-firmware. It is SCP_BL2 image
> which is used by ATF to boot SCP coprocessor. A bit more details are available
> in ATF design document:
> https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/firmware-design.rst#scp-bl2-system-control-processor-firmware-image-load

 As I understand it, it should also be possible to load the SCP firmware after
boot. Maybe not on all platforms. But even if it weren't I wouldn't consider it
a bootloader. And the same goes for vexpress-firmware by the way.

 That said, it's not such a big deal for me.

[snip]
>>> +define ARMADA_FIRMWARE_INSTALL_IMAGES_CMDS
>>> +	$(INSTALL) -D -m 0644 $(@D)/mrvl_scp_bl2_7040.img $(BINARIES_DIR)/mrvl_scp_bl2_7040.img
>>> +	$(INSTALL) -D -m 0644 $(@D)/mrvl_scp_bl2_8040.img $(BINARIES_DIR)/mrvl_scp_bl2_8040.img
>>
>>  I don't think the name is really relevant, is it? So maybe you could always
>> copy it to the same file in BINARIES_DIR so on the ATF side you don't need to
>> access variables of this package.
> 
> This file depends on platform. Now we are adding MacchiatoBin, but another
> interesting networking board called EspressoBin from the same vendor is on the
> horizon. So it makes sense to keep things a little bit more flexible.
> 
> It looks like, together with review comments from Baruch, this brings us
> to the following implementation:
> - choice submenu for available platforms in armada-firmware config menu
>   ..
>   config BR2_TARGET_ARMADA_FIRMWARE_IMAGE
>     string
>     default "mrvl_scp_bl2_8040.img" if BR2_PACKAGE_ARMADA_8040
>     default "mrvl_scp_bl2_7040.img" if BR2_PACKAGE_ARMADA_7040
> 
> - copy only selected BR2_TARGET_ARMADA_FIRMWARE_IMAGE to BINARIES_DIR
> 
> - use the same BR2_TARGET_ARMADA_FIRMWARE_FIRMWARE variable in ATF package
>   to specify correct firmware

 My point was: you can copy the image to $(BINARIES_DIR)/scp-fw.bin, then in the
ATF package you don't need to specify the firmware name but just always use
scp-fw.bin. A further step would be to introduce an arm-scp-firmware (or
atf-scp-firmware) virtual package (implemented by vexpress-firmware and
armada-firmware). That way no change is needed in ATF to add an additional
firmware package, and it's possible to add new firmware in BR2_EXTERNAL.

 Regards,
 Arnout

-- 
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] [PATCH/next 2/5] armada-ddr: new package

[Sergey Matyukevich]

This package adds Marvell Armada SoC DDR training algorithms.
This code is not built separately, it is needed as dependency
to build ATF firmware for Marvell Armada SoCs.

Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
---
 boot/Config.in                  |  1 +
 boot/armada-ddr/Config.in       | 16 ++++++++++++++++
 boot/armada-ddr/armada-ddr.hash |  2 ++
 boot/armada-ddr/armada-ddr.mk   | 20 ++++++++++++++++++++
 4 files changed, 39 insertions(+)
 create mode 100644 boot/armada-ddr/Config.in
 create mode 100644 boot/armada-ddr/armada-ddr.hash
 create mode 100644 boot/armada-ddr/armada-ddr.mk

diff --git a/boot/Config.in b/boot/Config.in
index 0ffbd7288b..1363181fc5 100644
--- a/boot/Config.in
+++ b/boot/Config.in
@@ -18,5 +18,6 @@ source "boot/uboot/Config.in"
 source "boot/vexpress-firmware/Config.in"
 source "boot/xloader/Config.in"
 source "boot/armada-firmware/Config.in"
+source "boot/armada-ddr/Config.in"
 
 endmenu
diff --git a/boot/armada-ddr/Config.in b/boot/armada-ddr/Config.in
new file mode 100644
index 0000000000..23b71b8345
--- /dev/null
+++ b/boot/armada-ddr/Config.in
@@ -0,0 +1,16 @@
+config BR2_TARGET_ARMADA_DDR
+	bool "armada-ddr"
+	depends on BR2_aarch64
+	help
+	  Marvell keeps algorithms for DDR training in a separate repository.
+	  This code is not built separately, it is needed as dependency
+	  to build ATF firmware for Marvell Armada 7040 and 8040 SoCs.
+
+if BR2_TARGET_ARMADA_DDR
+
+config BR2_TARGET_ARMADA_DDR_VERSION
+	string "Armada DDR training code version"
+	help
+	  Marvell Armada DDR training code version
+
+endif
diff --git a/boot/armada-ddr/armada-ddr.hash b/boot/armada-ddr/armada-ddr.hash
new file mode 100644
index 0000000000..2dc36e0975
--- /dev/null
+++ b/boot/armada-ddr/armada-ddr.hash
@@ -0,0 +1,2 @@
+# Locally calculated
+sha256 5f6f2b8c0742eb8b4ff716dc6715d20507c6ceadd5576aa446e407a428861de9 armada-ddr-mv_ddr-armada-17.10.tar.gz
diff --git a/boot/armada-ddr/armada-ddr.mk b/boot/armada-ddr/armada-ddr.mk
new file mode 100644
index 0000000000..5f76bfd7ed
--- /dev/null
+++ b/boot/armada-ddr/armada-ddr.mk
@@ -0,0 +1,20 @@
+################################################################################
+#
+# Marvell Armada DDR training code
+#
+################################################################################
+
+ARMADA_DDR_VERSION = $(call qstrip,$(BR2_TARGET_ARMADA_DDR_VERSION))
+ARMADA_DDR_SITE = $(call github,MarvellEmbeddedProcessors,mv-ddr-marvell,$(ARMADA_DDR_VERSION))
+ARMADA_DDR_LICENSE = Proprietary
+
+ARMADA_DDR_INSTALL_IMAGES  = YES
+
+define ARMADA_DDR_INSTALL_IMAGES_CMDS
+	$(INSTALL) -m 0755 -d $(DL_DIR)/mv-ddr-marvell
+	$(call suitable-extractor,$(notdir $(ARMADA_DDR_SOURCE))) \
+		$(DL_DIR)/$(notdir $(ARMADA_DDR_SOURCE)) | \
+		$(TAR) --strip-components=1 -C $(DL_DIR)/mv-ddr-marvell $(TAR_OPTIONS) -
+endef
+
+$(eval $(generic-package))
-- 
2.11.0

[Buildroot] [PATCH/next 2/5] armada-ddr: new package

[Baruch Siach]

Hi Sergey,

On Sun, Nov 12, 2017 at 11:16:43PM +0300, Sergey Matyukevich wrote:
> This package adds Marvell Armada SoC DDR training algorithms.
> This code is not built separately, it is needed as dependency
> to build ATF firmware for Marvell Armada SoCs.
> 
> Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
> ---
>  boot/Config.in                  |  1 +
>  boot/armada-ddr/Config.in       | 16 ++++++++++++++++
>  boot/armada-ddr/armada-ddr.hash |  2 ++
>  boot/armada-ddr/armada-ddr.mk   | 20 ++++++++++++++++++++
>  4 files changed, 39 insertions(+)
>  create mode 100644 boot/armada-ddr/Config.in
>  create mode 100644 boot/armada-ddr/armada-ddr.hash
>  create mode 100644 boot/armada-ddr/armada-ddr.mk
> 
> diff --git a/boot/Config.in b/boot/Config.in
> index 0ffbd7288b..1363181fc5 100644
> --- a/boot/Config.in
> +++ b/boot/Config.in
> @@ -18,5 +18,6 @@ source "boot/uboot/Config.in"
>  source "boot/vexpress-firmware/Config.in"
>  source "boot/xloader/Config.in"
>  source "boot/armada-firmware/Config.in"
> +source "boot/armada-ddr/Config.in"
>  
>  endmenu
> diff --git a/boot/armada-ddr/Config.in b/boot/armada-ddr/Config.in
> new file mode 100644
> index 0000000000..23b71b8345
> --- /dev/null
> +++ b/boot/armada-ddr/Config.in
> @@ -0,0 +1,16 @@
> +config BR2_TARGET_ARMADA_DDR
> +	bool "armada-ddr"
> +	depends on BR2_aarch64
> +	help
> +	  Marvell keeps algorithms for DDR training in a separate repository.
> +	  This code is not built separately, it is needed as dependency
> +	  to build ATF firmware for Marvell Armada 7040 and 8040 SoCs.
> +
> +if BR2_TARGET_ARMADA_DDR
> +
> +config BR2_TARGET_ARMADA_DDR_VERSION
> +	string "Armada DDR training code version"
> +	help
> +	  Marvell Armada DDR training code version
> +
> +endif
> diff --git a/boot/armada-ddr/armada-ddr.hash b/boot/armada-ddr/armada-ddr.hash
> new file mode 100644
> index 0000000000..2dc36e0975
> --- /dev/null
> +++ b/boot/armada-ddr/armada-ddr.hash
> @@ -0,0 +1,2 @@
> +# Locally calculated
> +sha256 5f6f2b8c0742eb8b4ff716dc6715d20507c6ceadd5576aa446e407a428861de9 armada-ddr-mv_ddr-armada-17.10.tar.gz
> diff --git a/boot/armada-ddr/armada-ddr.mk b/boot/armada-ddr/armada-ddr.mk
> new file mode 100644
> index 0000000000..5f76bfd7ed
> --- /dev/null
> +++ b/boot/armada-ddr/armada-ddr.mk
> @@ -0,0 +1,20 @@
> +################################################################################
> +#
> +# Marvell Armada DDR training code
> +#
> +################################################################################
> +
> +ARMADA_DDR_VERSION = $(call qstrip,$(BR2_TARGET_ARMADA_DDR_VERSION))

Here again, should be a static commit id.

> +ARMADA_DDR_SITE = $(call github,MarvellEmbeddedProcessors,mv-ddr-marvell,$(ARMADA_DDR_VERSION))
> +ARMADA_DDR_LICENSE = Proprietary

The few files I looked into each have a few optional license headings, 
including a Commercial License, GPL-2.0+, GPL with exception, and BSD.

> +
> +ARMADA_DDR_INSTALL_IMAGES  = YES
> +
> +define ARMADA_DDR_INSTALL_IMAGES_CMDS
> +	$(INSTALL) -m 0755 -d $(DL_DIR)/mv-ddr-marvell
> +	$(call suitable-extractor,$(notdir $(ARMADA_DDR_SOURCE))) \
> +		$(DL_DIR)/$(notdir $(ARMADA_DDR_SOURCE)) | \
> +		$(TAR) --strip-components=1 -C $(DL_DIR)/mv-ddr-marvell $(TAR_OPTIONS) -
> +endef

Can't you use $(BUILD_DIR)/... for ATF, where mv-ddr-marvell source are 
extracted anyway?

> +
> +$(eval $(generic-package))

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] [PATCH/next 2/5] armada-ddr: new package

[Sergey Matyukevich]

> > +################################################################################
> > +#
> > +# Marvell Armada DDR training code
> > +#
> > +################################################################################
> > +
> > +ARMADA_DDR_VERSION = $(call qstrip,$(BR2_TARGET_ARMADA_DDR_VERSION))
> 
> Here again, should be a static commit id.
> 
> > +ARMADA_DDR_SITE = $(call github,MarvellEmbeddedProcessors,mv-ddr-marvell,$(ARMADA_DDR_VERSION))
> > +ARMADA_DDR_LICENSE = Proprietary
> 
> The few files I looked into each have a few optional license headings, 
> including a Commercial License, GPL-2.0+, GPL with exception, and BSD.
> 
> > +
> > +ARMADA_DDR_INSTALL_IMAGES  = YES
> > +
> > +define ARMADA_DDR_INSTALL_IMAGES_CMDS
> > +	$(INSTALL) -m 0755 -d $(DL_DIR)/mv-ddr-marvell
> > +	$(call suitable-extractor,$(notdir $(ARMADA_DDR_SOURCE))) \
> > +		$(DL_DIR)/$(notdir $(ARMADA_DDR_SOURCE)) | \
> > +		$(TAR) --strip-components=1 -C $(DL_DIR)/mv-ddr-marvell $(TAR_OPTIONS) -
> > +endef
> 
> Can't you use $(BUILD_DIR)/... for ATF, where mv-ddr-marvell source are 
> extracted anyway?

All noted and will be implemented in v2.

Thanks again for your thorough review !

Regards,
Sergey

[Buildroot] [PATCH/next 3/5] atf: add support for Marvell Armada SoCs

[Sergey Matyukevich]

Add support for Marvell Armada SoCs to arm-trusted-firmware package.

Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
---
 boot/arm-trusted-firmware/arm-trusted-firmware.mk | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/boot/arm-trusted-firmware/arm-trusted-firmware.mk b/boot/arm-trusted-firmware/arm-trusted-firmware.mk
index 7b1cc6ebb6..d6bde29894 100644
--- a/boot/arm-trusted-firmware/arm-trusted-firmware.mk
+++ b/boot/arm-trusted-firmware/arm-trusted-firmware.mk
@@ -39,6 +39,19 @@ ARM_TRUSTED_FIRMWARE_MAKE_OPTS += SCP_BL2=$(BINARIES_DIR)/scp-fw.bin
 ARM_TRUSTED_FIRMWARE_DEPENDENCIES += vexpress-firmware
 endif
 
+ifeq ($(BR2_TARGET_ARMADA_FIRMWARE),y)
+ARMADA_FIRMWARE_IMAGE = $(call qstrip,$(BR2_TARGET_ARMADA_FIRMWARE_IMAGE))
+ARM_TRUSTED_FIRMWARE_MAKE_OPTS += \
+	SCP_BL2=$(BINARIES_DIR)/$(ARMADA_FIRMWARE_IMAGE)
+ARM_TRUSTED_FIRMWARE_DEPENDENCIES += armada-firmware
+endif
+
+ifeq ($(BR2_TARGET_ARMADA_DDR),y)
+ARM_TRUSTED_FIRMWARE_MAKE_OPTS += \
+	MV_DDR_PATH=$(DL_DIR)/mv-ddr-marvell
+ARM_TRUSTED_FIRMWARE_DEPENDENCIES += armada-ddr
+endif
+
 define ARM_TRUSTED_FIRMWARE_BUILD_CMDS
 	$(TARGET_CONFIGURE_OPTS) \
 		$(MAKE) -C $(@D) $(ARM_TRUSTED_FIRMWARE_MAKE_OPTS) \
-- 
2.11.0

[Buildroot] [PATCH/next 3/5] atf: add support for Marvell Armada SoCs

[Baruch Siach]

Hi Sergey,

On Sun, Nov 12, 2017 at 11:16:44PM +0300, Sergey Matyukevich wrote:
> Add support for Marvell Armada SoCs to arm-trusted-firmware package.
> 
> Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
> ---
>  boot/arm-trusted-firmware/arm-trusted-firmware.mk | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/boot/arm-trusted-firmware/arm-trusted-firmware.mk b/boot/arm-trusted-firmware/arm-trusted-firmware.mk
> index 7b1cc6ebb6..d6bde29894 100644
> --- a/boot/arm-trusted-firmware/arm-trusted-firmware.mk
> +++ b/boot/arm-trusted-firmware/arm-trusted-firmware.mk
> @@ -39,6 +39,19 @@ ARM_TRUSTED_FIRMWARE_MAKE_OPTS += SCP_BL2=$(BINARIES_DIR)/scp-fw.bin
>  ARM_TRUSTED_FIRMWARE_DEPENDENCIES += vexpress-firmware
>  endif
>  
> +ifeq ($(BR2_TARGET_ARMADA_FIRMWARE),y)
> +ARMADA_FIRMWARE_IMAGE = $(call qstrip,$(BR2_TARGET_ARMADA_FIRMWARE_IMAGE))
> +ARM_TRUSTED_FIRMWARE_MAKE_OPTS += \
> +	SCP_BL2=$(BINARIES_DIR)/$(ARMADA_FIRMWARE_IMAGE)
> +ARM_TRUSTED_FIRMWARE_DEPENDENCIES += armada-firmware
> +endif
> +
> +ifeq ($(BR2_TARGET_ARMADA_DDR),y)
> +ARM_TRUSTED_FIRMWARE_MAKE_OPTS += \
> +	MV_DDR_PATH=$(DL_DIR)/mv-ddr-marvell
> +ARM_TRUSTED_FIRMWARE_DEPENDENCIES += armada-ddr
> +endif

These are not really optional dependencies of ATF in general. It's only the 
Marvell specific ATF version that needs them, and they are not optional.

I don't have any better suggestion at the moment.

baruch

> +
>  define ARM_TRUSTED_FIRMWARE_BUILD_CMDS
>  	$(TARGET_CONFIGURE_OPTS) \
>  		$(MAKE) -C $(@D) $(ARM_TRUSTED_FIRMWARE_MAKE_OPTS) \

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] [PATCH/next 3/5] atf: add support for Marvell Armada SoCs

[Sergey Matyukevich]

> > Add support for Marvell Armada SoCs to arm-trusted-firmware package.
> > 
> > Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
> > ---
> >  boot/arm-trusted-firmware/arm-trusted-firmware.mk | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/boot/arm-trusted-firmware/arm-trusted-firmware.mk b/boot/arm-trusted-firmware/arm-trusted-firmware.mk
> > index 7b1cc6ebb6..d6bde29894 100644
> > --- a/boot/arm-trusted-firmware/arm-trusted-firmware.mk
> > +++ b/boot/arm-trusted-firmware/arm-trusted-firmware.mk
> > @@ -39,6 +39,19 @@ ARM_TRUSTED_FIRMWARE_MAKE_OPTS += SCP_BL2=$(BINARIES_DIR)/scp-fw.bin
> >  ARM_TRUSTED_FIRMWARE_DEPENDENCIES += vexpress-firmware
> >  endif
> >  
> > +ifeq ($(BR2_TARGET_ARMADA_FIRMWARE),y)
> > +ARMADA_FIRMWARE_IMAGE = $(call qstrip,$(BR2_TARGET_ARMADA_FIRMWARE_IMAGE))
> > +ARM_TRUSTED_FIRMWARE_MAKE_OPTS += \
> > +	SCP_BL2=$(BINARIES_DIR)/$(ARMADA_FIRMWARE_IMAGE)
> > +ARM_TRUSTED_FIRMWARE_DEPENDENCIES += armada-firmware
> > +endif
> > +
> > +ifeq ($(BR2_TARGET_ARMADA_DDR),y)
> > +ARM_TRUSTED_FIRMWARE_MAKE_OPTS += \
> > +	MV_DDR_PATH=$(DL_DIR)/mv-ddr-marvell
> > +ARM_TRUSTED_FIRMWARE_DEPENDENCIES += armada-ddr
> > +endif
> 
> These are not really optional dependencies of ATF in general. It's only the 
> Marvell specific ATF version that needs them, and they are not optional.
> 
> I don't have any better suggestion at the moment.

Neither do I. Another obvious option is to create a separate ATF package
for Marvell. But it doesn't look like a good idea. I opted the same
approach as for Versatile firmware, at least for the time being.

Regards,
Sergey

[Buildroot] [PATCH/next 4/5] solidrun/macchiatobin: add new board

[Sergey Matyukevich]

Add MacchiatoBin board by SolidRun. This board is based on Marvell
Armada 8040 SoC. Board support package includes the following
two options: mainline and vendor BSPs.

Mainline BSP:
- Marvell ATF v1.3-armada-17.10 and its dependencies
- mainline U-Boot v2017.09
- mainline Linux kernel v4.13.11

Marvell BSP with more hardware support enabled:
- Marvell ATF v1.3-armada-17.10 and its dependencies
- vendor U-Boot based on v2017.03
- Marvell Linux kernel based v4.4.52

More details about this board are available on wiki:
- http://wiki.macchiatobin.net

Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
---
 board/solidrun/macchiatobin/genimage.cfg         | 16 ++++++
 board/solidrun/macchiatobin/readme.txt           | 70 ++++++++++++++++++++++++
 configs/solidrun_macchiatobin_mainline_defconfig | 46 ++++++++++++++++
 configs/solidrun_macchiatobin_marvell_defconfig  | 48 ++++++++++++++++
 4 files changed, 180 insertions(+)
 create mode 100644 board/solidrun/macchiatobin/genimage.cfg
 create mode 100644 board/solidrun/macchiatobin/readme.txt
 create mode 100644 configs/solidrun_macchiatobin_mainline_defconfig
 create mode 100644 configs/solidrun_macchiatobin_marvell_defconfig

diff --git a/board/solidrun/macchiatobin/genimage.cfg b/board/solidrun/macchiatobin/genimage.cfg
new file mode 100644
index 0000000000..fdcda368a2
--- /dev/null
+++ b/board/solidrun/macchiatobin/genimage.cfg
@@ -0,0 +1,16 @@
+image sdcard.img {
+	hdimage {
+	}
+
+	partition uboot {
+		in-partition-table = "no"
+		image = "flash-image.bin"
+		offset = 0x200000
+	}
+
+	partition rootfs {
+		partition-type = 0x83
+		offset = 0x2200000
+		image = "rootfs.ext4"
+	}
+}
diff --git a/board/solidrun/macchiatobin/readme.txt b/board/solidrun/macchiatobin/readme.txt
new file mode 100644
index 0000000000..7bab5aca3c
--- /dev/null
+++ b/board/solidrun/macchiatobin/readme.txt
@@ -0,0 +1,70 @@
+Intro
+=====
+
+This default configuration will allow you to start experimenting with the
+buildroot environment for the MacchiatoBin board based on Marvell Armada
+8040 SoC. Documentation for the board hardware and software
+is available on wiki: http://wiki.macchiatobin.net
+
+This default configuration will bring-up the board and allow
+access through the serial console.
+
+How to build
+============
+
+There are two build options. The first option is mainline BSP:
+ - Linux v4.13.11
+ - U-Boot v2017.09
+
+The second option is vendor BSP which enables more hardware.
+Marvell BSP is based on the following Linux and U-Boot versions:
+ - Linux v4.4.52
+ - U-Boot v2017.03
+Sources are available on Marvell GitHub page:
+   https://github.com/MarvellEmbeddedProcessors
+
+To use mainline BSP run the following commands:
+    $ make solidrun_macchiatobin_mainline_defconfig
+    $ make
+
+To use vendor BSP run the following commands:
+    $ make solidrun_macchiatobin_marvell_defconfig
+    $ make
+
+Note: you will need access to the internet to download
+all the required sources.
+
+How to write the SD card
+========================
+
+Once the build process is finished you will have an image
+called "sdcard.img" in the output/images/ directory.
+
+Copy the bootable "sdcard.img" onto an SD card with "dd":
+
+  $ sudo dd if=output/images/sdcard.img of=/dev/sdX
+  $ sudo sync
+
+Insert the micro SDcard in MacchiatoBin board and power it up.
+The console is on the serial line, 115200 8N1.
+
+Note that MacchiatoBin board can be setup to load bootloader
+from different sources including eMMC, SPI flash, and SD card.
+Make sure to properly configure DIP switches SW1 and SW2
+according to information available on wiki.
+
+By default U-Boot will use environment from SPI flash. If SPI flash
+is empty or it keeps legacy environment which is incompatible with
+up-to-date mainline U-Boot and kernel, then the following
+commands can be used to boot the board:
+
+=> env default -f -a
+=> setenv bootargs console=ttyS0,115200 root=/dev/mmcblk1p1 rw rootwait
+=> setenv bootdelay 2
+=> setenv fdt_addr 0x1000000
+=> setenv fdt_high 0xffffffffffffffff
+=> setenv fdt_name boot/armada-8040-mcbin.dtb
+=> setenv kernel_addr 0x2000000
+=> setenv image_name boot/Image
+=> setenv bootcmd 'mmc dev 1; ext4load mmc 1:1 $kernel_addr $image_name; ext4load mmc 1:1 $fdt_addr $fdt_name; booti $kernel_addr - $fdt_addr'
+=> boot
diff --git a/configs/solidrun_macchiatobin_mainline_defconfig b/configs/solidrun_macchiatobin_mainline_defconfig
new file mode 100644
index 0000000000..ab82865a0d
--- /dev/null
+++ b/configs/solidrun_macchiatobin_mainline_defconfig
@@ -0,0 +1,46 @@
+BR2_aarch64=y
+
+#
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_13=y
+BR2_TARGET_GENERIC_HOSTNAME="mcbin"
+BR2_TARGET_GENERIC_ISSUE="Welcome to Buildroot for Marvell MacchiatoBin"
+
+# Firmware
+BR2_TARGET_ARM_TRUSTED_FIRMWARE=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_GIT=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_REPO_URL="https://github.com/MarvellEmbeddedProcessors/atf-marvell.git"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_REPO_VERSION="atf-v1.3-armada-17.10"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_PLATFORM="a80x0_mcbin"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_ADDITIONAL_VARIABLES="USE_COHERENT_MEM=0"
+
+BR2_TARGET_ARMADA_FIRMWARE=y
+BR2_TARGET_ARMADA_FIRMWARE_IMAGE="mrvl_scp_bl2_8040.img"
+BR2_TARGET_ARMADA_FIRMWARE_VERSION="binaries-marvell-armada-17.10"
+
+BR2_TARGET_ARMADA_DDR=y
+BR2_TARGET_ARMADA_DDR_VERSION="mv_ddr-armada-17.10"
+
+# U-Boot
+BR2_TARGET_UBOOT=y
+BR2_TARGET_UBOOT_BOARDNAME="mvebu_mcbin-88f8040"
+BR2_TARGET_UBOOT_CUSTOM_VERSION=y
+BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2017.09"
+
+# Kernel
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.13.11"
+BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
+BR2_LINUX_KERNEL_DTS_SUPPORT=y
+BR2_LINUX_KERNEL_INTREE_DTS_NAME="marvell/armada-8040-mcbin"
+BR2_LINUX_KERNEL_INSTALL_TARGET=y
+
+# rootfs
+BR2_TARGET_ROOTFS_TAR=y
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_ROOTFS_EXT2_4=y
+BR2_PACKAGE_HOST_DOSFSTOOLS=y
+BR2_PACKAGE_HOST_GENIMAGE=y
+BR2_PACKAGE_HOST_MTOOLS=y
+BR2_ROOTFS_POST_IMAGE_SCRIPT="support/scripts/genimage.sh"
+BR2_ROOTFS_POST_SCRIPT_ARGS="-c board/solidrun/macchiatobin/genimage.cfg"
diff --git a/configs/solidrun_macchiatobin_marvell_defconfig b/configs/solidrun_macchiatobin_marvell_defconfig
new file mode 100644
index 0000000000..f47df89fb3
--- /dev/null
+++ b/configs/solidrun_macchiatobin_marvell_defconfig
@@ -0,0 +1,48 @@
+BR2_aarch64=y
+
+#
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_4=y
+BR2_TARGET_GENERIC_HOSTNAME="mcbin"
+BR2_TARGET_GENERIC_ISSUE="Welcome to Buildroot for Marvell MacchiatoBin"
+
+# Firmware
+BR2_TARGET_ARM_TRUSTED_FIRMWARE=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_GIT=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_REPO_URL="https://github.com/MarvellEmbeddedProcessors/atf-marvell.git"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_REPO_VERSION="atf-v1.3-armada-17.10"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_PLATFORM="a80x0_mcbin"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_ADDITIONAL_VARIABLES="USE_COHERENT_MEM=0"
+
+BR2_TARGET_ARMADA_FIRMWARE=y
+BR2_TARGET_ARMADA_FIRMWARE_IMAGE="mrvl_scp_bl2_8040.img"
+BR2_TARGET_ARMADA_FIRMWARE_VERSION="binaries-marvell-armada-17.10"
+
+BR2_TARGET_ARMADA_DDR=y
+BR2_TARGET_ARMADA_DDR_VERSION="mv_ddr-armada-17.10"
+
+# U-Boot
+BR2_TARGET_UBOOT=y
+BR2_TARGET_UBOOT_CUSTOM_GIT=y
+BR2_TARGET_UBOOT_CUSTOM_REPO_URL="https://github.com/MarvellEmbeddedProcessors/u-boot-marvell"
+BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="u-boot-2017.03-armada-17.10"
+BR2_TARGET_UBOOT_BOARDNAME="mvebu_mcbin-88f8040"
+
+# Kernel
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_GIT=y
+BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/MarvellEmbeddedProcessors/linux-marvell"
+BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="linux-4.4.52-armada-17.10"
+BR2_LINUX_KERNEL_DEFCONFIG="mvebu_v8_lsp"
+BR2_LINUX_KERNEL_DTS_SUPPORT=y
+BR2_LINUX_KERNEL_INTREE_DTS_NAME="marvell/armada-8040-mcbin"
+BR2_LINUX_KERNEL_INSTALL_TARGET=y
+
+# rootfs
+BR2_TARGET_ROOTFS_TAR=y
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_ROOTFS_EXT2_4=y
+BR2_PACKAGE_HOST_DOSFSTOOLS=y
+BR2_PACKAGE_HOST_GENIMAGE=y
+BR2_PACKAGE_HOST_MTOOLS=y
+BR2_ROOTFS_POST_IMAGE_SCRIPT="support/scripts/genimage.sh"
+BR2_ROOTFS_POST_SCRIPT_ARGS="-c board/solidrun/macchiatobin/genimage.cfg"
-- 
2.11.0

[Buildroot] [PATCH/next 4/5] solidrun/macchiatobin: add new board

[Baruch Siach]

Hi Sergey,

On Sun, Nov 12, 2017 at 11:16:45PM +0300, Sergey Matyukevich wrote:
> Add MacchiatoBin board by SolidRun. This board is based on Marvell
> Armada 8040 SoC. Board support package includes the following
> two options: mainline and vendor BSPs.
> 
> Mainline BSP:
> - Marvell ATF v1.3-armada-17.10 and its dependencies
> - mainline U-Boot v2017.09
> - mainline Linux kernel v4.13.11

Thanks. For the mainline kernel BSP:

Tested-by: Baruch Siach <baruch@tkos.co.il>

I'll note though that 'df' crashes here consistently:

[  962.179129] df[1346]: unhandled level 2 translation fault (11) at 0x00000a74, esr 0x92000046, in busybox[400000+a4000]
[  962.190801] CPU: 0 PID: 1346 Comm: df Not tainted 4.13.11 #1
[  962.197869] Hardware name: Marvell 8040 MACHIATOBin (DT)
...

I have not investigated it any further.

A few more comments below.

> Marvell BSP with more hardware support enabled:
> - Marvell ATF v1.3-armada-17.10 and its dependencies
> - vendor U-Boot based on v2017.03
> - Marvell Linux kernel based v4.4.52
> 
> More details about this board are available on wiki:
> - http://wiki.macchiatobin.net
> 
> Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
> ---
>  board/solidrun/macchiatobin/genimage.cfg         | 16 ++++++
>  board/solidrun/macchiatobin/readme.txt           | 70 ++++++++++++++++++++++++
>  configs/solidrun_macchiatobin_mainline_defconfig | 46 ++++++++++++++++
>  configs/solidrun_macchiatobin_marvell_defconfig  | 48 ++++++++++++++++
>  4 files changed, 180 insertions(+)
>  create mode 100644 board/solidrun/macchiatobin/genimage.cfg
>  create mode 100644 board/solidrun/macchiatobin/readme.txt
>  create mode 100644 configs/solidrun_macchiatobin_mainline_defconfig
>  create mode 100644 configs/solidrun_macchiatobin_marvell_defconfig
> 
> diff --git a/board/solidrun/macchiatobin/genimage.cfg b/board/solidrun/macchiatobin/genimage.cfg
> new file mode 100644
> index 0000000000..fdcda368a2
> --- /dev/null
> +++ b/board/solidrun/macchiatobin/genimage.cfg
> @@ -0,0 +1,16 @@
> +image sdcard.img {
> +	hdimage {
> +	}
> +
> +	partition uboot {
> +		in-partition-table = "no"
> +		image = "flash-image.bin"
> +		offset = 0x200000
> +	}
> +
> +	partition rootfs {
> +		partition-type = 0x83
> +		offset = 0x2200000
> +		image = "rootfs.ext4"
> +	}
> +}
> diff --git a/board/solidrun/macchiatobin/readme.txt b/board/solidrun/macchiatobin/readme.txt
> new file mode 100644
> index 0000000000..7bab5aca3c
> --- /dev/null
> +++ b/board/solidrun/macchiatobin/readme.txt
> @@ -0,0 +1,70 @@
> +Intro
> +=====
> +
> +This default configuration will allow you to start experimenting with the
> +buildroot environment for the MacchiatoBin board based on Marvell Armada
> +8040 SoC. Documentation for the board hardware and software
> +is available on wiki: http://wiki.macchiatobin.net
> +
> +This default configuration will bring-up the board and allow
> +access through the serial console.

Would be nice to note that the serial console is accessible at the micro-USB 
connector marked CON9.

> +
> +How to build
> +============
> +
> +There are two build options. The first option is mainline BSP:
> + - Linux v4.13.11
> + - U-Boot v2017.09
> +
> +The second option is vendor BSP which enables more hardware.
> +Marvell BSP is based on the following Linux and U-Boot versions:
> + - Linux v4.4.52
> + - U-Boot v2017.03
> +Sources are available on Marvell GitHub page:
> +   https://github.com/MarvellEmbeddedProcessors
> +
> +To use mainline BSP run the following commands:
> +    $ make solidrun_macchiatobin_mainline_defconfig
> +    $ make
> +
> +To use vendor BSP run the following commands:
> +    $ make solidrun_macchiatobin_marvell_defconfig
> +    $ make
> +
> +Note: you will need access to the internet to download
> +all the required sources.
> +
> +How to write the SD card
> +========================
> +
> +Once the build process is finished you will have an image
> +called "sdcard.img" in the output/images/ directory.
> +
> +Copy the bootable "sdcard.img" onto an SD card with "dd":
> +
> +  $ sudo dd if=output/images/sdcard.img of=/dev/sdX
> +  $ sudo sync

A somewhat faster one liner:

  sudo dd if=output/images/sdcard.img of=/dev/sdX bs=1M conv=fsync

> +Insert the micro SDcard in MacchiatoBin board and power it up.
> +The console is on the serial line, 115200 8N1.
> +
> +Note that MacchiatoBin board can be setup to load bootloader
> +from different sources including eMMC, SPI flash, and SD card.
> +Make sure to properly configure DIP switches SW1 and SW2
> +according to information available on wiki.

Would be nice to write here the DIP switches configuration for SD card boot:

SW2: 01110
SW1: 1xxxx

> +By default U-Boot will use environment from SPI flash. If SPI flash
> +is empty or it keeps legacy environment which is incompatible with
> +up-to-date mainline U-Boot and kernel, then the following
> +commands can be used to boot the board:
> +
> +=> env default -f -a
> +=> setenv bootargs console=ttyS0,115200 root=/dev/mmcblk1p1 rw rootwait
> +=> setenv bootdelay 2

This doesn't make much sense, since the user is now at the serial console 
already.

> +=> setenv fdt_addr 0x1000000
> +=> setenv fdt_high 0xffffffffffffffff
> +=> setenv fdt_name boot/armada-8040-mcbin.dtb
> +=> setenv kernel_addr 0x2000000
> +=> setenv image_name boot/Image
> +=> setenv bootcmd 'mmc dev 1; ext4load mmc 1:1 $kernel_addr $image_name; ext4load mmc 1:1 $fdt_addr $fdt_name; booti $kernel_addr - $fdt_addr'
> +=> boot

Having to type all that on the console is not nice. Unfortunately, current 
mainline U-Boot does not make it easy to override the SPI flash stored 
environment. But we can ease the pain somewhat. Create a uEnv.txt file, and 
store it in /boot. The sequence above can now be shortened to:

=> ext4load mmc 1:1 0x01700000 /boot/uEnv.txt
=> env import -t 0x01700000 $filesize
=> boot

The uEnv.txt file that I tested is attached.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
-------------- next part --------------
bootargs=console=ttyS0,115200 root=/dev/mmcblk1p1 rw rootwait
fdt_addr=0x1000000
fdt_high=0xffffffffffffffff
fdt_name=boot/armada-8040-mcbin.dtb
kernel_addr=0x2000000
image_name=boot/Image
bootcmd=mmc dev 1; ext4load mmc 1:1 $kernel_addr $image_name; ext4load mmc 1:1 $fdt_addr $fdt_name; booti $kernel_addr - $fdt_addr

[Buildroot] [PATCH/next 4/5] solidrun/macchiatobin: add new board

[Jan Kundrát]

On pond?l? 13. listopadu 2017 13:27:02 CET, Baruch Siach wrote:
> Create a uEnv.txt file, and store it in /boot.

Hi Baruch, does U-Boot auto-load this file on each and every boot? If not, 
than I suggest to name it differently -- perhaps uEnv-recovery.txt. I would 
expect that any change in a /boot/uEnv.txt somehow propagates to U-Boot 
environment during the next boot.

Cheers,
Jan

[Buildroot] [PATCH/next 4/5] solidrun/macchiatobin: add new board

[Baruch Siach]

Hi Jan,

On Mon, Nov 13, 2017 at 01:51:01PM +0100, Jan Kundr?t wrote:
> On pond?l? 13. listopadu 2017 13:27:02 CET, Baruch Siach wrote:
> > Create a uEnv.txt file, and store it in /boot.
> 
> Hi Baruch, does U-Boot auto-load this file on each and every boot?

That depends on the default U-Boot environment. In the case of the 
Macchiatobin the built-in default is empty, and the SPI flash stored 
environment is not in a known state. So you must load uEnv.txt manually on 
every boot to make sure your environment is in a known state.

> If not, than I suggest to name it differently -- perhaps uEnv-recovery.txt. 
> I would expect that any change in a /boot/uEnv.txt somehow propagates to 
> U-Boot environment during the next boot.

That's a good idea.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] [PATCH/next 4/5] solidrun/macchiatobin: add new board

[Sergey Matyukevich]

> > Add MacchiatoBin board by SolidRun. This board is based on Marvell
> > Armada 8040 SoC. Board support package includes the following
> > two options: mainline and vendor BSPs.
> > 
> > Mainline BSP:
> > - Marvell ATF v1.3-armada-17.10 and its dependencies
> > - mainline U-Boot v2017.09
> > - mainline Linux kernel v4.13.11
> 
> Thanks. For the mainline kernel BSP:
> 
> Tested-by: Baruch Siach <baruch@tkos.co.il>
> 
> I'll note though that 'df' crashes here consistently:
> 
> [  962.179129] df[1346]: unhandled level 2 translation fault (11) at 0x00000a74, esr 0x92000046, in busybox[400000+a4000]
> [  962.190801] CPU: 0 PID: 1346 Comm: df Not tainted 4.13.11 #1
> [  962.197869] Hardware name: Marvell 8040 MACHIATOBin (DT)
> ...
> 
> I have not investigated it any further.

This issue is not specific to MacchiatoBin board. I observed it last week
testing images for another arm64 board - Orange Pi Zero Plus2 board.
I haven't investigated it yet.

Meanwhile this is not the only problem with mainline BSP. It turned out that
network interfaces do not work properly neither on v4.13.11 nor in fresh v4.14.
Kernel v4.13.11 doesn't enable them in DTS. Kernel v4.14 does enable them,
but I couldn't make them work: Tx looks ok, but no Rx. Meanwhile on kernel from
devel-4.14/all branch from https://github.com/MISL-EBU-System-SW/mainline-public
management 1Gb interface appears to be working fine.

I plan to bump kernel version to 4.14 and find minimal set of patches needed to
enable networking.

> > +This default configuration will allow you to start experimenting with the
> > +buildroot environment for the MacchiatoBin board based on Marvell Armada
> > +8040 SoC. Documentation for the board hardware and software
> > +is available on wiki: http://wiki.macchiatobin.net
> > +
> > +This default configuration will bring-up the board and allow
> > +access through the serial console.
> 
> Would be nice to note that the serial console is accessible at the micro-USB 
> connector marked CON9.

Ok, will do.

> > +How to write the SD card
> > +========================
> > +
> > +Once the build process is finished you will have an image
> > +called "sdcard.img" in the output/images/ directory.
> > +
> > +Copy the bootable "sdcard.img" onto an SD card with "dd":
> > +
> > +  $ sudo dd if=output/images/sdcard.img of=/dev/sdX
> > +  $ sudo sync
> 
> A somewhat faster one liner:
> 
>   sudo dd if=output/images/sdcard.img of=/dev/sdX bs=1M conv=fsync

Ok, thanks! Will do.


> > +Insert the micro SDcard in MacchiatoBin board and power it up.
> > +The console is on the serial line, 115200 8N1.
> > +
> > +Note that MacchiatoBin board can be setup to load bootloader
> > +from different sources including eMMC, SPI flash, and SD card.
> > +Make sure to properly configure DIP switches SW1 and SW2
> > +according to information available on wiki.
> 
> Would be nice to write here the DIP switches configuration for SD card boot:
> 
> SW2: 01110
> SW1: 1xxxx

Good point. Will do.


> > +=> setenv fdt_addr 0x1000000
> > +=> setenv fdt_high 0xffffffffffffffff
> > +=> setenv fdt_name boot/armada-8040-mcbin.dtb
> > +=> setenv kernel_addr 0x2000000
> > +=> setenv image_name boot/Image
> > +=> setenv bootcmd 'mmc dev 1; ext4load mmc 1:1 $kernel_addr $image_name; ext4load mmc 1:1 $fdt_addr $fdt_name; booti $kernel_addr - $fdt_addr'
> > +=> boot
> 
> Having to type all that on the console is not nice. Unfortunately, current 
> mainline U-Boot does not make it easy to override the SPI flash stored 
> environment. But we can ease the pain somewhat. Create a uEnv.txt file, and 
> store it in /boot. The sequence above can now be shortened to:
> 
> => ext4load mmc 1:1 0x01700000 /boot/uEnv.txt
> => env import -t 0x01700000 $filesize
> => boot

Indeed, that will be easier for quick start.

Regards,
Sergey

[Buildroot] [PATCH/next 4/5] solidrun/macchiatobin: add new board

[Thomas Petazzoni]

Hello,

On Mon, 13 Nov 2017 23:06:10 +0300, Sergey Matyukevich wrote:

> This issue is not specific to MacchiatoBin board. I observed it last week
> testing images for another arm64 board - Orange Pi Zero Plus2 board.
> I haven't investigated it yet.
> 
> Meanwhile this is not the only problem with mainline BSP. It turned out that
> network interfaces do not work properly neither on v4.13.11 nor in fresh v4.14.
> Kernel v4.13.11 doesn't enable them in DTS. Kernel v4.14 does enable them,
> but I couldn't make them work: Tx looks ok, but no Rx. Meanwhile on kernel from
> devel-4.14/all branch from https://github.com/MISL-EBU-System-SW/mainline-public
> management 1Gb interface appears to be working fine.

The fact that network interfaces don't work on mcbin with the stock
4.14 is not expected. I've added in Cc: my colleague Antoine T?nart who
worked on this topic.

Antoine, do you know which patches are missing in 4.14 ?

Thanks!

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

[Buildroot] [PATCH/next 4/5] solidrun/macchiatobin: add new board

[Antoine Ténart]

Hello Thomas, Sergey,

On Mon, Nov 13, 2017 at 11:36:28PM +0100, Thomas Petazzoni wrote:
> On Mon, 13 Nov 2017 23:06:10 +0300, Sergey Matyukevich wrote:
> 
> > Meanwhile this is not the only problem with mainline BSP. It turned out that
> > network interfaces do not work properly neither on v4.13.11 nor in fresh v4.14.
> > Kernel v4.13.11 doesn't enable them in DTS. Kernel v4.14 does enable them,
> > but I couldn't make them work: Tx looks ok, but no Rx. Meanwhile on kernel from
> > devel-4.14/all branch from https://github.com/MISL-EBU-System-SW/mainline-public
> > management 1Gb interface appears to be working fine.
> 
> The fact that network interfaces don't work on mcbin with the stock
> 4.14 is not expected. I've added in Cc: my colleague Antoine T?nart who
> worked on this topic.
> 
> Antoine, do you know which patches are missing in 4.14 ?

The 4.14 network support for the mcbin is partial but you should be able
to use 2 out of the 4 interfaces in the mode U-Boot configured them.
tl;dr; eth0 in 10G (sfp) and eth2 in 1G.

See https://elinux.org/Marvell_EBU:MacchiatoBin for the network
interfaces description.

- eth0 should work on 10G (the sfp cage).
- eth1 is not working because of a bug which is not cleanly fixed yet.
  The devel-4.14/all branch contains a workaround (which is not suitable
  for the upstream kernel), see 0968cd30a0d4 ("DO NOT UPSTREAM: phy: marvell10g:
  Do not reset PHY autoneg for 10G KR mode"). With this patch it should
  work on 10G (sfp) with the 4.14 kernel.
- eth2 should be working just fine on 1G.
- eth3 is not supported yet, in both the upstream kernel and the
  devel-4.14/all branch.

One feature not supported in the upstream 4.14 kernel is the dynamic
reconfiguration of the interfaces, i.e. the ability to switch from/to
10G to/from 1G on eth0 and eth1 given what's connected. To do this you
would need a few device tree patches from devel-4.14/all (which will be
in 4.15):
- 0f0dfbec373e ("arm64: dts: marvell: extend the cp110 syscon register area length")
- c90dab5d2bf4 ("arm64: dts: marvell: add comphy nodes on cp110 master and slave")
- 26c08c06b827 ("arm64: dts: marvell: mcbin: add comphy references to Ethernet ports")

Also, please note the network PHY drivers are not selected to be
built-in in the arm64 upstream defconfig, so you should probably
select both CONFIG_MARVELL_PHY and CONFIG_MARVELL_10G_PHY. This is done
in the devel-4.14/all arm64 defconfig.

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH/next 4/5] solidrun/macchiatobin: add new board

[Sergey Matyukevich]

Hello Antoine,

> > > Meanwhile this is not the only problem with mainline BSP. It turned out that
> > > network interfaces do not work properly neither on v4.13.11 nor in fresh v4.14.
> > > Kernel v4.13.11 doesn't enable them in DTS. Kernel v4.14 does enable them,
> > > but I couldn't make them work: Tx looks ok, but no Rx. Meanwhile on kernel from
> > > devel-4.14/all branch from https://github.com/MISL-EBU-System-SW/mainline-public
> > > management 1Gb interface appears to be working fine.
> > 
> > The fact that network interfaces don't work on mcbin with the stock
> > 4.14 is not expected. I've added in Cc: my colleague Antoine T?nart who
> > worked on this topic.
> > 
> > Antoine, do you know which patches are missing in 4.14 ?
> 
> The 4.14 network support for the mcbin is partial but you should be able
> to use 2 out of the 4 interfaces in the mode U-Boot configured them.
> tl;dr; eth0 in 10G (sfp) and eth2 in 1G.
> 
> See https://elinux.org/Marvell_EBU:MacchiatoBin for the network
> interfaces description.
> 
> - eth0 should work on 10G (the sfp cage).
> - eth1 is not working because of a bug which is not cleanly fixed yet.
>   The devel-4.14/all branch contains a workaround (which is not suitable
>   for the upstream kernel), see 0968cd30a0d4 ("DO NOT UPSTREAM: phy: marvell10g:
>   Do not reset PHY autoneg for 10G KR mode"). With this patch it should
>   work on 10G (sfp) with the 4.14 kernel.
> - eth2 should be working just fine on 1G.
> - eth3 is not supported yet, in both the upstream kernel and the
>   devel-4.14/all branch.
> 
> One feature not supported in the upstream 4.14 kernel is the dynamic
> reconfiguration of the interfaces, i.e. the ability to switch from/to
> 10G to/from 1G on eth0 and eth1 given what's connected. To do this you
> would need a few device tree patches from devel-4.14/all (which will be
> in 4.15):
> - 0f0dfbec373e ("arm64: dts: marvell: extend the cp110 syscon register area length")
> - c90dab5d2bf4 ("arm64: dts: marvell: add comphy nodes on cp110 master and slave")
> - 26c08c06b827 ("arm64: dts: marvell: mcbin: add comphy references to Ethernet ports")
> 
> Also, please note the network PHY drivers are not selected to be
> built-in in the arm64 upstream defconfig, so you should probably
> select both CONFIG_MARVELL_PHY and CONFIG_MARVELL_10G_PHY. This is done
> in the devel-4.14/all arm64 defconfig.

Thanks for detailed summary of mcbin networking support. However it sill looks
like there is a missing piece here. I have checked behavior of both mainline 4.14
(516fb7f2e73dcc) and marvell-mainline devel-4.14/all (a3d9036af3c6033). I did no
changes to kernel/dts/defconfig at all other than enabling Marvell PHYs for mainline
kernel. But the result is still the same: 1Gb eth2 interface works with devel-4.14/all,
but doesn't work with mainline. Though PHY is recognized and attached, mii-diag also
provides sane report. Tx packet counter in ifconfig is increased, but no packets
on wire.

Probably I am missing something obvious. I will do more checks and comparisons
later this week. Setup is just the same: mainline U-Boot 2017.09 and images
built using this patchset.

Regards,
Sergey

[Buildroot] [PATCH/next 4/5] solidrun/macchiatobin: add new board

[Antoine Ténart]

Hi Sergey,

On Tue, Nov 14, 2017 at 12:20:24PM +0300, Sergey Matyukevich wrote:
> 
> Thanks for detailed summary of mcbin networking support. However it sill looks
> like there is a missing piece here. I have checked behavior of both mainline 4.14
> (516fb7f2e73dcc) and marvell-mainline devel-4.14/all (a3d9036af3c6033). I did no
> changes to kernel/dts/defconfig at all other than enabling Marvell PHYs for mainline
> kernel. But the result is still the same: 1Gb eth2 interface works with devel-4.14/all,
> but doesn't work with mainline. Though PHY is recognized and attached, mii-diag also
> provides sane report. Tx packet counter in ifconfig is increased, but no packets
> on wire.
> 
> Probably I am missing something obvious. I will do more checks and comparisons
> later this week. Setup is just the same: mainline U-Boot 2017.09 and images
> built using this patchset.

Note that I never tested with the upstream U-Boot. Do the interfaces
work in U-Boot?

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH/next 4/5] solidrun/macchiatobin: add new board

[Sergey Matyukevich]

Hi Antoine,

> > Thanks for detailed summary of mcbin networking support. However it sill looks
> > like there is a missing piece here. I have checked behavior of both mainline 4.14
> > (516fb7f2e73dcc) and marvell-mainline devel-4.14/all (a3d9036af3c6033). I did no
> > changes to kernel/dts/defconfig at all other than enabling Marvell PHYs for mainline
> > kernel. But the result is still the same: 1Gb eth2 interface works with devel-4.14/all,
> > but doesn't work with mainline. Though PHY is recognized and attached, mii-diag also
> > provides sane report. Tx packet counter in ifconfig is increased, but no packets
> > on wire.
> > 
> > Probably I am missing something obvious. I will do more checks and comparisons
> > later this week. Setup is just the same: mainline U-Boot 2017.09 and images
> > built using this patchset.
> 
> Note that I never tested with the upstream U-Boot. Do the interfaces
> work in U-Boot?

No, interfaces do not work in U-Boot. Probably U-Boot matters,
but even with the same mainline U-Boot interface eth2 works
just fine on devel-4.14/all kernel.

By the way, could you please advise how to switch eth0
from SFP to RJ45 when using mainline kernel 4.14 ?

Regards,
Sergey

[Buildroot] [PATCH/next 4/5] solidrun/macchiatobin: add new board

[Antoine Ténart]

Hi Sergey,

On Tue, Nov 14, 2017 at 11:27:00PM +0300, Sergey Matyukevich wrote:
> 
> No, interfaces do not work in U-Boot. Probably U-Boot matters,
> but even with the same mainline U-Boot interface eth2 works
> just fine on devel-4.14/all kernel.

This is expected. The mainline 4.14 kernel relies on the U-Boot
configuration for some parts while the devel-4.14/all contains all the
patches to configure the network interfaces (+ comphy) from scratch.

So, it seems to me the upstream U-Boot 2017.09 has an issue while
configuring the network interface. There are chances the issue is within
the comphy configuration / driver in this U-Boot version.

> By the way, could you please advise how to switch eth0
> from SFP to RJ45 when using mainline kernel 4.14 ?

You need to apply the dt patches I provided. You should then be able to
use eth0 and eth1 with either an SFP or an RJ45 cable, depending on
what's (dynamically) connected. To sum up, you just need to plugin
either the SFP or the RJ45 cable to start using the interface in the
right mode. You can switch from one to the other without rebooting the
board.

To get this board supported in Buildroot with an upstream kernel, I
would suggest to put the device tree patches I gave you, so that the
kernel can not rely on the bootloader configuration. And as soon as 4.15
is out the patches can be removed from Buildroot.

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH/next 4/5] solidrun/macchiatobin: add new board

[Sergey Matyukevich]

Hi Antoine,

Thanks for the update on upstream status of this board.

> > By the way, could you please advise how to switch eth0
> > from SFP to RJ45 when using mainline kernel 4.14 ?
> 
> You need to apply the dt patches I provided. You should then be able to
> use eth0 and eth1 with either an SFP or an RJ45 cable, depending on
> what's (dynamically) connected. To sum up, you just need to plugin
> either the SFP or the RJ45 cable to start using the interface in the
> right mode. You can switch from one to the other without rebooting the
> board.
> 
> To get this board supported in Buildroot with an upstream kernel, I
> would suggest to put the device tree patches I gave you, so that the
> kernel can not rely on the bootloader configuration. And as soon as 4.15
> is out the patches can be removed from Buildroot.

With those 3 dts patches J5 management interface is working fine
even with upstream U-Boot. So I will add those patches to board
files for the time being, just to enable network access to the board
right out of the box.

Regards,
Sergey

[Buildroot] [PATCH/next 4/5] solidrun/macchiatobin: add new board

[Baruch Siach]

Hi Sergey,

On Sun, Nov 12, 2017 at 11:16:45PM +0300, Sergey Matyukevich wrote: 
> diff --git a/configs/solidrun_macchiatobin_mainline_defconfig b/configs/solidrun_macchiatobin_mainline_defconfig
> new file mode 100644
> index 0000000000..ab82865a0d
> --- /dev/null
> +++ b/configs/solidrun_macchiatobin_mainline_defconfig
> @@ -0,0 +1,46 @@
> +BR2_aarch64=y
> +
> +#
> +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_13=y
> +BR2_TARGET_GENERIC_HOSTNAME="mcbin"
> +BR2_TARGET_GENERIC_ISSUE="Welcome to Buildroot for Marvell MacchiatoBin"
> +
> +# Firmware
> +BR2_TARGET_ARM_TRUSTED_FIRMWARE=y
> +BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_GIT=y
> +BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_REPO_URL="https://github.com/MarvellEmbeddedProcessors/atf-marvell.git"
> +BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_REPO_VERSION="atf-v1.3-armada-17.10"
> +BR2_TARGET_ARM_TRUSTED_FIRMWARE_PLATFORM="a80x0_mcbin"
> +BR2_TARGET_ARM_TRUSTED_FIRMWARE_ADDITIONAL_VARIABLES="USE_COHERENT_MEM=0"
> +
> +BR2_TARGET_ARMADA_FIRMWARE=y
> +BR2_TARGET_ARMADA_FIRMWARE_IMAGE="mrvl_scp_bl2_8040.img"
> +BR2_TARGET_ARMADA_FIRMWARE_VERSION="binaries-marvell-armada-17.10"

It turns out that this firmware is not required, at least for the mainline 
kernel. The system boots just fine without it. It might be needed for the 
Marvell provided kernel. I didn't check that.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] [PATCH/next 4/5] solidrun/macchiatobin: add new board

[Sergey Matyukevich]

> > +BR2_TARGET_ARMADA_FIRMWARE=y
> > +BR2_TARGET_ARMADA_FIRMWARE_IMAGE="mrvl_scp_bl2_8040.img"
> > +BR2_TARGET_ARMADA_FIRMWARE_VERSION="binaries-marvell-armada-17.10"
> 
> It turns out that this firmware is not required, at least for the mainline 
> kernel. The system boots just fine without it. It might be needed for the 
> Marvell provided kernel. I didn't check that.

Thanks for checking! I followed BSP HOWTO at http://wiki.macchiatobin.net.
But it looks slightly outdated since it refers to 17.06 versions for all
the repositories. I will check both mainline and vendor BSPs to clarify
whether it is needed at all.

Regards,
Sergey

[Buildroot] [PATCH/next 4/5] solidrun/macchiatobin: add new board

[Sergey Matyukevich]

Hi Baruch,

> > > +BR2_TARGET_ARMADA_FIRMWARE=y
> > > +BR2_TARGET_ARMADA_FIRMWARE_IMAGE="mrvl_scp_bl2_8040.img"
> > > +BR2_TARGET_ARMADA_FIRMWARE_VERSION="binaries-marvell-armada-17.10"
> > 
> > It turns out that this firmware is not required, at least for the mainline 
> > kernel. The system boots just fine without it. It might be needed for the 
> > Marvell provided kernel. I didn't check that.
> 
> Thanks for checking! I followed BSP HOWTO at http://wiki.macchiatobin.net.
> But it looks slightly outdated since it refers to 17.06 versions for all
> the repositories. I will check both mainline and vendor BSPs to clarify
> whether it is needed at all.

I tried to build both vendor and mainline BSP w/o this firmware. Both appear
to be working fine without this firmware. According to ATF firmware design doc
https://github.com/ARM-software/arm-trusted-firmware, this SCP_BL2 image is
for platform-specific power/clock/reset/sysctl coprocessor available on
some systems.

As I mentioned, I didn't notice any issues during quick smoke test of images
built w/o SCP_BL2 firmware. However, according to MacchiatoBin wiki page
quite a few Linux power management features depend on this firmware:
http://wiki.macchiatobin.net/tiki-index.php?page=Enable+Power+Management+on+MACCHIATObin

So it makes a lot of sense to keep using it. To summarize, I would prefer
to keep this package, fixing all the issues.

Regards,
Sergey

[Buildroot] [PATCH/next 5/5] Add myself to MacchiatoBin releated packages

[Sergey Matyukevich]

Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
---
 DEVELOPERS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/DEVELOPERS b/DEVELOPERS
index 7a4218d9c5..39773bd65e 100644
--- a/DEVELOPERS
+++ b/DEVELOPERS
@@ -1474,12 +1474,18 @@ F:	package/mpir/
 N:	Sergey Matyukevich <geomatsi@gmail.com>
 F:	package/xr819-xradio/
 F:	package/armbian-firmware/
+F:	boot/arm-trusted-firmware/
+F:	boot/armada-firmware/
+F:	boot/armada-ddr/
 F:	board/orangepi/orangepi-zero
 F:	board/orangepi/orangepi-one
 F:	board/linksprite/pcduino
+F:	board/solidrun/macchiatobin
 F:	configs/orangepi_one_defconfig
 F:	configs/orangepi_zero_defconfig
 F:	configs/linksprite_pcduino_defconfig
+F:	configs/solidrun_macchiatobin_marvell_defconfig
+F:	configs/solidrun_macchiatobin_mainline_defconfig
 
 N:	Sergio Prado <sergio.prado@e-labworks.com>
 F:	package/libgdiplus/
-- 
2.11.0

[Buildroot] [PATCH/next 0/5] Add support for MacchiatoBin board

[Arnout Vandecappelle]

On 12-11-17 21:16, Sergey Matyukevich wrote:
> Hi all,
> 
> This patchset adds support for SolidRun MacchiatoBin board based on
> Marvell Armada 8040 SoC. For convenience the following two different
> build configurations are added:
> 
> - mainline BSP
>   mainline Linux v4.13.11 and U-Boot v2017.09
> 
> - vendor BSP (enables more hardware)
>   BSP from Marvell based on Linux 4.4.52 and U-Boot v2017.03

 Do we really want to have defconfigs for both upstream and vendor BSP?
Especially because we will also probably have a graphical defconfig later...
This way, we end up with 3-4 defconfigs per board, for dozens of boards...

 That said, I do think it is useful to have both of these for this specific
board. It's just that I'm afraid we're going to be overwhelmed by the number of
defconfigs...

 What do the others think?

 Regards,
 Arnout

> 
> Patches are rebased on top of next branch.
> 
> Regards,
> Sergey
> 
> Sergey Matyukevich (5):
>   armada-firmware: new package
>   armada-ddr: new package
>   atf: add support for Marvell Armada SoCs
>   solidrun/macchiatobin: add new board
>   DEVELOPERS: add myself to MacchiatoBin releated packages
> 
>  DEVELOPERS                                        |    6 +
>  board/solidrun/macchiatobin/genimage.cfg          |   16 +++++
>  board/solidrun/macchiatobin/readme.txt            |   70 ++++++++++++++++++++++
>  boot/Config.in                                    |    2 
>  boot/arm-trusted-firmware/arm-trusted-firmware.mk |   13 ++++
>  boot/armada-ddr/Config.in                         |   16 +++++
>  boot/armada-ddr/armada-ddr.hash                   |    2 
>  boot/armada-ddr/armada-ddr.mk                     |   20 ++++++
>  boot/armada-firmware/Config.in                    |   19 +++++
>  boot/armada-firmware/armada-firmware.hash         |    2 
>  boot/armada-firmware/armada-firmware.mk           |   18 +++++
>  configs/solidrun_macchiatobin_mainline_defconfig  |   46 ++++++++++++++
>  configs/solidrun_macchiatobin_marvell_defconfig   |   48 +++++++++++++++
>  13 files changed, 278 insertions(+)
> _______________________________________________
> 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] [PATCH/next 0/5] Add support for MacchiatoBin board

[Baruch Siach]

Hi Arnout,

On Tue, Nov 14, 2017 at 10:58:43PM +0100, Arnout Vandecappelle wrote:
> On 12-11-17 21:16, Sergey Matyukevich wrote:
> > This patchset adds support for SolidRun MacchiatoBin board based on
> > Marvell Armada 8040 SoC. For convenience the following two different
> > build configurations are added:
> > 
> > - mainline BSP
> >   mainline Linux v4.13.11 and U-Boot v2017.09
> > 
> > - vendor BSP (enables more hardware)
> >   BSP from Marvell based on Linux 4.4.52 and U-Boot v2017.03
> 
>  Do we really want to have defconfigs for both upstream and vendor BSP?
> Especially because we will also probably have a graphical defconfig later...
> This way, we end up with 3-4 defconfigs per board, for dozens of boards...
> 
>  That said, I do think it is useful to have both of these for this specific
> board. It's just that I'm afraid we're going to be overwhelmed by the number of
> defconfigs...
> 
>  What do the others think?

This board has no native graphic interface. So you can think of it as a basic 
(mainline) defconfig, and a fully featured (vendor) defconfig. This is similar 
to the basic and "demo" defconfigs that we have for other boards.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -