Date   

Re: B@D support Renesas iwg20m board - issue

Robert Marshall <robert.marshall@...>
 

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

Hello all,

I am trying to add support healthcheck for Renesas iwg20m board into
[1]. My current healthcheck is just simply boot up the board (no
deploy and test definition).
And I still meet one issue with that booting action. The issue is
whenever I run healthcheck, It always run soft-reboot and
failed. 'reboot' command is just supported after booting board. So if
I booted the board first, then run the healthcheck, it will pass.

Anyone have advices for me?
Hi

I've seen errors on the soft reboot with the beagle bone black which go
away the next time it is run. Have you tried this more than once - does
it consistently fail?

Thanks for the patches

I've always run HC tests with the BB black on an already booted board, do
you need to do any preparation to get the health check to run in this
case?

Robert


Please find my patches to apply for [1] in attached files.

[1] https://gitlab.com/cip-project/cip-testing/board-at-desk-single-dev/

Below is the log:

start: 0 validate
device may need manual intervention to reboot validate duration: 0.00
start: 1 uboot-action (max 120s)
start: 1.1 uboot-prepare-kernel (max 120s) uboot-prepare-kernel duration: 0.00
start: 1.2 uboot-from-media (max 120s)
uboot-from-media duration: 0.00
start: 1.3 uboot-overlay (max 120s)
Parsed boot commands: setenv autoload no; setenv initrd_high
'0xffffffff'; setenv fdt_high '0xffffffff'; setenv bootargs
'console=ttySC0,115200n8 vmalloc=384M root=/dev/mmcblk0p2 '; setenv
loadkernel 'fatload mmc 2:1 0x40007fc0 uImage'; setenv loadfdt
'fatload mmc 2:1 0x40f00000 r8a7743-iwg20m.dtb'; setenv bootcmd 'run
loadkernel; run loadfdt; bootm 0x40007fc0 - 0x40f00000'; run bootcmd
uboot-overlay duration: 0.00
start: 1.4 connect-device (max 120s)
connect-device Connecting to device using 'telnet localhost 8020'
connect-device duration: 0.00
start: 1.5 uboot-retry (max 120s)
start: 1.5.1 reboot-device (max 120s)
start: 1.5.1.1 soft-reboot (max 120s)
reboot
reboot
reboot -n
reboot -n
reboot -n -f
reboot -n -f
soft-reboot: Wait for prompt Restarting system. 120 seconds Trying ::1...
Connected to localhost.
Escape character is '^]'.
ser2net port 8020 device /dev/ttyUSB0 [115200 N81] (Debian GNU/Linux)
case: soft-reboot
definition: lava
result: fail
level: 1.5.1.1
duration: 120.000326157
extra: ...
soft-reboot timed out after 120 seconds
soft-reboot timed out after 120 seconds
uboot-retry failed: 1 of 2 attempts. 'soft-reboot timed out after 120 seconds'
start: 1.5.1 reboot-device (max 120s)
start: 1.5.1.1 soft-reboot (max 120s)
...

Best regards,
Binh Nguyen




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


B@D support Renesas iwg20m board - issue

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

Hello all,

I am trying to add support healthcheck for Renesas iwg20m board into [1]. My current healthcheck is just simply boot up the board (no deploy and test definition).
And I still meet one issue with that booting action. The issue is whenever I run healthcheck, It always run soft-reboot and failed. 'reboot' command is just supported after booting board. So if I booted the board first, then run the healthcheck, it will pass.

Anyone have advices for me?

Please find my patches to apply for [1] in attached files.

[1] https://gitlab.com/cip-project/cip-testing/board-at-desk-single-dev/

Below is the log:

start: 0 validate
device may need manual intervention to reboot validate duration: 0.00
start: 1 uboot-action (max 120s)
start: 1.1 uboot-prepare-kernel (max 120s) uboot-prepare-kernel duration: 0.00
start: 1.2 uboot-from-media (max 120s)
uboot-from-media duration: 0.00
start: 1.3 uboot-overlay (max 120s)
Parsed boot commands: setenv autoload no; setenv initrd_high '0xffffffff'; setenv fdt_high '0xffffffff'; setenv bootargs 'console=ttySC0,115200n8 vmalloc=384M root=/dev/mmcblk0p2 '; setenv loadkernel 'fatload mmc 2:1 0x40007fc0 uImage'; setenv loadfdt 'fatload mmc 2:1 0x40f00000 r8a7743-iwg20m.dtb'; setenv bootcmd 'run loadkernel; run loadfdt; bootm 0x40007fc0 - 0x40f00000'; run bootcmd uboot-overlay duration: 0.00
start: 1.4 connect-device (max 120s)
connect-device Connecting to device using 'telnet localhost 8020'
connect-device duration: 0.00
start: 1.5 uboot-retry (max 120s)
start: 1.5.1 reboot-device (max 120s)
start: 1.5.1.1 soft-reboot (max 120s)
reboot
reboot
reboot -n
reboot -n
reboot -n -f
reboot -n -f
soft-reboot: Wait for prompt Restarting system. 120 seconds Trying ::1...
Connected to localhost.
Escape character is '^]'.
ser2net port 8020 device /dev/ttyUSB0 [115200 N81] (Debian GNU/Linux)
case: soft-reboot
definition: lava
result: fail
level: 1.5.1.1
duration: 120.000326157
extra: ...
soft-reboot timed out after 120 seconds
soft-reboot timed out after 120 seconds
uboot-retry failed: 1 of 2 attempts. 'soft-reboot timed out after 120 seconds'
start: 1.5.1 reboot-device (max 120s)
start: 1.5.1.1 soft-reboot (max 120s)
...

Best regards,
Binh Nguyen


Re: Project-X (minimal root filesystem) for renesas board

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Chris,

-----Original Message-----
From: Chris Paterson [mailto:Chris.Paterson2@...]
Sent: Thursday, August 03, 2017 10:19 PM
To: Daniel Sangorrin; 'Agustin Benito Bethencourt'
Cc: cip-dev@...
Subject: RE: [cip-dev] Project-X (minimal root filesystem) for renesas board

Hello Daniel, all,

From: cip-dev-bounces@... [mailto:cip-dev-bounces@...
project.org] On Behalf Of Daniel Sangorrin
Sent: 07 July 2017 03:41

