Date   

Re: [PATCH 00/14] EFI capsule update support for IOT2000 devices

Ben Hutchings <ben.hutchings@...>
 

On Wed, 2017-08-30 at 21:13 +0200, Jan Kiszka wrote:
Last chunk: This backports EFI capsule updates, primarily for the use
with the IOT2020 and IOT2040, the latter with Quark-proprietary security
header format. The feature should also work for the Galileo Gen 2 and,
at least conceptually, for any EFI capsule update compatible firmware.
[...]

Applied these, but shouldn't I also apply:

commit 62075e581802ea1842d5d3c490a7e46330bdb9e1
Author: Matt Fleming <matt@...>
Date: Fri May 6 22:39:27 2016 +0100

efi/capsule: Make efi_capsule_pending() lockless

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: [PATCH 00/25] EXAR UART support for IOT2040 device

Ben Hutchings <ben.hutchings@...>
 

On Wed, 2017-08-30 at 21:05 +0200, Jan Kiszka wrote:
Second chunk: This imports a number of preparatory patches in order to
fully exploit the PCI-attached dual-port EXAR with RS232/422/485 on the
IOT2040.

To avoid having to backport also API-changing patches for platform
devices, I've slightly modified two patches to use a communication
pattern that does not require these changes.
[...]

Applied this series, except the gpiolib additions which were needed
earlier.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: [PATCH 0/8] Basic support for IOT2000 devices

Ben Hutchings <ben.hutchings@...>
 

On Wed, 2017-08-30 at 20:52 +0200, Jan Kiszka wrote:
This is the first of 3 chunks to enable the CIP kernel for the IOT2000
devices. It has the side effect of improving also the support of the
by now discontinued Galileo Gen 2 board.

Features added:
- Ethernet MACs on IOT2000
- TI ADC108S102 on IOT2000 and Galileo
- I2C frequency tuning on IOT2000
- GPIO support for pca9685 PWMs on IOT2000 and Galileo
- interrupt support for PCAL9535 on IOT2000 and Galileo
[...]

Applied this series, along with the gpiolib additions already noted.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: [PATCH 6/8] pwm: pca9685: Allow any of the 16 PWMs to be used as a GPIO

Ben Hutchings <ben.hutchings@...>
 

On Wed, 2017-08-30 at 20:52 +0200, Jan Kiszka wrote:
From: Mika Westerberg <mika.westerberg@...>

commit bccec89f0a35f65302734d1cdb01479df0f33ac9 upstream.
[...]
@@ -87,6 +93,151 @@ static inline struct pca9685 *to_pca(struct pwm_chip *chip)
return container_of(chip, struct pca9685, chip);
}

+#if IS_ENABLED(CONFIG_GPIOLIB)
+static int pca9685_pwm_gpio_request(struct gpio_chip *gpio, unsigned int offset)
+{
+ struct pca9685 *pca = gpiochip_get_data(gpio);
[...]

gpiochip_get_data() doesn't exist in 4.4.

I've cherry-picked commits b08ea35a3296 "gpio: add a data pointer to
gpio_chip", 0cf3292cde22 "gpio: Add devm_ apis for gpiochip_add_data and
gpiochip_remove", and 3988d663c02f "gpiolib: Fix a WARN_ON that can
never trigger" before this. But you should have included them in this
patch series.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: B@D support Renesas iwg20m board - issue

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Binh,

-----Original Message-----
From: Binh Thanh. Nguyen [mailto:binh.nguyen.uw@...]
Sent: Monday, September 11, 2017 8:00 PM
Any updates on this topic?
I have no update. I was busy with other tasks with high priority. I will manage to back to this task from next week.
I will let you know if there is any update.
OK, I'm working on it now. There were several problems with your patches and we are upgrading to LAVA 2017.7.
Before you start please let me know so we don't overlap.

I have two questions:

1) Is there any reason for renesas-iwg20m.jinja2 not to extend base-
uboot.jinja2 as in beaglebone-black.jinja2? Why is it extending base.jinja2 and
then duplicating code from base-uboot.jinja2?
Beaglebone-black.jinja2 does not extend base-uboot.jinja2, I think you are checking the Beaglebone-black.jinja2 in board-at-desk-
single-dev. But As I check, we are using the available beaglebone-black.jinja2 from lava-server. You can check it after starting VM and
check the file /etc/lava-server/dispatcher-config/device-types/beaglebone-black.jinja2.
I also copied and modify that beaglebone-black.jinja2 as it is faster to develop for Renesas board.
Yes, I was looking into the one in board-at-desk which is the same as the one in lava-server for new versions of LAVA (including LAVA 2017.7).
https://gitlab.com/cip-project/cip-testing/board-at-desk-single-dev/blob/master/device-types/beaglebone-black.jinja2
https://git.linaro.org/lava/lava-server.git/tree/lava_scheduler_app/tests/device-types/beaglebone-black.jinja2

