Hello LAVA mailing list,
I see RPI3 is supported by LAVA but unfortunately it doesn't fit Mbed Linux OS (MBL) case. Our build system produces a WIC image which can be written on the SD card directly (instructions here: https://os.mbed.com/docs/linux-os/v0.5/getting-started/writing-and-booting-t...). This is needed for two main reasons: * MBL has its own booting flow * MBL expects a partition layout (not only the rootfs) with multiple partitions in order to work.
What's the best way to automate the deployment on MBL on RPI3 via LAVA in order to run our tests?
Cheers
-- 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/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.
On Tue, 8 Jan 2019 at 19:36, Diego Russo Diego.Russo@arm.com wrote:
Hello LAVA mailing list,
I see RPI3 is supported by LAVA but unfortunately it doesn't fit Mbed Linux OS (MBL) case. Our build system produces a WIC image which can be written on the SD card directly (instructions here: https://os.mbed.com/docs/linux-os/v0.5/getting-started/writing-and-booting-t...). This is needed for two main reasons:
- MBL has its own booting flow
- MBL expects a partition layout (not only the rootfs) with multiple partitions in order to work.
What's the best way to automate the deployment on MBL on RPI3 via LAVA in order to run our tests?
I'd say there isn't any if you can't deliver your software to the board without manual operation (preparing SD card using host PC). You could try some sort of SDMux (for example this: https://wiki.tizen.org/MuxPi or this: https://wiki.tizen.org/SDWire) but from my experience they don't work. I didn't check them with RPi though, so there is some small chance of success :)
milosz
Cheers
-- 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/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
On Tue, 2019-01-08 at 21:05 +0000, Milosz Wasilewski wrote:
On Tue, 8 Jan 2019 at 19:36, Diego Russo Diego.Russo@arm.com wrote:
Hello LAVA mailing list,
I see RPI3 is supported by LAVA but unfortunately it doesn't fit Mbed Linux OS (MBL) case. Our build system produces a WIC image which can be written on the SD card directly (instructions here: https://os.mbed.com/docs/linux-os/v0.5/getting-started/writing-and-booting-t... ). This is needed for two main reasons:
- MBL has its own booting flow
- MBL expects a partition layout (not only the rootfs) with
multiple partitions in order to work.
What's the best way to automate the deployment on MBL on RPI3 via LAVA in order to run our tests?
I'd say there isn't any if you can't deliver your software to the board without manual operation (preparing SD card using host PC). You could try some sort of SDMux (for example this: https://wiki.tizen.org/MuxPi or this: https://wiki.tizen.org/SDWire) but from my experience they don't work. I didn't check them with RPi though, so there is some small chance of success :)
What we do on various board where we have a similar use-case is to split the lava test in esentially two stages: * network boot the system and flash the sd card (using deploy to secnodary media with a custom writer) * then boot into the sd card image and run the tests
See https://lava.collabora.co.uk/scheduler/job/1419582/definition for a practical example how we do this.
What this does require is that the bootloader isn't overwritten if you flash an image e.g. to be in a seperate flash/emmc hardware parittion/on the network
For the raspberry pi 3 you can enable network boot for this purpose: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmods/net_...
On 9 Jan 2019, at 08:52, Sjoerd Simons sjoerd.simons@collabora.co.uk wrote:
On Tue, 2019-01-08 at 21:05 +0000, Milosz Wasilewski wrote:
On Tue, 8 Jan 2019 at 19:36, Diego Russo Diego.Russo@arm.com wrote:
Hello LAVA mailing list,
I see RPI3 is supported by LAVA but unfortunately it doesn't fit Mbed Linux OS (MBL) case. Our build system produces a WIC image which can be written on the SD card directly (instructions here: https://os.mbed.com/docs/linux-os/v0.5/getting-started/writing-and-booting-t... ). This is needed for two main reasons:
- MBL has its own booting flow
- MBL expects a partition layout (not only the rootfs) with
multiple partitions in order to work.
What's the best way to automate the deployment on MBL on RPI3 via LAVA in order to run our tests?
I'd say there isn't any if you can't deliver your software to the board without manual operation (preparing SD card using host PC). You could try some sort of SDMux (for example this: https://wiki.tizen.org/MuxPi or this: https://wiki.tizen.org/SDWire) but from my experience they don't work. I didn't check them with RPi though, so there is some small chance of success :)
What we do on various board where we have a similar use-case is to split the lava test in esentially two stages:
- network boot the system and flash the sd card (using deploy to
secnodary media with a custom writer)
- then boot into the sd card image and run the tests
See https://lava.collabora.co.uk/scheduler/job/1419582/definition for a practical example how we do this.
What this does require is that the bootloader isn't overwritten if you flash an image e.g. to be in a seperate flash/emmc hardware parittion/on the network
For the raspberry pi 3 you can enable network boot for this purpose: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmods/net_...
Sjoerd, Milosz,
thanks for your replies.
Milosz: I did some investigations on SD MUX and I bumped into: https://pengutronix.de/en/blog/2017-10-23-usb-sd-mux_Intro.html They should be starting the production as we speak. In general I agree with you and I would prefer to avoid those.
Sjoerd: thanks for providing the LAVA pipeline, it’s very useful and it’s good to see we have similar cases.
I came up with another solution which I did try manually and it works. I need to check if this can be done via LAVA (and here I need your experience). This is the worflow:
On the LAVA worker: 1) Download the wic.gz image 2) Uncompress the image 3) Split the image in chunks of 800M (anyway less than 1GB 4) Start tftp server serving those chunks of data
On the RPI3: 1) boot at uboot and initialise network 2) tftp the first chunk 3) write the chunk to mmc 4) tftp the second chunk 5) write the chunk to mmc … x) reboot the board
Few things to note: * our image has u-boot in it
Now I have few questions: * Can such workflow be implemented in LAVA? * How can I achieve the multiple calls of tftp on the RPI3 in order to be dynamic (e.g.: image size changes)? * Every time I call a mmc write I need to specify offset (in hex) and size (in hex) - see below. * The size needs to be calculated: size (hex) / block size (hex)
Following few u-boot commands I’ve been running:
U-Boot> mmc part
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 8192 30367744 00000000-01 0c
U-Boot> tftp diegor/tftp/xaa Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 10.2.202.91; our IP address is 10.2.202.99 Filename 'diegor/tftp/xaa'. Load address: 0x200000 Loading: #####T T T T T T T ############################################ 800 MiB 2 MiB/s done Bytes transferred = 838860800 (32000000 hex)
U-Boot> mmc write 0x200000 0x0 0x190000
MMC write: dev # 0, block # 0, count 1638400 ... 1638400 blocks written: OK
U-Boot> tftp diegor/tftp/xab Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 10.2.202.91; our IP address is 10.2.202.99 Filename 'diegor/tftp/xab'. Load address: 0x200000 Loading: ################################################# 800 MiB 2.1 MiB/s done Bytes transferred = 838860800 (32000000 hex) U-Boot> mmc write 0x200000 0x190000 0x190000
MMC write: dev # 0, block # 1638400, count 1638400 ... 1638400 blocks written: OK U-Boot> tftp diegor/tftp/xac Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 10.2.202.91; our IP address is 10.2.202.99 Filename 'diegor/tftp/xac'. Load address: 0x200000 Loading: ################################################# 534 MiB 2.1 MiB/s done Bytes transferred = 559944192 (21601200 hex) U-Boot> mmc write 0x200000 0x320000 0x10B009
MMC write: dev # 0, block # 3276800, count 1093641 ... 1093641 blocks written: OK
After this, the micro SD card has the right partition table and it boots normally.
Thanks for your help
-- Sjoerd Simons Collabora Ltd.
-- 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/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.
Hello Diego,
I came up with another solution which I did try manually and it works. I
need to check if this can be done via LAVA (and here I need your experience). This is the worflow:
On the LAVA worker:
- Download the wic.gz image
- Uncompress the image
- Split the image in chunks of 800M (anyway less than 1GB
- Start tftp server serving those chunks of data
On the RPI3:
- boot at uboot and initialise network
- tftp the first chunk
- write the chunk to mmc
- tftp the second chunk
- write the chunk to mmc
… x) reboot the board
Few things to note:
- our image has u-boot in it
Now I have few questions:
- Can such workflow be implemented in LAVA?
This looks possible yes. Where is uboot stored? On the mmc or on another media? Because you should avoid touching the default uboot.
- How can I achieve the multiple calls of tftp on the RPI3 in order to be
dynamic (e.g.: image size changes)?
You will have to add some code in LAVA in order to send the right commands. So LAVA will know the addresses and can send the right strings.
Rémi,
On 10 Jan 2019, at 08:53, Remi Duraffort remi.duraffort@linaro.org wrote:
Hello Diego,
I came up with another solution which I did try manually and it works. I need to check if this can be done via LAVA (and here I need your experience). This is the worflow:
On the LAVA worker:
- Download the wic.gz image
- Uncompress the image
- Split the image in chunks of 800M (anyway less than 1GB
- Start tftp server serving those chunks of data
On the RPI3:
- boot at uboot and initialise network
- tftp the first chunk
- write the chunk to mmc
- tftp the second chunk
- write the chunk to mmc
… x) reboot the board
Few things to note:
- our image has u-boot in it
Now I have few questions:
- Can such workflow be implemented in LAVA?
This looks possible yes.
I’m glad this is possible! Are you able to give me pointers (e.g.: examples) on how to do that?
Where is uboot stored? On the mmc or on another media? Because you should avoid touching the default uboot.
u-boot is stored on mmc and we re-flash it every time. We use Trusted firmware boot flow (https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/firmwa...) and we know we can corrupt it (as any other component of the boot flow).
- How can I achieve the multiple calls of tftp on the RPI3 in order to be dynamic (e.g.: image size changes)?
You will have to add some code in LAVA in order to send the right commands. So LAVA will know the addresses and can send the right strings.
Also here any help would be more than welcome!
Thanks!
-- Rémi Duraffort LAVA Team
-- 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/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.
On Wed, 9 Jan 2019 at 17:19, Diego Russo Diego.Russo@arm.com wrote:
On 9 Jan 2019, at 08:52, Sjoerd Simons sjoerd.simons@collabora.co.uk wrote:
On Tue, 2019-01-08 at 21:05 +0000, Milosz Wasilewski wrote:
On Tue, 8 Jan 2019 at 19:36, Diego Russo Diego.Russo@arm.com wrote:
Hello LAVA mailing list,
I see RPI3 is supported by LAVA but unfortunately it doesn't fit Mbed Linux OS (MBL) case. Our build system produces a WIC image which can be written on the SD card directly (instructions here: https://os.mbed.com/docs/linux-os/v0.5/getting-started/writing-and-booting-t... ). This is needed for two main reasons:
- MBL has its own booting flow
- MBL expects a partition layout (not only the rootfs) with
multiple partitions in order to work.
What's the best way to automate the deployment on MBL on RPI3 via LAVA in order to run our tests?
I'd say there isn't any if you can't deliver your software to the board without manual operation (preparing SD card using host PC). You could try some sort of SDMux (for example this: https://wiki.tizen.org/MuxPi or this: https://wiki.tizen.org/SDWire) but from my experience they don't work. I didn't check them with RPi though, so there is some small chance of success :)
What we do on various board where we have a similar use-case is to split the lava test in esentially two stages:
- network boot the system and flash the sd card (using deploy to
secnodary media with a custom writer)
- then boot into the sd card image and run the tests
See https://lava.collabora.co.uk/scheduler/job/1419582/definition for a practical example how we do this.
What this does require is that the bootloader isn't overwritten if you flash an image e.g. to be in a seperate flash/emmc hardware parittion/on the network
For the raspberry pi 3 you can enable network boot for this purpose: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmods/net_...
Sjoerd, Milosz,
thanks for your replies.
Milosz: I did some investigations on SD MUX and I bumped into: https://pengutronix.de/en/blog/2017-10-23-usb-sd-mux_Intro.html They should be starting the production as we speak. In general I agree with you and I would prefer to avoid those.
I just tried SDwire with RPi3 and it works. I'm not sure how stable it will be in bigger production environment, but for me I booted 3 out of 3 times with success. If you could share some MBL image I can try this as well.
Sjoerd: thanks for providing the LAVA pipeline, it’s very useful and it’s good to see we have similar cases.
I came up with another solution which I did try manually and it works. I need to check if this can be done via LAVA (and here I need your experience). This is the worflow:
On the LAVA worker:
- Download the wic.gz image
- Uncompress the image
- Split the image in chunks of 800M (anyway less than 1GB
- Start tftp server serving those chunks of data
On the RPI3:
- boot at uboot and initialise network
- tftp the first chunk
- write the chunk to mmc
- tftp the second chunk
- write the chunk to mmc
… x) reboot the board
maybe it would be easier to implement sth like fastboot for your u-boot? This way you would avoid splitting to chunks as fastboot does that for you. The only difference between your approach and fastboot is that you probably need to discard partitions. One possible issue is that when you write the full disk image you will overwrite the u-boot you're using. This might result in 'bricking' the board and require manual recovery.
milosz
Few things to note:
- our image has u-boot in it
Now I have few questions:
- Can such workflow be implemented in LAVA?
- How can I achieve the multiple calls of tftp on the RPI3 in order to be dynamic (e.g.: image size changes)?
- Every time I call a mmc write I need to specify offset (in hex) and size (in hex) - see below.
- The size needs to be calculated: size (hex) / block size (hex)
Following few u-boot commands I’ve been running:
U-Boot> mmc part
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 8192 30367744 00000000-01 0c
U-Boot> tftp diegor/tftp/xaa Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 10.2.202.91; our IP address is 10.2.202.99 Filename 'diegor/tftp/xaa'. Load address: 0x200000 Loading: #####T T T T T T T ############################################ 800 MiB 2 MiB/s done Bytes transferred = 838860800 (32000000 hex)
U-Boot> mmc write 0x200000 0x0 0x190000
MMC write: dev # 0, block # 0, count 1638400 ... 1638400 blocks written: OK
U-Boot> tftp diegor/tftp/xab Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 10.2.202.91; our IP address is 10.2.202.99 Filename 'diegor/tftp/xab'. Load address: 0x200000 Loading: ################################################# 800 MiB 2.1 MiB/s done Bytes transferred = 838860800 (32000000 hex) U-Boot> mmc write 0x200000 0x190000 0x190000
MMC write: dev # 0, block # 1638400, count 1638400 ... 1638400 blocks written: OK U-Boot> tftp diegor/tftp/xac Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 10.2.202.91; our IP address is 10.2.202.99 Filename 'diegor/tftp/xac'. Load address: 0x200000 Loading: ################################################# 534 MiB 2.1 MiB/s done Bytes transferred = 559944192 (21601200 hex) U-Boot> mmc write 0x200000 0x320000 0x10B009
MMC write: dev # 0, block # 3276800, count 1093641 ... 1093641 blocks written: OK
After this, the micro SD card has the right partition table and it boots normally.
Thanks for your help
-- Sjoerd Simons Collabora Ltd.
-- 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/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@lists.lavasoftware.org
-
Diego Russo -
Milosz Wasilewski -
Remi Duraffort -
Sjoerd Simons