Hi Agustin, Chris

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Agustin
Benito Bethencourt
Sent: Thursday, June 29, 2017 5:21 PM
To: cip-dev@...
Subject: Re: [cip-dev] Project-X (minimal root filesystem) for renesas
board

Hi,

On 29/06/17 02:37, Daniel Sangorrin wrote:
Hi Koguchi-san,

-----Original Message-----
From: 小口琢夫 / KOGUCHI,TAKUO
[mailto:takuo.koguchi.sw@...]
Sent: Wednesday, June 28, 2017 6:08 PM
To: 'Daniel Sangorrin'; cip-dev@...
Cc: 'Chris Paterson'
Subject: RE: RE: Project-X (minimal root filesystem) for renesas
board

Daniel-san,

I think this is not a good approach. We would need to have a new
linux-cip folder for each release.
Let make it clear. Will you please describe your recommendation?
Yes, please see below.

Patches for the cyclone board should be on its own CIP kernel
repository (where you can merge cip releases and add tags). Then,
we can choose which version we want by specifying the repository and
tag/commit_id.
Good point. But CIP kernel repository is curerntly used for
release assuming it is tested. And CycloneV is not supported by CIP
at
this
moment. So I put the patches in the yocto project way.
I didn't mean to put it on Ben's CIP repository rather on github.
This way you can better maintain your "out-of-tree" cyclone V
patches
and merge (do not rebase please) changes from Ben's CIP kernel regularly.
In other words, do the same as Renesas is doing at [1].

[1] https://github.com/renesas-rz/renesas-cip
In order to have all the cip related code in one place, it would be
good, if anybody is using github, that at least there is a mirror of
that repo in gitlab. When we start automating builds/test, that would
be helpful.
Agustin: I don't mind, but is this necessary?.
Chris: Will you create another repository for u-boot?
Sorry for the delay.

u-boot source for the RZ/G1-M iWave platform is now available [1].

We've tested this using the gcc-arm-none-eabi-5_4-2016q3 [2] compiler:

export PATH=/opt/gcc-arm-none-eabi-5_4-2016q3/bin:$PATH
export CROSS_COMPILE=arm-none-eabi-
export ARCH=arm
make iwg20m_q7_config
make

The u-boot binary can be loaded onto the platform using JTAG or by writing it to the eMMC (be very careful though as this overwrites
the current u-boot, so if it goes wrong you'll need JTAG to un-brick the board). Instructions can be found in the Software User Guide
included on the CD which comes with the platform.


[1] https://github.com/renesas-rz/renesas-u-boot-cip/tree/2013.01.01/rzg1-iwave
[2] https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads

Kind regards, Chris
Thank you!

I have updated the project-x with the u-boot definitions.
I'm a bit scared of bricking the board and not being able to recover because
I probably don't have an appropriate JTAG ICE/cable. For that reason, I will
leave the flashing part for the future.

Thanks,
Daniel

I don't think it is necessary since the CIP root filesystem only supports a
few packages.
Do you mind if I rewrite this and other unnecessary definitions?
I am happy if you go ahead and fix it!
OK, thanks. I will also separate Beaglebone from Cyclone V.

Thanks,
Daniel

Best regards,
Takuo Koguchi



-----Original Message-----
From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: Wednesday, June 28, 2017 5:52 PM
To: 小口琢夫 / KOGUCHI,TAKUO; cip-dev@...
Cc: 'Chris Paterson'
Subject: [!]RE: Project-X (minimal root filesystem) for renesas
board

Ho Koguchi-san

-----Original Message-----
From: 小口琢夫 / KOGUCHI,TAKUO
[mailto:takuo.koguchi.sw@...]
Sent: Wednesday, June 28, 2017 5:35 PM
To: Daniel Sangorrin; cip-dev@...
Cc: 'Chris Paterson'
Subject: RE: Project-X (minimal root filesystem) for renesas
board

Hi Daniel-san,

I have a few questions:
- Why do you have two directories "linux-cip" and
"linux-cip2" that are almost
identical?

linux-cip directory is for linux-4.4.55-cip3.
linux-cip2 is for the previous release and it is not necessary if you
update linux-cip.

I think this is not a good approach. We would need to have a new
linux-cip folder for each release.

Patches for the cyclone board should be on its own CIP kernel
repository (where you can merge cip releases and add tags). Then,
we can choose which version we want by specifying the repository and
tag/commit_id.

- I can see some xserver-related definitions on the board's
configuration file. Are those necessary?
beaglebone.conf is based on poky/meta-yocto-bsp/conf/machine.
xserver-related definition was inculude in the original. I am not sure if
it is necessary.

I don't think it is necessary since the CIP root filesystem only supports a
few packages.
Do you mind if I rewrite this and other unnecessary definitions?

Thanks,
Daniel



Takuo Koguchi


-----Original Message-----
From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: Wednesday, June 28, 2017 4:05 PM
To: cip-dev@...; 小口琢夫 / KOGUCHI,TAKUO
Cc: 'Chris Paterson'
Subject: [!]Project-X (minimal root filesystem) for renesas
board

Hi Koguchi-san,
Cc: Chris, cip-dev

I'm going to add support to project-X for the Renesas iwg20m
board which is equipped with an armv7 chip.
I have noticed that you added support for beaglebone and cyclone
on the deby-armv7 folder [1].

I have a few questions:
- Why do you have two directories "linux-cip" and
"linux-cip2" that are almost
identical?
- I can see some xserver-related definitions on the board's
configuration file. Are those necessary?

Thanks,
Daniel

[1]
https://gitlab.com/cip-playground/project-x/tree/master/deby-arm
v7


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

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


Re: Project-X (minimal root filesystem) for renesas board

Chris Paterson
 

Hello Daniel, all,

From: cip-dev-bounces@... [mailto:cip-dev-bounces@...
project.org] On Behalf Of Daniel Sangorrin
Sent: 07 July 2017 03:41

Hi Agustin, Chris

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Agustin
Benito Bethencourt
Sent: Thursday, June 29, 2017 5:21 PM
To: cip-dev@...
Subject: Re: [cip-dev] Project-X (minimal root filesystem) for renesas
board

Hi,

On 29/06/17 02:37, Daniel Sangorrin wrote:
Hi Koguchi-san,

-----Original Message-----
From: 小口琢夫 / KOGUCHI,TAKUO
[mailto:takuo.koguchi.sw@...]
Sent: Wednesday, June 28, 2017 6:08 PM
To: 'Daniel Sangorrin'; cip-dev@...
Cc: 'Chris Paterson'
Subject: RE: RE: Project-X (minimal root filesystem) for renesas
board

Daniel-san,

I think this is not a good approach. We would need to have a new
linux-cip folder for each release.
Let make it clear. Will you please describe your recommendation?
Yes, please see below.

Patches for the cyclone board should be on its own CIP kernel
repository (where you can merge cip releases and add tags). Then,
we can choose which version we want by specifying the repository and
tag/commit_id.
Good point. But CIP kernel repository is curerntly used for
release assuming it is tested. And CycloneV is not supported by CIP
at
this
moment. So I put the patches in the yocto project way.
I didn't mean to put it on Ben's CIP repository rather on github.
This way you can better maintain your "out-of-tree" cyclone V
patches
and merge (do not rebase please) changes from Ben's CIP kernel regularly.
In other words, do the same as Renesas is doing at [1].

[1] https://github.com/renesas-rz/renesas-cip
In order to have all the cip related code in one place, it would be
good, if anybody is using github, that at least there is a mirror of
that repo in gitlab. When we start automating builds/test, that would
be helpful.
Agustin: I don't mind, but is this necessary?.
Chris: Will you create another repository for u-boot?
Sorry for the delay.

u-boot source for the RZ/G1-M iWave platform is now available [1].

We've tested this using the gcc-arm-none-eabi-5_4-2016q3 [2] compiler:

export PATH=/opt/gcc-arm-none-eabi-5_4-2016q3/bin:$PATH
export CROSS_COMPILE=arm-none-eabi-
export ARCH=arm
make iwg20m_q7_config
make

The u-boot binary can be loaded onto the platform using JTAG or by writing it to the eMMC (be very careful though as this overwrites the current u-boot, so if it goes wrong you'll need JTAG to un-brick the board). Instructions can be found in the Software User Guide included on the CD which comes with the platform.


[1] https://github.com/renesas-rz/renesas-u-boot-cip/tree/2013.01.01/rzg1-iwave
[2] https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads

Kind regards, Chris


Thanks,
Daniel





I don't think it is necessary since the CIP root filesystem only supports a
few packages.
Do you mind if I rewrite this and other unnecessary definitions?
I am happy if you go ahead and fix it!
OK, thanks. I will also separate Beaglebone from Cyclone V.

Thanks,
Daniel

Best regards,
Takuo Koguchi



-----Original Message-----
From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: Wednesday, June 28, 2017 5:52 PM
To: 小口琢夫 / KOGUCHI,TAKUO; cip-dev@...
Cc: 'Chris Paterson'
Subject: [!]RE: Project-X (minimal root filesystem) for renesas
board

Ho Koguchi-san

-----Original Message-----
From: 小口琢夫 / KOGUCHI,TAKUO
[mailto:takuo.koguchi.sw@...]
Sent: Wednesday, June 28, 2017 5:35 PM
To: Daniel Sangorrin; cip-dev@...
Cc: 'Chris Paterson'
Subject: RE: Project-X (minimal root filesystem) for renesas
board

Hi Daniel-san,

I have a few questions:
- Why do you have two directories "linux-cip" and
"linux-cip2" that are almost
identical?

linux-cip directory is for linux-4.4.55-cip3.
linux-cip2 is for the previous release and it is not necessary if you
update linux-cip.

I think this is not a good approach. We would need to have a new
linux-cip folder for each release.

Patches for the cyclone board should be on its own CIP kernel
repository (where you can merge cip releases and add tags). Then,
we can choose which version we want by specifying the repository and
tag/commit_id.

- I can see some xserver-related definitions on the board's
configuration file. Are those necessary?
beaglebone.conf is based on poky/meta-yocto-bsp/conf/machine.
xserver-related definition was inculude in the original. I am not sure if
it is necessary.

I don't think it is necessary since the CIP root filesystem only supports a
few packages.
Do you mind if I rewrite this and other unnecessary definitions?

Thanks,
Daniel



Takuo Koguchi


-----Original Message-----
From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: Wednesday, June 28, 2017 4:05 PM
To: cip-dev@...; 小口琢夫 / KOGUCHI,TAKUO
Cc: 'Chris Paterson'
Subject: [!]Project-X (minimal root filesystem) for renesas
board

Hi Koguchi-san,
Cc: Chris, cip-dev

I'm going to add support to project-X for the Renesas iwg20m
board which is equipped with an armv7 chip.
I have noticed that you added support for beaglebone and cyclone
on the deby-armv7 folder [1].

I have a few questions:
- Why do you have two directories "linux-cip" and
"linux-cip2" that are almost
identical?
- I can see some xserver-related definitions on the board's
configuration file. Are those necessary?

Thanks,
Daniel

[1]
https://gitlab.com/cip-playground/project-x/tree/master/deby-arm
v7


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

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


Re: CIP testing project. Action 2. Data flow diagram draft

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

Hi,

On 03/08/17 01:49, Daniel Sangorrin wrote:
Hi Agustín,

-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Agustin Benito Bethencourt
Sent: Thursday, August 03, 2017 12:23 AM
To: cip-dev@...
Subject: [cip-dev] CIP testing project. Action 2. Data flow diagram draft

Hi,

please find attached an initial version of the data flow chart of the
testing project using B@D. This is a high level view (level 0).
Looks good. Maybe the test maintainer also wants to check the test results.
I first had the maintainers (kernel and tests) both checking the results but I changed it to focus on the testing data flow only, not on the maintainers/maintenance data flow. It is arguable though.


I will try in the coming days to go down one level to provide more
detail. Hopefully I will be able to improve the look and field too. Any
designer around ? :-)
The colours are a bit dull, I suggest increasing the saturation.
I think the diagram is too colourful, too bright, it has too much contrast. In coming versions I will try to improve it.



Any feedback is welcome.
Thanks for the comments


You can find info about data flow diagrams in these links:
* Examples:
https://www.visual-paradigm.com/tutorials/data-flow-diagram-example-food-ordering-system.jsp
* Symbols:
https://www.lucidchart.com/pages/data-flow-diagram/data-flow-diagram-symbols
* Definition: https://en.wikipedia.org/wiki/Data_flow_diagram

Saludos
Saludos ;)
Daniel

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

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


Re: CIP testing project. Action 2. Data flow diagram draft

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Agustín,

