Date
1 - 1 of 1
Your patch: "recipes-bsp: drop custom deploy location for TF-A binary"
Andrey Zhizhikin
Hello Patrick,
I'll Cc: the meta-freescale ML here, since this a second issue of the
same type reported on the TF-A changes. I guess it would be
informative for the others to read it in order to avoid duplication.
On Wed, Aug 10, 2022 at 12:03 PM Patrick Boettcher
<patrick.boettcher@...> wrote:
implements NXP-specific BSP and is maintained by NXP engineers. This
involves also "locking up" versions of all layers in their manifest (the one you
used in initial cloning). This in turn implies that if you start to
mix-and-match
versions of NXP BSP with OSS layer updates - you get those inconsistencies
which would need to be solved by person who does this.
into `meta-freescale` for those components that are NXP-specific, which
allows Mainline BSP to be built as a combination of latest upstream
packages and latest NXP vendor parts.
`meta-imx` with consecutive releases.
Regards,
Andrey.
I'll Cc: the meta-freescale ML here, since this a second issue of the
same type reported on the TF-A changes. I guess it would be
informative for the others to read it in order to avoid duplication.
On Wed, Aug 10, 2022 at 12:03 PM Patrick Boettcher
<patrick.boettcher@...> wrote:
Then I suggest you switch from NXP BSP and move to Mainline one. `meta-imx`
Hi Andrey,
On Wed, 10 Aug 2022 09:11:16 +0200
Andrey Zhizhikin <andrey.z@...> wrote:Hello Patrick,Yes, I have the same problem and the same scenario. I'd rather stay
On Wed, Aug 10, 2022 at 6:18 AM Patrick Boettcher
<patrick.boettcher@...> wrote:Perhaps you see this issue because you do use a wrong combination of
Hi Andrey,
I'm using meta-freescale on kirkstone in my yocto-build and I'm
facing an issue with ATF-location you patched in June with the
following patch
546a884afd29b5e058ddf0f1a6964246db8ffb70@meta-freescale.
versions in your layers, see [1] for similar issue.
Link: [1]: https://github.com/Freescale/meta-freescale/issues/1126
with a recent meta-freescale than to go back to a version dating April.
implements NXP-specific BSP and is maintained by NXP engineers. This
involves also "locking up" versions of all layers in their manifest (the one you
used in initial cloning). This in turn implies that if you start to
mix-and-match
versions of NXP BSP with OSS layer updates - you get those inconsistencies
which would need to be solved by person who does this.
The process goes in the opposite direction: `meta-imx` releases are merged
What would need to be done on meta-imx to fix it?
into `meta-freescale` for those components that are NXP-specific, which
allows Mainline BSP to be built as a combination of latest upstream
packages and latest NXP vendor parts.
This has to be picked up by NXP from `meta-freescale` and integrated into
IIUC, you suggest to do the same change on meta-imx so that imx-atf is
deployed into the right place. What would be right change? Does
DEPLOYDIR needs to be changed?
`meta-imx` with consecutive releases.
--
--
Patrick.
Regards,
Andrey.