User:Gkindorf@ddci.com

From DDCIDeos
Jump to navigationJump to search

Component Expertise:

  • Kernel Test
  • Deos 653 config & CVT
  • IOIAPI and Ring Buffer libraries, IOI config & CVT tools,
  • Integration-tool & registry-cvt
  • IST config



General Information

Out of Office

  • PTO 2025
    • week ending Jan 26: 24h (death in family)
    • week ending May 4: 1h
    • week ending May 19: 7h (kelly knee replacement)
    • week ending May 26: 5h (kelly knee replacement)
    • week ending July 20: 2h (Take parents to visit assisted living options)
    • week ending July 27: 12h (celebration of life, family)
    • week ending Sep 7: 16h (help parent pack/sell house)
    • week ending Sep 21: 4h (help parents pack)
    • week ending Sep 28: 19h (moving day parents, estate sale)
    • week ending Oct 5: 16h (closing on parents house. done.)

Weekly Status

Weekly Status

27 Oct - 2 Nov 2025

Accomplishments:

  • Tooling :
    • None
  • Misc:
    • Andre provided coverity results for IOIAPI on kismet: [see here] or [here]
  • Customer Support
    • Assist CPow with a customers 653 feature provider that was attempting to rig vfile-aio.

Goals for coming weeks:

  1. IOI Bare Metal test case/procedure review
  2. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  3. pia feature to add offset to a startAddress(): PCR:16590
  4. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  5. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  6. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).
  7. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  8. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

20 Oct - 26 Oct 2025

Accomplishments:

  • Tooling :
    • Registry-cvt: [1]
  • Misc:
    • Dentist on Thursday
    • Dr on Friday
  • Customer Support


Goals for coming weeks:

  1. IOI Bare Metal test case/procedure review
  2. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  3. pia feature to add offset to a startAddress(): PCR:16590
  4. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  5. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  6. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).
  7. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  8. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

13 Oct - 19 Oct 2025

Accomplishments:

  • Tooling :
    • Registry-cvt: Implementing PCR:16236. After that, prep for and perform RFS.
    • [2]
  • Misc:
    • CI tag stuff on tuesday.
    • Dr. appointment wednesday afternoon
    • Training on thursday
  • Customer Support
    • Assist with supplemental doc material for Liebherr

Goals for coming weeks:

  1. IOI Bare Metal test case/procedure review
  2. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  3. pia feature to add offset to a startAddress(): PCR:16590
  4. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  5. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  6. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).
  7. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  8. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

06 Oct - 12 Oct 2025

Accomplishments:

  • Tooling :
    • Registry-cvt: Implementing PCR:16236. After that, prep for and perform RFS
  • Misc:
    • None.
  • Customer Support
    • None

Goals for coming weeks:

  1. Finish PCRs against registry-cvt on Europa. Need an RFS this or next week.
  2. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  3. pia feature to add offset to a startAddress(): PCR:16590
  4. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  5. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  6. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).
  7. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  8. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

29 Sep - 5 Oct 2025

Accomplishments:

  • Tooling :
    • Minor updates to the IT regression test suite to support multiple schemas.
  • Misc:
    • Support for family in transition to assisted living; will be done this week.
  • Customer Support
    • Some planning on CVT responses to Liebherr

Goals for coming weeks:

  1. Finish PCRs against registry-cvt on Europa. Need an RFS this or next week.
  2. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  3. pia feature to add offset to a startAddress(): PCR:16590
  4. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  5. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  6. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).
  7. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  8. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

22 Sep - 28 Sep 2025

Accomplishments:

  • Tooling :
    • integration-tool:
      • Stable on 3.66.0
      • Working on versioned XSD
    • deos653config:
      • unreleased 1.31.0
  • Misc:
    • Support for family in transition to assisted living; almost done. Couple pieces of furniture remain, house cleaning to do, some yard cleanup, and closing remain at the 2nd half of next week.
  • Customer Support
    • none

Goals for coming weeks:

  1. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  2. pia feature to add offset to a startAddress(): PCR:16590
  3. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  4. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  5. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).


  1. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  2. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  3. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  4. Get P2 partition capabilities re-integrated into kismet deos653config
  5. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  6. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

15 Sep - 21 Sep 2025

Accomplishments:

  • Tooling :
    • integration-tool:
      • Working on misc bug fixes in schema 51 reported internally
      • Working on versioned XSD
    • deos653config:
      • PCR:16608 Update xsi schemaLocation expressions in 653 XML, suppressing warnings in OA
    • registry-cvt: misc PCRs in progress. Prepping for an RFS for jupiter/europa
  • Misc:
    • Support for family in transition to assisted living. There will be demands here that I will need to service with priority thru September.
  • Customer Support
    • fourpeaks customer: registry-cvt reporting an error of DRC_REQ_PT1.1 in DDS-tostones-deos-fourpeaks-20180306. This appears to be an IT bug in 3.10.0 forward on the single core IT (mainline), but is resolved in the multi-core branch. See PCR:10485 and PCR:16746. Customer was directed to use 'systemReserved' instead of 'kernelMode' in their .pi.xml for their kmi interrupt.

Goals for coming weeks:

  1. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  2. pia feature to add offset to a startAddress(): PCR:16590
  3. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  4. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  5. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).


  1. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  2. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  3. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  4. Get P2 partition capabilities re-integrated into kismet deos653config
  5. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  6. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

9 Sep - 14 Sep 2025

Accomplishments:

  • Tooling :
    • integration-tool:
      • PCR:16613: Added support for <kernelModeLibrary>
      • PCR:16679: Added support for single core license to use standard apps on cores other than 0.
      • The other branch: working on versioned XSD
    • deos653config:
    • registry-cvt: misc PCRs in progress. Prepping for an RFS for jupiter/europa
  • Misc:
    • Family (A) reunion interrupted by altitude sickness
    • Support for family (B) in transition to assisted living. There will be demands here that I will need to service with priority thru September.
  • Customer Support

Goals for coming weeks:

  1. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  2. pia feature to add offset to a startAddress(): PCR:16590
  3. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  4. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  5. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).


  1. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  2. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  3. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  4. Get P2 partition capabilities re-integrated into kismet deos653config
  5. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  6. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

1 Sep - 7 Sep 2025

Accomplishments:

  • IOI Bare Metal and IOI Bare Metal Kismet:
    • Unreleased versions 1.0.1 and 2.0.1: Posted 1.0.1 to liebherr so they could try using our .a libs. They understand that the linking aspect our our verf'ed .a files requires them to have a qualified linker. Also found and fixed a problem with embedded filesystem data in the resulting .a file and .o files that was causing the CRC to be different between build of the same source.
  • Tooling :
    • integration-tool:
      • working other misc backlog of IT PCRs while this tool is in context
      • The other branch: working on versioned XSD
    • deos653config:
    • registry-cvt: misc PCRs in progress. Prepping for an RFS for jupiter/europa
  • Misc:
  • Customer Support

Goals for coming weeks:

  1. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  2. pia feature to add offset to a startAddress(): PCR:16590
  3. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  4. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  5. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).


  1. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  2. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  3. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  4. Get P2 partition capabilities re-integrated into kismet deos653config
  5. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  6. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

25 Aug - 31 Aug 2025

Accomplishments:

  • IOI Bare Metal and IOI Bare Metal Kismet:
    • Unreleased versions 1.0.1 and 2.0.1: Posted 1.0.1 to liebherr so they could try using our .a libs. They understand that the linking aspect our our verf'ed .a files requires them to have a qualified linker. Also found and fixed a problem with embedded filesystem data in the resulting .a file and .o files that was causing the CRC to be different between build of the same source.
  • Tooling :
    • integration-tool:
      • unreleased IT 3.66.0 with ryans kernel stack feature.
      • working other misc backlog of IT PCRs while this tool is in context
      • The other branch: working on versioned XSD
    • deos653config:
    • registry-cvt: misc PCRs in progress. Prepping for an RFS for jupiter/europa
  • Misc:
  • Customer Support

Goals for coming weeks:

  1. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  2. pia feature to add offset to a startAddress(): PCR:16590
  3. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  4. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  5. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).


  1. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  2. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  3. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  4. Get P2 partition capabilities re-integrated into kismet deos653config
  5. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  6. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

18 Aug - 24 Aug 2025

Accomplishments:

  • IOI Bare Metal and IOI Bare Metal Kismet:
    • Unreleased versions 1.0.1 and 2.0.1: Posted 1.0.1 to liebherr so they could try using our .a libs. They understand that the linking aspect our our verf'ed .a files requires them to have a qualified linker. Also found and fixed a problem with embedded filesystem data in the resulting .a file and .o files that was causing the CRC to be different between build of the same source.
  • Tooling :
    • integration-tool:
      • I have two local branches in development; one for working the set of backlogged PCRs, and one for Ryan on new kismet kernel features. The latter is almost done and I hope to get that resolved on monday
      • The other branch: working on versioned XSD
    • deos653config:
      • PCR:16699 Files in svn. I think I'm done. Chuck needs to confirm.
    • registry-cvt: misc PCRs in progress. Prepping for an RFS for jupiter/europa
  • Misc:
  • Customer Support
    • Attended meetings on dw-sockets. For their 'config items', Rons update to the config file demo seems like it would be a nice fix (opposed to an xml parsing tool)

Goals for coming weeks:

  1. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  2. pia feature to add offset to a startAddress(): PCR:16590
  3. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  4. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  5. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).


  1. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  2. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  3. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  4. Get P2 partition capabilities re-integrated into kismet deos653config
  5. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  6. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

11 Aug - 17 Aug 2025

Accomplishments:

  • Tooling :
    • integration-tool:
      • working on versioned XSD
      • ryan need support for a new kismet feature
    • deos653config:
      • chuck needs the partition management feature
    • registry-cvt: misc PCRs in progress. Prepping for an RFS for jupiter/europa
  • Misc:
  • Customer Support

Goals for coming weeks:

  1. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  2. pia feature to add offset to a startAddress(): PCR:16590
  3. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  4. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  5. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).


  1. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  2. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  3. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  4. Get P2 partition capabilities re-integrated into kismet deos653config
  5. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  6. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

04 Aug - 10 Aug 2025

Accomplishments:

  • Tooling :
    • integration-tool:
      • working on versioned XSD
      • ryan need support for a new kismet feature
    • deos653config:
      • chuck needs the partition management feature
    • registry-cvt: misc PCRs in progress. Prepping for an RFS for jupiter/europa
  • Misc:
    • None
  • Customer Support
    • Support ioi/r5/test infrastructure on kinghall
    • Support bsp-common/pia for zhangmen


Goals for coming weeks:

  1. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  2. pia feature to add offset to a startAddress(): PCR:16590
  3. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  4. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  5. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).


  1. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  2. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  3. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  4. Get P2 partition capabilities re-integrated into kismet deos653config
  5. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  6. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

28 Jul - 03 Aug 2025

Accomplishments:

  • Tooling :
    • integration-tool:
      • working on versioned XSD
      • ryan need support for a new kismet feature
    • deos653config:
      • chuck needs the partition management feature
    • cdproc
      • None
    • registry-cvt: Liebherr reported a problem related to the use of 'all-of-them' as a schedule-before token. That problem is 'fixed' locally, but there were other test problems related to this condition. Still in progress.
  • Misc:
    • None
  • Customer Support
    • Support for Cronk in Poland


