[U-Boot] How to update Espressobin (U-Boot) firmware?

[U-Boot] How to update Espressobin (U-Boot) firmware?

[Andre Przywara]

Hi,

I wanted to exploit U-Boot's EFI support on the Espressobin board, to
use off-the-shelf arm64 distribution installer images. This should work
with current U-Boot, which has support for the Espressobin board (and
for UEFI).

The firmware my board ships with seems to be built from older and
non-upstream sources - and, in contrast to the Macchiatobin board - I
cannot find either proper sources for all components (mv-ddr, ATF) nor
*any* kind of instructions how to (re-)build and update the firmware.

So I was wondering if there are any instructions or documentation I
missed on how to update at least U-Boot?

I see some hints that people are apparently chain-loading mainline
U-Boot, is this the only way?
I dumped the SPI flash and could identify the ATF FIP image on it, but I
am a bit wary of bricking the board by just squashing a freshly built
u-boot.bin into that - which I guess wouldn't work that easily anyway.

And to allow experimentation: Are the boot selection jumpers actually
working? Setting them to SD card (111) doesn't seem to make a difference
(it still booted off the SPI flash, apparently). Or does it fall back to
SPI flash in case the SD image is not valid (I put the dumped image at
sector 1)?
I see that selecting "UART" (110) gives me that "E" prompt, apparently
waiting for some data to be fed, but again can't tell what to do from
here? I take it that mkimage/kwboot won't work as is, as it needs ATF? I
found some mentioning of a Windows binary, but hope that's not the only
way to use this mode?

I'd be very grateful for any insight into this!

Cheers,
Andre.

[U-Boot] [EXT] How to update Espressobin (U-Boot) firmware?

[Kostya Porotchkin]

Hi, Andre,

The A37xx SoC does not support boot from SD.
Only boot from eMMC is supported, however your board probably only has soldering pads for the eMMC and not eMMC chip installed.
If you want to play with the bootloader without jeopardizing your SPI image, you have to use either UART or SATA boot mode.

For the boot image build you will need to obtain the u-boot, ATF and the image building tools sources.
https://github.com/MarvellEmbeddedProcessors/atf-marvell/tree/atf-v1.3-armada-17.06
https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/tree/A3700_utils-armada-17.06
https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/tree/u-boot-2017.03-armada-17.06

The "utils" git contains also the UART download tool.
It uses a proprietary download protocol and not xmodem one as in KW case.
The flash image structure on this platform also differs from KW, so please do not try to directly burn a "bin" or "kw" file created by the u-boot build system.
The ATF git from above already contains the required changes in the Makefile for running the additional steps of the final flash image formatting.
Additionally, the boot image contains a boot device information in its header, so you cannot move SPI flash image to another boot device.

For the boot loader build instructions please check the following documents:
https://github.com/MarvellEmbeddedProcessors/atf-marvell/blob/atf-v1.3-17.04/docs/marvell/build.txt
https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2017.03-armada-17.06/doc/mvebu/build.txt

UART boot details:
https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2017.03-armada-17.06/doc/mvebu/uart_boot.txt


Regards
Kosta

> -----Original Message-----
> From: Andre Przywara [mailto:andre.przywara at arm.com]
> Sent: Tuesday, July 18, 2017 17:45
> To: Kostya Porotchkin
> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT;
> Antoine Tenart; Andreas Färber; U-Boot
> Subject: [EXT] How to update Espressobin (U-Boot) firmware?
> 
> External Email
> 
> ----------------------------------------------------------------------
> Hi,
> 
> I wanted to exploit U-Boot's EFI support on the Espressobin board, to
> use off-the-shelf arm64 distribution installer images. This should work
> with current U-Boot, which has support for the Espressobin board (and
> for UEFI).
> 
> The firmware my board ships with seems to be built from older and non-
> upstream sources - and, in contrast to the Macchiatobin board - I cannot
> find either proper sources for all components (mv-ddr, ATF) nor
> *any* kind of instructions how to (re-)build and update the firmware.
> 
> So I was wondering if there are any instructions or documentation I
> missed on how to update at least U-Boot?
> 
> I see some hints that people are apparently chain-loading mainline U-
> Boot, is this the only way?
> I dumped the SPI flash and could identify the ATF FIP image on it, but I
> am a bit wary of bricking the board by just squashing a freshly built u-
> boot.bin into that - which I guess wouldn't work that easily anyway.
> 
> And to allow experimentation: Are the boot selection jumpers actually
> working? Setting them to SD card (111) doesn't seem to make a difference
> (it still booted off the SPI flash, apparently). Or does it fall back to
> SPI flash in case the SD image is not valid (I put the dumped image at
> sector 1)?
> I see that selecting "UART" (110) gives me that "E" prompt, apparently
> waiting for some data to be fed, but again can't tell what to do from
> here? I take it that mkimage/kwboot won't work as is, as it needs ATF? I
> found some mentioning of a Windows binary, but hope that's not the only
> way to use this mode?
> 
> I'd be very grateful for any insight into this!
> 
> Cheers,
> Andre.

[U-Boot] [EXT] How to update Espressobin (U-Boot) firmware?

[Andre Przywara]

Hi Kosta,

On 18/07/17 16:13, Kostya Porotchkin wrote:
> The A37xx SoC does not support boot from SD.

Ah!

> Only boot from eMMC is supported, however your board probably only has soldering pads for the eMMC and not eMMC chip installed.
> If you want to play with the bootloader without jeopardizing your SPI image, you have to use either UART or SATA boot mode.

Does SATA boot work like SD boot, where the boot image starts at sector
1? And it needs to be flagged as a SATA boot image, right?

> For the boot image build you will need to obtain the u-boot, ATF and the image building tools sources.
> https://github.com/MarvellEmbeddedProcessors/atf-marvell/tree/atf-v1.3-armada-17.06
> https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/tree/A3700_utils-armada-17.06
> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/tree/u-boot-2017.03-armada-17.06
> 
> The "utils" git contains also the UART download tool.
> It uses a proprietary download protocol and not xmodem one as in KW case.
> The flash image structure on this platform also differs from KW, so please do not try to directly burn a "bin" or "kw" file created by the u-boot build system.
> The ATF git from above already contains the required changes in the Makefile for running the additional steps of the final flash image formatting.
> Additionally, the boot image contains a boot device information in its header, so you cannot move SPI flash image to another boot device.
> 
> For the boot loader build instructions please check the following documents:
> https://github.com/MarvellEmbeddedProcessors/atf-marvell/blob/atf-v1.3-17.04/docs/marvell/build.txt
> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2017.03-armada-17.06/doc/mvebu/build.txt
> 
> UART boot details:
> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2017.03-armada-17.06/doc/mvebu/uart_boot.txt

Thanks a ton for those links and information, that was exactly what I
was looking for!
Do you mind if I (later ;-) write up those steps in a document which we
merge into the repo?
Something like [1], which proved useful in the past just to point people
to - that would save you some typing as well ;-)

Cheers,
Andre.

[1]
http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/README.sunxi64;hb=HEAD

> 
> 
> Regards
> Kosta
> 
>> -----Original Message-----
>> From: Andre Przywara [mailto:andre.przywara at arm.com]
>> Sent: Tuesday, July 18, 2017 17:45
>> To: Kostya Porotchkin
>> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT;
>> Antoine Tenart; Andreas Färber; U-Boot
>> Subject: [EXT] How to update Espressobin (U-Boot) firmware?
>>
>> External Email
>>
>> ----------------------------------------------------------------------
>> Hi,
>>
>> I wanted to exploit U-Boot's EFI support on the Espressobin board, to
>> use off-the-shelf arm64 distribution installer images. This should work
>> with current U-Boot, which has support for the Espressobin board (and
>> for UEFI).
>>
>> The firmware my board ships with seems to be built from older and non-
>> upstream sources - and, in contrast to the Macchiatobin board - I cannot
>> find either proper sources for all components (mv-ddr, ATF) nor
>> *any* kind of instructions how to (re-)build and update the firmware.
>>
>> So I was wondering if there are any instructions or documentation I
>> missed on how to update at least U-Boot?
>>
>> I see some hints that people are apparently chain-loading mainline U-
>> Boot, is this the only way?
>> I dumped the SPI flash and could identify the ATF FIP image on it, but I
>> am a bit wary of bricking the board by just squashing a freshly built u-
>> boot.bin into that - which I guess wouldn't work that easily anyway.
>>
>> And to allow experimentation: Are the boot selection jumpers actually
>> working? Setting them to SD card (111) doesn't seem to make a difference
>> (it still booted off the SPI flash, apparently). Or does it fall back to
>> SPI flash in case the SD image is not valid (I put the dumped image at
>> sector 1)?
>> I see that selecting "UART" (110) gives me that "E" prompt, apparently
>> waiting for some data to be fed, but again can't tell what to do from
>> here? I take it that mkimage/kwboot won't work as is, as it needs ATF? I
>> found some mentioning of a Windows binary, but hope that's not the only
>> way to use this mode?
>>
>> I'd be very grateful for any insight into this!
>>
>> Cheers,
>> Andre.

