Hi,

mainline U-Boot should work for Armada 3720, although I haven't tested recent master (so I don't know if there are some regressions). But Turris Mox uses cca 1 year old upstream with just few Mox specific patches atop (which I plan to get merged soon). You can find it here: https://gitlab.labs.nic.cz/turris/mox-u-boot

One thing that may need reworking (to become compatible with Linux) is the comphy driver. Linux' comphy driver for this SOC uses smccc calls to ARM Trusted Firmware, but U-Boot does not, and instead initializes SERDESes on its own.

Bear in mind that U-Boot is not enough for booting Armada 3720 SOC. You do also need ARM Trusted Firmware (you don't need to use Marvell's ATF, since their patches are merged into upstream ATF), and you also need firmware for the secure Cortex-M3 processor (Marvell's name for this firmware is WTMI), which does DDR training. Marvell has this in A3700-utils-marvell repository. For Turris MOX, we build all of this via https://gitlab.labs.nic.cz/turris/mox-boot-builder but this code can be MOX specific, so if you want to use it for other boards, I can provide more explanation of which does what and so on.

Marek

On Wed, 25 Mar 2020 17:44:57 +0100 Stefan Roese sr@denx.de wrote:

Hi Moritz,

On 25.03.20 16:05, Moritz Berghof wrote:

...

My Name is Moritz and we evaluate the Marvell Armada 88F3720 on the Marvell ESPRESSObin and the TURRIS MOX.

Does someone know, where is the actual or latest u-boot branch for Marvell Armada 88F3720 placed? At the u-boot master or a marvell custodian tree or somewhere else? Does Marvell develop u-boot still for their Armada 88F3720 and when yes, where?

Those boards are supported in general in mainline U-Boot. Though I have to admit, that I didn't test any of those ports recently. I added Marek Behun to Cc, as he did submit most of the Turris Mox stuff and has more recent experience than I do.

...

Because that https://github.com/MarvellEmbeddedProcessors/u-boot-marvell, which is well used on the ESPRESSObin is NOT up-to-date. 4 Years ago, last commit.

I just took a quick glance at this repo and there are newer, more recent branches, e.g. "u-boot-2018.03-armada-18.12". But still, this is far away from mainline, I agree.

Perhaps someone else (Marek) can comment on the current status of mainline U-Boot on those boards? Is something missing? If yes, it would be great to get it ported to mainline.

Thanks, Stefan

...

I'm searching an actual u-boot platform for my Chip.

I look forward to your reply, thank you very much,

-- Moritz Berghof Software Engineer Tel. +49 30 921028-209tel:+49%C2%A030%C2%A0921028-204 Fax +49 30 921028-020tel:+49%C2%A030%C2%A0921028-020 mberghof@phoenixcontact.commailto:mberghof@phoenixcontact.com www.phoenixcontact.comhttp://www.phoenixcontact.com/

PHOENIX CONTACT Cyber Security GmbH Richard-Willstätter-Straße 6x-apple-data-detectors://1/1 D-12489 Berlinx-apple-data-detectors://1/1 Register Court: AG Charlottenburg, HR B 202908 Geschäftsführer/General Manager: Kilian Golm

....................................................................................... PHOENIX CONTACT Cyber Security GmbH Richard-Willstätter-Straße 6 D-12489 Berlin

Register Court: AG Charlottenburg, HR B 202908 Geschäftsführer/General Manager: Kilian Golm

Hey Marek, Hi Stefan,

it's really great that you answered so fast and helpfully, thank you!

It's great you want get the board ported to mainline. Me too.

I build the U-boot mainline and uploaded on my espressobin. Used the ATF and WTMI from Marvell.

When I start the flashed .bin file, the U-boot crashed at this following point. "Synchronous Abort" handler, esr 0x96000210

Prompt is attached at this mail.

I think there is a problem with the RAM. For example, I build the U-Boot for 1 GB RAM with the Marvell U-boot and the mainline/master. Important constant is DDR_TOPOLOGY=2

make DEBUG=0 USE_COHERENT_MEM=0 LOG_LEVEL=20 SECURE=0 CLOCKSPRESET=CPU_1000_DDR_800 DDR_TOPOLOGY=2 WTP=... BOOTDEV=SPINOR PARTNUM=0 PLAT=a3700 all fip

But when the u-boot mainline starts it promts: U-Boot 2020.04-rc3-00188-g350c44dfb9 (Mar 31 2020 - 10:52:01 +0200)

DRAM: 512 MiB

The Marvell U-boot promts DRAM: 1 GiB

So my question is, where do you define the RAM Size?

At armada-3720-espressobin.dts i expanded the memory size. No success. At mvebu_armada-37xx.h I expand the RAM for two banks. No success.

Or do you see there other problems by starting the mainline?

Thanks,

-- Moritz Berghof Software Engineering Tel. +49 30 921028-209 Fax +49 30 921028-020 mberghof@phoenixcontact.com www.phoenixcontact.com   PHOENIX CONTACT Cyber Security GmbH Richard-Willstätter-Straße 6 D-12489 Berlin Register Court: AG Charlottenburg, HR B 202908 Geschäftsführer/General Manager: Kilian Golm

-----Ursprüngliche Nachricht----- Von: Marek Behun marek.behun@nic.cz Gesendet: Mittwoch, 25. März 2020 18:49 An: stefan roese sr@denx.de Cc: Moritz Berghof mberghof@phoenixcontact.com; u-boot mailing list u-boot@lists.denx.de Betreff: Re: latest u-boot branch for Marvell Armada 88F3720

***External email! Do not click links or open attachments unless you recognize the sender and know the content is safe.***

Hi,

mainline U-Boot should work for Armada 3720, although I haven't tested recent master (so I don't know if there are some regressions). But Turris Mox uses cca 1 year old upstream with just few Mox specific patches atop (which I plan to get merged soon). You can find it here: https://gitlab.labs.nic.cz/turris/mox-u-boot

