lava-users

lava-users@lists.lavasoftware.org

1 participants
942 discussions

Fwd: [EXT] Test jobs to boot the targets through trace32

by Nagendra Singamsetti

---------- Forwarded message --------- From: Nagendra Singamsetti <nag.singam91(a)gmail.com> Date: Fri, May 22, 2020 at 8:58 AM Subject: Re: [EXT] [Lava-users] Test jobs to boot the targets through trace32 To: Andrei Gansari <andrei.gansari(a)nxp.com> Hi Andrei, Good Morning !! *lava-dispatcher machine did not reach the serial on the device* I have debug the issue. Issue is telnet socket connection is not up. Now i am able to flash Renesas board using Jlink Debugger through LAVA. Attached job [image: lava_jlink_uboot_download.png] [image: lava_jlink_uboot_flash.png] Thanks!! for your good time to debug this issue. Now i am able to flash U-boot @specific offset say-0x18000000. Need to flash .dtb,Kernal & rootfs. Should i run again with different Job's or Can i run in single Job?? . Can you Please share your thoughts !! Regards Nagendra S On Thu, May 21, 2020 at 5:45 PM Nagendra Singamsetti <nag.singam91(a)gmail.com> wrote: > Hi Andrei, > Thanks for your kind response :) :) > > 1. > *Is your board flashed with the desired uboot? You can check by erasing > the flash and then running lava, the desired uboot should be flashed on the > board.* > Ans. Using lava, i am unable to flash with u boot also. As you mention I > have erased the flash up to 0 0x2000000 and tried again getting same > issue.error_msg: Invalid job data: ["Invalid device configuration - missing > 'commands'"]. > > 2.* Can you lava-dispatcher machine reach the serial on the device?* > Ans. In rza1h.jinja2, device-type file: i have added following commands to > open serial console > {% set console_device = console_device|default("ttyACM0") %} > {% set baud_rate = baud_rate|default(115200) %} > {% set bootloader_prompt = bootloader_prompt|default("=>") %} > > But i don't know* lava-dispatcher** machine reach the serial on the > device* or not. Due to job immediately terminated. > *Manually i am able to flash through JLink with following commands* : > JLinkExe -speed 15000 -if JTAG $JTAGCONF -device R7S721001 -CommanderScript > load_spi_uboot.txt > > *load_spi_uboot.txt contains following:* > rx 100 > exec SetSkipProgOnCRCMatch=0 > > // > // Download application into QSPI flash > // > > loadbin u-boot.bin,0x18000000 > //verifybin u-boot.bin,0x18000000 > > exit > > > 3. board_id:* '{{ board_id|default('0000000000') }}',usb_vendor_id: > '1366',usb_product_id: '0101' refers to JLink connected usb right. Can i > change directly in the device-type .jinja2 file.* > > I am very thankful, if you can share your sample device jinja2 , > device-type (jinja2 file) and working job description file. > I am just stuck with this issue issue.error_msg: Invalid job data: > ["Invalid device configuration - missing 'commands'"] from last 5 day's. i > gone through all the mail chain from lava-users but did not get proper > information.Don't know how to debug this issue. > Your presence and input is more valuable for me . > > I am attaching used job description and device& device-type .jinja files > for your reference. > > > > On Wed, May 20, 2020 at 4:04 PM Andrei Gansari <andrei.gansari(a)nxp.com> > wrote: > >> Hello Nagendra, >> >> >> >> Looks like *error_msg*: Invalid job data: ["Invalid device configuration >> - missing 'commands'"] is issued from serial.py so the validation reached >> executing serial commands. >> >> >> >> 1. Is your board flashed with the desired uboot? You can check by >> erasing the flash and then running lava, the desired uboot should be >> flashed on the board. >> 2. Can you lava-dispatcher machine reach the serial on the device? >> 3. Most likely it’s this pattern in job*.yaml it should look for the >> printed uboot header of prompt when the board is reset. The configuration >> below is used by Zephyr RTOS tests. >> >> - test: >> >> monitors: >> >> - name: tests >> >> * start: Running test suite common_test* >> >> * end: PROJECT EXECUTION SUCCESSFUL* >> >> * pattern: '(?P<result>(PASS|FAIL)) - (?P<test_case_id>.*)\.'* >> >> fixupdict: >> >> PASS: pass >> >> FAIL: fail >> >> >> >> Regards, >> >> Andrei G. >> >> >> >> *From:* Nagendra Singamsetti <nag.singam91(a)gmail.com> >> *Sent:* Tuesday, May 19, 2020 8:01 PM >> *To:* Andrei Gansari <andrei.gansari(a)nxp.com>; >> lava-users(a)lists.lavasoftware.org >> *Cc:* andrei.gansari(a)linaro.org >> *Subject:* Re: [EXT] [Lava-users] Test jobs to boot the targets through >> trace32 >> >> >> >> *Caution: *EXT Email >> >> Hi Andrei, Team, >> >> >> >> Issue is solved this is because of lava-server & remote worker version >> mismatch. I tried to boot the DUT (RZA1_RSA , Renesas) Using the >> rza1h.jinja2 file & job description with Segger Jlink debugger . I am >> getting following issue: >> >> - >> - *error_msg*: Invalid job data: ["Invalid device configuration - >> missing 'commands'"] >> - *error_type*: Job >> >> [image: renesas_jlink_Invalid_device_configuration.png] >> >> I am looking forward for your kind response.. >> >> >> >> thanks >> >> >> >> Regards >> >> Nagendra S >> >> >> >> >> >> On Tue, May 19, 2020 at 8:12 PM Nagendra Singamsetti < >> nag.singam91(a)gmail.com> wrote: >> >> Hello Andrei , Team, >> >> To get hands on knowledge, I have tried to boot Renesas images using >> JLink & Renesas - RZA1_RSA ver2 board on QSPI flash. >> >> I took frdm-k64f.janja2 file as a reference created *rza1h.jinja2* as a >> device-type. And added device as a *renesas_worker1(DUT)* under >> device-type *rza1h.* And connected to remote worker. >> >> On Remote worker, Segger Jlink debugger is connected to the DUT with jtag >> cable. >> >> >> >> But while submitting Job definition i am getting following error. >> >> >> >> [image: renesas_jlink_job_error.png] >> >> >> >> Attaching Job files and device-type file for reference. >> >> First time i am booting the hardware with Jlink using LAVA framework. >> Please help me out to debug this issue. >> >> >> >> Thanks >> >> >> >> Regards >> >> Nagendra S >> >> >> >> >> >> >> >> On Mon, Apr 27, 2020 at 5:28 PM Andrei Gansari <andrei.gansari(a)nxp.com> >> wrote: >> >> Please have a look at my pull requests: >> >> >> >> https://git.lavasoftware.org/lava/lava/-/merge_requests/608/diffs >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.lavas…> >> - script changes >> >> https://git.lavasoftware.org/lava/lava/-/merge_requests/758/diffs >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.lavas…> >> - job sample >> >> >> >> With JLink you need to install Segger’s software on the server where Lava >> dispatcher resides (in case you have multiple Lava servers). >> >> https://www.segger.com/downloads/jlink/#J-LinkSoftwareAndDocumentationPack >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.segge…> >> >> >> >> >> >> Regards, >> >> Andrei >> >> >> >> *From:* Nagendra Singamsetti <nag.singam91(a)gmail.com> >> *Sent:* Monday, April 27, 2020 12:42 PM >> *To:* Andrei Gansari <andrei.gansari(a)nxp.com> >> *Cc:* andrei.gansari(a)linaro.org; lava-users(a)lists.lavasoftware.org >> *Subject:* Re: [EXT] [Lava-users] Test jobs to boot the targets through >> trace32 >> >> >> >> *Caution: *EXT Email >> >> Hi Andrei, >> >> >> >> Wonderful!!, >> >> Thanks for your time .. >> >> I need bit support from you, don't mine :) ,Can you please share your >> Jink scripts. I will use these as a reference will write comparable boot >> method for trace32 . >> >> >> >> And if you can, Please share the appropriate Doc (link) to >> setup(interface) other software's in Lava server. Setup Jlink with Lava >> server also fine. >> >> >> >> >> >> Regards >> >> Nagendra S >> >> >> >> On Mon, Apr 27, 2020 at 2:10 PM Andrei Gansari <andrei.gansari(a)nxp.com> >> wrote: >> >> Hello Nagendra, >> >> >> >> JLink was added as most NXP mcus use this interface, there is no support >> for T32 in Lava as far as I know. >> >> Even if they use the same JTAG interface standard, Segger and Lauterbach >> use different hardware and software to interact. >> >> I’ve used JLinkExe command line software (from Segger) to control the >> debugger, in the case of T32 you will probably need to use Lauterbach’s >> Trace32 command line software + scripts, such as: >> https://stackoverflow.com/questions/24883140/controlling-trace32-via-comman… >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackover…> >> >> Haven’t used Trace32 GUI software for some years, never used the command >> line. >> >> >> >> You can probably create a flashing script starting form JLink scripts, >> you need to: >> >> - setup trace32 software on your Lava server >> - learn how to use the command to flash your board using a cmm script >> - change JLink scripts with T32 commands and cmm script generation >> - pull request your changes so others can benefit 😊 >> >> >> >> Andrei Gansari >> >> >> >> *From:* Lava-users <lava-users-bounces(a)lists.lavasoftware.org> *On >> Behalf Of *Nagendra Singamsetti >> *Sent:* Saturday, April 25, 2020 9:05 AM >> *To:* Kumar Gala <kumar.gala(a)linaro.org>; andrei.gansari(a)linaro.org >> *Cc:* lava-users(a)lists.lavasoftware.org >> *Subject:* [EXT] [Lava-users] Test jobs to boot the targets through >> trace32 >> >> >> >> *Caution: *EXT Email >> >> Hi Kumar, Andrei >> >> >> >> From the previous lava- mailing list i have seen that you people >> addressed jlink debugger information as like this : >> >> *On Thu, Jan 23, 2020 at 7:33 PM Andrei Gansari <andrei.gansari at nxp.com <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lav…>>* >> >> >>* wrote:* >> >> >> >> >> >>* From the screenshot it looks like you have a version of LAVA that does* >> >> >>* not support jlink boot method.* >> >> >> >> >> >>* JLink was added in version 2019.10-1* >> >> >> >> >> >> >>* On Tue, Nov 26, 2019 at 2:36 PM Andrei Gansari <andrei.gansari at nxp.com <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lav…>>* >> >> >>* wrote:* >> >> >> >> >> >>* I’ve tested lava+jlink on Cortex M with both onboard debugger and* >> >> >>* external debugger, like the one you referenced.* >> >> >> >> >> >>* You should change the following if needed:* >> >> >> >> >> >> >> >> >> >> >> >>* address:* >> >> >> >> >> >>* *0x00000000** >> >> >> >> >> >>* options:* >> >> >> >> >> >>* - '-device *MK64FN1M0xxx12'** >> >> >> >> >> >>* - '-if SWD'* >> >> >> >> >> >>* - '-speed 4000'* >> >> >> >> Can you please let me know, whether the latest lava version can support trace32 boot method instead jlink/cmsis-dac. trace32 debugger tool is designed by lauterbach and it is licensed one. >> >> I am bit afraid whether this support is available from lava server or not as Jlink support added recently. >> >> https://www2.lauterbach.com/pdf/app_t32start.pdf <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww2.laut…> >> >> We need trace32 debugger support as we are using cortex-M55 processor operations over here. >> >> I am looking forward your kind support >> >> >> >> thanks >> >> Regards >> >> Nagendra S >> >>

5 years, 9 months

About pdu script.

by Peter Lucas

Sorry, I missed title, send again. Hello, Milosz, Another question: I see your documentation suggest to use pdudaemon. But I had a look for you validation lava lab: https://validation.linaro.org/scheduler/device/hi6220-hikey-r2-02/devicedict, I see you use /usr/local/lab-scripts/snmp_pdu_control I want to know why your lab not use the one which you suggest? I had a look for pdudaemon, found it won't wait there until PDU operation finish. Will this have any issue? Will next logic start before the pdu really finish the operation?

5 years, 9 months

Test jobs to boot the targets through trace32

by Nagendra Singamsetti

Hi Kumar, Andrei >From the previous lava- mailing list i have seen that you people addressed jlink debugger information as like this : *On Thu, Jan 23, 2020 at 7:33 PM Andrei Gansari <andrei.gansari at nxp.com <https://lists.lavasoftware.org/mailman/listinfo/lava-users>> *>>* wrote: *>>>>* From the screenshot it looks like you have a version of LAVA that does *>>* not support jlink boot method. *>>>>* JLink was added in version 2019.10-1* >>* On Tue, Nov 26, 2019 at 2:36 PM Andrei Gansari <andrei.gansari at nxp.com <https://lists.lavasoftware.org/mailman/listinfo/lava-users>> *>>* wrote: *>>>>* I’ve tested lava+jlink on Cortex M with both onboard debugger and *>>* external debugger, like the one you referenced. *>>>>* You should change the following if needed: *>>>>>>>>* address: *>>>>* *0x00000000* *>>>>* options: *>>>>* - '-device *MK64FN1M0xxx12'* *>>>>* - '-if SWD' *>>>>* - '-speed 4000'* Can you please let me know, whether the latest lava version can support trace32 boot method instead jlink/cmsis-dac. trace32 debugger tool is designed by lauterbach and it is licensed one. I am bit afraid whether this support is available from lava server or not as Jlink support added recently. https://www2.lauterbach.com/pdf/app_t32start.pdf We need trace32 debugger support as we are using cortex-M55 processor operations over here. I am looking forward your kind support thanks Regards Nagendra S

5 years, 9 months

Question about serial.

by Peter Lucas

Dear Sir/Madam, I'm new to LAVA. I'm still in initial stage to use lava in our farm. I use customized board with Qualcomm's chip. Recently I met a question, a very simple job, sometimes when I start to operate uboot, the serial have chance to be closed. They I set retry in lava job, let it retry a lots of times, but looks never successfully open the serial again. But, after job finish, I quickly open the serial in manual, it's ok! I search your code a lot, and found in shell.py there is one comments, I want to know is this the reason that I failed to retry for serial? When will you fix it? *# FIXME: deliberately closing the connection (and starting a new one) needs to be supported.* *Cheers,* *Peter*

5 years, 9 months

Docker device basic setup

by Saheer Babu

Hi Lava folks, I am new to LAVA and trying to get some basic understand of lava. I am facing issues while I trying to set up a docker device in lava following the doc: https://lava.readthedocs.io/en/latest/admin/basic-tutorials/instance/instal… Steps followed: 1. I have installed Debian VM on my mac book pro. 2. Installed lava: https://lava.readthedocs.io/en/latest/admin/basic-tutorials/instance/instal… * Enabled lava site in apache “Production releases” https://docs.lavasoftware.org/lava/installing_on_debian.html (Btw, this step seems to be missing) * Config like “ALLOW_HOSTS<https://docs.lavasoftware.org/lava/advanced-installation.html?highlight=all…>”, CSRF etc: (a * Created one super user: https://lava.readthedocs.io/en/latest/admin/basic-tutorials/instance/config… * Created a token (for lavacli): sudo lava-server manage tokens add --user root 1. Setup docker device for running tests: https://lava.readthedocs.io/en/latest/admin/basic-tutorials/device-setup/do… ( I am following command line using lava-cli) * $LAVACLI device-types add docker * $LAVACLI devices add --type docker --worker buster.localdomain docker01 * $LAVACLI devices dict set docker01 test.jinja2 (test.jinja2 contains {% extend "docker.jinja2" %} ) * $LAVACLI devices update --health UNKNOWN docker01 After step “3”, I have the following error: “Configuration Error: missing or invalid template.” I am assuming there is some pre-condition I am not meeting for docker device. How can I get some more debug information on this? Can you help? Cheers, Saheer Babu IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 9 months

(no subject)

by Peter Lucas

Hello, Milosz, Another question: I see your documentation suggest to use pdudaemon. But I had a look for you validation lava lab: https://validation.linaro.org/scheduler/device/hi6220-hikey-r2-02/devicedict, I see you use /usr/local/lab-scripts/snmp_pdu_control I want to know why your lab not use the one which you suggest? I had a look for pdudaemon, found it won't wait there until PDU operation finish. Will this have any issue? Will next logic start before the pdu really finish the operation?

5 years, 9 months

Need help for 2020.05 release.

by Larry Shen

Hi, We have a problem here needs your help, as it's critical to us, could you give some suggestion? Thanks in advance. You know, we submit a MR here about reset shell: https://git.lavasoftware.org/lava/lava/-/merge_requests/1023 It's nearly compatible from 2018.11 to 2020.04 release when we patch it in local, the only changes I remember is once upon a time you changed all "internal_pipeline" to "pipeline", so we had to follow the new name. But in yesterday's 2020.05 release, I saw this commit: https://git.lavasoftware.org/lava/lava/-/commit/eefeef1864cc055c48215169b61… In this commit, the test action no longer been added as before like next: def __init__(self, parent, parameters): super().__init__(parent) self.action = TestShellRetry() self.action.job = self.job self.action.section = self.action_type parent.add_action(self.action, parameters) It becomes next: @classmethod def action(cls, parameters): return TestShellRetry() Correspondingly, in parse.py, it becomes from next: action(pipeline, parameters) to next: action = cls.action(parameters) That means "parent pipeline" no longer been passed to next level pipeline, parse.py will responsible for low level action inject into pipeline. Above change is the key issue we encountered as in our "ResetTestShell" we need to reuse the parameters of "Boot" in same namespace, we need it to operate UBoot & Login again after device reset, like next: def __init__(self, parent, parameters): super().__init__(parent) boot_action_para = None for per_action in parent.actions: if per_action.parameters["namespace"] == parameters["namespace"]: if per_action.__class__.__base__.__name__ == "BootAction": boot_action_para = per_action.parameters self.action = TestShellLoop(boot_action_para) self.action.job = self.job self.action.section = self.action_type parent.add_action(self.action, parameters) You see we could get the "Boot" action from its parent action, thus we could get the boot action's parameters defined in job.yaml, then reconstruct the boot action, inject it as a internal action to our own test action. But now, we can't do it as parent action no longer be passed to low level action... Could you give me some suggestion on it, if any other way I could get the parameters of boot action when I'm in test action? Thanks again. Regards, Larry

5 years, 9 months

docker-compose: how to administrate a LAVA master from this?

by Philippe Mazet (OSS)

Hi, I am looking into https://git.lavasoftware.org/lava/pkg/docker-compose I have few questions about it: * Are there guidelines somewhere about how to administrate a "master only" instance run from this docker-compose? Like tutorials about creating/restoring a backup, periodic maintenance/cleanup, restart one of the containers idenpendantly, upgrade versions, etc... * Is there an easy way to inject a backup created from a previous instance? (backup created with pg_dump. Note that I am not psql expert at all...) * Is LAVA coordinator supported in this docker solution ? Many thanks, Philippe

5 years, 9 months

test

by Remi Duraffort

Hello, please skip this message. -- Rémi Duraffort LAVA Architect Linaro

5 years, 9 months

LTP included rootfs.cpio file for Qualcomm Snapdragon (arm64) series

by koti koti

Hi, I am looking for the LTP test suite included(inbuild) rootfs.cpio file for the Qualcomm Snapdragon (arm64) seris. Please can some one let me know as where can I find this .cpio file in Linaro's prebuild releases? Regards, Koti

5 years, 9 months

← Newer
1
...
26
27
28
29
30
31
32
...
95
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users