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.
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).
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.
For A3700, it's the other way around. You cannot ship atf binaries
(yuck), because atf is the last element in the build chain.
1. https://github.com/openwrt/openwrt/pull/2521#pullrequestreview-309946728
-- ynezz
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
