[PATCH 1/5] arm: mvebu: Espressobin: Move env load addresses

[PATCH 1/5] arm: mvebu: Espressobin: Move env load addresses

[Pali Rohár]

According to Marvell's U-Boot description [1] current env load addresses
overlaps with ATF RT services region and TEE. Because the ATF RT service
and TEE region is going to be marked as secure and can't be overwritten,
use different different addresses for envs.

[1] - https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/0a5b159806baa0746b6449920e450498bc269ba7

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 include/configs/mvebu_armada-37xx.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
index ca662b0ce7..ac0998a2d4 100644
--- a/include/configs/mvebu_armada-37xx.h
+++ b/include/configs/mvebu_armada-37xx.h
@@ -91,10 +91,10 @@
 #include <config_distro_bootcmd.h>
 
 #define CONFIG_EXTRA_ENV_SETTINGS	\
-	"scriptaddr=0x4d00000\0"	\
-	"pxefile_addr_r=0x4e00000\0"	\
-	"fdt_addr_r=0x4f00000\0"	\
-	"kernel_addr_r=0x5000000\0"	\
+	"scriptaddr=0x6d00000\0"	\
+	"pxefile_addr_r=0x6e00000\0"	\
+	"fdt_addr_r=0x6f00000\0"	\
+	"kernel_addr_r=0x7000000\0"	\
 	"ramdisk_addr_r=0x8000000\0"	\
 	BOOTENV
 
-- 
2.20.1

[PATCH 2/5] arm: mvebu: Espressobin: Change default loadaddr

[Pali Rohár]

Current loadaddr is not writable on Espressobin and 'loadb' command cause
rebooting board. Marvell's U-Boot already set default loadaddr to value
0x06000000 [1] and after this change 'loadb' is working fine.

[1] - https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/0a5b159806baa0746b6449920e450498bc269ba7

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 include/configs/mvebu_armada-37xx.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
index ac0998a2d4..c6b0e2573a 100644
--- a/include/configs/mvebu_armada-37xx.h
+++ b/include/configs/mvebu_armada-37xx.h
@@ -37,7 +37,7 @@
 /*
  * Other required minimal configurations
  */
-#define CONFIG_SYS_LOAD_ADDR	0x00800000	/* default load adr- 8M */
+#define CONFIG_SYS_LOAD_ADDR	0x06000000	/* default load adr */
 #define CONFIG_SYS_RESET_ADDRESS 0xffff0000	/* Rst Vector Adr */
 #define CONFIG_SYS_MAXARGS	32	/* max number of command args */
 
-- 
2.20.1

[PATCH 2/5] arm: mvebu: Espressobin: Change default loadaddr

[Stefan Roese]

On 24.08.20 16:24, Pali Roh?r wrote:
> Current loadaddr is not writable on Espressobin and 'loadb' command cause
> rebooting board. Marvell's U-Boot already set default loadaddr to value
> 0x06000000 [1] and after this change 'loadb' is working fine.
> 
> [1] - https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/0a5b159806baa0746b6449920e450498bc269ba7
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

[PATCH 3/5] arm: mvebu: Espressobin: Define fdt_addr and kernel_addr env aliases

[Pali Rohár]

Boot scripts for existing Espressobin Linux distributions, like OpenWRT,
expect that U-Boot set fdt_addr and kernel_addr envs. So add env aliases
from fdt_addr_r and kernel_addr_r values.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 include/configs/mvebu_armada-37xx.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
index c6b0e2573a..6feceda757 100644
--- a/include/configs/mvebu_armada-37xx.h
+++ b/include/configs/mvebu_armada-37xx.h
@@ -90,10 +90,13 @@
 
 #include <config_distro_bootcmd.h>
 
+/* fdt_addr and kernel_addr are needed for existing distribution boot scripts */
 #define CONFIG_EXTRA_ENV_SETTINGS	\
 	"scriptaddr=0x6d00000\0"	\
 	"pxefile_addr_r=0x6e00000\0"	\
+	"fdt_addr=0x6f00000\0"		\
 	"fdt_addr_r=0x6f00000\0"	\
+	"kernel_addr=0x7000000\0"	\
 	"kernel_addr_r=0x7000000\0"	\
 	"ramdisk_addr_r=0x8000000\0"	\
 	BOOTENV
-- 
2.20.1

[PATCH 3/5] arm: mvebu: Espressobin: Define fdt_addr and kernel_addr env aliases

[Stefan Roese]

On 24.08.20 16:25, Pali Roh?r wrote:
> Boot scripts for existing Espressobin Linux distributions, like OpenWRT,
> expect that U-Boot set fdt_addr and kernel_addr envs. So add env aliases
> from fdt_addr_r and kernel_addr_r values.
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

[PATCH 4/5] arm: mvebu: Espressobin: Define console env

[Pali Rohár]

Some distribution bootscripts append console env into boot cmdline.
So define console env correctly to have early console access.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 include/configs/mvebu_armada-37xx.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
index 6feceda757..b473072976 100644
--- a/include/configs/mvebu_armada-37xx.h
+++ b/include/configs/mvebu_armada-37xx.h
@@ -17,6 +17,7 @@
 
 #define CONFIG_SYS_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, \
 					  115200, 230400, 460800, 921600 }
+#define CONFIG_DEFAULT_CONSOLE "console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000"
 
 /*
  * For booting Linux, the board info and command line data
@@ -99,6 +100,7 @@
 	"kernel_addr=0x7000000\0"	\
 	"kernel_addr_r=0x7000000\0"	\
 	"ramdisk_addr_r=0x8000000\0"	\
+	"console=" CONFIG_DEFAULT_CONSOLE "\0" \
 	BOOTENV
 
 #endif /* _CONFIG_MVEBU_ARMADA_37XX_H */
-- 
2.20.1

[PATCH 4/5] arm: mvebu: Espressobin: Define console env

[Stefan Roese]

On 24.08.20 16:25, Pali Roh?r wrote:
> Some distribution bootscripts append console env into boot cmdline.
> So define console env correctly to have early console access.
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

[PATCH 4/5] arm: mvebu: Espressobin: Define console env

[Andre Heider]

Hi,

On 24/08/2020 16:25, Pali Roh?r wrote:
> Some distribution bootscripts append console env into boot cmdline.
> So define console env correctly to have early console access.
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>
> ---
>   include/configs/mvebu_armada-37xx.h | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
> index 6feceda757..b473072976 100644
> --- a/include/configs/mvebu_armada-37xx.h
> +++ b/include/configs/mvebu_armada-37xx.h
> @@ -17,6 +17,7 @@
>   
>   #define CONFIG_SYS_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, \
>   					  115200, 230400, 460800, 921600 }
> +#define CONFIG_DEFAULT_CONSOLE "console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000"
>   
>   /*
>    * For booting Linux, the board info and command line data
> @@ -99,6 +100,7 @@
>   	"kernel_addr=0x7000000\0"	\
>   	"kernel_addr_r=0x7000000\0"	\
>   	"ramdisk_addr_r=0x8000000\0"	\
> +	"console=" CONFIG_DEFAULT_CONSOLE "\0" \
>   	BOOTENV
>   
>   #endif /* _CONFIG_MVEBU_ARMADA_37XX_H */
> 

this breaks booting debian with systemd for me:
[    4.632197] systemd-udevd[90]: Starting version 241
[    4.639324] systemd-udevd[91]: Failed to create udev control event 
source: Operation not permitted

"env delete console" and it works again.

The device tree already has 'stdout-path = "serial0:115200n8";' btw.

Regards,
Andre

[PATCH 4/5] arm: mvebu: Espressobin: Define console env

[Pali Rohár]

On Wednesday 26 August 2020 15:22:26 Andre Heider wrote:
> Hi,
> 
> On 24/08/2020 16:25, Pali Roh?r wrote:
> > Some distribution bootscripts append console env into boot cmdline.
> > So define console env correctly to have early console access.
> > 
> > Signed-off-by: Pali Roh?r <pali@kernel.org>
> > ---
> >   include/configs/mvebu_armada-37xx.h | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
> > index 6feceda757..b473072976 100644
> > --- a/include/configs/mvebu_armada-37xx.h
> > +++ b/include/configs/mvebu_armada-37xx.h
> > @@ -17,6 +17,7 @@
> >   #define CONFIG_SYS_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, \
> >   					  115200, 230400, 460800, 921600 }
> > +#define CONFIG_DEFAULT_CONSOLE "console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000"
> >   /*
> >    * For booting Linux, the board info and command line data
> > @@ -99,6 +100,7 @@
> >   	"kernel_addr=0x7000000\0"	\
> >   	"kernel_addr_r=0x7000000\0"	\
> >   	"ramdisk_addr_r=0x8000000\0"	\
> > +	"console=" CONFIG_DEFAULT_CONSOLE "\0" \
> >   	BOOTENV
> >   #endif /* _CONFIG_MVEBU_ARMADA_37XX_H */
> > 
> 
> this breaks booting debian with systemd for me:
> [    4.632197] systemd-udevd[90]: Starting version 241
> [    4.639324] systemd-udevd[91]: Failed to create udev control event
> source: Operation not permitted
> 
> "env delete console" and it works again.

This is really suspicious. Why systemd has problems with control socket
when console= parameter is specified on boot command line? And if
console= parameter is problematic on command line, why console output is
working fine? For me it looks like this variable controls something
different, not (only) console output. Maybe some bootscript sets
something more when it see u-boot env ${console} non-empty?

> The device tree already has 'stdout-path = "serial0:115200n8";' btw.

I see. But it does not initialize earlycon.

[PATCH 4/5] arm: mvebu: Espressobin: Define console env

[Andre Heider]

On 26/08/2020 15:31, Pali Roh?r wrote:
> On Wednesday 26 August 2020 15:22:26 Andre Heider wrote:
>> Hi,
>>
>> On 24/08/2020 16:25, Pali Roh?r wrote:
>>> Some distribution bootscripts append console env into boot cmdline.
>>> So define console env correctly to have early console access.
>>>
>>> Signed-off-by: Pali Roh?r <pali@kernel.org>
>>> ---
>>>    include/configs/mvebu_armada-37xx.h | 2 ++
>>>    1 file changed, 2 insertions(+)
>>>
>>> diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
>>> index 6feceda757..b473072976 100644
>>> --- a/include/configs/mvebu_armada-37xx.h
>>> +++ b/include/configs/mvebu_armada-37xx.h
>>> @@ -17,6 +17,7 @@
>>>    #define CONFIG_SYS_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, \
>>>    					  115200, 230400, 460800, 921600 }
>>> +#define CONFIG_DEFAULT_CONSOLE "console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000"
>>>    /*
>>>     * For booting Linux, the board info and command line data
>>> @@ -99,6 +100,7 @@
>>>    	"kernel_addr=0x7000000\0"	\
>>>    	"kernel_addr_r=0x7000000\0"	\
>>>    	"ramdisk_addr_r=0x8000000\0"	\
>>> +	"console=" CONFIG_DEFAULT_CONSOLE "\0" \
>>>    	BOOTENV
>>>    #endif /* _CONFIG_MVEBU_ARMADA_37XX_H */
>>>
>>
>> this breaks booting debian with systemd for me:
>> [    4.632197] systemd-udevd[90]: Starting version 241
>> [    4.639324] systemd-udevd[91]: Failed to create udev control event
>> source: Operation not permitted
>>
>> "env delete console" and it works again.
> 
> This is really suspicious. Why systemd has problems with control socket
> when console= parameter is specified on boot command line? And if
> console= parameter is problematic on command line, why console output is
> working fine? For me it looks like this variable controls something
> different, not (only) console output. Maybe some bootscript sets
> something more when it see u-boot env ${console} non-empty?

It sounds like a bug in systemd, this may be related:
https://github.com/systemd/systemd/issues/13332

With ugly workarounds like:
https://github.com/openembedded/openembedded-core/commit/dd6ee0b06cd8df6204cf600050516d15172302ea

This is easy for to me to work around, but note that this systemd 
version is the one shipping with current debian stable.

[PATCH 4/5] arm: mvebu: Espressobin: Define console env

[Pali Rohár]

On Wednesday 26 August 2020 16:00:05 Andre Heider wrote:
> On 26/08/2020 15:31, Pali Roh?r wrote:
> > On Wednesday 26 August 2020 15:22:26 Andre Heider wrote:
> > > Hi,
> > > 
> > > On 24/08/2020 16:25, Pali Roh?r wrote:
> > > > Some distribution bootscripts append console env into boot cmdline.
> > > > So define console env correctly to have early console access.
> > > > 
> > > > Signed-off-by: Pali Roh?r <pali@kernel.org>
> > > > ---
> > > >    include/configs/mvebu_armada-37xx.h | 2 ++
> > > >    1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
> > > > index 6feceda757..b473072976 100644
> > > > --- a/include/configs/mvebu_armada-37xx.h
> > > > +++ b/include/configs/mvebu_armada-37xx.h
> > > > @@ -17,6 +17,7 @@
> > > >    #define CONFIG_SYS_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, \
> > > >    					  115200, 230400, 460800, 921600 }
> > > > +#define CONFIG_DEFAULT_CONSOLE "console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000"
> > > >    /*
> > > >     * For booting Linux, the board info and command line data
> > > > @@ -99,6 +100,7 @@
> > > >    	"kernel_addr=0x7000000\0"	\
> > > >    	"kernel_addr_r=0x7000000\0"	\
> > > >    	"ramdisk_addr_r=0x8000000\0"	\
> > > > +	"console=" CONFIG_DEFAULT_CONSOLE "\0" \
> > > >    	BOOTENV
> > > >    #endif /* _CONFIG_MVEBU_ARMADA_37XX_H */
> > > > 
> > > 
> > > this breaks booting debian with systemd for me:
> > > [    4.632197] systemd-udevd[90]: Starting version 241
> > > [    4.639324] systemd-udevd[91]: Failed to create udev control event
> > > source: Operation not permitted
> > > 
> > > "env delete console" and it works again.
> > 
> > This is really suspicious. Why systemd has problems with control socket
> > when console= parameter is specified on boot command line? And if
> > console= parameter is problematic on command line, why console output is
> > working fine? For me it looks like this variable controls something
> > different, not (only) console output. Maybe some bootscript sets
> > something more when it see u-boot env ${console} non-empty?
> 
> It sounds like a bug in systemd, this may be related:
> https://github.com/systemd/systemd/issues/13332
> 
> With ugly workarounds like:
> https://github.com/openembedded/openembedded-core/commit/dd6ee0b06cd8df6204cf600050516d15172302ea
> 
> This is easy for to me to work around, but note that this systemd version is
> the one shipping with current debian stable.

But this looks like to be related to command line 'console=null'.

Can you check which parameter is causing problem? console=... or
earlycon=... ? Also do you have /dev/ttyMV0 in your system?

[PATCH 4/5] arm: mvebu: Espressobin: Define console env

[Andre Heider]

On 26/08/2020 16:10, Pali Roh?r wrote:
> On Wednesday 26 August 2020 16:00:05 Andre Heider wrote:
>> On 26/08/2020 15:31, Pali Roh?r wrote:
>>> On Wednesday 26 August 2020 15:22:26 Andre Heider wrote:
>>>> Hi,
>>>>
>>>> On 24/08/2020 16:25, Pali Roh?r wrote:
>>>>> Some distribution bootscripts append console env into boot cmdline.
>>>>> So define console env correctly to have early console access.
>>>>>
>>>>> Signed-off-by: Pali Roh?r <pali@kernel.org>
>>>>> ---
>>>>>     include/configs/mvebu_armada-37xx.h | 2 ++
>>>>>     1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
>>>>> index 6feceda757..b473072976 100644
>>>>> --- a/include/configs/mvebu_armada-37xx.h
>>>>> +++ b/include/configs/mvebu_armada-37xx.h
>>>>> @@ -17,6 +17,7 @@
>>>>>     #define CONFIG_SYS_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, \
>>>>>     					  115200, 230400, 460800, 921600 }
>>>>> +#define CONFIG_DEFAULT_CONSOLE "console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000"
>>>>>     /*
>>>>>      * For booting Linux, the board info and command line data
>>>>> @@ -99,6 +100,7 @@
>>>>>     	"kernel_addr=0x7000000\0"	\
>>>>>     	"kernel_addr_r=0x7000000\0"	\
>>>>>     	"ramdisk_addr_r=0x8000000\0"	\
>>>>> +	"console=" CONFIG_DEFAULT_CONSOLE "\0" \
>>>>>     	BOOTENV
>>>>>     #endif /* _CONFIG_MVEBU_ARMADA_37XX_H */
>>>>>
>>>>
>>>> this breaks booting debian with systemd for me:
>>>> [    4.632197] systemd-udevd[90]: Starting version 241
>>>> [    4.639324] systemd-udevd[91]: Failed to create udev control event
>>>> source: Operation not permitted
>>>>
>>>> "env delete console" and it works again.
>>>
>>> This is really suspicious. Why systemd has problems with control socket
>>> when console= parameter is specified on boot command line? And if
>>> console= parameter is problematic on command line, why console output is
>>> working fine? For me it looks like this variable controls something
>>> different, not (only) console output. Maybe some bootscript sets
>>> something more when it see u-boot env ${console} non-empty?
>>
>> It sounds like a bug in systemd, this may be related:
>> https://github.com/systemd/systemd/issues/13332
>>
>> With ugly workarounds like:
>> https://github.com/openembedded/openembedded-core/commit/dd6ee0b06cd8df6204cf600050516d15172302ea
>>
>> This is easy for to me to work around, but note that this systemd version is
>> the one shipping with current debian stable.
> 
> But this looks like to be related to command line 'console=null'.
> 
> Can you check which parameter is causing problem? console=... or
> earlycon=... ? Also do you have /dev/ttyMV0 in your system?
> 

