Long term plans for Deos BSPs

Status

Ideas/Issues

Cloning BSPs is becoming problematic.
1. Use of single source generating multiple BSPs helps, but still causes construct vs assembly.
  1. AL: We have the perception BSPs are custom.
  2. ALR: Most of the BSP is custom. Replacing U-Boot is what makes the BSPs expensive.
2. Recent OA support for Parent platform projects helps, but is incomplete.
The interface for a BSP has historically been kernel centric, but ancillary issues have been poorly documented.
1. Test support (TestResults)
2. ABC
3. Network
4. Drivers
5. 653
6. PCI -- substantial board specific issues
7. clock sync
8. timer support
9. Interrupts in general
  1. AL: Have the PAL provide an interface to allow privileged/PRL drivers to ... mask/unmask logical interrupts?
  2. ALR: We have been assigning more tasks to the PAL that are not platform specific. Hence, the PAL is becoming more than the PAL, losing its purpose.
PIA has resolved some driver interaction, but interrupt support is still incomplete.
1. Driver specify IRQ aggregation (multiple physical interrupts mapped to a single platform interrupt).
2. PIC configuration (level vs edge, etc.). Any way to make this Driver customizable?
  1. EM: Maybe we can consider something similar to the PCI config tool for interrupts configuration.
  2. ALR: This might also help to solve the interrupts aggregation topic.
  3. AL: It might be possible to make it with programming language instead of a config file.
  4. ALR: How about making the PCI initialization its own shared object?
How to deal with Ethernet MAC addresses?
1. Propose we enable a "board provisioning" step that writes some persistent data to a well known location that:
  1. config could arrange to make globally visible and that the BIO or PSBIO could have a pointer to, or
  2. define a platform resource(s) that enables access to it.
2. A writeup and proposal of solutions for the MAC address problem
  - Wiki page - BSP_MAC_Address_Project BSP MAC Address Project
Proposal to make boot selection archives require less custom boot logic
One libpal.so for all aarch64 bsps and its relation to PIA
1. aggregated interrupt support via registerInterruptHandler PAL interface.
2. Parent BSPs
3. (PIA?) Variable to specify base offset of devices
4. kernel provided registry services to get address of, e.g., PIC.
5. Various timers and interrupt controllers on different platforms
6. Insufficient number of timers.
~~Should there be PCI config support, e.g., via (something like) allocatePhysicalAddressRange(size, alignment)?~~
1. ~~If so, how would that integrate into the registry?~~
2. ~~Not clear this makes sense.~~
3. ~~Only use case we could think of would be as an offline tool, like region.py. No perceived need. Drop this issue.~~
~~What PAL customization technology? Interceptor? PAL extensions?~~ Interceptor
Boot: detect 32 vs 64-bit hyperstart image and "do the right thing".
1. Primary reason to consider this is to simplify board provisioning.
2. Would be helpful to have BIO member that specified 32 vs 64-bit.
Secure Boot
1. Where is secure BIT?
What Boot customization technology? See Modular_Boot
XML .bcfg generator for POD C structs
1. GCC tooling to parse C struct and generate appropriate XML schema, xml2cfg, and bcfg2xml.
2. Not directly BSP specific, but wanted to gauge interest.
3. AL: This was a customer request. Not sure if it is doable since it seems like data is rarely just numbers and strings.
Is there some way we can leverage the vendor provided DTB?
Architecture specific concerns. Attempting to make architecture specific, not platform specific implementations.
1. Aarch64 and x86 perhaps
2. powerpc seems more problematic.
3. RISC-V is TBD in this regard
4. If architecture specific, consider the extra effort of testing each architecture, each processor family, each platform, etc.
Logging See also Modular_Boot
1. Customizable placement into persistent memory
2. Where is the driver for this?
3. How variable/complicated is it?
Is there enough left in DeosBoot to make this worth while?
1. Image selection logic
2. Image authentication
What are the differences between a reference BSP and a verified one (w.r.t. this proposal)?
PCI support for reference boards
1. Goal: Get PCI scanner and pci-config to work on reference boards.
2. Would need some PCI boards that have onboard bridge controllers to verify hierarchical support is working.
3. There are ~ 4 different PCI implementations, that would complicate PCI support in the PAL and boot.
4. Not all boards have PCI slots.
5. "Windows" are a further complication on NXP processors, and introduce board specific considerations.
Should we be using vendor supplied BSP code rather than uboot?
1. Vendor GUI tools could make BSP customization easy enough that customers might be willing to adopt the verification of the result.
We need a list of potential challenges for Modular_Boot.

