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: 5
>>>   >>
>>>   >>      method: u-boot
>>>   >>
>>>   >>      commands: ramdisk
>>>   >>
>>>   >>      auto_login:
>>>   >>
>>>   >>        login_prompt: 'am335x-nmhw21 login: '
>>>   >>
>>>   >>        username: root
>>>   >>
>>>   >>      prompts:
>>>   >>
>>>   >>      - 'fct@am335x-nmhw21:~# '
>>>   >>
>>>   >>
>>>   >>
>>>   >> Have I misconfigured something? What I’m missing? Thanks!
>>>   >
>>>   >
>>>   >
>>>
>
>
>