Support ppc64 arch

[SergiiDmytruk]

Part of #1002.

Changes first replace some hard-coded paths with variables, then introduce subdirectory per architecture and finally make modules build for PowerPC 64 (although without board this isn't tested at this point, don't include it here?).

[macpijan]

@tlaurion The two failing checks have been rerun and now succeded

[tlaurion]

LGTM. @MrChromebox ?

[tlaurion]

@SergiiDmytruk I see a possible optimization that would not require all future modules to take into consideration supported archs/musl targets, following comment at https://github.com/osresearch/heads/pull/1002#issuecomment-1218684703

BUILD_TARGET: In Makefile x86 is used as default, which talos board configs overrides.

Then all modules are modified to create a module specific target for musl hosts (still weird to me since they should be targets, not hosts)...Anyway!

---

What about: BUILD_TARGET becomes BUILD_TARGET_ARCH in global Makefile and everywhere else? And then Adding MUSL_ARCH in global Makefile, specifying either x86_64 if BUILD_TARGET_ARCH is x86, or MUSL_ARCH specifying powerpc64le if BUILD_TARGET_ARCH is ppc64?

It seems that doing so, most of the modules outside of linux and coreboot could simply be changed to have their host/target set to use musl target variant (MUSL_ARCH) from global Makefile (overriden by board config if defined there at terminal make BOARD=) which would push that environment variable to modules without further modules modification in the future if we more BUILD_TARGET_ARCH + MUSL_ARCH are added?

Is that a silly idea?

Example: https://github.com/osresearch/heads/blob/53f2bb7e0b87e3c8c422dbfdd2149cb72f6cf6a1/modules/libksba The only thing needing to change in module after above change would be --host "$(MUSL_ARCH)-linux-musl" \

[SergiiDmytruk]

Let's get serious about this and make a table :)

module	x86 host target	ppc64 host target
coreboot	i386	ppc64
kexec	x86_64	powerpc64le
popt	i386-elf-linux	powerpc64le-elf-linux
qrencode	i386-elf-linux	powerpc64le-elf-linux
slang	i386-elf-linux	powerpc64le-elf-linux
util-linux	i386-elf-linux	powerpc64le-elf-linux
cryptsetup	i386-elf-linux	powerpc64le-elf-linux
pciutils	x86_64-linux-musl	powerpc64le-linux-musl
npth	x86_64-linux-musl	powerpc64le-linux-musl
libgcrypt	x86_64-linux-musl	powerpc64le-linux-musl
libksba	x86_64-linux-musl	powerpc64le-linux-musl
libassuan	x86_64-linux-musl	powerpc64le-linux-musl
gpg2	x86_64-linux-musl	powerpc64le-linux-musl
libgpg-error	x86_64-linux-musl	powerpc64le-linux-musl

I guess I gave up on doing this in one place after seeing that for x86 you need different values for the same variable. I think you're suggesting doing something like --host $MUSL_ARCH-linux-musl, which works in half of the cases. Or maybe i386 can be changed to x86_64 in i386-elf-linux? Don't remember whether I've tried that.

[tlaurion]

Blunt change under ec6b18a passed building board x230-hotp-maximized, passing everything i386 to x86_64 (for the default arch being x86, that is).

Been a really long while since I have to change content or add content to modules, but what we are doing in modules seem pretty wrong to me.

~The toolchain from host should be dynamic, or set to reuse what was compiled in musl-cross target.~ ~On x86, it should be x86_64-elf-linux, but for coreboot, which needs to be built with i386.~

As stated https://stackoverflow.com/questions/5139403/whats-the-difference-of-configure-option-build-host-and-target

--target only applies when you are compiling toolchains.
--build=the architecture of the build machine
--host=the architecture that you want the file to run on

~So I'm confused to what we are going here and if those are artifacts or hacks that needed to be applied to some modules which were not really compliant to crosscompilers.~ Will try to do additional tests...

EDIT: okok: --host=the architecture that you want the file to run on Makes sense and exactly what we do. target is actually target host. Nothing wrong then.

[tlaurion]

@JonathonHall-Purism @jans23 @SergiiDmytruk :LGTM.

I would merge asap so that new board additions are modified to follow the new requirements, as modified in this PR for actual boards, otherwise this PR will continue to be a moving target, which we do not want.

@JonathonHall-Purism @jans23: You can test the arfifacts from latest commit, no impact on x230-hotp-maximized on my side.

[tlaurion]

@SergiiDmytruk two additional added boards (qemu) needs modification (qemu+TPM boards)

[tlaurion]

https://github.com/osresearch/heads/pull/1002#issuecomment-1227290204

Long story short, supporting a new architecture need some changes on the build system to not break things, including CI/CD. As of now, CI is again causing issue (CI is a burden...), so that its caches (to reuse built stuff) can be reused if still valid (built stuff matching modules for which the cache was created for) and being reusable.

As of now, the build system takes consideration that packages are under ./packages, make install stuff is under ./install and musl-cross is installed under ./musl-cross

So probably the simplest fix would be to have ./packages under ./packages/arch (so they are part of the cache per arch and don't conflict on save_cache), ~or reduce strong dependency between make statements between ./packages/package_version_verify and ./build/arch/package-version/.canary?~

./crossgcc is the install dir of musl-cross as well, just like ./install for all other modules beside musl-cross and coreboot.

Those paths probably need to be arch specific to be cached as well to speed things up. This is why we see the cross compiler re-building (to fill install dir) where ./install is the dynamic link dir for binaries and might cause problems when building locally in parallel for multiple archs as well (note that binaries and libs are installed in initrd on Makefile initrd step, taking input from ./build/arch/package-version, not from ./install dir. The install dir is used for make install modules statements and dynamic linking only).

Those dir might as well be changed to ./crossgcc/arch and ./install/arch to be cachable per CI/CD and used in local parallel builds without creating problems down the line.

I am confident that once those directories are arch specific, CircleCI will not complain and packages, install directories will be cacheables and save_cache will also work on clean git checkout builds (That will require changing/adding CACHE_VERSION into CircleCI project's setting to test a full rebuild without cache to create caches including CACHE_VERSION into their names).

[tlaurion]

@JonathonHall-Purism @jans23 changes the build system so that everything is built in ./*/arch directory, set default to x86 in Makefile where ppc64 is supported.

Packages are downloaded under packages/arch directory as of now as well. modules are changed to support calling proper musl-cross

It has an impact of around 10 minutes on current CI when using cache.

LGTM. Prior step prior of merging #1002, which also LGTM.

[JonathonHall-Purism]

Boot tested mini v2, LGTM :100: