Hello,
We are using RPi3 B/B+ in our infrastructure and the latest uboot changed his behaviour in case of error. In our case we have a kernel and DTB but we don’t have the ramdisk. Despite this, LAVA tries the tftp command for the RAMDISK but the 2 versions have different errors.
With uboot 2019.07 this is what happens:
tftp - {RAMDISK} U-Boot> tftp - {RAMDISK} bootloader-commands: Wait for prompt ['U-Boot>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'Retry time exceeded; starting again', 'ERROR: The remote end did not respond in time.', 'Bad Linux ARM64 Image magic!', 'Wrong Ramdisk Image Format', 'Ramdisk image is corrupt or invalid', 'ERROR: Failed to allocate', 'TFTP error: trying to overwrite reserved memory'] (timeout 00:04:08) tftp - {RAMDISK} lan78xx_eth Waiting for PHY auto negotiation to complete...... done Using lan78xx_eth device TFTP from server 192.168.130.111; our IP address is 192.168.130.138 Filename '{RAMDISK}'. Load address: 0x0 Loading: * TFTP error: 'File not found' (1) Not retrying...
Uboot 2019.10 has a different behaviour and throws a different error:
tftp - {RAMDISK} U-Boot> tftp - {RAMDISK} bootloader-commands: Wait for prompt ['U-Boot>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'Retry time exceeded; starting again', 'ERROR: The remote end did not respond in time.', 'Bad Linux ARM64 Image magic!', 'Wrong Ramdisk Image Format', 'Ramdisk image is corrupt or invalid', 'ERROR: Failed to allocate', 'TFTP error: trying to overwrite reserved memory'] (timeout 00:04:12) tftp - {RAMDISK} lan78xx_eth Waiting for PHY auto negotiation to complete...... done Using lan78xx_eth device TFTP from server 192.168.130.111; our IP address is 192.168.130.138 Filename '{RAMDISK}'. TFTP error: trying to overwrite reserved memory... matched a bootloader error message: 'TFTP error: trying to overwrite reserved memory' (11)
At this point LAVA fails the job because it matches the error message.
What's the best way to solve the issue. How can I tell LAVA not to deal with the RAMDISK at all?
Thanks
-- Diego Russo | Staff Software Engineer | Mbed Linux OS ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - https://os.mbed.com/docs/mbed-linux-os/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Diego,
On Wed, 6 Nov 2019 at 15:38, Diego Russo Diego.Russo@arm.com wrote:
Hello,
We are using RPi3 B/B+ in our infrastructure and the latest uboot changed his behaviour in case of error. In our case we have a kernel and DTB but we don’t have the ramdisk. Despite this, LAVA tries the tftp command for the RAMDISK but the 2 versions have different errors.
With uboot 2019.07 this is what happens:
tftp - {RAMDISK} U-Boot> tftp - {RAMDISK} bootloader-commands: Wait for prompt ['U-Boot>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'Retry time exceeded; starting again', 'ERROR: The remote end did not respond in time.', 'Bad Linux ARM64 Image magic!', 'Wrong Ramdisk Image Format', 'Ramdisk image is corrupt or invalid', 'ERROR: Failed to allocate', 'TFTP error: trying to overwrite reserved memory'] (timeout 00:04:08) tftp - {RAMDISK} lan78xx_eth Waiting for PHY auto negotiation to complete...... done Using lan78xx_eth device TFTP from server 192.168.130.111; our IP address is 192.168.130.138 Filename '{RAMDISK}'. Load address: 0x0 Loading: * TFTP error: 'File not found' (1) Not retrying...
Uboot 2019.10 has a different behaviour and throws a different error:
tftp - {RAMDISK} U-Boot> tftp - {RAMDISK} bootloader-commands: Wait for prompt ['U-Boot>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'Retry time exceeded; starting again', 'ERROR: The remote end did not respond in time.', 'Bad Linux ARM64 Image magic!', 'Wrong Ramdisk Image Format', 'Ramdisk image is corrupt or invalid', 'ERROR: Failed to allocate', 'TFTP error: trying to overwrite reserved memory'] (timeout 00:04:12) tftp - {RAMDISK} lan78xx_eth Waiting for PHY auto negotiation to complete...... done Using lan78xx_eth device TFTP from server 192.168.130.111; our IP address is 192.168.130.138 Filename '{RAMDISK}'. TFTP error: trying to overwrite reserved memory... matched a bootloader error message: 'TFTP error: trying to overwrite reserved memory' (11)
At this point LAVA fails the job because it matches the error message.
What's the best way to solve the issue. How can I tell LAVA not to deal with the RAMDISK at all?
I saw this problem on some other board (don't remember which one). The quick fix is to replace the bootloader commands with custom ones either in device dictionary or in the job. In the long run this needs to be fixed in LAVA. I'll create a ticket if there isn't one already. For updating the commands in the job, here is the snippet:
- boot: timeout: minutes: 10 method: u-boot commands: - setenv autoload no - dhcp - env print - setenv serverip {SERVER_IP} - tftp {KERNEL_ADDR} {KERNEL} - tftp {DTB_ADDR} {DTB} - setenv bootargs 'console=ttyS0,115200n8 root=/dev/nfs rw nfsroot={NFS_SERVER_IP}:{NFSROOTFS},tcp,hard,intr,vers=3 rootwait coherent_pool=2M ip=dhcp' - '{BOOTX}'
This should do the trick for now.
milosz
Thanks
-- Diego Russo | Staff Software Engineer | Mbed Linux OS ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - https://os.mbed.com/docs/mbed-linux-os/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
> What's the best way to solve the issue. How can I tell LAVA not to deal with the RAMDISK at all?
I saw this problem on some other board (don't remember which one). The quick fix is to replace the bootloader commands with custom ones either in device dictionary or in the job. In the long run this needs to be fixed in LAVA. I'll create a ticket if there isn't one already. For updating the commands in the job, here is the snippet:
- boot: timeout: minutes: 10 method: u-boot commands: - setenv autoload no - dhcp - env print - setenv serverip {SERVER_IP} - tftp {KERNEL_ADDR} {KERNEL} - tftp {DTB_ADDR} {DTB} - setenv bootargs 'console=ttyS0,115200n8 root=/dev/nfs rw nfsroot={NFS_SERVER_IP}:{NFSROOTFS},tcp,hard,intr,vers=3 rootwait coherent_pool=2M ip=dhcp' - '{BOOTX}'
This should do the trick for now.
milosz
Milosz,
I've come up with a similar solution. I've added the following lines into the device type of the board:
{% set uboot_tftp_commands = [ "tftp {KERNEL_ADDR} {KERNEL}", "tftp {DTB_ADDR} {DTB}"] -%}
Thanks
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello,
I created a merge request for a similar issue to lony send the commands that are actually used. But in order to fix that properly, I have to create another set of u-boot commands to support ramdisk and another one for ramdisk-nfs.
See https://git.lavasoftware.org/lava/lava/merge_requests/492
In order to merge this MR we need a migration path to keep compatibility with jobs that uses the ability to use both ramdisk and nfs at the same time.
Rgds
Le lun. 11 nov. 2019 à 13:02, Diego Russo Diego.Russo@arm.com a écrit :
> What's the best way to solve the issue. How can I tell LAVA not todeal with the RAMDISK at all?
I saw this problem on some other board (don't remember which one). The quick fix is to replace the bootloader commands with custom ones either in device dictionary or in the job. In the long run this needs to be fixed in LAVA. I'll create a ticket if there isn't one already. For updating the commands in the job, here is the snippet: - boot: timeout: minutes: 10 method: u-boot commands: - setenv autoload no - dhcp - env print - setenv serverip {SERVER_IP} - tftp {KERNEL_ADDR} {KERNEL} - tftp {DTB_ADDR} {DTB} - setenv bootargs 'console=ttyS0,115200n8 root=/dev/nfs rw nfsroot={NFS_SERVER_IP}:{NFSROOTFS},tcp,hard,intr,vers=3 rootwait coherent_pool=2M ip=dhcp' - '{BOOTX}' This should do the trick for now. miloszMilosz,
I've come up with a similar solution. I've added the following lines into the device type of the board:
{% set uboot_tftp_commands = [ "tftp {KERNEL_ADDR} {KERNEL}", "tftp {DTB_ADDR} {DTB}"] -%}
Thanks
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
On Tue, 12 Nov 2019 at 13:13, Remi Duraffort remi.duraffort@linaro.org wrote:
Hello,
I created a merge request for a similar issue to lony send the commands that are actually used. But in order to fix that properly, I have to create another set of u-boot commands to support ramdisk and another one for ramdisk-nfs.
See https://git.lavasoftware.org/lava/lava/merge_requests/492
In order to merge this MR we need a migration path to keep compatibility with jobs that uses the ability to use both ramdisk and nfs at the same time.
Wouldn't it be better to simply omit the ramdisk related line from u-boot commands when ramdisk is not defined in the job?
milosz
Rgds
Le lun. 11 nov. 2019 à 13:02, Diego Russo Diego.Russo@arm.com a écrit :
> What's the best way to solve the issue. How can I tell LAVA not to deal with the RAMDISK at all? I saw this problem on some other board (don't remember which one). The quick fix is to replace the bootloader commands with custom ones either in device dictionary or in the job. In the long run this needs to be fixed in LAVA. I'll create a ticket if there isn't one already. For updating the commands in the job, here is the snippet: - boot: timeout: minutes: 10 method: u-boot commands: - setenv autoload no - dhcp - env print - setenv serverip {SERVER_IP} - tftp {KERNEL_ADDR} {KERNEL} - tftp {DTB_ADDR} {DTB} - setenv bootargs 'console=ttyS0,115200n8 root=/dev/nfs rw nfsroot={NFS_SERVER_IP}:{NFSROOTFS},tcp,hard,intr,vers=3 rootwait coherent_pool=2M ip=dhcp' - '{BOOTX}' This should do the trick for now. miloszMilosz,
I've come up with a similar solution. I've added the following lines into the device type of the board:
{% set uboot_tftp_commands = [ "tftp {KERNEL_ADDR} {KERNEL}", "tftp {DTB_ADDR} {DTB}"] -%}
Thanks
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
-- Rémi Duraffort LAVA Architect Linaro
Yes but it's difficult to know which line to remove as we only have a list of commands to send. Without any metadata.
Le mar. 12 nov. 2019 à 14:15, Milosz Wasilewski < milosz.wasilewski@linaro.org> a écrit :
On Tue, 12 Nov 2019 at 13:13, Remi Duraffort remi.duraffort@linaro.org wrote:
Hello,
I created a merge request for a similar issue to lony send the commands
that are actually used. But in order to fix that properly, I have to create another set of u-boot commands to support ramdisk and another one for ramdisk-nfs.
See https://git.lavasoftware.org/lava/lava/merge_requests/492
In order to merge this MR we need a migration path to keep compatibility
with jobs that uses the ability to use both ramdisk and nfs at the same time.
Wouldn't it be better to simply omit the ramdisk related line from u-boot commands when ramdisk is not defined in the job?
milosz
Rgds
Le lun. 11 nov. 2019 à 13:02, Diego Russo Diego.Russo@arm.com a écrit
:
> What's the best way to solve the issue. How can I tell LAVA notto deal with the RAMDISK at all?
I saw this problem on some other board (don't remember which one).The
quick fix is to replace the bootloader commands with custom ones either in device dictionary or in the job. In the long run thisneeds
to be fixed in LAVA. I'll create a ticket if there isn't onealready.
For updating the commands in the job, here is the snippet: - boot: timeout: minutes: 10 method: u-boot commands: - setenv autoload no - dhcp - env print - setenv serverip {SERVER_IP} - tftp {KERNEL_ADDR} {KERNEL} - tftp {DTB_ADDR} {DTB} - setenv bootargs 'console=ttyS0,115200n8 root=/dev/nfs rw nfsroot={NFS_SERVER_IP}:{NFSROOTFS},tcp,hard,intr,vers=3 rootwait coherent_pool=2M ip=dhcp' - '{BOOTX}' This should do the trick for now. miloszMilosz,
I've come up with a similar solution. I've added the following lines
into the device type of the board:
{% set uboot_tftp_commands = [ "tftp {KERNEL_ADDR} {KERNEL}", "tftp {DTB_ADDR} {DTB}"] -%}
Thanks
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
-- Rémi Duraffort LAVA Architect Linaro
See https://git.lavasoftware.org/lava/lava/blob/master/etc/dispatcher-config/dev...
Le mar. 12 nov. 2019 à 14:17, Remi Duraffort remi.duraffort@linaro.org a écrit :
Yes but it's difficult to know which line to remove as we only have a list of commands to send. Without any metadata.
Le mar. 12 nov. 2019 à 14:15, Milosz Wasilewski < milosz.wasilewski@linaro.org> a écrit :
On Tue, 12 Nov 2019 at 13:13, Remi Duraffort remi.duraffort@linaro.org wrote:
Hello,
I created a merge request for a similar issue to lony send the commands
that are actually used. But in order to fix that properly, I have to create another set of u-boot commands to support ramdisk and another one for ramdisk-nfs.
See https://git.lavasoftware.org/lava/lava/merge_requests/492
In order to merge this MR we need a migration path to keep
compatibility with jobs that uses the ability to use both ramdisk and nfs at the same time.
Wouldn't it be better to simply omit the ramdisk related line from u-boot commands when ramdisk is not defined in the job?
milosz
Rgds
Le lun. 11 nov. 2019 à 13:02, Diego Russo Diego.Russo@arm.com a
écrit :
> What's the best way to solve the issue. How can I tell LAVA notto deal with the RAMDISK at all?
I saw this problem on some other board (don't remember which one).The
quick fix is to replace the bootloader commands with custom ones either in device dictionary or in the job. In the long run thisneeds
to be fixed in LAVA. I'll create a ticket if there isn't onealready.
For updating the commands in the job, here is the snippet: - boot: timeout: minutes: 10 method: u-boot commands: - setenv autoload no - dhcp - env print - setenv serverip {SERVER_IP} - tftp {KERNEL_ADDR} {KERNEL} - tftp {DTB_ADDR} {DTB} - setenv bootargs 'console=ttyS0,115200n8 root=/dev/nfs rw nfsroot={NFS_SERVER_IP}:{NFSROOTFS},tcp,hard,intr,vers=3 rootwait coherent_pool=2M ip=dhcp' - '{BOOTX}' This should do the trick for now. miloszMilosz,
I've come up with a similar solution. I've added the following lines
into the device type of the board:
{% set uboot_tftp_commands = [ "tftp {KERNEL_ADDR} {KERNEL}", "tftp {DTB_ADDR} {DTB}"] -%}
Thanks
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
-- Rémi Duraffort LAVA Architect Linaro
-- Rémi Duraffort LAVA Architect Linaro
I didn't test it, just a suggestion:
{% set base_uboot_kernel_commands = base_uboot_kernel_commands|default(["tftp {KERNEL_ADDR} {KERNEL}"]) %} {% set base_uboot_ramdisk_commands = base_uboot_kernel_commands|default(["tftp {RAMDISK_ADDR} {RAMDISK}"]) %}
{% if RAMDISK is defined %} {% set base_uboot_tftp_commands = uboot_tftp_commands|default(base_uboot_kernel_commands + base_uboot_ramdisk_commands + ["setenv initrd_size ${filesize}"] + uboot_load_fdt) -%} {% else %} {% set base_uboot_tftp_commands = uboot_tftp_commands|default(base_uboot_kernel_commands + ["setenv initrd_size ${filesize}"] + uboot_load_fdt) -%} {% endif %}
milosz
On Tue, 12 Nov 2019 at 13:17, Remi Duraffort remi.duraffort@linaro.org wrote:
See https://git.lavasoftware.org/lava/lava/blob/master/etc/dispatcher-config/dev...
Le mar. 12 nov. 2019 à 14:17, Remi Duraffort remi.duraffort@linaro.org a écrit :
Yes but it's difficult to know which line to remove as we only have a list of commands to send. Without any metadata.
Le mar. 12 nov. 2019 à 14:15, Milosz Wasilewski milosz.wasilewski@linaro.org a écrit :
On Tue, 12 Nov 2019 at 13:13, Remi Duraffort remi.duraffort@linaro.org wrote:
Hello,
I created a merge request for a similar issue to lony send the commands that are actually used. But in order to fix that properly, I have to create another set of u-boot commands to support ramdisk and another one for ramdisk-nfs.
See https://git.lavasoftware.org/lava/lava/merge_requests/492
In order to merge this MR we need a migration path to keep compatibility with jobs that uses the ability to use both ramdisk and nfs at the same time.
Wouldn't it be better to simply omit the ramdisk related line from u-boot commands when ramdisk is not defined in the job?
milosz
Rgds
Le lun. 11 nov. 2019 à 13:02, Diego Russo Diego.Russo@arm.com a écrit :
> What's the best way to solve the issue. How can I tell LAVA not to deal with the RAMDISK at all? I saw this problem on some other board (don't remember which one). The quick fix is to replace the bootloader commands with custom ones either in device dictionary or in the job. In the long run this needs to be fixed in LAVA. I'll create a ticket if there isn't one already. For updating the commands in the job, here is the snippet: - boot: timeout: minutes: 10 method: u-boot commands: - setenv autoload no - dhcp - env print - setenv serverip {SERVER_IP} - tftp {KERNEL_ADDR} {KERNEL} - tftp {DTB_ADDR} {DTB} - setenv bootargs 'console=ttyS0,115200n8 root=/dev/nfs rw nfsroot={NFS_SERVER_IP}:{NFSROOTFS},tcp,hard,intr,vers=3 rootwait coherent_pool=2M ip=dhcp' - '{BOOTX}' This should do the trick for now. miloszMilosz,
I've come up with a similar solution. I've added the following lines into the device type of the board:
{% set uboot_tftp_commands = [ "tftp {KERNEL_ADDR} {KERNEL}", "tftp {DTB_ADDR} {DTB}"] -%}
Thanks
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
-- Rémi Duraffort LAVA Architect Linaro
-- Rémi Duraffort LAVA Architect Linaro
-- Rémi Duraffort LAVA Architect Linaro
Hello Milosz,
The problem here is that the list of commands is part of the device configuration jinja2 template which is rendered without any knowledge of the job definition itself. So we can test for the presence of a ramdisk. At least not we the current setup.
I had a hacky patch that does check for the presence of a placeholder (like {RAMDISK}) and remove the line if the placeholder is still present after the substitution. This would work fine but I'm wondering about possible breakage on some boards.
Cheers
Le mar. 12 nov. 2019 à 14:23, Milosz Wasilewski < milosz.wasilewski@linaro.org> a écrit :
I didn't test it, just a suggestion:
{% set base_uboot_kernel_commands = base_uboot_kernel_commands|default(["tftp {KERNEL_ADDR} {KERNEL}"]) %} {% set base_uboot_ramdisk_commands = base_uboot_kernel_commands|default(["tftp {RAMDISK_ADDR} {RAMDISK}"]) %}
{% if RAMDISK is defined %} {% set base_uboot_tftp_commands = uboot_tftp_commands|default(base_uboot_kernel_commands + base_uboot_ramdisk_commands + ["setenv initrd_size ${filesize}"] + uboot_load_fdt) -%} {% else %} {% set base_uboot_tftp_commands = uboot_tftp_commands|default(base_uboot_kernel_commands + ["setenv initrd_size ${filesize}"] + uboot_load_fdt) -%} {% endif %}
milosz
On Tue, 12 Nov 2019 at 13:17, Remi Duraffort remi.duraffort@linaro.org wrote:
See
https://git.lavasoftware.org/lava/lava/blob/master/etc/dispatcher-config/dev...
Le mar. 12 nov. 2019 à 14:17, Remi Duraffort remi.duraffort@linaro.org
a écrit :
Yes but it's difficult to know which line to remove as we only have a
list of commands to send. Without any metadata.
Le mar. 12 nov. 2019 à 14:15, Milosz Wasilewski <
milosz.wasilewski@linaro.org> a écrit :
On Tue, 12 Nov 2019 at 13:13, Remi Duraffort <
remi.duraffort@linaro.org> wrote:
Hello,
I created a merge request for a similar issue to lony send the
commands that are actually used. But in order to fix that properly, I have to create another set of u-boot commands to support ramdisk and another one for ramdisk-nfs.
See https://git.lavasoftware.org/lava/lava/merge_requests/492
In order to merge this MR we need a migration path to keep
compatibility with jobs that uses the ability to use both ramdisk and nfs at the same time.
Wouldn't it be better to simply omit the ramdisk related line from u-boot commands when ramdisk is not defined in the job?
milosz
Rgds
Le lun. 11 nov. 2019 à 13:02, Diego Russo Diego.Russo@arm.com a
écrit :
> What's the best way to solve the issue. How can I tell LAVAnot to deal with the RAMDISK at all?
I saw this problem on some other board (don't remember whichone). The
quick fix is to replace the bootloader commands with custom ones either in device dictionary or in the job. In the long run thisneeds
to be fixed in LAVA. I'll create a ticket if there isn't onealready.
For updating the commands in the job, here is the snippet: - boot: timeout: minutes: 10 method: u-boot commands: - setenv autoload no - dhcp - env print - setenv serverip {SERVER_IP} - tftp {KERNEL_ADDR} {KERNEL} - tftp {DTB_ADDR} {DTB} - setenv bootargs 'console=ttyS0,115200n8 root=/dev/nfs rw nfsroot={NFS_SERVER_IP}:{NFSROOTFS},tcp,hard,intr,vers=3 rootwait coherent_pool=2M ip=dhcp' - '{BOOTX}' This should do the trick for now. miloszMilosz,
I've come up with a similar solution. I've added the following
lines into the device type of the board:
{% set uboot_tftp_commands = [ "tftp {KERNEL_ADDR} {KERNEL}", "tftp {DTB_ADDR} {DTB}"] -%}
Thanks
IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
-- Rémi Duraffort LAVA Architect Linaro
-- Rémi Duraffort LAVA Architect Linaro
-- Rémi Duraffort LAVA Architect Linaro
lava-users@lists.lavasoftware.org
-
Diego Russo -
Milosz Wasilewski -
Remi Duraffort