Date   

Re: Interesting talks at OSSE/Kernel Summit

Jan Kiszka
 

On 2017-11-07 18:40, Ben Hutchings wrote:
I attended several talks at OSSE and Kernel Summit in Prague that might
be interesting to CIP members. These weren't recorded but I made some
notes on them. I'll send my notes on each talk as a reply to this
message.

Ben.
Thanks for the valuable summaries, Ben!


Re: B@D run on Renesas board - issue

Binh Thanh. Nguyen <binh.nguyen.uw@...>
 

Hello Daniel, Robert,

Subject: RE: B@D run on Renesas board - issue

Hello Binh-san,

-----Original Message-----
From: Robert Marshall [mailto:robert.marshall@...]
Sent: Saturday, November 04, 2017 1:05 AM
To: Binh Thanh. Nguyen
Cc: Daniel Sangorrin; O365-Toru Oishi; Chris Paterson; Trung. Huynh;
cip-dev@...
Subject: Re: B@D run on Renesas board - issue

"Binh Thanh. Nguyen" <binh.nguyen.uw@...> writes:

Hello Daniel, Robert,

We are facing an issue when trying to run healthcheck using B@D on
Renesas board.
I would like to attach the log and the healthcheck script (we
modified the healthcheck from Daniel)

The boot action was passed, but after that, look like LAVA cannot
send command to Board, only send "#" (it supposed to be "uname").
I wonder if you met same issue before?
And if possible, please give us any hints you may have for debugging this
issue!

Best regards,
Binh Nguyen
Thanh

Sorry for the delay in responding!

That test is missing a deploy section (all commented out) are you
trying to make the test too minimal? LAVA tends to swallow output if
it is what is expected.

Robert
As Robert said, please do not comment out the deploy section. LAVA does not
just deploy the binaries as they are, it also copies some scripts (LAVA Test
shell) into the ramdisk (or network filesystem).
# LAVA does not use scp (or a serial protocol) to copy them into the target

For deploying you need a PDU (remote power switch). If you don't have one
you need to buy one and then add the corresponding commands.
# Note: I use an IP Power 9258 remote PDU.
# Note: do not think you can get around without a PDU*
Thank you for your feedback.
We are now purchasing the PDU.


Thanks,
Daniel

*There are ways to do it but they have limitations
https://validation.linaro.org/static/docs/v2/dispatcher-design.html#primary-
connection



Best regards,
Binh Nguyen


Kselftest use-cases - Shuah Khan

Ben Hutchings <ben.hutchings@...>
 

## Kselftest use-cases - Shuah Khan

