GeekFest 2019

 linux04: sudo du -hs /svn/DDCI/ /scm/Deos/
 29G	/svn/DDCI/
 33G	/scm/Deos/

thing  (status of thing)
  blocked by list of component:feature (status of blocked feature)

All ARM boots have this issue (s32v234, harrys, imx8qm, zcu102, ls1043a, ls1048)
qemu-arm-boot  (implemented, not released)
     kernel:64-bit descriptors   (implemented, not released)

all arm, ppc, x86 pals
qemu-*-pal   (implemented, not released)
     kernel:pal interface        (implemented, not released)
       -- kernel unreleased has ppc and arm support for both "old" and "new" interface
       -- kernel released only has support for "old" interface
          x86 would have to be synchronized with kernel 9 release.

ARM bsps
  kernel:arm-cpu-requirements

Customers and the features they request.

Current state/baseline assumes features already in a component, even if the feature is not fully
implemented (e.g., frame-resync is a kernel feature, just not fully implemented yet).  Or there is
an existing (estimated) task on "the wiki".

components features that are currently only partially implemented
  kernel
    frame sync
    warmstart
    multicore        This feature is assumed "in".
    sliding windows  Used by harrys; needs to be verf'd
    x86 support      Don't do verf, but otherwise unchanged (currently no customers)
    ppc support      Don't do verf, but otherwise unchanged

  all components could skip verf on ppc and x86 for Harrys

NO-COMPONENT-INTERACTION

Harrys
  Kernel: feature complete.
  tdl: ...
  cffs: ....

Durants
  We desperately need to get concurrence from them on our interpretation of these tasks.
    Need a meeting with Durants after the preliminary design of
      KFS
      TLS
      Sliding windows in 653
      cumulative execution time of RMA threads

  F04: 653 sliding windows including frame sync and warmstart
    deos653-p1-runtime  (sliding window support)
    deos653-config
    deos653-cvt
    kernel
    integ-tool (add back sliding windows)

  F07a-1: C++ 11: Thread Local Keyword RMA and 653
    kernel
    libgcc-so
    deos653-p1-runtime
    constraint on the TLS implementation is that a lib can be used by RMA and 653/rtems without change.
    abc-tool (e.g., R2 if registers are required to implement TLS)

  F07a-2: primitives to support sync operations (memory fences, applicable to program memory only)
    used by ioi, cffs-server, cffs-api
      Kelly: This kernel feature must be done as part of harrys so that above components can be "done"
    Marketing says must support "old" ppc processors.

  F08: do verf for 653 part 1 sup3 runtime
    deos653-p1-runtime need to strip handies unicore-code for TBE.
    deos653-p4-runtime needs to be updated to satisfy code checklists, or we need to drop p4 support
      Richard: will get answer for whether to keep p4 or not.

  F08: do verf for part 2 file system
    cffs-api-p2 : cffs-server:512-byte-file-names

  F10: qemu extensions for simulation
    qemu-vm : NO-COMPONENT-INTERACTION
      Aaron to give Kelly reference to potential qemu developer.

  F13: kernel file system individual part number
    kernel
    hypstart
    registry-cvt
    integration-tool
    ftpserver
    open-arbor

  F14: special binary
    Some new file system driver
      Not clear this is part of SOW.
    All from F13.

  F17: kernel RFS on i.mx8
    kernel :  NO-COMPONENT-INTERACTION

  F17a: zcu102 RFS.  Durants thinks this is to be done on a Durants developed BSP.,
        DDCI thinks this is on a reference board or N/A.

  F22: cumulative execution for RMA threads
    kernel
    status-monitor
    open-arbor

  Other things that are not under contract that have been mentioned:
    Lauterbach "stuff", e.g., trace32 extension needs kernel:CONTEXTIDR
    atomics
    36-bit physical addressing on ARM (expected to be a "no")
       Durants requested this to be available for DEOS_RAM above 4GB.
       Note that without this feature, Deos on newer ARM will be limited to 2GB.

