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

Wed Sep 15 10:11:53 PDT 2021

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.
>
> 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.

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
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20210915/317fb457/attachment.sig>