Proposals

BIF Load With Redundancy Policy

There is an updated proposal in scm at https://ddci.zapto.org/scm/Deos/products/bsp/modular-boot/bif-loader with an executable specification.

Proposal to make BIF archive logic flexible enough so that for most cases it does not need custom boot code. An older/original proposal appeared on the mailman mailing list post Proposal to make boot selection archives require less custom boot logic and subsequent follow on discussion. There was a previous description on this wiki page that was substantially updated on 2025-09-10.

Proposal: A Boot Image File (BIF) is a type that has two categories:

BIF Atomics: LFS, MFS, binary archive, and a few others never implemented. This proposal does not change the definition of these.
BIF Archive: An ordered collection of BIFs.
- Note the BIF definition as of 2025-09 had two archive types; selection and composite. This proposal combines the two.

The following is an abstract view, i.e., the syntax and organization of the data items is TBD, although the likely representation will be XML.

A BIF archive has a header and an ordered list of sections. Loading an archive means loading a subset of the sections in the archive.

Each section:

Either contains a BIF, or is a reference to a BIF.
Contains a description of what to do for both a successful and unsuccessful load of the BIF.
The success and failure actions can be one of:
- return_failure
- return_success
- load_image@index -- basically a goto.
  1. When load_image@index denotes a section that is an archive (or reference to same), it should also specify the index within the archive to start the load at.

A section that is a reference must specify:

Where the image comes from e.g., a vfile filename, a RAM address, ???
The image header contains the destination address.

Would having the reference be able to override the destination be useful?

When loading an archive:

  bool loadArchive(image, index):
    loop:
      if loadSection(image.section[index]):
          action = image.section[index].success_response
      else:
          action = image.section[index].fail_response
      if action is return_*, then return that status
      // Only other possibility is load_image@index.
      index = the index from load_image@index

  bool loadSection(section):
    if section.type is reference:
	vfile.read the image into local memory (malloc?  Just the header?)
	return loadBIF(image)
	// loadBIF is either loadArchive() or for atomics as currently implemented
    else:
	load the section's contained BIF file (archive or atomic)
	and return the result.

Issues

The above captures the core proposed features. Obviously there might be a desire to have some additional capabilities for each section, for example:

Flag to generate a log, either on success or failure, or both.
Specify that the current section contains the image to boot from
A set of the permitted signature types (BIFH_integrityKeyType_t). The intent is to ensure chain of trust is maintained.
KG indicated there might be a need to sub-classify the failure types. More to follow.

Random notes:

An example boot0 could be an image that uses TFTP to download images. This might make production BSPs more tolerable
Need a BIF option to skip integrity checks and not relocate (might already exist) to handle situations like Loewen where some other boot agent loads the images.

Examples

Implementing Redundancy

An archive that describes how to load an LFS with a backup copy.

# Assume this file is stored in lfs.darc.xml
section name=primary, type=reference:
    source=some-vfile-path-to the lfs, e.g, /sata/parttition0, or /dvms/LFS0primary.lfs.bin
    on success return success
    on failure LOAD "secondary"

section name=secondary, type=reference
    source=some-vfile-path-to the lfs, e.g, /sata/parttition1, or /dvms/LFS0secondary.lfs.bin
    on success return success
    on failure return failure

Implementing Multiple Images

An archive that describes how to load all the BIF files for a system.

# Assume this file is stored in system.darc.xml
archive name=system
    section name=lfs, type=reference
	source=lfs.darc
	on success load next
	on failure return failure

    section name=mfs0, type=reference
	source=mfs0.darc
	on success load next
	# which of the following depends on whether MFS0 is "critical".
	on failure return failure, or load next

    more sections like mfs0.

    # The last section can't "load next", so...
    section name=mfsN, type=reference
	source=mfsN.darc
	on success return success
	# which of the following depends on whether mfsN is "critical".
	on failure return failure or success

Single File Multi-image And Redundancy