[U-Boot] [EXT] How to update Espressobin (U-Boot) firmware?

[Kostya Porotchkin]

Hi, Andre,

> -----Original Message-----
> From: Andre Przywara [mailto:andre.przywara at arm.com]
> Sent: Tuesday, July 18, 2017 18:24
> To: Kostya Porotchkin
> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT;
> Antoine Tenart; Andreas Färber; U-Boot; Benjamin (Guodan) Huang
> Subject: Re: [EXT] How to update Espressobin (U-Boot) firmware?
> 
> Hi Kosta,
> 
> On 18/07/17 16:13, Kostya Porotchkin wrote:
> > The A37xx SoC does not support boot from SD.
> 
> Ah!
> 
> > Only boot from eMMC is supported, however your board probably only has
> soldering pads for the eMMC and not eMMC chip installed.
> > If you want to play with the bootloader without jeopardizing your SPI
> image, you have to use either UART or SATA boot mode.
> 
> Does SATA boot work like SD boot, where the boot image starts at sector
> 1? And it needs to be flagged as a SATA boot image, right?
[Konstantin Porotchkin] Correct. You can put it on LBA-1 or LBA-34 if you use GPT.
Just remember, this image is very special. It's actually a multipart image
that we merge into a single blob for easier usage with the u-boot "bubt" command.

> 
> > For the boot image build you will need to obtain the u-boot, ATF and
> the image building tools sources.
> > https://github.com/MarvellEmbeddedProcessors/atf-marvell/tree/atf-v1.3
> > -armada-17.06
> > https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/tree/
> > A3700_utils-armada-17.06
> > https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/tree/u-boo
> > t-2017.03-armada-17.06
> >
> > The "utils" git contains also the UART download tool.
> > It uses a proprietary download protocol and not xmodem one as in KW
> case.
> > The flash image structure on this platform also differs from KW, so
> please do not try to directly burn a "bin" or "kw" file created by the
> u-boot build system.
> > The ATF git from above already contains the required changes in the
> Makefile for running the additional steps of the final flash image
> formatting.
> > Additionally, the boot image contains a boot device information in its
> header, so you cannot move SPI flash image to another boot device.
> >
> > For the boot loader build instructions please check the following
> documents:
> > https://github.com/MarvellEmbeddedProcessors/atf-marvell/blob/atf-v1.3
> > -17.04/docs/marvell/build.txt
> > https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boo
> > t-2017.03-armada-17.06/doc/mvebu/build.txt
> >
> > UART boot details:
> > https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boo
> > t-2017.03-armada-17.06/doc/mvebu/uart_boot.txt
> 
> Thanks a ton for those links and information, that was exactly what I
> was looking for!
> Do you mind if I (later ;-) write up those steps in a document which we
> merge into the repo?
> Something like [1], which proved useful in the past just to point people
> to - that would save you some typing as well ;-)
[Konstantin Porotchkin] Sure, any additional source of information would be great.
I just notified the Espressobin WIKI team about urgent need for this type of document and for an alternative boot source usage example.
Hope the new WIKI entry will be ready shortly.

Regards
Kosta
> 
> Cheers,
> Andre.
> 
> [1]
> http://git.denx.de/?p=u-
> boot.git;a=blob;f=board/sunxi/README.sunxi64;hb=HEAD
> 
> >
> >
> > Regards
> > Kosta
> >
> >> -----Original Message-----
> >> From: Andre Przywara [mailto:andre.przywara at arm.com]
> >> Sent: Tuesday, July 18, 2017 17:45
> >> To: Kostya Porotchkin
> >> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT;
> >> Antoine Tenart; Andreas Färber; U-Boot
> >> Subject: [EXT] How to update Espressobin (U-Boot) firmware?
> >>
> >> External Email
> >>
> >> ---------------------------------------------------------------------
> >> -
> >> Hi,
> >>
> >> I wanted to exploit U-Boot's EFI support on the Espressobin board, to
> >> use off-the-shelf arm64 distribution installer images. This should
> >> work with current U-Boot, which has support for the Espressobin board
> >> (and for UEFI).
> >>
> >> The firmware my board ships with seems to be built from older and
> >> non- upstream sources - and, in contrast to the Macchiatobin board -
> >> I cannot find either proper sources for all components (mv-ddr, ATF)
> >> nor
> >> *any* kind of instructions how to (re-)build and update the firmware.
> >>
> >> So I was wondering if there are any instructions or documentation I
> >> missed on how to update at least U-Boot?
> >>
> >> I see some hints that people are apparently chain-loading mainline U-
> >> Boot, is this the only way?
> >> I dumped the SPI flash and could identify the ATF FIP image on it,
> >> but I am a bit wary of bricking the board by just squashing a freshly
> >> built u- boot.bin into that - which I guess wouldn't work that easily
> anyway.
> >>
> >> And to allow experimentation: Are the boot selection jumpers actually
> >> working? Setting them to SD card (111) doesn't seem to make a
> >> difference (it still booted off the SPI flash, apparently). Or does
> >> it fall back to SPI flash in case the SD image is not valid (I put
> >> the dumped image at sector 1)?
> >> I see that selecting "UART" (110) gives me that "E" prompt,
> >> apparently waiting for some data to be fed, but again can't tell what
> >> to do from here? I take it that mkimage/kwboot won't work as is, as
> >> it needs ATF? I found some mentioning of a Windows binary, but hope
> >> that's not the only way to use this mode?
> >>
> >> I'd be very grateful for any insight into this!
> >>
> >> Cheers,
> >> Andre.

[U-Boot] How to update Espressobin (U-Boot) firmware?

[Andre Przywara]

Hi Kosta,

thanks again for the instructions, though I feel the road there is still
a bit bumpy and has some potholes ;-)

Here is what I did:
1) build u-boot.bin
2) build wtmi.bin (from the utils repo)
3) build ATF
$ make USE_COHERENT_MEM=0 DEBUG=1 LOG_LEVEL=20 DDR_TOPOLOGY=2
BOOTDEV=SPINOR WTMI_IMG=/path/to/wtmi.bin PLAT=a3700 all fip
This breaks after having created fip.bin. I concatenated bl1.bin (padded
to 128K) and fip.bin to atf.bin manually.
4) create the image description file (in the utils repo):
./buildtim.sh 0 SPINOR ./untrusted ./ CPU_800_DDR_800 2 0 1 ntim.txt
5) fixup the filenames in the generated text file (wtmi.bin and atf.bin)
6) create the image (utils repo):
./wtptp_tool/linux/TBB_linux -m 1 -r ntim.txt -V

From staring at the SPI dump in a hexeditor, I take it that:
a) TIM_ATF.bin goes to 0
b) wtmi.bin goes to 0x4000
c) atf.bin goes to 0x15000

Is that about right? Is it that doimage from the ATF repo is supposed to
glue this together (step 4-6), which for some reason doesn't work for me?

Another issue seems to be that the UART download tool seems to be closed
source only and only available from the Marvell "Extranet" under NDA?

From looking at the output of the "h" command in UART mode I guess this
tools is just a glorious wrapper around spoon-feeding the generated
binaries in 32-bit chunks into the respective SRAM regions, then execute
them? Possibly also doing all those register setups (via MMIO) described
in the ntim.txt/TIM_ATF.bin file?
Which doesn't look too complicated to hack an Open Source tool for.
Or is this tool actually available somewhere (either as source or as a
binary)?

Cheers,
Andre.