DesertEagle
  ANSI
    locale
    calloc/malloc
      Will be limited to single threaded due to lack of kernel support
        Kelly: Probably should get concurrence from customer.
      Developer-Note all ram init via virtualAllocDEOS is initialized
      Developer-Note the missing kernel support is a compare-and-swap-next-library-address
        To be thread safe needs the kernel to have an atomic get next/set next library addr
          We (RLR) don't think the DesertEagle needs a thread safe malloc
      malloc/calloc/free should be weak (but if this is a problem punt)

    printf/vprintf
      assume 'set function pointer for stdout' is implementation choice.

  time-library
    gmtime
    other APIs are not required for DesertEagle, but are for FACE, including set and get walltime.
    Developer-Note: what is the interface to getting wall time, and
       what support is required for setting the time base?  Unclear
       what other components are affected, potentially:
          kernel
          pal
	  ???
	  a PRL?

  startup-library (static)
    __dso_handle
      pending conversation with Johan/Thorkil.

  libgcc-so  (aka C++ runtime)
    new/delete : ansi:calloc/malloc
      Customer has agreed that operator delete will not free memory
    c++ casting, excluding dynamic cast (expected to be done by compiler).
    __cxa_atexit         Not part of kickoff slides but was part of procurement spec
    __cxa_pure_virtual   Not part of kickoff slides but was part of procurement spec
       Kelly get concurrence from customer that these can be omitted.

  cffs-server
    512-byte-file-names

  cffs-api
    512-byte-file-names

  cffs-api-p2
    512-byte-file-names
    log books
      Perhaps add option for "backend" cffs vs ioi+formatting function

  deos653-p1-runtime
    multi-module schedules
      kernel : multiple WAT support
      integration-tool : multiple WAT support
      registry-cvt : multiple WAT support
      deos653-config : multiple WAT support
      deos653-cvt : multiple WAT support
      PALs (maybe, did the PAL implementation do the right thing?)

    queueing port list
      deos653-config
      deos653-cvt

  kernel
    kernel file system individual part number (see durants above)

  math
    various new APIs : NO-COMPONENT-INTERACTION

  653p5
    partition mode change hooks
      deos653-p1-runtime
      deos653-config

    partition switching hook
      Design not sufficiently defined to determine if this is one or both of:
        kernel (?)  Probably "not" since the could depend on windowTimerWrite
        deos653-p1-runtime (?)  Need clarification if hook is in "user mode".
        deos653-config

    startup before partition scheduling
      Awaiting clarification of semantics from RLF

  decompression library (DAL D)
    Current understanding this is for boot and has NO-COMPONENT-INTERACTION

  lint for detecting usage of Deos specific extensions, e.g., 653p1 APIs
    RLF awaiting clarification of semantics from RLF
    RLF to schedule meeting.

  LS1048a BSP
  T1042 BSP
  LS1043a BSP
  CFFS SATA MAL
  serial device driver, gpio, spi drivers for each bsp
  Other things that are not under contract that have been mentioned:
    Ada
    CFFS EMMC MAL 

Rascal also Marketing request
  FACE 2.x spec, i.e., finish RTEMS integration (due April)
  FACE 3.x spec, depends on above ansi changes and multi-module schedules, but otherwise nothing new (due November)

savianos ARM v7 (whatever the coretex-a9 project is called)
  kernel needs sub-architecture specific memory barrier that differs between v7 and v8.

development task, to get people to understand memory model including fencing, etc.
  Kelly to schedule
  TBD to develop material.

--------------------------------------------------------------------------------

kernel

  Every WAT must have the same amount and placement of 653 windows vs RMA windows.  The number of
  size of 653 windows can change, but the aggregate must be congruent.  For RMA windows their
  durations and placement must be congruent.  setActiveWAT only takes effect at a WAT boundary.

  Add an API to get and change the active WAT, with appropriate access controls.
  LOE: 3 weeks for requirements + code (mostly requirements), assume standard multiplier for verf.

integration-tool
  add ability to store multiple WATs, and enforce the kernel's constraints.
  LOE: 2 weeks

registry-cvt
  adjust to changes made in config
  LOE: Already included in estimate on kernel multicore wiki.

