Yocto Project Discussions
 help / color / mirror / Atom feed
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
> >>>>
> >>>>

> 


  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