From: Guenter Roeck <linux@...>

commit 664a39236e718f9f03fa73fc01006da9ced04efc upstream.

Introduce an optional hardware maximum heartbeat in the watchdog core.
The hardware maximum heartbeat can be lower than the maximum timeout.

Drivers can set the maximum hardware heartbeat value in the watchdog data
structure. If the configured timeout exceeds the maximum hardware heartbeat,
the watchdog core enables a timer function to assist sending keepalive
requests to the watchdog driver.

Signed-off-by: Guenter Roeck <linux@...>
Signed-off-by: Wim Van Sebroeck <wim@...>
[mosipov@... backported to 4.4.y]
Signed-off-by: Maxim Yu. Osipov <mosipov@...>
---
Documentation/watchdog/watchdog-kernel-api.txt | 19 +++-
drivers/watchdog/watchdog_dev.c | 122 +++++++++++++++++++++++--
include/linux/watchdog.h | 30 ++++--
3 files changed, 154 insertions(+), 17 deletions(-)

diff --git a/Documentation/watchdog/watchdog-kernel-api.txt b/Documentation/watchdog/watchdog-kernel-api.txt
index d8b0d3367706..9887fa6d8f68 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -53,6 +53,7 @@ struct watchdog_device {
unsigned int timeout;
unsigned int min_timeout;
unsigned int max_timeout;
+ unsigned int max_hw_heartbeat_ms;
void *driver_data;
struct mutex lock;
unsigned long status;
@@ -73,8 +74,18 @@ It contains following fields:
additional information about the watchdog timer itself. (Like it's unique name)
* ops: a pointer to the list of watchdog operations that the watchdog supports.
* timeout: the watchdog timer's timeout value (in seconds).
+ This is the time after which the system will reboot if user space does
+ not send a heartbeat request if WDOG_ACTIVE is set.
* min_timeout: the watchdog timer's minimum timeout value (in seconds).
-* max_timeout: the watchdog timer's maximum timeout value (in seconds).
+ If set, the minimum configurable value for 'timeout'.
+* max_timeout: the watchdog timer's maximum timeout value (in seconds),
+ as seen from userspace. If set, the maximum configurable value for
+ 'timeout'. Not used if max_hw_heartbeat_ms is non-zero.
+* max_hw_heartbeat_ms: Maximum hardware heartbeat, in milli-seconds.
+ If set, the infrastructure will send heartbeats to the watchdog driver
+ if 'timeout' is larger than max_hw_heartbeat_ms, unless WDOG_ACTIVE
+ is set and userspace failed to send a heartbeat for at least 'timeout'
+ seconds.
* bootstatus: status of the device after booting (reported with watchdog
WDIOF_* status bits).
* driver_data: a pointer to the drivers private data of a watchdog device.
@@ -160,7 +171,11 @@ they are supported. These optional routines/operations are:
and -EIO for "could not write value to the watchdog". On success this
routine should set the timeout value of the watchdog_device to the
achieved timeout value (which may be different from the requested one
- because the watchdog does not necessarily has a 1 second resolution).
+ because the watchdog does not necessarily have a 1 second resolution).
+ Drivers implementing max_hw_heartbeat_ms set the hardware watchdog heartbeat
+ to the minimum of timeout and max_hw_heartbeat_ms. Those drivers set the
+ timeout value of the watchdog_device either to the requested timeout value
+ (if it is larger than max_hw_heartbeat_ms), or to the achieved timeout value.
(Note: the WDIOF_SETTIMEOUT needs to be set in the options field of the
watchdog's info structure).
* get_timeleft: this routines returns the time that's left before a reset.
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 56a649e66eb2..df43c586e53f 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -35,9 +35,11 @@
#include <linux/module.h> /* For module stuff/... */
#include <linux/types.h> /* For standard types (like size_t) */
#include <linux/errno.h> /* For the -ENODEV/... values */
+#include <linux/jiffies.h> /* For timeout functions */
#include <linux/kernel.h> /* For printk/panic/... */
#include <linux/fs.h> /* For file operations */
#include <linux/watchdog.h> /* For watchdog specific items */
+#include <linux/workqueue.h> /* For workqueue */
#include <linux/miscdevice.h> /* For handling misc devices */
#include <linux/init.h> /* For __init/__exit/... */
#include <linux/uaccess.h> /* For copy_to_user/put_user/... */
@@ -49,6 +51,73 @@ static dev_t watchdog_devt;
/* the watchdog device behind /dev/watchdog */
static struct watchdog_device *old_wdd;

+static struct workqueue_struct *watchdog_wq;
+
+static inline bool watchdog_need_worker(struct watchdog_device *wdd)
+{
+ /* All variables in milli-seconds */
+ unsigned int hm = wdd->max_hw_heartbeat_ms;
+ unsigned int t = wdd->timeout * 1000;
+
+ /*
+ * A worker to generate heartbeat requests is needed if all of the
+ * following conditions are true.
+ * - Userspace activated the watchdog.
+ * - The driver provided a value for the maximum hardware timeout, and
+ * thus is aware that the framework supports generating heartbeat
+ * requests.
+ * - Userspace requests a longer timeout than the hardware can handle.
+ */
+ return watchdog_active(wdd) && hm && t > hm;
+}
+
+static long watchdog_next_keepalive(struct watchdog_device *wdd)
+{
+ unsigned int timeout_ms = wdd->timeout * 1000;
+ unsigned long keepalive_interval;
+ unsigned long last_heartbeat;
+ unsigned long virt_timeout;
+ unsigned int hw_heartbeat_ms;
+
+ virt_timeout = wdd->last_keepalive + msecs_to_jiffies(timeout_ms);
+ hw_heartbeat_ms = min(timeout_ms, wdd->max_hw_heartbeat_ms);
+ keepalive_interval = msecs_to_jiffies(hw_heartbeat_ms / 2);
+
+ /*
+ * To ensure that the watchdog times out wdd->timeout seconds
+ * after the most recent ping from userspace, the last
+ * worker ping has to come in hw_heartbeat_ms before this timeout.
+ */
+ last_heartbeat = virt_timeout - msecs_to_jiffies(hw_heartbeat_ms);
+ return min_t(long, last_heartbeat - jiffies, keepalive_interval);
+}
+
+static inline void watchdog_update_worker(struct watchdog_device *wdd)
+{
+ if (watchdog_need_worker(wdd)) {
+ long t = watchdog_next_keepalive(wdd);
+
+ if (t > 0)
+ mod_delayed_work(watchdog_wq, &wdd->work, t);
+ } else {
+ cancel_delayed_work(&wdd->work);
+ }
+}
+
+static int __watchdog_ping(struct watchdog_device *wdd)
+{
+ int err;
+
+ if (wdd->ops->ping)
+ err = wdd->ops->ping(wdd); /* ping the watchdog */
+ else
+ err = wdd->ops->start(wdd); /* restart watchdog */
+
+ watchdog_update_worker(wdd);
+
+ return err;
+}
+
/*
* watchdog_ping: ping the watchdog.
* @wdd: the watchdog device to ping
@@ -73,16 +142,27 @@ static int watchdog_ping(struct watchdog_device *wdd)
if (!watchdog_active(wdd))
goto out_ping;

- if (wdd->ops->ping)
- err = wdd->ops->ping(wdd); /* ping the watchdog */
- else
- err = wdd->ops->start(wdd); /* restart watchdog */
+ wdd->last_keepalive = jiffies;
+ err = __watchdog_ping(wdd);

out_ping:
mutex_unlock(&wdd->lock);
return err;
}

+static void watchdog_ping_work(struct work_struct *work)
+{
+ struct watchdog_device *wdd;
+
+ wdd = container_of(to_delayed_work(work), struct watchdog_device,
+ work);
+
+ mutex_lock(&wdd->lock);
+ if (wdd && watchdog_active(wdd))
+ __watchdog_ping(wdd);
+ mutex_unlock(&wdd->lock);
+}
+
/*
* watchdog_start: wrapper to start the watchdog.
* @wdd: the watchdog device to start
@@ -95,6 +175,7 @@ out_ping:
static int watchdog_start(struct watchdog_device *wdd)
{
int err = 0;
+ unsigned long started_at;

mutex_lock(&wdd->lock);

@@ -106,9 +187,13 @@ static int watchdog_start(struct watchdog_device *wdd)
if (watchdog_active(wdd))
goto out_start;

+ started_at = jiffies;
err = wdd->ops->start(wdd);
- if (err == 0)
+ if (err == 0) {
set_bit(WDOG_ACTIVE, &wdd->status);
+ wdd->last_keepalive = started_at;
+ watchdog_update_worker(wdd);
+ }

out_start:
mutex_unlock(&wdd->lock);
@@ -146,8 +231,10 @@ static int watchdog_stop(struct watchdog_device *wdd)
}

err = wdd->ops->stop(wdd);
- if (err == 0)
+ if (err == 0) {
clear_bit(WDOG_ACTIVE, &wdd->status);
+ cancel_delayed_work(&wdd->work);
+ }

out_stop:
mutex_unlock(&wdd->lock);
@@ -211,6 +298,8 @@ static int watchdog_set_timeout(struct watchdog_device *wdd,

err = wdd->ops->set_timeout(wdd, timeout);

+ watchdog_update_worker(wdd);
+
out_timeout:
mutex_unlock(&wdd->lock);
return err;
@@ -490,6 +579,8 @@ static int watchdog_release(struct inode *inode, struct file *file)
/* Allow the owner module to be unloaded again */
module_put(wdd->ops->owner);

+ cancel_delayed_work_sync(&wdd->work);
+
/* make sure that /dev/watchdog can be re-opened */
clear_bit(WDOG_DEV_OPEN, &wdd->status);

@@ -527,6 +618,11 @@ int watchdog_dev_register(struct watchdog_device *wdd)
{
int err, devno;

+ if (!watchdog_wq)
+ return -ENODEV;
+
+ INIT_DELAYED_WORK(&wdd->work, watchdog_ping_work);
+
if (wdd->id == 0) {
old_wdd = wdd;
watchdog_miscdev.parent = wdd->parent;
@@ -573,6 +669,8 @@ int watchdog_dev_unregister(struct watchdog_device *wdd)
set_bit(WDOG_UNREGISTERED, &wdd->status);
mutex_unlock(&wdd->lock);

+ cancel_delayed_work_sync(&wdd->work);
+
cdev_del(&wdd->cdev);
if (wdd->id == 0) {
misc_deregister(&watchdog_miscdev);
@@ -589,7 +687,16 @@ int watchdog_dev_unregister(struct watchdog_device *wdd)

int __init watchdog_dev_init(void)
{
- int err = alloc_chrdev_region(&watchdog_devt, 0, MAX_DOGS, "watchdog");
+ int err;
+
+ watchdog_wq = alloc_workqueue("watchdogd",
+ WQ_HIGHPRI | WQ_MEM_RECLAIM, 0);
+ if (!watchdog_wq) {
+ pr_err("Failed to create watchdog workqueue\n");
+ return -ENOMEM;
+ }
+
+ err = alloc_chrdev_region(&watchdog_devt, 0, MAX_DOGS, "watchdog");
if (err < 0)
pr_err("watchdog: unable to allocate char dev region\n");
return err;
@@ -604,4 +711,5 @@ int __init watchdog_dev_init(void)
void __exit watchdog_dev_exit(void)
{
unregister_chrdev_region(watchdog_devt, MAX_DOGS);
+ destroy_workqueue(watchdog_wq);
}
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index 027b1f43f12d..26aba9b17ac3 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -10,8 +10,9 @@


#include <linux/bitops.h>
-#include <linux/device.h>
#include <linux/cdev.h>
+#include <linux/device.h>
+#include <linux/kernel.h>
#include <uapi/linux/watchdog.h>

struct watchdog_ops;
@@ -61,12 +62,17 @@ struct watchdog_ops {
* @bootstatus: Status of the watchdog device at boot.
* @timeout: The watchdog devices timeout value (in seconds).
* @min_timeout:The watchdog devices minimum timeout value (in seconds).
- * @max_timeout:The watchdog devices maximum timeout value (in seconds).
+ * @max_timeout:The watchdog devices maximum timeout value (in seconds)
+ * as configurable from user space. Only relevant if
+ * max_hw_heartbeat_ms is not provided.
+ * @max_hw_heartbeat_ms:
+ * Hardware limit for maximum timeout, in milli-seconds.
+ * Replaces max_timeout if specified.
* @driver-data:Pointer to the drivers private data.
* @lock: Lock for watchdog core internal use only.
* @status: Field that contains the devices internal status bits.
- * @deferred: entry in wtd_deferred_reg_list which is used to
- * register early initialized watchdogs.
+ * @deferred: Entry in wtd_deferred_reg_list which is used to
+ * register early initialized watchdogs.
*
* The watchdog_device structure contains all information about a
* watchdog timer device.
@@ -88,8 +94,11 @@ struct watchdog_device {
unsigned int timeout;
unsigned int min_timeout;
unsigned int max_timeout;
+ unsigned int max_hw_heartbeat_ms;
void *driver_data;
struct mutex lock;
+ unsigned long last_keepalive;
+ struct delayed_work work;
unsigned long status;
/* Bit numbers for status flags */
#define WDOG_ACTIVE 0 /* Is the watchdog running/active */
@@ -121,13 +130,18 @@ static inline bool watchdog_timeout_invalid(struct watchdog_device *wdd, unsigne
{
/*
* The timeout is invalid if
+ * - the requested value is larger than UINT_MAX / 1000
+ * (since internal calculations are done in milli-seconds),
+ * or
* - the requested value is smaller than the configured minimum timeout,
* or
- * - a maximum timeout is configured, and the requested value is larger
- * than the maximum timeout.
+ * - a maximum hardware timeout is not configured, a maximum timeout
+ * is configured, and the requested value is larger than the
+ * configured maximum timeout.
*/
- return t < wdd->min_timeout ||
- (wdd->max_timeout && t > wdd->max_timeout);
+ return t > UINT_MAX / 1000 || t < wdd->min_timeout ||
+ (!wdd->max_hw_heartbeat_ms && wdd->max_timeout &&
+ t > wdd->max_timeout);
}

/* Use the following functions to manipulate watchdog driver specific data */
--
2.11.0

Hello,

This is updated series after Ben's review.

* On 10/25/17 12:43, Ben Hutchings wrote:

On Wed, 2017-10-04 at 16:40 +0200, Maxim Yu. Osipov wrote:

From: Guenter Roeck <linux@...>

Backport from kernel.org, upstream commit ee142889e32f

The WDOG_HW_RUNNING flag is expected to be set by watchdog drivers if
the hardware watchdog is running. If the flag is set, the watchdog
subsystem will ping the watchdog even if the watchdog device is
closed.

The watchdog driver stop function is now optional and may be omitted
if the watchdog can not be stopped. If stopping the watchdog is not
possible but the driver implements a stop function, it is responsible
to set the WDOG_HW_RUNNING flag in its stop function.

[...]

--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c

[...]

@@ -651,9 +665,24 @@ int watchdog_dev_register(struct watchdog_device
*wdd)
if (wdd->id == 0) {
misc_deregister(&watchdog_miscdev);
old_wdd = NULL;
+ if (wdd->ops->unref)
+ wdd->ops->unref(wdd);

[...]

This doesn't look right. This is decrementing a reference counter
because the old_wdd reference is going away, but we never increment a
reference counter when old_wdd is set.

The upstream commit doesn't make any change here. There is a
kref_put() here in the upstream version but that was added as part of
the watchdog_device/watchdog_core_data split.

Ben.

* On 10/25/17 12:46, Ben Hutchings wrote:

Please use one of these formats for upstream references in the commit
messages:

commit 0123456789012345678901234567890123456789 upstream.

[ Upstream commit 0123456789012345678901234567890123456789 ]

Ben.

<<<<<<<<<<<<<


This series contains

* backport of patches of watchdog core infrastructure
supporting handling watchdog keepalive.

* imx21_wdt converted to use infrastructure triggered keepalives.

* backported support of WATCHDOG_HANDLE_BOOT_ENABLED option

On some systems it's desirable to have watchdog reboot the system
when it does not come up fast enough. This adds a kernel parameter
to disable the auto-update of watchdog before userspace takes over
and a kernel option to set the default.

One of the important use cases is safe system update.
In that case, the bootloader enables the watchdog, and Linux should only
take it over at the point the whole Linux system is sure to be able to
have a fully working system again, including userspace services that
could take the next update. If we start the trigger the watchdog too
early, like it was so far, we risk to enter a system state where the
kernel works but not all other services we need.

i.MX6 based board was used as a test platform.

We suppose that watchdog is enabled in bootloader and set to 120 seconds
(maximum timeout supported by i.MX watchdog timer)

After applying these patches, built-in i.MX watchdog (imx21_wdt) into
kernel and perform the following test cases:

1) option WATCHDOG_HANDLE_BOOT_ENABLED is turned off in kernel configuration
w/o userspace application triggering the watchdog.

Make sure that no userspace application is triggering watchdog.

After around 120 seconds (timeout set in bootloader) board will reboot.

2) option WATCHDOG_HANDLE_BOOT_ENABLED is turned off in kernel configuration
but userspace application is triggering watchdog more frequently that watchdog's
timeout (by default set to 60 seconds for imx21_wdt).

Watchdog will not reboot the board until the application re-arms
the watchdog.

3) option WATCHDOG_HANDLE_BOOT_ENABLED is turned on in kernel configuration
w/o userspace application triggering the watchdog.

Make sure that no userspace application is triggering watchdog.
Board will not reboot (watchdog keepalive is supported by watchdog core
infrastructure, not by driver itself)

Kind regards,
Maxim.

Guenter Roeck (6):
watchdog: Introduce hardware maximum heartbeat in watchdog core
watchdog: Introduce WDOG_HW_RUNNING flag
watchdog: Make stop function optional
watchdog: imx2: Convert to use infrastructure triggered keepalives
watchdog: core: Fix circular locking dependency
watchdog: core: Clear WDOG_HW_RUNNING before calling the stop function

Pratyush Anand (1):
watchdog: skip min and max timeout validity check when
max_hw_heartbeat_ms is defined

Rasmus Villemoes (1):
watchdog: change watchdog_need_worker logic

Sebastian Reichel (1):
watchdog: core: add option to avoid early handling of watchdog

Wei Yongjun (1):
watchdog: core: Fix error handling of watchdog_dev_init()

Documentation/watchdog/watchdog-kernel-api.txt | 51 +++++--
drivers/watchdog/Kconfig | 11 ++
drivers/watchdog/imx2_wdt.c | 74 ++--------
drivers/watchdog/watchdog_core.c | 4 +-
drivers/watchdog/watchdog_dev.c | 196 +++++++++++++++++++++++--
include/linux/watchdog.h | 40 ++++-
6 files changed, 277 insertions(+), 99 deletions(-)

--
2.11.0

Hi Chris, Daniel,

Subject: RE: [cip-dev] Status of cip-core

Hello Daniel,

Apologies for the slow response. Lots of ramblings below, happy to set
up a call if it's easier to go through the details.

From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: 24 October 2017 06:17

Hello Chris,

-----Original Message-----
From: Chris Paterson [mailto:Chris.Paterson2@...]
Sent: Tuesday, October 24, 2017 3:23 AM
To: Daniel Sangorrin; cip-dev@...; 'Jan Kiszka'
Subject: RE: [cip-dev] Status of cip-core

Hello Daniel,

Thank you for the update.

- modules.tgz is not generated for iwg20m (for bbb it is): I
have to investigate why but I think it is not a big problem
since they are included in the file system images. Probably the
reason is just that shmobile_defconfig has modules disabled.

Correct :)

I have noticed that the shmobile_defconfig from the official
linux-cip repo is quite different from the one at
https://github.com/renesas-

rz/renesas-cip.

Let me explain...

The renesas-rz github website is used to host the complete Yocto BSP
package for the RZ/G iWave platforms. This is used as a basis for the
"Renesas RZ/G Linux Platform" which was launched in October.

This BSP is based on the CIP Kernel, but as you can see has a lot of
patches applied on top. The main reason for these additional patches
is that the iwg20m platform is not yet fully supported upstream.

If using the above BSP for your testing, I'd recommend that you stick
with the
v4.4.55-cip3 branch. This has been fully verified and should be working.

Whilst Renesas are continuously working on the renesas-rz github
repository, in tandem we are also upstreaming support to the mainline
Kernel for the iwg20m platform. Periodically once a new Kernel release
has been made we are backporting support to the official CIP Kernel.

The latest CIP Kernel (v4.4.92-cip11) includes support for clk,
pinctrl, GPIO, Ethernet and eMMC on the iwg20m platform.

Previously I tested the official kernel using a ramdisk and it was
successful so I didn't notice the difference. But today I've tried
to boot the official kernel with the SD Card file system and it didn't work.

Currently the official CIP Kernel does not support SD on the iwg20m.
Support upstream will be included in Kernel v4.15. We plan to backport
support once
v4.15 is released, but can backport when v4.15-rc1 is out if there is
an urgent need.

One problem was that EXT3/4 wasn't enabled.

Yes. Historically shmobile_defconfig doesn't have ext3/4 enabled
upstream :( I guess one option would be to enable this on the CIP Kernel?

I decided to use renesas-cip's
shmobile_defconfig to build the official linux-cip kernel. However,
I got a build error because
https://gitlab.com/cip-project/linux-cip/blob/linux-4.4.y-
cip/drivers/usb/host/xhci-rcar.c
references a firmware called "r8a779x_usb3_v1.dlmem" which wasn't
available on the official kernel. I could solve that either by
copying the firmware from renesas-cip or by commenting out the
corresponding configuration flags.

There may well be other differences between the config used in the
renesas- rz BSP compared to the upstream/CIP version. It might be best
to stick with the version in the CIP Kernel and just enable EXT3/4 as
required. This is what we use to test when backporting to the CIP Kernel.

I managed to build the official kernel but still I couldn't get it
to boot from the SD Card.

Again, due to lack of SD support in the official Kernel (see
r8a7743-iwg20d- q7.dts).

# By the way, I noticed that the mmc numbering also changed
(mmcblk0p2 was working on renesas-cip kernel as the 2nd partition of
the SD Card, but for the official kernel that was a partition on the
eMMC and the kernel could not recognize mmcblk2p2).

I wonder if this problem comes from the device tree. On the
renesas-cip repository there was a r8a7743-iwgm.dts file that worked
fine, but on the official repository the one with the closest name
was

r8a7743-iwg20d-q7.dts.

This one worked fine when I boot from a ramdisk but not when I boot
from the SD Card.

Should I use renesas-cip kernel again?

As you have no need for the entire BSP (you only need the Kernel), I'd
recommend using the official CIP Kernel. For now this would mean that
you'd need to either use NFS or eMMC for your RFS. If using eMMC
you'll need to enable EXT3/4 on top of shmobile_defconfig.

This has the added benefit that CIP Core will use and test the
official CIP Kernel, rather than Renesas' out of tree BSP version.

I noticed that the new versions are been merged. I was using
renesas-cip's
v4.4.69-cip4 but I can see a newer branch called v4.4.83-cip8

v4.4.55-cip3 is the only version properly tested. I think the other
versions are just rebases.

Binh-san, could you confirm the current status of the newer branches
on renesas-rz?

v4.4.55-cip3 was fully tested, including UT,IT,ST.
v4.4.69-cip4 , v4.4.75-cip6 also worked with just some simple tests.

Best regards,
Binh Nguyen

Kind regards, Chris

Thanks,
Daniel

Hi Ben,
# I added the fuego mailing list to Cc

Thanks for the notes!

Hello Daniel,

Apologies for the slow response. Lots of ramblings below, happy to set up a call if it's easier to go through the details.

From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: 24 October 2017 06:17

Hello Chris,

-----Original Message-----
From: Chris Paterson [mailto:Chris.Paterson2@...]
Sent: Tuesday, October 24, 2017 3:23 AM
To: Daniel Sangorrin; cip-dev@...; 'Jan Kiszka'
Subject: RE: [cip-dev] Status of cip-core

Hello Daniel,

Thank you for the update.

- modules.tgz is not generated for iwg20m (for bbb it is): I have to
investigate why but I think it is not a big problem since they are
included in the file system images. Probably the reason is just that
shmobile_defconfig has modules disabled.

Correct :)

I have noticed that the shmobile_defconfig from the official linux-cip repo is
quite different from the one at https://github.com/renesas-rz/renesas-cip.

Let me explain...

The renesas-rz github website is used to host the complete Yocto BSP package for the RZ/G iWave platforms. This is used as a basis for the "Renesas RZ/G Linux Platform" which was launched in October.

This BSP is based on the CIP Kernel, but as you can see has a lot of patches applied on top. The main reason for these additional patches is that the iwg20m platform is not yet fully supported upstream.

If using the above BSP for your testing, I'd recommend that you stick with the v4.4.55-cip3 branch. This has been fully verified and should be working.

Whilst Renesas are continuously working on the renesas-rz github repository, in tandem we are also upstreaming support to the mainline Kernel for the iwg20m platform. Periodically once a new Kernel release has been made we are backporting support to the official CIP Kernel.

The latest CIP Kernel (v4.4.92-cip11) includes support for clk, pinctrl, GPIO, Ethernet and eMMC on the iwg20m platform.

Previously I tested the official kernel using a ramdisk and it was successful so
I didn't notice the difference. But today I've tried to boot the official kernel
with the SD Card file system and it didn't work.

Currently the official CIP Kernel does not support SD on the iwg20m. Support upstream will be included in Kernel v4.15. We plan to backport support once v4.15 is released, but can backport when v4.15-rc1 is out if there is an urgent need.

One problem was that EXT3/4 wasn't enabled.

Yes. Historically shmobile_defconfig doesn't have ext3/4 enabled upstream :( I guess one option would be to enable this on the CIP Kernel?

I decided to use renesas-cip's
shmobile_defconfig to build the official linux-cip kernel. However, I got a
build error because https://gitlab.com/cip-project/linux-cip/blob/linux-4.4.y-
cip/drivers/usb/host/xhci-rcar.c
references a firmware called "r8a779x_usb3_v1.dlmem" which wasn't
available on the official kernel. I could solve that either by copying the
firmware from renesas-cip or by commenting out the corresponding
configuration flags.

There may well be other differences between the config used in the renesas-rz BSP compared to the upstream/CIP version. It might be best to stick with the version in the CIP Kernel and just enable EXT3/4 as required. This is what we use to test when backporting to the CIP Kernel.

I managed to build the official kernel but still I couldn't get it to boot from the
SD Card.

Again, due to lack of SD support in the official Kernel (see r8a7743-iwg20d-q7.dts).

# By the way, I noticed that the mmc numbering also changed (mmcblk0p2
was working on renesas-cip kernel as the 2nd partition of the SD Card, but for
the official kernel that was a partition on the eMMC and the kernel could not
recognize mmcblk2p2).

I wonder if this problem comes from the device tree. On the renesas-cip
repository there was a r8a7743-iwgm.dts file that worked fine, but on the
official repository the one with the closest name was r8a7743-iwg20d-q7.dts.
This one worked fine when I boot from a ramdisk but not when I boot from
the SD Card.

Should I use renesas-cip kernel again?

As you have no need for the entire BSP (you only need the Kernel), I'd recommend using the official CIP Kernel. For now this would mean that you'd need to either use NFS or eMMC for your RFS. If using eMMC you'll need to enable EXT3/4 on top of shmobile_defconfig.

This has the added benefit that CIP Core will use and test the official CIP Kernel, rather than Renesas' out of tree BSP version.

I noticed that the new versions are been merged. I was using renesas-cip's
v4.4.69-cip4 but I can see a newer branch called v4.4.83-cip8

v4.4.55-cip3 is the only version properly tested. I think the other versions are just rebases.

Binh-san, could you confirm the current status of the newer branches on renesas-rz?


Kind regards, Chris

Thanks,
Daniel

From: cip-dev-bounces@... [mailto:cip-dev-
bounces@...] On Behalf Of Jan Kiszka
Sent: 08 November 2017 07:33

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!

+1

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!

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

[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

[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

[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

[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.

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.

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.

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

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.

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@...

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

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.

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