Juno - Linux Kernel - vmlinux file

FWIW 16.09 (for the first time) includes image files (system.map & vmlinux), but we only provide these for the FVP platform.

You can see this reflected in the options the new workspace script provides for FVP pre-built binaries  (the ones marked "Debug")

However, if you want to work with Juno - you'll need to rebuild from sources to produce these files.

>but I always receive an error: "Failed to sync Repo tool".

What desktop environment (OS) you are working on?

I'd suggest you try the following:

- Delete the existing workspace folder & create a new empty test folder

- Run the script again using this option ./workspace_1609.py --verbose-repo

This should give us a lot more feedback on Repo's progress (example output below)

If you still have issues please post the full contents of your console window after launching the script (or attach a file if it's long) and we'll try to help.

example output

------------------------------------------------

Syncing Repo tool (this may take a long time, please be patient)... Fetching project landing-teams/working/arm/ramdisk

Fetching project busybox

Fetching project landing-teams/working/arm/build-scripts

Fetching project optee_client.git

Fetching project ARM-software/arm-trusted-firmware

Fetching project landing-teams/working/arm/OpenPlatformPkg

Fetching project optee_linuxdriver.git

Fetching project mbedtls.git

Fetching projects:   5% (1/17)  Fetching project landing-teams/working/arm/u-boot

Fetching projects:  11% (2/17)  Fetching project uefi/uefi-tools.git

Fetching projects:  17% (3/17)  Fetching project landing-teams/working/arm/model-scripts

------------------------------------------------

Hello,

I am running on XUbuntu.

I tried again with "-verbose-repo" and it was able to run the script this time.

Now I receive the following error messages when I run "./build-scripts/build-all.sh all":

-----------------

gcc  -c -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -nostdlib -c -g  -I .. -I ../Include/Common -I ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I .   BasePeCoff.c -o BasePeCoff.o

In file included from ../Include/Common/UefiBaseTypes.h:19:0,

                 from BasePeCoff.c:17:

../Include/Common/BaseTypes.h:23:27: fatal error: ProcessorBind.h: No such file or directory

#include <ProcessorBind.h>

                           ^

compilation terminated.

../Makefiles/footer.makefile:27: recipe for target 'BasePeCoff.o' failed

make[2]: *** [BasePeCoff.o] Error 1

make[2]: Leaving directory '/home/lrl/linux_dev/linaro/workspace/uefi/edk2/BaseTools/Source/C/Common'

GNUmakefile:79: recipe for target 'Common' failed

make[1]: *** [Common] Error 2

make[1]: Leaving directory '/home/lrl/linux_dev/linaro/workspace/uefi/edk2/BaseTools/Source/C'

GNUmakefile:25: recipe for target 'Source/C' failed

make: *** [Source/C] Error 2

make: Leaving directory '/home/lrl/linux_dev/linaro/workspace/uefi/edk2/BaseTools'

Build failed: error while running do_build at line 62 in /home/lrl/linux_dev/linaro/workspace/build-scripts/build-uefi.sh for juno[juno][oe].

-----------------

I tried with other release versions and the same error came up.

Hi,

When repo fails - it's usually something outside our control (like an unresponsive server). So, glad that bit worked. The new build issue is obviously something different.

We've just re-tested this & it works fine for us. I'm assuming there's an "interesting" interaction here that is specific to your environment. We have seen this happen previously with one other user, but unfortunately we don't know the final outcome for them.

We *suspect* it's a UEFI makefile issue (rather than something related to the supplied Juno build scripts). We'll do some further investigation, based on the error you see.

Couple of questions /confirmations:

- Can you confirm you started with a new workspace directory (to rule out any possibility of interference from a previous failed invocation of repo)?

- Can you post the result of: uname -a on your XUbuntu box

- Can you open a new shell and post the result of: echo $ARCH  (we're assuming you invoked the workspace script & build from a new shell)

>I tried with other release versions and the same error came up.

You mean you've tried older (16.05 etc) releases in different workspaces and see the same issue?

Thanks

MarkN

lrl wrote:

gcc  -c -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -nostdlib -c -g  -I .. -I ../Include/Common -I ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I .   BasePeCoff.c -o BasePeCoff.o

In file included from ../Include/Common/UefiBaseTypes.h:19:0,

                 from BasePeCoff.c:17:

../Include/Common/BaseTypes.h:23:27: fatal error: ProcessorBind.h: No such file or directory

Looks like ARCH=Arm or ARCH=AArch64 is not properly set in the build.

Indeed - that's why I was asking about echo $ARCH in the shell the build is launched from.

Although we're cross compiling & expecting this variable not to be preset (outside the build scripts).

If you've previously been building something else in a shell, that assumption might not hold true.

Be good to get a resolution (or otherwise) confirmed if possible though.

Hi Mark, thank you for the quick answer.

Sorry for the delay, I was out of office.

Couple of questions /confirmations:

- Can you confirm you started with a new workspace directory (to rule out any possibility of interference from a previous failed invocation of repo)?

     Yes, I started from a new workspace several times.

- Can you post the result of: uname -a on your XUbuntu box

Linux lrl-fh 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:09:13 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

- Can you open a new shell and post the result of: echo $ARCH  (we're assuming you invoked the workspace script & build from a new shell)

echo $ARCH returns nothing

>I tried with other release versions and the same error came up.

You mean you've tried older (16.05 etc) releases in different workspaces and see the same issue?

Yes, I have tried at least with 16.05 and 16.04

Hi,

I think we will try to hang on to the makefile ARCH explanation for a while longer, because it's the only theory we have right now!

>echo $ARCH returns nothing

Do you mean the variable isn't set or that it is empty?

Here's a better test, please can you try this with 16.06:

$ tput reset

$ unset ARCH

$ ./build-scripts/build-all.sh juno-uefi clean

$ ./build-scripts/build-all.sh juno-uefi

** please post the full log from your console as an attachment **

We suspect the issue starts here: /uefi/edk2/BaseTools/Source/C/Makefiles/header.makefile & that the build detects the wrong (or empty) ARCH variable.

For example: I can get the error you see using export ARCH=" " before I invoke the UEFI build.

This results in /uefi/edk2/MdePkg/Include/$ARCH/ProcessorBind.h failing to be resolved and ultimately the build fails with  ../Include/Common/BaseTypes.h:23:27: fatal error: ProcessorBind.h: No such file or directory  #include <ProcessorBind.h>

If ARCH is not set (as expected) we would expect the UEFI makefile to query it & report the following in the console log

make: Entering directory `/media/markn/1TB_HDD/junk/HP_16_06_test/uefi/edk2/BaseTools'

make -C Source/C

Attempting to detect ARCH from 'uname -m': x86_64

Detected ARCH of X64 using uname.

Note the expected ARCH is X64 (not AARCH64) as we are querying the host arch (not the target).

HTH

MarkN.