Hello team,
Few things I noticed going through the getting started guide for building the Android bootloader/ kernel modules.
- I think there needs to be one script that we provide that downloads all the repositories and initializes them with the directory structure that the build scripts are expecting. It can be multiple scripts in the background but one top level one to download sources and one to build. All I'm doing is copy pasting from the SDK documentation anyways. The documentation in the build guide should explain how the script works and call out the relevant steps/ variables to change if customers want to tweak the build targets, output directories etc.
- This also allows for the commands in the SDK documentation to be TESTABLE. I have noticed typos (in prior build guides), omissions in how the environment variables should be set up, omissions in dependencies, and invalid or incorrect build flags or commands. For an example in 08.06.00:
- Omission in environment variable setup: nowhere in the guide does it mention that you should set your path to point to the arm cross compile tool chains. (As a side note the guide mentions that you can download the toolchains from the SDK web page but doesn't mention why you might want to do that)
- Omission in dependencies: building ti-optee-os requires python packages for cryptography and for pyelftools to be installed. Maybe it's covered in the ti-optee-os documentation but no mention of it in the build guide and causes build to fail.
- Incorrect build flags: Building Arm Trusted Firmware the instructions include a step that sets the CFLAG K3_PM_SYSTEM_SUSPEND=1:
make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 PLAT=k3 TARGET_BOARD=lite SPD=opteed CFLAGS+="-DK3_PM_SYSTEM_SUSPEND=1"
This lead to a build error for redefining this symbol.
- Testing of these instructions and scripts should be done on a clean install of the supported Ubuntu distro or Linux it's too easy to miss dependencies just because we've already had things installed on our Linux machines. It should be fairly easy to spin up a vm to do this, or we should distribute a docker container that contains all of the required packages for a build.
Another nice thing would be a general size of downloads expected and size of build artifacts generated. It's not a great feeling to come back from an overnight build and your disk is out of space.
Anyways for someone who has to hop in and out of Linux development this is easily one of the most painful parts of spinning up a build so hopefully we can make it easier.
Munan