-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Agustin Benito Bethencourt
Sent: Thursday, August 03, 2017 12:23 AM
To: cip-dev@...
Subject: [cip-dev] CIP testing project. Action 2. Data flow diagram draft

Hi,

please find attached an initial version of the data flow chart of the
testing project using B@D. This is a high level view (level 0).
Looks good. Maybe the test maintainer also wants to check the test results.

I will try in the coming days to go down one level to provide more
detail. Hopefully I will be able to improve the look and field too. Any
designer around ? :-)
The colours are a bit dull, I suggest increasing the saturation.


Any feedback is welcome.

You can find info about data flow diagrams in these links:
* Examples:
https://www.visual-paradigm.com/tutorials/data-flow-diagram-example-food-ordering-system.jsp
* Symbols:
https://www.lucidchart.com/pages/data-flow-diagram/data-flow-diagram-symbols
* Definition: https://en.wikipedia.org/wiki/Data_flow_diagram

Saludos
Saludos ;)
Daniel

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


CIP testing project. Action 2. Data flow diagram draft

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

Hi,

please find attached an initial version of the data flow chart of the testing project using B@D. This is a high level view (level 0).

I will try in the coming days to go down one level to provide more detail. Hopefully I will be able to improve the look and field too. Any designer around ? :-)

Any feedback is welcome.

You can find info about data flow diagrams in these links:
* Examples: https://www.visual-paradigm.com/tutorials/data-flow-diagram-example-food-ordering-system.jsp
* Symbols: https://www.lucidchart.com/pages/data-flow-diagram/data-flow-diagram-symbols
* Definition: https://en.wikipedia.org/wiki/Data_flow_diagram

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


Re: Kernel maintenance and CIP testing report weeks 28, 29 and 30

Robert Marshall <robert.marshall@...>
 

Hi, some comments on the individual issues below.

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

Dear CIP friends,

this is the report of the major actions related with those activities
led by Codethink Ltd. Some of the reported topics were already
communicated through this mailing list.

++ Kernel maintenance

1. Backported of the basic support for the Renesas board (family) has
been merged.

2. The first round of kernel features review has been provided. Some
feedback is still pending. Ben H. participated in the CIP TSC
bi-weekly call.

3. Now we need to define the next steps in the kernel maintenance front.

4. As usual, Ben H. is contributing to the upstream 4.4 LTS cycle.

++ CIP Testing

1. E-mail configuration in LAVA is done. Robert Marshall is publishing
the outcome of the basic health checks in the cip-testing-results
mailing list. Feel free to join:
https://lists.cip-project.org/mailman/listinfo/cip-testing-results The
documentation for CIP members to send reports through mail is work in
progress. https://gitlab.com/cip-project/cip-testing/testing/issues/102
Some documentation has been added to the wiki detailing how to set this up
I'll be adding more information there.


2. B@D now works on a W10 machine with little additional
configurations. Both, Windows and Linux users share the same
installations and configuration steps except when specifically
mentioned. Waiting to receive feedback from
Members. https://gitlab.com/cip-project/cip-testing/testing/issues/106

3. A change in git://git.linaro.org/qa/test-definitions.git had a
major impact in B@D. It has been fixed
now. https://gitlab.com/cip-project/cip-testing/testing/issues/116

4. There is progress in using B@D behind a web
proxy. https://gitlab.com/cip-project/cip-testing/testing/issues/99

5. Robert has started the trials to update the LAVA version shipped
with B@D. It includes several fixed to issues we are facing plus
several improvements we will need in the near
future. https://gitlab.com/cip-project/cip-testing/testing/issues/114
I have a provisioned box with the latest version of lava - however there
are problems with authentication that I'm currently investigating.

Once that is working I expect to look at how to attach health check
results to LAVA notifications
https://gitlab.com/cip-project/cip-testing/testing/issues/118

and then consider the issues involved in allowing users who are not the
original tester to import those results into their own B@D instance.

We will also need to investigate how tests and be signed and how LAVA
will verify those signatures.


Robert


6. Other topics

* Some weeks ago we reported to the LAVA team an issue that has
already been fixed upstream. Another good reason for updating
LAVA. https://gitlab.com/cip-project/cip-testing/testing/issues/84

* Several issues has been fixed like tickets #112, #92

* As reported, new repositories has been created and
populated. https://gitlab.com/cip-project/cip-testing/testing/issues/100
** We are starting to populate CIP-kernel-test-logs repository as a
first step towards publishing the "passed test" logs in a public repo
in order to compare the logs from tests done by other Members.

* There is no room for celebrating the CIP workshop at ELCE during the
even. We will need to include it the previous day, right after the CIP
TSC f2f meeting.

* At least Agustin B.B. and Ben H. will attend to ELCE.


Kernel maintenance and CIP testing report weeks 28, 29 and 30

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

Dear CIP friends,

this is the report of the major actions related with those activities led by Codethink Ltd. Some of the reported topics were already communicated through this mailing list.

++ Kernel maintenance

1. Backported of the basic support for the Renesas board (family) has been merged.

2. The first round of kernel features review has been provided. Some feedback is still pending. Ben H. participated in the CIP TSC bi-weekly call.

3. Now we need to define the next steps in the kernel maintenance front.

4. As usual, Ben H. is contributing to the upstream 4.4 LTS cycle.

++ CIP Testing

1. E-mail configuration in LAVA is done. Robert Marshall is publishing the outcome of the basic health checks in the cip-testing-results mailing list. Feel free to join: https://lists.cip-project.org/mailman/listinfo/cip-testing-results The documentation for CIP members to send reports through mail is work in progress. https://gitlab.com/cip-project/cip-testing/testing/issues/102

2. B@D now works on a W10 machine with little additional configurations. Both, Windows and Linux users share the same installations and configuration steps except when specifically mentioned. Waiting to receive feedback from Members. https://gitlab.com/cip-project/cip-testing/testing/issues/106

3. A change in git://git.linaro.org/qa/test-definitions.git had a major impact in B@D. It has been fixed now. https://gitlab.com/cip-project/cip-testing/testing/issues/116

4. There is progress in using B@D behind a web proxy. https://gitlab.com/cip-project/cip-testing/testing/issues/99

5. Robert has started the trials to update the LAVA version shipped with B@D. It includes several fixed to issues we are facing plus several improvements we will need in the near future. https://gitlab.com/cip-project/cip-testing/testing/issues/114

