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.

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.

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.

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/cmdline

It 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.

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

  * 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)

  * 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