yup, it's there:
crw--w---- 1 root tty 253, 0 Aug 26 15:09 /dev/ttyMV0

But I think it's related to console=null because it ends up as invalid:
Your patch sets "console" to "console=...".
Debian's boot.scr set "bootargs" to "... console=${console}".
So we end up with with kernel args "console=console=..." :)

So we need to strip one "console=", at least for debian's boot scripts:
"setenv console ttyMV0,115200 earlycon=ar3700_uart,0xd0012000" and it 
works again, including earlycon.

Regards,
Andre

[PATCH 4/5] arm: mvebu: Espressobin: Define console env

[Pali Rohár]

On Wednesday 26 August 2020 16:43:10 Andre Heider wrote:
> On 26/08/2020 16:10, Pali Roh?r wrote:
> > On Wednesday 26 August 2020 16:00:05 Andre Heider wrote:
> > > On 26/08/2020 15:31, Pali Roh?r wrote:
> > > > On Wednesday 26 August 2020 15:22:26 Andre Heider wrote:
> > > > > Hi,
> > > > > 
> > > > > On 24/08/2020 16:25, Pali Roh?r wrote:
> > > > > > Some distribution bootscripts append console env into boot cmdline.
> > > > > > So define console env correctly to have early console access.
> > > > > > 
> > > > > > Signed-off-by: Pali Roh?r <pali@kernel.org>
> > > > > > ---
> > > > > >     include/configs/mvebu_armada-37xx.h | 2 ++
> > > > > >     1 file changed, 2 insertions(+)
> > > > > > 
> > > > > > diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
> > > > > > index 6feceda757..b473072976 100644
> > > > > > --- a/include/configs/mvebu_armada-37xx.h
> > > > > > +++ b/include/configs/mvebu_armada-37xx.h
> > > > > > @@ -17,6 +17,7 @@
> > > > > >     #define CONFIG_SYS_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, \
> > > > > >     					  115200, 230400, 460800, 921600 }
> > > > > > +#define CONFIG_DEFAULT_CONSOLE "console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000"
> > > > > >     /*
> > > > > >      * For booting Linux, the board info and command line data
> > > > > > @@ -99,6 +100,7 @@
> > > > > >     	"kernel_addr=0x7000000\0"	\
> > > > > >     	"kernel_addr_r=0x7000000\0"	\
> > > > > >     	"ramdisk_addr_r=0x8000000\0"	\
> > > > > > +	"console=" CONFIG_DEFAULT_CONSOLE "\0" \
> > > > > >     	BOOTENV
> > > > > >     #endif /* _CONFIG_MVEBU_ARMADA_37XX_H */
> > > > > > 
> > > > > 
> > > > > this breaks booting debian with systemd for me:
> > > > > [    4.632197] systemd-udevd[90]: Starting version 241
> > > > > [    4.639324] systemd-udevd[91]: Failed to create udev control event
> > > > > source: Operation not permitted
> > > > > 
> > > > > "env delete console" and it works again.
> > > > 
> > > > This is really suspicious. Why systemd has problems with control socket
> > > > when console= parameter is specified on boot command line? And if
> > > > console= parameter is problematic on command line, why console output is
> > > > working fine? For me it looks like this variable controls something
> > > > different, not (only) console output. Maybe some bootscript sets
> > > > something more when it see u-boot env ${console} non-empty?
> > > 
> > > It sounds like a bug in systemd, this may be related:
> > > https://github.com/systemd/systemd/issues/13332
> > > 
> > > With ugly workarounds like:
> > > https://github.com/openembedded/openembedded-core/commit/dd6ee0b06cd8df6204cf600050516d15172302ea
> > > 
> > > This is easy for to me to work around, but note that this systemd version is
> > > the one shipping with current debian stable.
> > 
> > But this looks like to be related to command line 'console=null'.
> > 
> > Can you check which parameter is causing problem? console=... or
> > earlycon=... ? Also do you have /dev/ttyMV0 in your system?
> > 
> 
> yup, it's there:
> crw--w---- 1 root tty 253, 0 Aug 26 15:09 /dev/ttyMV0
> 
> But I think it's related to console=null because it ends up as invalid:
> Your patch sets "console" to "console=...".

It is doing same thing as other boards in U-Boot, see:

$ git grep 'define.*CONFIG_DEFAULT_CONSOLE'
include/configs/arndale.h:#define CONFIG_DEFAULT_CONSOLE                "console=ttySAC2,115200n8\0"
include/configs/espresso7420.h:#define CONFIG_DEFAULT_CONSOLE   "console=ttySAC1,115200n8\0"
include/configs/odroid.h:#define CONFIG_DEFAULT_CONSOLE         "console=ttySAC1,115200n8\0"
include/configs/odroid_xu3.h:#define CONFIG_DEFAULT_CONSOLE             "console=ttySAC2,115200n8\0"
include/configs/origen.h:#define CONFIG_DEFAULT_CONSOLE         "console=ttySAC1,115200n8\0"
include/configs/peach-pi.h:#define CONFIG_DEFAULT_CONSOLE       "console=ttySAC1,115200n8\0"
include/configs/peach-pit.h:#define CONFIG_DEFAULT_CONSOLE      "console=ttySAC1,115200n8\0"
include/configs/s5p_goni.h:#define CONFIG_DEFAULT_CONSOLE       "console=ttySAC2,115200n8\0"
include/configs/s5pc210_universal.h:#define CONFIG_DEFAULT_CONSOLE              "console=ttySAC1,115200n8\0"
include/configs/smdk5250.h:#define CONFIG_DEFAULT_CONSOLE               "console=ttySAC1,115200n8\0"
include/configs/smdk5420.h:#define CONFIG_DEFAULT_CONSOLE       "console=ttySAC1,115200n8\0"
include/configs/smdk5420.h:#define CONFIG_DEFAULT_CONSOLE               "console=ttySAC1,115200n8\0"
include/configs/smdkv310.h:#define CONFIG_DEFAULT_CONSOLE               "console=ttySAC2,115200n8\0"
include/configs/snow.h:#define CONFIG_DEFAULT_CONSOLE           "console=ttySAC1,115200n8\0"
include/configs/spring.h:#define CONFIG_DEFAULT_CONSOLE         "console=ttySAC1,115200n8\0"
include/configs/trats.h:#define CONFIG_DEFAULT_CONSOLE          "console=ttySAC2,115200n8\0"
include/configs/trats2.h:#define CONFIG_DEFAULT_CONSOLE         "console=ttySAC2,115200n8\0"

and:

$ git grep 'CONFIG_DEFAULT_CONSOLE' | grep -v ':#define'
include/configs/odroid.h:       "console=" CONFIG_DEFAULT_CONSOLE \
include/configs/odroid_xu3.h:   "console=" CONFIG_DEFAULT_CONSOLE \
include/configs/s5p_goni.h:     "console=" CONFIG_DEFAULT_CONSOLE \
include/configs/s5pc210_universal.h:    "console=" CONFIG_DEFAULT_CONSOLE \
include/configs/trats.h:        "console=" CONFIG_DEFAULT_CONSOLE \
include/configs/trats2.h:       "console=" CONFIG_DEFAULT_CONSOLE \
scripts/config_whitelist.txt:CONFIG_DEFAULT_CONSOLE

> Debian's boot.scr set "bootargs" to "... console=${console}".
> So we end up with with kernel args "console=console=..." :)

So then also other U-Boot boards are broken in Debian...
Where is that Debian's boot.scr file? In which package?

Armbian has 'setenv bootargs "$console ...'
https://dl.armbian.com/espressobin/u-boot/bootscript/boot.cmd

OpenWRT has 'setenv bootargs "${bootargs} ${console}"'
https://github.com/openwrt/openwrt/blob/master/target/linux/mvebu/image/generic-arm64.bootscript

So it seems that all expects that ${console} env contains 'console=tty...'

> So we need to strip one "console=", at least for debian's boot scripts:
> "setenv console ttyMV0,115200 earlycon=ar3700_uart,0xd0012000" and it works
> again, including earlycon.
> 
> Regards,
> Andre

[PATCH 4/5] arm: mvebu: Espressobin: Define console env

[Andre Heider]

On 26/08/2020 17:10, Pali Roh?r wrote:
> On Wednesday 26 August 2020 16:43:10 Andre Heider wrote:
>> On 26/08/2020 16:10, Pali Roh?r wrote:
>>> On Wednesday 26 August 2020 16:00:05 Andre Heider wrote:
>>>> On 26/08/2020 15:31, Pali Roh?r wrote:
>>>>> On Wednesday 26 August 2020 15:22:26 Andre Heider wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 24/08/2020 16:25, Pali Roh?r wrote:
>>>>>>> Some distribution bootscripts append console env into boot cmdline.
>>>>>>> So define console env correctly to have early console access.
>>>>>>>
>>>>>>> Signed-off-by: Pali Roh?r <pali@kernel.org>
>>>>>>> ---
>>>>>>>      include/configs/mvebu_armada-37xx.h | 2 ++
>>>>>>>      1 file changed, 2 insertions(+)
>>>>>>>
>>>>>>> diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
>>>>>>> index 6feceda757..b473072976 100644
>>>>>>> --- a/include/configs/mvebu_armada-37xx.h
>>>>>>> +++ b/include/configs/mvebu_armada-37xx.h
>>>>>>> @@ -17,6 +17,7 @@
>>>>>>>      #define CONFIG_SYS_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, \
>>>>>>>      					  115200, 230400, 460800, 921600 }
>>>>>>> +#define CONFIG_DEFAULT_CONSOLE "console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000"
>>>>>>>      /*
>>>>>>>       * For booting Linux, the board info and command line data
>>>>>>> @@ -99,6 +100,7 @@
>>>>>>>      	"kernel_addr=0x7000000\0"	\
>>>>>>>      	"kernel_addr_r=0x7000000\0"	\
>>>>>>>      	"ramdisk_addr_r=0x8000000\0"	\
>>>>>>> +	"console=" CONFIG_DEFAULT_CONSOLE "\0" \
>>>>>>>      	BOOTENV
>>>>>>>      #endif /* _CONFIG_MVEBU_ARMADA_37XX_H */
>>>>>>>
>>>>>>
>>>>>> this breaks booting debian with systemd for me:
>>>>>> [    4.632197] systemd-udevd[90]: Starting version 241
>>>>>> [    4.639324] systemd-udevd[91]: Failed to create udev control event
>>>>>> source: Operation not permitted
>>>>>>
>>>>>> "env delete console" and it works again.
>>>>>
>>>>> This is really suspicious. Why systemd has problems with control socket
>>>>> when console= parameter is specified on boot command line? And if
>>>>> console= parameter is problematic on command line, why console output is
>>>>> working fine? For me it looks like this variable controls something
>>>>> different, not (only) console output. Maybe some bootscript sets
>>>>> something more when it see u-boot env ${console} non-empty?
>>>>
>>>> It sounds like a bug in systemd, this may be related:
>>>> https://github.com/systemd/systemd/issues/13332
>>>>
>>>> With ugly workarounds like:
>>>> https://github.com/openembedded/openembedded-core/commit/dd6ee0b06cd8df6204cf600050516d15172302ea
>>>>
>>>> This is easy for to me to work around, but note that this systemd version is
>>>> the one shipping with current debian stable.
>>>
>>> But this looks like to be related to command line 'console=null'.
>>>
>>> Can you check which parameter is causing problem? console=... or
>>> earlycon=... ? Also do you have /dev/ttyMV0 in your system?
>>>
>>
>> yup, it's there:
>> crw--w---- 1 root tty 253, 0 Aug 26 15:09 /dev/ttyMV0
>>
>> But I think it's related to console=null because it ends up as invalid:
>> Your patch sets "console" to "console=...".
> 
> It is doing same thing as other boards in U-Boot, see:
> 
> $ git grep 'define.*CONFIG_DEFAULT_CONSOLE'
> include/configs/arndale.h:#define CONFIG_DEFAULT_CONSOLE                "console=ttySAC2,115200n8\0"
> include/configs/espresso7420.h:#define CONFIG_DEFAULT_CONSOLE   "console=ttySAC1,115200n8\0"
> include/configs/odroid.h:#define CONFIG_DEFAULT_CONSOLE         "console=ttySAC1,115200n8\0"
> include/configs/odroid_xu3.h:#define CONFIG_DEFAULT_CONSOLE             "console=ttySAC2,115200n8\0"
> include/configs/origen.h:#define CONFIG_DEFAULT_CONSOLE         "console=ttySAC1,115200n8\0"
> include/configs/peach-pi.h:#define CONFIG_DEFAULT_CONSOLE       "console=ttySAC1,115200n8\0"
> include/configs/peach-pit.h:#define CONFIG_DEFAULT_CONSOLE      "console=ttySAC1,115200n8\0"
> include/configs/s5p_goni.h:#define CONFIG_DEFAULT_CONSOLE       "console=ttySAC2,115200n8\0"
> include/configs/s5pc210_universal.h:#define CONFIG_DEFAULT_CONSOLE              "console=ttySAC1,115200n8\0"
> include/configs/smdk5250.h:#define CONFIG_DEFAULT_CONSOLE               "console=ttySAC1,115200n8\0"
> include/configs/smdk5420.h:#define CONFIG_DEFAULT_CONSOLE       "console=ttySAC1,115200n8\0"
> include/configs/smdk5420.h:#define CONFIG_DEFAULT_CONSOLE               "console=ttySAC1,115200n8\0"
> include/configs/smdkv310.h:#define CONFIG_DEFAULT_CONSOLE               "console=ttySAC2,115200n8\0"
> include/configs/snow.h:#define CONFIG_DEFAULT_CONSOLE           "console=ttySAC1,115200n8\0"
> include/configs/spring.h:#define CONFIG_DEFAULT_CONSOLE         "console=ttySAC1,115200n8\0"
> include/configs/trats.h:#define CONFIG_DEFAULT_CONSOLE          "console=ttySAC2,115200n8\0"
> include/configs/trats2.h:#define CONFIG_DEFAULT_CONSOLE         "console=ttySAC2,115200n8\0"
> 
> and:
> 
> $ git grep 'CONFIG_DEFAULT_CONSOLE' | grep -v ':#define'
> include/configs/odroid.h:       "console=" CONFIG_DEFAULT_CONSOLE \
> include/configs/odroid_xu3.h:   "console=" CONFIG_DEFAULT_CONSOLE \
> include/configs/s5p_goni.h:     "console=" CONFIG_DEFAULT_CONSOLE \
> include/configs/s5pc210_universal.h:    "console=" CONFIG_DEFAULT_CONSOLE \
> include/configs/trats.h:        "console=" CONFIG_DEFAULT_CONSOLE \
> include/configs/trats2.h:       "console=" CONFIG_DEFAULT_CONSOLE \
> scripts/config_whitelist.txt:CONFIG_DEFAULT_CONSOLE
> 
>> Debian's boot.scr set "bootargs" to "... console=${console}".
>> So we end up with with kernel args "console=console=..." :)
> 
> So then also other U-Boot boards are broken in Debian...
> Where is that Debian's boot.scr file? In which package?

That would be flash-kernel:
https://packages.qa.debian.org/f/flash-kernel.html