6. Other topics

* Some weeks ago we reported to the LAVA team an issue that has already been fixed upstream. Another good reason for updating LAVA. https://gitlab.com/cip-project/cip-testing/testing/issues/84

* Several issues has been fixed like tickets #112, #92

* As reported, new repositories has been created and populated. https://gitlab.com/cip-project/cip-testing/testing/issues/100
** We are starting to populate CIP-kernel-test-logs repository as a first step towards publishing the "passed test" logs in a public repo in order to compare the logs from tests done by other Members.

* There is no room for celebrating the CIP workshop at ELCE during the even. We will need to include it the previous day, right after the CIP TSC f2f meeting.

* At least Agustin B.B. and Ben H. will attend to ELCE.

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


Re: Kernel feature support - core features and debugging

Hidehiro Kawai
 

Hi Ben,

Thanks for the consideration and suggestion.

From: Ben Hutchings
Performance events (CONFIG_PERF_EVENTS) provide a significant attack
surface and generally allow unprivileged users to crash the system. If
you do need them enabled in production - which I can understand - you
might want to apply the Grsecurity/Debian/Android patch that disables
use by unprivileged users.
Is it difficult to support for super long term? I think it is up to
users to enable it or not.

User namespaces (CONFIG_USER_NS) open up a huge attack surface to
unprivileged users, which has resulted in a large number of privilege
escalation vulnerabilities. This is enabled in the plathome_obsvx1,
siemens_iot2000 and siemens_server configs. Do you need it?
I'm not sure how vulnerable it is, but I think we may want to adopt the
same approach with the CONFIG_PERF_EVENTS case.
https://github.com/copperhead/linux-hardened/commit/358b303ebdc0b4a74b66a41ddfd2a69322d5404a.patch

Best regards,

Hidehiro Kawai
Hitachi, Ltd. Research & Development Group


Re: Kernel feature support - architecture options and drivers

Hidehiro Kawai
 

Hello Ben,

I'm sorry for the late reply.

From: Behalf Of Ben Hutchings
nouveau (CONFIG_DRM_NOUVEAU) is enabled in the hitachi_omap config. I'm
not sure how this could be useful in an OMAP system, and I don't expect
the driver to be supportable. Please disable it.
e100 (CONFIG_E100) and e1000 (CONFIG_E1000) drivers are enabled in
several configs (hitachi_omap, plathome_obsvx1, siemens_server) but are
not maintained upstream. (Don't confuse e1000 with e1000e, which is for
PCI Express and is still maintained.) Please disable them.
These drivers are not used. We'll simply disable them.

USB-attached network drivers (CONFIG_USB_USBNET) are enabled in several
configs (hitachi_omap, toshiba_tegra, plathome_obsvx1) but few of them
seem to be properly maintained upstream. Do you need them?
It is used as a convenient network interface for engineering.
If it is difficult to support them for super long term, we don't mind
too much even if CIP doesn't support them.

KVM (CONFIG_VIRTUALIZATION) adds a large attack surface (guest-to-host)
and is likely to be hard to maintain in the long term. Several of the
configurations (hitachi_omap, plathome_obsvx1, siemens_iot2000,
siemens_server) enable this. Do you need it?
It is not used at this point, but may be need in the future.

As long as we don't use KVM to build up a multi tenant VM service,
i.e. all users are the same legitimate user, the security risk of
guest-to-host attack will not become higher. So with regard to the
security risk, it will not be a problem for some use cases.

/dev/kmem (CONFIG_DEVKMEM) is only rarely needed for kernel debugging,
but is enabled in many configs. Please disable it.

/dev/mem (CONFIG_DEVMEM) is needed by some userland drivers, though UIO
provides a cleaner way to do this. Please check whether you can disable
it.
I tried to grep executable files in /usr/{bin,sbin}, and I found multiple
commands which may access /dev/mem. But I'm not sure how much impact
disabling /dev/mem has on us. We also use /dev/mem for a user land
driver, but we will be able to reimplement it via UIO.


By the way, I think that `supporting a feature' is not the same as
`enabling a feature'. Does `please disable it' mean that this is a
suggestion for a secure config, or imply that CIP shouldn't support
this feature?

Best regards,

Hidehiro Kawai
Hitachi, Ltd. Research & Development Group


Re: change to the git://git.linaro.org/qa/test-definitions.git repos breaks the BBB health check

Robert Marshall <robert.marshall@...>
 

Robert Marshall <robert.marshall@...> writes:

Hi,

A change yesterday to the git://git.linaro.org/qa/test-definitions.git
repos, removing obsolete directories, has removed the ubuntu one that the
b@d BBB health check used so that the default beaglebone health check will
now fail. We're working on a fix!
The repos versions of the beaglebone black tests have been updated with
a valid test. If you have an already provisioned box you will need to
manually change the tests/bbb* files with this diff:


from: git
- path: ubuntu/smoke-tests-basic.yaml
+ path: common/dt-selftests.yaml
name: smoke-tests


Robert


change to the git://git.linaro.org/qa/test-definitions.git repos breaks the BBB health check

Robert Marshall <robert.marshall@...>
 

Hi,

A change yesterday to the git://git.linaro.org/qa/test-definitions.git
repos, removing obsolete directories, has removed the ubuntu one that the
b@d BBB health check used so that the default beaglebone health check will
now fail. We're working on a fix!

Robert


Re: Kernel feature support - architecture options and drivers

Jan Kiszka
 

On 2017-07-21 19:11, Ben Hutchings wrote:
On Fri, 2017-07-21 at 17:19 +0200, Jan Kiszka wrote:
On 2017-07-21 15:18, Ben Hutchings wrote:
Intel Quark support (CONFIG_X86_INTEL_QUARK) is enabled in the
siemens_iot2000 config. Are you really using Quark SoCs?
Yeah...
http://w3.siemens.com/mcms/pc-based-automation/en/industrial-iot/pages/default.aspx.
This revision will stop being shipped at latest in 2020, but there will
be a lot of these chips in the field until then.

Likely all needed patches will be in 4.13 (just still struggling to get
userspace software ported from the Intel BSP to mainline). So I'm
planning to submit the essential patches for CIP integration "soon".
I assume you're aware of erratum #24 affecting the LOCK prefix? There
seems to be no solution except to use Intel's forked version of binutils
which deletes the LOCK prefix.
That switch is even upstream. But, yeah, we need to rebuild everything
in userland from scratch and can't use, e.g., normal Debian packages.
For the next version, we software folks will be involved now.

