Date   

Twitter account

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

Hi,

maybe we can start the support of our promo efforts with a Twitter account. I would also think about a hashtag

Best Regards

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


Re: Kernel feature support

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Ben,

-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Ben Hutchings
Sent: Thursday, March 09, 2017 11:34 PM
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] Kernel feature support

We've previously agreed that not all kernel features (drivers,
filesystems, network protocols, etc.) can be supported in an SLTS
branch. I'd like to start working out what the supported features
should be for the 4.4 branch.

Are members able to share their kernel .config files, showing which
features are enabled?
Please find attached to this e-mail four kernel v4.4 configurations for different architectures and platforms. Some of these kernels contain vendor patches and the PREEMPT RT patch. Also, please note that they were created with 'make ARCH=xxx savedefconfig'.

Or would you prefer to specify your needs at a
slightly higher level?
I prepared a list of kernel config options that I consider the most important among the configs we are using. You can find them in the file config-cip (included in the attached zip file) which is reproduced below:

General setup
CONFIG_POSIX_MQUEUE
CONFIG_HZ_PERIODIC
CONFIG_HIGH_RES_TIMERS
CONFIG_IKCONFIG
CONFIG_IKCONFIG_PROC
CONFIG_CGROUPS
CONFIG_CPUSETS
CONFIG_NAMESPACES
CONFIG_SCHED_AUTOGROUP
CONFIG_BLK_DEV_INITRD
CONFIG_RD_GZIP
CONFIG_SHMEM
CONFIG_SYSCTL_SYSCALL
CONFIG_KPROBES

Processor type and features
CONFIG_SMP
CONFIG_EFI
CONFIG_HOTPLUG_CPU
CONFIG_CRASH_DUMP

System type
CONFIG_ARCH_TEGRA
CONFIG_ARCH_ZYNQ

Filesystems
CONFIG_EXT4_FS
CONFIG_INOTIFY_USER
CONFIG_OVERLAY_FS
CONFIG_VFAT_FS
CONFIG_PROC_FS
CONFIG_SYSFS
CONFIG_TMPFS
CONFIG_SQUASHFS
CONFIG_JFFS2_FS

Networking support
CONFIG_INET
CONFIG_VLAN_8021Q
CONFIG_IPV6

Device drivers
CONFIG_UIO
CONFIG_UIO_PDRV_GENIRQ
CONFIG_USB_EHCI_HCD
CONFIG_USB_XHCI_HCD
CONFIG_USB_STORAGE
CONFIG_USB_HID
CONFIG_USB_NET_DRIVERS
CONFIG_FB
CONFIG_TUN
CONFIG_DEVTMPFS
CONFIG_DEVTMPFS_MOUNT
CONFIG_GPIOLIB
CONFIG_GPIO_SYSFS
CONFIG_GPIOLIB_IRQCHIP
CONFIG_BLK_DEV_RAM
CONFIG_MTD
CONFIG_MTD_BLOCK
CONFIG_MTD_NAND
CONFIG_I2C
CONFIG_SPI
CONFIG_MMC
CONFIG_MMC_SDHCI
CONFIG_INPUT_EVDEV
CONFIG_PPS
CONFIG_E1000E
CONFIG_I40E
CONFIG_IGB

Kernel hacking
CONFIG_FTRACE
CONFIG_FUNCTION_TRACER
CONFIG_PRINTK_TIME
CONFIG_PANIC_ON_OOPS

Some of these kernel config options may be out of scope or too broad. I just provide them for reference.
We may send you more information in the future.

Best regards,
Daniel

--
IoT Technology center
Toshiba Corp. Industrial ICT solutions,
Daniel SANGORRIN


Re: Update 2017 wk12

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

Hi,


Codethink has published a blog post related with CIP:
https://www.codethink.co.uk/blog/articles/2017/why-codethink-founding-member-civil-infrastructure-platform/
it has now been published in the CIP site: https://www.cip-project.org/blog/2017/03/27/member-blog-why-codethink-is-a-founding-member-of-the-civil-infrastructure-platform-a-linux-foundation-initiative


