Repos
To create our BSP layer, we will rely on the use and configuration of the following projects:
How do we know that STM created forks of the various open source repositories for these components? From their use within their BSP layer, that is meta-st-stm32mp
32# ---------------------------------
33# Configure devupstream class usage
34# ---------------------------------
35BBCLASSEXTEND = "devupstream:target"
36
37SRC_URI:class-devupstream = "git://github.com/STMicroelectronics/arm-trusted-firmware.git;protocol=https;branch=${ARCHIVER_ST_BRANCH}"
38SRCREV:class-devupstream = "cadc66f13d2b8f292fe9335bf097b8801f5a4cd7"45# ---------------------------------
46# Configure devupstream class usage
47# ---------------------------------
48BBCLASSEXTEND = "devupstream:target"
49
50SRC_URI:class-devupstream = "git://github.com/STMicroelectronics/u-boot.git;protocol=https;branch=${ARCHIVER_ST_BRANCH}"
51SRCREV:class-devupstream = "64beae9fed51f49b53f952d00d9918b9eb3b040b"48# ---------------------------------
49# Configure devupstream class usage
50# ---------------------------------
51BBCLASSEXTEND = "devupstream:target"
52
53SRC_URI:class-devupstream = "git://github.com/STMicroelectronics/optee_os.git;protocol=https;branch=${ARCHIVER_ST_BRANCH}"
54SRCREV:class-devupstream = "a8dd87d45831be900f0aaa44a5e0587269e3df25"35# ---------------------------------
36# Configure devupstream class usage
37# ---------------------------------
38BBCLASSEXTEND = "devupstream:target"
39
40SRC_URI:class-devupstream = "git://github.com/STMicroelectronics/linux.git;protocol=https;branch=${ARCHIVER_ST_BRANCH}"
41SRCREV:class-devupstream = "f01241fbba4d879fa770685629b49d42e904e43c"
42#FIXME force the PV to avoid build issue:
43# do_package: ExpansionError('SRCPV', '${@bb.fetch2.get_srcrev(d)}', FetchError('SRCREV was used yet no valid SCM was found in SRC_URI', None))
44PV:class-devupstream = "${LINUX_VERSION}${LINUX_SUBVERSION}-${LINUX_TARGET}.${SRCPV}"Why use their repositories instead of the official ones? The reason is that, due to the large number of changes and additions that STM has undoubtedly made to integrate their specific components into this software, it would be extremely time-consuming to understand what changes have been made and replicate them ourselves. We might as well start from their code base and figure out how to configure it to our liking.
Why recreate recipes from scratch instead of using STM’s? Here too, we could save ourselves a ton of work by using their recipes directly, but these often introduce additional complexities and dependencies within our project and, above all, do not clearly expose how the source code is configured. For this reason, I personally prefer to recreate the recipes, so that I can refer to the official project documentation for most of the information and, if necessary, work a little harder to understand the specific details required for the STM platform. This does require me to study most of the source code, but with the assurance of knowing where to look for if I ever need to.
I strive for freedom of configuration, but knowing that I have a source code that should work without any problems on my platform.
But above all, I hated having to understand the twists and turns that STM did in their recipes just to end up assigning some crappy values to some compilation variables.