On 12/10/2020 22:16, Hauke Mehrtens wrote:
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. ;-)
Ah yes, right ;) (I mentioned it because there're binaries for it at the
atf-builds repo).
But crust and support for it for linux/u-boot is around the corner, and
then you require another cross compiler again, for the or1k arch.
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?
For wtmi.
Hauke
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