Goals for coming weeks:

  1. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  2. pia feature to add offset to a startAddress(): PCR:16590
  3. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  4. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  5. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).


  1. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  2. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  3. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  4. Get P2 partition capabilities re-integrated into kismet deos653config
  5. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  6. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

21 Jul - 27 Jul 2025

Accomplishments:

  • Tooling :
    • Working on versioned XSD for the IT.
    • cdproc plugin work with Lisa, Aaron
    • registry-cvt: Liebherr reported a problem:
    • deos653config: Chuck starting in on cross partition management. We have a rough design from last week. Need some tooling updates.
  • Misc:
    • None
  • Customer Support
    • None


Goals for coming weeks:

  1. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  2. pia feature to add offset to a startAddress(): PCR:16590
  3. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  4. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  5. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).


  1. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  2. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  3. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  4. Get P2 partition capabilities re-integrated into kismet deos653config
  5. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  6. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

14 Jul - 20 Jul 2025

Accomplishments:

  • Tooling :
    • Working on versioned XSD for the IT.
    • kfs-cvt port to 64-bit with Andre.
    • cdproc plugin work with Chris, Lisa, Aaron
    • pci-config unreleased: PCR:16638 The XSD string in the python source was not declared as raw, and was raising an error in docker kismet.
    • ioi-config unreleased: PCR:16639 IOI config tool UG contained bad reference to IOI API UG.
    • deos-integration-tool 3.65.5 stable for the jupiter/gdb/honeywell workarounds
  • Misc:
  • Customer Support
    • LPB: SPS reported status on Wednesday that the IT may not be setting system quota capability. This turned out to be false.
    • Liebherr reported a problem with regsitry-cvt. Needs investigation.


Goals for coming weeks:

  1. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  2. pia feature to add offset to a startAddress(): PCR:16590
  3. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  4. Flesh out cdproc makefiles for 653, ioi, it
  5. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  6. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).


  1. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  2. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  3. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  4. Get P2 partition capabilities re-integrated into kismet deos653config
  5. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  6. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

07 Jul - 13 Jul 2025

Accomplishments:

  • Tooling :
    • Working on versioned XSD for the IT.
    • kfs-cvt port to 64-bit with Andre.
    • cdproc plugin work with Chris, Lisa, Aaron
  • Misc:
  • Customer Support
    • LPB: No update on status from last week. Still waiting to hear if what IT/gdbserver updates work for Thunderbolt.

Goals for coming weeks:

  1. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  2. pia feature to add offset to a startAddress(): PCR:16590
  3. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  4. Flesh out cdproc makefiles for 653, ioi, it
  5. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  6. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).


  1. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  2. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  3. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  4. Get P2 partition capabilities re-integrated into kismet deos653config
  5. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  6. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

30 Jun - 06 Jul 2025

Accomplishments:

  • Tooling :
    • ioi-config-4.0.3 stable: For the sales tsunami 2025b, ioi-config 4.0.2 failed in cygwin. That python version is too old for the source code. PCR:16621
    • deos-integration-tool-3.65.5 unreleased: PCR:16620 Change semantics of threadtemplate period 'schedulerSlowest' for a mainThreadTemplate. This is to reduce the cpu footprint in trying to get gdbserver to operate in Honeywells flight software.
    • Working on versioned XSD for the IT.
    • kfs-cvt port to 64-bit with Andre
  • Misc:
  • Customer Support
    • LPB: Ryan updated gdbserver to create a 2nd process containing the fpu threads. That 2nd process is not expressed in gdbserver pd xml as a child, which excludes its quotas from being considered by the IT. Honeywell was given an IT update and a gdbserver update at the end of the week. Waiting to hear if that works for the thunderbolt platform where most configurations use gdb as an lwip thread, but lpb still uses the inetd approach.

Goals for coming weeks:

  1. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  2. pia feature to add offset to a startAddress(): PCR:16590
  3. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  4. Flesh out cdproc makefiles for 653, ioi, it
  5. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  6. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).


  1. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  2. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  3. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  4. Get P2 partition capabilities re-integrated into kismet deos653config
  5. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  6. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

23 Jun - 29 Jun 2025

Accomplishments:

  • Tooling :
    • Working on versioned XSD for the IT.
    • Working on gdb-server configuration in the IT.
      • The IT can reduce the scheduler oversubscription error to a warning, and that will enable the DSH processes to be created. But it does not clearly identify which processes are intended to behave this way, and as a result, will all the 'right' apps start when the scheduler is oversubscribed? Should the IT know that GDB is a DSH process implicitly? Soliciting opinion from RR/AL. Will finish next week.
  • Misc:
    • Working with Andre on kfs-cvt
    • Support CP on a customer support case involving cio from 653
  • Customer Support
    • Vivios: Shawn. Reported success on the ioi support case from last week
    • Elemento: Supporting Ron on getting the kernel RFS running with a fixed-address PAL. Their PAL was linked relocatable.
    • LPB: Honeywell is able to create a debug session via lwip app. If that session is closed and then another session started without a coldstart, gdbserver reports "failed to create ready_fpu_event". In the context of lwip, the created objects from the first session persist. RLF reports that no only do they need this, they need debug groups to work. The effort going forward will be to get the inetd configuration to work. That has the following challenges:
      • cpu budget of inetd may not be available in their schedule
      • cpu budget of gdb fpu threads may not be available.
      • TODO: Ask SPS if they ever rigged gdbserver main thread as 'fastest' so that the fpu threads are not faster than the main thread.
      • TODO: RLF suggested a kernel mod to permit createThread to NOT check cpu quota when DSH is enabled.
      • TODO: RLF suggested an IT and kernel mod to permit new attributes on a thread template to be exempt from CPU quota when DSH.
      • TODO: RR says IT only solution.
        • Main thread template (in gdb) needs symbolic period to mean same rate as next fastest thread in process
        • relax scheduler oversubscription error to warning. keep fpu thread instance count==1. registry will get cpu budget to enable createThread() success

Goals for coming weeks:

  1. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  2. pia feature to add offset to a startAddress(): PCR:16590
  3. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  4. Flesh out cdproc makefiles for 653, ioi, it
  5. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  6. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).


  1. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  2. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  3. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  4. Get P2 partition capabilities re-integrated into kismet deos653config
  5. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  6. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

16 Jun - 22 Jun 2025

Accomplishments:

  • June tsunami
    • ccb/stable on :
      • ioiapi-5.0.1
      • ioi-ringbuffer-5.0.2
      • ioiconfig-4.0.2
      • integ-tool-3.65.4
  • Tooling :
    • Working on versioned XSD for the IT.
  • Misc:
    • Working with Andre on kfs-cvt
    • Support CP on a customer support case involving cio from 653
  • Customer Support
    • Honeywell LPB. Met with their team on Wed am. They are seeing createThread()==8 errors from lwip running gdbserver as a thread. Noted their hypstart default registry has a -registryKFSPhysicalAddress=0x3DA00000. My best guess is that the desired registry is going into the LFS, not into that KFS. That turned out to be true.
    • Vivios: Shawn. Replied to an IOI configuration question. No response back as of yet.

Goals for coming weeks:

  1. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  2. pia feature to add offset to a startAddress(): PCR:16590
  3. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  4. Flesh out cdproc makefiles for 653, ioi, it
  5. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  6. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).


  1. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  2. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  3. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  4. Get P2 partition capabilities re-integrated into kismet deos653config
  5. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  6. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

9 Jun - 15 Jun 2025

Accomplishments:

  • June tsunami
    • deos-integration-tool-3.65.4: Started on pia documentation updates, but had to punt. 3.65.4 still has the updated CVT metadata to support registry-cvt 3.1.1 when a process template references memory pools symbolically.
    • Worked with Andre on porting kfs-cvt to kismet
    • test reports:
      • ioiapi
      • ring buffer
      • ioiconfig
      • integ-tool
  • Tooling :
    • Some planning on cdproc 653/ioi/it makefiles with aaron
  • Misc:
    • New hire training
  • Customer Support
    • SPS reported that he wants gdbserver configured as an lwip thread. Our FPU solution does not work with that configuration. Sent a .fp.xml file that adds the fpu thread template to lwip. It is hoped that we do not have to productize this.

Goals for coming weeks:

  1. pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
  2. Versioned XSD for IT, IOI, deos653, IST (see https://deos.ddci.com/ddciWiki/XML_versioned_schema_Project)
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  3. Flesh out cdproc makefiles for 653, ioi, it
  4. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  5. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).


  1. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  2. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  3. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  4. Get P2 partition capabilities re-integrated into kismet deos653config
  5. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  6. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

2 Jun - 8 Jun 2025

Accomplishments:

  • Tooling :
    • deos-integration-tool-3.65.3 stable
    • deos-integration-tool-3.65.4: pia documentation update in progress
    • Some planning on cdproc 653/ioi/it makefiles with aaron
  • Misc:
    • registry-cvt-3.1.1 reporting failures for SPS. Investigating. PCR:16563 was written against the IT and resovled in version 3.65.4
  • Customer Support
    • None

Goals for coming weeks:

  1. June tsunami needs pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  2. Flesh out cdproc makefiles for 653, ioi, it
  3. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml. If this is done, also update the IT dependency version to 3.65.4 per PCR:16563
  4. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).


  1. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  2. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  3. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  4. Get P2 partition capabilities re-integrated into kismet deos653config
  5. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  6. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

27 May - 1 Jun 2025

Accomplishments:

  • IOI Bare Metal and IOI Bare Metal Kismet:
    • Found a bug while configuring A-R core IOI usage. The user passes to ioi_init() a list of resource/physical address pairs that had to be sorted by resource hashed name. That is not documented or correct. Changed component logic to use a linear search instead of a binary search on the user provided lists.
  • June tsunami
    • IOIAPI: Unreleased 5.0.1
    • ringbuffer: Unreleased 5.0.2
    • ioiconfig: Unreleased 4.0.2
  • Tooling :
    • deos-integration-tool-3.65.3 stable
  • Misc:
    • Responded to a set of CVT related question from an auditor on Liebherr (due June 1)
  • Customer Support
    • None

Goals for coming weeks:

  1. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml
  2. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).
  1. June tsunami needs pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  2. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  3. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  4. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  5. Get P2 partition capabilities re-integrated into kismet deos653config
  6. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  7. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

19 May - 25 May 2025

Accomplishments:

  • IOI Bare Metal Kismet
    • Modified the test infrastructure to support multiple IOI queues within the CFFS_RAM_RW resource
  • Tooling :
  • Misc:
  • Customer Support

Goals for coming weeks:

  1. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml
  2. Get IOI Bare metal configured to operated between A and R cores with Mark.
  3. Liebherr CVT response to email from Kelly on 5/14 due June 1
  4. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).
  1. June tsunami needs pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  2. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  3. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  4. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  5. Get P2 partition capabilities re-integrated into kismet deos653config
  6. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  7. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

12 May - 18 May 2025

Accomplishments:

  • IOI Bare Metal Kismet
    • Unreleased and Uploaded 2.0.1: PCR:16504 Modified the IOI Bare Metal to build to interface to either IOIAPI 4.x.x or IOIAPI 5.x.x. Unreleased 1.0.1 (4.x.x) and 2.0.1 (5.x.x), and posted unreleased 2.0.1 to the vivios customer support site
  • Tooling :
    • PCR:16505: Add the ability for a thread template to specify "*" as its schedulerName. This causes the thread template to be replicated for each used scheduler in the registry, and quotas updated accordingly. This is for gdbserver on jupiter. Kernel maintainers indicate this wont be necessary on kismet.
  • Misc:
    • ooo Thursday for kellys knee replacement
  • Customer Support

