On 7 December 2017 at 16:20, Guillaume Tucker < guillaume.tucker@collabora.com> wrote:
A change was sent a while ago to add support for the Coreboot / Depthcharge bootloader which is used on Chromebook devices. This is useful in particular to avoid having to install U-Boot on Chromebook devices. See this Gerrit review here for previous history:
https://review.linaro.org/#/c/15203/I'm now opening this case again to try and get this resolved, there seem to be several issues with the original patch that would need to be clarified. Also, some things might have changed since then in LAVA or Coreboot which could potentially lead to a different approach - any feedback on this would be welcome.
Thanks for picking this up.
To start with, I understand that running mkimage on the dispatcher is not a valid thing to do, it should receive a FIT (flattened image tree) kernel image ready to be booted. This complicates things a bit for projects like kernelci.org where only a plain kernel image is built and ramdisks are served separately, but it's fair enough to say that LAVA is not meant to be packaging kernel images on the fly.
We've come up with a method in the meantime, although it does mean using LXC but that makes it completely generic. It's principally designed for boards which need to munge a kernel and other files into an image to be transferred to the device using tools like fastboot. This is how KernelCI will be able to submit boot tests on devices like HiKey and db410c. Sadly, the example test job is suffering because the db410c devices have a different problem which is keeping them offline. Matt has been looking into this.
https://staging.validation.linaro.org/scheduler/job/203317/definition
https://staging.validation.linaro.org/static/docs/v2/actions-deploy.html#ind...
Then I believe creating the command line file in LAVA should be fine, although it probably makes more sense to have both the FIT image and cmdline file generated by the same build system. In any case, both files would need to be served from the dispatcher TFTP server to the target device running Coreboot / Depthcharge.
That bit is fine, the problem is why this cannot use the existing temporary paths which all the other TFTP devices use. Is it just to do some mangling of the files?
So the idea was basically to have an option in Coreboot / Depthcharge to interactively tell it where to find these files for the current job to run, say:
<JOB_NUMBER>/tftp-deploy-<RANDOM>/kernel/vmlinuz <JOB_NUMBER>/tftp-deploy-<RANDOM>/kernel/cmdlineIt looks like the current patch in Gerrit relies on this location to be hard-coded in the bootloader, which works fine for a private development set-up but not for LAVA.
That makes very little sense because the whole point of TFTP is that everything after the SERVER_IP is just a relative path from the TFTP base directory which is handled by the TFTP daemon itself.
To recap, my understanding is that the "depthcharge" boot support code in LAVA would need to:
- maybe create the cmdline file with basically the kernel command line split up with one argument per line
Alternatively, do whatever operations are required in a test shell in the LXC and then pass those files to the device - entirely within the test shell support.
or just download the cmdline file along with the vmlinuz FIT
place both the cmdline and vmlinuz FIT files in the job's TFTP directory on the dispatcher
turn on the device and open the serial console...
interactively pass at least the path to the job TFTP directory on the serial console (and if possible the server IP address as well, and maybe even the individual file names rather than hard-coded vmlinuz and cmdline)
Isn't this equivalent to what U-Boot already does with TFTP?
- look for a bootloader message to know when the kernel starts to load and hand over to the next action (login...)
Please let me know if this sounds reasonable or if we should be doing anything differently. I think it would be good to have some agreement and a clear understanding of how this is going to be implemented before starting to work on the code again.
Best wishes, Guillaume _______________________________________________ Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users