On Thu, 25 Jun 2020 at 14:49, Stephen Lawrence stephen.lawrence@renesas.com wrote:
Hi Milosz,
-----Original Message----- From: Milosz Wasilewski milosz.wasilewski@linaro.org Sent: 25 June 2020 10:49 To: Stephen Lawrence stephen.lawrence@renesas.com Cc: lava-users@lists.lavasoftware.org; gandersson@genivi.org Subject: Re: [Lava-users] fastboot in docker support
Stephen,
I think what you want already works (sort of)
Thank you for your very quick reply and in particular taking the time to actually try out the solution and your follow ups :) The sequencing of the sections and the u-boot control example were educational.
I'm now taking some vacation till the end of the week, but based on a initial look I just wanted to ask a couple of questions to check I have it right for when I try this out Monday.
Looking at your job you would get:
- deploy: flash boot loader
- boot: board into fastboot in u-boot
In real world scenario I should have done (in u-boot shell): env default -f -a env set partitions $partitions_android fastboot 1
But I used the same version of bootloader that was already running on the board so these steps were not needed.
- interactive test: to perform bespoke fastboot cmds
you don't need interactive test. I thought it was needed to start fastboot inside u-boot, but it wasn't. I used inline test to invoke fastboot oem format, erase commands. IMHO this does the trick if you need to perform multi-step flashing (like in this case). In my case 'oem format' might change the partition layout so I should flash bootloader and xloader partitions again. But as I explained above I wasn't actually changing the bootloader/xloader.
- deploy: flash rest of android images (as normal)
yes, remember to flash bootloader/xloader if you change the version.
- test: as normal
So as long as the fastboot cmds in the interactive test section in step 3 do not require specific sequencing with the images being flashed in step 4, e.g that you must send 'oem format' after boot.img, but before vbmeta.img it should work. Do I have that right?
Yes, as mentioned above, 'oem format' alters the partition table (in my case).
If you have more commands that do something on the board you just repeat the deploy/boot/test sequence several times. It might be handy to use some templating engine to prepare your lava jobs.
I think with your example I could also sequence a job definition that called the script to flash the board from a test section. The only issue there is getting the images into the container in an automated way.
Hmm, I think this can be done with 'postprocessing' in deploy section but I didn't try. Antonio will know better. If it works you might not need the test section 3. Your second deploy step would do the oem format and reboot. I didn't try it but in theory it should work (famous last words).
milosz
Thanks again. I look forward to trying it out.
Cheers
Steve