[PATCH v3] arm-trusted-firmware-mvebu: CZ.NIC's Secure Firmware bump to v2021.09.07

[Andre Heider]

Hi Josef,

On 15/09/2021 19:11, Josef Schlehofer wrote:
> 
> On 15. 09. 21 15:21, Andre Heider wrote:
>> On 14/09/2021 20:42, Josef Schlehofer wrote:
>>>
>>> On 14. 09. 21 20:21, Andre Heider wrote:
>>>> On 14/09/2021 19:59, Hauke Mehrtens wrote:
>>>>> On 9/14/21 10:50 AM, sean lee wrote:
>>>>>> bump version and remove patches that have been applied
>>>>>>
>>>>>> 176d701 wtmi: Wait 1s after putting PHYs INTn pin low
>>>>>> 2eeccfe wtmi: Change comment describing reset workaround
>>>>>> e8c94a5 wtmi: Count RAM size from both CS0 and CS1
>>>>>> 995979e wtmi: Rename macro
>>>>>> e29eb29 wtmi: soc: Fix start_ap_workaround() for TF-A with debug
>>>>>> 81245ed wtmi: Use constant name PLAT_MARVELL_MAILBOX_BASE
>>>>>> 18ccb83 wtmi: Do a proper UART reset with clock change as described
>>>>>> in spec
>>>>>> 15ff106 avs: Validate VDD value from OTP
>>>>>> 3f33626 fix: clock: a3700: change pwm clock for 600/600 and 1200/750
>>>>>> preset
>>>>>> fb5e436 wtmi: uart: fix UART baudrate divisor calculation
>>>>>>
>>>>>> Signed-off-by: sean lee <ilf at live.com>
>>>>>> ---
>>>>>>     .../boot/arm-trusted-firmware-mvebu/Makefile  |  4 +-
>>>>>>     ...ix-UART-baudrate-divisor-calculation.patch | 66
>>>>>> -------------------
>>>>>>     ...change-pwm-clock-for-600-600-and-120.patch | 48 --------------
>>>>>>     .../102-avs-Validate-VDD-value-from-OTP.patch | 52 ---------------
>>>>>>     4 files changed, 2 insertions(+), 168 deletions(-)
>>>>>>     delete mode 100644
>>>>>> package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/100-wtmi-uart-fix-UART-baudrate-divisor-calculation.patch
>>>>>>
>>>>>>
>>>>>>     delete mode 100644
>>>>>> package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/101-fix-clock-a3700-change-pwm-clock-for-600-600-and-120.patch
>>>>>>
>>>>>>
>>>>>>     delete mode 100644
>>>>>> package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/102-avs-Validate-VDD-value-from-OTP.patch
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> This is a little bit unrelated.
>>>>>
>>>>> Is the source code of image/a3700-utils/wtptp/linux/tbb_linux
>>>>> available   somewhere? I wanted to build mvebu/cortex53 on an aarch64
>>>>> host system and this file is only available for x86_64 and the
>>>>> compilation fails.
>>>>
>>>> Yeah, its source is bundled, and actually atf upstream recently
>>>> switched to building it instead of using the checked in binary.
>>> TBH, it was outdated, buggy and recent changes were not included in the
>>> bundled library as said here
>>> https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/commit/f014428f4bf7feafec1dcc4c37506d847718649a
>>>
>>>>
>>>> Building it requires cryptocpp though, which doesn't yet exists as
>>>> package. We don't really care about crypto since we're building just
>>>> an untrusted firmware, so I opted to revert to using the binary
>>>> instead. This is on top of the x86_64 binary toolchain too anyway.
>>>
>>> This one:
>>> https://github.com/BKPepe/openwrt/commit/42322bebc5804a99b60a5bb54200eeba0587076d
>>>
>>> worked for me. But I didn't send it yet as I didn't do run-time testing
>>> yet. I will do it soon.
>>
> Hi Andre,
> 
>> Maybe use a cryptocpp release tarball instead of a git clone? That'll
>> be faster and a smaller download.
>>
> I was thinking about it too, but I noticed that everything (=
> a3700-utils, etc.) we are downloading uses git clone while looking at
> the Makefile. This would be exception, so I keep it that way, but I
> don't mind git clone/release tarball.

mox-boot-builder is the exception (intentionally btw, a git tree 
backfires there, as it's using submodules and the OpenWrt buildsystem 
fetches all of those), but I don't care too much about what to use for 
cryptocpp here.

>> And I think you also need to bump the a3700-utils version to include
>> the build fixes?
> Yes and no. My idea was to send a single PR with two commits (cryptopp
> and update a3700-utils) once I could do run-time testing on Turris MOX
> either ESPRESSObin first with cryptopp and then with the update itself
> to be sure that it didn't break anything else, but still. We can do it
> in two steps, I mean PRs. Both approaches are OK with me.

Ok, sounds good to me!

> 
> Josef
>>
>>>>
>>>> See
>>>> package/boot/arm-trusted-firmware-mvebu/patches/001-imagetool.patch.
>>>>
>>>> If you get rid of that patch and add cryptocpp/host it should build it
>>>> automatically and use that instead. But that still leaves the issue
>>>> with the binary toolchain, no?
>>>>
>>>>>
>>>>> Building flash image
>>>>> /bin/sh: 1:
>>>>> /home/ubuntu/openwrt/openwrt/staging_dir/target-aarch64_cortex-a53_musl/image/a3700-utils/wtptp/linux/tbb_linux:
>>>>>
>>>>> Exec format error
>>>>> make[4]: *** [plat/marvell/armada/a3k/common/a3700_common.mk:186:
>>>>> /home/ubuntu/openwrt/openwrt/build_dir/target-aarch64_cortex-a53_musl/trusted-firmware-a-espressobin-512mb/trusted-firmware-a-2.5/build/a3700/release/flash-image.bin]
>>>>>
>>>>> Error 2
>>>>>
>>>>>
>>>>> ubuntu at instance-20210910-2105:~/openwrt/openwrt$ file
>>>>> /home/ubuntu/openwrt/openwrt/staging_dir/target-aarch64_cortex-a53_musl/image/a3700-utils/wtptp/linux/tbb_linux
>>>>>
>>>>>
>>>>> /home/ubuntu/openwrt/openwrt/staging_dir/target-aarch64_cortex-a53_musl/image/a3700-utils/wtptp/linux/tbb_linux:
>>>>>
>>>>> ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically
>>>>> linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux
>>>>> 2.6.24, BuildID[sha1]=8169eedf6eef4b1993a65a180baee3d31660c000, with
>>>>> debug_info, not stripped
>>>>> ubuntu at instance-20210910-2105:~/openwrt/openwrt$ uname -a
>>>>> Linux instance-20210910-2105 5.11.0-1017-oracle #18~20.04.1-Ubuntu
>>>>> SMP Fri Aug 27 11:09:43 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
>>>>> ubuntu at instance-20210910-2105:~/openwrt/openwrt$
>>>>>
>>>>> Hauke
>>>
>>>
>>>
>>> _______________________________________________
>>> openwrt-devel mailing list
>>> openwrt-devel at lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>>
> 
>