I don't know if it's an issue for kernel
code, but probably not - the kernel shouldn't use LOCK if CONFIG_SMP is
not enabled, and in any case shouldn't get a page fault on such an
instruction..
Exactly, the kernel is fine as-is.

Jan

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


Re: Kernel feature support - architecture options and drivers

Ben Hutchings <ben.hutchings@...>
 

On Fri, 2017-07-21 at 17:19 +0200, Jan Kiszka wrote:
On 2017-07-21 15:18, Ben Hutchings wrote:
Intel Quark support (CONFIG_X86_INTEL_QUARK) is enabled in the
siemens_iot2000 config. Are you really using Quark SoCs?
Yeah...
http://w3.siemens.com/mcms/pc-based-automation/en/industrial-iot/pages/default.aspx.
This revision will stop being shipped at latest in 2020, but there will
be a lot of these chips in the field until then.

Likely all needed patches will be in 4.13 (just still struggling to get
userspace software ported from the Intel BSP to mainline). So I'm
planning to submit the essential patches for CIP integration "soon".
I assume you're aware of erratum #24 affecting the LOCK prefix? There
seems to be no solution except to use Intel's forked version of binutils
which deletes the LOCK prefix. I don't know if it's an issue for kernel
code, but probably not - the kernel shouldn't use LOCK if CONFIG_SMP is
not enabled, and in any case shouldn't get a page fault on such an
instruction..

uhci-hcd (CONFIG_USB_UHCI_HCD) is for obsolete hardware (so far as I
know) but is enabled in the plathome_obsvx1, siemens_server and toshiba
x86 configs. Please disable it.
You need it for old USB 2.0 chipsets that have separate USB 1.1 and 2.0
interfaces. Those would then no longer word with 1.1 devices. But I bet
none of the provided products contain that.
I know there were some UHCI/EHCI pairings but I haven't seen a UHCI in a
long time.

KVM (CONFIG_VIRTUALIZATION) adds a large attack surface (guest-to-host)
and is likely to be hard to maintain in the long term. Several of the
configurations (hitachi_omap, plathome_obsvx1, siemens_iot2000,
siemens_server) enable this. Do you need it?
Not on the IOT2000 (f...ine Yocto rules made that pop up, I still need
to convert to a plain defconfig), not for production purposes on our
server, but we do have products (not listed so far) with KVM.

With - buzzword alarm - "edge computing", it is getting more and more
important as isolation tool for "apps". Containers/namespaces are
sometimes not strong enough.
[...]

I understand that - just trying to check that is actually being used.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Kernel feature support - core features and debugging

Ben Hutchings <ben.hutchings@...>
 

This is the third and last part. There are actually a few features that
I'm recommending to *enable* here.

All the configs I was given *disable* the stack protector
(CONFIG_CC_STACKPROTECTOR_NONE enabled). Please enable
CONFIG_CC_STACKPROTECTOR_REGULAR or CONFIG_CC_STACKPROTECTOR_STRONG
instead.

Some configs disable heap randomisation (CONFIG_COMPAT_BRK enabled), but
this is only necessary for old C libraries and it weakens. Please
enable heap randomisation by default, i.e. disable CONFIG_COMPAT_BRK.

Module symbol versioning (CONFIG_MODVERSIONS) is disabled in some
configs. Consider enabling it in order to catch mistakes.

Performance events (CONFIG_PERF_EVENTS) provide a significant attack
surface and generally allow unprivileged users to crash the system. If
you do need them enabled in production - which I can understand - you
might want to apply the Grsecurity/Debian/Android patch that disables
use by unprivileged users.

Obsolete syscalls (CONFIG_SGETMASK_SYSCALL, CONFIG_SYSCTL_SYSCALL,
CONFIG_SYSFS_SYSCALL, CONFIG_UID16, CONFIG_USELIB) are enabled in some
configs. Consider disabling these.

Deprecated sysfs entries (CONFIG_SYSFS_DEPRECATED,
CONFIG_SYSFS_DEPRECATED_V2) are enabled in the toshiba powerpc config.
This is incompatible with current udev and other tools. Please disable
them.

User namespaces (CONFIG_USER_NS) open up a huge attack surface to
unprivileged users, which has resulted in a large number of privilege
escalation vulnerabilities. This is enabled in the plathome_obsvx1,
siemens_iot2000 and siemens_server configs. Do you need it?

Magic Sysrq (CONFIG_MAGIC_SYSRQ) can leak sensitive information if it's
possible for an untrusted user to invoke it. Consider setting
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x01b6 (this is what Debian uses) or
some other restrictive mask for production builds.

Linked list debug checks (CONFIG_LIST_DEBUG) are disabled in all
configs. Consider enabling them as these can make it harder to exploit
some bugs.

Kernel timer statistics (CONFIG_TIMER_STATS) have been removed upstream,
but are enabled in toshiba_zynq and plathome_obsvx1 configs. Apparently
there are tracepoints that provide similar functionality. Please
disable this.

Kernel shared memory (CONFIG_KSM) has an inherent security problem that
the merging of memory introduces a timing side-channel between VMs. On
systems vulnerable to Rowhammer, it can also be used to *modify* memory
belonging to other VMs. This is enabled in the toshiba_tegra,
plathome_obsvx1 and siemens_server configs. Please consider disabling
it.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: Kernel feature support - architecture options and drivers

Jan Kiszka
 

On 2017-07-21 15:18, Ben Hutchings wrote:
Intel Quark support (CONFIG_X86_INTEL_QUARK) is enabled in the
siemens_iot2000 config. Are you really using Quark SoCs?
Yeah...
http://w3.siemens.com/mcms/pc-based-automation/en/industrial-iot/pages/default.aspx.
This revision will stop being shipped at latest in 2020, but there will
be a lot of these chips in the field until then.

Likely all needed patches will be in 4.13 (just still struggling to get
userspace software ported from the Intel BSP to mainline). So I'm
planning to submit the essential patches for CIP integration "soon".

uhci-hcd (CONFIG_USB_UHCI_HCD) is for obsolete hardware (so far as I
know) but is enabled in the plathome_obsvx1, siemens_server and toshiba
x86 configs. Please disable it.
You need it for old USB 2.0 chipsets that have separate USB 1.1 and 2.0
interfaces. Those would then no longer word with 1.1 devices. But I bet
none of the provided products contain that.

