On Thu, May 02, 2019 at 08:05:13PM -0500, Dan Rue wrote:

Hi!

Anibal and I put together a list of steps that can be used to 'fastboot boot' to a ramdisk or nfs root filesystem in LAVA issue 271[1]. The idea here is to have LAVA create a boot image at runtime based on a kernel, kernel modules, optional ramdisk, and a dtb file. Embedded in the boot image is the kernel command line necessary to boot to a ramdisk or to an nfs root filesystem. This boot image is then run with 'fastboot boot' directly - no flashing required.

This is based on discussions related to dragonboard-845 implementation, and would make such boards compatible with kernelci (for example), but also simplify kernel test jobs that don't require a system image to be flashed to the board.

Cute! That sounds like a really nice thing to have. :-)

We started to look at what would be needed on the LAVA side to implement this, but need help defining the semantics and requirements for the LAVA implementation. I'm also not sure which parts should be in an LXC/docker type context, and which parts should be directly supported in LAVA. I can imagine the rest of the semantics will be very similar or the same to the tftp deploy type.

Feedback and LAVA implementation suggestions welcome. Perhaps this can be a topic at the next LAVA design meeting (can I get an invite?).

Just invited you now.

Cheers,

On Mon, May 06, 2019 at 02:31:53PM +0200, Remi Duraffort wrote:

Hello Dan,

that's a really good news because that might make many people's life easier.

Some questions:

I'll try to answer based on what I discovered but I'm not the expert here..

1/ is this applicable to all fastboot devices? Of this is requiring a specific firmware? (the underlying question is: is this board specific?)

The concept is generic so I expect it's possible on all boards. I just tried on hikey, and got 'ERROR: Did not find Device Tree blob (Not Found).' This is the same error I got on db410c before I updated its firmware - so something changed at some point related to where fastboot finds the dtb.

2/ mkbootimg should be of a specific version or they are all compatible?

This is a lousy situation too. I found two versions of mkbootimg - the qc guys use one called skales-mkbootimg, but my example in the lava issue uses google's upstream one. Even there, I found a C and a python implementation which seemed redundant, and I don't know the history. Further, I found this guide[1] which uses a tool called 'abootimg' in place of mkbootimage.

3/ the steps are board specific or command to all fastboot ?

I don't know 🤷

Because of my impression of the flexibility required here, I expect we will need some LXC/docker style interface to run arbitrary commands to construct a board-specific boot image and let LAVA not try to worry about every variation. Though I'm keen to hear from some fastboot people to see if it's possible to do this in a generic way.

Dan

[1] https://www.96boards.org/documentation/consumer/dragonboard/dragonboard410c/...

Cheers

Le ven. 3 mai 2019 à 03:05, Dan Rue dan.rue@linaro.org a écrit :

...

Hi!

Anibal and I put together a list of steps that can be used to 'fastboot boot' to a ramdisk or nfs root filesystem in LAVA issue 271[1]. The idea here is to have LAVA create a boot image at runtime based on a kernel, kernel modules, optional ramdisk, and a dtb file. Embedded in the boot image is the kernel command line necessary to boot to a ramdisk or to an nfs root filesystem. This boot image is then run with 'fastboot boot' directly - no flashing required.

This is based on discussions related to dragonboard-845 implementation, and would make such boards compatible with kernelci (for example), but also simplify kernel test jobs that don't require a system image to be flashed to the board.

We started to look at what would be needed on the LAVA side to implement this, but need help defining the semantics and requirements for the LAVA implementation. I'm also not sure which parts should be in an LXC/docker type context, and which parts should be directly supported in LAVA. I can imagine the rest of the semantics will be very similar or the same to the tftp deploy type.

Feedback and LAVA implementation suggestions welcome. Perhaps this can be a topic at the next LAVA design meeting (can I get an invite?).

Thanks, Dan

[1] https://git.lavasoftware.org/lava/lava/issues/271

---

Lava-devel mailing list Lava-devel@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-devel

-- Rémi Duraffort LAVA Team, Linaro