Goals for coming weeks:

  1. May need to update registry-cvt 3.1.1 TAS to indicate behaviors on PCR:16505 will reflect in the regenerated gdbserver.pd.xml
  2. Get IOI Bare metal configured to operated between A and R cores with Mark.
  3. Liebherr CVT response to email from Kelly on 5/14 due June 1
  4. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).
  1. June tsunami needs pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  2. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  3. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  4. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  5. Get P2 partition capabilities re-integrated into kismet deos653config
  6. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  7. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

5 May - 11 May 2025

Accomplishments:

  • IOI Bare Metal Kismet
    • Continued analysis for interfacing to 64-bit style config files. Looks like a very small data structure delta on a message queue header
  • IOIAPI Kismet (5.0.1 unreleased)
    • Ported misc changes from R5 code review back into ioiapi mainline kismet.
  • RingBuffer Kismet (5.0.2 unreleased)
    • Ported misc changes from R5 code review back into ring buffer mainline kismet.
  • Tooling :
    • Update IT regression test suite to operate in kismet.
  • Misc:
    • Onboarding Mark, Kevin, Roger
  • Customer Support
    • Attended a DTS with Matthew for a customer wanting to have/manage configuration data.


Goals for coming weeks:

  1. Honeywell/gdbserver/floating point: May require the IT to add one thread template per configured scheduler to the gdb server process template. This will cause registry-cvt to generate an XML miscompare. Need to update TAS on jupiter/europa, and 'fix' somehow on kismet.
  2. Continue with getting bare metal ioi working with both IOIAPI/Ring 4.x.x (europa) and 5.x.x (kismet)
  3. Team Meeting: what to do about .fp.xml files with Ron/Mark
    1. Issue is correctness and the means to ensure correctness prior to shipping
    2. For tools that generate .fp.xml (most xml tools), ...
      1. review tool output, integration tests
    3. For .fp.xml files delivered with components (build-util generated for example)
      1. the content is usually about RAM quota, and that is a guess. How many chapters will the image loading cross? objdump gets the data/bss sections sizes in build utils, but the end result is not fixed point.
    4. Role of CVTs:
      1. registry-cvt has an option to 'print' in csv data that is of interest to other CVTs.
        1. deos653-cvt: some examples
          1. D653_INT2: 653 synchronous interrupts manifest properly for the 653 scheduler in the deos registry
          2. D653CVT_WIN1_DERIVED.1: 653 windows end up as RMA windows with the correct scheduler/duration/wat.
          3. D653CVT_REGISTRY2_DERIVED: every partition is an auto-created Deos process.
          4. We chose to not validate the output .pd.xml and .fp.xml because the content varies with 653 xml content. Instead, we check the registry to ensure the parts of the configuration that manifest there are correct. We dont care how it got there (xml content, human edits somewhere else).

Not clear to me what the issue is. A CVT will check the registry for required values (or should if they dont).

  1. IOI Bare Metal Europa: Mark needs an assist in getting IOI configured between the A and R cores.
  2. June tsunami needs pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  3. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  4. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  5. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  6. Get P2 partition capabilities re-integrated into kismet deos653config
  7. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  8. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

28 Apr - 4 May 2025

Accomplishments:

  • IOI Bare Metal:
    • Assist with rigging IOI across A and R cores. Needed to reserve additional blocks of DDR for IOI queues.
  • IOI Bare Metal Kismet
    • This is a new project and 4th branch of the IOI API. The 'kismet' IOI uses a different alignment in the queues and in the internal data structures. Started an analysis to determine what changes are necessary to IOI Bare Metal for IOI Bare Metal Kismet. I dont have a term for 'uses the data structures required for 64-bit', so I dont know what to call this yet.
  • IOIAPI Kismet (5.0.1 unreleased)
    • PCR:16479 On kismet, fix IOIAPI .fp.xml files to adjust RAM of using process templates
  • Tooling :
    • ioi-config (4.0.2 unreleased):
      • PCR:16481 ioi-config generated .fp.xml files to adjust RAM of using process templates.
      • PCR:15274 ioi-config .cck now include heap size required, which is useful to R5 integrators.
  • Misc:
    • PCR:16437 Multicore memory pool example does not work, OA cannot launch debugger on it


  • Customer Support

Goals for coming weeks:

  1. IOI Bare Metal Kismet: This is a new and 4th branch of the IOI to be created. The 'kismet' IOI uses a different alignment in the queues and in the internal data structures.
  2. IOI Bare Metal Europa: Mark needs an assist in getting IOI configured between the A and R cores.
  3. June tsunami needs pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project).
    • Get the IT .pia default files included so that default pi content is no longer implicit (as opposed to documenting the implicit behavior). This requires pia tooling support for a cores() iterator function.
  4. Ryan needs an IT mod for the kernel for the June tsunami PCR:16425
  5. pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  6. Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  7. Get P2 partition capabilities re-integrated into kismet deos653config
  8. 653 config unreleased Kismet, including new .py interface to P2 features for Kismet? I think there are local changes from a different PCR in either my farmed win11vm or local win11vm.
  9. Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

21 Apr - 27 Apr 2025

Accomplishments:

  • IOI Bare Metal:
    • Requirement and code modification from the test team, including PCR:16363. See prev weeks Goals for details.
  • Tooling:
    • Started in on a proposal to make the pi tool defaulted elements (periods, schedulers, windows, users, groups, etc.) individual files in the /desk/etc folder, and have the IT contribute a .cd.xml file that lists these defaulted .pia.xml files. There is a need for a cores() function that acts like an iterator, so that num-cores default schedulers can be expressed.
  • Misc:
    • PIA and striped resources: Started investigating this task to determine if anything needs to be done. AL: thinks not.
    • OA DDCI_PCR:5411: The newly added MFS dialog should include ability to strip the MFS resource.
    • Dentist and car repairs.
  • Customer Support

Goals for coming weeks:

  • June tsunami needs pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project)
  • Ryan needs an IT mod for the kernel PCR:16425
  • pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  • Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  • Get P2 partition capabilities re-integrated into kismet deos653config
  • 653 config unreleased Kismet, including new .py interface to P2 features for Kismet?
  • Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

14 Apr - 20 Apr 2025

Accomplishments:

  • IOI Bare Metal:
    • Started in on making requirement changes per test development feedback.
  • Misc:
    • activity related to the tsunami/cdproc/oa


  • Customer Support

Goals for coming weeks:

  • June tsunami needs pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project)
  • ioi bare metal: Mark identified the need to add requirements for getMessageSequenceNumber behaviors when the fd is for writing.
  • ioi bare metal: Mark identified the need to add requirements for ioi_flushQueue when a write fd is passed: PCR:16363.
  • ioi bare metal: DDD_IOI_API_GETSEQ_30b: The state associated with 0x80000000 is not formally described, but it is the condition associated with this requirement. Search all of the DDD/UG for this, derive a formal term, and use that term to describe the state.
  • ioi bare metal: DDD_IOI_API_GETSEQ_30b: The description of the ioi_getMessageSequenceNumber() API nicely states that "When used with a write file descriptor, this function returns the message sequence number of the next message to write". But I don't see the requirement for it
  • pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  • Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  • Get P2 partition capabilities re-integrated into kismet deos653config
  • 653 config unreleased Kismet, including new .py interface to P2 features for Kismet?
  • Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

7 Apr - 13 Apr 2025

Accomplishments:

  • cdproc related activity


Goals for coming weeks:

  • June tsunami needs pia documentation (port content from https://deos.ddci.com/ddciWiki/PIA_Project)
  • ioi bare metal: Mark identified the need to add requirements for getMessageSequenceNumber behaviors when the fd is for writing.
  • ioi bare metal: Mark identified the need to add requirements for ioi_flushQueue when a write fd is passed: PCR:16363.
  • ioi bare metal: DDD_IOI_API_GETSEQ_30b: The state associated with 0x80000000 is not formally described, but it is the condition associated with this requirement. Search all of the DDD/UG for this, derive a formal term, and use that term to describe the state.
  • ioi bare metal: DDD_IOI_API_GETSEQ_30b: The description of the ioi_getMessageSequenceNumber() API nicely states that "When used with a write file descriptor, this function returns the message sequence number of the next message to write". But I don't see the requirement for it
  • get inetd and ftp-server stable for Deos_Sales_Kismet_25A
  • pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  • Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  • Get deos653cvt RFS completed pending 653 runtime verf effort.
  • Get P2 partition capabilities re-integrated into kismet deos653config
  • 653 config unreleased Kismet, including new .py interface to P2 features for Kismet?
  • Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

14 Mar - 30 Mar 2025

Accomplishments:

  • Tooling:
    • cdproc:
      • Mostly consult with Aaron on design. He has been implementing the details.
      • re-unreleased bsp-common, which now no longer contains <kernelFile> data for registries, as the new 'plugin' design in cdproc eliminated the need.
  • Misc:
  • Customer Support
    • BC pull me into a customer meeting; in greys, they need to run ftp/sm/tsvs in DL mode along with one of their apps. ftp is auto-created. inetd is not normally executed in DL mode, but they need the SM/tsvs for debugging their DL mode app. In the end, we were unable to make it work. Suspect not enough ram for inetd/sm/tsvs in DL mode. BC said he would experiment with that on his machine.


Goals for coming weeks:

  • ioi bare metal: Mark identified the need to add requirements for getMessageSequenceNumber behaviors when the fd is for writing.
  • ioi bare metal: Mark identified the need to add requirements for ioi_flushQueue when a write fd is passed: PCR:16363.
  • ioi bare metal: DDD_IOI_API_GETSEQ_30b: The state associated with 0x80000000 is not formally described, but it is the condition associated with this requirement. Search all of the DDD/UG for this, derive a formal term, and use that term to describe the state.
  • ioi bare metal: DDD_IOI_API_GETSEQ_30b: The description of the ioi_getMessageSequenceNumber() API nicely states that "When used with a write file descriptor, this function returns the message sequence number of the next message to write". But I don't see the requirement for it
  • get inetd and ftp-server stable for Deos_Sales_Kismet_25A
  • pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  • Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  • Get deos653cvt RFS completed pending 653 runtime verf effort.
  • Get P2 partition capabilities re-integrated into kismet deos653config
  • 653 config unreleased Kismet, including new .py interface to P2 features for Kismet?
  • Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

17 Mar - 23 Mar 2025

Accomplishments:

  • Tooling:
    • cdproc:
      • Add in enough of the OA makefile 'magic' to identify 653,ioi,ist,pci config files and get them on the load list
      • PCR:16353: written against 653 runtime to get the ioi-api .cd.xml file in explicit scope by adding a <depend> line in the 653 runtime cd.xml. The current implicit mechanism is that OA snoops ports in the 653 configuration, and if found, adds the dependency. RLF pointed out in the PCR that the status monitor may be impacted.
      • Unreleased bsp-common, which now declares the LFS (with contains all non-MFS files, and libkernel.so)
    • IT:
  • Misc:
  • Customer Support


Goals for coming weeks:

  • ioi bare metal: Mark identified the need to add requirements for getMessageSequenceNumber behaviors when the fd is for writing.
  • get inetd and ftp-server stable for Deos_Sales_Kismet_25A
  • pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  • Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  • Get deos653cvt RFS completed pending 653 runtime verf effort.
  • Get P2 partition capabilities re-integrated into kismet deos653config
  • 653 config unreleased Kismet, including new .py interface to P2 features for Kismet?
  • Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

10 Mar - 16 Mar 2025

Accomplishments:

  • Tooling:
    • cdproc:
      • json output for OA
      • Makefile is broken due to magic() adding content when the file in question is present (both found and not found)
    • IT:
      • Ron reported a search path problem. No only was the --searchPath provided value not honored, the pia and pi tools crash.
  • Misc:
  • Customer Support
    • Cronk in italy: registry-cvt version (?) reporting 2 errors. Migrating to the europa versions of the tools 'worked'.
    • stonecloud: a 1200 usec window at 200ms in a 200ms WAT yields a negative scheduler budget. Although the kernel, integration tool, and registry-cvt are correct, the time partitioning requirements may be overly conservative. The math is normalizing the window time to the system tick, when perhaps it should be normalizing to scheduler-fastest. Met with AL, RR on Fri to discuss


Goals for coming weeks:

  • ioi bare metal: Mark identified the need to add requirements for getMessageSequenceNumber behaviors when the fd is for writing.
  • get inetd and ftp-server stable for Deos_Sales_Kismet_25A
  • pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  • Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  • Get deos653cvt RFS completed pending 653 runtime verf effort.
  • Get P2 partition capabilities re-integrated into kismet deos653config
  • 653 config unreleased Kismet, including new .py interface to P2 features for Kismet?
  • Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

3 Mar - 9 Mar 2025

Accomplishments:

  • Tooling:
    • cdproc:
      • cdproc-makefile: The expansion of symbols in paths on last weeks unexpand() topic has been discarded. This was an OA usage problem, not a problem with cdproc
      • cdproc-query: The proposal from AL/LCJ was to add a new format (json) that could be applied to any object being queried (inlucding all). AL provided a patch to show how this would be added to cdproc. My task was to flesh it out with some json
  • Misc:
    • Will the europa 653 tools work in jupiter? Yes, but there is a small 653-bug; when the -i switch is paired with a binary IOI file, the tool crashes. It works fine when paired with an IOI text file, which can be generated by ioi-cvt. See PCR:16309. We can either start over on deos653-cvt verf, or document a usage restriction.
use 5.8.4 653 runtime in jupiter.  will the tools work?


             jupiter     europa
653 config   1.27.5  <-  1.29.3 (can generate all schemas)
653 cvt      3.0.0   <-  4.1.0  (new runtime is schema 20).
653 runtime  5.7.3   <-  5.8.4  
IT           3.65.2      3.65.2
registry cvt 3.1.1       3.1.1
ioi config   3.6.7       3.6.7
ioi cvt      1.8.1       1.8.1
ioiapi       4.2.0       4.2.0
kernel       10.8.0     10.8.0

1) Can 653 config 1.29.3 generate the right schema for runtime 5.8.4?
YES

