I am starting on the task of refactoring ARM Platform support. Initially in the ARM Ltd sense, but also in the general ARM-based SoC case.
The existing platform code, mostly under ArmPlatformPkg is fragmented, duplicated and hard to maintain. Adding a new platform often involves copy/paste of a lot of code that the platform owner neither understands nor really needs to care about.
The basic concept is to have as much common/generic code as possible and have as little in the platform specific code. Thus making porting to a new platform as simple as can be.
A new board using code that’s already in the tree should just be able to provide a .dsc file with some defines in it and include the common.dsc.inc file.
The common.dsc.inc file would then define everything, with conditional statements including various drivers or features.
For example, juno.dsc would define that it is using the CFI NOR flash driver and provide the defines for the flash config. The common.dsc.inc file would only include the CFI NOR flash driver in the build if it is specified in its parent .dsc file.
The other concept is to move the platform code from the EDK2 tree to the OpenPlatformPkg tree.
In my experiments, I have included OpenPlatformPkg as a sub-tree of the EDK2 git tree. This allows me to “git mv” files between the two repos. In reality, we would have to “git add” to the OpenPlatformPkg repo and “git rm” from EDK2 as separate patches.
--------------- Failed attempts --------------- I had several plays with the code.
In one attempt, I moved all the code in ArmPlatformPkg that was used by Juno and attempted to get this working in the new location. Unfortunately, in my opinion, the build system is so obtuse that this becomes a tangled web of build failures. I aborted this attempt very quickly.
In another attempt, I thought I would start from scratch by creating a new BSP. But I realised that my understanding of much of the code/config was severely lacking. There are some components and sections of the DSC and FDF files where I have absolutely no idea what they are for. I guess many people are in this position and it’s probably a reason why so many BSPs are boilerplate copied from ArmPlatformPkg.
--------------- Getting started --------------- I decided to start by splitting the Juno BSP up into common and platform specific code. The first step is to create a new juno.dsc file in OpenPlatformPkg.
Initially, this just #included ArmJuno.dsc from edk2.
Next, I copied ArmJuno.dsc over to OpenPlatformPkg/Platforms/common/common.dsc.inc and included that in the new juno.dsc.
Then, I migrated Juno specific stuff from common.dsc.inc to juno.dsc, eg. “PLATFORM_NAME = ArmJuno”.
From here on, I started walking through the common.dsc.inc file and
moving code across from ArmPlatformPkg to OpenPlatformPkg/Platforms/common. Bit by bit, I moved, renamed and fixed up components used by the Juno platform.
At this point, the “common” code is still very Juno specific. Function names, symbols and various other pieces still reference Juno. This needs to be fixed.
One part (of the many) that may cause controversy is that I have kept to a “simple” file naming scheme. Instead of everything having the words Arm, Juno, Platform and Pkg in multiple combinations, I’ve tried to keep things simple. I also used all lower case filenames, because we’re generally not DOS users and all these mixed case filenames drive me insane. I expect this to go down badly with some, but hope I can get away with it ;-)
------------------------------- Once Juno is migrated to common ------------------------------- After all the parts that Juno uses have been moved to OpenPlatformPkg, I intend to add another platform. I’ll use FVP: it’s similar enough to Juno that most of the common code will remain there, even if it is still quite ARM platform specific, but it will allow me to demonstrate two platforms using the common code.
What it won’t do yet is split out any functionality that is “Versatile Express” in nature, but neither Juno nor FVP specific; i.e. any code that is not really common to all platforms, but is common to ARM Ltd's platforms.
After this, I was thinking that first I need to go around cleaning up the code to remove all the Juno references. Then, adding another platform, such as HiKey or D01/02 into the common framework might be a brave next step to see how much we can keep common and how much needs to be split back into Juno, FVP or Versatile Express specific areas.
------------- My GIT branch ------------- I’ve created a demo branch with my experimental changes here:
https://git.linaro.org/landing-teams/working/arm/edk2.git/shortlog/refs/head...
This is only intended to demonstrate a concept, so don’t take too much of it to heart. I haven’t gone all the way in migrating the code either, I’ve just picked the essentials, followed by the NOR flash and ACPI parts. I picked those because NOR is common and ACPI is Juno specific.
-------------- So what next?? -------------- In order to push this code to OpenPlatformPkg, I think there are two ways of doing it:
Big hit: go away, do all the work in isolation and submit a patch series.
Gradual migration: submit small patch series as they are ready and remove the code from ArmPlatformPkg as we move along.
I’m a bit worried about doing it in one big hit. Looking at the amount of free time I have to work on this and how long my experiments have taken me, I worry that by the time the work is “done”, it will need some serious fixing again to catch up to the upstream code changes. I also think it leaves my changes less open to scrutiny by others.
Unfortunately, a gradual migration would possibly take a longer elapsed time to complete. I don’t think it would be realistic to create the new code in OpenPlatformPkg without removing (some of?) the code from ArmPlatformPkg as we go. If the migrated code is still in ArmPlatformPkg, people will continue to use it and patch it, leaving two diverging code bases that will need effort to sync. At the very least, removing the ArmJuno.dsc from ArmPlatformPkg would help keep things on track without removing the rest of the code in ArmPlatformPkg.
At this point, I’m soliciting feedback on my approach and hoping to get some sane critique on what can be done better/easier.
Regards, Ryan.