[PATCH v3] luv-test-manger : Add time stamp and platform information to luv.results file
by Gayatri Kammela
Modify luv-test-manager to include platform information in results file
It is good to have this key information( like its processor and number of cores)
saved in luv.results file along with the timestamp.
Some platforms provides information about the number of cores
(included in the model name) and some doesn't. It is better to include this
explicitly in luv.results file.
Cc: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com>
Cc: Matt Fleming <matt.fleming(a)intel.com>
Signed-off-by: Gayatri Kammela <gayatri.kammela(a)intel.com>
---
Changes since v2:
Indentation (added colon for readability)and commited in latest master branch
Changes since v1:
Included information that displays the number of cores in a platform
meta-luv/recipes-core/initscripts/initscripts/luv-test-manager | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta-luv/recipes-core/initscripts/initscripts/luv-test-manager b/meta-luv/recipes-core/initscripts/initscripts/luv-test-manager
index 6c11ae537cbb..c7facef735f1 100644
--- a/meta-luv/recipes-core/initscripts/initscripts/luv-test-manager
+++ b/meta-luv/recipes-core/initscripts/initscripts/luv-test-manager
@@ -102,9 +102,9 @@ psplash_write "PROGRESS 0"
cat <<EOF | tee ${LUV_SAVE_RESULTS_DIR}/luv.results > /tmp/luv.results
$luv_version
-Date and time of the system :$tstamp
+Date and time of the system : $tstamp
-System: $(cat /proc/cpuinfo | grep 'model name' | cut -d: -f2 | uniq)
+System: $(cat /proc/cpuinfo | grep 'model name' | cut -d: -f2 | uniq) x $(nproc)
Test results summary:
--
1.9.1
6 years, 2 months
[V3 PATCH 0/4] AArch64: Build Linus' kernel
by Naresh Bhat
The set of patch does the following
- Add support to build the kernel.org Linus' tree in linux-yocto-efi-test
recipe i.e. master branch with full ACPI support.
- Add defconfig file under qemuarm64.
- Add aarch64 machine compatibality, SRC_URI and SRCREV variables for qemuarm64.
- Remove leg-kernel recipe and defconfig file.
- Remove genericarmv8 machine configuration files. Which means now you have to
use MACHINE = "qemuarm64" while building luvOS for ARM64 architecture.
Updated wiki page and the luv-live-image.img boot logs on QEMU/FVP base model
https://wiki.linaro.org/LEG/Engineering/luvOS#Boot_log_of_luvOS_on_ARM64
Changes since V0->V1
- Re-arrange the patches in such way that first add support to build kernel.org
kernel and then remove the leg-kernel dependency as suggested by Graeme.
Changes since V1->V2
- Remove genericarmv8 machine configuration files.
Changes since V2->V3
- Fix the issue INIT: Id "hvc0" respawning too fast: disabled for 5 minutes
by override serial console value in meta-luv layer.
Naresh Bhat (4):
linux-yocto-efi-test: Add support to AArch64
leg-kernel: Remove leg kernel recipe
genericarmv8: Remove genericarmv8 conf files
qemuarm64: Fix hvc0 respaning issue
meta-luv/conf/machine/qemuarm64.conf | 5 +
meta-luv/recipes-kernel/linux/leg-kernel/defconfig | 3116 --------------------
meta-luv/recipes-kernel/linux/leg-kernel_git.bb | 26 -
.../linux/linux-yocto-efi-test/qemuarm64/defconfig | 2735 +++++++++++++++++
.../linux/linux-yocto-efi-test_4.1.bb | 9 +-
meta/conf/machine/genericarmv8.conf | 16 -
meta/conf/machine/genericarmv8b.conf | 6 -
7 files changed, 2748 insertions(+), 3165 deletions(-)
create mode 100644 meta-luv/conf/machine/qemuarm64.conf
delete mode 100644 meta-luv/recipes-kernel/linux/leg-kernel/defconfig
delete mode 100644 meta-luv/recipes-kernel/linux/leg-kernel_git.bb
create mode 100644 meta-luv/recipes-kernel/linux/linux-yocto-efi-test/qemuarm64/defconfig
delete mode 100644 meta/conf/machine/genericarmv8.conf
delete mode 100644 meta/conf/machine/genericarmv8b.conf
--
1.7.11.7
6 years, 2 months
luvOS yocto based project - "hvc0" respawning too fast
by Naresh Bhat
Hi Randy,
The luvOS project is based on luv-yocto frame work. I have built the
luvOS project for AArch64 architecture using qemuarm64.conf machine
configuration file and boot the luvOS image on QEMU machine (used
latest QEMU git repository image i.e. qemu-system-aarch64 QEMU
v2.4.50)
I am facing the following issue on the console "INIT: Id "hvc0"
respawning too fast: disabled for 5 minutes"
...
.....
[-] kernel-efi-warnings
[+] EFI_BOOT_SERVICES_*_illegal_access... passed
Ran 3 testsuites and 64 unittests, 53 passes, 15 fails, 3 skipped.
Linux UEFI Validation Distribution 2.0-dev qemuarm64 ttyAMA0
INIT: Id "hvc0" respawning too fast: disabled for 5 minutes
Linux UEFI Validation Distribution 2.0-dev qemuarm64 ttyAMA0
qemuarm64 login: root
root@qemuarm64:~#
root@qemuarm64:~#
Can you please let me know how did you tested this patch on QEMU and
what are the parameter's you have passed for command line ? Can you
please help me to overcome from the above issue ?
I am using following script to launch the QEMU -
https://wiki.linaro.org/LEG/Engineering/luvOS#How_to_test_luvOS_image_on_...
and I can see the below patch introduced the hvc0
[nareshbhat@Lenovo luv-yocto]$ git show f44e043c752470b1ed4d22f3732dc0b362f83fd9
commit f44e043c752470b1ed4d22f3732dc0b362f83fd9
Author: Randy Witt <randy.e.witt(a)linux.intel.com>
Date: Thu Aug 27 19:42:43 2015 -0700
qemuarm64.conf: Make the second serial console /dev/hvc0
Since the qemu for aarch64 must use a virtual console for the second
serial port rather than emulating actual hardware, make sure the correct
device is specified so that a tty is actually started.
(From OE-Core rev: 5b720a69f0d181ab2de6032a6e3f5a0ee4a14302)
Signed-off-by: Randy Witt <randy.e.witt(a)linux.intel.com>
Signed-off-by: Ross Burton <ross.burton(a)intel.com>
Signed-off-by: Richard Purdie <richard.purdie(a)linuxfoundation.org>
diff --git a/meta/conf/machine/qemuarm64.conf b/meta/conf/machine/qemuarm64.conf
index 7bbdad7..8459d0f 100644
--- a/meta/conf/machine/qemuarm64.conf
+++ b/meta/conf/machine/qemuarm64.conf
@@ -9,4 +9,4 @@ MACHINE_FEATURES = ""
KERNEL_IMAGETYPE = "Image"
-SERIAL_CONSOLES = "38400;ttyAMA0 38400;ttyAMA1"
+SERIAL_CONSOLES = "38400;ttyAMA0 38400;hvc0"
[nareshbhat@Lenovo luv-yocto]$
Thanks and Regards
-Naresh
6 years, 2 months
Results and a few questions
by Jason Barbier
Hey all,
I ran LUV-Live and my results are attached as a zip, I sort of was
wondering about the errors in the chipsec log though,
These were similar errors that I got last week that caused some issues
with my clock being reset using version 1.2, the latest RC seems to not
do that but It still can not seem to run all the tests.
--
WARNING: 'SPIBAR' MMIO BAR definition not found/correct in XML config
[pci] reading B/D/F: 0/31/0, offset: 0xF0, value: 0xFED1C001
[spi] SPI MMIO base: 0x00000000FED1F800 (assuming below 4GB)
[spi] SPI MMIO base: 0x00000000FED1F800 (assuming below 4GB)
[-] Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/chipsec_main.py", line 291, in
run_module
result = modx.run( module_argv )
File "/usr/lib/python2.7/site-packages/chipsec/module.py", line 69, in
run
result = self.get_module_object()
File "/usr/lib/python2.7/site-packages/chipsec/module.py", line 101,
in get_module_object
self.mod_obj = iref()
File
"/usr/lib/python2.7/site-packages/chipsec/modules/common/bios_wp.py",
line 51, in __init__
self.spi = SPI( self.cs )
File "/usr/lib/python2.7/site-packages/chipsec/hal/spi.py", line 176,
in __init__
self.hsfs_off = int(chipsec.chipset.get_register_def( self.cs,
"HSFS" )['offset'],16)
File "/usr/lib/python2.7/site-packages/chipsec/chipset.py", line 467,
in get_register_def
return _cs.Cfg.REGISTERS[ reg_name ]
KeyError: 'HSFS'
--
[-] Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/chipsec_main.py", line 291, in
run_module
result = modx.run( module_argv )
File "/usr/lib/python2.7/site-packages/chipsec/module.py", line 80, in
run
result = self.mod_obj.run(module_argv)
File
"/usr/lib/python2.7/site-packages/chipsec/modules/common/spi_desc.py",
line 68, in run
return self.check_flash_access_permissions()
File
"/usr/lib/python2.7/site-packages/chipsec/modules/common/spi_desc.py",
line 48, in check_flash_access_permissions
frap = chipsec.chipset.read_register( self.cs, 'FRAP' )
File "/usr/lib/python2.7/site-packages/chipsec/chipset.py", line 470,
in read_register
reg = _cs.Cfg.REGISTERS[ reg_name ]
KeyError: 'FRAP'
ERROR: Exception occurred during chipsec.modules.common.spi_desc.run():
''FRAP''
--
[-] Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/chipsec_main.py", line 291, in
run_module
result = modx.run( module_argv )
File "/usr/lib/python2.7/site-packages/chipsec/module.py", line 80, in
run
result = self.mod_obj.run(module_argv)
File
"/usr/lib/python2.7/site-packages/chipsec/modules/common/spi_lock.py",
line 59, in run
return self.check_spi_lock()
File
"/usr/lib/python2.7/site-packages/chipsec/modules/common/spi_lock.py",
line 46, in check_spi_lock
hsfs_reg = chipsec.chipset.read_register( self.cs, 'HSFS' )
File "/usr/lib/python2.7/site-packages/chipsec/chipset.py", line 470,
in read_register
reg = _cs.Cfg.REGISTERS[ reg_name ]
KeyError: 'HSFS'
ERROR: Exception occurred during chipsec.modules.common.spi_lock.run():
''HSFS''
--
--
Jason Barbier | E: kusuriya(a)corrupted.io
GPG Key-ID: B5F75B47 (http://kusuriya.devio.us/pubkey.asc)
6 years, 2 months
Re: [Luv] [chipsec] CHIPSEC error when building LUV image
by Neri, Ricardo
On Thu, 2015-10-22 at 10:13 -0700, Blibbet wrote:
> You might also want to ask on the LUV list about this build error. This
> might be a LUV-centric issue. The LUV team ported CHIPSEC to their
> system. The CHIPSEC team -- AFAIK -- has/have been using an alternative
> Linux live-boot solution until recently, so the LUV team may be better
> to answer a LUV-centric build question than the CHIPSEC team.
Actually, this the LUV team trying to build CHIPSEC for 32-bit. At a
first glance the errors seem to be related to converting pointers to
integers of different lengths; this is something that should be fairly
easy to fix.
>
> I wonder:
> Does a 32- and 64-bit LUV behave differently, w/r/t firmware tests, on
> different architectures?
It should have the same behavior.
> Does CHIPSEC behave differently on when built 32- or 64-bit -- on Linux
> or Windows or UEFI?
Good question!
> Perhaps we need LUV64-live and LUV32-live to solve??
We are in the process of providing support for 32-bit in LUV and we came
across this error.
Thanks and BR,
Ricardo
> Gettting more confused as I type, so I'll stop typing. :-)
>
> On 10/16/2015 01:00 PM, Blibbet wrote:
> > On 10/14/2015 10:08 AM, Dey, Megha wrote:
> >> I wanted to know if the CHIPSEC test suite builds and runs on 32 bit
> > platforms?
> >
> > I don't know the cause of your problems, but the CHIPSEC PDF says
> > Windows x86/x64, and says that on Linux, Debian is the only one
> > explicitly listed with 32-bit, Fedora and Ubuntu say 64-bit, LUV entry
> > does not specify.
> >
> > If possible to build LUV with LLVM clang, you might try that, it gives
> > much better warnings than GCC.
> >
> > I've only built CHIPSEC on Linux, and only for 64-bit targets. And I'm
> > afraid I can't help building a local LUV at the moment, sorry.
> >
> > Lee
> >
> >
>
> _______________________________________________
> chipsec mailing list
> chipsec(a)lists.01.org
> https://lists.01.org/mailman/listinfo/chipsec
6 years, 3 months
Re: [Luv] [PATCH v2] x86/mm: warn on W+x mappings
by Ricardo Neri
On Thu, 2015-10-15 at 12:33 +0200, Borislav Petkov wrote:
> Yeah, that's actually a good idea. Why not upstream it for the wider
> audience so that people can actually start reporting b0rked UEFIs?
> With
> a big and nice FW_BUG splat in there...
We attempted to upstream in the past but later I discovered that my
implementation in particular is causing warnings due to SMP. Also, I
need to implement an alternative or extension to the current
efi_map_region, which have the __init qualifier. This is because
mappings might happen after the __inits have been discarded. I have this
work currently in my scope.
Thanks and BR,
Ricardo
6 years, 3 months
Re: [Luv] [PATCH v2] x86/mm: warn on W+x mappings
by Matt Fleming
On Wed, 14 Oct, at 05:35:22PM, Borislav Petkov wrote:
> On Wed, Oct 14, 2015 at 08:30:48AM -0700, Andy Lutomirski wrote:
> > Can we just unmap these things until someone tries to do an EFI call,
> > and then unmap them again after the call returns? We already switch
> > pgds for EFI IIRC.
>
> hpa did mention an EFI-aware page fault handler at the time. I guess we
> could do that too...
We do this for the Linux UEFI Validation project kernel [1]. There, we
do not map EFI Boot Services regions by default, only if the firmware
tries to access them.
This gives us the opporunity to print an error message if Boot
Services regions are accessed after ExitBootServices() (which is the
bug mjg59 describes in commit 916f676f8dc0 ("x86, efi: Retain boot
service code until after switching to virtual mode")).
But for the issue being discussed in this thread, the thing unmapping
the EFI regions buys you is that they're no longer accessible from the
x86 sleep/wakeup code paths, since those also use trampoline_pgd which
is where the EFI page tables are mapped.
And that's probably a good idea.
[1] - https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit/?h=s...
--
Matt Fleming, Intel Open Source Technology Center
6 years, 3 months
[V2 PATCH 0/3] Build Linus' kernel in luvOS
by Naresh Bhat
The set of patch does the following
- Add support to build the kernel.org Linus' tree in linux-yocto-efi-test
recipe i.e. master branch with full ACPI support.
- Add defconfig file under qemuarm64.
- Add aarch64 machine compatibality, SRC_URI and SRCREV variables for qemuarm64.
- Remove leg-kernel recipe and defconfig file.
- Remove genericarmv8 machine configuration files. Which means now you have to
use MACHINE = "qemuarm64" while building luvOS for ARM64 architecture.
Updated wiki page and the luv-live-image.img boot logs on QEMU/FVP base model
https://wiki.linaro.org/LEG/Engineering/luvOS#Boot_log_of_luvOS_on_ARM64
Changes since V0->V1
- Re-arrange the patches in such way that first add support to build kernel.org
kernel and then remove the leg-kernel dependency as suggested by Graeme.
Changes since V1->V2
- Remove genericarmv8 machine configuration files.
Naresh Bhat (3):
linux-yocto-efi-test: Add support to AArch64
leg-kernel: Remove leg kernel recipe
genericarmv8: Remove genericarmv8 conf files
meta-luv/recipes-kernel/linux/leg-kernel/defconfig | 3116 --------------------
meta-luv/recipes-kernel/linux/leg-kernel_git.bb | 26 -
.../linux/linux-yocto-efi-test/qemuarm64/defconfig | 2735 +++++++++++++++++
.../linux/linux-yocto-efi-test_4.1.bb | 9 +-
meta/conf/machine/genericarmv8.conf | 16 -
meta/conf/machine/genericarmv8b.conf | 6 -
6 files changed, 2743 insertions(+), 3165 deletions(-)
delete mode 100644 meta-luv/recipes-kernel/linux/leg-kernel/defconfig
delete mode 100644 meta-luv/recipes-kernel/linux/leg-kernel_git.bb
create mode 100644 meta-luv/recipes-kernel/linux/linux-yocto-efi-test/qemuarm64/defconfig
delete mode 100644 meta/conf/machine/genericarmv8.conf
delete mode 100644 meta/conf/machine/genericarmv8b.conf
--
1.7.11.7
6 years, 3 months