One thing that may need reworking (to become compatible with Linux) is the comphy driver. Linux' comphy driver for this SOC uses smccc calls to ARM Trusted Firmware, but U-Boot does not, and instead initializes SERDESes on its own.

Bear in mind that U-Boot is not enough for booting Armada 3720 SOC. You do also need ARM Trusted Firmware (you don't need to use Marvell's ATF, since their patches are merged into upstream ATF), and you also need firmware for the secure Cortex-M3 processor (Marvell's name for this firmware is WTMI), which does DDR training. Marvell has this in A3700-utils-marvell repository. For Turris MOX, we build all of this via https://gitlab.labs.nic.cz/turris/mox-boot-builder but this code can be MOX specific, so if you want to use it for other boards, I can provide more explanation of which does what and so on.

Marek

On Wed, 25 Mar 2020 17:44:57 +0100 Stefan Roese sr@denx.de wrote:

Hi Moritz,

On 25.03.20 16:05, Moritz Berghof wrote:

...

My Name is Moritz and we evaluate the Marvell Armada 88F3720 on the Marvell ESPRESSObin and the TURRIS MOX.

Does someone know, where is the actual or latest u-boot branch for Marvell Armada 88F3720 placed? At the u-boot master or a marvell custodian tree or somewhere else? Does Marvell develop u-boot still for their Armada 88F3720 and when yes, where?

Those boards are supported in general in mainline U-Boot. Though I have to admit, that I didn't test any of those ports recently. I added Marek Behun to Cc, as he did submit most of the Turris Mox stuff and has more recent experience than I do.

...

Because that https://github.com/MarvellEmbeddedProcessors/u-boot-marvell, which is well used on the ESPRESSObin is NOT up-to-date. 4 Years ago, last commit.

I just took a quick glance at this repo and there are newer, more recent branches, e.g. "u-boot-2018.03-armada-18.12". But still, this is far away from mainline, I agree.

Perhaps someone else (Marek) can comment on the current status of mainline U-Boot on those boards? Is something missing? If yes, it would be great to get it ported to mainline.

Thanks, Stefan

...

I'm searching an actual u-boot platform for my Chip.

I look forward to your reply, thank you very much,

-- Moritz Berghof Software Engineer Tel. +49 30 921028-209tel:+49%C2%A030%C2%A0921028-204 Fax +49 30 921028-020tel:+49%C2%A030%C2%A0921028-020 mberghof@phoenixcontact.commailto:mberghof@phoenixcontact.com www.phoenixcontact.comhttp://www.phoenixcontact.com/

PHOENIX CONTACT Cyber Security GmbH Richard-Willstätter-Straße 6x-apple-data-detectors://1/1 D-12489 Berlinx-apple-data-detectors://1/1 Register Court: AG Charlottenburg, HR B 202908 Geschäftsführer/General Manager: Kilian Golm

....................................................................................... PHOENIX CONTACT Cyber Security GmbH Richard-Willstätter-Straße 6 D-12489 Berlin

Register Court: AG Charlottenburg, HR B 202908 Geschäftsführer/General Manager: Kilian Golm

....................................................................................... PHOENIX CONTACT Cyber Security GmbH Richard-Willstätter-Straße 6 D-12489 Berlin

Register Court: AG Charlottenburg, HR B 202908 Geschäftsführer/General Manager: Kilian Golm

On Thu, 2 Apr 2020 14:18:24 +0200 Stefan Roese sr@denx.de wrote:

Hi Moritz,

On 02.04.20 13:30, Moritz Berghof wrote:

...

it's really great that you answered so fast and helpfully, thank you!

It's great you want get the board ported to mainline. Me too.

I build the U-boot mainline and uploaded on my espressobin. Used the ATF and WTMI from Marvell.

When I start the flashed .bin file, the U-boot crashed at this following point. "Synchronous Abort" handler, esr 0x96000210

Looks like an issue with SATA - not sure why. You might want to try to disable SATA / AHCI for testing.

...

Prompt is attached at this mail.

I think there is a problem with the RAM. For example, I build the U-Boot for 1 GB RAM with the Marvell U-boot and the mainline/master. Important constant is DDR_TOPOLOGY=2

make DEBUG=0 USE_COHERENT_MEM=0 LOG_LEVEL=20 SECURE=0 CLOCKSPRESET=CPU_1000_DDR_800 DDR_TOPOLOGY=2 WTP=... BOOTDEV=SPINOR PARTNUM=0 PLAT=a3700 all fip

But when the u-boot mainline starts it promts: U-Boot 2020.04-rc3-00188-g350c44dfb9 (Mar 31 2020 - 10:52:01 +0200)

DRAM: 512 MiB

The Marvell U-boot promts DRAM: 1 GiB

So my question is, where do you define the RAM Size?

Take a look at arch/arm/mach-mvebu/arm64-common.c. Perhaps this code needs some changes for CONFIG_ARMADA_A3700 similar to what is done for CONFIG_ARMADA_8K ?

I suggest you debug in this area a bit to see, where it goes wrong.

There is a register on A3720 which should contain information about how much RAM the system has (0xD0000200 if the device contains only one DDR chip). It is written by the TIM image. I am going to send a patch which uses this register to determine RAM size for Turris Mox.

The thing is that without upgrade of TIM header some Moxes may report 1 GB RAM in this register, although they only have 512 MB. So a call to get_ram_size will still be needed.

Marek