From: Marc Titinger mtitinger@baylibre.com
- specific u-boot prompt - specific C-c interrupt char - uImage only: hardkernel u-boot sources are heavily hardcoded in an old u-boot version (no bootz)
Signed-off-by: Marc Titinger mtitinger@baylibre.com --- .../device-types/meson8b-odroidc1.conf | 44 ++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 lava_dispatcher/default-config/lava-dispatcher/device-types/meson8b-odroidc1.conf
diff --git a/lava_dispatcher/default-config/lava-dispatcher/device-types/meson8b-odroidc1.conf b/lava_dispatcher/default-config/lava-dispatcher/device-types/meson8b-odroidc1.conf new file mode 100644 index 0000000..96232b4 --- /dev/null +++ b/lava_dispatcher/default-config/lava-dispatcher/device-types/meson8b-odroidc1.conf @@ -0,0 +1,44 @@ +client_type = bootloader +send_char = False +uimage_only = True +append_dtb = True + +u_load_addrs = + 0x20000000 + 0x22000000 + 0x21000000 + +z_load_addrs = + 0x20000000 + 0x22000000 + 0x21000000 + +boot_cmds_ramdisk = + setenv autoload no, + setenv kernel_addr_r "'{KERNEL_ADDR}'", + setenv initrd_addr_r "'{RAMDISK_ADDR}'", + setenv loadkernel "'tftp ${kernel_addr_r} {KERNEL}'", + setenv loadinitrd "'tftp ${initrd_addr_r} {RAMDISK}; setenv initrd_size ${filesize}'", + setenv bootargs "'console=ttyAML0,115200n8 root=/dev/ram0 ip=dhcp'", + setenv bootcmd "'dhcp; dhcp; setenv serverip {SERVER_IP}; run loadkernel; run loadinitrd; {BOOTX}'", + run bootcmd + +boot_cmds_nfs = + setenv autoload no, + setenv kernel_addr_r "'{KERNEL_ADDR}'", + setenv initrd_addr_r "'{RAMDISK_ADDR}'", + setenv loadkernel "'tftp ${kernel_addr_r} {KERNEL}'", + setenv loadinitrd "'tftp ${initrd_addr_r} {RAMDISK}; setenv initrd_size ${filesize}'", + setenv nfsargs "'setenv bootargs console=ttyAML0,115200n8 root=/dev/nfs rw nfsroot={SERVER_IP}:{NFSROOTFS},tcp,hard,intr ip=dhcp'", + setenv bootcmd "'dhcp; setenv serverip {SERVER_IP}; run loadkernel; run loadinitrd; run nfsargs; {BOOTX}'", + run bootcmd + +bootloader_prompt = odroidc# +interrupt_boot_prompt = key to stop autoboot +interrupt_boot_control_character = c + +boot_options = + boot_cmds + +[boot_cmds] +default = boot_cmds
Thanks for the patch, it has been pushed as https://review.linaro.org/#/c/10593/1
Comments are likely to be made on this review but will not necessarily make it to the lava-users mailing list. You may wish to register as a Community contributor at https://register.linaro.org/
As a standard U-Boot device, it should also be possible to convert this to a pipeline device-type template.
Possibly not that many changes compared to: https://git.linaro.org/lava/lava-server.git/blob/HEAD:/lava_scheduler_app/te... (Feel free to drop the ssh blocks and the media block.)
This is the full example for reference. https://validation.linaro.org/static/docs/pipeline-admin-example.html
On 15 February 2016 at 16:31, Marc Titinger mtitinger@baylibre.com wrote:
From: Marc Titinger mtitinger@baylibre.com
- specific u-boot prompt
- specific C-c interrupt char
- uImage only: hardkernel u-boot sources are heavily hardcoded in an old u-boot version (no bootz)
Signed-off-by: Marc Titinger mtitinger@baylibre.com
.../device-types/meson8b-odroidc1.conf | 44 ++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 lava_dispatcher/default-config/lava-dispatcher/device-types/meson8b-odroidc1.conf
diff --git a/lava_dispatcher/default-config/lava-dispatcher/device-types/meson8b-odroidc1.conf b/lava_dispatcher/default-config/lava-dispatcher/device-types/meson8b-odroidc1.conf new file mode 100644 index 0000000..96232b4 --- /dev/null +++ b/lava_dispatcher/default-config/lava-dispatcher/device-types/meson8b-odroidc1.conf @@ -0,0 +1,44 @@ +client_type = bootloader +send_char = False +uimage_only = True +append_dtb = True
+u_load_addrs =
- 0x20000000
- 0x22000000
- 0x21000000
+z_load_addrs =
- 0x20000000
- 0x22000000
- 0x21000000
+boot_cmds_ramdisk =
- setenv autoload no,
- setenv kernel_addr_r "'{KERNEL_ADDR}'",
- setenv initrd_addr_r "'{RAMDISK_ADDR}'",
- setenv loadkernel "'tftp ${kernel_addr_r} {KERNEL}'",
- setenv loadinitrd "'tftp ${initrd_addr_r} {RAMDISK}; setenv initrd_size ${filesize}'",
- setenv bootargs "'console=ttyAML0,115200n8 root=/dev/ram0 ip=dhcp'",
- setenv bootcmd "'dhcp; dhcp; setenv serverip {SERVER_IP}; run loadkernel; run loadinitrd; {BOOTX}'",
- run bootcmd
+boot_cmds_nfs =
- setenv autoload no,
- setenv kernel_addr_r "'{KERNEL_ADDR}'",
- setenv initrd_addr_r "'{RAMDISK_ADDR}'",
- setenv loadkernel "'tftp ${kernel_addr_r} {KERNEL}'",
- setenv loadinitrd "'tftp ${initrd_addr_r} {RAMDISK}; setenv initrd_size ${filesize}'",
- setenv nfsargs "'setenv bootargs console=ttyAML0,115200n8 root=/dev/nfs rw nfsroot={SERVER_IP}:{NFSROOTFS},tcp,hard,intr ip=dhcp'",
- setenv bootcmd "'dhcp; setenv serverip {SERVER_IP}; run loadkernel; run loadinitrd; run nfsargs; {BOOTX}'",
- run bootcmd
+bootloader_prompt = odroidc# +interrupt_boot_prompt = key to stop autoboot +interrupt_boot_control_character = c
+boot_options =
- boot_cmds
+[boot_cmds]
+default = boot_cmds
2.5.0
Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
Neil Williams neil.williams@linaro.org writes:
Thanks for the patch, it has been pushed as https://review.linaro.org/#/c/10593/1
Comments are likely to be made on this review but will not necessarily make it to the lava-users mailing list. You may wish to register as a Community contributor at https://register.linaro.org/
As a standard U-Boot device, it should also be possible to convert this to a pipeline device-type template.
What version of LAVA can we start using pipeline?
I have a pile standard u-boot devices I'm planning to migrate to LAVA and have been waiting for the pipleine support to land to give it a try. I'm currently running 2016.02++
Kevin
The 2016.2 release is the point at which pipeline moved out of developer only and became available using the production systems for the Linaro Cambridge lab. There have been a few issues with the configuration files and some parts of the CLI in 2016.2 which will be solved in the next release.
So 2016.2 can run U-Boot pipeline jobs and is doing so on staging, validation.linaro.org and lava.debian.net. Devices need to be enabled as pipeline devices in the django admin interface and the old dispatcher configuration files need to be ported to device dictionaries which are then imported into the database. We're also updating the documentation on how to do that after feedback from those who have already used the pipeline dispatcher. https://review.linaro.org/#/c/10428/
We are aiming to get all the issues with 2016.2 fixed for 2016.3, hopefully before Connect BKK16 in March but it might need to wait until just after we return.
Note: There is an upcoming change to the syntax of the YAML files used for U-Boot to make the compression handling more straightforward. So be ready for some changes in the deploy: blocks:
kernel: http:// ramdisk: http://
becomes
kernel: url: http:// ramdisk: url: http:// compression: gz
We'll be updating the documentation at the same time: https://review.linaro.org/#/c/10589/1/doc/dispatcher-actions2.rst as well as updating the pipeline jobs at https://git.linaro.org/lava-team/refactoring.git
On 22 February 2016 at 21:45, Kevin Hilman khilman@baylibre.com wrote:
Neil Williams neil.williams@linaro.org writes:
Thanks for the patch, it has been pushed as https://review.linaro.org/#/c/10593/1
Comments are likely to be made on this review but will not necessarily make it to the lava-users mailing list. You may wish to register as a Community contributor at https://register.linaro.org/
As a standard U-Boot device, it should also be possible to convert this to a pipeline device-type template.
What version of LAVA can we start using pipeline?
I have a pile standard u-boot devices I'm planning to migrate to LAVA and have been waiting for the pipleine support to land to give it a try. I'm currently running 2016.02++
Kevin
Neil Williams neil.williams@linaro.org writes:
The 2016.2 release is the point at which pipeline moved out of developer only and became available using the production systems for the Linaro Cambridge lab. There have been a few issues with the configuration files and some parts of the CLI in 2016.2 which will be solved in the next release.
So 2016.2 can run U-Boot pipeline jobs and is doing so on staging, validation.linaro.org and lava.debian.net. Devices need to be enabled as pipeline devices in the django admin interface and the old dispatcher configuration files need to be ported to device dictionaries which are then imported into the database. We're also updating the documentation on how to do that after feedback from those who have already used the pipeline dispatcher. https://review.linaro.org/#/c/10428/
We are aiming to get all the issues with 2016.2 fixed for 2016.3, hopefully before Connect BKK16 in March but it might need to wait until just after we return.
Note: There is an upcoming change to the syntax of the YAML files used for U-Boot to make the compression handling more straightforward. So be ready for some changes in the deploy: blocks:
kernel: http:// ramdisk: http://
becomes
kernel: url: http:// ramdisk: url: http:// compression: gz
We'll be updating the documentation at the same time: https://review.linaro.org/#/c/10589/1/doc/dispatcher-actions2.rst as well as updating the pipeline jobs at https://git.linaro.org/lava-team/refactoring.git
It sounds to me like things are still in a fair amount of flux, so switching now might require a fair amount of babysitting (e.g on-going changes in YAML syntax are not something I feel like wanting to keep track of.)
Is there a freeze point coming where it might make more sense to switch over?
Kevin
It will be a gradual migration as more deployment types are added to provide wider device support. There are issues in 2016.2 which we will address in 2016.3 but the YAML submission formats for the pipeline design are likely to continue to evolve just as the JSON submission formats continued to change as new functionality was added. The difference is that since development of the pipeline model started, there has been significantly less development time on the "old" / V1 dispatcher model and therefore fewer changes in the JSON submissions. Whether individual instances are affected by those changes depends on the range of devices and methods in use.
The upcoming change in specifying the compression is being done to simplify the submission format for test writers and is a small change to the current U-Boot support in the pipeline model. The driver for future development is to put more control into the hands of test writers, that does mean that extra functionality will continue to be exposed, leading to ongoing changes to the submission format.
It isn't practical to freeze the submission schema for all devices, methods and users - even after the migration is completed and all the old V1 code has been removed. I don't expect that there will be significant changes affecting U-Boot type deployments but as the migration continues, there may still be instances where simplification of the submission format to add support for other test methods and other devices may lead to (small) changes being required in other submissions.
Those will be described in the docs and on the mailing lists and changes will be reflected in the refactoring examples.
On 23 February 2016 at 18:35, Kevin Hilman khilman@baylibre.com wrote:
Neil Williams neil.williams@linaro.org writes:
The 2016.2 release is the point at which pipeline moved out of developer only and became available using the production systems for the Linaro Cambridge lab. There have been a few issues with the configuration files and some parts of the CLI in 2016.2 which will be solved in the next release.
So 2016.2 can run U-Boot pipeline jobs and is doing so on staging, validation.linaro.org and lava.debian.net. Devices need to be enabled as pipeline devices in the django admin interface and the old dispatcher configuration files need to be ported to device dictionaries which are then imported into the database. We're also updating the documentation on how to do that after feedback from those who have already used the pipeline dispatcher. https://review.linaro.org/#/c/10428/
We are aiming to get all the issues with 2016.2 fixed for 2016.3, hopefully before Connect BKK16 in March but it might need to wait until just after we return.
Note: There is an upcoming change to the syntax of the YAML files used for U-Boot to make the compression handling more straightforward. So be ready for some changes in the deploy: blocks:
kernel: http:// ramdisk: http://
becomes
kernel: url: http:// ramdisk: url: http:// compression: gz
We'll be updating the documentation at the same time: https://review.linaro.org/#/c/10589/1/doc/dispatcher-actions2.rst as well as updating the pipeline jobs at https://git.linaro.org/lava-team/refactoring.git
It sounds to me like things are still in a fair amount of flux, so switching now might require a fair amount of babysitting (e.g on-going changes in YAML syntax are not something I feel like wanting to keep track of.)
Is there a freeze point coming where it might make more sense to switch over?
Kevin
On Mon, Feb 15, 2016 at 8:31 AM, Marc Titinger mtitinger@baylibre.com wrote:
From: Marc Titinger mtitinger@baylibre.com
- specific u-boot prompt
- specific C-c interrupt char
- uImage only: hardkernel u-boot sources are heavily hardcoded in an old u-boot version (no bootz)
Signed-off-by: Marc Titinger mtitinger@baylibre.com
Tested this in my local LAVA instance with this board:
Tested-by: Kevin Hilman khilman@baylibre.com
As Neil pointed out, it does an extra 'dhcp' command in u-boot, which is harmless, but should still be removed. After that change:
Acked-by: Kevin Hilman khilman@baylibre.com
On Thu, Mar 31, 2016 at 12:05 PM, Kevin Hilman khilman@baylibre.com wrote:
On Mon, Feb 15, 2016 at 8:31 AM, Marc Titinger mtitinger@baylibre.com wrote:
From: Marc Titinger mtitinger@baylibre.com
- specific u-boot prompt
- specific C-c interrupt char
- uImage only: hardkernel u-boot sources are heavily hardcoded in an old u-boot version (no bootz)
Signed-off-by: Marc Titinger mtitinger@baylibre.com
Tested this in my local LAVA instance with this board:
Tested-by: Kevin Hilman khilman@baylibre.com
As Neil pointed out, it does an extra 'dhcp' command in u-boot, which is harmless, but should still be removed. After that change:
Acked-by: Kevin Hilman khilman@baylibre.com
Oops, scratch that.
I wasn't testing what I thought I was testing. This doesn't seem to work yet for me. Among other things, I think it needs a text_offset setting for a specific uImage load address required by the factory boot loader. But even with that, I'm not having luck with the appended DTB on this platform.
Kevin
On 31/03/2016 22:32, Kevin Hilman wrote:
On Thu, Mar 31, 2016 at 12:05 PM, Kevin Hilman khilman@baylibre.com wrote:
On Mon, Feb 15, 2016 at 8:31 AM, Marc Titinger mtitinger@baylibre.com wrote:
From: Marc Titinger mtitinger@baylibre.com
- specific u-boot prompt
- specific C-c interrupt char
- uImage only: hardkernel u-boot sources are heavily hardcoded in an old u-boot version (no bootz)
Signed-off-by: Marc Titinger mtitinger@baylibre.com
Tested this in my local LAVA instance with this board:
Tested-by: Kevin Hilman khilman@baylibre.com
As Neil pointed out, it does an extra 'dhcp' command in u-boot, which is harmless, but should still be removed. After that change:
Acked-by: Kevin Hilman khilman@baylibre.com
Oops, scratch that.
I wasn't testing what I thought I was testing. This doesn't seem to work yet for me. Among other things, I think it needs a text_offset setting for a specific uImage load address required by the factory boot loader. But even with that, I'm not having luck with the appended DTB on this platform.
Yes, my apologies for the poor follow-up with this right now. I too thought this was doing ok, but I think the default config is missing proper FDT handling! parts like:
setenv fdt_addr_r "'0xxxxxxxxxx", setenv loadfdt "'tftp ${fdt_addr_r} {DTB}'", ... run loadfdt; ...
Kevin
-
Kevin Hilman -
Marc Titinger -
Neil Williams