Best Regards

Robert
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


Update 2017 wk12

Robert Marshall <robert.marshall@...>
 

Dear CIP friends,

here is the report of those tasks related with Testing and kernel
maintenance that we have been working on the past two weeks:

The whole team has been in Manchester for a week and has taken advantage
of that to have various face2face meetings.

CIP Testing

The following issues are being actively worked on:
* Issue #18 Exported vagrant box for an already loaded instance of CIP -
the size of this instance has been reduced and a script is being
prepared for the initial setup. (Issue #50)
* Issue #43 Refining test so that it uses the kernelci locally built kernel
* Issue #37 prepared checklist for release
* Issue #28 is still being investigated - to either document the
requirement or alter the test script so if necessary it performs a
'manual' login.


* Awaiting edit rights for Robert on the CIP public wiki

* Closed various solved issues
** #16 - Beaglebone black health check failing
** #22 - support arm64 build
** #33 - the VM requiring a weird mixture of debian versions
** #49 - deleted the VagrantFile sets up a USB passthru which is never used
** #47 - document the possible timeouts on the QEMU test


CIP kernel maintenance

* Ben has the VM working under Debian stable

Remember you can:
* Download the beta version of Board at Desk - Single dev VM at the
CIP testing Download page:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipdownload
* All issues/tickets referred in this report can be found in our
gitlab.com testing project:
https://gitlab.com/cip-project/testing/boards

Codethink has published a blog post related with CIP:
https://www.codethink.co.uk/blog/articles/2017/why-codethink-founding-member-civil-infrastructure-platform/

Best Regards

Robert


Re: Kernel feature support

Jan Kiszka
 

On 2017-03-27 12:31, Gernot Hillier wrote:
On 15.03.2017 17:18, Agustin Benito Bethencourt wrote:
Hi,

On 09/03/17 15:33, Ben Hutchings wrote:
We've previously agreed that not all kernel features (drivers,
filesystems, network protocols, etc.) can be supported in an SLTS
branch. I'd like to start working out what the supported features
should be for the 4.4 branch.

Are members able to share their kernel .config files, showing which
features are enabled? Or would you prefer to specify your needs at a
slightly higher level?
Answering this question is important to discard features in 4.4 that are
not of CIP interest so we can severely reduce the amount of effort that
we will need to do in terms of fixes analysis, security etc. in the future.

Please take some time to provide feedback.
Sorry for the late reply!
Fell through my cracks as well, just sending out another internal call
for more product configs. One is attached already, derived from
github.com/siemens/meta-iot2000.


Please find attached an x86 kernel configuration from early product
development using kernel 4.4.

This product uses nearly-COTS server hardware due to needed computation
power, but also comes with nice embedded requirements like longterm
maintenance - and as a special need, real-time support, so we use
Linux-Ipipe/Xenomai here.

This means two things:
* many included drivers (especially in net and storage) are only
activated "to be prepared" for future hw replacements
* Feel free to either include Xenomai on your list as a used "kernel
feature" or to ignore the related options.
Xenomai is not in CIP scope right now (though Siemens would welcome
anyone interested in collaborating on it).

In general, anything in a config not part of upstream is filtered out
"automatically", I would say. There are switches for out-of-tree
features in the iot2000 config as well (we are still in the process of
upstreaming).


So same as with the config from Hidehiro Kawai: please let me know if
you need prioritized list of drivers or other features!
Jan

--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux


Re: Kernel feature support

Gernot Hillier <gernot.hillier@...>
 

On 15.03.2017 17:18, Agustin Benito Bethencourt wrote:
Hi,

On 09/03/17 15:33, Ben Hutchings wrote:
We've previously agreed that not all kernel features (drivers,
filesystems, network protocols, etc.) can be supported in an SLTS
branch. I'd like to start working out what the supported features
should be for the 4.4 branch.

Are members able to share their kernel .config files, showing which
features are enabled? Or would you prefer to specify your needs at a
slightly higher level?
Answering this question is important to discard features in 4.4 that are
not of CIP interest so we can severely reduce the amount of effort that
we will need to do in terms of fixes analysis, security etc. in the future.

Please take some time to provide feedback.
Sorry for the late reply!

Please find attached an x86 kernel configuration from early product
development using kernel 4.4.

This product uses nearly-COTS server hardware due to needed computation
power, but also comes with nice embedded requirements like longterm
maintenance - and as a special need, real-time support, so we use
Linux-Ipipe/Xenomai here.

This means two things:
* many included drivers (especially in net and storage) are only
activated "to be prepared" for future hw replacements
* Feel free to either include Xenomai on your list as a used "kernel
feature" or to ignore the related options.

So same as with the config from Hidehiro Kawai: please let me know if
you need prioritized list of drivers or other features!

--
Kind regards,
Gernot Hillier

Siemens AG, Corporate Competence Center Embedded Linux


Re: u-boot policy for CIP

Ben Hutchings <ben.hutchings@...>
 

On Thu, 2017-03-16 at 12:07 +0000, Chris Paterson wrote:

I’m bringing a discussion I’ve started in other places here as it will
benefit from wider participation.
Thank you. I have limited knowledge of u-boot, but I did work on it
recently to add support for a new board.

[...]
Ideally CIP should choose a version of u-boot and use it when
testing/verifying the CIP Kernel on the reference hardware.
We should certainly pick one version for each reference board.

How we actively maintain that version (bug fixes/security
patches/features?) is another question. Given that most devices in the
field won’t have a way to update u-boot in the field (security
issues/practicalities), I think ‘SLTS’ support for u-boot may not be
required. Perhaps we just tag a version of u-boot at the launch of a
new CIP Kernel and stick with it?
If u-boot is configured to use network boot, or to require
authentication of its environment or boot images, or authentication to
interrupt boot (CONFIG_AUTOBOOT_KEYED=y), then it is sometimes handling
untrusted input and might need security updates. Otherwise it probably
does not.

It seems possible that some fixes might be needed to improve
reliability, e.g. if boot timing changes as hardware gets older.

How do we decide what u-boot version to support? Currently it looks
like the BBB platform are shipped with 2014.04
I have a new BBB that came with 2015.10 installed. So we cannot be
certain that a particular model of board will always be shipped with the
same version!

and the Renesas platform is shipped with 2013.01. That said, it looks
like there is upstream support for BBB [1], but how the feature set
compares to the version shipped with the platform I don’t know. There
is also support for some Renesas platforms [2], but not for the exact
board CIP will be using.

Do we want to push Ti/Renesas to ensure there is full support for
their boards upstream? When this is done do we pick the first version
that includes this support to work with? Or do we just stick with the
vendor provided forks?
I don't have an opinion on whether CIP should provide support for
u-boot, beyond the testing it will get through booting each kernel to be
tested. If we do, I would prefer not to include vendor forks as this
could greatly increase the maintenance effort.

Is there a particular feature set that CIP requires?
[...]

For testing purposes we will need at least an unauthenticated command
prompt (CONFIG_AUTOBOOT_KEYED=n), networking and TFTP support. That
probably isn't a complete list.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: u-boot policy for CIP

Mauerer, Wolfgang
 

Hi Chris,

On 16.03.2017 13:07, Chris Paterson wrote:
Hello all,



I’m bringing a discussion I’ve started in other places here as it will
benefit from wider participation.



As you know the aim of CIP is to maintain not just the Kernel, but a
number of other ‘core packages’. One of these is u-boot.



For the Kernel the project will provide super long term support for a
chosen version. For u-boot this will be harder to achieve as

a) there are no ‘LTS’ versions of u-boot to base our ‘SLTS’ version on;

b) a lot of hardware providers tend to use forks for their
platforms, rather than add full functionality upstream.
thanks for raising this question. The problem you describe does not just
exist for U-Boot, but also for many other components that we will be
looking into.



Ideally CIP should choose a version of u-boot and use it when
testing/verifying the CIP Kernel on the reference hardware. How we
actively maintain that version (bug fixes/security patches/features?) is
another question. Given that most devices in the field won’t have a way
to update u-boot in the field (security issues/practicalities), I think
‘SLTS’ support for u-boot may not be required. Perhaps we just tag a
version of u-boot at the launch of a new CIP Kernel and stick with it?
I also assume that updating the bootloader is currently not required
for many appliances, so it suffices to ensure it is labelled properly
and can be (slt) re-produced for these cases.

However, things change when networking features of U-Boot come
into play. These are usually used during product development, but
I imagine that certain (IoT-class) devices will use such features more
in the future. For these cases, it would be desirable to have something
like a CIP standardised update process for the boot loader besides
a SLTS version. Do member companies plan to employ these features
for other than development/debugging purposes in the future?

If the boot loader is part of a secure/trusted boot scenario, the
ability to update U-Boot will also become more important, but that
depends on the threat models.

To me, it seems important to collect information from the members
on U-Boot use-cases, and then decide if and what further action is
necessary. For Siemens at least, I would not be able to come up with a
definitive set of requirements without asking around in the company.




How do we decide what u-boot version to support? Currently it looks like
the BBB platform are shipped with 2014.04 and the Renesas platform is
shipped with 2013.01. That said, it looks like there is upstream support
for BBB [1], but how the feature set compares to the version shipped
with the platform I don’t know. There is also support for some Renesas
platforms [2], but not for the exact board CIP will be using.



Do we want to push Ti/Renesas to ensure there is full support for their
boards upstream? When this is done do we pick the first version that
includes this support to work with? Or do we just stick with the vendor
provided forks?
Having upstream support for the HW components is a critical precondition
for me. CIP has committed to working with the upstream projects as
closely as possible, and maintaining code outside is usually a good
recipe for disaster... Unless there's a really compelling reason
for sticking with a vendor fork, which I cannot think of any in our
context, we should always start from the upstream projects.
Or, in other words: Companies should usually be pushed to bring their
changes upstream, I'm not aware of any case where this has created more
problems than it has solved issues.



Is there a particular feature set that CIP requires?
that is something we would have to define. I again guess it makes sense
to collect configurations from products of the member companies, as the
in-company variability will already likely be substantial.

Best regards, Wolfgang




Forgive my random ramblings, I appreciate there are a lot of different
questions here!





[1] https://github.com/u-boot/u-boot/tree/master/board/ti/am335x

[2] https://github.com/u-boot/u-boot/tree/master/board/renesas



Kind regards, Chris



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


Re: Kernel feature support

Ben Hutchings <ben.hutchings@...>
 

On Fri, 2017-03-24 at 03:39 +0000, 河合英宏 / KAWAI,HIDEHIRO wrote:
[...]
I attached a defconfig for one of our products running on 4.4.12.
This config is based on omap2plus_defconfig, and a diff from
omap2plus_defconfig is also attached.

Currently, each config item has not been prioritized yet, and it
may contain non-important items. Please treat our defconfig
as a reference at this point.
Thanks, this is useful.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: Kernel feature support

Ben Hutchings <ben.hutchings@...>
 

On Thu, 2017-03-23 at 16:32 +0000, Chris Paterson wrote:
[...]
From an SoC vendor point of view, ideally we'd like the interfaces
provided by the reference platform to be included. As support for our
CIP reference platform is not yet mainlined, I can't provide the
exact .config yet. However it will likely be very similar to
shmobile_defconfig [1].
[...]

Thanks, I'll look through this config.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: Kernel feature support

Hidehiro Kawai
 

Hello Agustin and Ben,

From: cip-dev-bounces@lists.cip-project.org [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Agustin Benito
On 09/03/17 15:33, Ben Hutchings wrote:
We've previously agreed that not all kernel features (drivers,
filesystems, network protocols, etc.) can be supported in an SLTS
branch. I'd like to start working out what the supported features
should be for the 4.4 branch.

Are members able to share their kernel .config files, showing which
features are enabled? Or would you prefer to specify your needs at a
slightly higher level?
Answering this question is important to discard features in 4.4 that are
not of CIP interest so we can severely reduce the amount of effort that
we will need to do in terms of fixes analysis, security etc. in the future.

Please take some time to provide feedback.
I attached a defconfig for one of our products running on 4.4.12.
This config is based on omap2plus_defconfig, and a diff from
omap2plus_defconfig is also attached.

Currently, each config item has not been prioritized yet, and it
may contain non-important items. Please treat our defconfig
as a reference at this point.

Best regards,

Hidehiro Kawai
Hitachi, Ltd. Research & Development Group


Re: u-boot policy for CIP

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

Hi,

On 16/03/17 12:07, Chris Paterson wrote:
Hello all,

I’m bringing a discussion I’ve started in other places here as it will
benefit from wider participation.

As you know the aim of CIP is to maintain not just the Kernel, but a
number of other ‘core packages’. One of these is u-boot.

For the Kernel the project will provide super long term support for a
chosen version. For u-boot this will be harder to achieve as

a)there are no ‘LTS’ versions of u-boot to base our ‘SLTS’ version on;

b)a lot of hardware providers tend to use forks for their platforms,
rather than add full functionality upstream.

Ideally CIP should choose a version of u-boot and use it when
testing/verifying the CIP Kernel on the reference hardware. How we
actively maintain that version (bug fixes/security patches/features?) is
another question. Given that most devices in the field won’t have a way
to update u-boot in the field (security issues/practicalities), I think
‘SLTS’ support for u-boot may not be required. Perhaps we just tag a
version of u-boot at the launch of a new CIP Kernel and stick with it?

How do we decide what u-boot version to support? Currently it looks like
the BBB platform are shipped with 2014.04 and the Renesas platform is
shipped with 2013.01. That said, it looks like there is upstream support
for BBB [1], but how the feature set compares to the version shipped
with the platform I don’t know. There is also support for some Renesas
platforms [2], but not for the exact board CIP will be using.

Do we want to push Ti/Renesas to ensure there is full support for their
boards upstream? When this is done do we pick the first version that
includes this support to work with? Or do we just stick with the vendor
provided forks?

Is there a particular feature set that CIP requires?

Forgive my random ramblings, I appreciate there are a lot of different
questions here!
Slightly related to this topic, Ben H. gave a talk/Q&A about hardware support in Debian Stable back in DebConf13

Link: https://www.youtube.com/watch?v=oLTs1ikQR5E


[1] https://github.com/u-boot/u-boot/tree/master/board/ti/am335x

[2] https://github.com/u-boot/u-boot/tree/master/board/renesas

Kind regards, Chris



_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


Re: Kernel feature support

Chris Paterson
 

Hello Agustin, Ben,

Sorry for the slow response to your query.

From: cip-dev-bounces@lists.cip-project.org [mailto:cip-dev-
bounces@lists.cip-project.org] On Behalf Of Agustin Benito Bethencourt
Sent: 15 March 2017 16:19
Hi,

On 09/03/17 15:33, Ben Hutchings wrote:
We've previously agreed that not all kernel features (drivers,
filesystems, network protocols, etc.) can be supported in an SLTS
branch. I'd like to start working out what the supported features
should be for the 4.4 branch.

Are members able to share their kernel .config files, showing which
features are enabled? Or would you prefer to specify your needs at a
slightly higher level?
From an SoC vendor point of view, ideally we'd like the interfaces provided by the reference platform to be included. As support for our CIP reference platform is not yet mainlined, I can't provide the exact .config yet. However it will likely be very similar to shmobile_defconfig [1].

Of course, narrowing down configurations supported by the CIP Kernel should probably be lead more by the end use-cases, but hopefully this is a start.


[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/configs/shmobile_defconfig

Kind regards, Chris


Answering this question is important to discard features in 4.4 that are not of
CIP interest so we can severely reduce the amount of effort that we will
need to do in terms of fixes analysis, security etc. in the future.

Please take some time to provide feedback.

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink agustin.benito@codethink.co.uk
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev


Linux 4.4.55-cip3

Ben Hutchings <ben.hutchings@...>
 

I've released Linux version 4.4.55-cip3. There are no new CIP-specific
changes; this just adds the fixes from stable versions 4.4.49-4.4.55
inclusive. I reviewed those fixes, but have only done very basic manual
testing of the result.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


u-boot policy for CIP

Chris Paterson
 

Hello all,

 

I’m bringing a discussion I’ve started in other places here as it will benefit from wider participation.

 

As you know the aim of CIP is to maintain not just the Kernel, but a number of other ‘core packages’. One of these is u-boot.

 

For the Kernel the project will provide super long term support for a chosen version. For u-boot this will be harder to achieve as

a)      there are no ‘LTS’ versions of u-boot to base our ‘SLTS’ version on;

b)      a lot of hardware providers tend to use forks for their platforms, rather than add full functionality upstream.

 

Ideally CIP should choose a version of u-boot and use it when testing/verifying the CIP Kernel on the reference hardware. How we actively maintain that version (bug fixes/security patches/features?) is another question. Given that most devices in the field won’t have a way to update u-boot in the field (security issues/practicalities), I think ‘SLTS’ support for u-boot may not be required. Perhaps we just tag a version of u-boot at the launch of a new CIP Kernel and stick with it?

 

How do we decide what u-boot version to support? Currently it looks like the BBB platform are shipped with 2014.04 and the Renesas platform is shipped with 2013.01. That said, it looks like there is upstream support for BBB [1], but how the feature set compares to the version shipped with the platform I don’t know. There is also support for some Renesas platforms [2], but not for the exact board CIP will be using.

 

Do we want to push Ti/Renesas to ensure there is full support for their boards upstream? When this is done do we pick the first version that includes this support to work with? Or do we just stick with the vendor provided forks?

 

Is there a particular feature set that CIP requires?

 

Forgive my random ramblings, I appreciate there are a lot of different questions here!

 

 

[1] https://github.com/u-boot/u-boot/tree/master/board/ti/am335x

[2] https://github.com/u-boot/u-boot/tree/master/board/renesas

 

Kind regards, Chris


Re: Kernel feature support

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

Hi,

On 09/03/17 15:33, Ben Hutchings wrote:
We've previously agreed that not all kernel features (drivers,
filesystems, network protocols, etc.) can be supported in an SLTS
branch. I'd like to start working out what the supported features
should be for the 4.4 branch.

Are members able to share their kernel .config files, showing which
features are enabled? Or would you prefer to specify your needs at a
slightly higher level?
Answering this question is important to discard features in 4.4 that are not of CIP interest so we can severely reduce the amount of effort that we will need to do in terms of fixes analysis, security etc. in the future.

Please take some time to provide feedback.

Best Regards

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


Update 2017wk10

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

Dear CIP friends,

here is the report of those tasks related with Testing and kernel maintenance that Don, Ben, Robert and myself has been working on the past two weeks:

CIP Testing

* Investigation is ongoing on issue #16
* Continued work on Issue #30 the ArduinoPDU to control the Soft Reset and the Power On/Off commands to the Beaglebone Black (BBB).
** We are able to command it using the low level relay-ctrl.py command, but the pduclient command is still not working. I've reached out for help on the linaro-lava IRC channel with no success.

* Investigated Issue #31 incorporating QEMU/KVM as a second hypervisor. I want to avoid having to support two versions, so it will be a side-by-side "option."

* Started Issue #22 adding the required build tools for different architectures: The goal is to include tools for: armel, armhf, arm64, and i386 & amd64 at some point.