deos653-config
  ability to convey multiple module schedules to the registry
  LOE: 1 week

deos653-cvt
  adjust to changes made in config
  LOE: 1 week devel, 2 weeks verf

PALs
  no known/expected issues

deos653-p1-runtime
  Schedule change action
  implement SET_MODULE_SCHEDULE
  config actions
  LOE: 3 weeks devel+requirements, assume standard multiplier for verf.

--------------------------------------------------------------------------------

each ELF image has:
  .tdata &  .tbss thread local data and bss sections
  no constructors are permitted.

Kernel must provide:
  module number of each loaded ELF image.
  Storage for the sum of the tls space for all loaded modules
  An array of length #loaded modules.
  PIG must specify that PAL/PRL do not use TLS.

JN/TR will provide a determination of whether the kernel desired capabilities below:

  Desire being able to use TLS for both PIC and fixed addresses.
  Need get_addr to be called for all .sos, and ideally for the .exe as well.
  Would be nice to minimize kernel dependencies on thread create.
   - E.g., kernel calls a "thread init function" and module does its own init.
  TLS is not supported in .PE files.
  How does this affect debuggers.
    - Consider the effect of the new gdbserver porting layer.

can be supported by GCC, and what (if any) interesting compiler switches are necessary.

Kernel is expected to provide __tls_getaddr()

Kernel will use thread local store, and keep track of the "max initialized TLS address"

TLS will be specified as a single block of memory on the thread stack (i.e., kernel existing TLS model)
The TLS variable fixups will specify the offset from the thread local storage pointer to the
appropriate offset within the TLS for the variable taking consideration of the modules already loaded.

void *__get_addr(size_t m, size_t offset)
{
  if (offset >= previously_initialized_offset)
    previously_initialized_offset = initialize_the_newly_loaded_modules'_.tbss_and_.tdata(tls_base, previously_initialized_offset)
  return tls_base + offset
}

To eliminate the need to implement dynamic ELF symbol lookup, we could store the pointer to the
thread's TLS base at the thread's TLS base, then use a "double indirection" to get to the actual TLS
base.  653/POSIX would write the TLS base at a context switch to point to the TLS for the
653process/pthread being switched "to".

ANSI should be changed to no longer use TLS, instead it should use TLS.

All DDCI libraries that are usable from 653/POSIX should use TLS variables, not Deos TLS.

Kernel needs a new API to get the TLS size.

For 653, process 0 will use RMA's thread's TLS.

--------------------------------------------------------------------------------
How to deal with assignments of functions to startup, dart, etc.

startup library
  We'll keep libgcc.a, but move libgcc-so.so to a new component, e.g., like Bugzilla's gnu-language

libdart.so   Delete dart component, move functions to libgcc-so.so
  long long (un)signed division (for arm both ABI and gcc names)
  long long (un)signed comparison

libgcc-so.so
  long long to float&double and back   (for arm both ABI and gcc names)

math

ansi  non-math, non-time part of the c standard library  // stdlib.h, string.h,
  locale
  gmtime & gmtime_r  move to libtime.so

kernel
  atomics               fence functions

New functions:
  tls                   libgcc-so
  malloc/calloc         put in ANSI because they are defined in stdlib.h
  c++ new/delete        libgcc-so
  atomics               stdatomic.h, non-fence functions
  __dso_handle          libgcc-so
  __cxa_atexit          libgcc-so
  __cxa_pure_virtual    libgcc-so

libtime.so   time.h defined functions
  asctime_r     FACE request
  ctime_r       FACE request
  localtime_r   FACE request
  difftime
  gmtime & _r
  mktime
  tzname
  time    Needs ability to read current time from somewhere.
  tzset

Time	Type	Topic	Location	Lead
09:00 - 10:0	All Hands	Welcome and Agenda Overview	Main Conference Room	Bill C.
10:00 - 14:00	Management Team	Sales Kick Off meeting	Main Conference Room	Bob M.
10:00 - 14:00	All Hands	Sub-team face to face	Various	N/A
14:00 - 16:00	All Hands	Deliverables, Schedules & Staffing	Main Conference Room	Kelly L.
17:00 - 20:30	DDC-I Employees	A Company Celebration	Top Golf Scottsdale	Bob M.

