Deos Team Meetings

foo$ run-docker -it --rm --name=twinkie ubuntu-kismet-dev
dkr:gdb foo$ cdproc-makefile qemu-arm
dkr:gdb foo$ make boot
dkr:gdb foo$ startqemu    # Should show qemu running the kernel (blank screen) and nothing else.
# To add network standard apps:
dkr:gdb foo$ cdproc-makefile --component development-support qemu-arm
dkr:gdb foo$ make boot
dkr:gdb foo$ startqemu
--host-docker
* Ryan: provide cross core synchronization or critical [PCR:13443]

Technical & Support Topics:

  "< !-- &developmentDistribution; This distribution is not for customer delivery! -->"

   Noticing some requirement churn in DPAA-PRL which is affecting tests; however, the tags are not rolling i.e. testers don't know there is an impact..

  On PPC (currently) core == sub-architecture, I don't see that ever changing.  
  On ARM core != sub-architecture.
  On x86 I am not sure if the core is a separate entity from the processor.

@ package vfile ...
[test]
version: 6.0.0-9
depends: desk, desk-python-tools, kernel (>= 10.7.1), vfile-examples, vfileconfig
Adina, Chuck, Jean, Kelly, and I met and discussed this issue here are the results:
 - After some amount of gnashing of teeth, we decided if the tool is verifying some or all of the contents of a binary configuration file it falls under the category of a CVT.
 - All CVTs will continue to be TQL-4
 - All CVTs will be required to provide enough data for the user to determine if the output matches the input. The preferred approach will be in form of xml files that can be diffed with the input xml (i.e. current CVT) Another approach will be some form of report that the user can check against the input (i.e. similar to the way regchk worked).

  "This component will be installed in the <xref linkend="acr:DESK"/> and will link to the other installed documents. If this component is viewed outside of the  <xref linkend="acr:DESK"/>, the links within this document may not be operational."

   <restricted-domain-section type="include" domain1="DDD">
   If this document is viewed outside of the <xref linkend="acr:DESK"/>", external document links may not be operational.
   </restricted-domain-section>

  find . -iname '*.xml' -o -iname '*.mk' -o ... | xargs svn ps svn:eol-style LF

  for f in $(find . -type f); do echo $f $(svn pg svn:eol-style $f); done | grep native

  John found a problem with the Linux vs Cygwin GCC versions for arm(arm-eabi-gcc-7.3.0).
  Cygwin is version 7.3.0-2
  Linux is version  7.3.0-1
  This is a problem because the .comment section of an ELF file contains the compiler version string.  I have periodically verified that all kernel binaries generated on Linux and Cygwin for each architecture are identical.  I hadn't noticed the problem with the arm binaries previously because the kernel linker script discards the .comment section.
  There is no record in SCM for a "-2" version of GCC.  There was a migration from "building from scripts on the ftp server" to "building from scripts captured in scm" in December of 2020.  The Cygwin ARM GCC was created in Oct 2018, the linux ARM GCC created in "December 2020" (based on the scripts from the ftp server).  I.e., the Cygwin "-2" version predates the Linux "-1" version.  Presumably this means someone locally built a "-2" and didn't update the scripts on the ftp server.
  This means I have no idea what build options were used for the currently released Cygwin ARM GCC compiler. I am inclined to release the ARM compiler for both Cygwin and Linux using the "current build scripts".  The compilers will get version 7.3.0-4 (the currently "latest" version).  At this point I have no reason to believe that the binaries generated by the resulting compilers will be any different (sans versioning information) between the "-2" and (proposed) "-4" compilers.
  Unless I hear some objections by COB 1/11/2022 that is what I'll do: The only alternative that I can think of is to release the Linux "-4" compiler with a version of "-2".  This leaves the Cygwin compiler unchanged (and I have good evidence the compilers would generate equivalent binaries).  I tried to rebuild the Cygwin arm gcc using the current build scripts (and changing the version be "-2"), but the resulting binaries are quite different.  It is possible this is due to different build paths but I don't like the idea that I can't rebuild the cygwin "-2" compiler and get identical binaries (which is not necessary, but desirable).

svn diff -r 19126:73729 --old=https://deos.ddci.com/scm/Deos/products/kernel/kernel/branches/mainline/tests/can/tpk008.can@19126 --new=https://deos.ddci.com/scm/Deos/products/kernel/kernel/branches/mainline/tests/can/tpk008.can@73729

 a. Current build utils GCC settings permit generation of mis-aligned accesses (missing -mno-unaligned-access).
 b. The kernel recommends a HW setting on ARM that causes mis-aligned accesses to generate an exception.

 a. The kernel recommends a H/W setting that causes some IT sequences to generate an exception.  ARM has deprecated these sequences.  There are two cases:
   x. IT sequences that are ill-defined.
   y. IT sequences that have poor performance.
 b. current build utils GCC settings generate "y", but (we believe) not "x".

 cd ~/
 ./disableBuild.sh bcronk@ddci.com
 cd ~/deos2cygwin/
 ./deos2cygwin.py
 rm ~/deos2cygwin_build_failed

 svn up --no-auth-cache --username=bcronk@ddci.com

Deos Team Meetings

Contents

Meeting Details

Agenda

Brown Bag Lunch and Training Topics

Previous

Twinkie Topics

Previous

Prior Meeting Minutes

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

Navigation menu

Page actions

Page actions

Personal tools

Navigation

Search

DDCI Tools & Resources

DDC-I private

Shared IP

Other

Tools