optee failing to build on head of dunfell branch for j7-evm

optee failing to build on head of dunfell branch for j7-evm

[mlynch]

[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]

While trying to build core-image-minimal for j7-evm using the head of the"dunfell" branch of meta-arm, the build fails during compile of optee.  The optee recipe contains a patch that is supposed to patch "mk/gcc.mk" but I found that, for whatever reason, the patch is NOT getting applied before "make" gets run.  I worked around the issue by creating a bbappend for optee-os_git that fixes up the "mk/gcc.mk" file.  My bbappend simply "prepends" do_compile such that what the patch file does is done to the "mk/gcc.mk" file.  What I can't figure out is why the patch from the layer isn't getting applied in the first place but I do have a theory I was hoping someone could verify/validate.  What I noticed is the SRCREV (023e33656e2c9557ce50ad63a98b2e2c9b51c118) in optee-os.bb does not match to any commit reference in the remote git repo for optee_os and the version that ends being retrieved is the head of the "master" branch of optee_os.  I believe the mk/gcc.mk file that comes in with that version (master) of optee_os does not match what the patch file is expecting and thus the patch from the dunfell branch fails to apply?  One question I have is why bitbake doesn't show a patch application failure but only shows a failure later when the build fails?  Does any of this sound plausible to anyone or am I way off base with this?  Are these questions maybe more appropriately directed toward bitbake maybe?  Anyway, just looking for thoughts/opinions since I have a work-around that appears to do what is needed.

Mike