bootscript/all/bootscr.uboot-generic:  setenv bootargs "${bootargs} 
console=${console}"
bootscript/arm64/bootscr.uboot-generic:  setenv bootargs "${bootargs} 
console=${console}"
bootscript/armhf/bootscr.cubox:setenv bootargs 
@@LINUX_KERNEL_CMDLINE_DEFAULTS@@ console=${console} 
@@LINUX_KERNEL_CMDLINE@@
bootscript/armhf/bootscr.sunxi:  setenv bootargs "${bootargs} 
console=${console}"
debian/changelog:    - If ${console} is set then add 
"console=${console}" to the bootargs.

The last entry points to:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783074

Which has:
 > I suppose hush doesn't have sufficient power to check for an existing
 > console= in bootargs?
Not that I'm aware of.

So yeah...

Regards,
Andre
> 
> Armbian has 'setenv bootargs "$console ...'
> https://dl.armbian.com/espressobin/u-boot/bootscript/boot.cmd
> 
> OpenWRT has 'setenv bootargs "${bootargs} ${console}"'
> https://github.com/openwrt/openwrt/blob/master/target/linux/mvebu/image/generic-arm64.bootscript
> 
> So it seems that all expects that ${console} env contains 'console=tty...'
> 
>> So we need to strip one "console=", at least for debian's boot scripts:
>> "setenv console ttyMV0,115200 earlycon=ar3700_uart,0xd0012000" and it works
>> again, including earlycon.
>>
>> Regards,
>> Andre

[PATCH 4/5] arm: mvebu: Espressobin: Define console env

[Andre Heider]

On 26/08/2020 17:10, Pali Roh?r wrote:
> On Wednesday 26 August 2020 16:43:10 Andre Heider wrote:
>> On 26/08/2020 16:10, Pali Roh?r wrote:
>>> On Wednesday 26 August 2020 16:00:05 Andre Heider wrote:
>>>> On 26/08/2020 15:31, Pali Roh?r wrote:
>>>>> On Wednesday 26 August 2020 15:22:26 Andre Heider wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 24/08/2020 16:25, Pali Roh?r wrote:
>>>>>>> Some distribution bootscripts append console env into boot cmdline.
>>>>>>> So define console env correctly to have early console access.
>>>>>>>
>>>>>>> Signed-off-by: Pali Roh?r <pali@kernel.org>
>>>>>>> ---
>>>>>>>      include/configs/mvebu_armada-37xx.h | 2 ++
>>>>>>>      1 file changed, 2 insertions(+)
>>>>>>>
>>>>>>> diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
>>>>>>> index 6feceda757..b473072976 100644
>>>>>>> --- a/include/configs/mvebu_armada-37xx.h
>>>>>>> +++ b/include/configs/mvebu_armada-37xx.h
>>>>>>> @@ -17,6 +17,7 @@
>>>>>>>      #define CONFIG_SYS_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, \
>>>>>>>      					  115200, 230400, 460800, 921600 }
>>>>>>> +#define CONFIG_DEFAULT_CONSOLE "console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000"
>>>>>>>      /*
>>>>>>>       * For booting Linux, the board info and command line data
>>>>>>> @@ -99,6 +100,7 @@
>>>>>>>      	"kernel_addr=0x7000000\0"	\
>>>>>>>      	"kernel_addr_r=0x7000000\0"	\
>>>>>>>      	"ramdisk_addr_r=0x8000000\0"	\
>>>>>>> +	"console=" CONFIG_DEFAULT_CONSOLE "\0" \
>>>>>>>      	BOOTENV
>>>>>>>      #endif /* _CONFIG_MVEBU_ARMADA_37XX_H */
>>>>>>>
>>>>>>
>>>>>> this breaks booting debian with systemd for me:
>>>>>> [    4.632197] systemd-udevd[90]: Starting version 241
>>>>>> [    4.639324] systemd-udevd[91]: Failed to create udev control event
>>>>>> source: Operation not permitted
>>>>>>
>>>>>> "env delete console" and it works again.
>>>>>
>>>>> This is really suspicious. Why systemd has problems with control socket
>>>>> when console= parameter is specified on boot command line? And if
>>>>> console= parameter is problematic on command line, why console output is
>>>>> working fine? For me it looks like this variable controls something
>>>>> different, not (only) console output. Maybe some bootscript sets
>>>>> something more when it see u-boot env ${console} non-empty?
>>>>
>>>> It sounds like a bug in systemd, this may be related:
>>>> https://github.com/systemd/systemd/issues/13332
>>>>
>>>> With ugly workarounds like:
>>>> https://github.com/openembedded/openembedded-core/commit/dd6ee0b06cd8df6204cf600050516d15172302ea
>>>>
>>>> This is easy for to me to work around, but note that this systemd version is
>>>> the one shipping with current debian stable.
>>>
>>> But this looks like to be related to command line 'console=null'.
>>>
>>> Can you check which parameter is causing problem? console=... or
>>> earlycon=... ? Also do you have /dev/ttyMV0 in your system?
>>>
>>
>> yup, it's there:
>> crw--w---- 1 root tty 253, 0 Aug 26 15:09 /dev/ttyMV0
>>
>> But I think it's related to console=null because it ends up as invalid:
>> Your patch sets "console" to "console=...".
> 
> It is doing same thing as other boards in U-Boot, see:
> 
> $ git grep 'define.*CONFIG_DEFAULT_CONSOLE'
> include/configs/arndale.h:#define CONFIG_DEFAULT_CONSOLE                "console=ttySAC2,115200n8\0"
> include/configs/espresso7420.h:#define CONFIG_DEFAULT_CONSOLE   "console=ttySAC1,115200n8\0"
> include/configs/odroid.h:#define CONFIG_DEFAULT_CONSOLE         "console=ttySAC1,115200n8\0"
> include/configs/odroid_xu3.h:#define CONFIG_DEFAULT_CONSOLE             "console=ttySAC2,115200n8\0"
> include/configs/origen.h:#define CONFIG_DEFAULT_CONSOLE         "console=ttySAC1,115200n8\0"
> include/configs/peach-pi.h:#define CONFIG_DEFAULT_CONSOLE       "console=ttySAC1,115200n8\0"
> include/configs/peach-pit.h:#define CONFIG_DEFAULT_CONSOLE      "console=ttySAC1,115200n8\0"
> include/configs/s5p_goni.h:#define CONFIG_DEFAULT_CONSOLE       "console=ttySAC2,115200n8\0"
> include/configs/s5pc210_universal.h:#define CONFIG_DEFAULT_CONSOLE              "console=ttySAC1,115200n8\0"
> include/configs/smdk5250.h:#define CONFIG_DEFAULT_CONSOLE               "console=ttySAC1,115200n8\0"
> include/configs/smdk5420.h:#define CONFIG_DEFAULT_CONSOLE       "console=ttySAC1,115200n8\0"
> include/configs/smdk5420.h:#define CONFIG_DEFAULT_CONSOLE               "console=ttySAC1,115200n8\0"
> include/configs/smdkv310.h:#define CONFIG_DEFAULT_CONSOLE               "console=ttySAC2,115200n8\0"
> include/configs/snow.h:#define CONFIG_DEFAULT_CONSOLE           "console=ttySAC1,115200n8\0"
> include/configs/spring.h:#define CONFIG_DEFAULT_CONSOLE         "console=ttySAC1,115200n8\0"
> include/configs/trats.h:#define CONFIG_DEFAULT_CONSOLE          "console=ttySAC2,115200n8\0"
> include/configs/trats2.h:#define CONFIG_DEFAULT_CONSOLE         "console=ttySAC2,115200n8\0"
> 
> and:
> 
> $ git grep 'CONFIG_DEFAULT_CONSOLE' | grep -v ':#define'
> include/configs/odroid.h:       "console=" CONFIG_DEFAULT_CONSOLE \
> include/configs/odroid_xu3.h:   "console=" CONFIG_DEFAULT_CONSOLE \
> include/configs/s5p_goni.h:     "console=" CONFIG_DEFAULT_CONSOLE \
> include/configs/s5pc210_universal.h:    "console=" CONFIG_DEFAULT_CONSOLE \
> include/configs/trats.h:        "console=" CONFIG_DEFAULT_CONSOLE \
> include/configs/trats2.h:       "console=" CONFIG_DEFAULT_CONSOLE \
> scripts/config_whitelist.txt:CONFIG_DEFAULT_CONSOLE

Looking at this again, CONFIG_DEFAULT_CONSOLE with "console=" doesn't 
look like a de facto standard to me:

$ ll include/configs/|wc -l
712

$ git grep CONFIG_DEFAULT_CONSOLE|grep define|wc -l
18

Only 18 out of +700 boards use it, and all of them ttySAC*, so probably 
just copy pasta.
CONFIG_DEFAULT_CONSOLE looks like a leftover, it's not used anywhere 
except in those config headers. Some boards even define it, but don't 
use it, making it effectively dead.

On the other hand, check "git grep 'console='". So why not just add the 
earlycon to bootargs directly so it works everywhere?

Regards,
Andre

[PATCH 4/5] arm: mvebu: Espressobin: Define console env

[Pali Rohár]

On Thursday 27 August 2020 06:51:57 Andre Heider wrote:
> On the other hand, check "git grep 'console='". So why not just add the
> earlycon to bootargs directly so it works everywhere?

The only useful thing about CONFIG_DEFAULT_CONSOLE and ${console} env is
to propagate earlycon argument to kernel. As console kernel argument is
already set via chosen/stdout in DTS.

Setting earlycon directly to ${bootargs} env does not work as basically
all distribution scripts set/overwrite ${bootargs} on their own.

So we need to store earlycon argument into some other uboot env and then
teach these distribution scripts to append that new uboot env into their
bootargs...

Or is there any other way?

[PATCH 4/5] arm: mvebu: Espressobin: Define console env

[Andre Heider]

On 27/08/2020 12:29, Pali Roh?r wrote:
> On Thursday 27 August 2020 06:51:57 Andre Heider wrote:
>> On the other hand, check "git grep 'console='". So why not just add the
>> earlycon to bootargs directly so it works everywhere?
> 
> The only useful thing about CONFIG_DEFAULT_CONSOLE and ${console} env is
> to propagate earlycon argument to kernel. As console kernel argument is
> already set via chosen/stdout in DTS.
> 
> Setting earlycon directly to ${bootargs} env does not work as basically
> all distribution scripts set/overwrite ${bootargs} on their own.
> 
> So we need to store earlycon argument into some other uboot env and then
> teach these distribution scripts to append that new uboot env into their
> bootargs...
> 
> Or is there any other way?

I don't know the answer to that, but as we've seen with $console, it's 
hard to get everyone on the same page.

But maybe it's not worth the hassle, since console works, and earlycon 
may only be interesting to ppl who know how to enable it anyway.

Regards,
Andre

[PATCH 4/5] arm: mvebu: Espressobin: Define console env

[Andre Heider]

On 26/08/2020 17:10, Pali Roh?r wrote:
> On Wednesday 26 August 2020 16:43:10 Andre Heider wrote:

>> Debian's boot.scr set "bootargs" to "... console=${console}".
>> So we end up with with kernel args "console=console=..." :)
> 
> So then also other U-Boot boards are broken in Debian...

fyi: I opened a bug for this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969070

Regards,
Andre

[PATCH 5/5] arm: mvebu: Espressobin: Update README.marvell file

[Pali Rohár]

Include information about permanent ethernet MAC address and add link how
to build ATF as U-Boot on Espressobin cannot be flashed without ATF.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 doc/README.marvell | 40 +++++++++++++++++++++++++++++++++++++---
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/doc/README.marvell b/doc/README.marvell
index 336461745c..da16316407 100644
--- a/doc/README.marvell
+++ b/doc/README.marvell
@@ -13,7 +13,8 @@ Build Procedure
 
 2. Set the cross compiler:
 
-		# export CROSS_COMPILE=/path/to/toolchain/aarch64-marvell-linux-gnu-
+		# sudo apt-get install gcc-aarch64-linux-gnu
+		# export CROSS_COMPILE=aarch64-linux-gnu-
 
 3. Clean-up old residuals:
 
@@ -30,7 +31,7 @@ Build Procedure
 
 5. Configure the device-tree and build the U-Boot image:
 
-	Compile u-boot and set the required device-tree using:
+	For the Armada-70x0/80x0 DB board compile u-boot and set the required device-tree using:
 
 		# make DEVICE_TREE=<name>
 
@@ -42,12 +43,45 @@ Build Procedure
         In order to prevent this, the required device-tree MUST be set during compilation.
         All device-tree files are located in ./arch/arm/dts/ folder.
 
+	For other DB boards (MacchiatoBin, EsspressoBin and 3700 DB board) compile u-boot with
+	just default device-tree from defconfig using:
+
+		# make
+
 	NOTE:
 	The u-boot.bin should not be used as a stand-alone image.
 	The ARM Trusted Firmware (ATF) build process uses this image to generate the
-	flash image.
+	flash image. See TF-A Build Instructions for Marvell Platforms for more details at:
+	https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html
 
 Configuration update
 ---------------------
 	To update the U-Boot configuration, please refer to doc/README.kconfig
 
+
+Permanent ethernet MAC address
+-------------------------------
+	Prior flashing new U-Boot version (as part of ATF image) it is suggested to backup
+	permanent ethernet MAC address as it is stored only in U-Boot env storage (SPI or eMMC).
+	Some boards like EspressoBin have MAC address printed on sticker. To print current MAC
+	address run:
+
+		# echo $ethaddr
+
+	MAC addresses 00:51:82:11:22:00, 00:51:82:11:22:01, 00:51:82:11:22:02, 00:51:82:11:22:03
+	and F0:AD:4E:03:64:7F are default hardcoded values found in Marvell's and Armbian U-Boot
+	forks and therefore *not* unique. Usage of static hardcoded MAC addresses should be avoided.
+	When original address is lost (e.g. erased by Armbian boot scripts for EspressoBin) it is
+	suggested to generate new random one.
+
+	After flashing new U-Boot version it is suggested to reset U-Boot env variables to default
+	and then set correct permanent ethernet MAC address.
+
+		# env default -a
+		# setenv ethaddr XX:XX:XX:XX:XX:XX
+		# saveenv
+
+	Where XX:XX:XX:XX:XX:XX is permanent ethernet MAC address.
+
+	Recent Linux kernel versions use correct permanent ethernet MAC address from U-Boot env as
+	U-Boot will inject it into kernel's device-tree.
-- 
2.20.1

[PATCH 5/5] arm: mvebu: Espressobin: Update README.marvell file

[Stefan Roese]

On 24.08.20 16:25, Pali Roh?r wrote:
> Include information about permanent ethernet MAC address and add link how
> to build ATF as U-Boot on Espressobin cannot be flashed without ATF.
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

[PATCH 1/5] arm: mvebu: Espressobin: Move env load addresses

[Stefan Roese]

On 24.08.20 16:24, Pali Roh?r wrote:
> According to Marvell's U-Boot description [1] current env load addresses
> overlaps with ATF RT services region and TEE. Because the ATF RT service
> and TEE region is going to be marked as secure and can't be overwritten,
> use different different addresses for envs.
> 
> [1] - https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/0a5b159806baa0746b6449920e450498bc269ba7
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

[PATCH 1/5] arm: mvebu: Espressobin: Move env load addresses

[Andre Heider]

Pali,

thank you for all these espressobin fixes, much appreciated!

This isn't directly related to the patch I'm replying to, but since you 
seem to be syncing down- with upstream:

Upstream u-boot doesn't detect my sata ssd ("SATA link 0 timeout"), nor 
is it able to run debian's kernel (hangs after "Starting kernel"). Both 
work with armbian's downstream flash-image.bin.

I'm using the espressobin v1 with these patches from the list on top of 
2020.07:
arm64: a37xx: pci: Depends on DM_GPIO
arm: mvebu: Espressobin: Update README.marvell file
arm: mvebu: Espressobin: Define console env
arm: mvebu: Espressobin: Define fdt_addr and kernel_addr env aliases
arm: mvebu: Espressobin: Change default loadaddr
arm: mvebu: Espressobin: Move env load addresses
arm: mvebu: Espressobin: Setup MTD partitions when booting kernel
arm: mvebu: Espressobin: Make SPI env offset compatible with Marvell's 
U-Boot
arm: dts: a37x0: enable sd card support on espressobin
mmc: xenon: set signal voltage and max base clock
arm64: a37xx: pci: Assert PERST# signal when unloading driver
arm64: a37xx: pci: Make PCIe Reset GPIO DT compatible with Linux kernel DT
arm64: dts: armada-3720-espressobin: fix COMPHY nodes
arm: mvebu: Espressobin: Enable CONFIG_MVNETA
arm: mvebu: Espressobin: Disallow forwarding packets between wan and lan 
ports