We would want to have the ability to combine #Implementing_Redundancy and #Implementing_Multiple_Images into one xml:

archive name=system with redundancy inline
    section name=lfs, type=inline
	on success load next
	on failure return failure
	archive name=LFS
	    section name=primary, type=reference:
		source=some-vfile-path-to the lfs, e.g, /sata/parttition0, or /dvms/LFS0primary.lfs.bin
		on success return success
		on failure LOAD "secondary"

	    section name=secondary, type=reference
		source=some-vfile-path-to the lfs, e.g, /sata/parttition1, or /dvms/LFS0secondary.lfs.bin
		on success return success
		on failure return failure

    # similar sections for other images

Command Line makebif

The following is obsolete. Likely it would be replaced with XML that does something similar.

The command line interface for mkarchive that would support the above employs --on-success and --on-fail switches that apply to all subsequent files. Here is a way to approximate the current behavior of selection and composite archives:

mkarchive new switches
  --on-success= return-success return-fail load-index=x
  --on-fail=    return-success return-fail load-index=x


// Selection archive:
mkarchive 
  --on-success=return-success
  --on-fail=return-fail
  file1 file2 ...

// Composite archive:
  --on-success=load-next
  --on-fail=return-fail
  file1 file2 ...

// To specify a policy that the first (LFS) image is critical, and the MFS images are not:
  --on-success=load-next
  --on-fail=return-fail
  file1.LFS
  --on-fail=load-next
  file2.MFS
  file3.MFS

Modular Boot Module

To eliminate the need for custom boot logic, we could suggest that a modular boot .barc can (or always does?) contain a BIF image which could be:

An LFS that just runs.
An LFS that determines which image should have been loaded (e.g., by reading discretes) and then returns the image index to load via setKernelAttributesEx()
An executable that behaves like 2, but is a customer supplied "executable like thing". E.g., an SRT with the address of their code so it looks vaguely like a kernel startup.
(alternate to 3) a custom boot image file type that is just raw code that returns a selection index. It could be given the selection archive as an argument.

Using Kernel ELF Symbol Resolution for Interceptors

Example for how to have one or more Kernel Mode Interceptor Libraries (KMIL) get notified when a PAL function is called, e.g., timerWrite():

The PAL:

Defines timerWrite() as normal

Every KMIL that is to intercept the call:
1. Defines a module local variable for the function pointer:
  typeof(timerWrite) _timerWrite;
2. Defines a KMIL entrypoint/PRL registration function that contains:
  getLibrarySymbolAddressPPI(kernelLibraryBreadthFirstNext, "timerWrite", &_timerWrite);
3. Defines timerWrite() as normal:
  
  ... timerWrite(...)
  
  {
  
  // Do module specific code
  
  _timerWrite(...) // chain to next library and/or PAL.
  
  // Do module specific code
  
  }

The integrator is responsible for defining the load/invocation order of the KMILs in the platform registry.

Extending the kernel's interface

Second use case, i.e., if the PAL (or another KMIL) wants to notify KMILs of some operation, e.g., waitForExternalClockSync().

The PAL:

Defines waitForExternalClockSync() as a public empty function.
Calls the new function where appropriate, e.g., from waitForNextSystemTick():

 ... waitForNextSystemTick(...)
   ...
   waitForExternalClockSync(...); // call the new function
   ...
   return;

The KMIL does exactly as in the the above timerWrite() case, substituting waitForExternalClockSync for timerWrite.

Meetings

2024-03-07

Chris Pow, Matt Verreaux, and Ryan Roffelsen joined the team. Here are the notes:

Issues/Topics:

1. Platform interrupt aggregation under the control of the device
   driver, e.g., PRL code, registry specification implemented by
   kernel, PPI to access registry information to allow PAL to do
   aggregation.
          
2. PRL response to to raisePlatformInterrupt

   - Some implementation of twiddling hw prior to calling
     raisePlatformInterrupt().  E.g., Ryan's example: pacify device
     before masking the interrupt to PCI minimize spurious interrupts
     and/or confused HW state due to failure to acknowledge interrupt.

   - PRL implementation of KMI (not sure this is a good idea).

