| Message ID | 20201011184121.14056-1-hauke@hauke-m.de |
|---|---|
| State | Accepted |
| Delegated to: | Hauke Mehrtens |
| Headers | show |
| Series | build: Extract trusted-firmware-a.mk | expand |
Hauke Mehrtens <hauke@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. BTW I'm wondering why this can't be handled in the same way arm-trusted-firmware-rockchip is? 1. https://github.com/openwrt/openwrt/pull/2521#pullrequestreview-309946728 -- ynezz
On 12/10/2020 12:21, Petr Štetiar wrote: > Hauke Mehrtens <hauke@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 >
Hi. W dniu 12.10.2020 o 16:32, Andre Heider pisze: > On 12/10/2020 12:21, Petr Štetiar wrote: >> Hauke Mehrtens <hauke@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). 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. > >> >> 1. https://github.com/openwrt/openwrt/pull/2521#pullrequestreview-309946728 2. https://github.com/openwrt/openwrt/pull/2521#issuecomment-549079784 3. https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html#build-output Regards
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 <hauke@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
On 12/10/2020 20:45, 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 <hauke@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). > > 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. It doesn't, but for those platforms u-boot's binman is used to assemble a firmware in a digestible form. Which is why it's easy to ship atf binaries there. > >> >> 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. Worth mentioning is turrix mox, which has its own wtmi and firmware creation: https://gitlab.nic.cz/turris/mox-boot-builder/-/tree/master > 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. The whole build process with all its dependencies is a mess, there're even more ways to clean that up. But in the end anything that doesn't make it to atf's or u-boot's upstream is more or less unmaintainable. And that's probably not easy, since it implies testing on Marvell's end. > >> >>> >>> 1. https://github.com/openwrt/openwrt/pull/2521#pullrequestreview-309946728 > > 2. https://github.com/openwrt/openwrt/pull/2521#issuecomment-549079784 > 3. https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html#build-output > > Regards >
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 <hauke@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
Vladimir Vid <vladimir.vid@sartura.hr> [2020-10-12 19:23:37]: Hi, > I agree this was not the best solution but it works, and if you ask me I > would prefer functionality on some platforms rather that none. 1. I've provided feedback, asked your for changes, I was ignored 2. It doesn't work for the project as I've pointed out 3. Either provide suitable upstream solution or keep it in your local tree BTW why do you even ask for the review in the first place? Can't Luka just simply push it directly? What's the difference here? Reviewer's time. We could've spent that precious time on reviewing and merging other contributions. > We could always argue on that one. I don't personally use Mac, but from the > build guide I found it seems that a support was always a nightmare: > https://forum.archive.openwrt.org/viewtopic.php?id=34676; > https://openwrt.org/docs/guide-developer/buildroot.exigence.macosx It depends on your point of view. From my point of view it's not nightmare, I find it quite useful and informative. All of our GNUisms and bashisms. AFAIK Felix/nbd and Kevin/ldir (both core developers) are using macOS as their daily drivers. FYI ldir has even provided his macMini as GitLab runner for CI purposes, there is an effort to have FreeBSD CI[1] and there are still some people interested in the FreeBSD[2]. 1. https://builds.sr.ht/~aparcar/job/235519 2. https://github.com/openwrt/openwrt/pull/3110 > If you check step 4 from the first link: > > *Modifying Makefiles (e2fsprogs really doesn't like 64-bit Lion, and qemu > refuses to compile)* There is some misunderstanding here, we're talking about the main/core/master repository. Feeds (like the one in your example) might have different goals and usually different set of rules as well. > Does that mean we should also get rid of e2fsprogs and qemu as well because > they don't play nice with MacOS? I'm not the one to decide that, it's feed which has different maintainers, goals and rules. > Alternatively, I managed to find a way to get linaro working for both > FreeBSD and MacOS (on the first Google page!) in a couple of minutes and it > looks like a much less hassle than the core setup from the link above, > so I wouldn't agree that it can't be done. Good news, but I'm quite puzzled, why you didn't fixed it with that 1st page solution when I asked you to do so? > I agree with Andre's suggestions, we could simply mark the package broken > for non-linux platforms since ATF build is optional anyway and it would not > break anything. I don't agree. This would simply become precedent which might others try to follow and this would then turn into maintenance and support nightmare. From my point of view, OpenWrt project is not some random vendor tree, rather opposite. So the contribution either fits into the project or it should stay in the vendor tree until vendor has resources to upstream that stuff properly. So I see following solutions: 1. GNU/Linux host build system becomes mandatory (unlikely) 2. The package gets fixed so everyone can use it (would be nice) 3. The package gets removed from the tree -- ynezz
Hauke, On 11/10/2020 20:41, Hauke Mehrtens wrote: > From: Andre Heider <a.heider@gmail.com> > > The include/trusted-firmware-a.mk file is based on the > include/u-boot.mk file and should be used to build a Trusted Firmware-A > (TFA) which was previously named Arm trusted firmware. > > This is useful for targets where the TFA is board specific like for > Marvell SoCs and probably also NXP Layerscape SoCs. > > This also makes use of this abstraction in the > arm-trusted-firmware-mvebu package to build board specific ATF binaries. > > The ATF binaries will be automatically activated and build when the > board is selected in the normal build or all boards are selected. This > should also activate the build when build bot creates images. > > Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> is there anything left to be fixed or can this be pushed? Thanks, Andre
On 29/10/2020 08:53, Andre Heider wrote: > Hauke, > > On 11/10/2020 20:41, Hauke Mehrtens wrote: >> From: Andre Heider <a.heider@gmail.com> >> >> The include/trusted-firmware-a.mk file is based on the >> include/u-boot.mk file and should be used to build a Trusted Firmware-A >> (TFA) which was previously named Arm trusted firmware. >> >> This is useful for targets where the TFA is board specific like for >> Marvell SoCs and probably also NXP Layerscape SoCs. >> >> This also makes use of this abstraction in the >> arm-trusted-firmware-mvebu package to build board specific ATF binaries. >> >> The ATF binaries will be automatically activated and build when the >> board is selected in the normal build or all boards are selected. This >> should also activate the build when build bot creates images. >> >> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> > > is there anything left to be fixed or can this be pushed? ping? anyone? bueller? > > Thanks, > Andre
diff --git a/include/trusted-firmware-a.mk b/include/trusted-firmware-a.mk new file mode 100644 index 000000000000..b89014b249a4 --- /dev/null +++ b/include/trusted-firmware-a.mk @@ -0,0 +1,93 @@ +PKG_NAME ?= trusted-firmware-a + +ifndef PKG_SOURCE_PROTO +PKG_SOURCE = trusted-firmware-a-$(PKG_VERSION).tar.gz +PKG_SOURCE_URL:=https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/snapshot +endif + +PKG_BUILD_DIR = $(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION) + +PKG_TARGETS := bin +PKG_FLAGS:=nonshared + +PKG_LICENSE:=BSD-3-Clause +PKG_LICENSE_FILES:=docs/license.rst + +PKG_BUILD_PARALLEL:=1 + +export GCC_HONOUR_COPTS=s + +define Package/trusted-firmware-a/install/default + $(CP) $(patsubst %,$(PKG_BUILD_DIR)/build/$(PLAT)/release/%,$(TFA_IMAGE)) $(1)/ +endef + +Package/trusted-firmware-a/install = $(Package/trusted-firmware-a/install/default) + +define Trusted-Firmware-A/Init + BUILD_TARGET:= + BUILD_SUBTARGET:= + BUILD_DEVICES:= + NAME:= + DEPENDS:= + HIDDEN:= + DEFAULT:= + PLAT:= + VARIANT:=$(1) + TFA_IMAGE:= +endef + +TARGET_DEP = TARGET_$(BUILD_TARGET)$(if $(BUILD_SUBTARGET),_$(BUILD_SUBTARGET)) + +define Build/Trusted-Firmware-A/Target + $(eval $(call Trusted-Firmware-A/Init,$(1))) + $(eval $(call Trusted-Firmware-A/Default,$(1))) + $(eval $(call Trusted-Firmware-A/$(1),$(1))) + + define Package/trusted-firmware-a-$(1) + SECTION:=boot + CATEGORY:=Boot Loaders + TITLE:=Trusted-Firmware-A for $(NAME) + VARIANT:=$(VARIANT) + DEPENDS:=@!IN_SDK $(DEPENDS) + HIDDEN:=$(HIDDEN) + ifneq ($(BUILD_TARGET),) + DEPENDS += @$(TARGET_DEP) + ifneq ($(BUILD_DEVICES),) + DEFAULT := y if ($(TARGET_DEP)_Default \ + $(patsubst %,|| $(TARGET_DEP)_DEVICE_%,$(BUILD_DEVICES)) \ + $(patsubst %,|| $(patsubst TARGET_%,TARGET_DEVICE_%,$(TARGET_DEP))_DEVICE_%,$(BUILD_DEVICES))) + endif + endif + $(if $(DEFAULT),DEFAULT:=$(DEFAULT)) + URL:=https://www.trustedfirmware.org/projects/tf-a/ + endef + + define Package/trusted-firmware-a-$(1)/install + $$(Package/trusted-firmware-a/install) + endef +endef + + +define Build/Compile/Trusted-Firmware-A + +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \ + CROSS_COMPILE=$(TARGET_CROSS) \ + OPENSSL_DIR=$(STAGING_DIR_HOST) \ + PLAT=$(PLAT) \ + $(TFA_MAKE_FLAGS) +endef + +define BuildPackage/Trusted-Firmware-A/Defaults + Build/Configure/Default = $$$$(Build/Configure/Trusted-Firmware-A) + Build/Compile/Default = $$$$(Build/Compile/Trusted-Firmware-A) +endef + +define BuildPackage/Trusted-Firmware-A + $(eval $(call BuildPackage/Trusted-Firmware-A/Defaults)) + $(foreach type,$(if $(DUMP),$(TFA_TARGETS),$(BUILD_VARIANT)), \ + $(eval $(call Build/Trusted-Firmware-A/Target,$(type))) + ) + $(eval $(call Build/DefaultTargets)) + $(foreach type,$(if $(DUMP),$(TFA_TARGETS),$(BUILD_VARIANT)), \ + $(call BuildPackage,trusted-firmware-a-$(type)) + ) +endef diff --git a/package/boot/arm-trusted-firmware-mvebu/Makefile b/package/boot/arm-trusted-firmware-mvebu/Makefile index 38dd9d163529..1f84b8eb1929 100644 --- a/package/boot/arm-trusted-firmware-mvebu/Makefile +++ b/package/boot/arm-trusted-firmware-mvebu/Makefile @@ -7,149 +7,170 @@ include $(TOPDIR)/rules.mk -PKG_NAME:=arm-trusted-firmware-mvebu PKG_VERSION:=2.3 PKG_RELEASE:=1 - -PKG_SOURCE:=trusted-firmware-a-$(PKG_VERSION).tar.gz -PKG_SOURCE_URL:=https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/snapshot PKG_HASH:=37f917922bcef181164908c470a2f941006791c0113d738c498d39d95d543b21 -PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/trusted-firmware-a-$(PKG_VERSION) - -PKG_LICENSE:=BSD-3-Clause -PKG_LICENSE_FILES:=docs/license.rst PKG_MAINTAINER:=Vladimir Vid <vladimir.vid@sartura.hr> +include $(INCLUDE_DIR)/trusted-firmware-a.mk include $(INCLUDE_DIR)/package.mk -define Package/arm-trusted-firmware-mvebu - SECTION:=boot - CATEGORY:=Boot Loaders - DEPENDS:=@TARGET_mvebu_cortexa53 - VARIANT:=$(subst arm-trusted-firmware-mvebu-,,$(1)) +define Trusted-Firmware-A/Default + BUILD_TARGET:=mvebu + BUILD_SUBTARGET:=cortexa53 + TFA_IMAGE:=flash-image.bin uart-images.tgz + UBOOT:= + DDR_TOPOLOGY:= + CLOCKSPRESET:= endef -define Package/arm-trusted-firmware-mvebu-espressobin-512mb - $(Package/arm-trusted-firmware-mvebu) - TITLE:=ARM Trusted Firmware for Marvell ESPRESSObin (512MB) + +define Trusted-Firmware-A/espressobin-512mb + NAME:=Marvell ESPRESSObin (512MB) DEPENDS:=+u-boot-espressobin + BUILD_DEVICES:=globalscale_espressobin UBOOT:=espressobin DDR_TOPOLOGY:=0 CLOCKSPRESET:=CPU_800_DDR_800 PLAT:=a3700 endef -define Package/arm-trusted-firmware-mvebu-espressobin-v3-v5-1gb-1cs - $(Package/arm-trusted-firmware-mvebu) - TITLE:=ARM Trusted Firmware for Marvell ESPRESSObin V3-V5 (1GB 1CS) +define Trusted-Firmware-A/espressobin-v3-v5-1gb-1cs + NAME:=Marvell ESPRESSObin V3-V5 (1GB 1CS) DEPENDS:=+u-boot-espressobin + BUILD_DEVICES:=globalscale_espressobin UBOOT:=espressobin DDR_TOPOLOGY:=4 CLOCKSPRESET:=CPU_800_DDR_800 PLAT:=a3700 endef -define Package/arm-trusted-firmware-mvebu-espressobin-v3-v5-1gb-1cs-emmc - $(Package/arm-trusted-firmware-mvebu) - TITLE:=ARM Trusted Firmware for Marvell ESPRESSObin V3-V5 (1GB 1CS, eMMC) +define Trusted-Firmware-A/espressobin-v3-v5-1gb-1cs-emmc + NAME:=Marvell ESPRESSObin V3-V5 (1GB 1CS, eMMC) DEPENDS:=+u-boot-espressobin-emmc + BUILD_DEVICES:=globalscale_espressobin-emmc UBOOT:=espressobin-emmc DDR_TOPOLOGY:=4 CLOCKSPRESET:=CPU_800_DDR_800 PLAT:=a3700 endef -define Package/arm-trusted-firmware-mvebu-espressobin-v3-v5-1gb-2cs - $(Package/arm-trusted-firmware-mvebu) - TITLE:=ARM Trusted Firmware for Marvell ESPRESSObin V3-V5 (1GB, 2CS) +define Trusted-Firmware-A/espressobin-v3-v5-1gb-2cs + NAME:=Marvell ESPRESSObin V3-V5 (1GB, 2CS) DEPENDS:=+u-boot-espressobin + BUILD_DEVICES:=globalscale_espressobin UBOOT:=espressobin DDR_TOPOLOGY:=2 CLOCKSPRESET:=CPU_800_DDR_800 PLAT:=a3700 endef -define Package/arm-trusted-firmware-mvebu-espressobin-v3-v5-1gb-2cs-emmc - $(Package/arm-trusted-firmware-mvebu) - TITLE:=ARM Trusted Firmware for Marvell ESPRESSObin V3-V5 (1GB 2CS, eMMC) +define Trusted-Firmware-A/espressobin-v3-v5-1gb-2cs-emmc + NAME:=Marvell ESPRESSObin V3-V5 (1GB 2CS, eMMC) DEPENDS:=+u-boot-espressobin-emmc + BUILD_DEVICES:=globalscale_espressobin-emmc UBOOT:=espressobin-emmc DDR_TOPOLOGY:=2 CLOCKSPRESET:=CPU_800_DDR_800 PLAT:=a3700 endef -define Package/arm-trusted-firmware-mvebu-espressobin-v3-v5-2gb - $(Package/arm-trusted-firmware-mvebu) - TITLE:=ARM Trusted Firmware for Marvell ESPRESSObin V3-V5 (2GB) +define Trusted-Firmware-A/espressobin-v3-v5-2gb + NAME:=Marvell ESPRESSObin V3-V5 (2GB) DEPENDS:=+u-boot-espressobin + BUILD_DEVICES:=globalscale_espressobin UBOOT:=espressobin DDR_TOPOLOGY:=7 CLOCKSPRESET:=CPU_800_DDR_800 PLAT:=a3700 endef -define Package/arm-trusted-firmware-mvebu-espressobin-v3-v5-2gb-emmc - $(Package/arm-trusted-firmware-mvebu) - TITLE:=ARM Trusted Firmware for Marvell ESPRESSObin V3-V5 (2GB, eMMC) +define Trusted-Firmware-A/espressobin-v3-v5-2gb-emmc + NAME:=Marvell ESPRESSObin V3-V5 (2GB, eMMC) DEPENDS:=+u-boot-espressobin-emmc + BUILD_DEVICES:=globalscale_espressobin-emmc UBOOT:=espressobin-emmc DDR_TOPOLOGY:=7 CLOCKSPRESET:=CPU_800_DDR_800 PLAT:=a3700 endef -define Package/arm-trusted-firmware-mvebu-espressobin-v7-1gb - $(Package/arm-trusted-firmware-mvebu) - TITLE:=ARM Trusted Firmware for Marvell ESPRESSObin V7 (1GB) +define Trusted-Firmware-A/espressobin-v7-1gb + NAME:=Marvell ESPRESSObin V7 (1GB) DEPENDS:=+u-boot-espressobin + BUILD_DEVICES:=globalscale_espressobin-v7 UBOOT:=espressobin DDR_TOPOLOGY:=5 CLOCKSPRESET:=CPU_800_DDR_800 PLAT:=a3700 endef -define Package/arm-trusted-firmware-mvebu-espressobin-v7-1gb-emmc - $(Package/arm-trusted-firmware-mvebu) - TITLE:=ARM Trusted Firmware for Marvell ESPRESSObin V7 (1GB, eMMC) +define Trusted-Firmware-A/espressobin-v7-1gb-emmc + NAME:=Marvell ESPRESSObin V7 (1GB, eMMC) DEPENDS:=+u-boot-espressobin + BUILD_DEVICES:=globalscale_espressobin-v7-emmc UBOOT:=espressobin-emmc DDR_TOPOLOGY:=5 CLOCKSPRESET:=CPU_800_DDR_800 PLAT:=a3700 endef -define Package/arm-trusted-firmware-mvebu-espressobin-v7-2gb - $(Package/arm-trusted-firmware-mvebu) - TITLE:=ARM Trusted Firmware for Marvell ESPRESSObin V7 (2GB) +define Trusted-Firmware-A/espressobin-v7-2gb + NAME:=Marvell ESPRESSObin V7 (2GB) DEPENDS:=+u-boot-espressobin + BUILD_DEVICES:=globalscale_espressobin-v7 UBOOT:=espressobin DDR_TOPOLOGY:=6 CLOCKSPRESET:=CPU_800_DDR_800 PLAT:=a3700 endef -define Package/arm-trusted-firmware-mvebu-espressobin-v7-2gb-emmc - $(Package/arm-trusted-firmware-mvebu) - TITLE:=ARM Trusted Firmware for Marvell ESPRESSObin V7 (2GB, eMMC) +define Trusted-Firmware-A/espressobin-v7-2gb-emmc + NAME:=Marvell ESPRESSObin V7 (2GB, eMMC) DEPENDS:=+u-boot-espressobin + BUILD_DEVICES:=globalscale_espressobin-v7-emmc UBOOT:=espressobin-emmc DDR_TOPOLOGY:=6 CLOCKSPRESET:=CPU_800_DDR_800 PLAT:=a3700 endef -define Package/arm-trusted-firmware-mvebu-udpu - $(Package/arm-trusted-firmware-mvebu) - TITLE:=ARM Trusted Firmware for Methode uDPU +define Trusted-Firmware-A/udpu + NAME:=Methode uDPU DEPENDS:=+u-boot-uDPU + BUILD_DEVICES:=methode_udpu UBOOT:=uDPU DDR_TOPOLOGY:=0 CLOCKSPRESET:=CPU_1000_DDR_800 PLAT:=a3700 endef + +TFA_TARGETS:= \ + espressobin-512mb \ + espressobin-v3-v5-1gb-1cs \ + espressobin-v3-v5-1gb-1cs-emmc \ + espressobin-v3-v5-1gb-2cs \ + espressobin-v3-v5-1gb-2cs-emmc \ + espressobin-v3-v5-2gb \ + espressobin-v3-v5-2gb-emmc \ + espressobin-v7-1gb \ + espressobin-v7-1gb-emmc \ + espressobin-v7-2gb \ + espressobin-v7-2gb-emmc \ + udpu + +TFA_MAKE_FLAGS += \ + CROSS_CM3=$(STAGING_DIR_IMAGE)/$(LINARO_NAME)-$(LINARO_RELEASE).$(LINARO_VERSION)/bin/arm-linux-gnueabi- \ + BL33=$(STAGING_DIR_IMAGE)/$(UBOOT)-u-boot.bin \ + MV_DDR_PATH=$(STAGING_DIR_IMAGE)/$(MV_DDR_NAME) \ + WTP=$(STAGING_DIR_IMAGE)/$(A3700_UTILS_NAME) \ + DDR_TOPOLOGY=$(DDR_TOPOLOGY) \ + CLOCKSPRESET=$(CLOCKSPRESET) \ + all \ + fip + A3700_UTILS_NAME:=a3700-utils A3700_UTILS_RELEASE:=09679790 A3700_UTILS_SOURCE=$(A3700_UTILS_NAME)-$(A3700_UTILS_RELEASE).tar.bz2 @@ -201,41 +222,4 @@ define Build/Prepare $(TAR) -C $(STAGING_DIR_IMAGE) -xf $(DL_DIR)/$(LINARO_SOURCE) endef -export GCC_HONOUR_COPTS=s - -TARGET_CFLAGS = "" - -define Build/Compile - $(eval $(Package/arm-trusted-firmware-mvebu-$(BUILD_VARIANT))) \ - $(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \ - CROSS_COMPILE=$(TARGET_CROSS) \ - OPENSSL_DIR=$(STAGING_DIR_HOST) \ - CROSS_CM3=$(STAGING_DIR_IMAGE)/$(LINARO_NAME)-$(LINARO_RELEASE).$(LINARO_VERSION)/bin/arm-linux-gnueabi- \ - BL33=$(STAGING_DIR_IMAGE)/$(UBOOT)-u-boot.bin \ - MV_DDR_PATH=$(STAGING_DIR_IMAGE)/$(MV_DDR_NAME) \ - WTP=$(STAGING_DIR_IMAGE)/$(A3700_UTILS_NAME) \ - DDR_TOPOLOGY=$(DDR_TOPOLOGY) \ - CLOCKSPRESET=$(CLOCKSPRESET) \ - PLAT=$(PLAT) \ - all \ - fip -endef - -define Build/InstallDev - $(INSTALL_DIR) $(BIN_DIR)/flash-image-$(BUILD_VARIANT) - $(CP) $(PKG_BUILD_DIR)/build/$(PLAT)/release/flash-image.bin $(BIN_DIR)/flash-image-$(BUILD_VARIANT)/ - $(CP) $(PKG_BUILD_DIR)/build/$(PLAT)/release/uart-images.tgz $(BIN_DIR)/flash-image-$(BUILD_VARIANT)/ -endef - -$(eval $(call BuildPackage,arm-trusted-firmware-mvebu-espressobin-512mb)) -$(eval $(call BuildPackage,arm-trusted-firmware-mvebu-espressobin-v3-v5-1gb-1cs)) -$(eval $(call BuildPackage,arm-trusted-firmware-mvebu-espressobin-v3-v5-1gb-1cs-emmc)) -$(eval $(call BuildPackage,arm-trusted-firmware-mvebu-espressobin-v3-v5-1gb-2cs)) -$(eval $(call BuildPackage,arm-trusted-firmware-mvebu-espressobin-v3-v5-1gb-2cs-emmc)) -$(eval $(call BuildPackage,arm-trusted-firmware-mvebu-espressobin-v3-v5-2gb)) -$(eval $(call BuildPackage,arm-trusted-firmware-mvebu-espressobin-v3-v5-2gb-emmc)) -$(eval $(call BuildPackage,arm-trusted-firmware-mvebu-espressobin-v7-1gb)) -$(eval $(call BuildPackage,arm-trusted-firmware-mvebu-espressobin-v7-1gb-emmc)) -$(eval $(call BuildPackage,arm-trusted-firmware-mvebu-espressobin-v7-2gb)) -$(eval $(call BuildPackage,arm-trusted-firmware-mvebu-espressobin-v7-2gb-emmc)) -$(eval $(call BuildPackage,arm-trusted-firmware-mvebu-udpu)) +$(eval $(call BuildPackage/Trusted-Firmware-A))