warning: jobserver unavailable: using -j1. Add `+' to parent make rule.

[tixy]

Commit f58ad36f2f51798b093d282b56a3a311fdc78ca9 (Add Firmware Image Package creation tool) added three uses of the command make -C ${FIPTOOLPATH} following usual makefile practice, these should be ${MAKE} -C ${FIPTOOLPATH} as the GNU Make Manual says...

Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’

Doing this, fixes the warning in the title of this issue

[mahamble]

It would have been really nice if FIP was an optional format, basically the new patchset has broken everything... what a mess.

[tixy]

On Tue, 2014-02-18 at 04:22 -0800, mahamble wrote:

It would have been really nice if FIP was an optional format, basically the new patchset has broken everything... what a mess.

I'm updating my fixes branch to resolve some of the fallout from ARM's code drop, I'll push it out to the Linaro repo soon...

Note, you also need to a new UEFI to get FVP running as well.

[mahamble]

Thanks Tixy...

I bet I don't need a UEFI.... ;-)

I know that ARM have put a load of UEFI printfs into their supposed generic firmware, but we use uboot... so should be immune from those changes.

[danh-arm]

Although the Trusted Firmware is tested with UEFI, there is no tight coupling with UEFI or any other normal world boot firmware. Any printf output should only refer to UEFI as an example. If that's not the case, it should be fixed.

[mahamble]

Here's one: plat/fvp/plat_io_storage.c: INFO("Loading BL33 (UEFI)\n");

This comment is misleading: bl31/bl31_main.c: * before passing control to the bootloader (UEFI) or Linux. This function calls

Lot's of documentation references:

contributing.md:* Please test your changes. As a minimum, ensure UEFI boots to the shell on docs/change-log.md: The documented UEFI configuration disables some devices that are unavailable docs/change-log.md: in the Foundation FVP, including MMC and CLCD. The resultant UEFI binary can docs/porting-guide.md:BL2 is responsible for loading the normal world BL3-3 image (e.g. UEFI). docs/user-guide.md:* build-essential and uuid-dev packages for building UEFI and the Firmware docs/user-guide.md: version instead, refer to the "Debugging options" section below. UEFI can be docs/user-guide.md:#### Obtaining UEFI docs/user-guide.md:TODO: Update UEFI GitHub hash. docs/user-guide.md:implementation of the UEFI specification: docs/user-guide.md: 4. Rebuild EDK2 (see "Obtaining UEFI" section above). docs/user-guide.md:UEFI images should be used. docs/user-guide.md:BL2 loads the normal world firmware image (e.g. UEFI). BL2 relies on BL3-1 to docs/user-guide.md:##### UEFI firmware load docs/user-guide.md:BL2 loads the BL3-3 (UEFI) image into non-secure memory as defined by the

[danh-arm]

OK, there are a couple missing "e.g." statements in there but the other usages seem reasonable. We'll roll that in with the v0.3 documentation

[mahamble]

Why e.g. in the printf's, why not just say: plat/fvp/plat_io_storage.c: INFO("Loading BL33\n");

[danh-arm]

Yes, that particular one is a mistake - it should be "Loading BL3-3 (Normal world firmware)"

[danh-arm]

I believe the original issue here should be resolved by https://github.com/ARM-software/arm-trusted-firmware/commit/2f2cef46573cc55204e7873795b2c31fcc9f6216. Please confirm.

One of the incorrect UEFI references is resolved by https://github.com/ARM-software/arm-trusted-firmware/commit/08c28d5385f8fae3d5c61475a109b86ef11770d0. Fixes to the incorrect UEFI references in documentation are to follow later.

[tixy]

Yes, issue has been resolved commit 2f2cef46573cc55204e7873795b2c31fcc9f6216.