Bootlog:

TIM-1.0
WTMI-devel-18.12.1-
WTMI: system early-init
CPU VDD voltage default value: 1.108V
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.3(): (Marvell-devel-18.12.0)
NOTICE:  BL1: Built : 06:12:46, Aug 26 2020
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v2.3(): (Marvell-devel-18.12.0)
NOTICE:  BL2: Built : 06:12:46, Aug 26 2020
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v2.3(): (Marvell-devel-18.12.0)
NOTICE:  BL31: Built : 06:12:46

U-Boot 2020.07 (Aug 26 2020 - 06:12:46 +0000)

DRAM:  1 GiB
Comphy-0: USB3_HOST0    5 Gbps
Comphy-1: PEX0          2.5 Gbps
Comphy-2: SATA0         5 Gbps
SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs
PCIE-0: Link up
MMC:   sdhci at d0000: 0
Loading Environment from SPI Flash... SF: Detected w25q32dw with page 
size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
Model: Marvell Armada 3720 Community Board ESPRESSOBin
Net:   eth0: neta at 30000
Hit any key to stop autoboot:  0
MMC Device 1 not found
no mmc device at slot 1
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
2250 bytes read in 12 ms (182.6 KiB/s)
## Executing script at 06d00000
22079344 bytes read in 1219 ms (17.3 MiB/s)
10671 bytes read in 24 ms (433.6 KiB/s)
27689238 bytes read in 1555 ms (17 MiB/s)
Booting Debian 5.7.0-0.bpo.2-arm64 from mmc 0:1...
## Flattened Device Tree blob at 06f00000
    Booting using the fdt blob at 0x6f00000
    Loading Ramdisk to 3e0be000, end 3fb26116 ... OK
    Loading Device Tree to 000000003e0b8000, end 000000003e0bd9ae ... OK

Starting kernel ...
<hangs here>


Bootlog with armbian's flash-image-ddr3-1g-2cs-800_800.bin:
TIM-1.0
WTMI-devel-18.12.1-e6bb176
WTMI: system early-init
CPU VDD voltage default value: 1.108V
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.5(release):1f8ca7e (Marvell-devel-18.12.2)
NOTICE:  BL1: Built : 16:22:53, May 21 2019
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v1.5(release):1f8ca7e (Marvell-devel-18.12.2)
NOTICE:  BL2: Built : 16:22:55, May 21 2019
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v1.5(release):1f8ca7e (Marvell-devel-18.12.2)
NOTICE:  BL31: Built : 16:22:58

U-Boot 2018.03-devel-18.12.3-gc9aa92c-armbian (Feb 20 2019 - 09:45:04 +0100)

Model: Marvell Armada 3720 Community Board ESPRESSOBin
        CPU     800 [MHz]
        L2      800 [MHz]
        TClock  200 [MHz]
        DDR     800 [MHz]
DRAM:  1 GiB
Comphy chip #0:
Comphy-0: USB3          5 Gbps
Comphy-1: PEX0          2.5 Gbps
Comphy-2: SATA0         6 Gbps
Target spinup took 0 ms.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs
PCIE-0: Link up
MMC:   sdhci at d0000: 0, sdhci at d8000: 1
Loading Environment from SPI Flash... SF: Detected w25q32dw with page 
size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
Model: Marvell Armada 3720 Community Board ESPRESSOBin
Net:   eth0: neta at 30000 [PRIME]
Hit any key to stop autoboot:  0
/
2250 bytes read in 10 ms (219.7 KiB/s)
## Executing script at 06d00000
22079344 bytes read in 1231 ms (17.1 MiB/s)
10671 bytes read in 20 ms (520.5 KiB/s)
27689238 bytes read in 1570 ms (16.8 MiB/s)
Booting Debian 5.7.0-0.bpo.2-arm64 from mmc 0:...
## Flattened Device Tree blob at 06000000
    Booting using the fdt blob at 0x6000000
    Loading Ramdisk to 3dbc2000, end 3f62a116 ... OK
    Using Device Tree in place at 0000000006000000, end 00000000060059ae

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 5.7.0-0.bpo.2-arm64 
(debian-kernel at lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6), 
GNU ld (GNU Binutils for Debian) 2.31.1) #1 SMP Debian 5.7.10-1~bpo10+1 
(2020-07-30)
[    0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board
Any idea?

Thanks in advance!
Andre

Espressobin booting (Was: Re: [PATCH 1/5] arm: mvebu: Espressobin: Move env load addresses)

[Pali Rohár]

Hello!

On Wednesday 26 August 2020 09:30:11 Andre Heider wrote:
> Pali,
> 
> thank you for all these espressobin fixes, much appreciated!
> 
> This isn't directly related to the patch I'm replying to, but since you seem
> to be syncing down- with upstream:
> 
> Upstream u-boot doesn't detect my sata ssd ("SATA link 0 timeout"), nor is

Could you try following Marvell SATA/AHCI patch?
https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/2c1571432e4fd298be0236b53511f415bbdd21ac

> it able to run debian's kernel (hangs after "Starting kernel"). Both work
> with armbian's downstream flash-image.bin.
> 
> I'm using the espressobin v1 with these patches from the list on top of

Do you really have espressobin v1? I saw hw schemas and diagrams only
for V3, V4, V5 and V7. And I tested only V5 as I do not have any other
revisions.

> 2020.07:
> arm64: a37xx: pci: Depends on DM_GPIO
> arm: mvebu: Espressobin: Update README.marvell file
> arm: mvebu: Espressobin: Define console env
> arm: mvebu: Espressobin: Define fdt_addr and kernel_addr env aliases
> arm: mvebu: Espressobin: Change default loadaddr
> arm: mvebu: Espressobin: Move env load addresses
> arm: mvebu: Espressobin: Setup MTD partitions when booting kernel
> arm: mvebu: Espressobin: Make SPI env offset compatible with Marvell's
> U-Boot
> arm: dts: a37x0: enable sd card support on espressobin
> mmc: xenon: set signal voltage and max base clock
> arm64: a37xx: pci: Assert PERST# signal when unloading driver
> arm64: a37xx: pci: Make PCIe Reset GPIO DT compatible with Linux kernel DT
> arm64: dts: armada-3720-espressobin: fix COMPHY nodes
> arm: mvebu: Espressobin: Enable CONFIG_MVNETA
> arm: mvebu: Espressobin: Disallow forwarding packets between wan and lan
> ports
> 
> Bootlog:
> 
> TIM-1.0
> WTMI-devel-18.12.1-
> WTMI: system early-init
> CPU VDD voltage default value: 1.108V
> NOTICE:  Booting Trusted Firmware
> NOTICE:  BL1: v2.3(): (Marvell-devel-18.12.0)
> NOTICE:  BL1: Built : 06:12:46, Aug 26 2020
> NOTICE:  BL1: Booting BL2
> NOTICE:  BL2: v2.3(): (Marvell-devel-18.12.0)
> NOTICE:  BL2: Built : 06:12:46, Aug 26 2020
> NOTICE:  BL1: Booting BL31
> NOTICE:  BL31: v2.3(): (Marvell-devel-18.12.0)
> NOTICE:  BL31: Built : 06:12:46
> 
> U-Boot 2020.07 (Aug 26 2020 - 06:12:46 +0000)
> 
> DRAM:  1 GiB
> Comphy-0: USB3_HOST0    5 Gbps
> Comphy-1: PEX0          2.5 Gbps
> Comphy-2: SATA0         5 Gbps
> SATA link 0 timeout.
> AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
> flags: ncq led only pmp fbss pio slum part sxs
> PCIE-0: Link up
> MMC:   sdhci at d0000: 0
> Loading Environment from SPI Flash... SF: Detected w25q32dw with page size
> 256 Bytes, erase size 4 KiB, total 4 MiB
> OK
> Model: Marvell Armada 3720 Community Board ESPRESSOBin
> Net:   eth0: neta at 30000
> Hit any key to stop autoboot:  0
> MMC Device 1 not found
> no mmc device at slot 1
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> Found U-Boot script /boot.scr
> 2250 bytes read in 12 ms (182.6 KiB/s)
> ## Executing script at 06d00000
> 22079344 bytes read in 1219 ms (17.3 MiB/s)
> 10671 bytes read in 24 ms (433.6 KiB/s)
> 27689238 bytes read in 1555 ms (17 MiB/s)
> Booting Debian 5.7.0-0.bpo.2-arm64 from mmc 0:1...
> ## Flattened Device Tree blob at 06f00000
>    Booting using the fdt blob at 0x6f00000
>    Loading Ramdisk to 3e0be000, end 3fb26116 ... OK
>    Loading Device Tree to 000000003e0b8000, end 000000003e0bd9ae ... OK
> 
> Starting kernel ...
> <hangs here>

Can you write which commands you have run to load & boot kernel?
What are command line arguments for kernel?

Also have you reset env variables to default?

Espressobin booting (Was: Re: [PATCH 1/5] arm: mvebu: Espressobin: Move env load addresses)

[Andre Heider]

Hi,

On 26/08/2020 10:31, Pali Roh?r wrote:
> Hello!
> 
> On Wednesday 26 August 2020 09:30:11 Andre Heider wrote:
>> Pali,
>>
>> thank you for all these espressobin fixes, much appreciated!
>>
>> This isn't directly related to the patch I'm replying to, but since you seem
>> to be syncing down- with upstream:
>>
>> Upstream u-boot doesn't detect my sata ssd ("SATA link 0 timeout"), nor is
> 
> Could you try following Marvell SATA/AHCI patch?
> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/2c1571432e4fd298be0236b53511f415bbdd21ac

will do that later and report my findings, thanks!

>> it able to run debian's kernel (hangs after "Starting kernel"). Both work
>> with armbian's downstream flash-image.bin.
>>
>> I'm using the espressobin v1 with these patches from the list on top of
> 
> Do you really have espressobin v1? I saw hw schemas and diagrams only
> for V3, V4, V5 and V7. And I tested only V5 as I do not have any other
> revisions.

Oh sorry, I meant the first public version, the one with ddr3 memory. 
Which would be the V5 schematics iirc.

>> 2020.07:
>> arm64: a37xx: pci: Depends on DM_GPIO
>> arm: mvebu: Espressobin: Update README.marvell file
>> arm: mvebu: Espressobin: Define console env
>> arm: mvebu: Espressobin: Define fdt_addr and kernel_addr env aliases
>> arm: mvebu: Espressobin: Change default loadaddr
>> arm: mvebu: Espressobin: Move env load addresses
>> arm: mvebu: Espressobin: Setup MTD partitions when booting kernel
>> arm: mvebu: Espressobin: Make SPI env offset compatible with Marvell's
>> U-Boot
>> arm: dts: a37x0: enable sd card support on espressobin
>> mmc: xenon: set signal voltage and max base clock
>> arm64: a37xx: pci: Assert PERST# signal when unloading driver
>> arm64: a37xx: pci: Make PCIe Reset GPIO DT compatible with Linux kernel DT
>> arm64: dts: armada-3720-espressobin: fix COMPHY nodes
>> arm: mvebu: Espressobin: Enable CONFIG_MVNETA
>> arm: mvebu: Espressobin: Disallow forwarding packets between wan and lan
>> ports
>>
>> Bootlog:
>>
>> TIM-1.0
>> WTMI-devel-18.12.1-
>> WTMI: system early-init
>> CPU VDD voltage default value: 1.108V
>> NOTICE:  Booting Trusted Firmware
>> NOTICE:  BL1: v2.3(): (Marvell-devel-18.12.0)
>> NOTICE:  BL1: Built : 06:12:46, Aug 26 2020
>> NOTICE:  BL1: Booting BL2
>> NOTICE:  BL2: v2.3(): (Marvell-devel-18.12.0)
>> NOTICE:  BL2: Built : 06:12:46, Aug 26 2020
>> NOTICE:  BL1: Booting BL31
>> NOTICE:  BL31: v2.3(): (Marvell-devel-18.12.0)
>> NOTICE:  BL31: Built : 06:12:46
>>
>> U-Boot 2020.07 (Aug 26 2020 - 06:12:46 +0000)
>>
>> DRAM:  1 GiB
>> Comphy-0: USB3_HOST0    5 Gbps
>> Comphy-1: PEX0          2.5 Gbps
>> Comphy-2: SATA0         5 Gbps
>> SATA link 0 timeout.
>> AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
>> flags: ncq led only pmp fbss pio slum part sxs
>> PCIE-0: Link up
>> MMC:   sdhci at d0000: 0
>> Loading Environment from SPI Flash... SF: Detected w25q32dw with page size
>> 256 Bytes, erase size 4 KiB, total 4 MiB
>> OK
>> Model: Marvell Armada 3720 Community Board ESPRESSOBin
>> Net:   eth0: neta at 30000
>> Hit any key to stop autoboot:  0
>> MMC Device 1 not found
>> no mmc device at slot 1
>> switch to partitions #0, OK
>> mmc0 is current device
>> Scanning mmc 0:1...
>> Found U-Boot script /boot.scr
>> 2250 bytes read in 12 ms (182.6 KiB/s)
>> ## Executing script at 06d00000
>> 22079344 bytes read in 1219 ms (17.3 MiB/s)
>> 10671 bytes read in 24 ms (433.6 KiB/s)
>> 27689238 bytes read in 1555 ms (17 MiB/s)
>> Booting Debian 5.7.0-0.bpo.2-arm64 from mmc 0:1...
>> ## Flattened Device Tree blob at 06f00000
>>     Booting using the fdt blob at 0x6f00000
>>     Loading Ramdisk to 3e0be000, end 3fb26116 ... OK
>>     Loading Device Tree to 000000003e0b8000, end 000000003e0bd9ae ... OK
>>
>> Starting kernel ...
>> <hangs here>
> 
> Can you write which commands you have run to load & boot kernel?
> What are command line arguments for kernel?
> 
> Also have you reset env variables to default?

Yeah, I do reset the full env when switching between the flash images.

For the upstream version:
env default -a
setenv ethaddr f0:ad:4e:03:86:cd
setenv eth1addr f0:ad:4e:03:86:cd
setenv eth2addr f0:ad:4e:03:86:cd
setenv serverip 192.168.0.40
setenv ipaddr 192.168.0.2
saveenv

For the downstream version:
env default -a
env delete console
setenv fdt_addr_r 0x6000000
setenv kernel_addr_r 0x7000000
setenv ramdisk_addr_r 0x1100000
setenv ethaddr f0:ad:4e:03:86:cd
setenv eth1addr f0:ad:4e:03:86:cd
setenv eth2addr f0:ad:4e:03:86:cd
setenv serverip 192.168.0.40
setenv ipaddr 192.168.0.2
setenv fdt_addr 0x6000000
setenv kernel_addr 0x7000000
setenv loadaddr 0x8000000
setenv initrd_size 0x2000000
setenv initrd_addr 0x1100000
setenv scriptaddr 0x6d00000
setenv initrd_image uInitrd
setenv image_name Image
setenv boot_targets 'mmc0 usb sata mmc1'
setenv boot_prefixes '/ /boot/'
setenv bootcmd_mmc0 'setenv devnum 0; setenv devtype mmc; run 
scan_dev_for_boot;'
setenv bootcmd_mmc1 'setenv devnum 1; setenv devtype mmc; run 
scan_dev_for_boot;'
setenv bootcmd_sata 'setenv devnum 0; scsi scan; scsi dev 0; setenv 
devtype scsi; run scan_dev_for_boot;'
setenv bootcmd_usb 'setenv devnum 0; usb start;setenv devtype usb; run 
scan_dev_for_boot;'
setenv bootcmd 'for target in ${boot_targets}; do run bootcmd_${target}; 
done'
setenv scan_dev_for_boot 'for prefix in ${boot_prefixes}; do echo 
${prefix};run boot_a_script; done'
setenv boot_a_script 'ext4load ${devtype} ${devnum}:1 ${scriptaddr} 
${prefix}boot.scr;source ${scriptaddr};'
saveenv

Debian's boot.scr relies on u-boot's distro boot. Downstream still fails 
to enable it (even managed to break my patch to enable it...), so most 
of my env is to make it compatible again so I can use an unmodified 
userland.

Debian's script is rather boring then:

$ strings /boot/boot.scr
boot script
# flash-kernel: bootscr.uboot-generic
# Bootscript using the new unified bootcmd handling
# Expects to be called with the following environment variables set:
#  devtype              e.g. mmc/scsi etc
#  devnum               The device number of the given type
#  bootpart             The partition containing the boot files
#  distro_bootpart      The partition containing the boot files
#                       (introduced in u-boot mainline 2016.01)
#  prefix               Prefix within the boot partiion to the boot files
#  kernel_addr_r        Address to load the kernel to
#  fdt_addr_r           Address to load the FDT to
#  ramdisk_addr_r       Address to load the initrd to.
# The uboot must support the booti and generic filesystem load commands.
if test -n "${console}"; then
   setenv bootargs "${bootargs} console=${console}"
setenv bootargs  ${bootargs} root=LABEL=espresso-root
if test -z "${fk_kvers}"; then
    setenv fk_kvers '5.7.0-0.bpo.2-arm64'
# These two blocks should be the same apart from the use of
# ${fk_kvers} in the first, the syntax supported by u-boot does not
# lend itself to removing this duplication.
if test -n "${fdtfile}"; then
    setenv fdtpath dtbs/${fk_kvers}/${fdtfile}
else
    setenv fdtpath dtb-${fk_kvers}
if test -z "${distro_bootpart}"; then
   setenv partition ${bootpart}
else
   setenv partition ${distro_bootpart}
load ${devtype} ${devnum}:${partition} ${kernel_addr_r} 
${prefix}vmlinuz-${fk_kvers} \
&& load ${devtype} ${devnum}:${partition} ${fdt_addr_r} 
${prefix}${fdtpath} \
&& load ${devtype} ${devnum}:${partition} ${ramdisk_addr_r} 
${prefix}initrd.img-${fk_kvers} \
&& echo "Booting Debian ${fk_kvers} from ${devtype} 
${devnum}:${partition}..." \
&& booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
load ${devtype} ${devnum}:${partition} ${kernel_addr_r} ${prefix}vmlinuz \
&& load ${devtype} ${devnum}:${partition} ${fdt_addr_r} ${prefix}dtb \
&& load ${devtype} ${devnum}:${partition} ${ramdisk_addr_r} 
${prefix}initrd.img \
&& echo "Booting Debian from ${devtype} ${devnum}:${partition}..." \
&& booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

Regards,
Andre

Espressobin booting (Was: Re: [PATCH 1/5] arm: mvebu: Espressobin: Move env load addresses)

[Pali Rohár]

On Wednesday 26 August 2020 11:57:01 Andre Heider wrote:
> Hi,
> 
> On 26/08/2020 10:31, Pali Roh?r wrote:
> > Hello!
> > 
> > On Wednesday 26 August 2020 09:30:11 Andre Heider wrote:
> > > Pali,
> > > 
> > > thank you for all these espressobin fixes, much appreciated!
> > > 
> > > This isn't directly related to the patch I'm replying to, but since you seem
> > > to be syncing down- with upstream:
> > > 
> > > Upstream u-boot doesn't detect my sata ssd ("SATA link 0 timeout"), nor is
> > 
> > Could you try following Marvell SATA/AHCI patch?
> > https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/2c1571432e4fd298be0236b53511f415bbdd21ac
> 
> will do that later and report my findings, thanks!
> 
> > > it able to run debian's kernel (hangs after "Starting kernel"). Both work
> > > with armbian's downstream flash-image.bin.
> > > 
> > > I'm using the espressobin v1 with these patches from the list on top of
> > 
> > Do you really have espressobin v1? I saw hw schemas and diagrams only
> > for V3, V4, V5 and V7. And I tested only V5 as I do not have any other
> > revisions.
> 
> Oh sorry, I meant the first public version, the one with ddr3 memory. Which
> would be the V5 schematics iirc.
> 
> > > 2020.07:
> > > arm64: a37xx: pci: Depends on DM_GPIO
> > > arm: mvebu: Espressobin: Update README.marvell file
> > > arm: mvebu: Espressobin: Define console env
> > > arm: mvebu: Espressobin: Define fdt_addr and kernel_addr env aliases
> > > arm: mvebu: Espressobin: Change default loadaddr
> > > arm: mvebu: Espressobin: Move env load addresses
> > > arm: mvebu: Espressobin: Setup MTD partitions when booting kernel
> > > arm: mvebu: Espressobin: Make SPI env offset compatible with Marvell's
> > > U-Boot
> > > arm: dts: a37x0: enable sd card support on espressobin
> > > mmc: xenon: set signal voltage and max base clock
> > > arm64: a37xx: pci: Assert PERST# signal when unloading driver
> > > arm64: a37xx: pci: Make PCIe Reset GPIO DT compatible with Linux kernel DT
> > > arm64: dts: armada-3720-espressobin: fix COMPHY nodes
> > > arm: mvebu: Espressobin: Enable CONFIG_MVNETA
> > > arm: mvebu: Espressobin: Disallow forwarding packets between wan and lan
> > > ports
> > > 
> > > Bootlog:
> > > 
> > > TIM-1.0
> > > WTMI-devel-18.12.1-
> > > WTMI: system early-init
> > > CPU VDD voltage default value: 1.108V
> > > NOTICE:  Booting Trusted Firmware
> > > NOTICE:  BL1: v2.3(): (Marvell-devel-18.12.0)
> > > NOTICE:  BL1: Built : 06:12:46, Aug 26 2020
> > > NOTICE:  BL1: Booting BL2
> > > NOTICE:  BL2: v2.3(): (Marvell-devel-18.12.0)
> > > NOTICE:  BL2: Built : 06:12:46, Aug 26 2020
> > > NOTICE:  BL1: Booting BL31
> > > NOTICE:  BL31: v2.3(): (Marvell-devel-18.12.0)
> > > NOTICE:  BL31: Built : 06:12:46
> > > 
> > > U-Boot 2020.07 (Aug 26 2020 - 06:12:46 +0000)
> > > 
> > > DRAM:  1 GiB
> > > Comphy-0: USB3_HOST0    5 Gbps
> > > Comphy-1: PEX0          2.5 Gbps
> > > Comphy-2: SATA0         5 Gbps
> > > SATA link 0 timeout.
> > > AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
> > > flags: ncq led only pmp fbss pio slum part sxs
> > > PCIE-0: Link up
> > > MMC:   sdhci at d0000: 0
> > > Loading Environment from SPI Flash... SF: Detected w25q32dw with page size
> > > 256 Bytes, erase size 4 KiB, total 4 MiB
> > > OK
> > > Model: Marvell Armada 3720 Community Board ESPRESSOBin
> > > Net:   eth0: neta at 30000
> > > Hit any key to stop autoboot:  0
> > > MMC Device 1 not found
> > > no mmc device at slot 1
> > > switch to partitions #0, OK
> > > mmc0 is current device
> > > Scanning mmc 0:1...
> > > Found U-Boot script /boot.scr
> > > 2250 bytes read in 12 ms (182.6 KiB/s)
> > > ## Executing script at 06d00000
> > > 22079344 bytes read in 1219 ms (17.3 MiB/s)
> > > 10671 bytes read in 24 ms (433.6 KiB/s)
> > > 27689238 bytes read in 1555 ms (17 MiB/s)
> > > Booting Debian 5.7.0-0.bpo.2-arm64 from mmc 0:1...
> > > ## Flattened Device Tree blob at 06f00000
> > >     Booting using the fdt blob at 0x6f00000
> > >     Loading Ramdisk to 3e0be000, end 3fb26116 ... OK
> > >     Loading Device Tree to 000000003e0b8000, end 000000003e0bd9ae ... OK
> > > 
> > > Starting kernel ...
> > > <hangs here>
> > 
> > Can you write which commands you have run to load & boot kernel?
> > What are command line arguments for kernel?
> > 
> > Also have you reset env variables to default?
> 
> Yeah, I do reset the full env when switching between the flash images.

Now I tried to boot openwrt kernel image and it is working fine on
tested espressobin v5 unit. I compiled u-boot with all those a37xx
patches.

DRAM:  512 MiB
Comphy-0: USB3_HOST0    5 Gbps    
Comphy-1: PEX0          2.5 Gbps  
Comphy-2: SATA0         5 Gbps    
SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs 
PCIE-0: Link up
MMC:   sdhci at d0000: 0
Loading Environment from SPIFlash... SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
Model: Marvell Armada 3720 Community Board ESPRESSOBin
Net:   eth0: neta at 30000 [PRIME]
Hit any key to stop autoboot:  0 
=> env default -a
## Resetting to default environment
=> setenv bootargs "root=PARTUUID=aefd80c5-02 rw rootwait"
=> setenv bootargs "${bootargs} ${console}"
=> mmc dev 0
switch to partitions #0, OK
mmc0 is current device
=> load mmc 0:1 ${fdt_addr} armada-3720-espressobin.dtb
10630 bytes read in 11 ms (943.4 KiB/s)
=> load mmc 0:1 ${kernel_addr} Image
10197000 bytes read in 436 ms (22.3 MiB/s)
=> booti ${kernel_addr} - ${fdt_addr}
Moving Image from 0x7000000 to 0x7080000, end=7a82000
## Flattened Device Tree blob at 06f00000
   Booting using the fdt blob at 0x6f00000
   Loading Device Tree to 000000001fb20000, end 000000001fb25985 ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 5.4.59 (builder at buildhost) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r14241-ba2ddba56b)) #0 SMP Mon Aug 24 00:09:30 2020