[-- Attachment #2: Type: text/html, Size: 1590 bytes --]

Re: [meta-arm] optee failing to build on head of dunfell branch for j7-evm

[Ross Burton]

On 19 Jan 2024, at 18:01, mlynch via lists.yoctoproject.org <mlynch=hi-techniques.com@lists.yoctoproject.org> wrote:
> 
> What I noticed is the SRCREV (023e33656e2c9557ce50ad63a98b2e2c9b51c118) in optee-os.bb does not match to any commit reference in the remote git repo for optee_os

I’ll stop you there.

https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-security/optee/optee-os_git.bb?h=dunfell

The version is 3.8.0 and the SRCREV is 023e33656e2c9557ce50ad63a98b2e2c9b51c118, as you say.

https://github.com/OP-TEE/optee_os/releases/tag/3.8.0

The 3.8.0 tag has the SHA of 023e33656e2c9557ce50ad63a98b2e2c9b51c118.

It’s possible that the recipe is broken because our CI didn’t really test optee in dunfell, but I’d start by removing optee-os from your DL_DIR and building from scratch.

Ross

Re: [meta-arm] optee failing to build on head of dunfell branch for j7-evm

[Ross Burton]

[Re-copying the list]

On 22 Jan 2024, at 13:47, Michael Lynch <mlynch@hi-techniques.com> wrote:
> 
> Ross, thanks for the info.  In all cases I've been working from a fresh directory tree.  E.G.  Downloading everything (layers and sources) afresh each time I tested the build.  My meta-arm version is 3.1.6 (head of dunfell branch).  The problem I see is after I attempt the build and it fails, I go to tmp/work/j7_evm-poky-linux/optee-os/3.20.0+gitAUTOINC+8e74d47616-r0/git and check the version and it is 3.20.x.  I expected it to be 3.8.0 or am I wrong?  Since the optee_os source is not the version expected, the patch won't apply.  It's acting like the SRCREV from the optee recipe isn't being applied when the source is cloned from the GIT repository.  I know TI does some odd things in some of their recipes and their layer (meta-ti) does, in fact, append the optee-os recipe.  I'll check that and see if there is anything obvious in it that may explain what is going on.  The nasty thing about testing this with meta-ti and the dunfell branch is optee is only used with the j7-evm (and possibly others) machine but is NOT used with any of the beagleXXX machines.  I'll let you know if I find anything with TI's append to the optee recipe.

What meta-ti branch are you using?

Ross

Re: [meta-arm] optee failing to build on head of dunfell branch for j7-evm

[Ross Burton]

On 22 Jan 2024, at 14:11, Michael Lynch <mlynch@hi-techniques.com> wrote:
> 
> Meta-ti branch is head of dunfell.
> 
> Ok I believe see what's going on.  The dunfell branch of the meta-ti layer appends optee_os such that it updates optee_os to the 3.20.0 git version but does NOT supply a replacement patch file that works with the "mk/gcc.mk" file that comes with 3.20.0 nor does TI's optee_os append override do_patch and I believe this is why the build ends up failing?  Maybe time to ask on the meta-ti forum?

Absolutely.  They don’t appear to be testing that combination.

Ross

Re: [meta-arm] optee failing to build on head of dunfell branch for j7-evm

[Denys Dmytriyenko]

On Mon, Jan 22, 2024 at 02:25:34PM +0000, Ross Burton wrote:
> On 22 Jan 2024, at 14:11, Michael Lynch <mlynch@hi-techniques.com> wrote:
> > 
> > Meta-ti branch is head of dunfell.
> > 
> > Ok I believe see what's going on.  The dunfell branch of the meta-ti layer 
> > appends optee_os such that it updates optee_os to the 3.20.0 git version 
> > but does NOT supply a replacement patch file that works with the 
> > "mk/gcc.mk" file that comes with 3.20.0 nor does TI's optee_os append 
> > override do_patch and I believe this is why the build ends up failing?  
> > Maybe time to ask on the meta-ti forum?
> 
> Absolutely.  They don’t appear to be testing that combination.

Well, TI historically have been using stable/LTS releases even for adding new 
platforms, hence bumping BSP components to newer versions, often backporting 
them from master, but sometimes even updating OPTEE/TFA before meta-arm does. 
Those combinations are always being tested for TI platforms, as overrides in 
those bbappends are specific to TI SoC platforms.

Now, the issue is with the libgcc sysroot patch that's been there forever, 
until just several days ago when it got replaced with CFLAGS in master. And 
passing sysroot is required for OE-built toolchain.

Anyway, I've done some digging - in the past TI was using external toolchain 
for their products, so when optee-os got bumped to 3.20, the issue with the 
patch was missed, as external toolchain has no issue finding libgcc, e.g.:

TCMODE = "external-arm"
EXTERNAL_TOOLCHAIN = "<path-to-the-toolchain>"

And switching TI products to OE-built toolchain (TOOLCHAIN_TYPE=internal) 
surely exposes this issue:

| aarch64-oe-linux-ld.bfd: cannot find libgcc.a: No such file or directory

TI products have switched to Kirkstone about a year ago and also changed the 
default toolchain to OE-built one, so no issues there or in master.

And Dunfell branch hasn't seen any updates in meta-ti since then, but I guess 
this can be fixed, as apparently there are people still using Dunfell...

-- 
Denys

Re: [meta-ti] [meta-arm] optee failing to build on head of dunfell branch for j7-evm

[Denys Dmytriyenko]

On Mon, Jan 22, 2024 at 01:33:12PM -0500, Denys Dmytriyenko wrote:
> On Mon, Jan 22, 2024 at 02:25:34PM +0000, Ross Burton wrote:
> > On 22 Jan 2024, at 14:11, Michael Lynch <mlynch@hi-techniques.com> wrote:
> > > 
> > > Meta-ti branch is head of dunfell.
> > > 
> > > Ok I believe see what's going on.  The dunfell branch of the meta-ti layer 
> > > appends optee_os such that it updates optee_os to the 3.20.0 git version 
> > > but does NOT supply a replacement patch file that works with the 
> > > "mk/gcc.mk" file that comes with 3.20.0 nor does TI's optee_os append 
> > > override do_patch and I believe this is why the build ends up failing?  
> > > Maybe time to ask on the meta-ti forum?
> > 
> > Absolutely.  They don’t appear to be testing that combination.
> 
> Well, TI historically have been using stable/LTS releases even for adding new 
> platforms, hence bumping BSP components to newer versions, often backporting 
> them from master, but sometimes even updating OPTEE/TFA before meta-arm does. 
> Those combinations are always being tested for TI platforms, as overrides in 
> those bbappends are specific to TI SoC platforms.
> 
> Now, the issue is with the libgcc sysroot patch that's been there forever, 
> until just several days ago when it got replaced with CFLAGS in master. And 
> passing sysroot is required for OE-built toolchain.
> 
> Anyway, I've done some digging - in the past TI was using external toolchain 
> for their products, so when optee-os got bumped to 3.20, the issue with the 
> patch was missed, as external toolchain has no issue finding libgcc, e.g.:
> 
> TCMODE = "external-arm"
> EXTERNAL_TOOLCHAIN = "<path-to-the-toolchain>"
> 
> And switching TI products to OE-built toolchain (TOOLCHAIN_TYPE=internal) 
> surely exposes this issue:
> 
> | aarch64-oe-linux-ld.bfd: cannot find libgcc.a: No such file or directory
> 
> TI products have switched to Kirkstone about a year ago and also changed the 
> default toolchain to OE-built one, so no issues there or in master.
> 
> And Dunfell branch hasn't seen any updates in meta-ti since then, but I guess 
> this can be fixed, as apparently there are people still using Dunfell...

https://patchwork.yoctoproject.org/project/ti/patch/20240122191902.1561510-1-denis@denix.org/

-- 
Denys