3. Interrupts need a thread, and a thread can only be assigned to a
   single window.  How to handle clients in multiple windows?

   - Perhaps synchronous interrupts?
   - Relax constraint of one ISR, e.g., ISR per scheduler, ISR span
     schedulers, etc.
   - Make KMIs be kernel known so KMIs are easier to manage/specify.
   - Make use of other cores, or other SoC processors to handle I/O.

4. If we added window/thread timer numbers to registry and be probed
   by PAL?

5. PIC properties (edge/level, polarity) configuration.
   Might be solvable via a table mechanism.

6. Registry specified multiplier and Divisor to convert clocks to
   engineering units, may need capability to permit PAL to dynamically
   compute.

Action Items:

 1. BSP/Driver team provide "nice to know" data that the registry
    could provide, e.g., platform resource specification where the
    interrupt controller is, etc.

 2. Make platform resource description available to PRL registration
    function. 

 3. Can an application determine if a feature provided feature was
    used, e.g., to customize library resource usage.

2024-03-14

We discussed having a "board provisioning" operation where configuration data (ideally attribute/value style) could be placed on the target to handle things like Ethernet Mac addresses. Placed at a customer specified address, and then the address be given to makeboot and/or hypstart so that the address was available, for example, via the boot interface object. That way the existence of the object, and its address would not have to be a compile time constant in any code. The format of the configuration data was not seriously discussed, but the desire for metadata is so that it can be extended in the future as other data items are needed. Perhaps device tree format?

We also discussed a refinement of the "phased boot" approach and developed a sketch in drawio. See https://deos.ddci.com/scm/Deos/products/bsp/dev-kit/proposals/phased-boot-proposal-01.drawio

2024-04-04

We updated the boot proposal: https://ddci.zapto.org/scm/Deos/products/bsp/dev-kit/proposals/phased-boot-proposal-02.drawio

DeosBoot currently does:

Issue much architecture specific:
Verification:
- Structural coverage is a concern.
- Requires emulator to run tests. Two reasons:
  1. Tests require a power cycle between.
  2. Saving results between tests.
- Team is generally happy with result:
  - Same test strategy and infrastructure can be reused.
- Losing a board might necessitate removing features.
CPU init:
1. Very early, e.g., necessary to test DDR
2. Init required only once per power cycle.
3. Init required for each kernel entry.
Results are very architecture specific.

Boot image file loading features we might need to add:

Way to disable integrity check.
Way to inhibit relocation (e.g., special case source==dest).

Topic for next week:

"Phases" Impact on verification. Seems like lots more work.
Where do these components "live", in CM and in /desk.

Topics for next weeks:

The PAL, and "PAL functions" (a PAL for the PAL) available to customize.
1. Clock rate (e.g., convert ticks to ns/ms).
PAL support multiple GICs (versions)?
Interrupt management by (PRL) drivers. Invite driver team.

2024-04-11

sdiv and udiv are included in ARM v8 for both 32 and 64-bit. I.e., they no longer need to be provided in software.
1. Note, on ARM v7 the PAL can use the kernel's div runtime implementations.
2. Probably would need capability to providing more accurate (non-floating point) rate conversion functions (e.g., ticks to ns).
3. Issue: is there a performance issue here? E.g., is computation with compile time constants noticeably faster than using runtime only known values.
  1. Suggest a benchmark?
    1. result due 04/25
    2. compare calls with constants to func(time, num, den) { return (time*num)/den; } vs calls where function is in a different file.
    3. pick (num, den) values from several existing BSPs, call each 10k times.

PAL Interrupt Delegation Proposal 1

PAL has two interfaces for Interrupts platform and "logical".
The PAL provides a set of PPIs for masking and unmasking logical interrupts, e.g., maskLogicalInterrupt(n).
PAL has a vector of "handlers" for each logical interrupt.
1. The handler is probably a tuple <raise, mask, unmask, etc>
The PAL would respond to (un)maskPlatformInterrupt by calling the associated logical interrupt handler
A PRL could register, i.e., set the PAL logical interrupt handler for an interrupt to be functions provided by the PRL.
The PRL would take responsibility for masking the interrupt when its raisePlatformInterrupt, and, for example, in the case of aggregated interrupts, mask and unmask several logical interrupts whenever any of the associated platform interrupts needed to be masked.
Profit.

Still missing:

