Thanks again, Neil.
Future proofing means keeping up with upstream and, hopefully, contributing the support back to upstream. A new Strategy class is a requirement for inclusion upstream, to be able to isolate this bootloader from future changes to better support U-Boot in ways that your bootloader cannot manage.
I get your point and agree with you on that. So does this mean you would accept contributions for a new bootloader, even if it is a proprietary one?
However, for a quick check how LAVA works I was able to go the hacky way and abuse the uboot class to send commands to our own bootloader. This led me to further questions:
1. The TFTP deployment strategy does not seem to support deploying a rootfs. Is that correct? If yes, why?
2. Our bootloader supports download via HTTP as well, so actually we could get the files from the web to the device directly. The test system would not need to download any files then. LAVA does not seem to support such a scenario. All deployment strategies download the files first, before performing further steps. How could I handle this case in LAVA? Obviously I could remove the deploy action from the job completely and handle everything in the boot command sequence. Still I would need some possibility to specify the URL of the image within the job, which the boot command sequence then should use. Is there a way to achieve this? I assume the correct way would be to implement a new deployment strategy for this, which does not do anything. However, this seems a bit weird to me. Is there another way? Or would the whole idea work against the general LAVA workflow?
3. As far as I understand, LAVA needs to apply an overlay tarball to the image before executing tests, which is usually performed directly on the image file before it is deployed to the target. This would not work in the case of (2). But I saw there is a boot action "transfer_overlay" to do this after the actual deployment. Is it correct, that I could use this action in such a case?
Mit freundlichen Grüßen / Best regards Tim Jaacks DEVELOPMENT ENGINEER Garz & Fricke GmbH Tempowerkring 2 21079 Hamburg Direct: +49 40 791 899 - 55 Fax: +49 40 791899 - 39 tim.jaacks@garz-fricke.com www.garz-fricke.com SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz
Hello and sorry for the delay,
I get your point and agree with you on that. So does this mean you would
accept contributions for a new bootloader, even if it is a proprietary one?
As long as the code is clean and you are willing to maintenain it we welcome contributions.
However, for a quick check how LAVA works I was able to go the hacky way
and abuse the uboot class to send commands to our own bootloader. This led me to further questions:
- The TFTP deployment strategy does not seem to support deploying a
rootfs. Is that correct? If yes, why?
We use nfs for the rootfs which is easier to setup and easier to update the rootfs with the lava overlay.
2. Our bootloader supports download via HTTP as well, so actually we could
get the files from the web to the device directly. The test system would not need to download any files then. LAVA does not seem to support such a scenario. All deployment strategies download the files first, before performing further steps.
Yes LAVA does not allow to download directly from the device only because we don't have such device! It's also linked to your last question: being able to add the LAVA ovelay to the rootfs.
How could I handle this case in LAVA? Obviously I could remove the deploy
action from the job completely and handle everything in the boot command sequence. Still I would need some possibility to specify the URL of the image within the job, which the boot command sequence then should use. Is there a way to achieve this? I assume the correct way would be to implement a new deployment strategy for this, which does not do anything. However, this seems a bit weird to me. Is there another way? Or would the whole idea work against the general LAVA workflow?
I haven't really though about that but creating a new deployment strategie sounds logical. Yes this method won't do much: 1/ checking that the url does return 200 2/ creating the overlay 3/ adding the right variables into the context
3. As far as I understand, LAVA needs to apply an overlay tarball to the
image before executing tests, which is usually performed directly on the image file before it is deployed to the target. This would not work in the case of (2). But I saw there is a boot action "transfer_overlay" to do this after the actual deployment. Is it correct, that I could use this action in such a case?
That's the goal of this boot action.
Cheers
-
Remi Duraffort -
Tim Jaacks