From: "Denys Dmytriyenko" <denis@denix.org>
To: Joshua Watt <JPEWhacker@gmail.com>
Cc: Khem Raj <raj.khem@gmail.com>,
yocto@lists.yoctoproject.org, Trevor Woerner <twoerner@gmail.com>
Subject: Re: [yocto][meta-rockchip][PATCH 2/4] gcc-arm-none-eabi-native: Add recipe
Date: Thu, 23 Jan 2020 15:46:08 -0500 [thread overview]
Message-ID: <20200123204608.GD4735@denix.org> (raw)
In-Reply-To: <79f3d4de-e3b1-53da-b25e-c62214d20034@gmail.com>
On Thu, Jan 23, 2020 at 02:14:57PM -0600, Joshua Watt wrote:
>
> On 1/23/20 2:06 PM, Khem Raj wrote:
> >On Thu, Jan 23, 2020 at 11:59 AM Joshua Watt <jpewhacker@gmail.com> wrote:
> >>
> >>On 1/23/20 1:49 PM, Khem Raj wrote:
> >>>On Thu, Jan 23, 2020 at 8:08 AM Joshua Watt <JPEWhacker@gmail.com> wrote:
> >>>>Adds a recipe to pull down the prebuilt GCC for compiling on Cortex-R
> >>>>and Cortex-M processors from ARM. This toolchain is required to build
> >>>>Arm Trusted Firmware for the Rockchip rk3399 SoC, since it must compile
> >>>>some firmware for the M0 coprocessor.
> >>>>
> >>>can this use mutliconfig ?
> >>>This seems then can be avoided
> >>I'm not sure if multiconfig is applicable in this case; This is required
> >>because the same recipe (arm-trusted-firmware) requires 2 different
> >>compilers to be available; the target compiler (aarch64-poky-linux), and
> >>an arm-none-eabi-gcc compiler specifically to compile some M0 firmware
> >>that goes into ATF.
> >>
> >>Multiconfig would work (I think), if the recipe only needed one or the
> >>other, but not in this case where it needs both.
> >right, so question is if this recipe can be effectively two such recipes. If not
> >then perhaps this solution is ok or perhaps we can just use prebuilts for the M0
>
> It *might* be possible to build it in two passes, but I'd rather not
> because its not the way the ATF is intended to be built. The code
> currently expects that it can build with the arm-none-eabi-gcc, so
> anything thing we do differently is more likely to break. Right now,
> the AFT recipe should be pretty easy to maintain; breaking it apart
> will make it quite a bit more complicated.
>
> I'd rather have a prebuilt (for now) GCC building some firmware from
> source that download a prebuilt firmware image :)
>
> Like I said, long term I'd like to build up the arm-none-eabi-gcc
> from gcc-cross in OE-core, I just haven't figured out the best way
> to do that yet.
Ha, this is quite familiar as well! We had these gcc-arm-none-eabi-native and
other recipes in meta-ti for compiling different pieces for secondary cores in
our SoCs - MCUs, DSPs, etc. That was way before multiconfig was available.
Recently I was looking into converting the old model into multiconfig - there
was a discussion with fray last month regarding this and he posted a more
generic proposal to oe-architecture list. I still need to get back to that
activity - kind of got busy after the holidays...
--
Denys
> >>I also looked at building an additional gcc-cross recipe that explicitly
> >>targets arm-none-eabi, but the maintenance was going to be a pain unless
> >>A) the recipe lived in OE-core or B) this layer copied all of the GCC
> >>recipes. Neither of those was appealing at the moment, but I plan on
> >>revisiting it. Even when I did have it in OE-core, I had some trouble
> >>with some manifest warnings, so I'm not quite sure I was doing it correctly.
> >>
> >>>>Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
> >>>>---
> >>>> ...cc-arm-none-eabi-native_9-2019-q4-major.bb | 37 +++++++++++++++++++
> >>>> 1 file changed, 37 insertions(+)
> >>>> create mode 100644 recipes-devtools/gcc-arm-none-eabi/gcc-arm-none-eabi-native_9-2019-q4-major.bb
> >>>>
> >>>>diff --git a/recipes-devtools/gcc-arm-none-eabi/gcc-arm-none-eabi-native_9-2019-q4-major.bb b/recipes-devtools/gcc-arm-none-eabi/gcc-arm-none-eabi-native_9-2019-q4-major.bb
> >>>>new file mode 100644
> >>>>index 0000000..a0c832d
> >>>>--- /dev/null
> >>>>+++ b/recipes-devtools/gcc-arm-none-eabi/gcc-arm-none-eabi-native_9-2019-q4-major.bb
> >>>>@@ -0,0 +1,37 @@
> >>>>+# Copyright (C) 2019 Garmin Ltd. or its subsidaries
> >>>>+# Released under the MIT license (see COPYING.MIT for the terms)
> >>>>+
> >>>>+DESCRIPTION = "Baremetal GCC for ARM-R and ARM-M processors"
> >>>>+LICENSE = "GPL-3.0-with-GCC-exception & GPLv3"
> >>>>+
> >>>>+LIC_FILES_CHKSUM = "file://share/doc/gcc-arm-none-eabi/license.txt;md5=c18349634b740b7b95f2c2159af888f5"
> >>>>+
> >>>>+PROVIDES = "virtual/arm-none-eabi-gcc"
> >>>>+
> >>>>+SRC_URI = "https://developer.arm.com/-/media/Files/downloads/gnu-rm/9-2019q4/RC2.1/${BPN}-${PV}-x86_64-linux.tar.bz2"
> >>>>+
> >>>>+SRC_URI[md5sum] = "fe0029de4f4ec43cf7008944e34ff8cc"
> >>>>+SRC_URI[sha256sum] = "bcd840f839d5bf49279638e9f67890b2ef3a7c9c7a9b25271e83ec4ff41d177a"
> >>>>+
> >>>>+S = "${WORKDIR}/${BPN}-${PV}"
> >>>>+
> >>>>+inherit native
> >>>>+
> >>>>+COMPATIBLE_HOST = "x86_64.*-linux"
> >>>>+
> >>>>+do_install() {
> >>>>+ install -d ${D}${datadir}/arm-none-eabi/
> >>>>+ cp -r ${S}/. ${D}${datadir}/arm-none-eabi/
> >>>>+
> >>>>+ install -d ${D}${bindir}
> >>>>+ # Symlink all executables into bindir
> >>>>+ for f in ${D}${datadir}/arm-none-eabi/bin/arm-none-eabi-*; do
> >>>>+ lnr $f ${D}${bindir}/$(basename $f)
> >>>>+ done
> >>>>+}
> >>>>+
> >>>>+INSANE_SKIP_${PN} = "already-stripped"
> >>>>+
> >>>>+INHIBIT_SYSROOT_STRIP = "1"
> >>>>+INHIBIT_PACKAGE_STRIP = "1"
> >>>>+INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
> >>>>--
> >>>>2.24.1
> >>>>
> >>>>
>
next prev parent reply other threads:[~2020-01-23 20:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-23 16:08 [yocto][meta-rockchip][PATCH 0/4] Add RockPi 4 support Joshua Watt
2020-01-23 16:08 ` [yocto][meta-rockchip][PATCH 1/4] arm-trusted-firmware: Add recipe Joshua Watt
2020-01-23 16:08 ` [yocto][meta-rockchip][PATCH 2/4] gcc-arm-none-eabi-native: " Joshua Watt
2020-01-23 19:49 ` Khem Raj
2020-01-23 19:59 ` Joshua Watt
2020-01-23 20:06 ` Khem Raj
2020-01-23 20:14 ` Joshua Watt
2020-01-23 20:46 ` Denys Dmytriyenko [this message]
2020-01-23 22:34 ` Khem Raj
2020-01-23 16:08 ` [yocto][meta-rockchip][PATCH 3/4] rk3399: Add generic rk3399 support Joshua Watt
2020-01-23 16:08 ` [yocto][meta-rockchip][PATCH 4/4] rock-pi-4-rk3399: Add machine Joshua Watt
2020-01-23 19:46 ` [yocto][meta-rockchip][PATCH v2 0/4] Add Rock Pi 4 Support Joshua Watt
2020-01-23 19:46 ` [yocto][meta-rockchip][PATCH v2 1/4] arm-trusted-firmware: Add recipe Joshua Watt
2020-01-23 20:39 ` Denys Dmytriyenko
2020-01-23 19:46 ` [yocto][meta-rockchip][PATCH v2 2/4] gcc-arm-none-eabi-native: " Joshua Watt
2020-01-23 19:46 ` [yocto][meta-rockchip][PATCH v2 3/4] rk3399: Add generic rk3399 support Joshua Watt
2020-01-23 19:46 ` [yocto][meta-rockchip][PATCH v2 4/4] rock-pi-4: Add machine Joshua Watt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200123204608.GD4735@denix.org \
--to=denis@denix.org \
--cc=JPEWhacker@gmail.com \
--cc=raj.khem@gmail.com \
--cc=twoerner@gmail.com \
--cc=yocto@lists.yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox