Hey everyone!
As I got last problems solved, I am able to boot my device - but that doesn't work out to be reliable. During inspection of console output, I see that there are "random" chars where I don't expect them to be, these chars are the next command that gets sent - before the previous command is finished.
For me it seems as U-Boot bootloader-commands doesn't wait for the prompt. Can this be the case here? Or is something other going wrong?
Configuration basically the same as in https://lists.lavasoftware.org/archives/list/lava-users@lists.lavasoftware.o... Serial console of the device is connected via USB2Serial adapter which uses ser2net to make this available with Telnet (which seems to be the LAVA default way to go).
In console I can see things like this, e.g. when tftp command shows its progress, only '#' should be displayed, but there are chars in between: Loading: *################s#####################################e############ ###############t######################################e############ ########################n#####################################v####
The chars in there are "setenv" which is the next command that LAVA wants to execute.
This causes the boot to fail in some occurrences, e.g. if dhcp command is not yet fully executed and zImage already tried to load, thus it fails and boot fails. See attached (stripped to relevant parts) log for details.
As workaround I set character delay to 100 milliseconds, which seems to make it a bit more reliable, but that can only be a temporary solution, as the characters still appear at the wrong place.
Thanks in advance!
Stefan
Hello,
could you share the logs? It looks like lava is matching the previous prompt, not the current one. So LAVA is always in advance of one command.
Le ven. 24 mars 2023 à 10:51, Stefan < lists.lavasoftware.org_23@green-sparklet.de> a écrit :
Hey everyone!
As I got last problems solved, I am able to boot my device - but that doesn't work out to be reliable. During inspection of console output, I see that there are "random" chars where I don't expect them to be, these chars are the next command that gets sent - before the previous command is finished.
For me it seems as U-Boot bootloader-commands doesn't wait for the prompt. Can this be the case here? Or is something other going wrong?
Configuration basically the same as in https://lists.lavasoftware.org/archives/list/lava-users@lists.lavasoftware.o... Serial console of the device is connected via USB2Serial adapter which uses ser2net to make this available with Telnet (which seems to be the LAVA default way to go).
In console I can see things like this, e.g. when tftp command shows its progress, only '#' should be displayed, but there are chars in between: Loading: * ################s#####################################e############
###############t######################################e############
########################n#####################################v####
The chars in there are "setenv" which is the next command that LAVA wants to execute.
This causes the boot to fail in some occurrences, e.g. if dhcp command is not yet fully executed and zImage already tried to load, thus it fails and boot fails. See attached (stripped to relevant parts) log for details.
As workaround I set character delay to 100 milliseconds, which seems to make it a bit more reliable, but that can only be a temporary solution, as the characters still appear at the wrong place.
Thanks in advance!
Stefan _______________________________________________ Lava-users mailing list -- lava-users@lists.lavasoftware.org To unsubscribe send an email to lava-users-leave@lists.lavasoftware.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
Hi Remi,
good guess! I was able to test a bit more and found a workaround: Default string to recognize an U-Boot prompt (bootloader_prompt) is set to '=>'. Somehow this seems to match the equal sign in the string that happens in my bootlog: "Uncompressed size: 7007204 = 0x6AEBE4" - as you can see in the logs that I already attached in my first post. It always starts after this line to get garbled like this: "etenLoaded FPGA firmware" (a bit different every time, but always in that line)
So I tried setting the string to '=> ', that didn't work either.
What worked is setting bootloader_prompt to '=> $' Now it runs smoothly! I guess there's a bug in LAVA on recognizing the Bootloader prompt. At least I now have a workaround.
Best regards Stefan
On 4/7/2023 11:17 AM, Remi Duraffort wrote:
Hello,
could you share the logs? It looks like lava is matching the previous prompt, not the current one. So LAVA is always in advance of one command.
Le ven. 24 mars 2023 à 10:51, Stefan <lists.lavasoftware.org_23@green-sparklet.de mailto:lists.lavasoftware.org_23@green-sparklet.de> a écrit :
Hey everyone! As I got last problems solved, I am able to boot my device - but that doesn't work out to be reliable. During inspection of console output, I see that there are "random" chars where I don't expect them to be, these chars are the next command that gets sent - before the previous command is finished. For me it seems as U-Boot bootloader-commands doesn't wait for the prompt. Can this be the case here? Or is something other going wrong? Configuration basically the same as in https://lists.lavasoftware.org/archives/list/lava-users@lists.lavasoftware.org/thread/2S6CHLHFEZO5CGO2B34LXU5MJKY7WV63/ Serial console of the device is connected via USB2Serial adapter which uses ser2net to make this available with Telnet (which seems to be the LAVA default way to go). In console I can see things like this, e.g. when tftp command shows its progress, only '#' should be displayed, but there are chars in between: Loading: * ################s#####################################e############ ###############t######################################e############ ########################n#####################################v#### The chars in there are "setenv" which is the next command that LAVA wants to execute. This causes the boot to fail in some occurrences, e.g. if dhcp command is not yet fully executed and zImage already tried to load, thus it fails and boot fails. See attached (stripped to relevant parts) log for details. As workaround I set character delay to 100 milliseconds, which seems to make it a bit more reliable, but that can only be a temporary solution, as the characters still appear at the wrong place. Thanks in advance! Stefan _______________________________________________ Lava-users mailing list -- lava-users@lists.lavasoftware.org <mailto:lava-users@lists.lavasoftware.org> To unsubscribe send an email to lava-users-leave@lists.lavasoftware.org <mailto:lava-users-leave@lists.lavasoftware.org> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s-- Rémi Duraffort Principal Tech Lead Automation Software Team Linaro
Lava-users mailing list -- lava-users@lists.lavasoftware.org To unsubscribe send an email to lava-users-leave@lists.lavasoftware.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
lava-users@lists.lavasoftware.org
-
Remi Duraffort -
Stefan