Time	Type	Topic	Location	Lead
09:00 - 11:00	All Hands	Deliverables, Schedules & Staffing	Main Conference Room	Kelly L.
10:00 - 11:00	All Hands	OpenArbor Road Map	Main Conference Room	Lisa J.
14:00 - 15:00	All Hands	#Maintainer use of Eclipse	Main Conference Room	TBD
15:00 - 16:00	All Hands	#Infrastructure tasks	Main Conference Room	TBD
18:00 - 19:30	All Hands	FACE social	TBD	TBD

Time	Type	Topic	Location	Lead
09:00 - 09:20	All Hands	#CFFS Multicore Features and Improvements	Main Conference Room	Jerry K.
09:20 - 10:00	All Hands	#Process Improvements	Main Conference Room	Kelly L.
11:00 - 12:00	All Hands	ProjectManager.com	Main Conference Room	Kelly L.
09:00 - 10:00	All Hands	Marketing State of Union	Main Conference Room	Greg R.
10:00 - 11:00	All Hands	Needed Sales Features	Main Conference Room	Gary G.
11:00 - 12:00	All Hands	Security Requirements	Main Conference Room	TBD
13:00 - 14:00	All Hands	#Location of compiler support routines	Main Conference Room	TBD
14:00 - 15:00	All Hands	#Honeywell Oversight	Main Conference Room	TBD
15:00 - 17:00	Deos Team	#Meeting with Honeywell Team	Main Conference Room	Bill & Stephen So (HI)

Person	Rental	Arrival	Riders	Departure	Riders
Aaron Larson	Yes	01-24-17:14 AA327	TBD	02-01-19:53 AA1560	TBD
Adina Roffelsen	No	01-24-23:45 SWA1433	N/A	02-01-18:00 SWA2175	N/A
Bill Cronk	No	01-27-17:30 SWA 3647	N/A	02-01-18:00 SWA 2175	N/A
Gary Gilliland	Yes	01-28-13:47 AA407	MH	01-31-21:10 AA766	MH
Gary Kindorf	TBD	01-27-17:30 SWA 3647	TBD	02-01-18:00 SWA 2175	TBD
Johan O. Nielsen	Yes	01-26-22:47 UA483	TBR	02-02-15:33 UA2000	TBR
John Kimball	No	01-27-20:30 SW5116	TBD	02-02-11:20 SW2370	TBD
Kelly Leonard	No	01-28-19:10	TBD	02-01-18:00 SWA	TBD
Laurent Meilleur	TBD	1-28-??	TBD	02-01-??	TBD
Lisa Jett	Yes	01-25-9:30 Delta704	TBD	02-01-18:00 Delta723	GK
Mike Horgan	No	01-28-12:45 SW1534	TBD	01-31-21:20 SW3981	TBD
Ryan Roffelsen	Yes	01-24-23:45 SW1433	TBD	02-01-18:00 SWA2175	TBD
Theresa Rickman	TBD	1-28-??	TBD	02-01-??	TBD
Thorkil Rasmussen	No	01-26-22:47 UA483	TBD	02-02-15:33 UA2000	TBD

GeekFest 2019

Contents

Description

Agenda

For those coming from out of town

Travel Plans

Traditional Hikes

Potential Topics

Infrastructure tasks

Location of compiler support routines

Honeywell Oversight

653 Verification

Process Improvements

CFFS Multicore Features and Improvements

Maintainer use of Eclipse

Project Planning

Discuss Security Requirements

Meeting with Honeywell Team

Geek notes

Component Dependencies

Kernel file system

multi-module schedules

TLS

Libraries Where Functions Go

Atomic Fences

Kernel ARM RAM limit

Navigation menu

Page actions

Page actions

Personal tools

Navigation

Search

DDCI Tools & Resources

DDC-I private

Shared IP

Other

Tools