Was there any reason not to do the same with iwg20m? It looks much easier to override a few variables than
creating a complete template.

2) Why are you using the connect-renesas/connect-BBB.sh scripts instead of
'telnet localhost 8020'? LAVA already supports autologin.
After first time boot board, If I run healthcheck without script connect-renesas.sh, it will keep issuing 'reboot' command at the login
prompt.
Autologin only works from second time run healthcheck, when already logged in.
I was not able to make it auto login at the first time run healthcheck, If you have a solution that not need connect-renesas.sh script,
please share me.
I'm using the power_off_command and power_on_command to connect with a PDU (power distribution unit). Probably the reboot
command appears because you have not set these commands or do not have a PDU. I'm not sure why it needs to be these way, I will
ask to the mailing list in the future.
Ref: https://validation.linaro.org/static/docs/v2/lava-scheduler-device-dictionary.html

Thanks,
Daniel
-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Binh
Thanh. Nguyen
Sent: Thursday, August 10, 2017 10:53 PM
To: cip dev
Cc: O365-Toru Oishi
Subject: Re: [cip-dev] B@D support Renesas iwg20m board - issue

Hello Robert,

Thank you very much for your feedback.

-----Original Message-----
From: Robert Marshall [mailto:robert.marshall@...]
Sent: Monday, August 7, 2017 8:14 PM
To: cip dev <cip-dev@...>
Cc: Binh Thanh. Nguyen <binh.nguyen.uw@...>; O365-Toru
Oishi <toru.oishi.zj@...>
Subject: Re: [cip-dev] B@D support Renesas iwg20m board - issue

"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?
Yes, at that moment, it consistently failed.
Thanks for your reminding the healthcheck of BBB. I checked how BBB
run healthcheck and found that I need to make a script similar to
connectBBB.sh I attach two patches (following three previous patches) to fix
the soft reboot issue on Renesas board.
The patches are just for your reference , I will re-create full series of patches
after finish all remained works + test.
Next steps is to add deploy and test action into healthcheck. I will
follow your recommend to use local kernel image built in VM

Best regards,
Binh Nguyen



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-de
v/

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
Kind regards,
Binh Nguyen



Re: B@D support Renesas iwg20m board - issue

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

Hello Daniel,

Subject: RE: [cip-dev] B@D support Renesas iwg20m board - issue

Hi Binh, Robert:

Any updates on this topic?
I have no update. I was busy with other tasks with high priority. I will manage to back to this task from next week.
I will let you know if there is any update.


I have two questions:

1) Is there any reason for renesas-iwg20m.jinja2 not to extend base-
uboot.jinja2 as in beaglebone-black.jinja2? Why is it extending base.jinja2 and
then duplicating code from base-uboot.jinja2?
Beaglebone-black.jinja2 does not extend base-uboot.jinja2, I think you are checking the Beaglebone-black.jinja2 in board-at-desk-single-dev. But As I check, we are using the available beaglebone-black.jinja2 from lava-server. You can check it after starting VM and check the file /etc/lava-server/dispatcher-config/device-types/beaglebone-black.jinja2.
I also copied and modify that beaglebone-black.jinja2 as it is faster to develop for Renesas board.