KVM (CONFIG_VIRTUALIZATION) adds a large attack surface (guest-to-host)
and is likely to be hard to maintain in the long term. Several of the
configurations (hitachi_omap, plathome_obsvx1, siemens_iot2000,
siemens_server) enable this. Do you need it?
Not on the IOT2000 (f...ine Yocto rules made that pop up, I still need
to convert to a plain defconfig), not for production purposes on our
server, but we do have products (not listed so far) with KVM.

With - buzzword alarm - "edge computing", it is getting more and more
important as isolation tool for "apps". Containers/namespaces are
sometimes not strong enough.

I can contribute to reviewing patches when needed or talk to the current
maintainers to have a look as well. At least on x86, it is mature by
now. ARM seems to be catching up quickly.

/dev/mem (CONFIG_DEVMEM) is needed by some userland drivers, though UIO
provides a cleaner way to do this. Please check whether you can disable
it.
I just explained this these days to someone who wanted to build an API
around it. In current embedded, it can be tricky, but I'm with you and
will promote its removal further.


Chrome platform support (CONFIG_CHROME_PLATFORMS) is enabled in the
siemens_server config. Assuming you don't need to support these
platforms, please disable it.
Ack.

Jan

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


Re: Kernel feature support - architecture options and drivers

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

Dear CIP friends,

On 21/07/17 15:18, Ben Hutchings wrote:
Sorry for the delay in reviewing feature support. I previously reviewed
filesystems and networking options, and this covers most of the rest. I
will send one more mail after this covering the remaining options.

please remember that Ben H. will join us at the TSC bi-weekly call next Monday. It would be very good if you can take a look at this mail before the meeting.

Best Regards

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


Re: [PATCH 0/3] Add iWave RZ/G1M documentation

Ben Hutchings <ben.hutchings@...>
 

On Thu, 2017-07-20 at 09:48 +0100, Chris Paterson wrote:
This series adds iWave to the vendor list, and documents the iWave RZ/G1M
board.

Patches based on linux-4.4.y-cip 7bac4ad.
Applied and pushed, thanks.

Ben.

Biju Das (3):
of: Add vendor prefix for iWave Systems Technologies Pvt. Ltd
ARM: shmobile: document iW-RainboW-G20M-Qseven-RZG1M system on module
ARM: shmobile: document iW-RainboW-G20D-Qseven-RZG1M board

Documentation/devicetree/bindings/arm/shmobile.txt | 4 ++++
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
2 files changed, 5 insertions(+)
--
Ben Hutchings
Software Developer, Codethink Ltd.


Kernel feature support - architecture options and drivers

Ben Hutchings <ben.hutchings@...>
 

Sorry for the delay in reviewing feature support. I previously reviewed
filesystems and networking options, and this covers most of the rest. I
will send one more mail after this covering the remaining options.

# x86

a.out support (CONFIG_IA32_AOUT) is enabled in plathome_obsvx but is
only needed for programs built before about 1995! Please disable it.

Vsyscall emulation (CONFIG_LEGACY_VSYSCALL_EMULATE) should be disabled
as it's only needed by older C libraries. Please select
CONFIG_LEGACY_VSYSCALL_NONE instead.

The modify_ldt syscall (CONFIG_MODIFY_LDT_SYSCALL) and 16-bit code
support (CONFIG_X86_16BIT) should be disabled; they're only needed to
run WINE.

Intel Quark support (CONFIG_X86_INTEL_QUARK) is enabled in the
siemens_iot2000 config. Are you really using Quark SoCs?

X32 syscall support (CONFIG_X86_X32) adds some attack surface that is
not well-tested. Several of the configurations (plathome_obsvx1,
siemens_server and toshiba) enable this. Do you need it?

KVM old-style device assignment (CONFIG_KVM_DEVICE_ASSIGNMENT) is
deprecated and the feature has been removed upstream in 4.12, so it is
definitely not supportable. Only the plathome_obsvx1 config has this
enabled. Please disable it. If you are actually using this feature, it
should be replaced by VFIO.

i7300_idle (CONFIG_I7300_IDLE) has been removed upstream, but is enabled
in the plathome_obsvx1, siemens_server and toshiba configs). This is
only useful for the Intel i7300 chipset, so it should be fine to disable
it.

Several drivers (CONFIG_HP_WIRELESS, CONFIG_INTEL_RST,
CONFIG_INTEL_SMARTCONNECT) appear to only be useful for laptops, but are
enabled in the siemens_server config. Please consider disabling them.

SFI (CONFIG_SFI) seems to only be useful for Intel smartphone platforms,
but is enabled in the siemens_server config. Please disable it.

# Storage drivers

nbd (CONFIG_BLK_DEV_NBD) was not in good shape in 4.4, but is enabled in
plathome_obsvx1.config and
siemens_iot2000. Do you need it?

dm-cache (CONFIG_DM_CACHE) is marked as experimental in 4.4 and has
changed a lot upstream, which will make it hard to maintain. The
siemens_server config has it enabled. Do you need it?

dm-switch (CONFIG_DM_SWITCH) is marked as experimental in 4.4, but is
enabled in the siemens_server config. Do you need it?

MD multipath (CONFIG_MD_MULTIPATH) is "not under active development",
and should be replaced with dm-multipath. It is enabled in the
plathome_obsvx1, siemens_iot2000, and siemens_server configs. Do you
need it?

Many old SCSI drivers (CONFIG_BLK_DEV_3W_XXXX_RAID, CONFIG_SCSI_3W_9XXX,
CONFIG_SCSI_3W_SAS, CONFIG_SCSI_ACARD, CONFIG_SCSI_ADVANSYS,
CONFIG_SCSI_AM53C974, CONFIG_SCSI_BUSLOGIC, CONFIG_SCSI_DC395x,
CONFIG_SCSI_DMX3191D, CONFIG_SCSI_DPT_I2O, CONFIG_SCSI_EATA,
CONFIG_SCSI_GDTH, CONFIG_SCSI_IMM, CONFIG_SCSI_INIA100,
CONFIG_SCSI_INITIO, CONFIG_SCSI_IPS, CONFIG_SCSI_MVUMI,
CONFIG_SCSI_PMCRAID, CONFIG_SCSI_PPA, CONFIG_SCSI_QLOGIC_1280,
CONFIG_SCSI_SYM53C8XX_2, CONFIG_SCSI_WD719X, CONFIG_SCSI_AIC79XX,
CONFIG_SCSI_AIC7XXX, CONFIG_SCSI_AIC94XX, CONFIG_SCSI_ESAS2R,
CONFIG_MEGARAID_LEGACY, CONFIG_SCSI_MVSAS, CONFIG_SCSI_QLA_ISCSI) are
enabled in siemens_server config and I very much doubt you need any of
these. Please disable them.