On 18/07/17 16:32, Kostya Porotchkin wrote:
> Hi, Andre,
> 
>> -----Original Message-----
>> From: Andre Przywara [mailto:andre.przywara at arm.com]
>> Sent: Tuesday, July 18, 2017 18:24
>> To: Kostya Porotchkin
>> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT;
>> Antoine Tenart; Andreas Färber; U-Boot; Benjamin (Guodan) Huang
>> Subject: Re: [EXT] How to update Espressobin (U-Boot) firmware?
>>
>> Hi Kosta,
>>
>> On 18/07/17 16:13, Kostya Porotchkin wrote:
>>> The A37xx SoC does not support boot from SD.
>>
>> Ah!
>>
>>> Only boot from eMMC is supported, however your board probably only has
>> soldering pads for the eMMC and not eMMC chip installed.
>>> If you want to play with the bootloader without jeopardizing your SPI
>> image, you have to use either UART or SATA boot mode.
>>
>> Does SATA boot work like SD boot, where the boot image starts at sector
>> 1? And it needs to be flagged as a SATA boot image, right?
> [Konstantin Porotchkin] Correct. You can put it on LBA-1 or LBA-34 if you use GPT.
> Just remember, this image is very special. It's actually a multipart image
> that we merge into a single blob for easier usage with the u-boot "bubt" command.
> 
>>
>>> For the boot image build you will need to obtain the u-boot, ATF and
>> the image building tools sources.
>>> https://github.com/MarvellEmbeddedProcessors/atf-marvell/tree/atf-v1.3
>>> -armada-17.06
>>> https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/tree/
>>> A3700_utils-armada-17.06
>>> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/tree/u-boo
>>> t-2017.03-armada-17.06
>>>
>>> The "utils" git contains also the UART download tool.
>>> It uses a proprietary download protocol and not xmodem one as in KW
>> case.
>>> The flash image structure on this platform also differs from KW, so
>> please do not try to directly burn a "bin" or "kw" file created by the
>> u-boot build system.
>>> The ATF git from above already contains the required changes in the
>> Makefile for running the additional steps of the final flash image
>> formatting.
>>> Additionally, the boot image contains a boot device information in its
>> header, so you cannot move SPI flash image to another boot device.
>>>
>>> For the boot loader build instructions please check the following
>> documents:
>>> https://github.com/MarvellEmbeddedProcessors/atf-marvell/blob/atf-v1.3
>>> -17.04/docs/marvell/build.txt
>>> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boo
>>> t-2017.03-armada-17.06/doc/mvebu/build.txt
>>>
>>> UART boot details:
>>> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boo
>>> t-2017.03-armada-17.06/doc/mvebu/uart_boot.txt
>>
>> Thanks a ton for those links and information, that was exactly what I
>> was looking for!
>> Do you mind if I (later ;-) write up those steps in a document which we
>> merge into the repo?
>> Something like [1], which proved useful in the past just to point people
>> to - that would save you some typing as well ;-)
> [Konstantin Porotchkin] Sure, any additional source of information would be great.
> I just notified the Espressobin WIKI team about urgent need for this type of document and for an alternative boot source usage example.
> Hope the new WIKI entry will be ready shortly.
> 
> Regards
> Kosta
>>
>> Cheers,
>> Andre.
>>
>> [1]
>> http://git.denx.de/?p=u-
>> boot.git;a=blob;f=board/sunxi/README.sunxi64;hb=HEAD
>>
>>>
>>>
>>> Regards
>>> Kosta
>>>
>>>> -----Original Message-----
>>>> From: Andre Przywara [mailto:andre.przywara at arm.com]
>>>> Sent: Tuesday, July 18, 2017 17:45
>>>> To: Kostya Porotchkin
>>>> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT;
>>>> Antoine Tenart; Andreas Färber; U-Boot
>>>> Subject: [EXT] How to update Espressobin (U-Boot) firmware?
>>>>
>>>> External Email
>>>>
>>>> ---------------------------------------------------------------------
>>>> -
>>>> Hi,
>>>>
>>>> I wanted to exploit U-Boot's EFI support on the Espressobin board, to
>>>> use off-the-shelf arm64 distribution installer images. This should
>>>> work with current U-Boot, which has support for the Espressobin board
>>>> (and for UEFI).
>>>>
>>>> The firmware my board ships with seems to be built from older and
>>>> non- upstream sources - and, in contrast to the Macchiatobin board -
>>>> I cannot find either proper sources for all components (mv-ddr, ATF)
>>>> nor
>>>> *any* kind of instructions how to (re-)build and update the firmware.
>>>>
>>>> So I was wondering if there are any instructions or documentation I
>>>> missed on how to update at least U-Boot?
>>>>
>>>> I see some hints that people are apparently chain-loading mainline U-
>>>> Boot, is this the only way?
>>>> I dumped the SPI flash and could identify the ATF FIP image on it,
>>>> but I am a bit wary of bricking the board by just squashing a freshly
>>>> built u- boot.bin into that - which I guess wouldn't work that easily
>> anyway.
>>>>
>>>> And to allow experimentation: Are the boot selection jumpers actually
>>>> working? Setting them to SD card (111) doesn't seem to make a
>>>> difference (it still booted off the SPI flash, apparently). Or does
>>>> it fall back to SPI flash in case the SD image is not valid (I put
>>>> the dumped image at sector 1)?
>>>> I see that selecting "UART" (110) gives me that "E" prompt,
>>>> apparently waiting for some data to be fed, but again can't tell what
>>>> to do from here? I take it that mkimage/kwboot won't work as is, as
>>>> it needs ATF? I found some mentioning of a Windows binary, but hope
>>>> that's not the only way to use this mode?
>>>>
>>>> I'd be very grateful for any insight into this!
>>>>
>>>> Cheers,
>>>> Andre.

[U-Boot] How to update Espressobin (U-Boot) firmware?

[Kostya Porotchkin]

Hi, Andre,

> -----Original Message-----
> From: Andre Przywara [mailto:andre.przywara at arm.com]
> Sent: Wednesday, July 19, 2017 18:19
> To: Kostya Porotchkin
> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT;
> Antoine Tenart; Andreas Färber; U-Boot; Benjamin (Guodan) Huang
> Subject: Re: How to update Espressobin (U-Boot) firmware?
> 
> Hi Kosta,
> 
> thanks again for the instructions, though I feel the road there is still
> a bit bumpy and has some potholes ;-)
> 
[Konstantin Porotchkin] Until the WIKI instructions are ready, I will try to follow the entire build process out of Github sources and post you my results here.
> Here is what I did:
> 1) build u-boot.bin
> 2) build wtmi.bin (from the utils repo)
> 3) build ATF
> $ make USE_COHERENT_MEM=0 DEBUG=1 LOG_LEVEL=20 DDR_TOPOLOGY=2
> BOOTDEV=SPINOR WTMI_IMG=/path/to/wtmi.bin PLAT=a3700 all fip This breaks
> after having created fip.bin. I concatenated bl1.bin (padded to 128K)
> and fip.bin to atf.bin manually.
> 4) create the image description file (in the utils repo):
> ./buildtim.sh 0 SPINOR ./untrusted ./ CPU_800_DDR_800 2 0 1 ntim.txt
> 5) fixup the filenames in the generated text file (wtmi.bin and atf.bin)
> 6) create the image (utils repo):
> ./wtptp_tool/linux/TBB_linux -m 1 -r ntim.txt -V
> 
> From staring at the SPI dump in a hexeditor, I take it that:
> a) TIM_ATF.bin goes to 0
> b) wtmi.bin goes to 0x4000
> c) atf.bin goes to 0x15000
> 
> Is that about right? Is it that doimage from the ATF repo is supposed to
> glue this together (step 4-6), which for some reason doesn't work for
> me?
[Konstantin Porotchkin] It should not be THAT complex. You suppose to run few build commands and get the flash image ready with almost no effort. I am mostly working with another SoC family (A8K) and need to try this build by my own for refreshing the entire process in my memory.
If Benjamin (included in this thread) does not have the build recipe already, I will give you my compilation steps tomorrow.
> 
> Another issue seems to be that the UART download tool seems to be closed
> source only and only available from the Marvell "Extranet" under NDA?
[Konstantin Porotchkin] I think it's not an NDA issue. If the UART download tool currently not available in a source form, it probably will be supplied in August SW release (17.08). Anyway, I believe if this tool is missing, we can share it in the binary form as a temporary solution. I will update you about it after my build test.
> 
> From looking at the output of the "h" command in UART mode I guess this
> tools is just a glorious wrapper around spoon-feeding the generated
> binaries in 32-bit chunks into the respective SRAM regions, then execute
> them? Possibly also doing all those register setups (via MMIO) described
> in the ntim.txt/TIM_ATF.bin file?
> Which doesn't look too complicated to hack an Open Source tool for.
> Or is this tool actually available somewhere (either as source or as a
> binary)?
[Konstantin Porotchkin] The UART download tool is working with the SoC service CPU (Cortex-M3), which runs the BootROM. So the BootROM verifies the information received over the serial line and executes all required initializations. Some memory regions and registers are not accessible or cannot be modified by the application CPU, so only the service CPU can do the job.