2) Why are you using the connect-renesas/connect-BBB.sh scripts instead of
'telnet localhost 8020'? LAVA already supports autologin.
After first time boot board, If I run healthcheck without script connect-renesas.sh, it will keep issuing 'reboot' command at the login prompt.
Autologin only works from second time run healthcheck, when already logged in.
I was not able to make it auto login at the first time run healthcheck, If you have a solution that not need connect-renesas.sh script, please share me.


Thanks,
Daniel

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Binh
Thanh. Nguyen
Sent: Thursday, August 10, 2017 10:53 PM
To: cip dev
Cc: O365-Toru Oishi
Subject: Re: [cip-dev] B@D support Renesas iwg20m board - issue

Hello Robert,

Thank you very much for your feedback.

-----Original Message-----
From: Robert Marshall [mailto:robert.marshall@...]
Sent: Monday, August 7, 2017 8:14 PM
To: cip dev <cip-dev@...>
Cc: Binh Thanh. Nguyen <binh.nguyen.uw@...>; O365-Toru
Oishi <toru.oishi.zj@...>
Subject: Re: [cip-dev] B@D support Renesas iwg20m board - issue

"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?
Yes, at that moment, it consistently failed.
Thanks for your reminding the healthcheck of BBB. I checked how BBB
run healthcheck and found that I need to make a script similar to
connectBBB.sh I attach two patches (following three previous patches) to fix
the soft reboot issue on Renesas board.
The patches are just for your reference , I will re-create full series of patches
after finish all remained works + test.
Next steps is to add deploy and test action into healthcheck. I will
follow your recommend to use local kernel image built in VM

Best regards,
Binh Nguyen



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-de
v/

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
Kind regards,
Binh Nguyen


Re: B@D support Renesas iwg20m board - issue

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Binh, Robert:

Any updates on this topic?

I have two questions:

1) Is there any reason for renesas-iwg20m.jinja2 not to extend base-uboot.jinja2 as in beaglebone-black.jinja2? Why is it extending base.jinja2 and then duplicating code from base-uboot.jinja2?

2) Why are you using the connect-renesas/connect-BBB.sh scripts instead of 'telnet localhost 8020'? LAVA already supports autologin.

Thanks,
Daniel

-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Binh Thanh. Nguyen
Sent: Thursday, August 10, 2017 10:53 PM
To: cip dev
Cc: O365-Toru Oishi
Subject: Re: [cip-dev] B@D support Renesas iwg20m board - issue

Hello Robert,

Thank you very much for your feedback.

-----Original Message-----
From: Robert Marshall [mailto:robert.marshall@...]
Sent: Monday, August 7, 2017 8:14 PM
To: cip dev <cip-dev@...>
Cc: Binh Thanh. Nguyen <binh.nguyen.uw@...>; O365-Toru
Oishi <toru.oishi.zj@...>
Subject: Re: [cip-dev] B@D support Renesas iwg20m board - issue

"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?
Yes, at that moment, it consistently failed.
Thanks for your reminding the healthcheck of BBB. I checked how BBB run healthcheck and found that I need to make a script similar
to connectBBB.sh
I attach two patches (following three previous patches) to fix the soft reboot issue on Renesas board.
The patches are just for your reference , I will re-create full series of patches after finish all remained works + test.
Next steps is to add deploy and test action into healthcheck. I will follow your recommend to use local kernel image built in VM

Best regards,
Binh Nguyen



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


Re: Y2038 BoF at DebConf 2017

Maemalynn Meanor <maemalynn@...>
 

Thanks for sharing, Agustin! I’ll promote this article on our Twitter channel. 

Thanks,
Maemalynn