[    0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board
[    0.000000] earlycon: ar3700_uart0 at MMIO 0x00000000d0012000 (options '')
[    0.000000] printk: bootconsole [ar3700_uart0] enabled
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: MIGRATE_INFO_TYPE not supported.
[    0.000000] psci: SMC Calling Convention v1.1
[    0.000000] percpu: Embedded 16 pages/cpu s26520 r8192 d30824 u65536
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: GIC system register CPU interface
[    0.000000] Speculative Store Bypass Disable mitigation not required
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 128512
[    0.000000] Kernel command line: root=PARTUUID=aefd80c5-02 rw rootwait console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000
...

Espressobin booting (Was: Re: [PATCH 1/5] arm: mvebu: Espressobin: Move env load addresses)

[Pali Rohár]

On Wednesday 26 August 2020 12:51:18 Pali Roh?r wrote:
> On Wednesday 26 August 2020 11:57:01 Andre Heider wrote:
> > Hi,
> > 
> > On 26/08/2020 10:31, Pali Roh?r wrote:
> > > Hello!
> > > 
> > > On Wednesday 26 August 2020 09:30:11 Andre Heider wrote:
> > > > Pali,
> > > > 
> > > > thank you for all these espressobin fixes, much appreciated!
> > > > 
> > > > This isn't directly related to the patch I'm replying to, but since you seem
> > > > to be syncing down- with upstream:
> > > > 
> > > > Upstream u-boot doesn't detect my sata ssd ("SATA link 0 timeout"), nor is
> > > 
> > > Could you try following Marvell SATA/AHCI patch?
> > > https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/2c1571432e4fd298be0236b53511f415bbdd21ac
> > 
> > will do that later and report my findings, thanks!
> > 
> > > > it able to run debian's kernel (hangs after "Starting kernel"). Both work
> > > > with armbian's downstream flash-image.bin.
> > > > 
> > > > I'm using the espressobin v1 with these patches from the list on top of
> > > 
> > > Do you really have espressobin v1? I saw hw schemas and diagrams only
> > > for V3, V4, V5 and V7. And I tested only V5 as I do not have any other
> > > revisions.
> > 
> > Oh sorry, I meant the first public version, the one with ddr3 memory. Which
> > would be the V5 schematics iirc.
> > 
> > > > 2020.07:
> > > > arm64: a37xx: pci: Depends on DM_GPIO
> > > > arm: mvebu: Espressobin: Update README.marvell file
> > > > arm: mvebu: Espressobin: Define console env
> > > > arm: mvebu: Espressobin: Define fdt_addr and kernel_addr env aliases
> > > > arm: mvebu: Espressobin: Change default loadaddr
> > > > arm: mvebu: Espressobin: Move env load addresses
> > > > arm: mvebu: Espressobin: Setup MTD partitions when booting kernel
> > > > arm: mvebu: Espressobin: Make SPI env offset compatible with Marvell's
> > > > U-Boot
> > > > arm: dts: a37x0: enable sd card support on espressobin
> > > > mmc: xenon: set signal voltage and max base clock
> > > > arm64: a37xx: pci: Assert PERST# signal when unloading driver
> > > > arm64: a37xx: pci: Make PCIe Reset GPIO DT compatible with Linux kernel DT
> > > > arm64: dts: armada-3720-espressobin: fix COMPHY nodes
> > > > arm: mvebu: Espressobin: Enable CONFIG_MVNETA
> > > > arm: mvebu: Espressobin: Disallow forwarding packets between wan and lan
> > > > ports
> > > > 
> > > > Bootlog:
> > > > 
> > > > TIM-1.0
> > > > WTMI-devel-18.12.1-
> > > > WTMI: system early-init
> > > > CPU VDD voltage default value: 1.108V
> > > > NOTICE:  Booting Trusted Firmware
> > > > NOTICE:  BL1: v2.3(): (Marvell-devel-18.12.0)
> > > > NOTICE:  BL1: Built : 06:12:46, Aug 26 2020
> > > > NOTICE:  BL1: Booting BL2
> > > > NOTICE:  BL2: v2.3(): (Marvell-devel-18.12.0)
> > > > NOTICE:  BL2: Built : 06:12:46, Aug 26 2020
> > > > NOTICE:  BL1: Booting BL31
> > > > NOTICE:  BL31: v2.3(): (Marvell-devel-18.12.0)
> > > > NOTICE:  BL31: Built : 06:12:46
> > > > 
> > > > U-Boot 2020.07 (Aug 26 2020 - 06:12:46 +0000)
> > > > 
> > > > DRAM:  1 GiB
> > > > Comphy-0: USB3_HOST0    5 Gbps
> > > > Comphy-1: PEX0          2.5 Gbps
> > > > Comphy-2: SATA0         5 Gbps
> > > > SATA link 0 timeout.
> > > > AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
> > > > flags: ncq led only pmp fbss pio slum part sxs
> > > > PCIE-0: Link up
> > > > MMC:   sdhci at d0000: 0
> > > > Loading Environment from SPI Flash... SF: Detected w25q32dw with page size
> > > > 256 Bytes, erase size 4 KiB, total 4 MiB
> > > > OK
> > > > Model: Marvell Armada 3720 Community Board ESPRESSOBin
> > > > Net:   eth0: neta at 30000
> > > > Hit any key to stop autoboot:  0
> > > > MMC Device 1 not found
> > > > no mmc device at slot 1
> > > > switch to partitions #0, OK
> > > > mmc0 is current device
> > > > Scanning mmc 0:1...
> > > > Found U-Boot script /boot.scr
> > > > 2250 bytes read in 12 ms (182.6 KiB/s)
> > > > ## Executing script at 06d00000
> > > > 22079344 bytes read in 1219 ms (17.3 MiB/s)
> > > > 10671 bytes read in 24 ms (433.6 KiB/s)
> > > > 27689238 bytes read in 1555 ms (17 MiB/s)
> > > > Booting Debian 5.7.0-0.bpo.2-arm64 from mmc 0:1...
> > > > ## Flattened Device Tree blob at 06f00000
> > > >     Booting using the fdt blob at 0x6f00000
> > > >     Loading Ramdisk to 3e0be000, end 3fb26116 ... OK
> > > >     Loading Device Tree to 000000003e0b8000, end 000000003e0bd9ae ... OK
> > > > 
> > > > Starting kernel ...
> > > > <hangs here>
> > > 
> > > Can you write which commands you have run to load & boot kernel?
> > > What are command line arguments for kernel?
> > > 
> > > Also have you reset env variables to default?
> > 
> > Yeah, I do reset the full env when switching between the flash images.
> 
> Now I tried to boot openwrt kernel image and it is working fine on
> tested espressobin v5 unit. I compiled u-boot with all those a37xx
> patches.

I looked at Debian and booting Debian kernel with Debian initrd failed:

=> booti ${kernel_addr_r} ${ramdisk_addr_r}:{filesize} ${fdt_addr_r}
Moving Image from 0x7000000 to 0x7080000, end=82f2000
ERROR: RD image overlaps OS image (OS=0x7080000..0x82f2000)

Debian's kernel is big, so it is needed to move also ramdisk_addr_r env
variable. Following patch helped:

diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
index 6f72a13301..8929fcf390 100644
--- a/include/configs/mvebu_armada-37xx.h
+++ b/include/configs/mvebu_armada-37xx.h
@@ -99,7 +99,7 @@
 	"fdt_addr_r=0x6f00000\0"	\
 	"kernel_addr=0x7000000\0"	\
 	"kernel_addr_r=0x7000000\0"	\
-	"ramdisk_addr_r=0x8000000\0"	\
+	"ramdisk_addr_r=0xa000000\0"	\
 	"console=" CONFIG_DEFAULT_CONSOLE "\0" \
 	BOOTENV
 

And after that Debian kernel with Debian initrd and FDT was booted:

DRAM:  512 MiB
Comphy-0: USB3_HOST0    5 Gbps    
Comphy-1: PEX0          2.5 Gbps  
Comphy-2: SATA0         5 Gbps    
SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs 
PCIE-0: Link up
MMC:   sdhci at d0000: 0
Loading Environment from SPIFlash... SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
Model: Marvell Armada 3720 Community Board ESPRESSOBin
Net:   eth0: neta at 30000 [PRIME]
Hit any key to stop autoboot:  0 
=> env default -a
## Resetting to default environment
=> mmc dev 0
switch to partitions #0, OK
mmc0 is current device
=> load mmc 0:2 ${fdt_addr_r} debian/armada-3720-espressobin.dtb
10553 bytes read in 17 ms (605.5 KiB/s)
=> load mmc 0:2 ${kernel_addr_r} debian/vmlinuz-4.19.0-10-arm64
18759536 bytes read in 804 ms (22.3 MiB/s)
=> load mmc 0:2 ${ramdisk_addr_r} debian/initrd.img-4.19.0-10-arm64
23890636 bytes read in 1013 ms (22.5 MiB/s)
=> setenv bootargs "$console root=/dev/mmcblk0p2 ro rootwait net.ifnames=0 biosdevname=0"
=> echo $bootargs
console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/mmcblk0p2 ro rootwait net.ifnames=0 biosdevname=0
=> echo ${filesize}
16c8acc
=> booti ${kernel_addr_r} ${ramdisk_addr_r}:{filesize} ${fdt_addr_r}
Moving Image from 0x7000000 to 0x7080000, end=82f2000
## Flattened Device Tree blob at 06f00000
   Booting using the fdt blob at 0x6f00000
   Loading Ramdisk to 20000000, end 20000000 ... OK
   Loading Device Tree to 000000001f620000, end 000000001f625938 ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 4.19.0-10-arm64 (debian-kernel at lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.132-1 (2020-07-24)
[    0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board
[    0.000000] earlycon: ar3700_uart0 at MMIO 0x00000000d0012000 (options '')
[    0.000000] bootconsole [ar3700_uart0] enabled
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: UEFI not found.
[    0.000000] cma: Reserved 64 MiB at 0x000000001b400000
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x000000001fffffff]
[    0.000000] NUMA: NODE_DATA [mem 0x1ffe6600-0x1ffe7dbf]
[    0.000000] Zone ranges:
[    0.000000]   DMA32    [mem 0x0000000000000000-0x000000001fffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x0000000003ffffff]
[    0.000000]   node   0: [mem 0x0000000004200000-0x000000001fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001fffffff]
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: MIGRATE_INFO_TYPE not supported.
[    0.000000] psci: SMC Calling Convention v1.1
[    0.000000] random: get_random_bytes called from start_kernel+0x9c/0x4c0 with crng_init=0
[    0.000000] percpu: Embedded 25 pages/cpu s61976 r8192 d32232 u102400
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: enabling workaround for ARM erratum 845719
[    0.000000] Speculative Store Bypass Disable mitigation not required
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 128512
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/mmcblk0p2 ro rootwait net.ifnames=0 biosdevname=0
...

Espressobin booting (Was: Re: [PATCH 1/5] arm: mvebu: Espressobin: Move env load addresses)

[Andre Heider]

Hi,

On 26/08/2020 13:40, Pali Roh?r wrote:
> On Wednesday 26 August 2020 12:51:18 Pali Roh?r wrote:
>> On Wednesday 26 August 2020 11:57:01 Andre Heider wrote:
>>> Hi,
>>>
>>> On 26/08/2020 10:31, Pali Roh?r wrote:
>>>> Hello!
>>>>
>>>> On Wednesday 26 August 2020 09:30:11 Andre Heider wrote:
>>>>> Pali,
>>>>>
>>>>> thank you for all these espressobin fixes, much appreciated!
>>>>>
>>>>> This isn't directly related to the patch I'm replying to, but since you seem
>>>>> to be syncing down- with upstream:
>>>>>
>>>>> Upstream u-boot doesn't detect my sata ssd ("SATA link 0 timeout"), nor is
>>>>
>>>> Could you try following Marvell SATA/AHCI patch?
>>>> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/2c1571432e4fd298be0236b53511f415bbdd21ac
>>>
>>> will do that later and report my findings, thanks!

That one didn't help unfortunately. u-boot still prints "SATA link 0 
timeout". Booting kernel 5.7.0-0.bpo.2-arm64 with that and sata works, 
but booting 4.19.0-10-arm64 and it doesn't: "ata1: SATA link down 
(SStatus 131 SControl 300)" is printed all over again.

>>>
>>>>> it able to run debian's kernel (hangs after "Starting kernel"). Both work
>>>>> with armbian's downstream flash-image.bin.
>>>>>
>>>>> I'm using the espressobin v1 with these patches from the list on top of
>>>>
>>>> Do you really have espressobin v1? I saw hw schemas and diagrams only
>>>> for V3, V4, V5 and V7. And I tested only V5 as I do not have any other
>>>> revisions.
>>>
>>> Oh sorry, I meant the first public version, the one with ddr3 memory. Which
>>> would be the V5 schematics iirc.
>>>
>>>>> 2020.07:
>>>>> arm64: a37xx: pci: Depends on DM_GPIO
>>>>> arm: mvebu: Espressobin: Update README.marvell file
>>>>> arm: mvebu: Espressobin: Define console env
>>>>> arm: mvebu: Espressobin: Define fdt_addr and kernel_addr env aliases
>>>>> arm: mvebu: Espressobin: Change default loadaddr
>>>>> arm: mvebu: Espressobin: Move env load addresses
>>>>> arm: mvebu: Espressobin: Setup MTD partitions when booting kernel
>>>>> arm: mvebu: Espressobin: Make SPI env offset compatible with Marvell's
>>>>> U-Boot
>>>>> arm: dts: a37x0: enable sd card support on espressobin
>>>>> mmc: xenon: set signal voltage and max base clock
>>>>> arm64: a37xx: pci: Assert PERST# signal when unloading driver
>>>>> arm64: a37xx: pci: Make PCIe Reset GPIO DT compatible with Linux kernel DT
>>>>> arm64: dts: armada-3720-espressobin: fix COMPHY nodes
>>>>> arm: mvebu: Espressobin: Enable CONFIG_MVNETA
>>>>> arm: mvebu: Espressobin: Disallow forwarding packets between wan and lan
>>>>> ports
>>>>>
>>>>> Bootlog:
>>>>>
>>>>> TIM-1.0
>>>>> WTMI-devel-18.12.1-
>>>>> WTMI: system early-init
>>>>> CPU VDD voltage default value: 1.108V
>>>>> NOTICE:  Booting Trusted Firmware
>>>>> NOTICE:  BL1: v2.3(): (Marvell-devel-18.12.0)
>>>>> NOTICE:  BL1: Built : 06:12:46, Aug 26 2020
>>>>> NOTICE:  BL1: Booting BL2
>>>>> NOTICE:  BL2: v2.3(): (Marvell-devel-18.12.0)
>>>>> NOTICE:  BL2: Built : 06:12:46, Aug 26 2020
>>>>> NOTICE:  BL1: Booting BL31
>>>>> NOTICE:  BL31: v2.3(): (Marvell-devel-18.12.0)
>>>>> NOTICE:  BL31: Built : 06:12:46
>>>>>
>>>>> U-Boot 2020.07 (Aug 26 2020 - 06:12:46 +0000)
>>>>>
>>>>> DRAM:  1 GiB
>>>>> Comphy-0: USB3_HOST0    5 Gbps
>>>>> Comphy-1: PEX0          2.5 Gbps
>>>>> Comphy-2: SATA0         5 Gbps
>>>>> SATA link 0 timeout.
>>>>> AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
>>>>> flags: ncq led only pmp fbss pio slum part sxs
>>>>> PCIE-0: Link up
>>>>> MMC:   sdhci at d0000: 0
>>>>> Loading Environment from SPI Flash... SF: Detected w25q32dw with page size
>>>>> 256 Bytes, erase size 4 KiB, total 4 MiB
>>>>> OK
>>>>> Model: Marvell Armada 3720 Community Board ESPRESSOBin
>>>>> Net:   eth0: neta at 30000
>>>>> Hit any key to stop autoboot:  0
>>>>> MMC Device 1 not found
>>>>> no mmc device at slot 1
>>>>> switch to partitions #0, OK
>>>>> mmc0 is current device
>>>>> Scanning mmc 0:1...
>>>>> Found U-Boot script /boot.scr
>>>>> 2250 bytes read in 12 ms (182.6 KiB/s)
>>>>> ## Executing script at 06d00000
>>>>> 22079344 bytes read in 1219 ms (17.3 MiB/s)
>>>>> 10671 bytes read in 24 ms (433.6 KiB/s)
>>>>> 27689238 bytes read in 1555 ms (17 MiB/s)
>>>>> Booting Debian 5.7.0-0.bpo.2-arm64 from mmc 0:1...
>>>>> ## Flattened Device Tree blob at 06f00000
>>>>>      Booting using the fdt blob at 0x6f00000
>>>>>      Loading Ramdisk to 3e0be000, end 3fb26116 ... OK
>>>>>      Loading Device Tree to 000000003e0b8000, end 000000003e0bd9ae ... OK
>>>>>
>>>>> Starting kernel ...
>>>>> <hangs here>
>>>>
>>>> Can you write which commands you have run to load & boot kernel?
>>>> What are command line arguments for kernel?
>>>>
>>>> Also have you reset env variables to default?
>>>
>>> Yeah, I do reset the full env when switching between the flash images.
>>
>> Now I tried to boot openwrt kernel image and it is working fine on
>> tested espressobin v5 unit. I compiled u-boot with all those a37xx
>> patches.
> 
> I looked at Debian and booting Debian kernel with Debian initrd failed:
> 
> => booti ${kernel_addr_r} ${ramdisk_addr_r}:{filesize} ${fdt_addr_r}
> Moving Image from 0x7000000 to 0x7080000, end=82f2000
> ERROR: RD image overlaps OS image (OS=0x7080000..0x82f2000)
> 
> Debian's kernel is big, so it is needed to move also ramdisk_addr_r env
> variable. Following patch helped:
> 
> diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
> index 6f72a13301..8929fcf390 100644
> --- a/include/configs/mvebu_armada-37xx.h
> +++ b/include/configs/mvebu_armada-37xx.h
> @@ -99,7 +99,7 @@
>   	"fdt_addr_r=0x6f00000\0"	\
>   	"kernel_addr=0x7000000\0"	\
>   	"kernel_addr_r=0x7000000\0"	\
> -	"ramdisk_addr_r=0x8000000\0"	\
> +	"ramdisk_addr_r=0xa000000\0"	\
>   	"console=" CONFIG_DEFAULT_CONSOLE "\0" \
>   	BOOTENV
>   
> 
> And after that Debian kernel with Debian initrd and FDT was booted:

Heh, nice. That indeed works!

Well minus one thing, see my reply to "arm: mvebu: Espressobin: Define 
console env".

Thanks,
Andre

Espressobin booting (Was: Re: [PATCH 1/5] arm: mvebu: Espressobin: Move env load addresses)

[Pali Rohár]

On Wednesday 26 August 2020 15:22:37 Andre Heider wrote:
> Hi,
> 
> On 26/08/2020 13:40, Pali Roh?r wrote:
> > On Wednesday 26 August 2020 12:51:18 Pali Roh?r wrote:
> > > On Wednesday 26 August 2020 11:57:01 Andre Heider wrote:
> > > > Hi,
> > > > 
> > > > On 26/08/2020 10:31, Pali Roh?r wrote:
> > > > > Hello!
> > > > > 
> > > > > On Wednesday 26 August 2020 09:30:11 Andre Heider wrote:
> > > > > > Pali,
> > > > > > 
> > > > > > thank you for all these espressobin fixes, much appreciated!
> > > > > > 
> > > > > > This isn't directly related to the patch I'm replying to, but since you seem
> > > > > > to be syncing down- with upstream:
> > > > > > 
> > > > > > Upstream u-boot doesn't detect my sata ssd ("SATA link 0 timeout"), nor is
> > > > > 
> > > > > Could you try following Marvell SATA/AHCI patch?
> > > > > https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/2c1571432e4fd298be0236b53511f415bbdd21ac
> > > > 
> > > > will do that later and report my findings, thanks!
> 
> That one didn't help unfortunately. u-boot still prints "SATA link 0
> timeout". Booting kernel 5.7.0-0.bpo.2-arm64 with that and sata works, but
> booting 4.19.0-10-arm64 and it doesn't: "ata1: SATA link down (SStatus 131
> SControl 300)" is printed all over again.

I guess it was broken also prior applying all those patches. So for now
I do not have any fix for this. Somebody else would need to look at it.

> > I looked at Debian and booting Debian kernel with Debian initrd failed:
> > 
> > => booti ${kernel_addr_r} ${ramdisk_addr_r}:{filesize} ${fdt_addr_r}
> > Moving Image from 0x7000000 to 0x7080000, end=82f2000
> > ERROR: RD image overlaps OS image (OS=0x7080000..0x82f2000)
> > 
> > Debian's kernel is big, so it is needed to move also ramdisk_addr_r env
> > variable. Following patch helped:
> > 
> > diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
> > index 6f72a13301..8929fcf390 100644
> > --- a/include/configs/mvebu_armada-37xx.h
> > +++ b/include/configs/mvebu_armada-37xx.h
> > @@ -99,7 +99,7 @@
> >   	"fdt_addr_r=0x6f00000\0"	\
> >   	"kernel_addr=0x7000000\0"	\
> >   	"kernel_addr_r=0x7000000\0"	\
> > -	"ramdisk_addr_r=0x8000000\0"	\
> > +	"ramdisk_addr_r=0xa000000\0"	\
> >   	"console=" CONFIG_DEFAULT_CONSOLE "\0" \
> >   	BOOTENV
> > 
> > And after that Debian kernel with Debian initrd and FDT was booted:
> 
> Heh, nice. That indeed works!

Ok, I have sent a new version V2 of this patch series and updated first
patch which fix also ramdisk_addr_r.

> Well minus one thing, see my reply to "arm: mvebu: Espressobin: Define
> console env".

For now I have dropped this patch for V2, until it is solved/fixed in
some way.

Espressobin booting (Was: Re: [PATCH 1/5] arm: mvebu: Espressobin: Move env load addresses)

[Pali Rohár]

On Wednesday 26 August 2020 15:22:37 Andre Heider wrote:
> Hi,
> 
> On 26/08/2020 13:40, Pali Roh?r wrote:
> > On Wednesday 26 August 2020 12:51:18 Pali Roh?r wrote:
> > > On Wednesday 26 August 2020 11:57:01 Andre Heider wrote:
> > > > Hi,
> > > > 
> > > > On 26/08/2020 10:31, Pali Roh?r wrote:
> > > > > Hello!
> > > > > 
> > > > > On Wednesday 26 August 2020 09:30:11 Andre Heider wrote:
> > > > > > Pali,
> > > > > > 
> > > > > > thank you for all these espressobin fixes, much appreciated!
> > > > > > 
> > > > > > This isn't directly related to the patch I'm replying to, but since you seem
> > > > > > to be syncing down- with upstream:
> > > > > > 
> > > > > > Upstream u-boot doesn't detect my sata ssd ("SATA link 0 timeout"), nor is
> > > > > 
> > > > > Could you try following Marvell SATA/AHCI patch?
> > > > > https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/2c1571432e4fd298be0236b53511f415bbdd21ac
> > > > 
> > > > will do that later and report my findings, thanks!
> 
> That one didn't help unfortunately. u-boot still prints "SATA link 0
> timeout". Booting kernel 5.7.0-0.bpo.2-arm64 with that and sata works, but
> booting 4.19.0-10-arm64 and it doesn't: "ata1: SATA link down (SStatus 131
> SControl 300)" is printed all over again.