Regards
Kosta
> 
> Cheers,
> Andre.
> 
> 
> On 18/07/17 16:32, Kostya Porotchkin wrote:
> > Hi, Andre,
> >
> >> -----Original Message-----
> >> From: Andre Przywara [mailto:andre.przywara at arm.com]
> >> Sent: Tuesday, July 18, 2017 18:24
> >> To: Kostya Porotchkin
> >> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT;
> >> Antoine Tenart; Andreas Färber; U-Boot; Benjamin (Guodan) Huang
> >> Subject: Re: [EXT] How to update Espressobin (U-Boot) firmware?
> >>
> >> Hi Kosta,
> >>
> >> On 18/07/17 16:13, Kostya Porotchkin wrote:
> >>> The A37xx SoC does not support boot from SD.
> >>
> >> Ah!
> >>
> >>> Only boot from eMMC is supported, however your board probably only
> >>> has
> >> soldering pads for the eMMC and not eMMC chip installed.
> >>> If you want to play with the bootloader without jeopardizing your
> >>> SPI
> >> image, you have to use either UART or SATA boot mode.
> >>
> >> Does SATA boot work like SD boot, where the boot image starts at
> >> sector 1? And it needs to be flagged as a SATA boot image, right?
> > [Konstantin Porotchkin] Correct. You can put it on LBA-1 or LBA-34 if
> you use GPT.
> > Just remember, this image is very special. It's actually a multipart
> > image that we merge into a single blob for easier usage with the u-
> boot "bubt" command.
> >
> >>
> >>> For the boot image build you will need to obtain the u-boot, ATF and
> >> the image building tools sources.
> >>> https://github.com/MarvellEmbeddedProcessors/atf-marvell/tree/atf-v1
> >>> .3
> >>> -armada-17.06
> >>> https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/tre
> >>> e/
> >>> A3700_utils-armada-17.06
> >>> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/tree/u-b
> >>> oo
> >>> t-2017.03-armada-17.06
> >>>
> >>> The "utils" git contains also the UART download tool.
> >>> It uses a proprietary download protocol and not xmodem one as in KW
> >> case.
> >>> The flash image structure on this platform also differs from KW, so
> >> please do not try to directly burn a "bin" or "kw" file created by
> >> the u-boot build system.
> >>> The ATF git from above already contains the required changes in the
> >> Makefile for running the additional steps of the final flash image
> >> formatting.
> >>> Additionally, the boot image contains a boot device information in
> >>> its
> >> header, so you cannot move SPI flash image to another boot device.
> >>>
> >>> For the boot loader build instructions please check the following
> >> documents:
> >>> https://github.com/MarvellEmbeddedProcessors/atf-marvell/blob/atf-v1
> >>> .3
> >>> -17.04/docs/marvell/build.txt
> >>> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-b
> >>> oo t-2017.03-armada-17.06/doc/mvebu/build.txt
> >>>
> >>> UART boot details:
> >>> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-b
> >>> oo t-2017.03-armada-17.06/doc/mvebu/uart_boot.txt
> >>
> >> Thanks a ton for those links and information, that was exactly what I
> >> was looking for!
> >> Do you mind if I (later ;-) write up those steps in a document which
> >> we merge into the repo?
> >> Something like [1], which proved useful in the past just to point
> >> people to - that would save you some typing as well ;-)
> > [Konstantin Porotchkin] Sure, any additional source of information
> would be great.
> > I just notified the Espressobin WIKI team about urgent need for this
> type of document and for an alternative boot source usage example.
> > Hope the new WIKI entry will be ready shortly.
> >
> > Regards
> > Kosta
> >>
> >> Cheers,
> >> Andre.
> >>
> >> [1]
> >> http://git.denx.de/?p=u-
> >> boot.git;a=blob;f=board/sunxi/README.sunxi64;hb=HEAD
> >>
> >>>
> >>>
> >>> Regards
> >>> Kosta
> >>>
> >>>> -----Original Message-----
> >>>> From: Andre Przywara [mailto:andre.przywara at arm.com]
> >>>> Sent: Tuesday, July 18, 2017 17:45
> >>>> To: Kostya Porotchkin
> >>>> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT;
> >>>> Antoine Tenart; Andreas Färber; U-Boot
> >>>> Subject: [EXT] How to update Espressobin (U-Boot) firmware?
> >>>>
> >>>> External Email
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> -
> >>>> Hi,
> >>>>
> >>>> I wanted to exploit U-Boot's EFI support on the Espressobin board,
> >>>> to use off-the-shelf arm64 distribution installer images. This
> >>>> should work with current U-Boot, which has support for the
> >>>> Espressobin board (and for UEFI).
> >>>>
> >>>> The firmware my board ships with seems to be built from older and
> >>>> non- upstream sources - and, in contrast to the Macchiatobin board
> >>>> - I cannot find either proper sources for all components (mv-ddr,
> >>>> ATF) nor
> >>>> *any* kind of instructions how to (re-)build and update the
> firmware.
> >>>>
> >>>> So I was wondering if there are any instructions or documentation I
> >>>> missed on how to update at least U-Boot?
> >>>>
> >>>> I see some hints that people are apparently chain-loading mainline
> >>>> U- Boot, is this the only way?
> >>>> I dumped the SPI flash and could identify the ATF FIP image on it,
> >>>> but I am a bit wary of bricking the board by just squashing a
> >>>> freshly built u- boot.bin into that - which I guess wouldn't work
> >>>> that easily
> >> anyway.
> >>>>
> >>>> And to allow experimentation: Are the boot selection jumpers
> >>>> actually working? Setting them to SD card (111) doesn't seem to
> >>>> make a difference (it still booted off the SPI flash, apparently).
> >>>> Or does it fall back to SPI flash in case the SD image is not valid
> >>>> (I put the dumped image at sector 1)?
> >>>> I see that selecting "UART" (110) gives me that "E" prompt,
> >>>> apparently waiting for some data to be fed, but again can't tell
> >>>> what to do from here? I take it that mkimage/kwboot won't work as
> >>>> is, as it needs ATF? I found some mentioning of a Windows binary,
> >>>> but hope that's not the only way to use this mode?
> >>>>
> >>>> I'd be very grateful for any insight into this!
> >>>>
> >>>> Cheers,
> >>>> Andre.

[U-Boot] How to update Espressobin (U-Boot) firmware?

[Kostya Porotchkin]

Hi, Andre,

Looks like I had enough time for trying the entire process today.
Please see my steps below.
The UART download tool seems to be missed in the "tools" folder.
I will ask if it possible to put the binary version somewhere until we got the new release with sources.
I probably have to build and try the SATA image as the next step.

BTW It was more complicated than I expected, probably since I usually only run the step 4.
Enjoy!

Regards
Kosta

#############################
# 1. Get sources from the GIT
#############################

mkdir /work/community && cd /work/community

git clone git at github.com:MarvellEmbeddedProcessors/atf-marvell.git -b atf-v1.3-armada-17.06
git clone https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell.git - b A3700_utils-armada-17.06
git clone git at github.com:MarvellEmbeddedProcessors/u-boot-marvell.git -b u-boot-2017.03-armada-17.06

##########################################################
# 2. TBB tool build - not sure if this step is needed
# or the build will be triggered by ATF build
# However I preferred to build it separately - this should
# be done only once anyway.
##########################################################

wget https://www.cryptopp.com/cryptopp565.zip
cd /work/community/A3700-utils-marvell/wtptp_tool/src/TBB_Linux && makedir -p lib/cryptpp565
cd lib/cryptpp565 && unzip /work/community/cryptopp565.zip

make -f GNUmakefile && cd ../../
make -f TBB_linux.mak LIBDIR=`pwd`/lib/cryptpp565

######################
# 3. WTMI binary build
######################

cd /work/community/A3700-utils-marvell/wtmi
make

###############################################
# 4. Build the u-boot, ATF and the flash image
###############################################

cd /work/community/u-boot-marvell

export CROSS_COMPILE=/opt/gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
export BL33=`pwd`/u-boot.bin
export ATF_DIR=/work/community/atf-marvell
export WTP=/work/community/A3700-utils-marvell
export WTMI_IMG=/work/community/A3700-utils-marvell/wtmi/build/wtmi.bin

make mrproper && make mvebu_espressobin-88f3720_defconfig && make

make -C ${ATF_DIR} distclean && make -C ${ATF_DIR} DDR_TOPOLOGY=0 BOOTDEV=SPINOR USE_COHERENT_MEM=0 LOG_LEVEL=20 PLAT=a3700 all fip

##########################################################
# The resulting images are in ${ATF_DIR}/build/a3700/release
# The "flash-image.bin" is the image for the boot source device
# (SPI NOR flash for the above example)
# The "uart-images.tgz" archive contains separate image
# components for UART download.
##########################################################


Regards
Kosta