2) deos653-cvt takes IOI and registry data as input.  That data can be in binary or
text form.  The binary form would be platreg.bin and ioi.cfg.  The text form
is optionally generated by ioi-cvt and registry-cvt

2a) Can deos653-cvt accept binary and text forms of registry data?
YES

2b) Can deos653-cvt accept binary and text forms of IOI data?
NO (only text form works)

This is a 653 cvt bug.  653 cvt verf is in-progress so we can choose to
fix this and start over, or document that the -i switch must be in 
text form.
https://deos.ddci.com/bugzilla/show_bug.cgi?id=16309
    • INetD: todo: ccb/test report/stable
    • ftp-server: todo: ccb/test report stable
  • Customer Support
    • none

Goals for coming weeks:

  • pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  • Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  • Get deos653cvt RFS completed pending 653 runtime verf effort.
  • Get P2 partition capabilities re-integrated into kismet deos653config
  • 653 config unreleased Kismet, including new .py interface to P2 features for Kismet?
  • Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

24 Feb - 2 Mar 2025

Accomplishments:

  • Tooling:
    • cdproc:
      • cdproc-makefile: Local mods to inject the use of --var values in generated mfs-config.mk. Works, but need to consult AL: about implementation details.
      • cdproc-query: Starting on generation of json file for mapping file->mfs(s), and mfs->file(s) as an extension of 'kfsFile' command
  • Misc:
    • INetD: PCR:14061 Enable INetD to execute in kismet (quotas), and fixed a bug related to having inetd-create-able processes active when inetd initializes. Unreleased on kismet. Although INetD does not work on Jupiter or Europa, this fix was only made on kismet.
    • ftp-server: PCR:16279, PCR:16298: Added new .app.cd.xml for use by standard-apps.cd.xml so that app configuration data is packaged with the app instead of being centralized in standard-apps.
  • Customer Support
    • Santan with BC: Their 653 partition creates inetd and gdb in 'initialization mode'. when gdb is created, the partition stops generating output and the network is non-responsive. On Wed, BC was able to reproduce the error on one of our santan boards; we'll need an emulator to make further progress.
    • Santan: Jamie trying to get crittime data via OA dialogs but cannot find the crittime buttons in the target manager view. Problem was having external project references in the workspace.

Goals for coming weeks:

  • pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  • Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  • Get deos653cvt RFS completed pending 653 runtime verf effort.
  • Get P2 partition capabilities re-integrated into kismet deos653config
  • 653 config unreleased Kismet, including new .py interface to P2 features for Kismet?
  • Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

17 Feb - 23 Feb 2025

Accomplishments:

  • IOI Bare Metal:
    • Mark reported (last week) that ioi_init(), when passed a correct list of formatting functions, yields a formattingFunctionNotFound error. There was an implicit precondition that the user provided parameter (formatting function list) to ioi_init() be sorted. That has been removed. Thanks Mark for finding that.
  • Tooling:
    • IT: Went stable on 3.65.2 for a DDS that had to go out this week
  • Misc:
    • Get some DVMS throughput demos ported to deos653 for boeing. The performance variance observed for RMA vs 653 was related to how performance was being calculated (budget was a factor, and 653 runs as pure slack). After correcting, performance was equivalent.
    • "inetd" PCR:16119: Although we did make the warning of interest about DEOS_FLASH go away with an ftpserver update (jupiter and mainline branches) when configuring INetD based deos apps, there was a pile of uncovered damage:
      • INetD is broken (before i touched it) on kismet, europa, and probably jupiter. kismet needs amo size, ram quota updated in addition to a source bug fix. jupiter/europa can ping, but cannot connect to ftp in DL mode.
      • lwIP diagnostic version is broken, as the diagnostics are based on vfile, and vfile is not 'used' in lwip.pd.xml or a dependency in the .cd.xml.
      • ftpserver on jupiter/europa does work in DL mode with the ftp fixes in-progress. Still collecting inetd data.
  • Customer Support

Goals for coming weeks:

  • pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  • Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  • Get deos653cvt RFS completed pending 653 runtime verf effort.
  • Get P2 partition capabilities re-integrated into kismet deos653config
  • 653 config unreleased Kismet, including new .py interface to P2 features for Kismet?
  • Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

10 Feb - 16 Feb 2025