Maemalynn Meanor
PR Manager 
The Linux Foundation
Maemalynn@...
(602) 541-0356
Skype: Maemalynn





On Sep 7, 2017, at 1:45 AM, Agustin Benito Bethencourt <agustin.benito@...> wrote:

Hi,

summary of the BoF: https://lwn.net/Articles/732794/

Best Regards
--
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


Re: Project-X: Deby-based reference filesystems milestone achieved

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

Hi,

On 07/09/17 10:43, Daniel Sangorrin wrote:
Hi all,

I just added support in Project-X for the NE0-Nano-SoC Cyclone V board using the
CIP patched kernel provided by Koguchi-san (https://gitlab.com/cip-playground/linux-cip-cyclonev).
# Koguchi-san: thanks!

This completes the first milestone for Project-X, which added support for the Beaglebone Black,
Qemux86_64, Renesas iwg10m and NE0-Nano-SoC boards using Deby. All of them can be built with the
KAS tool (https://kas.readthedocs.io/en/latest/userguide.html) provided by Siemens
(or alternatively with a setup.sh script).

https://gitlab.com/cip-playground/project-x
Congratulations!


The next milestones are:
- to integrate them with B@D (I am currently working on the renesas board integration)
This will save us some time before ELCE. Thanks.

- to provide ISAR reference file systems (Jan: any plans about this? I can try but I have no experience with ISAR)

Thanks,
Daniel



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


Y2038 BoF at DebConf 2017

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

Hi,

summary of the BoF: https://lwn.net/Articles/732794/

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


Project-X: Deby-based reference filesystems milestone achieved

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi all,

I just added support in Project-X for the NE0-Nano-SoC Cyclone V board using the
CIP patched kernel provided by Koguchi-san (https://gitlab.com/cip-playground/linux-cip-cyclonev).
# Koguchi-san: thanks!

This completes the first milestone for Project-X, which added support for the Beaglebone Black,
Qemux86_64, Renesas iwg10m and NE0-Nano-SoC boards using Deby. All of them can be built with the
KAS tool (https://kas.readthedocs.io/en/latest/userguide.html) provided by Siemens
(or alternatively with a setup.sh script).

https://gitlab.com/cip-playground/project-x

The next milestones are:
- to integrate them with B@D (I am currently working on the renesas board integration)
- to provide ISAR reference file systems (Jan: any plans about this? I can try but I have no experience with ISAR)

Thanks,
Daniel


Re: B@D: mapping serial device to the VM for ser2net

Daniel Sangorrin <daniel.sangorrin@...>
 

Hello Robert,

-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Robert Marshall
Sent: Monday, September 04, 2017 9:22 PM
To: cip dev
Subject: Re: [cip-dev] B@D: mapping serial device to the VM for ser2net

Daniel

"Daniel Sangorrin" <daniel.sangorrin@...> writes:

Hi,

I'm trying to setup ser2net for LAVA to access the serial port output of the
Renesas iwg20m board via local telnet from within the B@D virtual machine.

I managed to get it working by using the Serial port settings window at
the Oracle VM Virtualbox Manager (GUI). In particular, I used port mode 'Host Device'
and '/dev/ttyUSB1' for the Path/Address (the device file name on the host).

That maps the host's /dev/ttyUSB1 to the VM's /dev/ttyS0, so I also had
to modify the /etc/ser2net.conf file and specify that port 2000 is supposed
to use a 115200 baud rate.

Although works fine (telnet localhost 2000), I see that you guys are using the
port 8020 for /dev/ttyUSB0 by default so I was wondering if there is a better strategy.
# I have also tried using the "USB" settings in the Virtualbox Manager (after installing
# the extension pack), but I haven't figured out how to it works yet
For the USB settings have you tried the config suggestions at the end of this page:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/beagleboneblackboard
points 15-16 intended for windows but should also work with debian

I don't remember changing my local ser2net.conf and wondered whether
8020 was a default (or is that what you're saying), but it's been quite
a few months since I set it up!
Yes, I had already tried those instructions but I couldn't see any devices showing up on my Virtualbox manager.
I solved the problem with these instructions:

$ sudo apt install virtualbox-ext-pack
$ sudo adduser $USER vboxusers

Now I can see the USB devices as in the instructions. Thanks for your help.

Regards,
Daniel





Robert

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


Re: B@D: mapping serial device to the VM for ser2net

Robert Marshall <robert.marshall@...>
 

Daniel

"Daniel Sangorrin" <daniel.sangorrin@...> writes:

Hi,

I'm trying to setup ser2net for LAVA to access the serial port output of the
Renesas iwg20m board via local telnet from within the B@D virtual machine.

I managed to get it working by using the Serial port settings window at
the Oracle VM Virtualbox Manager (GUI). In particular, I used port mode 'Host Device'
and '/dev/ttyUSB1' for the Path/Address (the device file name on the host).

That maps the host's /dev/ttyUSB1 to the VM's /dev/ttyS0, so I also had
to modify the /etc/ser2net.conf file and specify that port 2000 is supposed
to use a 115200 baud rate.

Although works fine (telnet localhost 2000), I see that you guys are using the
port 8020 for /dev/ttyUSB0 by default so I was wondering if there is a better strategy.
# I have also tried using the "USB" settings in the Virtualbox Manager (after installing
# the extension pack), but I haven't figured out how to it works yet
For the USB settings have you tried the config suggestions at the end of this page:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/beagleboneblackboard
points 15-16 intended for windows but should also work with debian

I don't remember changing my local ser2net.conf and wondered whether
8020 was a default (or is that what you're saying), but it's been quite
a few months since I set it up!

Robert


CIP testing and kernel maintenance report week 34 and 35

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

Hi,

a couple of weeks with some tangible results.

++ Kernel maintenance

* Renesas latest patch series review
* In progress
* Kernel features analysis.
* Ongoing discussion with several CIP Members through the cip-dev mailing list
* How to back-port upstream BSP patches to CIP kernel
* Support provided through cip-dev mailing list. Ongoing.
* New version of CIP Linux kernel published
* Linux 4.4.83-cip8
* ELCE: Talk about kernel maintenance approved.
* Check https://osseu17.sched.com/event/ByYa/maintaining-a-linux-kernel-for-13-years-you-must-be-kidding-me-we-need-at-least-30-agustin-benito-bethencourt-ben-hutchings-codethink-ltd

++ CIP testing project

* LAVA has been updated to 2017.7 version which will allow us to close a couple of issues that appeared in older versions and has been fixed in newer ones. #114 https://gitlab.com/cip-project/cip-testing/testing/issues/114
* MR under review and initramfs issues created.
* One of the issues that the new LAVA version fixes in this one, notified by us several weeks ago #84 https://gitlab.com/cip-project/cip-testing/testing/issues/84
* Status report sent a few days ago to the cip-dev mailing list
* Modifying the script to populate initramfs now that LAVA has been updated. #111 https://gitlab.com/cip-project/cip-testing/testing/issues/111
* Script is under review.
* Using the verbose mode in LAVA reports to provide more detailed info #115 https://gitlab.com/cip-project/cip-testing/testing/issues/115
* In progress.
* Bug. kernelci build of cip8 runs out of disk space #130 https://gitlab.com/cip-project/cip-testing/testing/issues/130
* Fixed
* B@D works behind a web proxy so #99 and #128 has been closed
* Error in kernelci with csrf token #128 https://gitlab.com/cip-project/cip-testing/testing/issues/128 closed
* Issues with installing when running behind a web proxy #99 https://gitlab.com/cip-project/cip-testing/testing/issues/99 closed
* As part of our contribution upstream, we keep notifying Linaro developers issues with the licenses files they are fixing diligently.
* B@D introduced at the AGL CIAT Meeting #132 https://gitlab.com/cip-project/cip-testing/testing/issues/132
* Discussed at the CIP testing tech meeting last Thursday
* Slides published on the wiki.
* Report sent to cip-dev mailing list
* New B@D release schedule #134 https://gitlab.com/cip-project/cip-testing/testing/issues/134
* In progress

++ Other tasks

* B@D 101 training session at CIP workshop during ELCE #126 https://gitlab.com/cip-project/cip-testing/testing/issues/126
* Preparation in progress
* Y2038 related meeting and CIP Kernel maintainers meeting at ELCE
* Preparation in progress
* CIP testing project journal started (experiment). Check https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/journal


Best Regards

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


B@D: mapping serial device to the VM for ser2net

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi,

I'm trying to setup ser2net for LAVA to access the serial port output of the
Renesas iwg20m board via local telnet from within the B@D virtual machine.

I managed to get it working by using the Serial port settings window at
the Oracle VM Virtualbox Manager (GUI). In particular, I used port mode 'Host Device'
and '/dev/ttyUSB1' for the Path/Address (the device file name on the host).

That maps the host's /dev/ttyUSB1 to the VM's /dev/ttyS0, so I also had
to modify the /etc/ser2net.conf file and specify that port 2000 is supposed
to use a 115200 baud rate.

Although works fine (telnet localhost 2000), I see that you guys are using the
port 8020 for /dev/ttyUSB0 by default so I was wondering if there is a better strategy.
# I have also tried using the "USB" settings in the Virtualbox Manager (after installing
# the extension pack), but I haven't figured out how to it works yet

Thanks,
Daniel


[PATCH v2 18/18] ARM: multi_v7_defconfig: Enable r8a774[35] SoCs

Biju Das <biju.das@...>
 

From: Simon Horman <horms+renesas@...>

Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs.

Signed-off-by: Simon Horman <horms+renesas@...>
Acked-by: Geert Uytterhoeven <geert+renesas@...>
(cherry picked from commit 0a2cd376019d5bfe8ddcf96a525c8dbd9b295e28)
Signed-off-by: Biju Das <biju.das@...>
---
arch/arm/configs/multi_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index cd7b198..f1ba3fb 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -80,6 +80,8 @@ CONFIG_ARCH_EMEV2=y
CONFIG_ARCH_R7S72100=y
CONFIG_ARCH_R8A73A4=y
CONFIG_ARCH_R8A7740=y
+CONFIG_ARCH_R8A7743=y
+CONFIG_ARCH_R8A7745=y
CONFIG_ARCH_R8A7778=y
CONFIG_ARCH_R8A7779=y
CONFIG_ARCH_R8A7790=y
--
1.9.1


[PATCH v2 17/18] ARM: shmobile: defconfig: Enable r8a774[35] SoCs

Biju Das <biju.das@...>
 

From: Simon Horman <horms+renesas@...>

Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs.

Signed-off-by: Simon Horman <horms+renesas@...>
Acked-by: Geert Uytterhoeven <geert+renesas@...>
(cherry picked from commit d234e29dae04b224a63e39bc29938fa77819b3f1)
Signed-off-by: Biju Das <biju.das@...>
---
arch/arm/configs/shmobile_defconfig | 2 ++
1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 3aef019..fb8094a 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -14,6 +14,8 @@ CONFIG_ARCH_EMEV2=y
CONFIG_ARCH_R7S72100=y
CONFIG_ARCH_R8A73A4=y
CONFIG_ARCH_R8A7740=y
+CONFIG_ARCH_R8A7743=y
+CONFIG_ARCH_R8A7745=y
CONFIG_ARCH_R8A7778=y
CONFIG_ARCH_R8A7779=y
CONFIG_ARCH_R8A7790=y
--
1.9.1


[PATCH v2 16/18] ARM: dts: iwg20d-q7: Add support for iWave G20D-Q7 board based on RZ/G1M

Biju Das <biju.das@...>
 

Add support for iWave RainboW-G20D-Qseven board based on RZ/G1M.

Signed-off-by: Biju Das <biju.das@...>
Reviewed-by: Chris Paterson <chris.paterson2@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit ad2c0558d0494b420cadd6e887ddab2cd4e27e48)

Conflicts:
arch/arm/boot/dts/Makefile
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 25 +++++++++++++++++++++++++
2 files changed, 26 insertions(+)
create mode 100644 arch/arm/boot/dts/r8a7743-iwg20d-q7.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..f8fd692 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -544,6 +544,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
r7s72100-genmai.dtb \
r8a73a4-ape6evm.dtb \
r8a7740-armadillo800eva.dtb \
+ r8a7743-iwg20d-q7.dtb \
r8a7778-bockw.dtb \
r8a7779-marzen.dtb \
r8a7790-lager.dtb \
diff --git a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
new file mode 100644
index 0000000..9b54783
--- /dev/null
+++ b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
@@ -0,0 +1,25 @@
+/*
+ * Device Tree Source for the iWave-RZG1M Qseven carrier board
+ *
+ * Copyright (C) 2017 Renesas Electronics Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a7743-iwg20m.dtsi"
+
+/ {
+ model = "iWave Systems RainboW-G20D-Qseven board based on RZ/G1M";
+ compatible = "iwave,g20d", "iwave,g20m", "renesas,r8a7743";
+
+ aliases {
+ serial0 = &scif0;
+ };
+};
+
+&scif0 {
+ status = "okay";
+};
--
1.9.1


[PATCH v2 15/18] ARM: dts: iwg20m: Add iWave RZG1M Qseven SOM

Biju Das <biju.das@...>
 

Add support for iWave RZG1M Qseven System On Module.
http://www.iwavesystems.com/rz-g1m-qseven-module.html

Signed-off-by: Biju Das <biju.das@...>
Reviewed-by: Chris Paterson <chris.paterson2@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit aabf13bac0046a1add4a3c39881ffb0abe692542)
---
arch/arm/boot/dts/r8a7743-iwg20m.dtsi | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
create mode 100644 arch/arm/boot/dts/r8a7743-iwg20m.dtsi

diff --git a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
new file mode 100644
index 0000000..001ca91
--- /dev/null
+++ b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
@@ -0,0 +1,29 @@
+/*
+ * Device Tree Source for the iWave-RZG1M-20M Qseven SOM
+ *
+ * Copyright (C) 2017 Renesas Electronics Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include "r8a7743.dtsi"
+
+/ {
+ compatible = "iwave,g20m", "renesas,r8a7743";
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0 0x40000000 0 0x20000000>;
+ };
+
+ memory@200000000 {
+ device_type = "memory";
+ reg = <2 0x00000000 0 0x20000000>;
+ };
+};
+
+&extal_clk {
+ clock-frequency = <20000000>;
+};
--
1.9.1


[PATCH v2 14/18] ARM: dts: r8a7743: Remove unit-address and reg from integrated cache

Biju Das <biju.das@...>
 

From: Geert Uytterhoeven <geert+renesas@...>

The Cortex-A15 cache controller is an integrated controller, and thus
the device node representing it should not have a unit-addresses or reg
property.

Fixes: 34e8d993a68ae459 ("ARM: dts: r8a7743: initial SoC device tree")
Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit 37f0c804e57ac93ca37a98aa5a210c6b73e6572a)
Signed-off-by: Biju Das <biju.das@...>
---
arch/arm/boot/dts/r8a7743.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 9227ab4..fde6327 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -31,9 +31,8 @@
next-level-cache = <&L2_CA15>;
};

- L2_CA15: cache-controller@0 {
+ L2_CA15: cache-controller-0 {
compatible = "cache";
- reg = <0>;
cache-unified;
cache-level = <2>;
};
--
1.9.1

9081 - 9100 of 9636