> -----Original Message-----
> From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Kostya
> Porotchkin
> Sent: Wednesday, July 19, 2017 18:48
> To: Andre Przywara
> Cc: Thomas Petazzoni; Benjamin (Guodan) Huang; Marc Zyngier; U-Boot;
> Stefan Roese; Andreas F채rber
> Subject: [EXT] Re: [U-Boot] How to update Espressobin (U-Boot) firmware?
> 
> External Email
> 
> ----------------------------------------------------------------------
> Hi, Andre,
> 
> > -----Original Message-----
> > From: Andre Przywara [mailto:andre.przywara at arm.com]
> > Sent: Wednesday, July 19, 2017 18:19
> > To: Kostya Porotchkin
> > Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT;
> > Antoine Tenart; Andreas F채rber; U-Boot; Benjamin (Guodan) Huang
> > Subject: Re: How to update Espressobin (U-Boot) firmware?
> >
> > Hi Kosta,
> >
> > thanks again for the instructions, though I feel the road there is
> > still a bit bumpy and has some potholes ;-)
> >
> [Konstantin Porotchkin] Until the WIKI instructions are ready, I will
> try to follow the entire build process out of Github sources and post
> you my results here.
> > Here is what I did:
> > 1) build u-boot.bin
> > 2) build wtmi.bin (from the utils repo)
> > 3) build ATF
> > $ make USE_COHERENT_MEM=0 DEBUG=1 LOG_LEVEL=20 DDR_TOPOLOGY=2
> > BOOTDEV=SPINOR WTMI_IMG=/path/to/wtmi.bin PLAT=a3700 all fip This
> > breaks after having created fip.bin. I concatenated bl1.bin (padded to
> > 128K) and fip.bin to atf.bin manually.
> > 4) create the image description file (in the utils repo):
> > ./buildtim.sh 0 SPINOR ./untrusted ./ CPU_800_DDR_800 2 0 1 ntim.txt
> > 5) fixup the filenames in the generated text file (wtmi.bin and
> > atf.bin)
> > 6) create the image (utils repo):
> > ./wtptp_tool/linux/TBB_linux -m 1 -r ntim.txt -V
> >
> > From staring at the SPI dump in a hexeditor, I take it that:
> > a) TIM_ATF.bin goes to 0
> > b) wtmi.bin goes to 0x4000
> > c) atf.bin goes to 0x15000
> >
> > Is that about right? Is it that doimage from the ATF repo is supposed
> > to glue this together (step 4-6), which for some reason doesn't work
> > for me?
> [Konstantin Porotchkin] It should not be THAT complex. You suppose to
> run few build commands and get the flash image ready with almost no
> effort. I am mostly working with another SoC family (A8K) and need to
> try this build by my own for refreshing the entire process in my memory.
> If Benjamin (included in this thread) does not have the build recipe
> already, I will give you my compilation steps tomorrow.
> >
> > Another issue seems to be that the UART download tool seems to be
> > closed source only and only available from the Marvell "Extranet"
> under NDA?
> [Konstantin Porotchkin] I think it's not an NDA issue. If the UART
> download tool currently not available in a source form, it probably will
> be supplied in August SW release (17.08). Anyway, I believe if this tool
> is missing, we can share it in the binary form as a temporary solution.
> I will update you about it after my build test.
> >
> > From looking at the output of the "h" command in UART mode I guess
> > this tools is just a glorious wrapper around spoon-feeding the
> > generated binaries in 32-bit chunks into the respective SRAM regions,
> > then execute them? Possibly also doing all those register setups (via
> > MMIO) described in the ntim.txt/TIM_ATF.bin file?
> > Which doesn't look too complicated to hack an Open Source tool for.
> > Or is this tool actually available somewhere (either as source or as a
> > binary)?
> [Konstantin Porotchkin] The UART download tool is working with the SoC
> service CPU (Cortex-M3), which runs the BootROM. So the BootROM verifies
> the information received over the serial line and executes all required
> initializations. Some memory regions and registers are not accessible or
> cannot be modified by the application CPU, so only the service CPU can
> do the job.
> 
> Regards
> Kosta
> >
> > Cheers,
> > Andre.
> >
> >
> > On 18/07/17 16:32, Kostya Porotchkin wrote:
> > > Hi, Andre,
> > >
> > >> -----Original Message-----
> > >> From: Andre Przywara [mailto:andre.przywara at arm.com]
> > >> Sent: Tuesday, July 18, 2017 18:24
> > >> To: Kostya Porotchkin
> > >> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT;
> > >> Antoine Tenart; Andreas F채rber; U-Boot; Benjamin (Guodan) Huang
> > >> Subject: Re: [EXT] How to update Espressobin (U-Boot) firmware?
> > >>
> > >> Hi Kosta,
> > >>
> > >> On 18/07/17 16:13, Kostya Porotchkin wrote:
> > >>> The A37xx SoC does not support boot from SD.
> > >>
> > >> Ah!
> > >>
> > >>> Only boot from eMMC is supported, however your board probably only
> > >>> has
> > >> soldering pads for the eMMC and not eMMC chip installed.
> > >>> If you want to play with the bootloader without jeopardizing your
> > >>> SPI
> > >> image, you have to use either UART or SATA boot mode.
> > >>
> > >> Does SATA boot work like SD boot, where the boot image starts at
> > >> sector 1? And it needs to be flagged as a SATA boot image, right?
> > > [Konstantin Porotchkin] Correct. You can put it on LBA-1 or LBA-34
> > > if
> > you use GPT.
> > > Just remember, this image is very special. It's actually a multipart
> > > image that we merge into a single blob for easier usage with the u-
> > boot "bubt" command.
> > >
> > >>
> > >>> For the boot image build you will need to obtain the u-boot, ATF
> > >>> and
> > >> the image building tools sources.
> > >>> https://github.com/MarvellEmbeddedProcessors/atf-marvell/tree/atf-
> > >>> v1
> > >>> .3
> > >>> -armada-17.06
> > >>> https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/t
> > >>> re
> > >>> e/
> > >>> A3700_utils-armada-17.06
> > >>> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/tree/u
> > >>> -b
> > >>> oo
> > >>> t-2017.03-armada-17.06
> > >>>
> > >>> The "utils" git contains also the UART download tool.
> > >>> It uses a proprietary download protocol and not xmodem one as in
> > >>> KW
> > >> case.
> > >>> The flash image structure on this platform also differs from KW,
> > >>> so
> > >> please do not try to directly burn a "bin" or "kw" file created by
> > >> the u-boot build system.
> > >>> The ATF git from above already contains the required changes in
> > >>> the
> > >> Makefile for running the additional steps of the final flash image
> > >> formatting.
> > >>> Additionally, the boot image contains a boot device information in
> > >>> its
> > >> header, so you cannot move SPI flash image to another boot device.
> > >>>
> > >>> For the boot loader build instructions please check the following
> > >> documents:
> > >>> https://github.com/MarvellEmbeddedProcessors/atf-marvell/blob/atf-
> > >>> v1
> > >>> .3
> > >>> -17.04/docs/marvell/build.txt
> > >>> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u
> > >>> -b oo t-2017.03-armada-17.06/doc/mvebu/build.txt
> > >>>
> > >>> UART boot details:
> > >>> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u
> > >>> -b oo t-2017.03-armada-17.06/doc/mvebu/uart_boot.txt
> > >>
> > >> Thanks a ton for those links and information, that was exactly what
> > >> I was looking for!
> > >> Do you mind if I (later ;-) write up those steps in a document
> > >> which we merge into the repo?
> > >> Something like [1], which proved useful in the past just to point
> > >> people to - that would save you some typing as well ;-)
> > > [Konstantin Porotchkin] Sure, any additional source of information
> > would be great.
> > > I just notified the Espressobin WIKI team about urgent need for this
> > type of document and for an alternative boot source usage example.
> > > Hope the new WIKI entry will be ready shortly.
> > >
> > > Regards
> > > Kosta
> > >>
> > >> Cheers,
> > >> Andre.
> > >>
> > >> [1]
> > >> http://git.denx.de/?p=u-
> > >> boot.git;a=blob;f=board/sunxi/README.sunxi64;hb=HEAD
> > >>
> > >>>
> > >>>
> > >>> Regards
> > >>> Kosta
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Andre Przywara [mailto:andre.przywara at arm.com]
> > >>>> Sent: Tuesday, July 18, 2017 17:45
> > >>>> To: Kostya Porotchkin
> > >>>> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory
> > >>>> CLEMENT; Antoine Tenart; Andreas F채rber; U-Boot
> > >>>> Subject: [EXT] How to update Espressobin (U-Boot) firmware?
> > >>>>
> > >>>> External Email
> > >>>>
> > >>>> -----------------------------------------------------------------
> > >>>> --
> > >>>> --
> > >>>> -
> > >>>> Hi,
> > >>>>
> > >>>> I wanted to exploit U-Boot's EFI support on the Espressobin
> > >>>> board, to use off-the-shelf arm64 distribution installer images.
> > >>>> This should work with current U-Boot, which has support for the
> > >>>> Espressobin board (and for UEFI).
> > >>>>
> > >>>> The firmware my board ships with seems to be built from older and
> > >>>> non- upstream sources - and, in contrast to the Macchiatobin
> > >>>> board
> > >>>> - I cannot find either proper sources for all components (mv-ddr,
> > >>>> ATF) nor
> > >>>> *any* kind of instructions how to (re-)build and update the
> > firmware.
> > >>>>
> > >>>> So I was wondering if there are any instructions or documentation
> > >>>> I missed on how to update at least U-Boot?
> > >>>>
> > >>>> I see some hints that people are apparently chain-loading
> > >>>> mainline
> > >>>> U- Boot, is this the only way?
> > >>>> I dumped the SPI flash and could identify the ATF FIP image on
> > >>>> it, but I am a bit wary of bricking the board by just squashing a
> > >>>> freshly built u- boot.bin into that - which I guess wouldn't work
> > >>>> that easily
> > >> anyway.
> > >>>>
> > >>>> And to allow experimentation: Are the boot selection jumpers
> > >>>> actually working? Setting them to SD card (111) doesn't seem to
> > >>>> make a difference (it still booted off the SPI flash,
> apparently).
> > >>>> Or does it fall back to SPI flash in case the SD image is not
> > >>>> valid (I put the dumped image at sector 1)?
> > >>>> I see that selecting "UART" (110) gives me that "E" prompt,
> > >>>> apparently waiting for some data to be fed, but again can't tell
> > >>>> what to do from here? I take it that mkimage/kwboot won't work as
> > >>>> is, as it needs ATF? I found some mentioning of a Windows binary,
> > >>>> but hope that's not the only way to use this mode?
> > >>>>
> > >>>> I'd be very grateful for any insight into this!
> > >>>>
> > >>>> Cheers,
> > >>>> Andre.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] How to update Espressobin (U-Boot) firmware?

[Andre Przywara]

Hi,

On 19/07/17 17:37, Kostya Porotchkin wrote:
> Hi, Andre,
> 
> Looks like I had enough time for trying the entire process today.
> Please see my steps below.

Thanks very much. As I suspected it seems that I missed:
export WTP=/work/community/A3700-utils-marvell
before building ATF, so the ATF build system couldn't find the tools to
assemble the image. It looks like this should avoid my steps 4-6 and
indeed simplifies the process.

> The UART download tool seems to be missed in the "tools" folder.
> I will ask if it possible to put the binary version somewhere until we got the new release with sources.

Thanks, that would be very nice.

> I probably have to build and try the SATA image as the next step.

Yeah, that was my plan for tonight as well, since this would allow me to
experiment safely with the generated image.

Oh, BTW: Chain-loading mainline U-Boot worked quite nicely and I could
launch the generic debian-testing installer via EFI boot. The only issue
was that I was using the U-Boot DT directly, which isn't enough for the
kernel (missing clocks and interrupts). I will try to send some patches
to bring the U-Boot DT in sync with the kernel one. If this is in place,
one could simply attach some (UEFI enabled) USB pen drive and it should
start without further ado (given a newer U-Boot in the SPI flash with
EFI support).

Thanks again!

Cheers,
Andre.