Need polarity and sense information associated with each logical interrupt.
1. Would need some "registry like" information for edge vs level, and high vs low, rising vs falling.
2. Need kernel to provide API to query interrupt information, and for the registry to contain polarity and sense.
3. TODO: Aaron to contact kernel team to see if we can get a kernel feature to query interrupt info.
4. TODO: same for adding polarity and sense to registry.
5. TODO: Can we make the registry information about interrupts sparse? PCR:11101
  1. Rationale: is to reduce startup time, e.g., 1k interrupts possible, sync interrupts must be after that.
PAL documentation should show mapping from physical to logical interrupts.
1. e.g., how interrupt controllers map to logical interrupts.
Issue: How does having common boot and pal affect user documentation?

  // Sample code
kernel calls PALInterruptHandler()

PALInterruptHandler():
   lookup which physical interrupt occurred and translate to logical.
   call table[logical interrupt number].raise()

PCI initialization:

PCI config parsing is common.
Initialization of PCI bus is sometimes platform specific
1. Window settings affect BAR addresses.

TODO: Aaron to look at celestial (see BSP ug) vs layerscape (de1048a) BSP.

Proposal:

new libpci.so library with "pci coldstart" and "pci warmstart" functions.
perhaps provide stub "do nothing" libpci.so that implements "no op" functions for "pci coldstart" and "pci warmstart".

2024-04-12

Aaron talked with Ryan about: #PAL Interrupt Delegation Proposal 1 specifically these TODO items:

TODO: Aaron to contact kernel team to see if we can get a kernel feature to query interrupt info.
TODO: same for adding polarity and sense to registry.
TODO: Can we make the registry information about interrupts sparse? PCR:11101

With respect to interrupts the response from the kernel team is that the query API is acceptable. A counter proposal is that the registry contain a collection of the information about each logical interrupt(s) that is/are associated with each platform interrupt. The proposal is that the information about the logical interrupt would contain its number and "stuff that the PAL needs". The intent is that the integration tool team and the BSP team would agree on what that data should be (i.e., the kernel is not involved). The expectation is that the logical interrupt data would contain at least the polarity and sense data. For backward compatibility reasons the suggestion is that the collection would have a "number of logical interrupts" and also a size of each the information associated with each logical interrupt so the BSP could be backward and forward compatible to registry definitions.

There is already a PCR (noted above) for making the interrupt information sparse. The request is suspended pending benchmark feedback that indicates performance is not acceptable.

Observation: Perhaps the fact that we might make the platform interrupt information sparse means the query interface should be based on "the N'th platform interrupt rather than platform interrupt number N".

Observation: Now that the PAL has the logical interrupt information, should the PAL do the interrupt aggregation? Or should that continue to be delegated to the PRLs?

Regarding the proposal:

new libpci.so library with "pci coldstart" and "pci warmstart" functions.

I.e., the issue of PALs conditionally needing other capabilities. The possible "solution" of using kernel library interceptor capabilities was discussed. There was tentative approval of the direction, although specifics were not discussed other than to note that a possible strategy would be to have the registry contain a "list of PALs" and that the PALs be added to the kernel object file record before the kernel. The latter is so that the PALs could intercept calls back to the kernel. How to handle registration functions was not discussed.

The topic of changing the registry to have "numerator and denominator" data for the PAL was also discussed and tentatively approved.

Tasks

Provide a way for components to levy requirements on BSP
1. Or better, figure out how to make formerly BSP related constraints be pushed out to drivers.
  1. E.g., BSP_Support_PhysicalAlloc

Be A Maintainer

Updates to dev-kit

Add selection archive support to all BSPs. (following notes were from geekfest 2023 phys-alloc discussion)

BSP Dev-Kit

Mode changing: Which things should be initialized in mode changes.
Boot image files including selection.
1. Have the reference BSPs load a selection archive with a default behavior: Let's say, if the first image fails, load the second one. The current Dev-Kit implementation supports any sort of mutation of the image-to-load.
OA loading DeosBoot.bin to NVM
1. Add support on OA to the boards that have been integrated with vfile so that OA allows the user to load some image to a well-known location such that U-Boot can later be told to load the file from NVM and OA.
PCI config: It looks like adding this feature to a reference BSP is not very convenient as the reference BSPs rely on Uboot's PCIe configuration.
1. Long-term plan for PCI support on reference BSPs
TDL Support: This is linked with supporting the flash of DeosBoot.bin in NVM.