I found another patch which could maybe help:
https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/6c6b2088f83b992d03e0d56f92c4dda7d44a7dc0

Or maybe with this patch:

diff --git a/arch/arm/dts/armada-3720-espressobin.dts b/arch/arm/dts/armada-3720-espressobin.dts
index 4534f5ff29..c5eea978f6 100644
--- a/arch/arm/dts/armada-3720-espressobin.dts
+++ b/arch/arm/dts/armada-3720-espressobin.dts
@@ -95,6 +95,7 @@
 	phy2 {
 		phy-type = <PHY_TYPE_SATA0>;
 		phy-speed = <PHY_SPEED_5G>;
+		phy-invert = <COMPHY_POLARITY_NO_INVERT>;
 	};
 };
 

Espressobin booting (Was: Re: [PATCH 1/5] arm: mvebu: Espressobin: Move env load addresses)

[Andre Heider]

On 28/08/2020 14:39, Pali Roh?r wrote:
> On Wednesday 26 August 2020 15:22:37 Andre Heider wrote:
>> Hi,
>>
>> On 26/08/2020 13:40, Pali Roh?r wrote:
>>> On Wednesday 26 August 2020 12:51:18 Pali Roh?r wrote:
>>>> On Wednesday 26 August 2020 11:57:01 Andre Heider wrote:
>>>>> Hi,
>>>>>
>>>>> On 26/08/2020 10:31, Pali Roh?r wrote:
>>>>>> Hello!
>>>>>>
>>>>>> On Wednesday 26 August 2020 09:30:11 Andre Heider wrote:
>>>>>>> Pali,
>>>>>>>
>>>>>>> thank you for all these espressobin fixes, much appreciated!
>>>>>>>
>>>>>>> This isn't directly related to the patch I'm replying to, but since you seem
>>>>>>> to be syncing down- with upstream:
>>>>>>>
>>>>>>> Upstream u-boot doesn't detect my sata ssd ("SATA link 0 timeout"), nor is
>>>>>>
>>>>>> Could you try following Marvell SATA/AHCI patch?
>>>>>> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/2c1571432e4fd298be0236b53511f415bbdd21ac
>>>>>
>>>>> will do that later and report my findings, thanks!
>>
>> That one didn't help unfortunately. u-boot still prints "SATA link 0
>> timeout". Booting kernel 5.7.0-0.bpo.2-arm64 with that and sata works, but
>> booting 4.19.0-10-arm64 and it doesn't: "ata1: SATA link down (SStatus 131
>> SControl 300)" is printed all over again.
> 
> I found another patch which could maybe help:
> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/6c6b2088f83b992d03e0d56f92c4dda7d44a7dc0