> BTW It was more complicated than I expected, probably since I usually only run the step 4.
> Enjoy!
> 
> Regards
> Kosta
> 
> #############################
> # 1. Get sources from the GIT
> #############################
> 
> mkdir /work/community && cd /work/community
> 
> git clone git at github.com:MarvellEmbeddedProcessors/atf-marvell.git -b atf-v1.3-armada-17.06
> git clone https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell.git - b A3700_utils-armada-17.06
> git clone git at github.com:MarvellEmbeddedProcessors/u-boot-marvell.git -b u-boot-2017.03-armada-17.06
> 
> ##########################################################
> # 2. TBB tool build - not sure if this step is needed
> # or the build will be triggered by ATF build
> # However I preferred to build it separately - this should
> # be done only once anyway.
> ##########################################################
> 
> wget https://www.cryptopp.com/cryptopp565.zip
> cd /work/community/A3700-utils-marvell/wtptp_tool/src/TBB_Linux && makedir -p lib/cryptpp565
> cd lib/cryptpp565 && unzip /work/community/cryptopp565.zip
> 
> make -f GNUmakefile && cd ../../
> make -f TBB_linux.mak LIBDIR=`pwd`/lib/cryptpp565
> 
> ######################
> # 3. WTMI binary build
> ######################
> 
> cd /work/community/A3700-utils-marvell/wtmi
> make
> 
> ###############################################
> # 4. Build the u-boot, ATF and the flash image
> ###############################################
> 
> cd /work/community/u-boot-marvell
> 
> export CROSS_COMPILE=/opt/gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
> export BL33=`pwd`/u-boot.bin
> export ATF_DIR=/work/community/atf-marvell
> export WTP=/work/community/A3700-utils-marvell
> export WTMI_IMG=/work/community/A3700-utils-marvell/wtmi/build/wtmi.bin
> 
> make mrproper && make mvebu_espressobin-88f3720_defconfig && make
> 
> make -C ${ATF_DIR} distclean && make -C ${ATF_DIR} DDR_TOPOLOGY=0 BOOTDEV=SPINOR USE_COHERENT_MEM=0 LOG_LEVEL=20 PLAT=a3700 all fip
> 
> ##########################################################
> # The resulting images are in ${ATF_DIR}/build/a3700/release
> # The "flash-image.bin" is the image for the boot source device
> # (SPI NOR flash for the above example)
> # The "uart-images.tgz" archive contains separate image
> # components for UART download.
> ##########################################################
> 
> 
> Regards
> Kosta
> 
>> -----Original Message-----
>> From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Kostya
>> Porotchkin
>> Sent: Wednesday, July 19, 2017 18:48
>> To: Andre Przywara
>> Cc: Thomas Petazzoni; Benjamin (Guodan) Huang; Marc Zyngier; U-Boot;
>> Stefan Roese; Andreas F채rber
>> Subject: [EXT] Re: [U-Boot] How to update Espressobin (U-Boot) firmware?
>>
>> External Email
>>
>> ----------------------------------------------------------------------
>> Hi, Andre,
>>
>>> -----Original Message-----
>>> From: Andre Przywara [mailto:andre.przywara at arm.com]
>>> Sent: Wednesday, July 19, 2017 18:19
>>> To: Kostya Porotchkin
>>> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT;
>>> Antoine Tenart; Andreas F채rber; U-Boot; Benjamin (Guodan) Huang
>>> Subject: Re: How to update Espressobin (U-Boot) firmware?
>>>
>>> Hi Kosta,
>>>
>>> thanks again for the instructions, though I feel the road there is
>>> still a bit bumpy and has some potholes ;-)
>>>
>> [Konstantin Porotchkin] Until the WIKI instructions are ready, I will
>> try to follow the entire build process out of Github sources and post
>> you my results here.
>>> Here is what I did:
>>> 1) build u-boot.bin
>>> 2) build wtmi.bin (from the utils repo)
>>> 3) build ATF
>>> $ make USE_COHERENT_MEM=0 DEBUG=1 LOG_LEVEL=20 DDR_TOPOLOGY=2
>>> BOOTDEV=SPINOR WTMI_IMG=/path/to/wtmi.bin PLAT=a3700 all fip This
>>> breaks after having created fip.bin. I concatenated bl1.bin (padded to
>>> 128K) and fip.bin to atf.bin manually.
>>> 4) create the image description file (in the utils repo):
>>> ./buildtim.sh 0 SPINOR ./untrusted ./ CPU_800_DDR_800 2 0 1 ntim.txt
>>> 5) fixup the filenames in the generated text file (wtmi.bin and
>>> atf.bin)
>>> 6) create the image (utils repo):
>>> ./wtptp_tool/linux/TBB_linux -m 1 -r ntim.txt -V
>>>
>>> From staring at the SPI dump in a hexeditor, I take it that:
>>> a) TIM_ATF.bin goes to 0
>>> b) wtmi.bin goes to 0x4000
>>> c) atf.bin goes to 0x15000
>>>
>>> Is that about right? Is it that doimage from the ATF repo is supposed
>>> to glue this together (step 4-6), which for some reason doesn't work
>>> for me?
>> [Konstantin Porotchkin] It should not be THAT complex. You suppose to
>> run few build commands and get the flash image ready with almost no
>> effort. I am mostly working with another SoC family (A8K) and need to
>> try this build by my own for refreshing the entire process in my memory.
>> If Benjamin (included in this thread) does not have the build recipe
>> already, I will give you my compilation steps tomorrow.
>>>
>>> Another issue seems to be that the UART download tool seems to be
>>> closed source only and only available from the Marvell "Extranet"
>> under NDA?
>> [Konstantin Porotchkin] I think it's not an NDA issue. If the UART
>> download tool currently not available in a source form, it probably will
>> be supplied in August SW release (17.08). Anyway, I believe if this tool
>> is missing, we can share it in the binary form as a temporary solution.
>> I will update you about it after my build test.
>>>
>>> From looking at the output of the "h" command in UART mode I guess
>>> this tools is just a glorious wrapper around spoon-feeding the
>>> generated binaries in 32-bit chunks into the respective SRAM regions,
>>> then execute them? Possibly also doing all those register setups (via
>>> MMIO) described in the ntim.txt/TIM_ATF.bin file?
>>> Which doesn't look too complicated to hack an Open Source tool for.
>>> Or is this tool actually available somewhere (either as source or as a
>>> binary)?
>> [Konstantin Porotchkin] The UART download tool is working with the SoC
>> service CPU (Cortex-M3), which runs the BootROM. So the BootROM verifies
>> the information received over the serial line and executes all required
>> initializations. Some memory regions and registers are not accessible or
>> cannot be modified by the application CPU, so only the service CPU can
>> do the job.
>>
>> Regards
>> Kosta
>>>
>>> Cheers,
>>> Andre.
>>>
>>>
>>> On 18/07/17 16:32, Kostya Porotchkin wrote:
>>>> Hi, Andre,
>>>>
>>>>> -----Original Message-----
>>>>> From: Andre Przywara [mailto:andre.przywara at arm.com]
>>>>> Sent: Tuesday, July 18, 2017 18:24
>>>>> To: Kostya Porotchkin
>>>>> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT;
>>>>> Antoine Tenart; Andreas F채rber; U-Boot; Benjamin (Guodan) Huang
>>>>> Subject: Re: [EXT] How to update Espressobin (U-Boot) firmware?
>>>>>
>>>>> Hi Kosta,
>>>>>
>>>>> On 18/07/17 16:13, Kostya Porotchkin wrote:
>>>>>> The A37xx SoC does not support boot from SD.
>>>>>
>>>>> Ah!
>>>>>
>>>>>> Only boot from eMMC is supported, however your board probably only
>>>>>> has
>>>>> soldering pads for the eMMC and not eMMC chip installed.
>>>>>> If you want to play with the bootloader without jeopardizing your
>>>>>> SPI
>>>>> image, you have to use either UART or SATA boot mode.
>>>>>
>>>>> Does SATA boot work like SD boot, where the boot image starts at
>>>>> sector 1? And it needs to be flagged as a SATA boot image, right?
>>>> [Konstantin Porotchkin] Correct. You can put it on LBA-1 or LBA-34
>>>> if
>>> you use GPT.
>>>> Just remember, this image is very special. It's actually a multipart
>>>> image that we merge into a single blob for easier usage with the u-
>>> boot "bubt" command.
>>>>
>>>>>
>>>>>> For the boot image build you will need to obtain the u-boot, ATF
>>>>>> and
>>>>> the image building tools sources.
>>>>>> https://github.com/MarvellEmbeddedProcessors/atf-marvell/tree/atf-
>>>>>> v1
>>>>>> .3
>>>>>> -armada-17.06
>>>>>> https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/t
>>>>>> re
>>>>>> e/
>>>>>> A3700_utils-armada-17.06
>>>>>> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/tree/u
>>>>>> -b
>>>>>> oo
>>>>>> t-2017.03-armada-17.06
>>>>>>
>>>>>> The "utils" git contains also the UART download tool.
>>>>>> It uses a proprietary download protocol and not xmodem one as in
>>>>>> KW
>>>>> case.
>>>>>> The flash image structure on this platform also differs from KW,
>>>>>> so
>>>>> please do not try to directly burn a "bin" or "kw" file created by
>>>>> the u-boot build system.
>>>>>> The ATF git from above already contains the required changes in
>>>>>> the
>>>>> Makefile for running the additional steps of the final flash image
>>>>> formatting.
>>>>>> Additionally, the boot image contains a boot device information in
>>>>>> its
>>>>> header, so you cannot move SPI flash image to another boot device.
>>>>>>
>>>>>> For the boot loader build instructions please check the following
>>>>> documents:
>>>>>> https://github.com/MarvellEmbeddedProcessors/atf-marvell/blob/atf-
>>>>>> v1
>>>>>> .3
>>>>>> -17.04/docs/marvell/build.txt
>>>>>> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u
>>>>>> -b oo t-2017.03-armada-17.06/doc/mvebu/build.txt
>>>>>>
>>>>>> UART boot details:
>>>>>> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u
>>>>>> -b oo t-2017.03-armada-17.06/doc/mvebu/uart_boot.txt
>>>>>
>>>>> Thanks a ton for those links and information, that was exactly what
>>>>> I was looking for!
>>>>> Do you mind if I (later ;-) write up those steps in a document
>>>>> which we merge into the repo?
>>>>> Something like [1], which proved useful in the past just to point
>>>>> people to - that would save you some typing as well ;-)
>>>> [Konstantin Porotchkin] Sure, any additional source of information
>>> would be great.
>>>> I just notified the Espressobin WIKI team about urgent need for this
>>> type of document and for an alternative boot source usage example.
>>>> Hope the new WIKI entry will be ready shortly.
>>>>
>>>> Regards
>>>> Kosta
>>>>>
>>>>> Cheers,
>>>>> Andre.
>>>>>
>>>>> [1]
>>>>> http://git.denx.de/?p=u-
>>>>> boot.git;a=blob;f=board/sunxi/README.sunxi64;hb=HEAD
>>>>>
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Kosta
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Andre Przywara [mailto:andre.przywara at arm.com]
>>>>>>> Sent: Tuesday, July 18, 2017 17:45
>>>>>>> To: Kostya Porotchkin
>>>>>>> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory
>>>>>>> CLEMENT; Antoine Tenart; Andreas F채rber; U-Boot
>>>>>>> Subject: [EXT] How to update Espressobin (U-Boot) firmware?
>>>>>>>
>>>>>>> External Email
>>>>>>>
>>>>>>> -----------------------------------------------------------------
>>>>>>> --
>>>>>>> --
>>>>>>> -
>>>>>>> Hi,
>>>>>>>
>>>>>>> I wanted to exploit U-Boot's EFI support on the Espressobin
>>>>>>> board, to use off-the-shelf arm64 distribution installer images.
>>>>>>> This should work with current U-Boot, which has support for the
>>>>>>> Espressobin board (and for UEFI).
>>>>>>>
>>>>>>> The firmware my board ships with seems to be built from older and
>>>>>>> non- upstream sources - and, in contrast to the Macchiatobin
>>>>>>> board
>>>>>>> - I cannot find either proper sources for all components (mv-ddr,
>>>>>>> ATF) nor
>>>>>>> *any* kind of instructions how to (re-)build and update the
>>> firmware.
>>>>>>>
>>>>>>> So I was wondering if there are any instructions or documentation
>>>>>>> I missed on how to update at least U-Boot?
>>>>>>>
>>>>>>> I see some hints that people are apparently chain-loading
>>>>>>> mainline
>>>>>>> U- Boot, is this the only way?
>>>>>>> I dumped the SPI flash and could identify the ATF FIP image on
>>>>>>> it, but I am a bit wary of bricking the board by just squashing a
>>>>>>> freshly built u- boot.bin into that - which I guess wouldn't work
>>>>>>> that easily
>>>>> anyway.
>>>>>>>
>>>>>>> And to allow experimentation: Are the boot selection jumpers
>>>>>>> actually working? Setting them to SD card (111) doesn't seem to
>>>>>>> make a difference (it still booted off the SPI flash,
>> apparently).
>>>>>>> Or does it fall back to SPI flash in case the SD image is not
>>>>>>> valid (I put the dumped image at sector 1)?
>>>>>>> I see that selecting "UART" (110) gives me that "E" prompt,
>>>>>>> apparently waiting for some data to be fed, but again can't tell
>>>>>>> what to do from here? I take it that mkimage/kwboot won't work as
>>>>>>> is, as it needs ATF? I found some mentioning of a Windows binary,
>>>>>>> but hope that's not the only way to use this mode?
>>>>>>>
>>>>>>> I'd be very grateful for any insight into this!
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Andre.
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> https://lists.denx.de/listinfo/u-boot

[U-Boot] How to update Espressobin (U-Boot) firmware?

