WEBVTT 00:00.000 --> 00:15.000 Hello everyone, thank you everyone for joining my name is Andrea Andreshan and today I will 00:15.000 --> 00:22.240 try to guide you through what I've done but with the cloth on the hard work testing 00:22.240 --> 00:32.240 first structure. So first this is the outline of my presentation. I will guide you through 00:32.240 --> 00:41.240 the steps where I used cloth. Everything started actually from scripts that I implemented 00:41.240 --> 00:48.240 and was like let's see what I can do with the eye to reproduce what I've already done. 00:49.240 --> 00:56.240 So the purpose was to automate and to end harder validation for a specific analogue device 00:56.240 --> 01:03.240 is hard to achieve. There is a set of development boards that use 01:03.240 --> 01:12.240 yokto images on base. I think you can run different images but I put it yokto on them 01:12.240 --> 01:20.240 and for the testing pipeline where I used cloth first you I didn't find the flash project 01:20.240 --> 01:29.240 by checking the TFTPE directory for work configuration then I detect the work connection 01:29.240 --> 01:38.240 where the board is connected to can run the test on it and after that run the hardware test 01:38.240 --> 01:47.240 and also generate test rubric that will be uploaded as artifacts in GitHub or on our specific 01:47.240 --> 01:55.240 artifact storage site. The key benefit of this hardware infrastructure is that you have a 01:55.240 --> 02:02.240 fully automated board discovery and validation with no manual configuration. 02:02.240 --> 02:11.240 So these are the steps is like a chain because for step two you need the output from the previous step 02:11.240 --> 02:18.240 for step three from the second and that's going on. As input we need the TFTPE boot directory 02:18.240 --> 02:25.240 to check what was the setup that we flashed and booted then we need the available serial ports 02:26.240 --> 02:34.240 and also a board configuration JSON but you will see that I have two cases. One where I detect the 02:34.240 --> 02:42.240 you weren't a connection of the board and one where I give it a config file to know exactly which one is 02:42.240 --> 02:53.240 and as outputs the output from the previous step and then as a whole a mark down test rubric 02:53.240 --> 03:03.240 the first step so the check of TFTP boot is done by cloud so everything is prompting 03:03.240 --> 03:10.240 you here and here. I will show you just what cloud is actually does and I told him hey 03:10.240 --> 03:17.240 check this you will see in the next slides that I have there actually prompts that task that I 03:18.240 --> 03:26.240 told him to do but the first step as a pipeline is to check and detect the board that I've connected. 03:26.240 --> 03:38.240 The thing is that you can have multiple boards because if you want to have an entire system you can have different 03:38.240 --> 03:49.240 ADSP boards connected and this identification is made through the U-boot file description where you have the 03:49.240 --> 04:02.240 boards name in it on it is this one and identified this sum as a kit setup. So this are the files that you found in the 04:02.240 --> 04:11.240 TFTP boot folder and you just detect the board. This are some examples of the boards that we 04:11.240 --> 04:22.240 support with this specific cloud context. Then after we connected what board was flashed we 04:22.240 --> 04:30.240 want to check the what connection to the machine. You may ask why I don't use I don't know the SSH 04:30.240 --> 04:38.240 connection to the board it's because in your network you may have multiple boards and if you 04:38.240 --> 04:45.240 want to connect with SSH maybe you run tests on the harder connected on your other teammate 04:45.240 --> 04:52.240 or something but if you run it on your UART connection from your machine then you will be sure that 04:52.240 --> 05:02.240 is the board that you flashed before implemented. This is also like cloud will just list the 05:02.240 --> 05:11.240 UART available boards. Here I had two boards connected to my machine so it found USB zero and USB one. 05:11.240 --> 05:21.240 And then with a serial import is a best script that also generated it checks based on the 05:22.240 --> 05:31.240 host name of the thing of the board connected on the UART connection it will discover which one 05:31.240 --> 05:43.240 is the board because I can have multiple like a 594 and a 598 board but if I flashed the 594 then I want to test that one 05:44.240 --> 05:50.240 because maybe on the 598 is another e-mage word version that was previously theft. 05:54.240 --> 06:04.240 Here are some results from Iran. I told you I detected two boards and on the USB zero connection was found 06:05.240 --> 06:14.240 the 594 setup. For board identification from the previous step this is the host name and will basically 06:14.240 --> 06:23.240 match the detected board with the UART connection. Then it will try to run some harder tests on it. 06:23.240 --> 06:33.240 So this is a cloud context created specific for this setup. So previously I talked with him I 06:33.240 --> 06:39.240 gave it some best scripts that I had with test and told him hey this is the generic one and for this 06:39.240 --> 06:51.240 setup add some extra some extra test that were not implemented and it created a Python framework testing infrastructure. 06:51.240 --> 06:59.240 So what I had previously was some best scripts. So it will try to connect the board, authentificate 06:59.240 --> 07:07.240 and then run with the UART connection, some generic tests that include like serial, E2C, 07:08.240 --> 07:21.240 crypto or ashram. Sorry. This are like some generic test executed on the board. I don't know exactly to 07:21.240 --> 07:30.240 told you more about it because I'm just the person that just included them in the pipeline. So it's not something that I know. 07:31.240 --> 07:47.240 This are some results of the test generated, of the test run with cloud and also this is the output that it prompts in your CI or on your session with cloud 07:47.240 --> 08:02.240 internal. But oh, this is sorry. This is the detailed output. What's nice is for failed tests for failed tests. 08:02.240 --> 08:09.240 It also can give you some possible causes of why the test failed. 08:10.240 --> 08:22.240 Maybe for persons that interact with the hardware and they know more about it. It's not that much, but for an engineer that all we want to do is to boot the board and he doesn't know 08:24.240 --> 08:34.240 the steps exactly and why it probably failed. It's actually nice to have a hint at first to know what to start to debug or something. 08:34.240 --> 08:49.240 I told you it generates a test rubric that you can export and keep somewhere with the results. 08:49.240 --> 09:03.240 It's not much, it's just the test. This are the supported boards that the context that I've created and worked with it supports. 09:03.240 --> 09:12.240 And as you can see for specific setups has tests that run just on those ones. 09:12.240 --> 09:19.240 You can connect to the board with a board rate credentials. 09:19.240 --> 09:31.240 You can find this on our GitHub, is there a documentation and that's what I've used to create the context. 09:31.240 --> 09:36.240 And use it to support this. 09:36.240 --> 09:49.240 So after I tried this in a terminal session with Claude, I was like, how would sound to you add this in a workflow on GitHub on the workflow that I've worked with? 09:49.240 --> 09:54.240 It's like build and flash and then testing. 09:54.240 --> 10:04.240 I also kept the tests that I've had in Bash and I just added the Claude ones. 10:04.240 --> 10:15.240 So for the testing part is just the checkout of the repo and the context because I want to have the context that I created that I know it's working. 10:15.240 --> 10:23.240 And the one that it's not necessarily modified by previous runs. 10:23.240 --> 10:27.240 And all I need to do is check out the repo's context. 10:27.240 --> 10:31.240 We boot the board to be sure it's on a neutral stage. 10:31.240 --> 10:36.240 Download the artifacts, then flash and boot the board. 10:36.240 --> 10:40.240 Then I will run some tests with Claude. 10:40.240 --> 10:54.240 This one is that also does the hardware identification and this stage is just running some tests where I give it to him the configuration file. 10:54.240 --> 11:03.240 So this will be the first stage and it's really simple because all you need to do is just source. 11:03.240 --> 11:12.240 I actually think we boot the board first to be sure it's on the boot mode that needs to be. 11:12.240 --> 11:15.240 And then just give it like Claude. 11:15.240 --> 11:19.240 Hey, identify board type from the TFTP boot files. 11:19.240 --> 11:24.240 And it will identify what I've booted and flashed before. 11:24.240 --> 11:32.240 Then you say, hi, find board on the specific USB connection. 11:32.240 --> 11:41.240 This way you don't need to do anything just pre-bron, push and Claude will do that for you. 11:41.240 --> 11:47.240 What's nice is if you have the context locally, you just open a terminal and say, 11:47.240 --> 11:59.240 You can do all this process from, I don't know, building the octo image, flashing, booting and also testing with one terminal session of cloud. 11:59.240 --> 12:09.240 But for all of these, you just need the proper context to be created and to be sure it's working it. 12:09.240 --> 12:22.240 And this is the second stage where I told you, this was the first one that I created because first I just give it him by default the USB and board connection. 12:22.240 --> 12:37.240 And then I was like, okay, let's see how it's working to find itself, what board and what connection, where is connected to, to know where to run the result, to run the test. 12:37.240 --> 12:51.240 But basically, from a prompt engineering, it's pretty easy to just open a terminal and say, hi, just boot the specific setup that I have here connected to mine. 12:51.240 --> 13:01.240 To my machine and not open like GDB, open OCD and copy all this in the TFDB boot. 13:01.240 --> 13:06.240 This everything can be done with, with Claude. 13:06.240 --> 13:15.240 So for this, I actually use two different contexts. I have the first one, which actually is context two, sorry for that. 13:15.240 --> 13:23.240 Which I created with where I give him, what I give him specific the connection. 13:23.240 --> 13:34.240 And then upon that, I tried to make him detect the board and work to run the test. 13:34.240 --> 13:41.240 This is an example of the workflow run, so it works fine. 13:41.240 --> 13:53.240 You can, I mean, I can do parallel because I use NFS boot for the full image yokto. 13:53.240 --> 14:02.240 So it's shared and I can use the 594 with root of FAS4598 because one work. 14:02.240 --> 14:06.240 So it's sequential pipeline. 14:06.240 --> 14:22.240 But in the end, Claude successfully identified the board, executed test, VI, UART connection, and the results were captured in the workflow blog and also in MDF. 14:23.240 --> 14:35.240 These are the steps. Actually, it's like everything done. 14:35.240 --> 14:44.240 I mean, you can done this without a very good knowledge of how to run the test. 14:45.240 --> 15:03.240 Compared with what I've, with my experience when I try to add this in the pipeline, it's pretty easy to just open a session and then prompt him, tell him, hey, just do that. 15:03.240 --> 15:08.240 And this is the CICD integration summary. 15:08.240 --> 15:16.240 It identified the hardware and automated testing the boards. 15:16.240 --> 15:25.240 This are like the main, the main script that Claude wrote. 15:33.240 --> 15:40.240 Thanks for watching.