[yocto] Automate hardware test using oeqa runtime library
Hi Richard, I wrote some scripts to test USB mount/unmount, read & write on real hardware. I use OEQA runtime library to wrote the test cases. However, these tests only work on hardware and not for qemu. Since these tests run on hardware, I need to add a flag to avoid the tests execute on qemu. I am not sure if these tests case should pass on qemu too. Links below refer to patches of BSP test cases to test USB. There are 2 patches files called "bsp-test-helper" and usb.py. bsp-test-helper is a wrapper script to execute USB test cases on usb.py file. USB test cases, usb.py https://lists.yoctoproject.org/pipermail/yocto/2018-August/042261.html wrapper script, bsp-test-helper https://lists.yoctoproject.org/pipermail/yocto/2018-August/042262.html Regards, Alim Hussin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] runtime: add BSP test case for usb storage
HI Paul, This patch is my supersede of earlier "manualbsp" which I split into 2 parts called usb test and microsd test. I would use MACHINE_FEATURES = "usbhost" instead of introducing new variable as it would eliminate problem in case someone try to execute the usb test case without enable the "HARDWARE_TEST = 1" or download the image form public autobuilder. > Otherwise I agree with Mike's reply, we should avoid writing to the storage > device as part of the test. It is mean that just do test like mount and unmount only? To read something in storage device we need to write at first place? Regards, Alim Hussin -Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: Monday, September 24, 2018 4:50 AM To: Hussin, Mohamad Noor Alim Cc: yocto@yoctoproject.org Subject: Re: [yocto] [PATCH] runtime: add BSP test case for usb storage Hi Alim, On Monday, 20 August 2018 3:22:09 AM NZST mohamad.noor.alim.hus...@intel.com wrote: > From: Mohamad Noor Alim Hussin > > Contain test cases to test mount/unmount the usb stick on target > platform such as minnowboard and beaglebone. The test assume that the > usb storage device such as usb thumb drive was plugged into the target > device otherwise the test for would failed. It also test to read and > write from usb thumb drive. Usb test cases start with mount the usb > thumb drive then write and read from it. Lastly, it will unmount it. > If the usb thumb drive unable to mount due to corrupt of partition or > not exists, then the mount test will failed and the following test > would skip. Does this supersede part of your earlier "manualbsp" patch? It's not made clear here or in the cover letter but it looks like it might. The helper script patch needs to come before this patch rather than after it, since this patch won't work without it. > This test need to enable flag 'HARDWARE_TEST = "1"' on conf/local.conf > file in order to run on target device. This test should be skip on qemu. Can we use "usbhost" being in MACHINE_FEATURES and MACHINE not starting with "qemu" to enable this instead of adding another variable? (Assuming that sounds reasonable to everyone else) Otherwise I agree with Mike's reply, we should avoid writing to the storage device as part of the test. Also, as this is patching OE-Core, the patch needs to be sent to the openembedded-c...@lists.openembedded.org mailing list, if you could please use that for the next revision that would be great. Thanks, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] runtime: Add support to manual BSP test cases
TestID was determined from testopia,
https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=9635.
Regards,
Alim Hussin
-Original Message-
From: akuster808 [mailto:akuster...@gmail.com]
Sent: Friday, July 13, 2018 10:52 PM
To: Hussin, Mohamad Noor Alim ;
yocto@yoctoproject.org; richard.pur...@linuxfoundation.org
Subject: Re: [yocto] [PATCH] runtime: Add support to manual BSP test cases
On 07/13/2018 05:08 AM, mohamad.noor.alim.hus...@intel.com wrote:
> From: Mohamad Noor Alim Hussin
>
> This is manual BSP test cases that have converted to auto test cases
> for QA release. Manualbsp.py has dependency on file bsphardware that
> run on hardware.
How do the TestID get determined?
Also, I think this patch needs to be cc'd to
"openembedded-c...@lists.openembedded.org"
>
> Signed-off-by: Mohamad Noor Alim Hussin
>
> ---
> meta/lib/oeqa/runtime/cases/manualbsp.py | 122
> meta/lib/oeqa/runtime/files/bsphardware
> | 132 +++
> 2 files changed, 254 insertions(+)
> create mode 100644 meta/lib/oeqa/runtime/cases/manualbsp.py
> create mode 100755 meta/lib/oeqa/runtime/files/bsphardware
>
> diff --git a/meta/lib/oeqa/runtime/cases/manualbsp.py
> b/meta/lib/oeqa/runtime/cases/manualbsp.py
> new file mode 100644
> index 000..22d0d33
> --- /dev/null
> +++ b/meta/lib/oeqa/runtime/cases/manualbsp.py
> @@ -0,0 +1,122 @@
> +from oeqa.runtime.case import OERuntimeTestCase from
> +oeqa.core.decorator.depends import OETestDepends from
> +oeqa.core.decorator.oeid import OETestID import subprocess import
> +time
> +
> +class BspRuntimeTest(OERuntimeTestCase):
> +
> +@OETestID(240)
> +def test_check_bash(self):
> +status, output = self.target.run('which bash')
> +msg = ('bash shell not working as expected. '
> +'Status and output:%s and %s.' % (status, output))
> +self.assertEqual(status, 0, msg = msg)
> +
> +@OETestID(228)
> +def test_runlevel_5(self):
> +status, output = self.target.run('init 5')
> +msg = ('System unable to init 5 '
> +'Status and output:%s and %s.' % (status, output))
> +self.assertEqual(status, 255, msg = msg)
> +time.sleep(2)
> +command = 'bsphardware -r 5'
> +status, output = self.target.run(command)
> +msg = ('System did not start from runlevel 5. '
> +'Status:%s.' % (status))
> +self.assertEqual(status, 0, msg = msg)
> +
> +@OETestID(198)
> +def test_runlevel_3(self):
> +status, output = self.target.run('init 3')
> +msg = ('System unable to start with runlevel 3. '
> +'Status and output:%s and %s.' % (status, output))
> +self.assertEqual(status, 255, msg = msg)
> +time.sleep(2)
> +command = 'bsphardware -r 3'
> +status, output = self.target.run(command)
> +msg = ('Unable to change from runlevel 5 to 3. '
> +'Status and output:%s and %s.' % (status, output))
> +self.assertEqual(status, 0, msg = msg)
> +
> +class BspHardwareTest(OERuntimeTestCase):
> +
> +@classmethod
> +def setUpClass(cls):
> +src = os.path.join(cls.tc.runtime_files_dir, 'bsphardware')
> +cls.tc.target.run('mkdir ~/test')
> +cls.tc.target.copyTo(src, '/usr/bin')
> +
> +@classmethod
> +def tearDownClass(cls):
> +cls.tc.target.run('rm -rf ~/test')
> +
> +@OETestID(216)
> +def test_USB_mount(self):
> +command = 'bsphardware -d sd -sp 1 -m ~/test/stick'
> +status, output = self.target.run(command)
> +msg = ('Unable to mount USB stick. '
> +'Status and output:%s and %s.' % (status, output))
> +self.assertEqual(status, 0, msg = msg)
> +
> +@OETestID(217)
> +@OETestDepends(['manualbsp.BspHardwareTest.test_USB_write_file'])
> +def test_USB_read_file(self):
> +command = 'cat ~/test/stick/hello_stick'
> +status, output = self.target.run(command)
> +msg = ('Unable to read file from USB stick. '
> +'Status and output:%s and %s.' % (status, output))
> +self.assertEqual(status, 0, msg = msg)
> +
> +@OETestDepends(['manualbsp.BspHardwareTest.test_USB_mount'])
> +@OETestID(219)
> +def test_USB_write_file(self):
> +command = 'touch ~/test/stick/hello_stick'
> +status, output = self.target.run(command)
> +msg = ('Status and output:%s and %s.' % (status, output))
> +self.assertEqual(status, 0, msg = msg)
> +
> +@OETestDepends(['manualbsp.BspHardwareTest.test_USB_mount'])
> +@OETest
Re: [linux-yocto] [PATCH] igb.cfg: change igb config from m to y
This is for yocto-4.14 and yocto-4.15. Regards, Alim Hussin -Original Message- From: Hussin, Mohamad Noor Alim Sent: Wednesday, June 27, 2018 5:01 AM To: linux-yocto@yoctoproject.org Cc: Hussin, Mohamad Noor Alim ; Chan, Aaron Chun Yew Subject: [PATCH] igb.cfg: change igb config from m to y From: Mohamad Noor Alim Hussin Yocto Project reference board such as Minnowboard need IGB module to enable ethernet networking. It need to bundle together with kernel when use NFS boot without initramfs. Signed-off-by: Mohamad Noor Alim Hussin --- features/igb/igb.cfg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/features/igb/igb.cfg b/features/igb/igb.cfg index 89216c9..a3e549b 100644 --- a/features/igb/igb.cfg +++ b/features/igb/igb.cfg @@ -1,2 +1,2 @@ -CONFIG_IGB=m +CONFIG_IGB=y CONFIG_IGBVF=m -- 2.7.4 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] PXE Boot NFS not working
Regarding to your question on legacy BIOS.
1. vesamenu.c32 or menu.32 are graphic library to display PXE menu.
Normally if you don't provide these files, you will not able to see PXE menu.
2. Use kernel or linux parameter is depend on your GRUB bootloader
command. You can try to load the kernel without initrd/initramfs/rootfs to make
sure your kernel able to load from network. After you able to load the kernel,
you will hit kernel panic as kernel unable to find rootfs.
3. 3. "hard,tcp,intr" they are nfs parameter. If your server side use nfs
v3 the you need to specify "nfsroot=192.168.1.2:/srv/rootfs,nfsvers=3".
4. Make sure you only have one DHCP service running. If you use router,
turn off the DHCP service on your router. Another way just put static IP
address for your board in dhcpd.conf. if you want to have another DHCP server
running then you need to use proxyDHCP on your PXE server.
a. Example for configure static IP in DHCP server.
host myboard {
hardware ethernet 00:0A:A1:B2:C3:;
fixed-address 192.168.1.1;
}
5. Your kernel wait for "removable media"? Are you include
initramfs/initrd? Actually you can remove initramfs/initrd if you want to use
NFS boot. Can you check LED on Ethernet port. If blink the your network is up.
Try to ping to your target device to make sure your network is working.
Regards,
Alim Hussin
From: Raymond Yeung [mailto:rksye...@hotmail.com]
Sent: Friday, April 27, 2018 12:43 PM
To: Hussin, Mohamad Noor Alim <mohamad.noor.alim.hus...@intel.com>;
yocto@yoctoproject.org
Subject: Re: PXE Boot NFS not working
Thanks a lot Alim for the detail step-by-step, for both modes. I'd like to
stay with legacy mode with pxelinux.0 for now. I'm doing pretty much the same
as what you described below, with exceptions -
1. I'm not using vesamenu.c32. Instead menu.32 is used, though I don't
think that would be an issue.
2. I use "kernel image/bzImage" instead of "linux image/bzImage". Still
this shouldn't be an issue.
3. With the "append" line, I've a question - what is the significance of the
options "hard, tcp, intr"? I currently don't use them.
Since my last email this morning, I'd made some progress -
1. I figured out how to reconfigure the kernel with bitbake menuconfig to
change my Ethernet driver from .ko to part of kernel.
2. I now have a confusing situation, due to Avahi-daemon in the mix.
PXEBoot would request IP address via DHCP. Then when this NFS boot runs, it
too uses DHCP, and allocates a different IP address. I suppose this is fine,
so long as I've enough IP address to spare. However, Avahi-daemon also request
IP address and get the board yet another IP address. I've yet to figure out
how to turn off Avahi-daemon. And NFS boot still doesn't work (I don't see the
mount point with "df -h").
3. Client side uses NFS v4.1 while server side uses v3. Would this be a
problem? I suppose there must be backward compatibility built into NFS.
Also, in the "Append" line of pxelinux.cfg/default, I add nfsrootdebug. What
sort of NFS debugs should I see? I only see two NFS logs, and 4 RPC calls. Is
there anyway to turn up the verbosity so I know how NFS client fails?
Until I get some more insights to above, I'd proceed to investigate the other
issue - why my kernel initialization would need to wait for any "removable
media" indefinitely, and see if I could fix/change this.
Thanks,
Raymond
From: Hussin, Mohamad Noor Alim
<mohamad.noor.alim.hus...@intel.com<mailto:mohamad.noor.alim.hus...@intel.com>>
Sent: Thursday, April 26, 2018 8:30 PM
To: Raymond Yeung; yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Subject: RE: PXE Boot NFS not working
You are using PXE with legacy BIOS as you use pxelinux.0 . To configure PXE
with legacy BIOS follow these instruction
Note: PXE server IP = 192.168.1.2
Target IP = 192.168.1.1
On PXE server
1. make sure DHCP, NFS & TFTP services are up and running.
2. change the filename "pxelinux.0"; in /etc/dhcp/dhcpd.conf. Then
restart your DHCP service.
3. Put your kernel to /path/to/tftpboot/image/ and extract your rootfs to
/srv/rootfs/.
4. Create a file in /path/to/tftpboot/pxelinux.cfg/default. The content
should like this
include menu.cfg
default vesamenu.c32
prompt 0
timeout 5
label Manual Netboot genericx86-64
menu label Netboot genericx86-64
linux image/bzImage
append root=/dev/nfs rw nfsroot=192.168.1.2:/srv/rootfs,hard,tcp,intr ip=dhcp
if you want to use PXE with GRUB, bootx64.efi, you need to enable UEFI instead
of legacy BIOS in BIOS configuration. Follow these instruction.
on PXE server
1. make sure DHCP, NFS & TFTP services are up and running.
2. change the filename "bootx64.efi
Re: [yocto] PXE Boot NFS not working
You are using PXE with legacy BIOS as you use pxelinux.0 . To configure PXE
with legacy BIOS follow these instruction
Note: PXE server IP = 192.168.1.2
Target IP = 192.168.1.1
On PXE server
1. make sure DHCP, NFS & TFTP services are up and running.
2. change the filename "pxelinux.0"; in /etc/dhcp/dhcpd.conf. Then
restart your DHCP service.
3. Put your kernel to /path/to/tftpboot/image/ and extract your rootfs to
/srv/rootfs/.
4. Create a file in /path/to/tftpboot/pxelinux.cfg/default. The content
should like this
include menu.cfg
default vesamenu.c32
prompt 0
timeout 5
label Manual Netboot genericx86-64
menu label Netboot genericx86-64
linux image/bzImage
append root=/dev/nfs rw nfsroot=192.168.1.2:/srv/rootfs,hard,tcp,intr ip=dhcp
if you want to use PXE with GRUB, bootx64.efi, you need to enable UEFI instead
of legacy BIOS in BIOS configuration. Follow these instruction.
on PXE server
1. make sure DHCP, NFS & TFTP services are up and running.
2. change the filename "bootx64.efi"; in /etc/dhcp/dhcpd.conf. Then
restart your DHCP service.
3. Put your kernel to /path/to/tftpboot/image/ and extract your rootfs to
/srv/rootfs/.
4. If you want to get into GRUB,
a. comment the commands from /path/to/tftpboot/grub/grub.cfg to avoid
grub automatically load the kernel from network.
b. On GRUB, press "TAB" key to list available command. Or you can try use
this command
i. net_bootp
ii. linux
(tftp,pxeserverip)/image/bzImage root=/dev/nfs rw
nfsroot=192.168.1.2:/srv/rootfs,hard,tcp,intr ip=dhcp
iii. boot
5. if you want boot automatically to NFS, create a file called grub.cfg
in /path/to/tftpboot/grub.cfg. your grub.cfg should look like this
Set timeout 5
menuentry " genericx86-64" {
linux image/bzImage root=/dev/nfs rw
nfsroot=192.168.1.2:/srv/rootfs,hard,tcp,intr ip=dhcp
initrd image/initrd
}
6. When your device boot, it will download bootx64.efi and the message
something like this
>>Start PXE over IPv4.
Station IP address is 192.168.1.1
Server IP address is 192.168.1.2
NBP filename is bootx64.efi
NBP filesize is 1137016 Bytes
Downloading NBP file...
NBP file downloaded successfully.
Please note that I did not use initramfs or initrd as my kernel already have
network module build-in. To build your kernel with network module, you need to
know which module need to build-in into your kernel. Simply boot your device
using *.hhdimg from USB stick. Then check loaded kernel module from your device.
$ lsmod
Find the module something with network. Yes it is a little bit tricky.
Build your kernel in host machine.
$ bitbake virtual/kernel -c menuconfig
A menu will popup and search your kernel module using key "/". Make sure symbol
module [*] indicate build-in.
$ bitbake virtual/kernel
You also can create a kernel bundle with initramfs. Read this
https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#building-an-initramfs-image.
Maybe need to ask someone who are expert on kernel development on how to enable
build-in kernel module.
Regards,
Alim Hussin
From: Raymond Yeung [mailto:rksye...@hotmail.com]
Sent: Friday, April 27, 2018 1:12 AM
To: Hussin, Mohamad Noor Alim <mohamad.noor.alim.hus...@intel.com>;
yocto@yoctoproject.org
Subject: Re: PXE Boot NFS not working
Follow-up to my previous post, after seeing the reply below suggesting me not
to use initramfs (but initrd is usable, right?). BTW, I don't use bootx64.efi.
Instead, I use pxelinux.0 along with the other lib***.c32 files.
1. Is there a way to verify if GRUB (that I'm using) supports networking or
not? It seems to have very limited user commands available.
2. How do I get into GRUB? I'd been into GRUB, more like accidentally. The
reply below refers to grub.cfg. Is this cfg file stored on target, or on host
(like pxelinux.cfg)?
3. How do I configure my build (and what yocto tool to use, if any) in order
to get my network driver part of kernel, instead of being a LKM that isn't
there when I need it for NFS boot?
From: Hussin, Mohamad Noor Alim
<mohamad.noor.alim.hus...@intel.com<mailto:mohamad.noor.alim.hus...@intel.com>>
Sent: Thursday, April 26, 2018 12:26 AM
To: Raymond Yeung; yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Subject: RE: PXE Boot NFS not working
Refer to my post here
https://lists.yoctoproject.org/pipermail/yocto/2018-April/040860.html
Don't use initramfs/initrd as it not working.
Regards,
Alim Hussin
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] PXE Boot NFS not working
Refer to my post here https://lists.yoctoproject.org/pipermail/yocto/2018-April/040860.html Don't use initramfs/initrd as it not working. Regards, Alim Hussin From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Raymond Yeung Sent: Thursday, April 26, 2018 12:46 PM To: yocto@yoctoproject.org Subject: [yocto] PXE Boot NFS not working I've an Intel Xeon-D board. I could boot up the board with PXE booting. However, this seems to be always looking for "removable media"; if there is none, it would hang (in a .sh file). I want to explore NFS approach. So far, I've read up, experimented on NFS setup via pxelinux.cfg/default file. I'm able to manually perform nfs mount from client side, but doing it via configuration file doesn't seem to work. Now, I'm wondering if my bzImage and initrd files are built correct. According to this article here: https://wiki.yoctoproject.org/wiki/Poky_NFS_Root Two requirements must be met. First one is that the network driver must be built into the kernel rather than being a module. Second one is to disable network init script. Does anyone know how to do the above two items? What recipe file(s) should I modify? Thanks, Raymond -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Linux Files needed for PXE network boot
Maybe grub file bootx64.efi do not have network module. You can try to use
grub provided by Ubuntu
http://archive.ubuntu.com/ubuntu/dists/trusty/main/uefi/grub2-amd64/current/grubnetx64.efi.signed
Or build your own grub that build-in with network capability.
In your root tftp server create a grub folder with grub.cfg.
/tftpboot/grub/grub.cfg
Your grub.cfg should look like this
=
Set timeout 5
menuentry "core-image-sato" {
linux image/bzImage
initrd image/initrd
}
==
Put your image in tftp root
/tftpboot/image/bzImage
/tftpboot/image/initrd
If you want to put your rootfs in NFS. You need to include network module in
kernel and extract your rootfs for example to /srv/rootfs. Then your grub.cfg
should be like this
= grub.cfg
Set timeout 5
menuentry "core-image-sato-NFS" {
linux image/bzImage root=/dev/nfs rw
nfsroot=192.168.1.1:/srv/rootfs,hard,tcp,intr ip=dhcp
initrd image/initrd
}
Regards,
Alim Hussin
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