Questions

BootRAM and DeosFlash location: This issue was resolved with the creation of the BOOT_ARCHIVE that has first priority, so the BSP can tell the user to put the selection archive, composite archive, or LFS at UNALLOCATED_RAM.
1. Boot needs to know the location of boot RAM before loading the hyperstart image i.e. A temporary location to load the image from the Non-volatile storage. Once the image header has been validated, boot loads the image to its storage destination (this is read from the header). Where is this temporary location going to be located?
2. For reference BSPs, the UG documents the location the user must load the hyperstart image to. How will the BSP communicate this location if it is defined during integration time? ANSWER: The decision is that boot uses the address of UNALLOCATED_RAM as the address in the UG.

BSP standard capabilities and optional/custom capabilities

This is a first pass attempt to capture the standard and custom BSP capabilities to be provided. [PMZ]

BSP Responsibilities (Standard, U-Boot provided)

U-Boot
1. Initialize memory
2. Initialize serial device
3. Initialize ethernet
4. Initialize pci
5. Initialize buses
6. Initialize GPIOs/Pads/PLLs
deosBoot
1. Identify primary and secondary CPUs
2. Start kernel (primary core)
  1. Load the hyperstart image
  2. Extract the boot interface object from the SRT
  3. Initialize the CPU
  4. Initialize video memory
  5. Let the secondary cores enter the kernel (if configured to do so)
PAL
1. Set up timers
2. Set up interrupts
3. PALcoldstart
4. PALwarmstart
5. powerLossDuration
6. waitForNextSystemTick
7. frameSynchLostTickIndex
8. pollForSystemTick
9. timerWrite
10. timerTimeRemaining
11. setActiveWAT
12. windowTimerWrite
13. windowTimerTimeRemaining
14. unmaskPlatformInterrupt
15. attributeChangesPermitted
16. PALExtensionFunction
17. setCriticalLevel

Custom BSP

Bare metal / replace U-Boot responsibilities
- ALR: What about PBIT? Selection/Loading boot/hypstart images? Error Handling?
Other PAL capabilities

BSP Common 3.2.0 and Consistency Updates

In constants.py set BOOT_ARCHIVELoadPhys = unallocatedRam.phys with the preceding comment, then remove bootLoadPhys

     # The physical address the first stage boot loader uses as the
     # composite archive load address is the first address allocated in unallocated RAM.
     # See boot-archive.pia.xml for allocation of BOOT_ARCHIVE.

Search all files and replace as follows:
- bootLoadPhys to bootRAMStartPhys
- bootLoadPhysNoHex to bootRAMStartPhysNoHex
- hyperstartLoadPhys to BOOT_ARCHIVELoadPhys
- hypstart.loadAddress to bootArchive.loadAddress
- hypstart.loadAddress.nohex to bootArchive.loadAddress.nohex
- hyperstartLoadPhysNoHex to BOOT_ARCHIVELoadPhysNoHex

In the openarbor.options file, remove the cd in <componentDescriptor xmlns="http://www.ddci.com/cdoptions">, e.g. <componentDescriptor xmlns="http://www.ddci.com/options">
- The schema must be added if not present, the full schema header for the options file is listed below
- For now, you have to make a hack to get this to work when releasing a BSP. Soon we'll get an update from OpenArbor to fix this issue, but until then you must do the following in each WSL distribution or docker container:

     <componentDescriptor xmlns="http://www.ddci.com/options" 
                          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
                          xsi:schemaLocation="http://www.ddci.com/options ddci:/xsd/componentDescriptor.xsd">

     sudo sed --in-place -e 's:/cdoptions:/options:g' /OpenArbor/etc/xsd/componentDescriptor.xsd