I think we have a winner:

U-Boot 2020.10-rc3-00020-gbcf6779d94 (Aug 28 2020 - 16:23:44 +0200)

DRAM:  1 GiB
Comphy-0: USB3_HOST0    5 Gbps
Comphy-1: PEX0          2.5 Gbps
Comphy-2: SATA0         5 Gbps
Target spinup took 0 ms.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs
PCIE-0: Link up
MMC:   sdhci at d0000: 0
Loading Environment from SPIFlash... SF: Detected w25q32dw with page 
size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
Model: Marvell Armada 3720 Community Board ESPRESSOBin
Net:   eth0: neta at 30000
Hit any key to stop autoboot:  0
=> scsi scan
scanning bus for devices...
   Device 0: (0:0) Vendor: ATA Prod.: Crucial_CT250MX2 Rev: MU05
             Type: Hard Disk
             Capacity: 238475.1 MB = 232.8 GB (488397168 x 512)

:)

Nice, thanks! Will send the patch soon,
Andre

Espressobin booting (Was: Re: [PATCH 1/5] arm: mvebu: Espressobin: Move env load addresses)

[Pali Rohár]

On Friday 28 August 2020 16:35:22 Andre Heider wrote:
> On 28/08/2020 14:39, Pali Roh?r wrote:
> > On Wednesday 26 August 2020 15:22:37 Andre Heider wrote:
> > > Hi,
> > > 
> > > On 26/08/2020 13:40, Pali Roh?r wrote:
> > > > On Wednesday 26 August 2020 12:51:18 Pali Roh?r wrote:
> > > > > On Wednesday 26 August 2020 11:57:01 Andre Heider wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On 26/08/2020 10:31, Pali Roh?r wrote:
> > > > > > > Hello!
> > > > > > > 
> > > > > > > On Wednesday 26 August 2020 09:30:11 Andre Heider wrote:
> > > > > > > > Pali,
> > > > > > > > 
> > > > > > > > thank you for all these espressobin fixes, much appreciated!
> > > > > > > > 
> > > > > > > > This isn't directly related to the patch I'm replying to, but since you seem
> > > > > > > > to be syncing down- with upstream:
> > > > > > > > 
> > > > > > > > Upstream u-boot doesn't detect my sata ssd ("SATA link 0 timeout"), nor is
> > > > > > > 
> > > > > > > Could you try following Marvell SATA/AHCI patch?
> > > > > > > https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/2c1571432e4fd298be0236b53511f415bbdd21ac
> > > > > > 
> > > > > > will do that later and report my findings, thanks!
> > > 
> > > That one didn't help unfortunately. u-boot still prints "SATA link 0
> > > timeout". Booting kernel 5.7.0-0.bpo.2-arm64 with that and sata works, but
> > > booting 4.19.0-10-arm64 and it doesn't: "ata1: SATA link down (SStatus 131
> > > SControl 300)" is printed all over again.
> > 
> > I found another patch which could maybe help:
> > https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/6c6b2088f83b992d03e0d56f92c4dda7d44a7dc0
> 
> I think we have a winner:
> 
> U-Boot 2020.10-rc3-00020-gbcf6779d94 (Aug 28 2020 - 16:23:44 +0200)
> 
> DRAM:  1 GiB
> Comphy-0: USB3_HOST0    5 Gbps
> Comphy-1: PEX0          2.5 Gbps
> Comphy-2: SATA0         5 Gbps
> Target spinup took 0 ms.
> AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
> flags: ncq led only pmp fbss pio slum part sxs
> PCIE-0: Link up
> MMC:   sdhci at d0000: 0
> Loading Environment from SPIFlash... SF: Detected w25q32dw with page size
> 256 Bytes, erase size 4 KiB, total 4 MiB
> OK
> Model: Marvell Armada 3720 Community Board ESPRESSOBin
> Net:   eth0: neta at 30000
> Hit any key to stop autoboot:  0
> => scsi scan
> scanning bus for devices...
>   Device 0: (0:0) Vendor: ATA Prod.: Crucial_CT250MX2 Rev: MU05
>             Type: Hard Disk
>             Capacity: 238475.1 MB = 232.8 GB (488397168 x 512)
> 
> :)
> 
> Nice, thanks! Will send the patch soon,
> Andre

Excellent!

[PATCH v2 1/4] arm: mvebu: Espressobin: Move env load addresses

[Pali Rohár]

According to Marvell's U-Boot description [1] current env load addresses
overlaps with ATF RT services region and TEE. Because the ATF RT service
and TEE region is going to be marked as secure and can't be overwritten,
use different different addresses for envs.

[1] - https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/0a5b159806baa0746b6449920e450498bc269ba7

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
Changes in V2:
* Move also ramdisk_addr_r, so there is enough space for kernel
* Drop patch "Define console env" as it cause problems for Debian bootscript
---
 include/configs/mvebu_armada-37xx.h | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
index ca662b0ce7..a9ed0a838f 100644
--- a/include/configs/mvebu_armada-37xx.h
+++ b/include/configs/mvebu_armada-37xx.h
@@ -91,11 +91,11 @@
 #include <config_distro_bootcmd.h>
 
 #define CONFIG_EXTRA_ENV_SETTINGS	\
-	"scriptaddr=0x4d00000\0"	\
-	"pxefile_addr_r=0x4e00000\0"	\
-	"fdt_addr_r=0x4f00000\0"	\
-	"kernel_addr_r=0x5000000\0"	\
-	"ramdisk_addr_r=0x8000000\0"	\
+	"scriptaddr=0x6d00000\0"	\
+	"pxefile_addr_r=0x6e00000\0"	\
+	"fdt_addr_r=0x6f00000\0"	\
+	"kernel_addr_r=0x7000000\0"	\
+	"ramdisk_addr_r=0xa000000\0"	\
 	BOOTENV
 
 #endif /* _CONFIG_MVEBU_ARMADA_37XX_H */
-- 
2.20.1

[PATCH v2 2/4] arm: mvebu: Espressobin: Change default loadaddr

[Pali Rohár]

Current loadaddr is not writable on Espressobin and 'loadb' command cause
rebooting board. Marvell's U-Boot already set default loadaddr to value
0x06000000 [1] and after this change 'loadb' is working fine.

[1] - https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/0a5b159806baa0746b6449920e450498bc269ba7

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 include/configs/mvebu_armada-37xx.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
index a9ed0a838f..93c05e30cc 100644
--- a/include/configs/mvebu_armada-37xx.h
+++ b/include/configs/mvebu_armada-37xx.h
@@ -37,7 +37,7 @@
 /*
  * Other required minimal configurations
  */
-#define CONFIG_SYS_LOAD_ADDR	0x00800000	/* default load adr- 8M */
+#define CONFIG_SYS_LOAD_ADDR	0x06000000	/* default load adr */
 #define CONFIG_SYS_RESET_ADDRESS 0xffff0000	/* Rst Vector Adr */
 #define CONFIG_SYS_MAXARGS	32	/* max number of command args */
 
-- 
2.20.1

[PATCH v2 2/4] arm: mvebu: Espressobin: Change default loadaddr

[Stefan Roese]

On 27.08.20 15:01, Pali Roh?r wrote:
> Current loadaddr is not writable on Espressobin and 'loadb' command cause
> rebooting board. Marvell's U-Boot already set default loadaddr to value
> 0x06000000 [1] and after this change 'loadb' is working fine.
> 
> [1] - https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/0a5b159806baa0746b6449920e450498bc269ba7
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

> ---
>   include/configs/mvebu_armada-37xx.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
> index a9ed0a838f..93c05e30cc 100644
> --- a/include/configs/mvebu_armada-37xx.h
> +++ b/include/configs/mvebu_armada-37xx.h
> @@ -37,7 +37,7 @@
>   /*
>    * Other required minimal configurations
>    */
> -#define CONFIG_SYS_LOAD_ADDR	0x00800000	/* default load adr- 8M */
> +#define CONFIG_SYS_LOAD_ADDR	0x06000000	/* default load adr */
>   #define CONFIG_SYS_RESET_ADDRESS 0xffff0000	/* Rst Vector Adr */
>   #define CONFIG_SYS_MAXARGS	32	/* max number of command args */
>   
> 


Viele Gr??e,
Stefan

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de

[PATCH v2 2/4] arm: mvebu: Espressobin: Change default loadaddr

[Andre Heider]

On 27/08/2020 15:01, Pali Roh?r wrote:
> Current loadaddr is not writable on Espressobin and 'loadb' command cause
> rebooting board. Marvell's U-Boot already set default loadaddr to value
> 0x06000000 [1] and after this change 'loadb' is working fine.
> 
> [1] - https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/0a5b159806baa0746b6449920e450498bc269ba7
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>

Tested-by: Andre Heider <a.heider@gmail.com>

[PATCH v2 2/4] arm: mvebu: Espressobin: Change default loadaddr

[Stefan Roese]

On 27.08.20 15:01, Pali Roh?r wrote:
> Current loadaddr is not writable on Espressobin and 'loadb' command cause
> rebooting board. Marvell's U-Boot already set default loadaddr to value
> 0x06000000 [1] and after this change 'loadb' is working fine.
> 
> [1] - https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/0a5b159806baa0746b6449920e450498bc269ba7
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>

Applied to u-boot-marvell/master

Thanks,
Stefan

> ---
>   include/configs/mvebu_armada-37xx.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
> index a9ed0a838f..93c05e30cc 100644
> --- a/include/configs/mvebu_armada-37xx.h
> +++ b/include/configs/mvebu_armada-37xx.h
> @@ -37,7 +37,7 @@
>   /*
>    * Other required minimal configurations
>    */
> -#define CONFIG_SYS_LOAD_ADDR	0x00800000	/* default load adr- 8M */
> +#define CONFIG_SYS_LOAD_ADDR	0x06000000	/* default load adr */
>   #define CONFIG_SYS_RESET_ADDRESS 0xffff0000	/* Rst Vector Adr */
>   #define CONFIG_SYS_MAXARGS	32	/* max number of command args */
>   
> 


Viele Gr??e,
Stefan

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de

[PATCH v2 3/4] arm: mvebu: Espressobin: Define fdt_addr and kernel_addr env aliases

[Pali Rohár]

Boot scripts for existing Espressobin Linux distributions, like OpenWRT,
expect that U-Boot set fdt_addr and kernel_addr envs. So add env aliases
from fdt_addr_r and kernel_addr_r values.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 include/configs/mvebu_armada-37xx.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
index 93c05e30cc..905ce09b7a 100644
--- a/include/configs/mvebu_armada-37xx.h
+++ b/include/configs/mvebu_armada-37xx.h
@@ -90,10 +90,13 @@
 
 #include <config_distro_bootcmd.h>
 
+/* fdt_addr and kernel_addr are needed for existing distribution boot scripts */
 #define CONFIG_EXTRA_ENV_SETTINGS	\
 	"scriptaddr=0x6d00000\0"	\
 	"pxefile_addr_r=0x6e00000\0"	\
+	"fdt_addr=0x6f00000\0"		\
 	"fdt_addr_r=0x6f00000\0"	\
+	"kernel_addr=0x7000000\0"	\
 	"kernel_addr_r=0x7000000\0"	\
 	"ramdisk_addr_r=0xa000000\0"	\
 	BOOTENV
-- 
2.20.1

[PATCH v2 3/4] arm: mvebu: Espressobin: Define fdt_addr and kernel_addr env aliases

[Stefan Roese]

On 27.08.20 15:01, Pali Roh?r wrote:
> Boot scripts for existing Espressobin Linux distributions, like OpenWRT,
> expect that U-Boot set fdt_addr and kernel_addr envs. So add env aliases
> from fdt_addr_r and kernel_addr_r values.
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

> ---
>   include/configs/mvebu_armada-37xx.h | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
> index 93c05e30cc..905ce09b7a 100644
> --- a/include/configs/mvebu_armada-37xx.h
> +++ b/include/configs/mvebu_armada-37xx.h
> @@ -90,10 +90,13 @@
>   
>   #include <config_distro_bootcmd.h>
>   
> +/* fdt_addr and kernel_addr are needed for existing distribution boot scripts */
>   #define CONFIG_EXTRA_ENV_SETTINGS	\
>   	"scriptaddr=0x6d00000\0"	\
>   	"pxefile_addr_r=0x6e00000\0"	\
> +	"fdt_addr=0x6f00000\0"		\
>   	"fdt_addr_r=0x6f00000\0"	\
> +	"kernel_addr=0x7000000\0"	\
>   	"kernel_addr_r=0x7000000\0"	\
>   	"ramdisk_addr_r=0xa000000\0"	\
>   	BOOTENV
> 


Viele Gr??e,
Stefan

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de

[PATCH v2 3/4] arm: mvebu: Espressobin: Define fdt_addr and kernel_addr env aliases

[Andre Heider]

On 27/08/2020 15:01, Pali Roh?r wrote:
> Boot scripts for existing Espressobin Linux distributions, like OpenWRT,
> expect that U-Boot set fdt_addr and kernel_addr envs. So add env aliases
> from fdt_addr_r and kernel_addr_r values.
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>

Tested-by: Andre Heider <a.heider@gmail.com>

[PATCH v2 3/4] arm: mvebu: Espressobin: Define fdt_addr and kernel_addr env aliases

[Stefan Roese]

On 27.08.20 15:01, Pali Roh?r wrote:
> Boot scripts for existing Espressobin Linux distributions, like OpenWRT,
> expect that U-Boot set fdt_addr and kernel_addr envs. So add env aliases
> from fdt_addr_r and kernel_addr_r values.
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>

Applied to u-boot-marvell/master

Thanks,
Stefan

