PIA Project

From DDCIDeos
Jump to navigationJump to search

Description

This project is to enable components to allocate physical addresses, notably RAM, without having to change the BSP to do so. The types of physical memory considered:

  • Platform resources
    • MFS
    • DMA buffers
  • DEOS_FLASH
  • DEOS_RAM, i.e., pool 0 range 0 (p0r0 below).

The basic idea is to introduce a phase of platform project build that would create/modify:

  1. basecon.hyp (DEOS_RAM and DEOS_FLASH)
  2. platreg.pi.xml (Memory mapped resources and DEOS_RAM pool(s))
  3. mkkfs configuration

The project also considered other steps to remove knowledge from the BSP so that the BSP itself would be less susceptible to changes due to changes in application code, e.g., moving/resizing Network Buffers, or the presence/absence of CFFS (see #BSP_Simplification).

Status

Implementation has begun.

for build instructions: https://ddci.zapto.org/scm/test/projects/phys-alloc/

PCRs: Deos DDCI

Goals

Dreams:

  1. Eliminate driver and application induced churn in BSPs.
  2. Enable assembling a customer BSP using off the shelf drivers and a base BSP using OpenArbor only
    • I.e., it works that well.
    • Supports testing (at least informal) of the generated BSP.
    • Includes documentation and other "normal" BSP artifacts.
  3. Enable user to do more things without "copy for editing" and eliminate the need to copy more than what is needed.
  4. Reduce the cost of the CVTs
  5. Enable a component, e.g., vfile, to be added to OpenArbor without needing OpenArbor to change.
    • At least for makefile stuff.
  6. Only one reference Boot/PAL for any SOC, perhaps every (related) family of SOCs

Attainable:

Use Cases

  1. Create a child platform that:
    1. Adds a (vfile?) driver
    2. Adds another Ethernet interface (multi-home)
    3. Adds a second lwip instance (multi-network)
    4. Adds an MFS
  2. User adds or changes various PI section data.

Proposed BSP changes

  1. Eliminate -kernelFile lines from basecon.hyp
    • Can be done immediately
    • Affects:
      • test infrastructure which will temporarily take on responsibility for providing -kernelFile info for every active platform
      • test_elfchk. Proposed alternate is a hard coded list of files with likely stable dependencies
    • Ideally would be replaced by OpenArbor ability to process .options and .cd.xml files from command line.
  2. Eliminate memory mapped resources and memory pool information from basecon.hyp and platreg.pi.xml
  3. Eliminate DEOS_RAM*, DEOS_FLASH*, mem{Block,Gap,Offset}* from basecon.hyp and platreg.pi.xml
  4. Make basecon.hyp file contain only switches destined for hypstart.py
    • Probably requires some minor changes to makeboot, e.g., eliminating the -DEOS_{RAM,FLASH} switches
    • This would be a major step to enabling toolCrib.py to generate errors for unknown switches.
  5. Remove application specific resources from platreg.pi.xml
    1. Usernames, groupnames, files
      • IT could default these to existing BSP content
    2. schedulers, windowActivationTables
      • IT could default these to values based the assumption that system tick is fastest period and have one scheduler per core, etc.

Physical Alloc Capability

Issues

There were several substantial issues discussed related to physical memory allocation activity.

  1. Spurious re-hyperstart needs to be minimized.
    1. Some changes, e.g., to size of DEOS_FLASH, can't be avoided.
    2. Whether a change requires a re-hyperstart is highly system configuration dependent, e.g., if boot must load the MFSes on a hyp index change.
    3. Changing an MFS that OpenArbor can update via /proc/res may or may not force a re-hyperstart, but recovering from an uninitialized MFS would require support from OpenArbor, e.g., to do a full /proc/res download.
  2. DMA. Changing the physical addresses of a memoryMappedResource supporting DMA would likely lead to a non-functional box after a registry change.
    1. Requiring a consistent memory map across all registries would be hard to manage.
    2. Suggestion is to introduce a DMA shutdown protocol, either in the kernel or at the application level. How is TBD (see #Meeting Notes).
    3. Having a shutdown protocol is key to making this capability reliable during development.
    4. Having assurance that DMA is turned off in all devices is sometimes a (DAL A) customer requirement.
  3. Is this a new tool, or a mod to IT?
    • Either seems technically feasible.
    • Using IT would imply CVT support.
    • Using new tool would either imply a new CVT, or forcing the user to use the output .pi.xml file as the input for the final system. I.e., verified systems couldn't use .pm.xml files.

Proposal 1

Tasks

  1. The tool (mem info output file fragents DEOS_RAM+..., resource specs, etc.
  2. makefile foo to glue it all together (for open arbor)
  3. config component changes, what are they?
  4. Changes to components:
    • DMA, firewire, network drivers,
  5. zcu102 BSP "updated" to proposed new content.
  6. Everyone Identify/track what documentation updates are required, e.g., updating rates.

2021-11-10 action items.

  1. Adina develop proposed new BSP content.
  2. GK develop refined proposal for tool.
  1. New .pm.xml format that can define an available range of memory or allocate physical memory.
    • alternately could have .am (available memory) and .ma (memory allocate), or similar
    • These files are "integration tool files"

The files would be processed either by the pi tool, or a new "preprocessing phase" tool that would accept a .pi file as input and output an updated .pi into the workspace's output/ directory.

Conceptual sample files: 

<available-memory
   name = "string"
   startAddress = integer constant page aligned address
   sizeInPages = integer constant
 Unclear if this could/should be permitted to have a single range (block/gap/offset)
/>
<allocate-memory
   name = "string name of output .pi memoryMappedResource or memory pool"
   source = "the name of an available-memory"
   sizeInPages = integer constant or expression or "left over"
   alignmentInPages = integer constant (or expression?)
   stripingPermitted = bool (if available-memory can be striped)
   allocationDirection = {begining,end}
>
  Optionally a single range striping specification
    - This applies to either platformMemoryPool or memoryMappedResource
    - Note that multi-range memory pools would not be specified with
      this mechanism (to reduce tool complexity)

<!-- Optional additional output formats:
   hypstart related: generate hypstart DEOS_FLASH, DEOS_RAM switches to a file.

   kfs related: generate -storageBlockAddress and -storageBlockLength switches

   memory pool: would output .pi.xml platformMemoryPool, this field
                would include the extra fields, e.g., aliases, and id,
                and would incorporate the striping specification.
</allocate-memory>

The .pm files would be processed in an arbitrary but stable order from one run to the next, e.g., all "left over done last" and rest sorted by name. Alternatively a list of the order the .pm files must be applied in which could be maintained by the make system and seeded by the BSP (e.g., do DEOS_FLASH first). The purpose of allocationDirection is to minimize changes that would cause a re-hyperstart (e.g., deos_flash) vs those that "might not", e.g. "network buffers" or an MFS.

The makefile system would incorporate the hypstart and mkkfs switch files into the building of the hypstart and MFS files. Some makefile magic would detect hypstart sensitive changes to the DEOS_RAM and/or DEOS_FLASH and cause OpenArbor to prompt the user to perform a re-hyperstart. Proposed criteria: any change to deos_flash, or a change to deos_ram that affects the starting address or reduces the length to something less than the BootInterfaceStructTYP.numRamPagesToInitialize. This warning could be generated after rebuilding the hypstart image and comparing old with new.

Sample artifacts

The BSP would provide a .pi.xml file similar to today, but with all memoryMappedResource instances for "buffer like" things and DEOS_RAM and DEOS_FLASH removed. The BSP would newly provide a .pm.xml file describing all available ram, e.g.,

available-ram.pm.xml: 

<available-memory name="available_ram" start=xxx .../>

and add a .options dependency on simulated-deos_flash.pm.xml and deos_ram.pm.xml

The basecon.hyp would replace DEOS_FLASH and DEOS_RAM switches with

  • @deos_flash.hyp
    @deos_ram.hyp

Every component, that needs a memory mapped resource would provide a .pm declaring its need, and specifying allocationDirection=end. This includes drivers needing DMA buffers, or components like CFFS. For example, lwip would have:

  • lwip-network-buffers.pm.xml

The "desk" (standard-apps?) would provide:

  • simulated-deos_flash.pm.xml
<allocate-memory
  name="DEOS_FLASH"
  source= "available_ram"
  size=32MB
  allocationDirection=beginning
>
  <additional-output-formats
    <output-format format="hypstart" name="deos_flash.hyp"/>
  • deos-ram.pm.xml
<allocate-memory
  name="DEOS_RAM"
  source= "available_ram"
  size="left over"
  allocationDirection=beginning
>
  <additional-output-formats
    <output-format name="deos_ram.hyp"/>

It would be helpful if the resulting output files contained a comment providing the name of the source .pm file from whence the content originated.

Proposal 1a Device .pm Files

We could specify all physical memory resources via .pm files, even those for devices by adding an optional startingPhysicalAddress attribute. This would permit the .pi.xml file to only include the resources that are needed by the BSP and provide a clean way to remove and/or keep devices, namely by just removing the dependency on the device's .pm file from the .options file.


Proposal 2

Issues TODO: striping,

  1. Could have platform define "basic stripe" (e.g., smallest block+gap size)
  2. User could define stripe objects in terms of "basic stripe"
  3. platform resources and pools could be defined in terms of stripe objects
  1. platform resources:
    1. suggest manual for now (user has to allocate a block then construct stripes within it
    2. Could introduce a stripe object and pass that to allocate.
  2. pools: ???

order of allocation: Later/enhancement: allow user to specify total order via a list.

Introduce a new tool (called physmem below TODO: better name) that would input:

  1. basecon.pi.xml (provided by BSP config component), and
  2. any number of .platres.xml (provided by drivers), and
  3. any number of .mempool.xml files (provided by IT, kernel, or ??)

It would output:

  1. An updated platreg.pi.xml

The basecon.pi.xml (not platreg) file would include BSP defined platform resource(s) (exception vectors, boot stack, etc.) but no driver or application resources. It would also include a specification of the "unallocated RAM", expressed as a memory pool named UNALLOCATED_RAM.

.platres.xml file would have the same format as existing IT: 

   some header goo
      <memoryMappedResources>
         <memoryMappedResource
              name = "CFFS_RAM_RW"
              startAddress="allocate(from=^UNALLOCATED_RAM^)"
              lengthInBytes = "0x2D00000"
              accessRights = "rw"
              allowMultipleOwners = "no"
              cacheMode = "off"
              resourceOverlapList = "CFFS_RAM_RO"
              proxyAccessPermitted="yes"
            >

TODO: need to describe platformMemoryPools modifications as well (ref deos-ram.pia.xml).

Enable startAddress to include some new expressions: 

  1. allocate()
    See below.
  2. startAddress(resname)

Similarly enable lengthInBytes and cacheMode to have new accessor expressions (e.g., to create alias resources):

TODO:[for GK], should the strings be ^^ quoted always, or only if they contain spaces? No ^. The xref resource is whatever is between ( and ) 

         <memoryMappedResource
              name = "CFFS_RAM_RO"
              startAddress="startAddress(^CFFS_RAM_RW^)"
              lengthInBytes = "lengthInBytes(^CFFS_RAM_RW^)"
              accessRights = "r"
              allowMultipleOwners = "yes"
              cacheMode = "cacheMode(^CFFS_RAM_RW^)"
              resourceOverlapList = "CFFS_RAM_RW"
              proxyAccessPermitted="yes"
            >

startAddress can contain a call to allocate() or startAddress(): 

allocate(aligned=alignment, from=source, priority=pri, direction=dir)

Allocates lengthInBytes contiguous memory from the 'source' platform resource.

  • alignment is a power of 2. defaults to page size
    • TODO: must alignment be at least page size?
  • from/source is a platform resource name, default is 'UNALLOCATED_RAM'.
  • priority is first, first+1, ...first+n, default, last-m, ..., last-1, last, default is 'default'.
    • Priority is expected to be irrelevant for verified components, it is only for development. See DMA below.
  • direction is start | end, default is 'end'

For each source, allocation is done ordered by: direction('end' first, then 'start'), priority, alignment(larger first), name. If there is an allocation that specifies "remaining()" it is performed last. There can only be one "remaining()" for a given resource. 

 startAddress(resource name)

lengthInBytes can be a call to lengthInBytes(), or "remaining()" 

 lengthInBytes(resource name)  returns lengthInBytes of the resource.

remaining() means the associated allocation will consume all remaining memory from the source. TODO: should remaining() take a "minimum amount of space required" argument?

cacheMode can be a call to cacheMode() 

 cacheMode(resource name)

For platformMemoryPoolRange:

startingPhysicalAddress can be allocate() or startAddress() (see above for both)

sizeInPages can be lengthInPages() or "remaining()" 

 lengthInPages(resource name)  lengthInBytes of the resource converted to pages


TODO: [TBD] If a platform resource that was the source of any allocate becomes zero length it is omitted from the .pi file.

DEOS_FLASH and DEOS_RAM pool 0 range 0 would be the only (suggested) direction=beginning resources. DEOS_FLASH would have a priority of first, DEOS_RAM pool 0 range 0 first+1. DEOS_RAM first+2. No other beginning+first resources should be defined (Rationale: due to hypstart dependencies, if DEOS_FLASH or pool 0 range 0 is changed requires re-hyperstart).

DMA resources that are active in download mode would be priority first (or perhaps the first 10 priorities). (Rationale: priority is to address file system modification and DMA interactions). Hopefully the only such resources are for network.

KFS resources would be next. (Rationale: If a KFS' physical location is updated its contents will be scrambled on a mode change that gets a registry with the updated addresses.)

TODO: perhaps we should have some symbolic names, e.g., priority=KFS, DMA

TODO: should lengthInBytes by enhanced to accept: decimal-integer {GiB, MiB, KiB, pages)?

  1. To address spurious DMA accesses when a change is made to a "DMA priority" resource OpenArbor could force /proc/res access when doing any file system update and/or initiate a second reboot before checking for file system changes.

Resources that are intended for persistent data, e.g., KFSes would be next highest priority.

Integ Tool Proposed Changes

IT (or kernel?) would provide default .pia.xml for the .pi.xml content for:

  1. periods
  2. schedulers
  3. windowActivationTables
  4. usernames
  5. groupnames
  6. files

Currently the IT has default values for these built into the IT. Making them explicit files would make it easier for users to know how to modify the defaults.

  • TODO: OpenArbor copies the output .pi.xml file back to the "copy for editing" version, so it makes it tough to retian the separate file content.

Driver Content

Drivers install files into platform directories.

parent platforms describe inheritance 

 desk
  ppc              -- Drivers would install binaries at this level
  platform
    t2080          -- Drivers would install XML for interrupts and registers at this level
      nai68ppc2    -- cd.xml and lwip.config for integrating drivers at this level.
      celestial
      t2080rdb
      nai68ppc2-db

Driver would be comprised of two packages:

  1. Binaries
  2. Configs -- XML files for the boards where the driver is ported.
    1. These might be installed into any of several directories

TODO: XML file naming convetions:

  1. component.cd.xml
  2. How to represent bus and unit numbers?


If resource exists in BSP but an updated driver creates a .pia file that generates a conflicting platform resource TODO:...

Each driver would deliver files named (options): TODO:

  1. the same as the resource name
  2. the component name + resource name
  3. "res-" + resource name

openarbor to use basecon.pia.xml as indicator to use the "new tool".

ISSUE: what about .fp files that create memory objects? Presume no longer needed (allowed?).

Proposal 3

Perhaps rather than .phys mem, we should define .pia (platform integrator adjunct)

  1. Define not only plat res and pools, but also groups, periods, etc. as individual files.
  2. much smaller stuff to copy/modify.
  3. basecon.pia would contain essentially nothing.
  4. pi/pia tool would merge all definitions.
  5. Mixed bag for users.
    • + Less collateral copy damage
    • - Harder to find item to edit
    • - Getting an editable overview (e.g., complete .pi file) would be a tooling problem.

Issues

  1. Changing size of DEOS_FLASH and MFS images is now easier and more reliable, but requires knowledge of yet another XML format.
  2. Chaging resources during development likely will be unreliable until shutdown protocol is implemented.
    • Should be completely solid for "from scrath build and flash board" scenario.
  3. Making multi-range striped resources will require user to hand edit .pi file.
  4. Physical memory layout is even more obtuse until .cck file is viewed.
    • Could have IT output xml format which we could view in OA or browser as either html or graphically.
      • xml stylesheet for tabular HTML would be trivial. svg would be slightly harder.
      • having "source of resource" in .pi and/or report .xml file would enable easier editing of the source input from such a view.

Migration Proposal

  1. DAL E components: re-release them with bloblet support.
    • Should be pretty easy and wouldn't require much if any testing
  2. DAL !E components: two options:
    1. delta-baseline
    2. Add cygwin/linux dependent package (e.g., cffs-pm-files) that provides .pm.xml support. When component is next updated, make dependent package empty.

Background

Meeting Notes

Aaron, Adina, Chris, Gary, and Ryan (AL, AR, CP, GK, RR) had several teleconferences between 2021-10-04 and 2021-10-13 to discuss this project. The following are the notes. The phrases containing "blob" correspond to something that can specify/allocate addresses, the form was not well envisioned. 

Need the ability at integration time to allocate physical memory for:

  MFS
  DMA buffers
  Hyperstart/Boot image

Proposal:
  The IT would provide some syntax that approximates the following
  function:

  PhysicalAddress64
  allocatePhysMem(lengthInPages,
                  sourceMemoryPool,  // Where the memory will come from
                  bool stripingPermitted)
                  physicalAddress=automatic // maybe, but was contentious

Normally physicalAddress will be computed by allocatePhysMem(), but (to
satisfy the boot image use case) it can be a physical address an it is
up to the integration tool to use that address.

Top level options
 - deblobber
 - .fp files that allocate mem from memory pool

Questions:
  pool or range?
  How do we deal with p0r0 vs p0r1.
  Most BSPs have only one range in Deos RAM?
  Is DEOS_RAM resource needed?
  Does the p0r0 range have the same name in all BSPs?
  Would removing DEOS_FLASH from basecon.hyp help?
  DMA concerns (change of physical addresses)
  Re-deblobbing can cause spurious re-hypstart/flashing.
    - could be reduced by:
      - order of bloblet applications
      - alloc from front or back
      - Having allocation have some stability property.
    - depending on configuration some changes may/may-not cause a
      re-hyperstart, e.g., 
      - changes to registry living in LFS --> rehyp, living in MFS "maybe not".
      - changes to kernel.
    - having a shutdown hook would resolve need to re-hyp due to
      changes to DMA platform resources.
      Options:
        - register a "shutdown hook" with the PAL.
        - Kernel "unloads" the PRLs.
        - user mode signalling mechanism.
        - What is required assurance level of "no DMA".
      Concerns:
        - latency
        - Need for user mode application interactions before shutdown.
        - Discretionary?
      Affected components:
        - All DMA drivers: network, ???

Classes of resources: (seems bogus)
  - 1 (DMA)
    - coldstart allocatable
    - same between registries (would be alleviated by shutdown hook)
    - Can change location readily between 
  - 2 
    - location must be persistent across 

Is this a development time issue only?

BSP provides
  physical memory range(s) name[start:end]  available_ram
  possibly some (default) bloblets deos_flash
  basecon like today sans DEOS_FLASH
  pi like today, but without:
    - (specific) ram based memory resources
    - memory pools, unsure of p0r0

components provide:
  bloblet (requests for allocation of physical memory)

Bloblets:
  specification of physical memory needed:
   - size + alignment
   - rest of memory (to handle deos_ram for apps)
   - striping?
  output type:
     pi resource
     pi memory pool
     basecon content:
       deos_flash
       deos_ram (p0r0)   Kernel heap
       memory pools
     
(de?)blobber
  inputs:
    - physical memory range + ordered list of bloblets
    - basecon
    - pi.xml (e.g., from BSP)
  outputs:
    - basecon.hyp content (or just hypstart?)
    - pi memory resources and/or memory pools
      is this a full .pi file, or inputs to the IT?
    - mkkfs and mkarchive config files

  things:
    - MFS
    - DMA buffers
    - DEOS_FLASH(?)

How is striping addressed? if at all.

Migration:
  - How to minimize churn in BSPs as drivers incrementally become
    bloblet aware?
    - enumerate all existing resources and for those resources permit
      bloblets to silently override specification in bsp provided
      .pi.xml.

Need:
  - shutdown hooks
    without this:
     - pi files must be consistent in their DMA buffers.
     - MFS resources must be files 

DDCI Migration path:
 - Can "create resource" .fp.xml coexist with pi.xml specified resource?
   - 2 FPs creating the same resource is an error, if PI&FP does then don't?
     - may not be possible.
 - Still need ability to have BSP override of component specified
   values, e.g., network buffers
 - What is the name of the pool defined by the BSP.
 - QEMU makeboot extension computes qemu ram requirements based on deos ram

What components would need to be updated
 - (All?) network drivers
 - firewire
 - cffs
 - usb
 - tte
 - dma drivers.
 - all "active" BSPs 10-15
 

Thoughts on syntax:

platformResource
   physicalAddress = 0x... or allocatePhysMem()

findOrAllocateResource

<ramResource
  name = "mmr-2"
  lengthInBytes = "0x1000"
  accessRights = "r"
  allowMultipleOwners = "no"
  cacheMode = "writeThru"
  resourceOverlapList = ""
  proxyAccessPermitted = "yes"
  a: physicalAddress = xxx
  b: 
      platformMemoryPool = "0"
      stripingPermitted = bool
      mustBeFirst
>


--------------------------------------------------------------------------------
Discussion with RLR:

p0r0
platform resources

memory regions (video mem, test results)    owned by BSP
other regions mapped to RAM (not currently supported)

pool 1 = blob - deos_flash - p0r0
memory mapped resources come from pool 1

define memory pool aliases for standard apps

Need physical address alignment requirement.

--------------------------------------------------------------------------------
2021-09-30
AL, AR, CP, GK, RLR


contents of available_ram.?.xml:  
   list of physical "ram like" address ranges:   name, start, length
    ram_config.?.xml:
       low_ram: 0x000... to 0x....10000  can this include multiple ranges?
       high_ram: 0x000... to 0x....10000  can this include multiple ranges?
       sram3: 0x000... to 0x....10000
    app_and_kernel_usable = low_ram, high_ram
    cache line size?

deblobber tool takes available_ram.xml as input and generates stuff
  for IT to define platform resources.
  Might take in "template like".pi and output a new .pi

The BSP delivers a file containing the "available" RAM like memory regions.
  MFS
  DMA buffers
  Hyperstart/Boot image
    deos_flash
    deos_ram?

component lwip:   Make me "network buffers":
  name = "network buffers"
  lengthInBytes = "0x1000"
  alignment?
  striping?
  from = "app_and_kernel_usable"

Can bloblets create pools?

kernel:
  reserve p0r0  --> hypstart
  DEOS_FLASH
  "give me the rest"  --> DEOS_RAM, i.e., memory pools



kernel-outputs:
  pi
  basecon content

deblobber inputs collection of debloblets
  It is important to specify some constraints on ordering, e.g., kernel first/last

debloblets need to be specified in .cd file, probably distinct from IT files.

stretch goal:
  have property of a file to say "gui user should not modify this file"

BSP migration
  deblobber capable BSP doesn't include a pi.xml, but assumes
  deblobber would.
  PhysicalAddress64
  allocatePhysMem(lengthInPages,
                  sourceMemoryPool,  // Where the memory will come from
                  bool stripingPermitted)
                  physicalAddress=automatic // maybe, but was contentious

BSP Simplification

On 2021-10-11 Aaron and Adina met to see what logically could be removed from a BSP, the notes follow: 

...how to further simplify the BSPs, or perhaps more accurately, how
to make the BSPs more ignorant of the system they support.

reference vs custom
  striping
    - should bloblet specify striping or the input
      "range"(available_memory)?
    - Do we need "must not be striped" property on a bloblet?
  bloblets
    Could "pi?" cck? keep track of the mechanism that created the
    resource, e.g., resource "fred" was constructed by fred.bloblet.
  platform resources via .fp files.
    Is there an "output" .pi.xml file that can be used by the integrator?
    If not, what would be the output containing the full resource map?

  Adina: have ability (for OA?) to "turn off" deblobletizer...

Suggested activities or interesting observations:
  basecon.hyp make it be hypstart specific.
    Note: makeboot switches are specified in .options file
    May need changes to makeboot to eliminate spurious dependency on switches.
  move debugComponent switches from bsp .options file to standard apps.
  what version of .pi.xml should BSPs be delivered with?
  Could there be default versions of rates, schedulers, windows, UGO,
  files, etc.?
  delete -kernelFile switches.

I took a look at celestial to see what is currently provided, and took
the following notes, hopefully it will be helpful to kickstart our
discussion:

basecon.hyp
    -platform=!platform!                    Present in .cd.xml file
    -subArchitecture=ppc_e6500
    -defaultRegistry=platregd.bin           Value is default for hypstart switch
    -hypFile=hypstart.bin                   Value is default for hypstart switch
    -maxCoreIndex=!bootMaxCoreIndex!
    -CCApartNo=00000055
    -memoryRegion="exceptions"              Hard to eliminate.  Compile time addresses. 1-to-1
    -memoryRegion="ABCHitMap"               Hard to eliminate.  Compile time addresses. 1-to-1
    -memoryRegion="testResults"             Hard to eliminate.  Compile time addresses. 1-to-1
    -memoryRegion="CGAVideoMemory"          perhaps add videobuf to BSP.
    -memoryRegion="bootRAM"

    -DEOS_RAMStart                          bloblet (proposed)
    -DEOS_numRAMPages                       bloblet (proposed)
    -DEOS_FLASHStart                        bloblet (proposed)
    -DEOS_numFLASHPages                     bloblet (proposed)

    -memBlockNumPages=16                    Should not be part of BSP
    -memGapNumPages=16			    This can't be right.
    -memOffsetNumPages=0

    -kernelFile
      Alternate either:
        - .cd.xml processor
        - switch content to test-infrastructure
        - Is there a user/use case from Honeywell?
      Used by:
        kernel tests
        some component tests (e.g., elfchk)
        ???

    -bootDest
      Seems like bootDest should defalt to dir:. for all BSPs.
      Or perhaps default should come from extension.
      Maybe just delete it?  Not sure who would use it.

config.pci.xml
    Seems to have device specific info, e.g., network controller
    Is this device, or RAM, or both?
    Might have a bloblet interaction in the future.

em1.fp.xml

openarbor.bangvar.options
    cffs
    lwip
    pci-scanner-resources

platreg.pi.xml
  resources
    DEOS_RAM
    DEOS_FLASH
    duart*
    dma*
    di2c
    NetworkBuffers
    bla bla bla
  rates
  schedulers
  windows
  UGO info
  files

GeekFest 2023 Discusion

Phys alloc - BSP Team Discussion - 4/17/2023

At this point, the config component performs all the integration. If one change in the configuration is required, it's needed to modify the contants.py file and recompile the BSP to rellocate new sections and move the previous sections (if needed).

  1. Proposal 1:

See Wiki for proposal description. The main problem with it is that Deos Flash or Deos RAM are described in the hypstart image. If you change them, you need to reflash a new hypstart image.

These two memory regions can be allocated from low Memory to high memory, while the unallocated RAM can be allocated from high to low.

What about the tick rate variable? Some BSPs set it to a different rate. Can we pass this to the customer? We need to consider removing the .pia files from the CVT.

What about updating the current BSPs to implement these .pia files? We could make the IT tool to ignore all the .pia files if there is a file with the previous format.

When is this new feature going to be implemented? This needs to be discussed with Kelly and Richard.

Cache partitioning: The alignment of Deos RAM is important to define the partitions.

BSP Dev-Kit

  1. Mode changing: Which things should be initialized in mode changes.
  2. 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.
  3. 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.
  4. 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.
  5. TDL Support: This is linked with supporting the flash of DeosBoot.bin in NVM.

Questions

  1. BootRAM and DeosFlash location:
    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?
  2. Cache Partitioning - Code & Data
    1. Two options:
      1. How it works today (e.g., aliasing)
      2. Specify smallest stripe
      3. Note: might need pool definition capability
  3. LFS vs. MFS vs. Hyperstart
    1. Needs smallest stripe syntax
    2. Hyperstart & LFS terms
    3. MFS what's it stand for?
  4. Tick rate variable?
    1. Platform attributes, Kernel attributes, etc., would be PIA files that would be delivered by *something*.
  5. Can a user "lock-down" to s specific *.pi.xml file ("lock-down" means can add but not change what's there)?
    1. Short answer: no, apart from priority & direction.
    2. Follow-on - is priority the correct idiom?
Retrieved from "https://ddci.zapto.org/ddciWiki/index.php?title=PIA_Project&oldid=54329"