Hi Neil,
Apart from inlined answers below, job configuration and full log is attached.
On 04/12/2018 11:02, Neil Williams wrote:
On Tue, 4 Dec 2018 at 09:37, Andrejs Cainikovs Andrejs.Cainikovs@netmodule.com wrote:
Hi,
TWIMC: I got it working. However, I have noticed that last command in command sequence (at least for U-Boot) never waits for command prompt, so I had to update base-uboot.jinja2 to get past this issue.
Compare with : https://staging.validation.linaro.org/scheduler/job/245806
The last command issued to U-Boot should be boot and that is not expected to ever get to a U-Boot prompt. Yet LAVA does check for a U-Boot prompt occurring after that command, along with other failure indicators like Must RESET board to recover
You are, of course, right. I was not clear enough, and by last command I meant something else, which we can skip now. Obviously, my aim is to boot the DUT past the U-Boot into Linux, and then run some tests.
Please do more investigation on your end to work out if the problem is correctly fixed.
Now, when I'm looking at this patch which I prepared yesterday - I'm not sure whether it was indeed issue with last command in a sequence, or with `dhcp` command processing (there must be a reason why I moved `setenv serverip` to top, but I'm lazy to check. Just giving it back to community as it is in case someone will face something similar.
Please take the time to check. When vcu.jinja2 is properly debugged, a contribution to upstream (with supporting unit test) would be very welcome.
I have put some extra effort into debugging, and got working scenario without changing base-uboot.jinja2. I did this by setting `uboot_ipaddr_cmd` in device type template:
{% set uboot_ipaddr_cmd = 'sleep 5; setenv serverip {SERVER_IP}; dhcp' %}
However, I still realize this is a hack, and looking into the log I might be catching something:
- {"dt": "2018-12-04T12:47:23.731495", "lvl": "debug", "msg": "bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.', 'Retry time exceeded'] (timeout 00:04:56)"} - {"dt": "2018-12-04T12:47:23.746562", "lvl": "input", "msg": "sleep 5; setenv serverip 172.17.1.189; dhcp\n"} - {"dt": "2018-12-04T12:47:23.852418", "lvl": "target", "msg": "sleep 5; setenv serverip 172.17.1.189; dhcp"} - {"dt": "2018-12-04T12:47:23.857183", "lvl": "debug", "msg": "bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.', 'Retry time exceeded'] (timeout 00:04:56)"} - {"dt": "2018-12-04T12:47:23.862239", "lvl": "target", "msg": "setenv autoload no"} - {"dt": "2018-12-04T12:47:23.866570", "lvl": "input", "msg": "setenv serverip 172.17.1.189\n"}
It looks like prompt waiting is skipped in this particular block! Why?
https://master.lavasoftware.org/static/docs/v2/contribution-intro.html
Also, attaching updated device type config.
$ diff base-uboot.jinja2 base-uboot.jinja2.backup
19,21c19,20 < " - setenv serverip {SERVER_IP} < - " + uboot_ipaddr_cmd|default('dhcp') + "
< - sleep 1" ) -%}
" - " + uboot_ipaddr_cmd|default('dhcp') + " - setenv serverip {SERVER_IP}" ) -%}
This doesn't need a change to base-uboot.jinja2 - this can be done in the device-type which extends base-uboot.jinja2, supported by a unit test.
No, that's not true. `base_uboot_dhcp_command` variable from base-uboot.jinja2 is not overrideable by device type templates. Or did I missed something?
Best regards, Andrejs Cainikovs.
On 29/11/2018 16:38, Andrejs Cainikovs wrote:
Hi Neil,
On 29/11/2018 15:58, Neil Williams wrote:
On Thu, 29 Nov 2018 at 14:42, Andrejs Cainikovs Andrejs.Cainikovs@netmodule.com wrote:
Hi everyone,
I’m facing an issue when U-Boot commands are sent one after another
without waiting for a prompt. Obviously, device is not able to boot.
Excerpt from logs:
(Much better to attach the complete log as downloaded from the menu on the job detail page, it includes timestamps and other useful content.) I'm afraid the content you've pasted into your original doesn't help. Please attach the complete test job log file, don't paste it into the body of the email where it will be mangled.
Complete log attached.
What version of lava-server and lava-dispatcher are you running?
Latest from stretch-backports: 2018.11-1~bpo9+1
One thing would be to obtain a U-Boot device which is already available on staging.validation.linaro.org or another instance and known to be working, then borrow the config from that. If you have something like that available already, it'll make things easier.
Thanks for a hint, I'll have a look into this.
As you see, all commands that were sent between `dhcp` command and
until it was able to complete or fail are simply dropped.
Device type config:
{% extends 'base-uboot.jinja2' %}
{% set device_type = "vcu" %}
This line isn't required and a couple of other lines are the defaults.
{% set console_device = 'ttyS2' %}
{% set baud_rate = 115200 %}
{% set interrupt_prompt = 'Press s to abort autoboot' %}
{% set interrupt_char = 's' %}
{% set bootloader_prompt = '=>' %}
{% set uboot_mkimage_arch = 'arm' %}
{% set bootz_kernel_addr = '0x80000000' %}
{% set bootz_ramdisk_addr = '0x83000000' %}
{% set bootz_dtb_addr = '0x82000000' %}
{% set extra_kernel_args = 'ti_cpsw.rx_packet_max=1526' %}
{% set kernel_start_message = 'Welcome to' %}
Device config:
{% extends 'vcu.jinja2' %}
{% set connection_command = 'telnet lava-disp-1.local 7000' %}
{% set power_on_command = 'relay-ctrl --relay 1 --state on' %}
{% set power_off_command = 'relay-ctrl --relay 1 --state off' %}
{% set hard_reset_command = 'relay-ctrl --relay 1 --toggle' %}
Boot action block from job definition:
boot:
timeout:
minutes: 5method: u-boot
commands: ramdisk
auto_login:
login_prompt: 'am335x-nmhw21 login: ' username: rootprompts:
- 'fct@am335x-nmhw21:~# '
Have I misconfigured something? What I’m missing? Thanks!