In all makefiles
- Change MORE_FILES_TO_CLEAN to CLEAN_FILES (this is more in line with the OpenArbor make system
- Change multiline lists to each do a += instead of
- Remember to remove the '\' at the end of the line

     palDevKitObjects    = $(palDevKitObjects_$(HOST_ARCHITECTURE)) \
                           armv7-common-timer.o \
                           etc
     to 
     palDevKitObjects += $(palDevKitObjects_$(HOST_ARCHITECTURE))
     palDevKitObjects += armv7-common-timer.o
     etc.

- Replace CC_SWT with CPPCC_PROJECT_SPECIFIC
- On arm platforms, thumb is no longer the compiler default, so the following can be removed:

     DEOS_COMMON_arm :=$(subst -mthumb -mthumb-interwork,-marm -mthumb-interwork,$(DEOS_COMMON_arm))
     $(bootObjects): ASM_NATIVEAPPLICATION_arm :=$(subst $(aComma)-mthumb$(aComma),$(aComma),$(ASM_NATIVEAPPLICATION_arm))

GIC variable declarations are only made to avoid warnings and should be removed

     # These are not necessary for this platform.
     # They're set as empty definitions to avoid warnings about them not being defined
     gicDistributorSizeInPages =
     GICCPUInterfacePhys =
     GICCPUInterfaceSizeInPages =

Remove unwanted projectSpecificSwitches if present
- -DDEOS_ALLOW_OBSOLETE_DEFINITIONS

Break apart constantsBangvarTargets into seperate variables for their own makefiles
- addEntities.ent should be included in the boot makefile

     In PAL
     constantsBangvarTargets += $(bootLinkerScript) config.h addEntities.ent basecon.hyp basecon.pia.xml basecon-resources.pia.xml
     To
     In Boot
     constantsBangvarTargetsBoot += config.h
     constantsBangvarTargetsBoot += addEntities.ent
     constantsBangvarTargets += $(bootLinkerScript) $(constantsBangvarTargetsBoot)     
     In Config
     constantsBangvarTargetsConfig += basecon-resources.pia.xml
     constantsBangvarTargetsConfig += basecon.pia.xml
     constantsBangvarTargetsConfig += basecon.hyp
     constantsBangvarTargets += $(constantsBangvarTargetsConfig)
     In PAL (if present)
     constantsBangvarTargetsPAL += ...
     constantsBangvarTargets += $(constantsBangvarTargetsPAL)

Remove BSP_PROGRAM_OBJ and replace with the variable that it is being assigned to in that makefile

     $(BSP_PROGRAM_OBJ) : $(BRANCH_PREFIX)/code/shared/$(wildcard *constants.py)
     To
     $(bootObjects) : $(BRANCH_PREFIX)/code/shared/$(wildcard *constants.py)
     Or
     $(PALObjects) : $(BRANCH_PREFIX)/code/shared/$(wildcard *constants.py)

Add a rule when adding to ASM_SWT variable to make it localized to that makefile

     ASM_SWT += $(constantsMacros)
     To
     $(bootObjects) : ASM_SWT += $(constantsMacros)

Remove rule for bootDisassembleFile:

     $(bootDisassembleFile) : $(bootDebugExecutable)
     	 $(quietMessage)
     	 $(QUIET)$(OBJDUMP) -d $< > $@

To achieve this, it is required the disassembled file target name is <basename>.dis (no .exe.dbg.dis or any permutation). Also, the interim 64-bits boot binary produced for ARM can leverage this rule. But there is something additional to consider: The rule uses the objdump utility for the compiler for the HOST_ARCHITECTURE architecture. This is a problem because for ARM, the architecture is ARM. To solve it, set OBJDUMP to the correspondent obj dump utility for aarch64.

    $(bootx64DisassembleFile) : OBJDUMP=aarch64-elf-objdump

Remove VPATH addition of uboot-bin, if present in the BSP (This still needs to be tested, will be updated when confirmed)

     #VPATH += $(BRANCH_PREFIX)/uboot-bin-$(APP_CONFIG)

Add VideoBffer memoryMappedResource to the basecon-resources.pia file if not present

              <memoryMappedResource 
                   name="VideoBuffer" 
                   startAddress="!videoMemoryStartPhys!" 
                   lengthInBytes="!videoMemorySizeInBytes!" 
                   accessRights="r" 
                   allowMultipleOwners="yes" 
                   cacheMode="off" 
                   resourceOverlapList="" 
                   proxyAccessPermitted="yes"
                 > 
              </memoryMappedResource>

Remove basecon.makeboot file if it is not supported

Set any variable declarations = to nothing to ?=

Single space between code blocks and comments

Spaces before and after :'s when declaring rules in make

BSP Project