On 10/12/20 8:45 PM, Tomasz Maciej Nowak wrote:
Hi.
W dniu 12.10.2020 o 16:32, Andre Heider pisze:
On 12/10/2020 12:21, Petr Štetiar wrote:
Hauke Mehrtens <ha...@hauke-m.de> [2020-10-11 20:41:21]:
Hi,
(I've expressed this already in my initial review[1] which was not addressed
and pushed anyway.)
+TFA_MAKE_FLAGS += \
+
CROSS_CM3=$(STAGING_DIR_IMAGE)/$(LINARO_NAME)-$(LINARO_RELEASE).$(LINARO_VERSION)/bin/arm-linux-gnueabi-
\
AFAIU this is Linux only toolchain, so we should either stop pretending, that
we support usage of FreeBSD/macOS as the build host OS or fix this for good.
As with other boards, we need a secondary cross compiler for a cortex m3 cpu
here. Yes, currently a linux binary toolchain is downloaded. It's not optimal,
and I'm not a fan of this solution either. But that's already used, this patch
doesn't change that fact.
But It'll force other targets to comply with that or workaround it.
Building a firmware for these boards is a total clusterfuck. So one goal of all
the espressobin PRs has been for openwrt to provide binary firmware files. With
that in mind I see two options:
1) Error out on !Linux build hosts. Maybe that's good enough, because we mainly
want it to work on buildbot
2) build a cm3 cross compiler
I'd go for 2), but the main question is if that's acceptable, because every
buildslave would need to build it. We just need a bare metal toolchain though,
so just binutils and gcc, no libc, g++ and whatnot. That's actually not as much
as it sounds. And if we had that, the sunxi and rockchip atf package could use
it too instead of downloading binaries (yay).
sunxi builds ATF/TF-A from source with the normal aarch64 toolchain we
also use for the rest of the system like the Linux kernel. Looks like
Allwinner has the best chip design here. ;-)
That's also what I suggested on the same PR [2]. But building another toolchain
consumes resources on buildbot and I think people managing buildbots won't like
that.
BTW I'm wondering why this can't be handled in the same way
arm-trusted-firmware-rockchip is?
For sunxi and rockchip, you start with an atf build, and then pass the filename
of the resulting binary to the u-boot build system.
U-Boot build system cares little for ATF. It doesn't need it to build itself.
For A3700, it's the other way around. You cannot ship atf binaries (yuck),
because atf is the last element in the build chain.
You can change that. The resulting bootloader is actually an FIP image[3]
packed with fiptool, which is part of ATF build system. You can build each
binary (wtmi, atf, u-boot) individually and later combine them with fiptool
(never done that personally). As I understand it, because fiptool is part of
ATF, the build process was tailored so that You can build ready-to-flash
bootloader in one go.
What could be done to split the process:
a) modify ATF Makefile to skip packaging the FIP image and do it when requested
from provided components,
b) build the wtmi binaries with https://github.com/atf-builds (I don't know if
that'll be accepted, since that's not exactly ATF and it needs additional
dependencies) or create another entity to do that,
c) download binaries and create the FIP image within ATF package.
or
a) modify ATF Makefile to skip packaging the FIP image and build ATF with wtmi
binaries with https://github.com/atf-builds,
b) download the binaries within ATF package,
c) add fiptool to tools,
d) combine binaries with fiptool in whichever OpenWrt buildroot place You want.
I don't have time to tackle that ATM and it's waaaay on the bottom on my ToDo
list with very low priority, so whoever has motivation and time please do.
I also do not like that we download an extra toolchain here, but I would
suggest to make this part Linux only for now. Building ATF and U-Boot
for A3700 should then only be selected on Linux hosts, but the rest like
mvebu Linux kernel and rootfs can still be build on Linux and macOS.
If someone wants to implement the better solution as proposed by Tomasz,
this would be nice.
For which image (wtmi, atf, u-boot) do we need the cortex m3 toolchain?
Hauke
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
