Hi Neil, thanks for your reply.
Why do you need an in-house bootloader? (Hint: Just because you can / have is the worst possible reason.) Honestly, just find some other way to do it
- it will likely be much quicker.
We have developed our own bootloader for our hardware, for various reasons, and want our OS to be tested in combination with it. Our devices do not support any other bootloader except our own anyway, so there is no other possibility. This is what we have, and we need to automate testing somehow. So I am trying to figure out whether LAVA is suitable for this task.
Supporting a new bootloader is a very complex and time-consuming process for any test framework. It typically takes several months. Once done, there is an ongoing maintenance burden as the code for the supported bootloaders continues to advance.
This is not a problem generally. We are planning long-term and want a future-proof solution.
You need a new Strategy Class, as per the documentation. You must not overload the "method: u-boot" support for anything except U-Boot. You must create a new boot method.
Why? What is wrong with using the u-boot method for a bootloader which works similarly? As far as I can see right now, I would only remove stuff from the u-boot method and set a bunch of already existing variables to new values. I do not see the need for a completely new boot method. Is there any hard reason for this, except that it would be neater?
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