Accomplishments:

  • IOI Bare Metal:
    • Misc activity in the role of test mentor and author.
    • Fixed bug reported last week in fifo reading logic. Bug does not exist in regular IOI. Bug not shipped in IOI bare metal. Resolved.
    • Mark reported that ioi_init(), when passed a correct list of formatting functions, yields a formattingFunctionNotFound error. Needs investigation.
  • Misc:
    • CP reported the IT was not ignoring a missing feature set when configured to do so. Found the issue (not the IT).
    • "inetd" PCR:16119, which is really against the two active branches of ftpserver. Consensus among ftpserver maintainers is that ownership of DEOS_FLASH is only required in DL mode. There are already 2 variants of ftp-server.pd.xml (/desk/etc and /desk/etc/platregd). The solution is to remove the use of kfs init feature from the /desk/etc variant. Unreleased on both jupiter and mainline branches.
  • Customer Support
    • kinghall: Why cant the used memory mapped resource access rights be used instead of the memory mapped resource access rights.
    • lpb: Wrote PCR:16259 to capture need for user/group exposure in 653 for filesystem UGO.
    • verifyLicense execute permission in dds-gator-deos-kismet-20241216: Lisa, Matthew, Kevin and I pounded on this problem all week (cygwin installer has tar files with the correct permission on said file, but the installer yields -x. It seems to depend on the shell used to list the file. user/group issue? Worst case is we just have to hit it with a chmod +x in postinstaller. Is this the only borked file?
      • AL: Within 10 seconds, Aaron ID'd the .zip file format as the root cause, as the permission in .zip dont always translate into the cygwin filesystem based on properies (and version?) of cygwin1.dll. Lisa changed the file format to .xz and all seems fine.

Goals for coming weeks:

  • pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  • Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  • Get deos653cvt RFS completed pending 653 runtime verf effort.
  • Update ftp site to enable 3.65.x also be distributed to (at least) Europa. Could also go to jupiter. 3.65.x is compatible with the latest registry-cvt.
  • Get P2 partition capabilities re-integrated into kismet deos653config
  • 653 config unreleased Kismet, including new .py interface to P2 features for Kismet?
  • Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

3 Feb - 9 Feb 2025

Accomplishments:

  • IOI Bare Metal:
    • Misc activity in the role of test mentor and author.
    • Testing uncovered a bug related to computing deltas between message sequence numbers. Isolated that at the end of the week.
  • Tools:
    • deos653-cvt: Drafted the BE docs in PCR:16243. Waiting for verf complete on P1 runtime.
    • Integ tool 3.65.2: unreleased with tests. There were two problems; there was one more place in the logic where resource overlaps needed to considered ownership before raising a warning. And there was a problem with pia where the XSD type was integer (forcing integer inputs), but the code was considering the values as hex. This was in the area of stripes.
  • Misc:
    • Adina asked if the /desk/etc/deos-ram.pia.xml file could have the DEOS_RAM resource removed. DEOS_RAM has a function based definition of start address and length, and DEOS_RAM is referenced by a pool 0 range. The functions cannot simply be moved to the pool specification, as the functions only apply to resources. Note that IT 3.65.2 will suppress resource overlap warnings when one of the overlapping resources is not owned. That is the solution for now.
  • Customer support
    • Honeywell asked about the ability to assign user/group data in 653 so that partitions could use UGO.

Goals for coming weeks:

  • pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? Yes. RLF asked if a pia stripe example could be made to work.
  • Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  • Get deos653cvt RFS completed pending 653 runtime verf effort.
  • Update ftp site to enable 3.65.x also be distributed to (at least) Europa. Could also go to jupiter. 3.65.x is compatible with the latest registry-cvt.
  • Get P2 partition capabilities re-integrated into kismet deos653config
  • 653 config unreleased Kismet, including new .py interface to P2 features for Kismet?
  • Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

27 Jan - 2 Feb 2025

Accomplishments:

  • IOI Bare Metal:
    • Misc activity in the role of test mentor and author.
  • Tools:
    • integration-tool: Unreleased 3.65.2 (again). Added a check to report a striped resource overlap with a platform memory pool. Also ensure such shared pages have the same cache policy (writeBack). However, the registry-cvt for jupiter/europa does not report these warnings. There is no requirement to do so, but it seems like a good idea to report such overlap warnings. See PCR:16236. Consensus among peers is that 16236 does not need to be implemented for jupiter/europa for this pool/resource overlap, but the CVT also fails to consider striping in resources when reporting overlaps. I would expect to be asked to fix that.
    • registry-cvt: Drafted updates to the requirements per the above (PCR:16236).
  • Support
    • SPS reported a network hang in their chino/fourpeaks environment. They are using both our BSP and their BSP. In the latest delivery we made, Adina fixed an MSI bug (PCR:16110) that fixed the hang in our BSP. Provided some hints about what we did (aka gave them that PCR number), and they were able to resolve their problem.
    • SPS/Jeff asked if the IT warnings involving unowned resources could be turned on. I said 'no', but we could add an option to include that behavior if they really need it.

Goals for coming weeks:

  • Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  • Get deos653cvt RFS completed pending 653 runtime verf effort.
  • Adina asked in the deos-ram.pia.xml file default content could be modified to remove DEOS_RAM memory mapped resource.
  • pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? RLF says no.
  • Update ftp site to enable 3.65.x also be distributed to (at least) Europa. Could also go to jupiter. 3.65.x is compatible with the latest registry-cvt.
  • Get P2 partition capabilities re-integrated into kismet deos653config
  • 653 config unreleased Kismet, including new .py interface to P2 features for Kismet?
  • Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

20 Jan - 26 Jan 2025

Accomplishments:

  • Tools:
    • deos653-cvt: Did the RFS on Deos653-cvt-4.1.0 and made it stable. The requirement coverage analysis has a checklist item stating the pinned component (deos651p1 in this case) is verified. It's not verified. It actually cannot be verification complete until a change analysis is done comparing the draft TQD to the verified TQD. Plan to let the runtime get closer to verified, then finish up this CVT. All relevant CVT RFS data has been captured in the cert archive.
    • cdproc:
    • deos653config:
      • Misc lightweight PCRs
    • integration-tool:
      • Some churn in last weeks changes (in support of OA tests) to xml-tools-common common_fval. In short, there are a few functions to extract a handful of attributes from an XML file using find() logic. I attempted to replace that logic which was failing for an OA test with XML parsing. That was a mistake, as the XML files are not known to be in a parseable state. find() is back in use, and the OA tests are functioning.
      • SPS/Jeff Novacek reported false warning from the IT regarding striped memory pools and/or striped resources. Needs analysis
  • Support

Goals for coming weeks:

  • Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  • Get deos653cvt RFS completed pending 653 runtime verf effort.
  • Adina asked in the deos-ram.pia.xml file default content could be modified to remove DEOS_RAM memory mapped resource.
  • pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file? RLF says no.
  • Update ftp site to enable 3.65.x also be distributed to (at least) Europa. Could also go to jupiter. 3.65.x is compatible with the latest registry-cvt.
  • Get P2 partition capabilities re-integrated into kismet deos653config
  • 653 config unreleased Kismet, including new .py interface to P2 features for Kismet?
  • Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

13 Jan - 19 Jan 2025

Accomplishments:

  • Tools:
    • deos653-cvt: Did the RFS on Deos653-cvt-4.1.0 and made it stable. The requirement coverage analysis has a checklist item stating the pinned component (deos651p1 in this case) is verified. It's not verified. It actually cannot be verification complete until a change analysis is done comparing the draft TQD to the verified TQD. Plan to let the runtime get closer to verified, then finish up this CVT. All relevant CVT RFS data has been captured in the cert archive.
    • cdproc: Met with Lisa/Chuck/Kelly/Aaron on remaining work.
    • deos653config:
      • Added back partition capabilities for the kismet version of the runtime (in progress)
  • Support
    • Questions on new platform resource/memory pool overlaps in IT 3.65.0. Noted that IT 3.65.2 only raises that warning if the resource is owned.
    • Fractal (kismet): A set of .so images that they produced do not have import tables, but they do import from both our images and their images. On target, missing symbol errors result. Ryan think the error should not have occurred.

Goals for coming weeks:

  • Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  • Get deos653cvt RFS completed pending 653 runtime verf effort.
  • Adina asked in the deos-ram.pia.xml file default content could be modified to remove DEOS_RAM memory mapped resource.
  • pia is missing the ability to manage stripes. However, can hard coded stripes be in a .pia.xml file?
  • Update ftp site to enable 3.65.x also be distributed to (at least) Europa. Could also go to jupiter. 3.65.x is compatible with the latest registry-cvt.
  • Revert the changes to common_fval in mid January. The problem with using an XML parser to extract attributes is that the file may not be parse-able.
  • Get P2 partition capabilities re-integrated into kismet deos653config
  • 653 config unreleased Kismet, including new .py interface to P2 features for Kismet?
  • Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.

6 Jan - 12 Jan 2025

Accomplishments:

  • IOI Bare Metal:
    • Code reviews:
      • Processing feedback from Ron
    • Test Development:
      • Assist Mark in test procedure deveopment
  • Tools:
    • deos653-cvt: Did the RFS on Deos653-cvt-4.1.0 and made it stable. The requirement coverage analysis has a checklist item stating the pinned component (deos651p1 in this case) is verified. It's not verified. It actually cannot be verification complete until a change analysis is done comparing the draft TQD to the verified TQD. Plan to let the runtime get closer to verified, then finish up this CVT. All relevant CVT RFS data has been captured in the cert archive.
    • cdproc: Met with Lisa/Chuck/Kelly/Aaron on remaining work.
    • IT 3.65.2 unreleased
      • see Support below
      • PCR:16202 Updated xml-tools-common to replace string.find() logic with pythons build in xml parsing package. Lisa had an unformatted and old XML input file that could not be parsed, as the old logic expected the file to have been validated (formatted).
      • PCR:16201 Previous versions were leaving temporary files in /tmp.
    • deos653config:
      • Revisited the 653p1-3 spec on the topic of xsd's to ensure the tooling is compliant, in anticipation of breaking our one 653 file into multiple files.
      • Started the activity of added back partition capabilities for the kismet version of the runtime.
  • Support

Goals for coming weeks:

  • Get an estimate for breaking the 653 XML into smaller chunks, perhaps in pia-like form. Need to support 653 library development (adjust quotas without declaring a partition)
  • Get deos653cvt RFS completed pending 653 runtime verf effort.
  • Get P2 partition capabilities re-integrated into kismet deos653config
  • 653 config unreleased Kismet, including new .py interface to P2 features for Kismet?
  • IOI bare metal test procedure development.
  • Update ioi-config to not erase invalid bindings as a default behavior (customer support). The tool currently adds 'new' processes to the binder with all their consume items unbound, and any process not present in .ioi.xml files are removed from the binder file.
  • Striped resource pia behaviors. Can the offset be specified and the address be xrefed to an existing resource.


30 Dec - 5 Jan 2025

Accomplishments:

  • IOI Bare Metal:
    • Code reviews: no activity
    • Test Development:
      • Mark made some progress over the holiday break. Starting in on test case review.
  • Tools:
    • deos653-cvt: Did the RFS on Deos653-cvt-4.1.0 and made it stable. The requirement coverage analysis has a checklist item stating the pinned component (deos651p1 in this case) is verified. It's not verified. It actually cannot be verification complete until a change analysis is done comparing the draft TQD to the verified TQD. Plan to let the runtime get closer to verified, then finish up this CVT. All relevant CVT RFS data has been captured in the cert archive.
  • Support
    • registry-cvt at Honeywell: They are trying to get the new registry-cvt to operate in a DDCI Console (DOS). We expected that to be run in bash. SPS added back the .bat file wrappers but is finding one test procedure failure. That test is related to generating a command line error in the path to the registry file. The path is obtained by tempfile.gettempdir(). That function has different behaviors on windows and non-windows platforms. The proposed solution was to add 'set TEMP=/tmp' and 'set TMPDIR=/tmp' in the .bat file wrapper. That worked for me.

Goals for coming weeks:

  • Get deos653cvt RFS completed pending 653 runtime verf effort.
  • 653 config unreleased Kismet, including new .py interface to P2 features for Kismet?
  • IOI bare metal test procedure development.

16 Dec - 22 Dec 2024

Accomplishments:

  • IOI Bare Metal:
    • Code reviews:
      • Effectively done. I have accepted all of the proposed changes. Ron just needs to finish up the review summary report.
    • Test Development:
      • Had a short/intro training session with Ron and Mark. Went over how to load the R5 executive via uboot and run a test procedure. tpioi001 is the only functioning (sanity) test we have. It demonstrates basic produce/consume to self on the R5, and some error status code generation.
  • Tools:
    • deos653-cvt: Did the RFS on Deos653-cvt-4.1.0 and made it stable. The requirement coverage analysis has a checklist item stating the pinned component (deos651p1 in this case) is verified. It's not verified. It actually cannot be verification complete until a change analysis is done comparing the draft TQD to the verified TQD. Plan to let the runtime get closer to verified, then finish up this CVT. All relevant CVT RFS data has been captured in the cert archive.
    • IT: PCR:16181: Aaron requested that the memory pool/platform resource overlap warnings be suppressed when the platform resources are not owned.
  • Support
    • Worked with Matthew a bit on py2 pyc files causing a problem for woodward configured workstations. There are python interpreter options to inhibit pyc file generation, and that seems to work. Where I left off, Matthew was consider a deos_environment.py or possibly a windows environment variable change.

Goals for coming weeks:

  • Get deos653cvt/config unreleased for Europa, including new .py interface to P2 features for Kismet?
  • RFS on deos653 cvt when able.
  • IOI bare metal test procedure development.

9 Dec - 15 Dec 2024

Accomplishments:

  • IOI Bare Metal:
    • Code reviews in progress by Ron. I'm still constructing some test support functions, and expanding the set of sanity-check test cases in one test procedure.
  • Tools:
    • deos653-cvt: The effort to go stable is not significantly different from doing a formal build and RFS. I'll ask Jean on Monday to witness the formal build. RFSon deck? Deos653-cvt-4.1.0
    • deos-integration-tool 3.65.1 stable (kernel schema 50)
    • ist-config 1.4.2 stable (python3 warning)
    • deos653-config 1.29.3 stable (runtime schemas 20,21)
  • Support
    • kinghall lwIP configuration DTS

Goals for coming weeks:

  • Get deos653cvt/config unreleased for Europa, including new .py interface to P2 features for Kismet?
  • RFS on deos653 cvt.

2 Dec - 8 Dec 2024

Accomplishments:

  • IOI Bare Metal:
    • Requirement review completed: ioi-bare-metal-1.x.x
    • Code review next. Liebherr may want the R5/ioi bare metal to be 64-bit.
    • Was able to get the one test procedure running. Proceeding with getting code read-for-review
  • Support
    • None

Goals for coming weeks:

  • Work as many of these as possible: [Kismet Sunami]
  • Get deos653cvt/config unreleased for Europa, including new .py interface to P2 features for Kismet?
  • Get ioi bare metal ready for code review

25 Nov - 1 Dec 2024

Accomplishments:

  • IOI Bare Metal:
    • Requirement review (almost) completed: ioi-bare-metal-1.x.x
    • Code review next. Liebherr may want the R5/ioi bare metal to be 64-bit.
    • Began the process of remembering how to get bare metal ioi running on an r5; its been 6 months. ioi-bare-metal
  • Tools:
    • deos653-cvt: Unreleased on europa. Reviews complete. Will halt activity here until runtime code reviews are complete. Deos653-cvt-4.1.0
  • Support
    • None

Goals for coming weeks:

  • deos-integration-tool 3.65.1: Added support for kismet kernel schema 50. Unreleased. Needs some test work PCR:16128
  • Get deos653cvt/config unreleased for Europa, including new .py interface to P2 features for Kismet?
  • Test cpsw update from Chris. Try running the 1 sample test procedure using the release variant of lwip -- the debug variant has a fatal assert during DHCP logic. See PCR:14244

18 Nov - 24 Nov 2024

Accomplishments:

  • Support
    • PCR:16119 on Inetd to not grant rw access to DEOS_FLASH (via libkfs.fp.xml via inetd.cd.xml) when not in DL mode.

Goals for coming weeks:

  • Get deos653cvt/config unreleased for Europa, including new .py interface to P2 features for Kismet?
  • Test cpsw update from Chris. Try running the 1 sample test procedure using the release variant of lwip -- the debug variant has a fatal assert during DHCP logic. See PCR:14244

11 Nov - 17 Nov 2024

Accomplishments:

  • IOI Bare Metal:
    • Ron provided requirement review feedback. Need to respond.
  • Tools:
    • Ryan sent regtyp.h patch for what will become schema 50 on kismet (integ tool). No actual work on it this week.
    • registry-cvt RFS and stable. Backend activities in progress: Registry-cvt-3.1.1.
  • Support
    • Nothing

Goals for coming weeks:

  • Verf: ioi-bare-metal review complete. Exchanges with the the reviewer (Ron) in progress.
  • deos653-cvt: Deos653-cvt-4.1.0
  • Get deos653cvt/config unreleased for Europa, including new .py interface to P2 features for Kismet?
  • Test cpsw update from Chris. Try running the 1 sample test procedure using the release variant of lwip -- the debug variant has a fatal assert during DHCP logic. See PCR:14244

4 Nov - 10 Nov 2024

Accomplishments:

  • IOI Bare Metal:
    • no activity. waiting for response to review feedback.
  • Tools:
    • Ryan sent regtyp.h patch for what will become schema 50 on kismet (integ tool). No actual work on it this week.
    • registry-cvt verf in progress (due next week): Registry-cvt-3.1.1. Currently held up by cvt requirements checklist review.
  • Support
    • NGC: content of a pia.xml file changed between DDSs (20240710 to 20240930). Customer does not understand why. Trying to figure out if that file was different in the distributions, or if it was a tooling action that changed the files, or OA that may be updating validated XML in a different way.

Goals for coming weeks:

  • Verf: ioi-bare-metal review complete. Exchanges with the the reviewer (Ron) in progress.
  • deos653-cvt: Deos653-cvt-4.1.0
  • Get deos653cvt/config unreleased for Europa, including new .py interface to P2 features for Kismet?
  • Test cpsw update from Chris. Try running the 1 sample test procedure using the release variant of lwip -- the debug variant has a fatal assert during DHCP logic. See PCR:14244

28 Oct - 3 Nov 2024

Accomplishments:

  • Tools:
    • Ryan indicates schema 49 will have some additional changes coming
    • registry-cvt verf in progress (due next week): Registry-cvt-3.1.1
  • Support
    • Louie: Did not get an update on last weeks support.

Goals for coming weeks:

  • Verf: ioi-bare-metal review complete. Exchanges with the the reviewer (Ron) in progress.
  • deos653-cvt: Deos653-cvt-4.1.0
  • Get deos653cvt/config unreleased for Europa, including new .py interface to P2 features for Kismet?
  • Test cpsw update from Chris. Try running the 1 sample test procedure using the release variant of lwip -- the debug variant has a fatal assert during DHCP logic. See PCR:14244


21 Oct - 27 Oct 2024

Accomplishments:

  • IOI Bare Metal:
    • Started processing requirement review feedback. There was a problem with the testability of the ring buffer requirements, as they were referencing parameters in the ring buffer library APIs which are not visible in IOI bare metal. The original approach was to keep the requirement structure/numbers as similar as possible between the bare metal and normal IOIs for maintenance. That is going to have to give in, but the code should still be largely similar.
  • Tools:
    • One more IT unrelease related to --appendSource (thanks Ron for finding that)
  • Support
    • Louie: Did not get an update on last weeks support.

Goals for coming weeks:

  • Verf: Get ioi-bare-metal review feedback to Ron
  • registry-cvt rfs: Registry-cvt-3.1.1
  • deos653-cvt: Deos653-cvt-4.1.0
  • Get deos653cvt/config unreleased for Europa, including new .py interface to P2 features for Kismet?
  • Test cpsw update from Chris. Try running the 1 sample test procedure using the release variant of lwip -- the debug variant has a fatal assert during DHCP logic. See PCR:14244

14 Oct - 20 Oct 2024

Accomplishments:

  • IOI Bare Metal:
    • Ron has provided requirement review feedback PCR:15120
  • Tools:
    • deos653cvt: 4.1.0 unreleased for Europa. Some new requirements from Chuck during the week.
  • Support
    • Louie: Some minor stuff related to ioiconfig, hopefully just a bad DESKHOME environment variable set during a make.

Goals for coming weeks:

  • Verf: Get ioi-bare-metal review feedback to Ron
  • registry-cvt rfs: Registry-cvt-3.1.1
  • deos653-cvt: Deos653-cvt-4.1.0
  • Get deos653cvt/config unreleased for Europa, including new .py interface to P2 features for Kismet?
  • Test cpsw update from Chris. Try running the 1 sample test procedure using the release variant of lwip -- the debug variant has a fatal assert during DHCP logic. See PCR:14244

7 Oct - 13 Oct 2024

Accomplishments:

  • IOI Bare Metal:
    • HOLD -> Not on hold: CPSW update. Chris has made some updates to the cpsw and ftpserver, and claims success (using the release variant of lwip -- the debug variant has a fatal assert during DHCP logic). Need to give the r5 tests a go next week. See PCR:14244
  • Tools:
    • More PCRs for IT 3.65.0 (unreleased): PCR:9045 Reenabled a check for memory pool/platform resource overlaps that was disabled 10 years ago. There are still some BSPs with these overlaps which will now raise additional warnings. This was requested by Honeywell (SPS).
    • Updated registry-cvt 3.0.0 PCR:15957 and 3.0.1 PCR:15956 backend docs.
    • registry-cvt: create wiki for verification: Registry-cvt-3.1.1
    • deos653cvt: Work in progress to support schema 20, prep for verification.
  • Support
    • Updated cvt requirement checklist PCR:15685 per Kelly.


Goals for coming weeks:

  • Get deos653cvt/config unreleased for Europa, including new .py interface to P2 features for Kismet
  • Ensure there is sufficient data in the registry-cvt -T file to restore synchronous interrupt names in the 653 XML.
  • Initialize verf wiki for deos653-cvt

30 Sep - 6 Oct 2024

Accomplishments:

  • IOI Bare Metal:
    • HOLD -> Not on hold: CPSW update. Chris has made some updates to the cpsw and ftpserver, and claims success (using the release variant of lwip -- the debug variant has a fatal assert during DHCP logic). Need to give the r5 tests a go next week. See PCR:14244
  • Tools:
    • IT 3.65.0: Unreleased in support of kernel 11.5/schema 49 a couple times. registry-cvt uncovered an IT bug late in the week (PCR:16029).
    • registry-cvt 3.1.1 Unreleased: PCR:15953, PCR:16012
      • SPS has built this tool from SVN and is using it in Jupiter to confirm it works with their various registries. He claims success in using registry-cvt/IT as a standalone pair, and also via deos653-cvt (which invokes registry-cvt).
      • Works-for-me on Europa
      • All development work is done. Verf activities can start.
    • Per AL, changed xml-tools-common xPossibleHosts from arch-independent to all-workstation (PCR:16026)
  • Support
    • lastdrop: Had a DTS with customer, Matthew, and JK. In an IST configuration, they had the *queue-full-status* produce item configured with a numeric production interval. This is incorrect, as it causes the normal slowest-consumer / production rate queue size calculation, and their per in-use rates, caused the queue(s) to be so large, their AMOs exceeded the 768MB MOM VAS limit. Changing their rates to 'aperiodic' resolved the issue.


Goals for coming weeks:

  • Get deos653cvt/config unreleased for Europa, including new .py interface to P2 features for Kismet
  • Ensure there is sufficient data in the registry-cvt -T file to restore synchronous interrupt names in the 653 XML.
  • Publish TAS limitations via PCRs From Sep 16 for registry-cvt 3.0.0/3.0.1

16 Sep - 22 Sep 2024

Accomplishments:

  • IOI Bare Metal:
    • HOLD: There may be a new cpsw coming 'soon'; this would enable this project to resume.
  • Tools:
    • License script: Provided to the OA team on Wednesday for testing. If successful, this would remove the need for --verifyLicense in pi and deos653config.
    • deos653cvt (in work for europa, interrupt list cross check with registry data, chuck has new DRCs)
    • pci-config-cvt documentation PCRs worked. In svn, not unreleased.
    • registry-cvt 3.0.0/3.0.1 has a new limitation that restricts the maximum number of schedulers to 32. Honeywell uses 36 schedulers:
    • deos653config: Met with Shayne, Chris to plan a .py interface between the tool and the dvms/vfile p2 library on kismet.


  • Support
    • Honeywell: warmstartDisruptedSchedulerBitmap (MCAL-D93P99): registry-cvt is raising this error in one of their registries. This is a registry-cvt bug that will cause a false fail (or possibly a false pass) if the number of schedulers in the registry is > 32. This impacts registry-cvt 3.0.0 and 3.0.1. See PCRs above.
      • Proposed Solution (1): Put IT 3.64.0 and registry-cvt 3.1.1 into both jupiter and europa. Success was observed running one deos653-cvt example in this configuration. SPS offered to build the updated tools from svn when available to test on all their registries/config files.
      • Proposed Solution (2): Branch the IT (for the --forceFSOwnership metadata bug) and registry-cvt.

Goals for coming weeks:

  • Customer support actions from above
  • The R5 project is coming back. CP/MV to start by getting the cpsw to survive restarts. Also need to get requirements/code RFR if not already done.
  • Get IT 3.64.1 unreleased
  • Get registry-cvt 3.1.1 unreleased
  • Fully test both CVTs + 653CVT in a jupiter environment to ensure Honeywell proposed solution (1) is viable.
  • Get deos653cvt/config unreleased for Europa, including new .py interface to P2 features for Kismet
  • publish TAS limitations via PCRs above for registry-cvt 3.0.0/3.0.1



Important Notes/Blocking Issues:

  • Still having trouble with cpsw on the Jacintoevm-1. After 3 mode changes, and after a test procedure completes, the network 'spinner' in video memory is spinning and with the correct IP addr, but no ping/ftp connections possible.

9 Sep - 15 Sep 2024

Accomplishments:

  • IOI Bare Metal:
    • HOLD: There may be a new cpsw coming 'soon'; this would enable this project to resume.
  • Tools:
    • IT 3.64.0: Stable on Monday (license checking, kernel 11.5.x/schema 49 support, PRL data alignment fix)
    • unreleased deos653config 1.29.3: Added schema 20,21 support for runtimes used in kismet and europa.
  • Support
    • Kinghall: The oversubscribed scheduler problem mentioned last week. Customer now understand the source of blocking is the RPC between his application and lwIP. They are going to reconfigure the userServiceThread attributes.
    • Licensing (internal): Since we want the updated licensing to apply to older environments, it is not practical to deploy our licensed tools into those older environments because of the CVT costs. Richard suggesting creating a separate license check script, written in python, that OA could use in all environments. This is all to manage a problem where a license borrowed via OA is not usable by the licensed python tools. It was observed that if the license server is placed into 'borrow mode', and then a licensed python tool checks out and returns a license, the borrow license is usable by the licensed python tool. Although still speculation at this point, were going to copy the license checkout logic in the python tool to a standalone script packaged in (OA? desk-python-tools? other?). If that works, that will be the solution.
    • Honeywell: --forceFSOwnership: This is crashing the registry-cvt in Jupiter. The reason is that the IT computes a set of CVT metadata, but sadly does that computation prior to processing --forceFSOwnership. This causes the number of file systems owned by Network to be 'large' in the registry, but 'small' in the CVT metadata, which manifests as an index-out-of-range type of error. This was resolved in newer versions of the IT. Jupiter is CVT schema 9. Of course any newer version of the IT will work in Jupiter, the CVT metadata changed version prior to the IT fix.
      • Workaround 1: Don't use --forceFSOwnership in flight registries. This is apparently NOT an option with Honeywell. I'm not sure how a low DAL network process can have RW access to those MFSs, but I did not ask.
      • Workaround 2: Modify network-lwip.pd.xml (or a .fp.xml) to add ownership of the MFSs.
      • Update Option 1: Branch the IT at the last version prior to the cvt schema 9->10 change. Backport in the --forceFSOwnership fix. Seems simplest.
      • Update Option 2: Update the Jupiter registry-cvt to be compatible with an IT version have has the --forceFSOwnership fix. More expensive, but may also pick up more fixes (or bugs).
    • Honeywell: warmstartDisruptedSchedulerBitmap (MCAL-D93P99): registry-cvt is raising this error in one of their registries. This is a registry-cvt bug that will cause a false fail (or possibly a false pass) if the number of schedulers in the registry is > 32. This impact registry-cvt 3.0.0 and 3.0.1.

Goals for coming weeks:

  • Customer support actions from above
  • License checkout script from above
  • R5 test environment.
  • Implement Aaron suggestion on versioned schemas/cdproc, quiet mode.


Important Notes/Blocking Issues:

  • Still having trouble with cpsw on the Jacintoevm-1. After 3 mode changes, and after a test procedure completes, the network 'spinner' in video memory is spinning and with the correct IP addr, but no ping/ftp connections possible.

2 Sep - 8 Sep 2024

Accomplishments:

  • IOI Bare Metal:
    • HOLD: See last week. Overheard Kelly in a meeting with Liebherr: There may be a new cpsw coming 'soon'; this would enable this project to resume.
  • Tools:
    • IT 3.63.1: Stable on Wednesday (license checking)
    • deos653config 1.29.2: Stable on Wednesday (license checking)
    • IT 3.64.0:
      • In support of kernel schema 49. Ryan, there is a patch in PCR:15825 for regtyp.h in there. Sufficient CVT metadata has been added to support schema 49.
      • Customer reported that an oversubscribed scheduler is shown in the .cck, but fails to generate an error (in some cases). Resolved in 3.64.0. See PCR:15910.
      • Maintainer (CP) noted that not all PRL driver data structures in the registry were 64-bit aligned, causing alignment exceptions. PCR:15915 resolved this issue. Unreleased Friday, test report created over the weekend. Will go stable Monday after another CCB, effectively cancelling version 3.63.1.
  • Support
    • Trickyfish: Found a problem with power cycling that can cause dvms to be unable to recover. Chris has a solution and a workaround is being pondered. No resolution to the ioi ram page problem. If there was rogue DMA activity from dvms, Chris thinks there would be a specific pattern somewhere on the 'bad page'. Boeing reported Friday that no such pattern was found. Were are out of ideas on this matter; next steps would include adding JTAG to the bad board at Boeing and chasing this problem with a Lauterbach on that specific SOM.
    • Kinghall: The oversubscribed scheduler problem mentioned above. The remaining claim from them is that a not-oversubscribed scheduler is not scheduling all threads in their periods. We did review their source and noted a blocking sendto(). With that removed, the claim remains that the thread is not scheduled in each of its periods. Were waiting for platreg.s platreg.cck and timemap evidence.


Goals for coming weeks:

  • R5 test environment.
  • Implement Aaron suggestion on versioned schemas/cdproc, quiet mode.
  • deos653config:
    • Merge schemas in support of Chucks baseline merge


Important Notes/Blocking Issues:

  • Still having trouble with cpsw on the Jacintoevm-1. After 3 mode changes, and after a test procedure completes, the network 'spinner' in video memory is spinning and with the correct IP addr, but no ping/ftp connections possible.

26 Aug - 2 Sep 2024

Accomplishments:

  • IOI Bare Metal:
    • HOLD: See last week.
  • Tools:
    • IT 3.63.1 (unreleased):
      • PCR:15825 prlLoadOrder feature is in.
      • PCR:15891 Added switch to verify license, used by OA during 'borrowing' of licenses
      • Still need to add user data for interrupts (level/edge triggered, etc.) and thread templates (x86 CAT).
  • Support
    • Trickyfish:
      • Summary for the week. We did receive trickfish hardware, and eventually some software that would boot up their display. We were never able to reproduce the primary problem, where an IOI queue in a Deos shared memory object can be written to and read from on core 0, but a view of that same physical page (via attachMemoryObject) shows all zeros. Cache policy is writeBack in both page tables, and permissions are also correct. Problem #2 was dvms journal related, where the primary data structure (super block?) was corrupted. We also learned that is might have been possible, via ftp, that multi-thread access to dvms was in play. That is not supported. dvms tests are in progress at Boeing and at DDC-I. Should have some results on Tuesday.
    • Internal: Borrowed licenses.
      • The licensed config tools have been updated to support a new strategy within OA to manage borrowed licenses. Looks like borrowing licenses in WSL is not supported by flexnet. Returning a borrowed license is now possible in OA with the tooling updates.

Goals for coming weeks:

  • R5 test environment.
  • Implement Aaron suggestion on versioned schemas/cdproc, quiet mode.
  • knock out Ryans remaining registry mods
    • add user data for interrupts and thread templates.
    • stable IT/653config released (need the license related updates)
  • deos653config:
    • Shanye may need some support for P2 debugging configuration. Need synchronization.
    • Merge schemas in support of Chucks baseline merge


Important Notes/Blocking Issues:

  • Still having trouble with cpsw on the Jacintoevm-1. After 3 mode changes, and after a test procedure completes, the network 'spinner' in video memory is spinning and with the correct IP addr, but no ping/ftp connections possible.

19 Aug - 25 Aug 2024

Accomplishments:

  • IOI Bare Metal:
    • HOLD: See last week.
  • Tools:
    • IT 3.61.1:
      • PCR:15825 prlLoadOrder feature is in svn PCR:15825.
      • Not unreleased, pending feature to add user data for interrupts and thread templates.
  • Support
    • Trickyfish:
      • Monday meeting: Had them add a 'print' of the IOI queue memory in their two processes (653/APP, and Deos NVM). The write calls appear in the shared memory object, but the readers view of that memory object is all 0's. Ryan suggested getting the VAS dump from the status monitor for both processes, as that report will include the cache settings.
        • APP (core 0): Vaddr c7f78000 (3354886144): Mom,3354886144,1200128,Present,2384572416,Write Back,Read/Write
        • NVM (core 2): Vaddr C8C00000 (3368026112): Mom,3368026112,1200128,Present,2384572416,Write Back,Read
      • Tuesday meeting: Per the above, Ryan thinks that some uboot setting may incompatible with the memory performance of the hardware (tolerances too tight). Reported this status to the customer. They seemed reluctant to accept that answer, but same page different content is before them. They were going to try another 'som' (hardware) to see if 3 consistently fail in this same manner. Asked them to contact support for any knowledge we may have with uboot settings.
      • Wednesday Meeting: Ryan, Matthew, Kelly showed up for a meeting. Ryan led the technical exchange. 'Formatting' a portion of the board does make things function normally. Ryan speculated that some uboot settings could be overwritten by that and initialized back to a working state. Their 'formatting' may just be limited to an area that stores log files. Need clarification. We volunteered to add logic to our 'print' function (on a specific page of RAM used for an IOI queue used in a cross core configuration where the writer see its writes, but the reader does not see any of the writes) to include a cache flush. Mailed out that update Wed pm.
      • Friday: Kevin reached out for status:
        • There was an email on support related to the cache flush results that I did not see (not on support). Results made no sense to me. Reader continues to see 0's on core 2. Writer see its own data on core 0, but after flushing cache, is unable to print any data but is also not page faulting. Same print routine just does not print the data. Ryan is checking my code. They also showed the same code executing on a working SOM and reader sees data, but the post cache flush print on the writer still fails to print. The reader calling the same print function prints before and after as expected.
        • Mondays meeting will include BSP team members
        • Boeing cannot push this matter past next Friday.
    • Internal: Lisa/Matthew report that the IT license checking on a borrowed license fails when not VPN connected on one of our test machines. Customer also reports an issue with a borrowed license. Investigation in progress. All tools using licenses (OA, IT, deos653config) can use borrowed licenses except the python based tools.
      • Thought the python license checking logic was flawed with py2/py3 string/unicode interface to the license checking dll/so, but I could not make that conclusion. The stable versions of the tools do checkout and checkin licenses from the server as expected. When a license is borrowed (OA Help menu), that's when things are inconsistent:
        • In my personal cygwin 2024 environment, a borrowed license function normally.
        • In my personal europa wsl, a borrowed license is not recognized.
        • On Lisas test machines, and for the customer, a borrowed license is not recognized
        • Meeting with the license software provider on Monday

Goals for coming weeks:

  • R5 test environment.
  • Implement Aaron suggestion on versioned schemas/cdproc, quiet mode.
  • knock out Ryans remaining registry mods
    • add user data for interrupts and thread templates.
    • unrelease schema 49
  • deos653config:
    • Shanye may need some support for P2 debugging configuration. Need synchronization.
    • Merge schemas in support of Chucks baseline merge


Important Notes/Blocking Issues:

  • Still having trouble with cpsw on the Jacintoevm-1. After 3 mode changes, and after a test procedure completes, the network 'spinner' in video memory is spinning and with the correct IP addr, but no ping/ftp connections possible.

12 Aug - 18 Aug 2024

Accomplishments:

  • IOI Bare Metal:
    • HOLD: See last week.
  • Tools:
    • IT 3.61.1:
      • prlLoadOrder feature is in svn PCR:15825.
      • Not unreleased, pending feature to add user data for interrupts and thread templates.
  • Support
    • Most of the week was spent trickyfish support. They are about to be in ground flight test, and are producing hardware/software systems (same hardware, same software). They are reporting that an ioi_read in a hybrid configuration where the writer is a 653 partition using a queuing port is not functioning in 1 out of 10 systems.
      • the static configuration data looks correct
      • stack utilizations are well with bounds
      • The ioi file descriptors to use have been 'printed' and appear to be correct (653 GET_QUEUING_PORT_ID() reports back the expected ID on the writer); need to check the FD value on the reader
      • OA reports a debug suspend icon on their reading process, but there are no exceptions. Will try the cmd line status monitor to determine state
      • Sent them a function to dump the ioi queue memory for use in both the reading and writing processes to see if the problem is their view of memory.
      • Not sure what else to do to help them, but they are a anxious for an understanding as they are about to begin formal production.

Goals for coming weeks:

  • R5 test environment.
  • Implement Aaron suggestion on versioned schemas/cdproc, quiet mode.
  • knock out Ryans remaining registry mods
    • add user data for interrupts and thread templates.
    • unrelease schema 49
  • deos653config:
    • Shanye may need some support for P2 debugging configuration. Need synchronization.


Important Notes/Blocking Issues:

  • Still having trouble with cpsw on the Jacintoevm-1. After 3 mode changes, and after a test procedure completes, the network 'spinner' in video memory is spinning and with the correct IP addr, but no ping/ftp connections possible.

5 Aug - 11 Aug 2024

Accomplishments:

  • OOO: Tuesday
  • IOI Bare Metal:
    • HOLD: See last week.
  • Tools:
    • IT 3.61.1:
      • Added CVT schema 10 data in support of PRL load ordering PCR:15825. The PRL load ordering feature was working. Per feedback from Ryan, it's back into re-implementation with a slightly different set of functionality; previous attempt was driven in part by CVT impacts. On the new path, the CVT metadata will encode the XML expressions, and the CVT will determine the set of nodes and paths, and ensure those are honored in the registry, in addition to ensuring no ordering expressions were omitted. The actual order of files in the registry may vary but still be in compliance (e.g., a -> b, a->c could yield a -> b -> c or a -> c -> b in the registry).
      • Added tests for dag in prl order.
    • deos653config:
      • Shanye may need some support for P2 debugging configuration. Need synchronization.
  • Customer Support
    • Trickyfish IOI investigation of queuing port -> ioi consume item. Their .cfg files have been analyzed and no errors were detected. Matt and I will meet with them on Monday for a DTS.

Goals for coming weeks:

  • R5 test environment.
  • Implement Aaron suggestion on versioned schemas/cdproc, quiet mode.
  • knock out Ryans remaining registry mods
    • add user data for interrupts and thread templates.
    • unrelease schema 49


Important Notes/Blocking Issues:

  • Still having trouble with cpsw on the Jacintoevm-1. After 3 mode changes, and after a test procedure completes, the network 'spinner' in video memory is spinning and with the correct IP addr, but no ping/ftp connections possible.

29 Jul - 4 Aug 2024

Accomplishments:

  • IOI Bare Metal:
    • HOLD: See last week.
  • Tools:
    • IT 3.63.1: Added support for kernel schema 49, which allows .pi.xml to specify PRL load orders is in svn PCR:15825
    • Deos653Config: Chucks merge of the runtime ranches was able to retail schema 19 for europa and schema 18 for kismet.
  • Customer Support
    • Someone was using an IT version from over 2 years ago that did not support a feature provider setting largestAMOSizeInPages multiple times. That has been resolve.
    • Assist Bill in training on a scheduler-before build.
    • Claim from TrickyFish (jupiter) that a hybrid IOI reader is not receiving data from a 653 queuing port writer. Under investigation. They said "This issue is only present on one of our red label units. Other units loaded with the same software have been functioning as expected. In our troubleshooting process, to rule out hardware being the root cause, we cloned the “faulty” 64 GB image to a fresh SOM and verified that the issue was present on the second SOM." It's not clear to me how ... same software works on multiple boards, but when it loaded on a 'fresh som' the failure repeats. Scenario is:
      • Queuing port writer with a formatting function to strip off 653 stuff. All queuing ports use the queueFullDetection mechanism (via deos653config).
      • Deos IOI consumer
      • Queue size of 1, message size of 4096
      • All ioi_init() and ioi_open() calls complete normally.
      • Writer can write, reader cannot read
      • Analysis:
        • A success status code from SEND_QUEUING_MESSAGE on > 1 message means something read the message and sent back via queueFullDetection the message sequence number read. Without that, the writer would get an error status code.
        • If the writer had a TBE during SEND_QUEUING_MESSAGE, that would cause the reader to receive status code ioiInvalidMessage.
        • Is something else calling read?
    • Hon reported a 653 power transient exception handling error that may involve deos653config and or the 653 p1 runtime. Under investigation.

Goals for coming weeks:

  • R5 test environment.
  • Implement Aaron suggestion on versioned schemas/cdproc.
  • knock out Ryans remaining registry mods


Important Notes/Blocking Issues:

  • Still having trouble with cpsw on the Jacintoevm-1. After 3 mode changes, and after a test procedure completes, the network 'spinner' in video memory is spinning and with the correct IP addr, but no ping/ftp connections possible.

22 Jul - 28 Jul 2024

Accomplishments:

  • OOO Monday
  • IOI Bare Metal:
    • HOLD: See last week.
  • Tools:
    • CPow identified a bug in 64-bit registries when an unmapped resource is associated with a driver; the driver data was represented as 32-bit when it should have been 64-bit PCR:15809. Fixed in IT 3.63.1.
    • Adina reported that the -g switch from pia, which generates the platreg.pi.xml file, was listing the memory mapped resources in random (instead of startAddress) order. Although this is not an error, it is unusual and makes reading that .pi.xml file a little harder. Validation of the file does generate the resources in the correct order. This is resolved in PCR:15817
    • Minor UG updates for SPS via support PCR:15816.
    • Met with Ryan and Aaron on the topic of "registry blobs". There was discussion on whether the registry was generally open to use supplied data or whether the registry was just kernel data (where the PAL is part of the kernel). The latter was the conclusion. As a result, the short term data need for kismet will be met in the following way:
      • CAT support: a <threadTemplate> will get a new attribute (TDB name) for the Intel CAT [3] feature.
      • Interrupt sense/level data: <interrupt> will get a new attribute 'configWord0' which can be used as driver specific data.
    • Ryan needs the ability to have the set of PRL images listed in the registry subject to a sorting order. This is primarily driven by the need to load test interceptor libraries before the corresponding real libraries. Such a feature is likely going to be subject to a DAG [4] for correctness, which adds some work.
      • In the platreg.s, change registryRegistrationFunctionNames (pairs of library, initialization function) into a sorted list of libraries. Another list would associate an initialization function name with an index into the first list. On the XML side, two options were discussed:
        • add an optional child element of <memoryMappedResourceDriverAccess> or add new attributes to that element to include an operator (before | after) and reference to PRL library.
        • add a new element to the .pi.xml that would allow a set of before|after expressions. This results in some duplication of data, but the feature is not anticipated to be of much interest outside of DDCI.
  • Other:
    • Liebherr response on data/control coupling for IOI, emphasizing Deos components do not share global data, that the UG/API usage guidance is the formal interface.

Goals for coming weeks:

  • R5 test environment.
  • Get with Aaron on versioned schemas/cdproc.
  • knock out Ryans registry mods
  • deos653config: Chuck is merging the 653 runtime branches, causing a merge of config file schemas 17, 18 and 19, resulting in 20. Update config/cvt


Important Notes/Blocking Issues:

  • Still having trouble with cpsw on the Jacintoevm-1. After 3 mode changes, and after a test procedure completes, the network 'spinner' in video memory is spinning and with the correct IP addr, but no ping/ftp connections possible.

15 Jul - 21 Jul 2024

Accomplishments:

  • IOI Bare Metal:
    • HOLD: This task is effectively on hold pending a network stack that can survive coldstarts. Status is one test procedure is executing correctly, but results must be observed with an emulator. Instrumented variant of a test procedure cannot be loaded (too many coldstarts in the regress sequence and cannot survive a clear hitmap operation). There is also a set of changes to test utils to enable regress to test a .a file, and to run-tests.sh to NOT extract architecture and variant from the image being tested.
  • Tools:
    • Investigating lxml and namespaces for Aaron. Had a meeting late in the week and will be initially focusing on cdproc, mfs integration, and versioned schemas in the upcoming week
    • Aaron reported that Adina (on Vacation) reported that the memory mapped resources in the (platreg.s| validated .pi.xml) is not in the correct order.
  • Other:
    • Liebherr data control coupling response for ioiapi.
      • Process Bug?: We use the checklists as part of the verification strategy. If the checklist is updated, can we re-use a verified component without performing a standards change analysis?
    • The house is in disarray. Primary contractor is going to be unavailable after Wed for about a month. We are in a panic, which translates into a priority to assist him while he's here. Subject to last minute vacation approval, I may be mostly ooo M-W on July 22,23,24


Goals for coming weeks:

  • R5 test environment.
  • Ryan needs an IT modification for specifying PRL load orders. Same PRL can be the registry list multiple times with same or different registry function names. Need a different structure.

Important Notes/Blocking Issues:

  • Still having trouble with cpsw on the Jacintoevm-1. After 3 mode changes, and after a test procedure completes, the network 'spinner' in video memory is spinning and with the correct IP addr, but no ping/ftp connections possible.

8 Jul - 14 Jul 2024

Accomplishments:

  • IOI Bare Metal:
    • Able to successfully call ioi api functions from a test procedure on the R5.
    • Cleanup TODOs in test environment
    • Got the instrumented build at the right hitmap address
    • Test Utils/regress: Pinned at an older Jupiter/europa revision (pre cdproc). ioi-bare-metal is packaged as a .a file. regress does not permit that file type, and run-tests.sh (called by regress) has preconditions that cannot be met. Have to effectively branch test-utils, or create local scripts. Pursuing the former.


Goals for coming weeks:

  • R5 test environment.
  • Ryan needs an IT modification for specifying PRL load orders. Same PRL can be the registry list multiple times with same or different registry function names. Need a different structure.
  • Aaron needs to know if lxml and namespaces work properly.

Important Notes/Blocking Issues:

  • Still having trouble with cpsw on the Jacintoevm-1. After 3 mode changes, and after a test procedure completes, the network 'spinner' in video memory is spinning and with the correct IP addr, but no ping/ftp connections possible.

1 Jul - 7 Jul 2024

Accomplishments:

  • Tue: With some linker script assist from Ryan and Adina, the IOI Bare Metal regress script made its first end-to-end call, showing the infrastructure is working. Note that this also includes some FTP shutdown hook and cpsw patches for the Jacinto.
  • Wed: deos653config 1.29.1 stable for the sales release.
  • Wed: ioiconfig 4.0.1 stable for the sales release.


Goals for coming weeks:

  • More R5 testing.
  • Ryan needs an IT modification for specifying PRL load orders.

Important Notes/Blocking Issues:

  • None.

24 Jun - 30 Jun 2024

Accomplishments:

  • OOO: Just keeping up with email oversight, minor feedback where needed
  • unreleased ioi-config 4.0.1 for kismet debugger support (PCR:15767)

Goals for coming weeks:

  • R5 Test Environment.

Important Notes/Blocking Issues:

  • Emulator on DeosJacinto7EVM-1. Need that back.
  • Stuck on getting an R core test procedure, loaded by an A core, to write to TestResults.
Retrieved from "https://ddci.zapto.org/ddciWiki/index.php?title=User:Gkindorf@ddci.com&oldid=75308"