EC firmware_DevMode.ec_wp test case fails…

[Martin Yan]

As I tested EC firmware_DevMode.ec_wp case,

$ /usr/bin/test_that --board=$BOARD 192.168.1.4 firmware_DevMode.ec_wp

The error messages are as followings,

 

///

Disabling keyboard controlled developer mode

Setting power_state to off

Setting power_state to on

…

Waiting 20 seconds for XMLRPC server to start.

<class 'socket.error'>([Errno 111] Connection refused)

Retrying in 1.043647 seconds...

<class 'httplib.BadStatusLine'>('')

Retrying in 0.805010 seconds...

<class 'httplib.BadStatusLine'>('')

Retrying in 1.120565 seconds...

<class 'httplib.BadStatusLine'>('')

Retrying in 1.349685 seconds...

<class 'httplib.BadStatusLine'>('')

Retrying in 1.230480 seconds...

<class 'httplib.BadStatusLine'>('')

…

….

raise BadStatusLine(line)

BadStatusLine: ''

///

 

Refer to Attached “20180402-firmware_devmode_ec_wp.zip” for more information.

 

Note:

firmware_FAFTSetup is passed prior to running this test case;

 

In recovery mode, dev mode can be enabled properly since “OS verification is OFF” is showed as reboot, and dev mode can be disabled (i.e. normal mode) properly too since “OS verification is ON” is showed as reboot;

 

After dev mode is disabled and system is reboot, the “welcome” window is showed (doesn’t show password log in window), then test server will show error messages mentioned above;

 

On DUT, “localhost~# /usr/share/vboot/bin/make_dev_firmware.sh” has been executed;

 

Prior to run test, As system is boot up in dev mode, “ssh dut” is executed, “known_hosts” unde /.ssh/ is created, does it fit in normal mode (i.e. dev disabling mode) either?

 

Did I miss anything?

 

Regards,

Martin

[Tom Wai-Hong Tam (談偉航)]

Hi Martin,

According to the log (results-1-firmware_DevMode.ec_wp/debug), it failed to start the XML server on the DUT. This XML server is a communication channel between the DUT and the server. Looks like the failure was caused by a cp error on initialization.

03/29 15:54:24.907 ERROR|rpc_server_tracker:0201| Failed to start XMLRPC server.

03/29 15:54:24.957 ERROR|rpc_server_tracker:0206| The log of XML RPC server:

[2018-03-29 13:56:16.860395] XMLRPC Server: Spinning up FAFT server

Traceback (most recent call last):

  File "/usr/local/autotest/cros/faft/rpc_server.py", line 39, in <module>

    main()

  File "/usr/local/autotest/cros/faft/rpc_server.py", line 31, in main

    server.register_instance(RPCFunctions())

  File "/usr/local/autotest/cros/faft/rpc_functions.py", line 113, in __init__

    self._updater = firmware_updater.FirmwareUpdater(self._os_if)

  File "/usr/local/autotest/cros/faft/utils/firmware_updater.py", line 68, in __init__

    self._setup_temp_dir()

  File "/usr/local/autotest/cros/faft/utils/firmware_updater.py", line 88, in _setup_temp_dir

    self.os_if.copy_file(original_shellball, working_shellball)

  File "/usr/local/autotest/cros/faft/utils/os_interface.py", line 178, in copy_file

    return self.run_shell_command(cmd)

  File "/usr/local/autotest/cros/faft/utils/os_interface.py", line 108, in run_shell_command

    self.shell.run_command(cmd)

  File "/usr/local/autotest/cros/faft/utils/shell_wrapper.py", line 55, in run_command

    (cmd, process.returncode))

autotest_lib.client.cros.faft.utils.shell_wrapper.ShellError: command cp -f /usr/sbin/chromeos-firmwareupdate /var/tmp/faft/autest/chromeos-firmwareupdate failed (code: 1)

You may do more investigation on why this cp command failed. Is your disk quota full? Does /usr/sbin/chromeos-firmwareupdate exist?

Tom

--
You received this message because you are subscribed to the Google Groups "faft users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to faft-users+...@chromium.org.

[Martin Yan]

Yes, “chromeos-firmwareupdate” utility doesn’t exist on DUT’s /usr/sbin/… directory.

We are investigating why this utility is missing on DUT, but a few more clarification questions,

 

1: “chromeos-firmwareupdate” utility exists on DUT in default as test OS is installed onto DUT? Or during FAFT test, test server downloads this utility onto DUT?

 

2: if this utility is built in OS image, “build_image –board=${BOARD} –noenable_rootfs_verificaiton test” should include this image if built correctly? Or need to build with “dev” but not “test”? (one of our engineers suspects).

 

Thanks,

Martin

[Tom Wai-Hong Tam (談偉航)]

On Mon, Apr 9, 2018 at 8:48 AM Martin Yan <Marti...@microchip.com> wrote:

Yes, “chromeos-firmwareupdate” utility doesn’t exist on DUT’s /usr/sbin/… directory.

We are investigating why this utility is missing on DUT, but a few more clarification questions,

 

1: “chromeos-firmwareupdate” utility exists on DUT in default as test OS is installed onto DUT? Or during FAFT test, test server downloads this utility onto DUT?

The chromeos-firmwareupdate should exist in the default base image. It is not affected by FAFT.

 

 

2: if this utility is built in OS image, “build_image –board=${BOARD} –noenable_rootfs_verificaiton test” should include this image if built correctly? Or need to build with “dev” but not “test”? (one of our engineers suspects).

Should be there. Is there any error or warning when you build the image?

[Martin Yan]

Hi Tom,

 

Per your recommendation, mchp can build chromeos-firmwareupdate package, and as it is copied into /usr/sbin/ directory on DUT, we can pass EC “firmware_DevMode.ec_wp” test case.

 

Thanks your help again!

 

Regards,

Martin

/////

Hi Martin,

 

As a workaround, you may try to create a firmware updater package that will build a local firmware updater from source.

 

Just remove all the dummy implementations from https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/chromeos-base/chromeos-firmware-null/chromeos-firmware-null-9999.ebuild

 

On another hand, we forwaded the request to the right team to give you access to the private overlay.

 

Tom

/////////

Hi Tom,

 

Per mchp engineer feedback for “chromeos-firmwareupdate” missing out TEST OS build,

 

///

Building Firmware Updater

The updater is provided by the virtual/chromeos-firmware package in Chromium OS source tree, which will be replaced and includes the chromeos-base/chromeos-firmware-${BOARD} package in private board overlays.

 

If I try

$ emerge-reef chromeos-firmware-reef

 

The command returns with an error stating it can’t find package “chromeos-firmware-reef”.  This proves Google has a private board overlay for reef that we don’t have access to.

///

How to get this package? Or can get reef “chromeos-firmwareupdate” utility directly?

Regards,

Martin