# Graphics drivers

gma500 (CONFIG_DRM_GMA{3600,500,600}) is not maintained upstream and
will be unsupportable, but is enabled in the plathome_obsvx1 config. Do
you need it?

nouveau (CONFIG_DRM_NOUVEAU) is enabled in the hitachi_omap config. I'm
not sure how this could be useful in an OMAP system, and I don't expect
the driver to be supportable. Please disable it.

# Network drivers

Many old Ethernet drivers (CONFIG_TYPHOON, CONFIG_VORTEX,
CONFIG_NE2K_PCI, CONFIG_DNET, CONFIG_ETHOC, CONFIG_FEALNX, CONFIG_JME,
CONFIG_ADAPTEC_STARFIRE, CONFIG_AMD8111_ETH, CONFIG_PCNET32,
CONFIG_ATL1, CONFIG_ATL1C, CONFIG_ATL1E, CONFIG_ATL2, CONFIG_B44,
CONFIG_BCMGENET, CONFIG_CHELSIO_T1, CONFIG_DE2104X, CONFIG_DE4X5,
CONFIG_DM9102, CONFIG_NET_TULIP, CONFIG_ULI526X, CONFIG_WINBOND_840,
CONFIG_DL2K, CONFIG_SUNDANCE, CONFIG_HP100, CONFIG_SKY2, CONFIG_KS8842,
CONFIG_KSZ884X_PCI, CONFIG_ENC28J60, CONFIG_MYRI10GE, CONFIG_NATSEMI,
CONFIG_NS83820, CONFIG_S2IO, CONFIG_VXGE, CONFIG_FORCEDETH,
CONFIG_HAMACHI, CONFIG_YELLOWFIN, CONFIG_NETXEN_NIC, CONFIG_QLA3XXX,
CONFIG_QLGE, CONFIG_R6040, CONFIG_8139CP, CONFIG_8139TOO, CONFIG_ATP,
CONFIG_SC92031, CONFIG_SIS190, CONFIG_SIS900, CONFIG_EPIC100,
CONFIG_SMSC9420, CONFIG_CASSINI, CONFIG_HAPPYMEAL, CONFIG_NIU,
CONFIG_TEHUTI, CONFIG_TLAN, CONFIG_VIA_RHINE, CONFIG_VIA_VELOCITY,
CONFIG_WIZNET_W5100, CONFIG_WIZNET_W5300) are enabled in siemens_server
config and I very much doubt you need any of these. samsung-sxgbe
(CONFIG_SXGBE_ETH) is also enabled, but this hardware only exists in
Samsung SoCs. Please disable them.

e100 (CONFIG_E100) and e1000 (CONFIG_E1000) drivers are enabled in
several configs (hitachi_omap, plathome_obsvx1, siemens_server) but are
not maintained upstream. (Don't confuse e1000 with e1000e, which is for
PCI Express and is still maintained.) Please disable them.

sungem (CONFIG_SUNGEM) is enabled in the siemens_server and toshiba
powerpc configs, but I doubt that this driver is needed. Please
consider disabling it.

USB-attached network drivers (CONFIG_USB_USBNET) are enabled in several
configs (hitachi_omap, toshiba_tegra, plathome_obsvx1) but few of them
seem to be properly maintained upstream. Do you need them?

i2400m-usb (CONFIG_WIMAX_I2400M_USB) is enabled in plathome_obsvx1, but
is unmaintained upstream. Do you need it? (I also noted previously
that wimax in general is dead.)

Wifi drivers may be hard to support in the long term due to changes in
the softMAC (mac80211) driver API. However I will assume that they are
needed for some applications.

The ipw2x00 drivers (CONFIG_IPW2100, CONFIG_IPW2200) are not maintained
and only found in some old x86 systems, but is enabled in the
plathome_obsvx1 config. Please disable them.

zd1211rw (CONFIG_ZD1211RW) seems to be unmaintained but is enabled in
the plathome_obsvx1 config. Please disable it.

r8172u (CONFIG_R8712U) is in drivers/staging (and has been for nearly 7
years!) and is therefore unlikely to be supportable, but is enabled in
the siemens_iot2000 config. Do you need it?

# USB drivers

fotg210-hcd (CONFIG_USB_FOTG210_HCD) is a platform driver that doesn't
look usable on x86, but is enabled in the siemens_server config. Please
disable it.

uhci-hcd (CONFIG_USB_UHCI_HCD) is for obsolete hardware (so far as I
know) but is enabled in the plathome_obsvx1, siemens_server and toshiba
x86 configs. Please disable it.

ehset (CONFIG_USB_EHSET_TEST_FIXTURE) and usb3503
(CONFIG_USB_HSIC_USB3503) are unlikely to be needed but are enabled in
the siemens_server config. Please consider disabling them.

# Misc drivers

OProfile (CONFIG_OPROFILE) seems to be barely maintained and redundant
with perf, but all the configs still enable it (mostly because it's
enabled in upstream defconfigs). Please consider disabling it.

KVM (CONFIG_VIRTUALIZATION) adds a large attack surface (guest-to-host)
and is likely to be hard to maintain in the long term. Several of the
configurations (hitachi_omap, plathome_obsvx1, siemens_iot2000,
siemens_server) enable this. Do you need it?

/dev/kmem (CONFIG_DEVKMEM) is only rarely needed for kernel debugging,
but is enabled in many configs. Please disable it.

/dev/mem (CONFIG_DEVMEM) is needed by some userland drivers, though UIO
provides a cleaner way to do this. Please check whether you can disable
it.

Chrome platform support (CONFIG_CHROME_PLATFORMS) is enabled in the
siemens_server config. Assuming you don't need to support these
platforms, please disable it.

--
Ben Hutchings
Software Developer, Codethink Ltd.

8221 - 8240 of 8627