[Description](https://osseu17.sched.com/event/CnFp/)

kselftest is the kernel developer regression test suite.  It is
written by kernel developers and users.  It is used by developers,
users, automated test infrastructure (kernel-ci.org, 0-day test
robot).

How to run tests:

* `make --silent kselftest` - run all default targets
  (`TARGETS` in `tools/testing/selftests/Makefile`).
* `make --silent TARGETS=timers kselftest` - run all
  non-destructive tests in `tools/testing/selftests/timers`
* `make --silent -C tools/testing/selftests/timers run_tests`
  - same

Set `O=dir` for an out-of-tree build.  (But cureently this
may require a `.config` file in the source directory.)

Set `quicktest=1` to exclude time-consuming tests.

kselftest outputs a summary of results (since 4.14) following
TAP (Test Anything Protocol).

The output of individual tests can be found in `/tmp` (currently),
but it should be changed to allow specifying directory.

It is possible to run latest selftests on older kernels, but there
will be some failures due to missing features.  Ideally missing
dependencies result in a "skip" result but some maintainers aren't
happy to support that.  One reason is that if a feature is broken so
badly it isn't detected, tests may be skipped rather than failed.

Some tests apparently check for dependencies in a kernel config file.
(It wasn't clear to me where they look for it.)

Tips and hints:

* Use the `--silent` option to suppress make output
* Some tests need to run as root
* Beware that some tests are disruptive

More information:

* [Documentation/dev-tools/kselftest.rst](https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html)
* [Blog entries](https://blogs.s-osg.org/author/shuahkh/)


--
Ben Hutchings
Software Developer, Codethink Ltd.


Improve Regression Tracking - Thorsten Leemhuis

Ben Hutchings <ben.hutchings@...>
 

## Improve Regression Tracking - Thorsten Leemhuis

[Description](https://osseu17.sched.com/event/CnFn/)

Thorsten has started tracking regressions in the kernel, in his spare
time.  He is not a programmer but a journalist (for c't) and community
manager.  He started doing this because Linus said he would like to
see someone do the job which Rafael Wysocki used to.

He expected it to be hard and frustrating, and it's even worse than that!
He needs to search through LKML, subsystem MLs, multiple Bugzillas.
It's very time consuming and he's still missing a lot of regressions.

Discussion of a single issue might change forum and it's not obvious
so he doesn't see that.  An issue might get quietly resolved by commit
without any message to a bug tracker.

He requested people to use a regression ID (which he assigns) and put
it in discussions and commit messages.  This hasn't happened (yet).
Someone suggested to make wider use of `[REGRESSION]` for reports
of recent regressions.  (Both of the above should be added to in-tree
documentation.)

Someone suggested to add another mailing list specifically for
regression reports, that may be cc'd(?) along with specific ML.

The upstream bug reporting process differs a lot across subsystems -
frustrating for distribution maintainers forwarding reports.  It is
also hard to see current regression status of the next stable release
when considering whether to update the kernel package.

Regression tracking is also needed for the "long tail" of bugs that
don't get reported so quickly (within 1 or 2 release cycles).  This
will require a team of people, not just one.

There needs to be some kind of database to collect information, if
only references to discussions elsewhere.  Rafael used to create
tracking bugs on <https://bugzilla.kernel.org>.  Thorsten is using
a spreadsheet.


--
Ben Hutchings
Software Developer, Codethink Ltd.


Detecting Performance Regressions in the Linux Kernel - Jan Kara

Ben Hutchings <ben.hutchings@...>
 

## Detecting Performance Regressions in the Linux Kernel - Jan Kara

[Description](https://osseu17.sched.com/event/BxIY/)

SUSE runs performance tests on a "grid" of different machines (10 x86,
1 ARM).  The x86 machines have a wide range of CPUs, memory size,
storage performance.  There are two back-to-back connected pairs for
network tests.

Other instances of the same models are available for debugging.

### Software used

"Marvin" is their framework for deploying, scheduling tests, bisecting.

"MMTests" is a framework for benchmarks - parses results and generates
comparisons - <https://github.com/gormanm/mmtests>.

CPU benchmarks: hackbench. libmicro, kernel page alloc benchmark (with
special module), PFT, SPECcpu2016, and others,

IO benchmarks: Iozone, Bonnie, Postmark, Reaim, Dbench4.  These are
run for all supported filesystems (ext3, ext4, xfs, btrfs) and
different RAID and non-RAID configurations.

Network benchmarks: sockperf, netperf, netpipe, siege.  These are run
over loopback and 10 gigabit Ethernet using Unix domain sockets (where
applicable), TCP, and UDP.  siege doesn't scale well so will be
replaced.

Complex benchmarks: kernbench, SPECjvm, Pgebcnh, sqlite insertion,
Postgres & MariaDB OLTP, ...

### How to detect performance changes?

Comparing a single benchmark result from each version is no good -
there is often significant variance in results.  It is necessary to
take multiple measurements, calculate average and s.d.

Caches and other features for increasing performance involve
prediction, which creates strong statistical dependencies.
Some statistical tests assume samples come from a normal
distribution, but performance results often don't.

It is sometimes possible to use Welch's T-test for significance of a
difference, but it is often necessary to plot a graph to understand
how the performance distribution is different - it can be due to
small numbers of outliers.

Some benchmarks take multiple (but not enough) results and average
them internally.  Ideally a benchmark framework will get all the
results and do its own statistical analysis.  For this reason, MMTests
uses modified versions of some benchmarks.

### Reducing variance in benchmarks

Filesystems: create from scratch each time

Scheduling: bind tasks to specific NUMA nodes; disable background
services; reboot before starting

It's generally not possible to control memory layout (which affects
cache performance) or interrupt timing.

### Benchmarks are buggy

* Setup can take most of the time
* Averages are not always calculated correctly
* Output is sometimes not flushed at exit, causing it to be truncated

--
Ben Hutchings
Software Developer, Codethink Ltd.


Automating Open Source License Compliance - Kate Stewart

Ben Hutchings <ben.hutchings@...>
 

## Automating Open Source License Compliance - Kate Stewart

[Description](https://osseu17.sched.com/event/BxI3/)

A product distribution may need to include copyright statements,
licence statements, disclaimers.

Why is this a problem?  Open source projects are changing quickly,
bringing in more copyrights and licenses.  Sometimes a project's
license doesn't actually apply to every source file.

Different sponsoring organisations and distributions have different
policies for which licenses they accept and how they're recorded.
Language specific package repositories also have their own standards
for recording licenses.

Wish lists for automation:

* Developers want a simple concise way to mark source files with
  license, checked at build time
* Open Source Offices want accurate license summary for third party
  software, and their own.  She referred to "Trusted Upstream
  Processes" but didn't expand on that.

SPDX (Software Package Data eXchange) provides standard ways to
identify licenses, to tag source files and to summarise this
information in a manifest.  Common OSS licenses are assigned short
names; custom licenses are also supported.

SPDX license identifiers supported by Debian (DEP-5), and other
distributions and organisations considering adopting them.  U-Boot
uses them, Linux is starting to use them, Eclipse Package Manager(?)
will start soon.

"Open Government Partnership" created a best practices template
that includes use of SPDX license identifiers.

An SPDX v2.1 document has metadata for itself, each package covered,
each source file included in packages, and any "snippets" (parts of
a source file) with a different license.

Various tooling is needed and available.  Open source tools include
FOSSology, ScanCode, SPDXTools; more are listed at
<https://wiki.debian.org/CopyrightReviewTools>.  Proprietary tools
are available from Wind River, Black Duck, others.

How accurate are the scanning tools?  All are based partly on
heuristics.  She recomends testing them against a known set of source
files.

She mentioned some other types of tools, but I wasn't clear on what
they do.

The OpenChain project documents the process of license compliance(?),
which is useful for a supply chain.

Missing pieces:

* Trusted SPDX importers (for reviewed documents?)
* CI/CD build tool integration (check for tags at build time?)
* Curated real world examples
* End-to-end case studies using SPDX documents

--
Ben Hutchings
Software Developer, Codethink Ltd.


Interesting talks at OSSE/Kernel Summit

Ben Hutchings <ben.hutchings@...>
 

I attended several talks at OSSE and Kernel Summit in Prague that might
be interesting to CIP members. These weren't recorded but I made some
notes on them. I'll send my notes on each talk as a reply to this
message.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: Next CIP kernel: CIP - Debian alignment

Ben Hutchings <ben.hutchings@...>
 

On Tue, 2017-11-07 at 17:41 +0100, Agustin Benito Bethencourt wrote:
Hi Ben,

one of the recurrent questions at ELCE, that also was done at the TSC 
meeting is when will we pick the following kernel. The following 
variables apply to this decision:

* Some time ago, you made clear that, in order to keep the maintenance 
effort affordable, we should not pick kernels in tight cadence. TSC 
agreed to assume that advice.

* Since we have agreed to base CIP-Core in Debian sources and during 
ELCE 2017 we picked Debian as the default distro for CIP, it seems a 
natural choice to pick LTS kernels that are also selected by Debian as 
preferred choice.

Based on your understanding about the Debian project:

- When do you expect the next Debian kernel to be selected?
I take it that you mean the kernel for the next Debian stable release
(10/buster).

Debian is aiming to release roughly every 2 years. The last freeze was
delayed at my request, to allow inclusion of the LTS kernel selected at
the end of 2016, which was 4.9. So I would expect that the next Debian
release will include the LTS kernel selected at the end of 2018.

- Based on that answer, which ones are the best candidates?
The kernel release cycle is 9-10 weeks, so I would expect the 2018 LTS
kernel to be 4.19 or 4.20/5.0. (I think I heard Linus say 4.19 will be
followed by 5.0, the same way 3.19 was followed by 4.0.)

- Do you expect LTS and Debian selection to be aligned?
Absolutely.

- If not, if this something you would like to see happening?
- If yes, how can CIP help to make it happen?
I don't think CIP needs to do anything to encourage this.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: [PATCH 0/2] Remove firmware files from CIP kernel

Jan Kiszka
 

On 2017-11-07 16:28, Jan Kiszka wrote:
On 2017-11-07 16:16, Ben Hutchings wrote:
On Mon, 2017-11-06 at 15:33 +0100, Jan Kiszka wrote:
This backports the removal of in-kernel firmware files that upstream
did for 4.14.

Besides the issue mentioned in the upstream commit, the primary
motivation for us are undefined licenses (according to WHENCE) for a 
couple of the files. This creates entries in automated license
analysis
and, depending on the conclusion drawn from them, can mean further
activities like kernel source package surgeries. For similar reasons,
Debian removed those files long ago as well.
Right, this seems like a reasonable change.

I couldn't apply your patch 1, apparently because some of the deleted
ihex files have lines longer than the SMTP line limit, but I believe
I've ended up with an equivalent commit.
Yeah, I was afraid of that to happen (and had to use --no-validate to
get the patch out). Good that such a file is gone now.

I'll cross-check, but the conflict I had to resolve was only in the
top-level Makefile, and that was trivial.
It's identical.

Jan


Y2038 meeting at ELCE

Ben Hutchings <ben.hutchings@...>
 

There was a meeting at ELCE about the status and development of Y2038-
safe APIs in Linux and GNU libc. This included several developers from
members of CIP, plus Arnd Bergmann, Mark Brown and Albert Aribaud.
Below are my notes from the meeting.

Ben.

## Kernel

Arnd Bergmann started working on Y2038 about 6 years ago, initially
looking at file-systems and VFS. File-systems are mostly ready but VFS
hasn't been switched over yet.

The largest missing piece is the syscall interface. "We know what we
want to do." There was a complete patch set for an older version, but
it has not been completely rebased onto current mainline. On 32-bit
systems about 35 syscalls use 32-bit time, but half of those are
already obsolete. Something like 22 new syscalls will be needed.

Network, sound, media, key management, input have not been dealt with
yet. Patches are available for some of these but they can be invasive
and hard to review. This is a low priority for some subsystem
maintainers.

About 100 device drivers need changes, ranging from an obvious 1 line
change to a week's work.

About 10% of the changes are needed for Y2038 safety on both 32-bit
and 64-bit architectures, the rest only for 32-bit.

Arnd wants to include a kconfig option to disable the 32-bit time
APIs, so that any remaining users are easy to detect.

## GNU libc

Albert Aribaut talked about the status of glibc. It will need to
support both 32-bit `time_t` and 64-bit `time_t` independently of the
kernel. A draft specification for this exists at
<https://sourceware.org/glibc/wiki/Y2038ProofnessDesign>. About 60
APIs are affected, using `time_t` or derived type.

Ideally source can be rebuilt to use 64-bit `time_t` just by
defining the feature macro to enable it.

The implementation is not complete, partly because syscalls haven't
yet been defined.

## Other C libraries

Arnd says some other C libraries will support 64-bit `time_t` but as a
build-time option. I.e. libc and all applications must be built for
either 32-bit or 64-bit `time_t`.

## Application compatibility issues

If Unix timestamps are used in binary file formats or network
protocols, these will need a new version. In some cases switching to
unsigned 32-bit values is easy and will work for long enough.

If `time_t` is used in library APIs then an ABI change is required.
cppcheck(?) can find instances of this.

Some libraries may use their own time types, so changing `time_t`
won't be an ABI change but they will need to be updated anyway.

Printing a value of type `time_t` with `printf()` and similar
functions requires casting as there's no format specifier for it. It
will be necessary to cast to `long long`, whereas previously `long`
would work.

The sparse static checker is supposed to be able to check for
truncating conversions of `time_t`.

## Ongoing work in kernel and glibc

A few people are working part time on this. Kernel patches are 60%
done after 5 years, GNU libc about 75% (but only some of those changes
have been applied). More people may be needed to speed this up and get
it finished.

The kernel side is coordinated through the y2038 mailing list:
<https://lists.linaro.org/mailman/listinfo/y2038>. Patches are all
sent to this mailing list. There is currently no git tree collecting
them all.

Help is wanted to:

* Update device drivers
* Review sound patches
* Collect patches into single git tree

The glibc side is coordinated through the general development mailing
list: <https://www.gnu.org/software/libc/involved.html>,
<https://sourceware.org/ml/libc-alpha/>.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Next CIP kernel: CIP - Debian alignment

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi Ben,

one of the recurrent questions at ELCE, that also was done at the TSC meeting is when will we pick the following kernel. The following variables apply to this decision:

* Some time ago, you made clear that, in order to keep the maintenance effort affordable, we should not pick kernels in tight cadence. TSC agreed to assume that advice.

* Since we have agreed to base CIP-Core in Debian sources and during ELCE 2017 we picked Debian as the default distro for CIP, it seems a natural choice to pick LTS kernels that are also selected by Debian as preferred choice.

Based on your understanding about the Debian project:

- When do you expect the next Debian kernel to be selected?
- Based on that answer, which ones are the best candidates?
- Do you expect LTS and Debian selection to be aligned?
- If not, if this something you would like to see happening?
- If yes, how can CIP help to make it happen?

Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...


Re: [PATCH 0/2] Remove firmware files from CIP kernel

Jan Kiszka
 

On 2017-11-07 16:16, Ben Hutchings wrote:
On Mon, 2017-11-06 at 15:33 +0100, Jan Kiszka wrote:
This backports the removal of in-kernel firmware files that upstream
did for 4.14.

Besides the issue mentioned in the upstream commit, the primary
motivation for us are undefined licenses (according to WHENCE) for a 
couple of the files. This creates entries in automated license
analysis
and, depending on the conclusion drawn from them, can mean further
activities like kernel source package surgeries. For similar reasons,
Debian removed those files long ago as well.
Right, this seems like a reasonable change.

I couldn't apply your patch 1, apparently because some of the deleted
ihex files have lines longer than the SMTP line limit, but I believe
I've ended up with an equivalent commit.
Yeah, I was afraid of that to happen (and had to use --no-validate to
get the patch out). Good that such a file is gone now.

I'll cross-check, but the conflict I had to resolve was only in the
top-level Makefile, and that was trivial.

Thanks,
Jan


Re: [PATCH 0/2] Remove firmware files from CIP kernel

Ben Hutchings <ben.hutchings@...>
 

On Mon, 2017-11-06 at 15:33 +0100, Jan Kiszka wrote:
This backports the removal of in-kernel firmware files that upstream
did for 4.14.

Besides the issue mentioned in the upstream commit, the primary
motivation for us are undefined licenses (according to WHENCE) for a 
couple of the files. This creates entries in automated license
analysis
and, depending on the conclusion drawn from them, can mean further
activities like kernel source package surgeries. For similar reasons,
Debian removed those files long ago as well.
Right, this seems like a reasonable change.

I couldn't apply your patch 1, apparently because some of the deleted
ihex files have lines longer than the SMTP line limit, but I believe
I've ended up with an equivalent commit.

Ben.

Jan

Greg Kroah-Hartman (1):
  firmware: delete in-kernel firmware

Markus Trippelsdorf (1):
  firmware: Restore support for built-in firmware

 Makefile                                    |    14 -
 drivers/base/Kconfig                        |     5 +-
 firmware/3com/typhoon.bin.ihex              |  2819 -----
 firmware/Makefile                           |   182 +-
 firmware/README.AddingFirmware              |    45 -
 firmware/WHENCE                             |   854 --
 firmware/acenic/tg1.bin.ihex                |  4573 --------
 firmware/acenic/tg2.bin.ihex                |  4844 --------
 firmware/adaptec/starfire_rx.bin.ihex       |    53 -
 firmware/adaptec/starfire_tx.bin.ihex       |    53 -
 firmware/advansys/3550.bin.ihex             |   317 -
 firmware/advansys/38C0800.bin.ihex          |   336 -
 firmware/advansys/38C1600.bin.ihex          |   398 -
 firmware/advansys/mcode.bin.ihex            |   147 -
 firmware/atmsar11.HEX                       |   204 -
 firmware/av7110/Boot.S                      |   109 -
 firmware/av7110/bootcode.bin.ihex           |    15 -
 firmware/bnx2/bnx2-mips-06-6.2.1.fw.ihex    |  5818 ----------
 firmware/bnx2/bnx2-mips-09-6.2.1a.fw.ihex   |  6512 -----------
 firmware/bnx2/bnx2-rv2p-06-6.0.15.fw.ihex   |   366 -
 firmware/bnx2/bnx2-rv2p-09-6.0.17.fw.ihex   |   392 -
 firmware/bnx2/bnx2-rv2p-09ax-6.0.17.fw.ihex |   425 -
 firmware/bnx2x/bnx2x-e1-6.2.9.0.fw.ihex     |  9484 ----------------
 firmware/bnx2x/bnx2x-e1h-6.2.9.0.fw.ihex    | 13192 ----------------
------
 firmware/bnx2x/bnx2x-e2-6.2.9.0.fw.ihex     | 15473 ----------------
----------
 firmware/cis/.gitignore                     |     1 -
 firmware/cis/3CCFEM556.cis.ihex             |    13 -
 firmware/cis/3CXEM556.cis.ihex              |    13 -
 firmware/cis/COMpad2.cis.ihex               |    11 -
 firmware/cis/COMpad4.cis.ihex               |     9 -
 firmware/cis/DP83903.cis.ihex               |    14 -
 firmware/cis/LA-PCM.cis.ihex                |    20 -
 firmware/cis/MT5634ZLX.cis.ihex             |    11 -
 firmware/cis/NE2K.cis.ihex                  |     8 -
 firmware/cis/PCMLM28.cis.ihex               |    18 -
 firmware/cis/PE-200.cis.ihex                |     9 -
 firmware/cis/PE520.cis.ihex                 |     9 -
 firmware/cis/RS-COM-2P.cis.ihex             |    10 -
 firmware/cis/SW_555_SER.cis.ihex            |    12 -
 firmware/cis/SW_7xx_SER.cis.ihex            |    13 -
 firmware/cis/SW_8xx_SER.cis.ihex            |    13 -
 firmware/cis/tamarack.cis.ihex              |    10 -
 firmware/cpia2/stv0672_vp4.bin.ihex         |    73 -
 firmware/cxgb3/ael2005_opt_edc.bin.ihex     |    69 -
 firmware/cxgb3/ael2005_twx_edc.bin.ihex     |    93 -
 firmware/cxgb3/ael2020_twx_edc.bin.ihex     |   100 -
 firmware/cxgb3/t3b_psram-1.1.0.bin.ihex     |   162 -
 firmware/cxgb3/t3c_psram-1.1.0.bin.ihex     |   162 -
 firmware/dsp56k/bootstrap.asm               |    98 -
 firmware/dsp56k/bootstrap.bin.ihex          |    26 -
 firmware/e100/d101m_ucode.bin.ihex          |    38 -
 firmware/e100/d101s_ucode.bin.ihex          |    38 -
 firmware/e100/d102e_ucode.bin.ihex          |    38 -
 firmware/edgeport/boot.H16                  |    29 -
 firmware/edgeport/boot2.H16                 |    28 -
 firmware/edgeport/down.H16                  |    29 -
 firmware/edgeport/down2.H16                 |    29 -
 firmware/edgeport/down3.bin.ihex            |   815 --
 firmware/emi26/bitstream.HEX                |  4391 --------
 firmware/emi26/firmware.HEX                 |  1261 ---
 firmware/emi26/loader.HEX                   |   116 -
 firmware/emi62/bitstream.HEX                |  6107 ----------
 firmware/emi62/loader.HEX                   |   107 -
 firmware/emi62/midi.HEX                     |  1266 ---
 firmware/emi62/spdif.HEX                    |  1257 ---
 firmware/ess/maestro3_assp_kernel.fw.ihex   |   120 -
 firmware/ess/maestro3_assp_minisrc.fw.ihex  |    51 -
 firmware/ihex2fw.c                          |   281 -
 firmware/kaweth/new_code.bin.ihex           |   206 -
 firmware/kaweth/new_code_fix.bin.ihex       |    40 -
 firmware/kaweth/trigger_code.bin.ihex       |    13 -
 firmware/kaweth/trigger_code_fix.bin.ihex   |     3 -
 firmware/keyspan/mpr.HEX                    |   104 -
 firmware/keyspan/usa18x.HEX                 |   141 -
 firmware/keyspan/usa19.HEX                  |   101 -
 firmware/keyspan/usa19qi.HEX                |   101 -
 firmware/keyspan/usa19qw.HEX                |   142 -
 firmware/keyspan/usa19w.HEX                 |   141 -
 firmware/keyspan/usa28.HEX                  |   148 -
 firmware/keyspan/usa28x.HEX                 |   141 -
 firmware/keyspan/usa28xa.HEX                |   141 -
 firmware/keyspan/usa28xb.HEX                |   142 -
 firmware/keyspan/usa49w.HEX                 |   145 -
 firmware/keyspan/usa49wlc.HEX               |   153 -
 firmware/keyspan_pda/keyspan_pda.HEX        |    83 -
 firmware/keyspan_pda/keyspan_pda.S          |  1124 --
 firmware/keyspan_pda/xircom_pgs.HEX         |    87 -
 firmware/keyspan_pda/xircom_pgs.S           |  1192 --
 firmware/korg/k1212.dsp.ihex                |   987 --
 firmware/matrox/g200_warp.H16               |    28 -
 firmware/matrox/g400_warp.H16               |    44 -
 firmware/mts_cdma.fw.ihex                   |   867 --
 firmware/mts_edge.fw.ihex                   |   881 --
 firmware/mts_gsm.fw.ihex                    |   867 --
 firmware/myricom/lanai.bin.ihex             |  4771 --------
 firmware/ositech/Xilinx7OD.bin.ihex         |   177 -
 firmware/qlogic/1040.bin.ihex               |  2111 ----
 firmware/qlogic/12160.bin.ihex              |  1771 ---
 firmware/qlogic/1280.bin.ihex               |  2008 ----
 firmware/qlogic/isp1000.bin.ihex            |  1158 --
 firmware/qlogic/sd7220.fw.ihex              |   513 -
 firmware/r128/r128_cce.bin.ihex             |   129 -
 firmware/radeon/R100_cp.bin.ihex            |   130 -
 firmware/radeon/R200_cp.bin.ihex            |   130 -
 firmware/radeon/R300_cp.bin.ihex            |   130 -
 firmware/radeon/R420_cp.bin.ihex            |   130 -
 firmware/radeon/R520_cp.bin.ihex            |   130 -
 firmware/radeon/R600_me.bin.ihex            |  1345 ---
 firmware/radeon/R600_pfp.bin.ihex           |   145 -
 firmware/radeon/RS600_cp.bin.ihex           |   130 -
 firmware/radeon/RS690_cp.bin.ihex           |   130 -
 firmware/radeon/RS780_me.bin.ihex           |  1345 ---
 firmware/radeon/RS780_pfp.bin.ihex          |   145 -
 firmware/radeon/RV610_me.bin.ihex           |  1345 ---
 firmware/radeon/RV610_pfp.bin.ihex          |   145 -
 firmware/radeon/RV620_me.bin.ihex           |  1345 ---
 firmware/radeon/RV620_pfp.bin.ihex          |   145 -
 firmware/radeon/RV630_me.bin.ihex           |  1345 ---
 firmware/radeon/RV630_pfp.bin.ihex          |   145 -
 firmware/radeon/RV635_me.bin.ihex           |  1345 ---
 firmware/radeon/RV635_pfp.bin.ihex          |   145 -
 firmware/radeon/RV670_me.bin.ihex           |  1345 ---
 firmware/radeon/RV670_pfp.bin.ihex          |   145 -
 firmware/radeon/RV710_me.bin.ihex           |   341 -
 firmware/radeon/RV710_pfp.bin.ihex          |   213 -
 firmware/radeon/RV730_me.bin.ihex           |   341 -
 firmware/radeon/RV730_pfp.bin.ihex          |   213 -
 firmware/radeon/RV770_me.bin.ihex           |   341 -
 firmware/radeon/RV770_pfp.bin.ihex          |   213 -
 firmware/sb16/alaw_main.csp.ihex            |    87 -
 firmware/sb16/ima_adpcm_capture.csp.ihex    |   121 -
 firmware/sb16/ima_adpcm_init.csp.ihex       |    70 -
 firmware/sb16/ima_adpcm_playback.csp.ihex   |   122 -
 firmware/sb16/mulaw_main.csp.ihex           |    84 -
 firmware/sun/cassini.bin.ihex               |   143 -
 firmware/tehuti/bdx.bin.ihex                |  2678 -----
 firmware/ti_3410.fw.ihex                    |   862 --
 firmware/ti_5052.fw.ihex                    |   862 --
 firmware/tigon/tg3.bin.ihex                 |   175 -
 firmware/tigon/tg3_tso.bin.ihex             |   446 -
 firmware/tigon/tg3_tso5.bin.ihex            |   252 -
 firmware/ttusb-budget/dspbootcode.bin.ihex  |   820 --
 firmware/vicam/firmware.H16                 |     7 -
 firmware/whiteheat.HEX                      |  1097 --
 firmware/whiteheat_loader.HEX               |   314 -
 firmware/whiteheat_loader_debug.HEX         |   403 -
 firmware/yam/1200.bin.ihex                  |   342 -
 firmware/yam/9600.bin.ihex                  |   342 -
 firmware/yamaha/ds1_ctrl.fw.ihex            |   769 --
 firmware/yamaha/ds1_dsp.fw.ihex             |     9 -
 firmware/yamaha/ds1e_ctrl.fw.ihex           |   769 --
 firmware/yamaha/yss225_registers.bin.ihex   |   998 --
 scripts/Makefile.fwinst                     |    70 -
 153 files changed, 5 insertions(+), 129107 deletions(-)
 delete mode 100644 firmware/3com/typhoon.bin.ihex
 delete mode 100644 firmware/README.AddingFirmware
 delete mode 100644 firmware/WHENCE
 delete mode 100644 firmware/acenic/tg1.bin.ihex
 delete mode 100644 firmware/acenic/tg2.bin.ihex
 delete mode 100644 firmware/adaptec/starfire_rx.bin.ihex
 delete mode 100644 firmware/adaptec/starfire_tx.bin.ihex
 delete mode 100644 firmware/advansys/3550.bin.ihex
 delete mode 100644 firmware/advansys/38C0800.bin.ihex
 delete mode 100644 firmware/advansys/38C1600.bin.ihex
 delete mode 100644 firmware/advansys/mcode.bin.ihex
 delete mode 100644 firmware/atmsar11.HEX
 delete mode 100644 firmware/av7110/Boot.S
 delete mode 100644 firmware/av7110/bootcode.bin.ihex
 delete mode 100644 firmware/bnx2/bnx2-mips-06-6.2.1.fw.ihex
 delete mode 100644 firmware/bnx2/bnx2-mips-09-6.2.1a.fw.ihex
 delete mode 100644 firmware/bnx2/bnx2-rv2p-06-6.0.15.fw.ihex
 delete mode 100644 firmware/bnx2/bnx2-rv2p-09-6.0.17.fw.ihex
 delete mode 100644 firmware/bnx2/bnx2-rv2p-09ax-6.0.17.fw.ihex
 delete mode 100644 firmware/bnx2x/bnx2x-e1-6.2.9.0.fw.ihex
 delete mode 100644 firmware/bnx2x/bnx2x-e1h-6.2.9.0.fw.ihex
 delete mode 100644 firmware/bnx2x/bnx2x-e2-6.2.9.0.fw.ihex
 delete mode 100644 firmware/cis/.gitignore
 delete mode 100644 firmware/cis/3CCFEM556.cis.ihex
 delete mode 100644 firmware/cis/3CXEM556.cis.ihex
 delete mode 100644 firmware/cis/COMpad2.cis.ihex
 delete mode 100644 firmware/cis/COMpad4.cis.ihex
 delete mode 100644 firmware/cis/DP83903.cis.ihex
 delete mode 100644 firmware/cis/LA-PCM.cis.ihex
 delete mode 100644 firmware/cis/MT5634ZLX.cis.ihex
 delete mode 100644 firmware/cis/NE2K.cis.ihex
 delete mode 100644 firmware/cis/PCMLM28.cis.ihex
 delete mode 100644 firmware/cis/PE-200.cis.ihex
 delete mode 100644 firmware/cis/PE520.cis.ihex
 delete mode 100644 firmware/cis/RS-COM-2P.cis.ihex
 delete mode 100644 firmware/cis/SW_555_SER.cis.ihex
 delete mode 100644 firmware/cis/SW_7xx_SER.cis.ihex
 delete mode 100644 firmware/cis/SW_8xx_SER.cis.ihex
 delete mode 100644 firmware/cis/tamarack.cis.ihex
 delete mode 100644 firmware/cpia2/stv0672_vp4.bin.ihex
 delete mode 100644 firmware/cxgb3/ael2005_opt_edc.bin.ihex
 delete mode 100644 firmware/cxgb3/ael2005_twx_edc.bin.ihex
 delete mode 100644 firmware/cxgb3/ael2020_twx_edc.bin.ihex
 delete mode 100644 firmware/cxgb3/t3b_psram-1.1.0.bin.ihex
 delete mode 100644 firmware/cxgb3/t3c_psram-1.1.0.bin.ihex
 delete mode 100644 firmware/dsp56k/bootstrap.asm
 delete mode 100644 firmware/dsp56k/bootstrap.bin.ihex
 delete mode 100644 firmware/e100/d101m_ucode.bin.ihex
 delete mode 100644 firmware/e100/d101s_ucode.bin.ihex
 delete mode 100644 firmware/e100/d102e_ucode.bin.ihex
 delete mode 100644 firmware/edgeport/boot.H16
 delete mode 100644 firmware/edgeport/boot2.H16
 delete mode 100644 firmware/edgeport/down.H16
 delete mode 100644 firmware/edgeport/down2.H16
 delete mode 100644 firmware/edgeport/down3.bin.ihex
 delete mode 100644 firmware/emi26/bitstream.HEX
 delete mode 100644 firmware/emi26/firmware.HEX
 delete mode 100644 firmware/emi26/loader.HEX
 delete mode 100644 firmware/emi62/bitstream.HEX
 delete mode 100644 firmware/emi62/loader.HEX
 delete mode 100644 firmware/emi62/midi.HEX
 delete mode 100644 firmware/emi62/spdif.HEX
 delete mode 100644 firmware/ess/maestro3_assp_kernel.fw.ihex
 delete mode 100644 firmware/ess/maestro3_assp_minisrc.fw.ihex
 delete mode 100644 firmware/ihex2fw.c
 delete mode 100644 firmware/kaweth/new_code.bin.ihex
 delete mode 100644 firmware/kaweth/new_code_fix.bin.ihex
 delete mode 100644 firmware/kaweth/trigger_code.bin.ihex
 delete mode 100644 firmware/kaweth/trigger_code_fix.bin.ihex
 delete mode 100644 firmware/keyspan/mpr.HEX
 delete mode 100644 firmware/keyspan/usa18x.HEX
 delete mode 100644 firmware/keyspan/usa19.HEX
 delete mode 100644 firmware/keyspan/usa19qi.HEX
 delete mode 100644 firmware/keyspan/usa19qw.HEX
 delete mode 100644 firmware/keyspan/usa19w.HEX
 delete mode 100644 firmware/keyspan/usa28.HEX
 delete mode 100644 firmware/keyspan/usa28x.HEX
 delete mode 100644 firmware/keyspan/usa28xa.HEX
 delete mode 100644 firmware/keyspan/usa28xb.HEX
 delete mode 100644 firmware/keyspan/usa49w.HEX
 delete mode 100644 firmware/keyspan/usa49wlc.HEX
 delete mode 100644 firmware/keyspan_pda/keyspan_pda.HEX
 delete mode 100644 firmware/keyspan_pda/keyspan_pda.S
 delete mode 100644 firmware/keyspan_pda/xircom_pgs.HEX
 delete mode 100644 firmware/keyspan_pda/xircom_pgs.S
 delete mode 100644 firmware/korg/k1212.dsp.ihex
 delete mode 100644 firmware/matrox/g200_warp.H16
 delete mode 100644 firmware/matrox/g400_warp.H16
 delete mode 100644 firmware/mts_cdma.fw.ihex
 delete mode 100644 firmware/mts_edge.fw.ihex
 delete mode 100644 firmware/mts_gsm.fw.ihex
 delete mode 100644 firmware/myricom/lanai.bin.ihex
 delete mode 100644 firmware/ositech/Xilinx7OD.bin.ihex
 delete mode 100644 firmware/qlogic/1040.bin.ihex
 delete mode 100644 firmware/qlogic/12160.bin.ihex
 delete mode 100644 firmware/qlogic/1280.bin.ihex
 delete mode 100644 firmware/qlogic/isp1000.bin.ihex
 delete mode 100644 firmware/qlogic/sd7220.fw.ihex
 delete mode 100644 firmware/r128/r128_cce.bin.ihex
 delete mode 100644 firmware/radeon/R100_cp.bin.ihex
 delete mode 100644 firmware/radeon/R200_cp.bin.ihex
 delete mode 100644 firmware/radeon/R300_cp.bin.ihex
 delete mode 100644 firmware/radeon/R420_cp.bin.ihex
 delete mode 100644 firmware/radeon/R520_cp.bin.ihex
 delete mode 100644 firmware/radeon/R600_me.bin.ihex
 delete mode 100644 firmware/radeon/R600_pfp.bin.ihex
 delete mode 100644 firmware/radeon/RS600_cp.bin.ihex
 delete mode 100644 firmware/radeon/RS690_cp.bin.ihex
 delete mode 100644 firmware/radeon/RS780_me.bin.ihex
 delete mode 100644 firmware/radeon/RS780_pfp.bin.ihex
 delete mode 100644 firmware/radeon/RV610_me.bin.ihex
 delete mode 100644 firmware/radeon/RV610_pfp.bin.ihex
 delete mode 100644 firmware/radeon/RV620_me.bin.ihex
 delete mode 100644 firmware/radeon/RV620_pfp.bin.ihex
 delete mode 100644 firmware/radeon/RV630_me.bin.ihex
 delete mode 100644 firmware/radeon/RV630_pfp.bin.ihex
 delete mode 100644 firmware/radeon/RV635_me.bin.ihex
 delete mode 100644 firmware/radeon/RV635_pfp.bin.ihex
 delete mode 100644 firmware/radeon/RV670_me.bin.ihex
 delete mode 100644 firmware/radeon/RV670_pfp.bin.ihex
 delete mode 100644 firmware/radeon/RV710_me.bin.ihex
 delete mode 100644 firmware/radeon/RV710_pfp.bin.ihex
 delete mode 100644 firmware/radeon/RV730_me.bin.ihex
 delete mode 100644 firmware/radeon/RV730_pfp.bin.ihex
 delete mode 100644 firmware/radeon/RV770_me.bin.ihex
 delete mode 100644 firmware/radeon/RV770_pfp.bin.ihex
 delete mode 100644 firmware/sb16/alaw_main.csp.ihex
 delete mode 100644 firmware/sb16/ima_adpcm_capture.csp.ihex
 delete mode 100644 firmware/sb16/ima_adpcm_init.csp.ihex
 delete mode 100644 firmware/sb16/ima_adpcm_playback.csp.ihex
 delete mode 100644 firmware/sb16/mulaw_main.csp.ihex
 delete mode 100644 firmware/sun/cassini.bin.ihex
 delete mode 100644 firmware/tehuti/bdx.bin.ihex
 delete mode 100644 firmware/ti_3410.fw.ihex
 delete mode 100644 firmware/ti_5052.fw.ihex
 delete mode 100644 firmware/tigon/tg3.bin.ihex
 delete mode 100644 firmware/tigon/tg3_tso.bin.ihex
 delete mode 100644 firmware/tigon/tg3_tso5.bin.ihex
 delete mode 100644 firmware/ttusb-budget/dspbootcode.bin.ihex
 delete mode 100644 firmware/vicam/firmware.H16
 delete mode 100644 firmware/whiteheat.HEX
 delete mode 100644 firmware/whiteheat_loader.HEX
 delete mode 100644 firmware/whiteheat_loader_debug.HEX
 delete mode 100644 firmware/yam/1200.bin.ihex
 delete mode 100644 firmware/yam/9600.bin.ihex
 delete mode 100644 firmware/yamaha/ds1_ctrl.fw.ihex
 delete mode 100644 firmware/yamaha/ds1_dsp.fw.ihex
 delete mode 100644 firmware/yamaha/ds1e_ctrl.fw.ihex
 delete mode 100644 firmware/yamaha/yss225_registers.bin.ihex
 delete mode 100644 scripts/Makefile.fwinst
--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: B@D network setup

Robert Marshall <robert.marshall@...>
 

Daniel Wagner <daniel.wagner@...> writes:

On 11/07/2017 01:09 PM, Robert Marshall wrote:
Robert, what is your take on this approach?
I think that first step sounds reasonable - all the network config IIRC
happens in the Vagrantfile apart from the suggested workthrough on the
wiki.
When I tried to build my own VM from scratch I failed at the config part
inside the VM. Though this is a while ago. Maybe I should just retry to
build the VM, though I would prefer not to do it. I workaround could be
to asign the VM my USB Ethernet interface... Need to check the docs :)
From my experience with network issues at ELCE I'd be inclined to just
comment out the

config.vm.network "public_network", use_dhcp_assigned_default_route: true

line. And the VM should build without problems, it only needs that line
for running a test on the beaglebone black

Robert


Re: B@D network setup

Daniel Wagner <daniel.wagner@...>
 

On 11/07/2017 01:09 PM, Robert Marshall wrote:
Robert, what is your take on this approach?
I think that first step sounds reasonable - all the network config IIRC
happens in the Vagrantfile apart from the suggested workthrough on the
wiki.
When I tried to build my own VM from scratch I failed at the config part
inside the VM. Though this is a while ago. Maybe I should just retry to
build the VM, though I would prefer not to do it. I workaround could be
to asign the VM my USB Ethernet interface... Need to check the docs :)

Thanks,
Daniel


Re: B@D network setup

Robert Marshall <robert.marshall@...>
 

Agustin/Daniel

Agustin Benito Bethencourt <agustin.benito@...> writes:

Hi,

On 07/11/17 09:47, Daniel Wagner wrote:
Hi Daniel,

On 11/07/2017 03:40 AM, Daniel Sangorrin wrote:
So my question is, couldn't we add additional network interface, e.g.
USB Ethernet adapter, and attach the device under test to this
interface? I don't know if Vagrant is offering such an option. In the
past I've done this with Qemu.
If your network is using the MAC address for authentication you could also
put the MAC address of your USB ethernet adapter into the Virtualbox
ethernet interface (adapter 2).
Unfortunately, we do have proper security in place :) The device needs
to do EAP and I don't think u-boot is able to this.

Having a dedicated network interface (maybe attached to a standalone
switch) has also the beauty that you have it complete under control what
is happening on the test network.
When designing B@D, we assumed the most simple network
configuration. Since the system is based on a VM, the network set up
is something that can be adapted. Looking at this assumption now, we
probably were optimistic. Yes it can be customised, but the complexity
might be high to expect a user to do it on her own.

Let's see how we can help. Probably the first step is clearly
documenting the network set up we currently have in B@D pointing at
the scripts responsible for such configuration. We will take decision
from that point.

Robert, what is your take on this approach?
I think that first step sounds reasonable - all the network config IIRC
happens in the Vagrantfile apart from the suggested workthrough on the
wiki.

Robert


Re: B@D network setup

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

On 07/11/17 09:47, Daniel Wagner wrote:
Hi Daniel,

On 11/07/2017 03:40 AM, Daniel Sangorrin wrote:
So my question is, couldn't we add additional network interface, e.g.
USB Ethernet adapter, and attach the device under test to this
interface? I don't know if Vagrant is offering such an option. In the
past I've done this with Qemu.
If your network is using the MAC address for authentication you could also
put the MAC address of your USB ethernet adapter into the Virtualbox
ethernet interface (adapter 2).
Unfortunately, we do have proper security in place :) The device needs
to do EAP and I don't think u-boot is able to this.

Having a dedicated network interface (maybe attached to a standalone
switch) has also the beauty that you have it complete under control what
is happening on the test network.
When designing B@D, we assumed the most simple network configuration. Since the system is based on a VM, the network set up is something that can be adapted. Looking at this assumption now, we probably were optimistic. Yes it can be customised, but the complexity might be high to expect a user to do it on her own.

Let's see how we can help. Probably the first step is clearly documenting the network set up we currently have in B@D pointing at the scripts responsible for such configuration. We will take decision from that point.

Robert, what is your take on this approach?



Thanks,
Daniel
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...


Re: B@D network setup

Daniel Wagner <daniel.wagner@...>
 

We've opened a ticket for this
https://gitlab.com/cip-project/cip-testing/testing/issues/169

so that we can investigate and you can keep track!
Excellent!

Thanks,
Daniel


Re: B@D network setup

Robert Marshall <robert.marshall@...>
 

Daniel,

Daniel Wagner <daniel.wagner@...> writes:

Hi Daniel,

On 11/07/2017 03:40 AM, Daniel Sangorrin wrote:
So my question is, couldn't we add additional network interface, e.g.
USB Ethernet adapter, and attach the device under test to this
interface? I don't know if Vagrant is offering such an option. In the
past I've done this with Qemu.
If your network is using the MAC address for authentication you could also
put the MAC address of your USB ethernet adapter into the Virtualbox
ethernet interface (adapter 2).
Unfortunately, we do have proper security in place :) The device needs
to do EAP and I don't think u-boot is able to this.

Having a dedicated network interface (maybe attached to a standalone
switch) has also the beauty that you have it complete under control what
is happening on the test network.
We've opened a ticket for this
https://gitlab.com/cip-project/cip-testing/testing/issues/169

so that we can investigate and you can keep track!

Robert


Re: B@D network setup

Daniel Wagner <daniel.wagner@...>
 

Hi Daniel,

On 11/07/2017 03:40 AM, Daniel Sangorrin wrote:
So my question is, couldn't we add additional network interface, e.g.
USB Ethernet adapter, and attach the device under test to this
interface? I don't know if Vagrant is offering such an option. In the
past I've done this with Qemu.
If your network is using the MAC address for authentication you could also
put the MAC address of your USB ethernet adapter into the Virtualbox
ethernet interface (adapter 2).
Unfortunately, we do have proper security in place :) The device needs
to do EAP and I don't think u-boot is able to this.

Having a dedicated network interface (maybe attached to a standalone
switch) has also the beauty that you have it complete under control what
is happening on the test network.

Thanks,
Daniel

9461 - 9480 of 10158