* Investigated "weird mixture of Debian versions" Issue #33 and from this work, we will solidify the base from which future version will be created.

* Determined to distribute the CIP-Board-at-Desk VM to anyone who cannot build the VM from Vagrant due to software versioning issues in Issue #34 .

* Closed several issues as they were solved:
** #35 Consolidate all the instructions on the wiki
** #29 Beaglebone Black's Debian doesn't give standard Shutdown Message
** #32 Could not access KVM kernel module
** #21 qemu01 health check fails

* Space requested to deploy the VMs for the release.
** LF is working on it
** Size reduced from +4GB to aroind 2GB using different techniques.
** Still unknown how we will deploy it.

* Tested the health check on the beaglebone black

* Created a export of the virtual machine and am currently debugging issues around the re-import on other user machines

* Support Ben H. with several issue he has found with Board at desk - Single dev since he is trying to set it up in his machine to test the CIP 4.4 kernel.
** The current setup depends on the Vagrant version that each distro provides for certain configurations.
** Reported some issues with the build process.
** Identified and reported changes needed to allow running the box under older version of Vagrant for, in this case, Debian Stable.

* Created new milestones for the project.
** Link: https://gitlab.com/cip-project/testing/milestones
** Processed the requests we've got after the Beta release and moved them to the right milestone.

CIP kernel maintenance

* Going through several questions raised by Members after ELC
* Reviewed changes in Linux 4.4.49-4.4.52 stable releases
* Question to Members about 4.4 features to include in CIP in cip-dev ML. Please take it in consideration.

Remember you can:
* Download the beta version of Board at Desk - Single dev VM at the CIP testing Download page: https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipdownload
* All issues/tickets referred in this report can be found in our gitlab.com testing project: https://gitlab.com/cip-project/testing/boards

Codethink has published a blog post related with CIP: https://www.codethink.co.uk/blog/articles/2017/why-codethink-founding-member-civil-infrastructure-platform/

Best Regards

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


Re: Kernel feature support

Ben Hutchings <ben.hutchings@...>
 

On Thu, 2017-03-09 at 18:55 +0000, Ben Hutchings wrote:
On Thu, 2017-03-09 at 16:25 +0100, Angelo Compagnucci wrote:
Dear Ben Hutchings,

2017-03-09 15:33 GMT+01:00 Ben Hutchings <ben.hutchings@codethink.co.uk>:
We've previously agreed that not all kernel features (drivers,
filesystems, network protocols, etc.) can be supported in an SLTS
branch. I'd like to start working out what the supported features
should be for the 4.4 branch.

Are members able to share their kernel .config files, showing which
features are enabled? Or would you prefer to specify your needs at a
slightly higher level?
I would really like to have IIO drivers, they are generally easy to
backport and extremely useful in industrial contexts.
But you don't use *all* the IIO drivers, do you?
Also, I'm not talking about backports here - only about which of the
existing features in 4.4 will need SLTS.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: Kernel feature support

Ben Hutchings <ben.hutchings@...>
 

On Thu, 2017-03-09 at 16:25 +0100, Angelo Compagnucci wrote:
Dear Ben Hutchings,

2017-03-09 15:33 GMT+01:00 Ben Hutchings <ben.hutchings@codethink.co.uk>:
We've previously agreed that not all kernel features (drivers,
filesystems, network protocols, etc.) can be supported in an SLTS
branch. I'd like to start working out what the supported features
should be for the 4.4 branch.

Are members able to share their kernel .config files, showing which
features are enabled? Or would you prefer to specify your needs at a
slightly higher level?
I would really like to have IIO drivers, they are generally easy to
backport and extremely useful in industrial contexts.
But you don't use *all* the IIO drivers, do you?

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Blog post from Codethink about CIP

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

Hi,

we published a blog post to promote CIP and also to explain why Codethink Ltd. is part of it.

link: https://www.codethink.co.uk/blog/articles/2017/why-codethink-founding-member-civil-infrastructure-platform/

Best regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk

8221 - 8240 of 8412