> ---
>   include/configs/mvebu_armada-37xx.h | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
> index 93c05e30cc..905ce09b7a 100644
> --- a/include/configs/mvebu_armada-37xx.h
> +++ b/include/configs/mvebu_armada-37xx.h
> @@ -90,10 +90,13 @@
>   
>   #include <config_distro_bootcmd.h>
>   
> +/* fdt_addr and kernel_addr are needed for existing distribution boot scripts */
>   #define CONFIG_EXTRA_ENV_SETTINGS	\
>   	"scriptaddr=0x6d00000\0"	\
>   	"pxefile_addr_r=0x6e00000\0"	\
> +	"fdt_addr=0x6f00000\0"		\
>   	"fdt_addr_r=0x6f00000\0"	\
> +	"kernel_addr=0x7000000\0"	\
>   	"kernel_addr_r=0x7000000\0"	\
>   	"ramdisk_addr_r=0xa000000\0"	\
>   	BOOTENV
> 


Viele Gr??e,
Stefan

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de

[PATCH v2 4/4] arm: mvebu: Espressobin: Update README.marvell file

[Pali Rohár]

Include information about permanent ethernet MAC address and add link how
to build ATF as U-Boot on Espressobin cannot be flashed without ATF.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 doc/README.marvell | 40 +++++++++++++++++++++++++++++++++++++---
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/doc/README.marvell b/doc/README.marvell
index 336461745c..da16316407 100644
--- a/doc/README.marvell
+++ b/doc/README.marvell
@@ -13,7 +13,8 @@ Build Procedure
 
 2. Set the cross compiler:
 
-		# export CROSS_COMPILE=/path/to/toolchain/aarch64-marvell-linux-gnu-
+		# sudo apt-get install gcc-aarch64-linux-gnu
+		# export CROSS_COMPILE=aarch64-linux-gnu-
 
 3. Clean-up old residuals:
 
@@ -30,7 +31,7 @@ Build Procedure
 
 5. Configure the device-tree and build the U-Boot image:
 
-	Compile u-boot and set the required device-tree using:
+	For the Armada-70x0/80x0 DB board compile u-boot and set the required device-tree using:
 
 		# make DEVICE_TREE=<name>
 
@@ -42,12 +43,45 @@ Build Procedure
         In order to prevent this, the required device-tree MUST be set during compilation.
         All device-tree files are located in ./arch/arm/dts/ folder.
 
+	For other DB boards (MacchiatoBin, EspressoBin and 3700 DB board) compile u-boot with
+	just default device-tree from defconfig using:
+
+		# make
+
 	NOTE:
 	The u-boot.bin should not be used as a stand-alone image.
 	The ARM Trusted Firmware (ATF) build process uses this image to generate the
-	flash image.
+	flash image. See TF-A Build Instructions for Marvell Platforms for more details at:
+	https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html
 
 Configuration update
 ---------------------
 	To update the U-Boot configuration, please refer to doc/README.kconfig
 
+
+Permanent ethernet MAC address
+-------------------------------
+	Prior flashing new U-Boot version (as part of ATF image) it is suggested to backup
+	permanent ethernet MAC address as it is stored only in U-Boot env storage (SPI or eMMC).
+	Some boards like EspressoBin have MAC address printed on sticker. To print current MAC
+	address run:
+
+		# echo $ethaddr
+
+	MAC addresses 00:51:82:11:22:00, 00:51:82:11:22:01, 00:51:82:11:22:02, 00:51:82:11:22:03
+	and F0:AD:4E:03:64:7F are default hardcoded values found in Marvell's and Armbian U-Boot
+	forks and therefore *not* unique. Usage of static hardcoded MAC addresses should be avoided.
+	When original address is lost (e.g. erased by Armbian boot scripts for EspressoBin) it is
+	suggested to generate new random one.
+
+	After flashing new U-Boot version it is suggested to reset U-Boot env variables to default
+	and then set correct permanent ethernet MAC address.
+
+		# env default -a
+		# setenv ethaddr XX:XX:XX:XX:XX:XX
+		# saveenv
+
+	Where XX:XX:XX:XX:XX:XX is permanent ethernet MAC address.
+
+	Recent Linux kernel versions use correct permanent ethernet MAC address from U-Boot env as
+	U-Boot will inject it into kernel's device-tree.
-- 
2.20.1

[PATCH v2 4/4] arm: mvebu: Espressobin: Update README.marvell file

[Stefan Roese]

On 27.08.20 15:01, Pali Roh?r wrote:
> Include information about permanent ethernet MAC address and add link how
> to build ATF as U-Boot on Espressobin cannot be flashed without ATF.
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

> ---
>   doc/README.marvell | 40 +++++++++++++++++++++++++++++++++++++---
>   1 file changed, 37 insertions(+), 3 deletions(-)
> 
> diff --git a/doc/README.marvell b/doc/README.marvell
> index 336461745c..da16316407 100644
> --- a/doc/README.marvell
> +++ b/doc/README.marvell
> @@ -13,7 +13,8 @@ Build Procedure
>   
>   2. Set the cross compiler:
>   
> -		# export CROSS_COMPILE=/path/to/toolchain/aarch64-marvell-linux-gnu-
> +		# sudo apt-get install gcc-aarch64-linux-gnu
> +		# export CROSS_COMPILE=aarch64-linux-gnu-
>   
>   3. Clean-up old residuals:
>   
> @@ -30,7 +31,7 @@ Build Procedure
>   
>   5. Configure the device-tree and build the U-Boot image:
>   
> -	Compile u-boot and set the required device-tree using:
> +	For the Armada-70x0/80x0 DB board compile u-boot and set the required device-tree using:
>   
>   		# make DEVICE_TREE=<name>
>   
> @@ -42,12 +43,45 @@ Build Procedure
>           In order to prevent this, the required device-tree MUST be set during compilation.
>           All device-tree files are located in ./arch/arm/dts/ folder.
>   
> +	For other DB boards (MacchiatoBin, EspressoBin and 3700 DB board) compile u-boot with
> +	just default device-tree from defconfig using:
> +
> +		# make
> +
>   	NOTE:
>   	The u-boot.bin should not be used as a stand-alone image.
>   	The ARM Trusted Firmware (ATF) build process uses this image to generate the
> -	flash image.
> +	flash image. See TF-A Build Instructions for Marvell Platforms for more details at:
> +	https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html
>   
>   Configuration update
>   ---------------------
>   	To update the U-Boot configuration, please refer to doc/README.kconfig
>   
> +
> +Permanent ethernet MAC address
> +-------------------------------
> +	Prior flashing new U-Boot version (as part of ATF image) it is suggested to backup
> +	permanent ethernet MAC address as it is stored only in U-Boot env storage (SPI or eMMC).
> +	Some boards like EspressoBin have MAC address printed on sticker. To print current MAC
> +	address run:
> +
> +		# echo $ethaddr
> +
> +	MAC addresses 00:51:82:11:22:00, 00:51:82:11:22:01, 00:51:82:11:22:02, 00:51:82:11:22:03
> +	and F0:AD:4E:03:64:7F are default hardcoded values found in Marvell's and Armbian U-Boot
> +	forks and therefore *not* unique. Usage of static hardcoded MAC addresses should be avoided.
> +	When original address is lost (e.g. erased by Armbian boot scripts for EspressoBin) it is
> +	suggested to generate new random one.
> +
> +	After flashing new U-Boot version it is suggested to reset U-Boot env variables to default
> +	and then set correct permanent ethernet MAC address.
> +
> +		# env default -a
> +		# setenv ethaddr XX:XX:XX:XX:XX:XX
> +		# saveenv
> +
> +	Where XX:XX:XX:XX:XX:XX is permanent ethernet MAC address.
> +
> +	Recent Linux kernel versions use correct permanent ethernet MAC address from U-Boot env as
> +	U-Boot will inject it into kernel's device-tree.
> 


Viele Gr??e,
Stefan

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de

[PATCH v2 4/4] arm: mvebu: Espressobin: Update README.marvell file

[Stefan Roese]

On 27.08.20 15:01, Pali Roh?r wrote:
> Include information about permanent ethernet MAC address and add link how
> to build ATF as U-Boot on Espressobin cannot be flashed without ATF.
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>

Applied to u-boot-marvell/master

Thanks,
Stefan

> ---
>   doc/README.marvell | 40 +++++++++++++++++++++++++++++++++++++---
>   1 file changed, 37 insertions(+), 3 deletions(-)
> 
> diff --git a/doc/README.marvell b/doc/README.marvell
> index 336461745c..da16316407 100644
> --- a/doc/README.marvell
> +++ b/doc/README.marvell
> @@ -13,7 +13,8 @@ Build Procedure
>   
>   2. Set the cross compiler:
>   
> -		# export CROSS_COMPILE=/path/to/toolchain/aarch64-marvell-linux-gnu-
> +		# sudo apt-get install gcc-aarch64-linux-gnu
> +		# export CROSS_COMPILE=aarch64-linux-gnu-
>   
>   3. Clean-up old residuals:
>   
> @@ -30,7 +31,7 @@ Build Procedure
>   
>   5. Configure the device-tree and build the U-Boot image:
>   
> -	Compile u-boot and set the required device-tree using:
> +	For the Armada-70x0/80x0 DB board compile u-boot and set the required device-tree using:
>   
>   		# make DEVICE_TREE=<name>
>   
> @@ -42,12 +43,45 @@ Build Procedure
>           In order to prevent this, the required device-tree MUST be set during compilation.
>           All device-tree files are located in ./arch/arm/dts/ folder.
>   
> +	For other DB boards (MacchiatoBin, EspressoBin and 3700 DB board) compile u-boot with
> +	just default device-tree from defconfig using:
> +
> +		# make
> +
>   	NOTE:
>   	The u-boot.bin should not be used as a stand-alone image.
>   	The ARM Trusted Firmware (ATF) build process uses this image to generate the
> -	flash image.
> +	flash image. See TF-A Build Instructions for Marvell Platforms for more details at:
> +	https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html
>   
>   Configuration update
>   ---------------------
>   	To update the U-Boot configuration, please refer to doc/README.kconfig
>   
> +
> +Permanent ethernet MAC address
> +-------------------------------
> +	Prior flashing new U-Boot version (as part of ATF image) it is suggested to backup
> +	permanent ethernet MAC address as it is stored only in U-Boot env storage (SPI or eMMC).
> +	Some boards like EspressoBin have MAC address printed on sticker. To print current MAC
> +	address run:
> +
> +		# echo $ethaddr
> +
> +	MAC addresses 00:51:82:11:22:00, 00:51:82:11:22:01, 00:51:82:11:22:02, 00:51:82:11:22:03
> +	and F0:AD:4E:03:64:7F are default hardcoded values found in Marvell's and Armbian U-Boot
> +	forks and therefore *not* unique. Usage of static hardcoded MAC addresses should be avoided.
> +	When original address is lost (e.g. erased by Armbian boot scripts for EspressoBin) it is
> +	suggested to generate new random one.
> +
> +	After flashing new U-Boot version it is suggested to reset U-Boot env variables to default
> +	and then set correct permanent ethernet MAC address.
> +
> +		# env default -a
> +		# setenv ethaddr XX:XX:XX:XX:XX:XX
> +		# saveenv
> +
> +	Where XX:XX:XX:XX:XX:XX is permanent ethernet MAC address.
> +
> +	Recent Linux kernel versions use correct permanent ethernet MAC address from U-Boot env as
> +	U-Boot will inject it into kernel's device-tree.
> 


Viele Gr??e,
Stefan

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de

[PATCH v2 1/4] arm: mvebu: Espressobin: Move env load addresses

[Andre Heider]

On 27/08/2020 15:01, Pali Roh?r wrote:
> According to Marvell's U-Boot description [1] current env load addresses
> overlaps with ATF RT services region and TEE. Because the ATF RT service
> and TEE region is going to be marked as secure and can't be overwritten,
> use different different addresses for envs.
> 
> [1] - https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/0a5b159806baa0746b6449920e450498bc269ba7
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>

For the series:
Tested-by: Andre Heider <a.heider@gmail.com>

Thanks again, finally I'm able to boot with an upstream atf/u-boot!

[PATCH v2 1/4] arm: mvebu: Espressobin: Move env load addresses

[Stefan Roese]

Hi Andre,

On 27.08.20 16:31, Andre Heider wrote:
> On 27/08/2020 15:01, Pali Roh?r wrote:
>> According to Marvell's U-Boot description [1] current env load addresses
>> overlaps with ATF RT services region and TEE. Because the ATF RT service
>> and TEE region is going to be marked as secure and can't be overwritten,
>> use different different addresses for envs.
>>
>> [1] - 
>> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/0a5b159806baa0746b6449920e450498bc269ba7 
>>
>>
>> Signed-off-by: Pali Roh?r <pali@kernel.org>
> 
> For the series:
> Tested-by: Andre Heider <a.heider@gmail.com>

Could you please send such a mail with the TB tag for all the 4 out of
4 patches from this series? Reason being, that patchwork automatically
collects these tags making it easier for me (and other maintainers) to
keep track of these tags.

Thanks,
Stefan

[PATCH v2 1/4] arm: mvebu: Espressobin: Move env load addresses

[Stefan Roese]

On 27.08.20 15:01, Pali Roh?r wrote:
> According to Marvell's U-Boot description [1] current env load addresses
> overlaps with ATF RT services region and TEE. Because the ATF RT service
> and TEE region is going to be marked as secure and can't be overwritten,
> use different different addresses for envs.
> 
> [1] - https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/0a5b159806baa0746b6449920e450498bc269ba7
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

> ---
> Changes in V2:
> * Move also ramdisk_addr_r, so there is enough space for kernel
> * Drop patch "Define console env" as it cause problems for Debian bootscript
> ---
>   include/configs/mvebu_armada-37xx.h | 10 +++++-----
>   1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
> index ca662b0ce7..a9ed0a838f 100644
> --- a/include/configs/mvebu_armada-37xx.h
> +++ b/include/configs/mvebu_armada-37xx.h
> @@ -91,11 +91,11 @@
>   #include <config_distro_bootcmd.h>
>   
>   #define CONFIG_EXTRA_ENV_SETTINGS	\
> -	"scriptaddr=0x4d00000\0"	\
> -	"pxefile_addr_r=0x4e00000\0"	\
> -	"fdt_addr_r=0x4f00000\0"	\
> -	"kernel_addr_r=0x5000000\0"	\
> -	"ramdisk_addr_r=0x8000000\0"	\
> +	"scriptaddr=0x6d00000\0"	\
> +	"pxefile_addr_r=0x6e00000\0"	\
> +	"fdt_addr_r=0x6f00000\0"	\
> +	"kernel_addr_r=0x7000000\0"	\
> +	"ramdisk_addr_r=0xa000000\0"	\
>   	BOOTENV
>   
>   #endif /* _CONFIG_MVEBU_ARMADA_37XX_H */
> 


Viele Gr??e,
Stefan

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de

[PATCH v2 1/4] arm: mvebu: Espressobin: Move env load addresses

[Stefan Roese]

On 27.08.20 15:01, Pali Roh?r wrote:
> According to Marvell's U-Boot description [1] current env load addresses
> overlaps with ATF RT services region and TEE. Because the ATF RT service
> and TEE region is going to be marked as secure and can't be overwritten,
> use different different addresses for envs.
> 
> [1] - https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/0a5b159806baa0746b6449920e450498bc269ba7
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>

Applied to u-boot-marvell/master

Thanks,
Stefan

> ---
> Changes in V2:
> * Move also ramdisk_addr_r, so there is enough space for kernel
> * Drop patch "Define console env" as it cause problems for Debian bootscript
> ---
>   include/configs/mvebu_armada-37xx.h | 10 +++++-----
>   1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/include/configs/mvebu_armada-37xx.h b/include/configs/mvebu_armada-37xx.h
> index ca662b0ce7..a9ed0a838f 100644
> --- a/include/configs/mvebu_armada-37xx.h
> +++ b/include/configs/mvebu_armada-37xx.h
> @@ -91,11 +91,11 @@
>   #include <config_distro_bootcmd.h>
>   
>   #define CONFIG_EXTRA_ENV_SETTINGS	\
> -	"scriptaddr=0x4d00000\0"	\
> -	"pxefile_addr_r=0x4e00000\0"	\
> -	"fdt_addr_r=0x4f00000\0"	\
> -	"kernel_addr_r=0x5000000\0"	\
> -	"ramdisk_addr_r=0x8000000\0"	\
> +	"scriptaddr=0x6d00000\0"	\
> +	"pxefile_addr_r=0x6e00000\0"	\
> +	"fdt_addr_r=0x6f00000\0"	\
> +	"kernel_addr_r=0x7000000\0"	\
> +	"ramdisk_addr_r=0xa000000\0"	\
>   	BOOTENV
>   
>   #endif /* _CONFIG_MVEBU_ARMADA_37XX_H */
> 


Viele Gr??e,
Stefan

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de