[Andreas Färber]

Hi,

Am 19.07.2017 um 18:50 schrieb Andre Przywara:
> On 19/07/17 17:37, Kostya Porotchkin wrote:
>> I probably have to build and try the SATA image as the next step.
> 
> Yeah, that was my plan for tonight as well, since this would allow me to
> experiment safely with the generated image.
> 
> Oh, BTW: Chain-loading mainline U-Boot worked quite nicely and I could
> launch the generic debian-testing installer via EFI boot. The only issue
> was that I was using the U-Boot DT directly, which isn't enough for the
> kernel (missing clocks and interrupts). I will try to send some patches
> to bring the U-Boot DT in sync with the kernel one. If this is in place,
> one could simply attach some (UEFI enabled) USB pen drive and it should
> start without further ado (given a newer U-Boot in the SPI flash with
> EFI support).

Which devices have you successfully enumerated on mainline U-Boot? Does
SATA work for you? I had reported an endless reset on another board. USB
was not quite working either last time I tried on the other board -
either the initial scan or a reset had similar symptoms to SATA.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[U-Boot] How to update Espressobin (U-Boot) firmware?

[Andre Przywara]

Hi,

On 19/07/17 17:58, Andreas Färber wrote:
> Hi,
> 
> Am 19.07.2017 um 18:50 schrieb Andre Przywara:
>> On 19/07/17 17:37, Kostya Porotchkin wrote:
>>> I probably have to build and try the SATA image as the next step.
>>
>> Yeah, that was my plan for tonight as well, since this would allow me to
>> experiment safely with the generated image.
>>
>> Oh, BTW: Chain-loading mainline U-Boot worked quite nicely and I could
>> launch the generic debian-testing installer via EFI boot. The only issue
>> was that I was using the U-Boot DT directly, which isn't enough for the
>> kernel (missing clocks and interrupts). I will try to send some patches
>> to bring the U-Boot DT in sync with the kernel one. If this is in place,
>> one could simply attach some (UEFI enabled) USB pen drive and it should
>> start without further ado (given a newer U-Boot in the SPI flash with
>> EFI support).
> 
> Which devices have you successfully enumerated on mainline U-Boot? Does
> SATA work for you? I had reported an endless reset on another board. USB
> was not quite working either last time I tried on the other board -
> either the initial scan or a reset had similar symptoms to SATA.

I was using USB (2.0), that worked with origin/master. I haven't tested
SATA yet, but will try tonight and let you know.

Cheers,
Andre.

[U-Boot] How to update Espressobin (U-Boot) firmware?

[André Przywara]

On 19/07/17 18:01, Andre Przywara wrote:

Hi Andreas,

> On 19/07/17 17:58, Andreas Färber wrote:
>> Hi,
>>
>> Am 19.07.2017 um 18:50 schrieb Andre Przywara:
>>> On 19/07/17 17:37, Kostya Porotchkin wrote:
>>>> I probably have to build and try the SATA image as the next step.
>>>
>>> Yeah, that was my plan for tonight as well, since this would allow me to
>>> experiment safely with the generated image.
>>>
>>> Oh, BTW: Chain-loading mainline U-Boot worked quite nicely and I could
>>> launch the generic debian-testing installer via EFI boot. The only issue
>>> was that I was using the U-Boot DT directly, which isn't enough for the
>>> kernel (missing clocks and interrupts). I will try to send some patches
>>> to bring the U-Boot DT in sync with the kernel one. If this is in place,
>>> one could simply attach some (UEFI enabled) USB pen drive and it should
>>> start without further ado (given a newer U-Boot in the SPI flash with
>>> EFI support).
>>
>> Which devices have you successfully enumerated on mainline U-Boot? Does
>> SATA work for you? I had reported an endless reset on another board. USB
>> was not quite working either last time I tried on the other board -
>> either the initial scan or a reset had similar symptoms to SATA.
> 
> I was using USB (2.0), that worked with origin/master. I haven't tested
> SATA yet, but will try tonight and let you know.

Quick update:
Indeed SATA does not work with mainline U-Boot, I see it probing, but it
apparently runs into a timeout. Also MMC (SD card) didn't work for me, I
think there was no device detected at all. USB works.
This was with chainloading U-Boot, so it might as well be a problem with
those devices not being turned off properly and/or the mainline init
code not being able to cope with all corner cases (like already
initialized devices).

All of MMC, USB and SATA work with the Marvell U-Boot version on the SPI
flash.

Unfortunately I can't do further tests or debugging at the moment
(although the build process now seems to work correctly), as I managed
to snap off the microUSB socket from my board (while pushing apparently
too hard to the SATA cable), so I lost console access and couldn't
recover yet. I didn't have success with a 1.8V serial adapter connected
to those UART pins on the JTAG header. I will try later to solder a TX
and RX wire to the PL2303 chip's pins directly (where I can measure 1.8V
in contrast to those JTAG header pins) - but only after my holidays ;-)

Cheers,
Andre.

[U-Boot] [EXT] Re: How to update Espressobin (U-Boot) firmware?

[Benjamin Huang]

Hi Andre,

Just FYI, if you want to build bootloader for SATA boot, please use the ATF build instructions like below:

make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 SECURE=0 CLOCKSPRESET=CPU_1000_DDR_800 DDR_TOPOLOGY=2 BOOTDEV=SATA PARTNUM=0 PLAT=a3700 WTP=`pwd`/../A3700-utils-marvell all fip

The A3700 bootROM has partition capability, so if you dd the flash-image.bin to a partition with type 0x4d, and the ESPRESSObin is able to find the bootloader at power up.  Of course you can dd to LBA0 to make it simpler.

Thanks,
Benjamin

-----Original Message-----
From: André Przywara [mailto:andre.przywara at arm.com] 
Sent: Sunday, July 23, 2017 2:06 PM
To: Andreas Färber <afaerber@suse.de>
Cc: Kostya Porotchkin <kostap@marvell.com>; Thomas Petazzoni <thomas.petazzoni@free-electrons.com>; Benjamin (Guodan) Huang <gdhuang@marvell.com>; Marc Zyngier <Marc.Zyngier@arm.com>; U-Boot <u-boot@lists.denx.de>; Stefan Roese <sr@denx.de>
Subject: [EXT] Re: How to update Espressobin (U-Boot) firmware?

External Email

----------------------------------------------------------------------
On 19/07/17 18:01, Andre Przywara wrote:

Hi Andreas,

> On 19/07/17 17:58, Andreas Färber wrote:
>> Hi,
>>
>> Am 19.07.2017 um 18:50 schrieb Andre Przywara:
>>> On 19/07/17 17:37, Kostya Porotchkin wrote:
>>>> I probably have to build and try the SATA image as the next step.
>>>
>>> Yeah, that was my plan for tonight as well, since this would allow me to
>>> experiment safely with the generated image.
>>>
>>> Oh, BTW: Chain-loading mainline U-Boot worked quite nicely and I could
>>> launch the generic debian-testing installer via EFI boot. The only issue
>>> was that I was using the U-Boot DT directly, which isn't enough for the
>>> kernel (missing clocks and interrupts). I will try to send some patches
>>> to bring the U-Boot DT in sync with the kernel one. If this is in place,
>>> one could simply attach some (UEFI enabled) USB pen drive and it should
>>> start without further ado (given a newer U-Boot in the SPI flash with
>>> EFI support).
>>
>> Which devices have you successfully enumerated on mainline U-Boot? Does
>> SATA work for you? I had reported an endless reset on another board. USB
>> was not quite working either last time I tried on the other board -
>> either the initial scan or a reset had similar symptoms to SATA.
> 
> I was using USB (2.0), that worked with origin/master. I haven't tested
> SATA yet, but will try tonight and let you know.

Quick update:
Indeed SATA does not work with mainline U-Boot, I see it probing, but it
apparently runs into a timeout. Also MMC (SD card) didn't work for me, I
think there was no device detected at all. USB works.
This was with chainloading U-Boot, so it might as well be a problem with
those devices not being turned off properly and/or the mainline init
code not being able to cope with all corner cases (like already
initialized devices).

All of MMC, USB and SATA work with the Marvell U-Boot version on the SPI
flash.

Unfortunately I can't do further tests or debugging at the moment
(although the build process now seems to work correctly), as I managed
to snap off the microUSB socket from my board (while pushing apparently
too hard to the SATA cable), so I lost console access and couldn't
recover yet. I didn't have success with a 1.8V serial adapter connected
to those UART pins on the JTAG header. I will try later to solder a TX
and RX wire to the PL2303 chip's pins directly (where I can measure 1.8V
in contrast to those JTAG header pins) - but only after my holidays ;-)

Cheers,
Andre.