[PATCH] v2[LUV]luv-live-image.bb:Switch from MSDOS MBR to GPT including FAT 32.
by AJ James
The change will align to UEFI specs of having an EFI system partion
formatted to FAT and having a GPT type so that the firmware can find it.
Furthermore allow utilization of 128 bit UUID and additional partitions and
a larger range of size. These changes are in reference to
https://github.com/01org/luv-yocto/issues/4
Additionally I switched from bytes to sectors for proper partition
sector alignment and moved the sectors and partition calculations
to variables allowing for easier changes in the future. Space was added
to account for the skipped sector at the beginning of the disk and
and a second skipped sector seperating the two partions for proper alignment
I also capitilized the volumes labels as bitbake reported Fat did
not work well with with lowercase names. Both the luv-results and
luv boot partitions will be FAT32.
Signed-off-by: AJ James <aaron.k.james(a)linux.intel.com>
Changes since v1:
1) Removed leading and trailing spaces
2) Added more detail to commit message explaing the need for GPT, Fat32
and extra space
3) Added more documentation on use of variables
4) Moved end statements to comply with 80 character line limit
5) Removed option to force Fat 32 format in bootimg class
6) Added option to copy bootimg to VFAT after forcing Fat 32 partion
7) Zeroed out beginning and ending partion tables
8) Removed extra space on Luv-Results folder
---
meta-luv/recipes-core/images/luv-live-image.bb | 60 +++++++++++++-------------
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/meta-luv/recipes-core/images/luv-live-image.bb b/meta-luv/recipes-core/images/luv-live-image.bb
index 86a3ab12ac2b..aad9f2f54ef1 100644
--- a/meta-luv/recipes-core/images/luv-live-image.bb
+++ b/meta-luv/recipes-core/images/luv-live-image.bb
@@ -6,7 +6,7 @@ DEPENDS_${PN} = "grub-efi bits"
HDDDIR = "${S}/hddimg"
HDDIMG_ID = "423CC2C8"
LABELS = "LUV"
-
+
INITRD_IMAGE = "core-image-efi-initramfs"
INITRD = "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE}-${MACHINE}.cpio.gz"
MACHINE_FEATURES += "efi"
@@ -35,56 +35,56 @@ build_img() {
VFAT_RESULTS_SPACE=16777216
VFAT_RESULTS_BLOCKS=$(expr $VFAT_RESULTS_SPACE / 1024)
# TODO: do we need to dynamically generate the UUID?
- # For now, every time this UUID changes, the file etc/init.d/luv-test-manager
- # needs to be updated accordingly.
+ # For now, every time this UUID changes,
+ # the file etc/init.d/luv-test-manager needs to be updated accordingly.
VFAT_RESULTS_UUID=05D61523
VFAT_RESULTS_LABEL="LUV-RESULTS"
- FATSIZE="-F32"
+ FATSIZE="-F32"
BLKSIZE=512
SECTOR=2048
- # Extra space to accommodate skipped sectors used for disk alignment
- EXTRA_SPACE=3145728
-
+ # Extra space to account for skipped sectors used for disk alignment
+ EXTRA_SPACE=3145728
+
if [ -e ${VFAT_RESULTS} ]; then
rm ${VFAT_RESULTS}
fi
-
- mkdosfs -v ${FATSIZE} -C ${VFAT_RESULTS} -S ${BLKSIZE} -i ${VFAT_RESULTS_UUID} \
- -n ${VFAT_RESULTS_LABEL} ${VFAT_RESULTS_BLOCKS}
- mkfs.vfat -v ${FATSIZE} -S ${BLKSIZE} -n ${LABELS} -i ${HDDIMG_ID} ${VFAT}
+ mkdosfs -v ${FATSIZE} -C ${VFAT_RESULTS} -S ${BLKSIZE} \
+ -i ${VFAT_RESULTS_UUID} -n ${VFAT_RESULTS_LABEL} ${VFAT_RESULTS_BLOCKS}
+
+ mkfs.vfat -v ${FATSIZE} -S ${BLKSIZE} -n ${LABELS} -i ${HDDIMG_ID} ${VFAT}
mcopy -i ${VFAT} -s ${HDDDIR}/* ::/
-
- dd if=/dev/zero of=$IMG bs=512 count=1
+ dd if=/dev/zero of=$IMG bs=512 count=1
+
VFAT_SIZE=$(du -L --apparent-size -bs $VFAT | cut -f 1)
VFAT_RESULTS_SIZE=$(du -L --apparent-size -bs $VFAT_RESULTS | cut -f 1)
-
- # Create the size of the Luv image
+
+ # Create the size of the Luv image
IMG_SIZE=$(expr $VFAT_SIZE + $VFAT_RESULTS_SIZE + $EXTRA_SPACE)
-
- # Convert the partition from bytes to sectors and set start/end for partitions
+
+ # Convert partitions from bytes to sectors and set start/end for partitions
END_P1=$(expr $(expr $VFAT_RESULTS_SIZE / $BLKSIZE) + $SECTOR)
START_P2=$(expr $END_P1 + $SECTOR)
- END_P2=$(expr $(expr $IMG_SIZE / $BLKSIZE ) - $SECTOR)
+ END_P2=$(expr $(expr $IMG_SIZE / $BLKSIZE ) - $SECTOR)
OFFSET=$(expr $START_P2)
+
+ dd if=/dev/zero of=$IMG bs=1 seek=$IMG_SIZE count=0
- dd if=/dev/zero of=$IMG bs=1 seek=$IMG_SIZE count=0
-
- parted -s $IMG mklabel gpt
-
- # First partition for luv-results folder
- parted $IMG unit s mkpart primary fat32 ${SECTOR} ${END_P1}
-
+ parted -s $IMG mklabel gpt
+
+ # First partition for luv-results folder
+ parted $IMG unit s mkpart primary fat32 ${SECTOR} ${END_P1}
+
# start second partition on the first sector after the first partition
parted $IMG unit s mkpart ESP fat32 ${START_P2} ${END_P2}
-
- parted $IMG set 2 boot on
- dd if=${VFAT_RESULTS} of=$IMG conv=notrunc seek=${SECTOR}b bs=1
-
+ parted $IMG set 2 boot on
+
+ dd if=${VFAT_RESULTS} of=$IMG conv=notrunc seek=${SECTOR}b bs=1
+
dd if=${VFAT} of=$IMG conv=notrunc seek=${OFFSET}b bs=1
-
+
}
python do_create_img() {
bb.build.exec_func('build_img', d)
--
1.9.1
5 years, 9 months
[PATCH 0/5] Luv: Add netconsole feature
by Gayatri Kammela
Hi,
This is about adding a Linux feature called Netconsole in Linux* UEFI Validation.
In LUV netconsole feature is enabled only for the test suites that run once
the Linux takes control over and BITS test suite will be excluded from
having this kind of support.
Why this feature:
Netconsole in LUV help us debug the kernel panics or system hangs by
sending not only kernel messages but also information regarding the running tests
simultaneously on to the remote machine via ethernet. Now the remote machine can
be on same subnet or different subnet with respective to the local machine
( machine you are trying to boot LUV).
To enable netconsole feature in LUV, changes are made in various files to include
kernel modules like netconsole and different network utilites that can send messages
via ethernet.Besides these changes are made to luv-test-manger to make all the
running tests information sent to dmesg to make the debugging more easy.
How this feature works:
Liberty is given to user to choose the ip address and port number where he/she wants
all messages to sent to. once decided , user can replace the dummy ip address given
in grub.cfg as @,64001@10.11.12.13/ with the destined address and port number.
The same information is mentioned in README file , so that user can get
to know the usage of netconsole.
Requirements for this feature:
Not many changes are required for this feature , except enabling some of the
kernel config options. Luv kernel has config optons enabled that are
obsolutely necessary for the image and to keep the kernel size as low as possible.
Since netconsole require lot of options enabled related to TCP/IP , IPV4 , IPV6 and
filesystem related options. These information can be overwhelming and just for the
sake of clarity some of the important options that needs to enabled are given below
1)CONFIG_NETCONSOLE=m
2)CONFIG_NETCONSOLE_DYNAMIC=y
3)CONFIG_IP_MULTICAST=y
4)CONFIG_NET_IPGRE_BROADCAST=y
5)CONFIG_NET_TEAM_MODE_BROADCAST=y
6)CONFIG_IPVLAN=y
7)CONFIG_NETDEVICES=y
8)CONFIG_ETHERNET=y
9)CONFIG_VT_CONSOLE=y
10)CONFIG_CONFIGFS_FS=y
The rest of the config options which are included in luv kernel will be taken care by Megha Dey
The goal of this feature is to help us debug the issues we face while booting different
platforms with LUV
Gayatri Kammela (5):
core-image-efi-initramfs.bb: Add network utilites to support
netconsole in LUV
luv-live-image.bb: Kernel parameters for netconsole support
luv: Add a new file 'luv-netconsole' to the initscripts
LUV: initscripts_1.0.bbappend : Create runlevel link for the
luv-netconsole
luv-test-manager : Redirect the test results to the dmesg buffer
.../images/core-image-efi-initramfs.bb | 4 +-
meta-luv/recipes-core/images/luv-live-image.bb | 2 +-
.../initscripts/initscripts/luv-netconsole | 53 ++++++++++++++++++++++
.../initscripts/initscripts/luv-test-manager | 13 +++---
.../initscripts/initscripts_1.0.bbappend | 8 +++-
5 files changed, 70 insertions(+), 10 deletions(-)
create mode 100644 meta-luv/recipes-core/initscripts/initscripts/luv-netconsole
--
1.9.1
5 years, 9 months
[PATCH 4/6] LUV: initscripts_1.0.bbappend : Create runlevel link for the luv-netconsole
by Gayatri Kammela
Modify the initscripts_1.0.bbappend to include the luv-netconsole
file and then create a runlevel link for it.
By creating runlevel link , luv-netconsole will show up as one of the
start up scripts and runs at all levels ( 2, 3, 4, 5). Running
luv-netconsole at all levels will help netconsole to capture messages
generated at all levels and sends them to a remote machine so that user
will not miss any important detail of it
Cc: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com>
Signed-off-by: Gayatri Kammela <gayatri.kammela(a)intel.com>
---
meta-luv/recipes-core/initscripts/initscripts_1.0.bbappend | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/meta-luv/recipes-core/initscripts/initscripts_1.0.bbappend b/meta-luv/recipes-core/initscripts/initscripts_1.0.bbappend
index 871fadb3e483..79f24926771b 100644
--- a/meta-luv/recipes-core/initscripts/initscripts_1.0.bbappend
+++ b/meta-luv/recipes-core/initscripts/initscripts_1.0.bbappend
@@ -1,7 +1,8 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://luv-test-manager file://luv-test-parser \
- file://luv-crash-handler"
+ file://luv-crash-handler \
+ file://luv-netconsole"
do_install_append() {
install -m 755 ${WORKDIR}/luv-test-manager ${D}${sysconfdir}/init.d/
@@ -19,4 +20,9 @@ do_install_append() {
# Create runlevel link for the crash handler
update-rc.d -r ${D} luv-crash-handler start 98 3 5 .
+
+ install -m 755 ${WORKDIR}/luv-netconsole ${D}${sysconfdir}/init.d/
+
+ # Create runlevel link for the luv-netconsole
+ update-rc.d -r ${D} luv-netconsole start 98 2 3 4 5 .
}
--
1.9.1
5 years, 9 months
[PATCH 6/6] meta-luv- README file: Add information on usage of netconsole in LUV
by Gayatri Kammela
Update the README file to let users aware of the usage of netconsole
feature in LUV.
Cc: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com>
Signed-off-by: Gayatri Kammela <gayatri.kammela(a)intel.com>
---
meta-luv/README | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/meta-luv/README b/meta-luv/README
index b640ee9cadfe..c5bae5eb2831 100644
--- a/meta-luv/README
+++ b/meta-luv/README
@@ -58,3 +58,21 @@ Then it is necessary to specify the luv distribution in local.conf.
e.g.:
DISTRO = "luv"
+
+
+Usage of Netconsole within LUV
+===============================
+
+In order to make use of the netconsole feature that is added in LUV
+user must aware of its usage. Assuming users know how to get ip address and
+port number (typically from 6000 ports are not assigned to specific tasks so
+they can be used) , instructions are given below to follow
+
+Choose the ip address and port number where you want all messages to sent to.
+once decided , you can replace the dummy ip address and port number given
+in grub.cfg as netconsole=@,64001@10.11.12.13/ with the port number and ipaddress
+respectively.
+
+The grub.cfg file is located in boot partition. The location is
+EFI/BOOT/grub.cfg. Edit the file to replace the numbers and notation should be
+preserved for identifying the difference between ipaddress and port number.
--
1.9.1
5 years, 9 months
[PATCH 5/6] luv-test-manager : Redirect the test results to the dmesg buffer
by Gayatri Kammela
Netconsole will only send kernel messages that are in dmesg buffer and
userspace messages are not redirected to the dmesg buffer as they can
be overwhelmingly large
In LUV it would be good to have userspace messages
(messages from running tests) included in dmesg buffer for the sake of
the debugging.
Modify luv-test-manager to redirect the test results to /dev/kmsg
which will inturn inject them back to dmesg buffer. Every test result
will be provided with a timestamp which makes the job of debugging
easy in case of a system hang or panic while booting luv.
Cc: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com>
Signed-off-by: Gayatri Kammela <gayatri.kammela(a)intel.com>
---
.../recipes-core/initscripts/initscripts/luv-test-manager | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/meta-luv/recipes-core/initscripts/initscripts/luv-test-manager b/meta-luv/recipes-core/initscripts/initscripts/luv-test-manager
index 15deca5feacd..efc340b618af 100644
--- a/meta-luv/recipes-core/initscripts/initscripts/luv-test-manager
+++ b/meta-luv/recipes-core/initscripts/initscripts/luv-test-manager
@@ -88,7 +88,7 @@ psplash_write "MSG Running tests..."
luv_version=$(cut -d\\ -f1 /etc/issue)
-cat <<EOF
+cat <<EOF | tee /dev/kmsg
Welcome to ${luv_version}
Running tests...
@@ -116,7 +116,7 @@ mkdir -p ${LUV_LOG_DIR}
psplash_write "PROGRESS 0"
# Begin the results files by stating the version of luv
-cat <<EOF | tee ${LUV_SAVE_RESULTS_DIR}/luv.results > /tmp/luv.results
+cat <<EOF | tee /dev/kmsg | tee ${LUV_SAVE_RESULTS_DIR}/luv.results > /tmp/luv.results
$luv_version
Date and time of the system :$tstamp
@@ -145,17 +145,18 @@ for r in $runner_list; do
$runner | tee ${LUV_LOG_DIR}/$r | tee ${LUV_SAVE_RAW_DIR}/$r | $parser | \
tee ${LUV_SAVE_PARSED_DIR}/$r | ${LUV_PARSER_DIR}/test-manager | \
- tee /dev/console | \
+ tee /dev/console | while read line ; do case $line in *+* ) \
+ echo ' ' $line ;; * ) echo $line ;; esac done | tee /dev/kmsg | \
tee -a /tmp/luv.results | tee -a ${LUV_SAVE_RESULTS_DIR}/luv.results
sync
-done | awk '/ \[\+/ { units += 1 }
- / \[\-/ { suites += 1 }
+done | awk '/+/ { units += 1 }
+ /-/ { suites += 1 }
/pass/ { passes += 1 }
/fail/ { fails += $3 }
/skip/ { skips += 1 }
END {
printf("\nRan %d testsuites and %d unittests, %d passes, %d fails, %d skipped.\n", suites, units, passes, fails, skips)
- }' | tee -a /tmp/luv.results | tee -a ${LUV_SAVE_RESULTS_DIR}/luv.results
+ }' | tee /dev/kmsg | tee -a /tmp/luv.results | tee -a ${LUV_SAVE_RESULTS_DIR}/luv.results
file=${LUV_SAVE_RESULTS_DIR}/luv.results
html=$(echo $file | sed 's/\.results$/\.html/i')
--
1.9.1
5 years, 9 months
[PATCH 3/6] luv: Add a new file 'luv-netconsole' to the initscripts
by Gayatri Kammela
Netconsole is a linux feature that sends the kernel messages
to a remote machine via ethernet. The kernel messages sent over
to remote machine are useful for debugging in case of a kernel
panic.
Netconsole support in luv help debug platforms that luv couldn't
boot. It sends all the information to the remote machine that is
in the ring buffer which includes all kernel messages and luv.results
too. In this way , user can figure out what is causing the hang with
the help of the last message sent along with the timestamp provided
on the remote side
luv-netconsole is capable of sending kernel messages to the remote
machine which belongs to the same subnet and machines that are
not on the same subnet as local machine.
luv-netconsole script is made run at all levels to capture each detail
of the system's boot and continuously sends messages until interrupted
by the user at remote side
luv-netconsole takes the ip address and port number given by the user and
send the kernel messages to the destined ip address provided that remote
machine listens to local machine with the port number given by user
Cc: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com>
Signed-off-by: Gayatri Kammela <gayatri.kammela(a)intel.com>
---
.../initscripts/initscripts/luv-netconsole | 53 ++++++++++++++++++++++
1 file changed, 53 insertions(+)
create mode 100644 meta-luv/recipes-core/initscripts/initscripts/luv-netconsole
diff --git a/meta-luv/recipes-core/initscripts/initscripts/luv-netconsole b/meta-luv/recipes-core/initscripts/initscripts/luv-netconsole
new file mode 100644
index 000000000000..5bc2a5db0f14
--- /dev/null
+++ b/meta-luv/recipes-core/initscripts/initscripts/luv-netconsole
@@ -0,0 +1,53 @@
+#! /bin/sh
+
+###
+#Netconsole script
+##
+#Get the port number given by the user
+#from the kernel command line using grep
+
+NETCONSOLE_PORT=$(cat /proc/cmdline | grep -Eo "[0.0-9.0]+" | tail -2 | head -1)
+
+#Get the ipaddress provided by the user
+#from the kernel command line using grep
+
+REC_IP=$(cat /proc/cmdline | grep -Eo "[0.0-9.0]+" | tail -1)
+
+#Refresh the arp buffer
+
+$(cat /proc/net/arp > /dev/null)
+
+#If reciever is in the same subnet then
+#Get the reciever HW MAC Address
+#using the reciever's ip address
+
+$(ping -rc 1 $REC_IP > /dev/null)
+if [ $? -eq 0 ] ; then
+ REC_MAC_EX=$(arp -n $REC_IP | awk '{ print $3 }')
+ REC_MAC=$(echo $REC_MAC_EX | awk '{ print $2 }')
+else
+
+#determine the default gateway and then
+#Get the reciever HW MAC Address
+#using the reciever's ip address
+
+ DEF_GATE=$(netstat -rn | grep ^0.0.0.0 | awk '{print $2}')
+ $(ping -c 1 $DEF_GATE > /dev/null)
+ REC_MAC_EX=$(arp -n $DEF_GATE | awk '{ print $3 }')
+ REC_MAC=$(echo $REC_MAC_EX | awk '{ print $2 }')
+fi
+
+# Get local IP and Interface
+
+SEND_IF=$(ip -o -4 r s to default | grep ^default | awk '{print $5}')
+SEND_IP=$(ifconfig | grep eth -A1 | grep inet | awk -F: '{print $2}' | awk '{print $1}')
+
+#Disable helper by default
+
+echo 0 > /proc/sys/net/netfilter/nf_conntrack_helper
+
+# Install netconsole
+
+modprobe -r netconsole
+modprobe netconsole netconsole=$NETCONSOLE_PORT@$SEND_IP/$SEND_IF,$NETCONSOLE_PORT@$REC_IP/$REC_MAC
+
--
1.9.1
5 years, 9 months
[PATCH 2/6] luv-live-image.bb: Kernel parameters for netconsole support
by Gayatri Kammela
Modify luv-live-image.bb to pass all the required kernel
parameters via APPEND line that support netconsole feature
in LUV
Parameters include declaring system console and the size of
the ring buffer to accommodate more messages that might
be useful to debug in case of a kernel panic while you run LUV
Other parameters include changing ip address settings so
that it sets to dhcp and an option that helps user to provide
remote ip address and port of user's choice
Cc: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com>
Signed-off-by: Gayatri Kammela <gayatri.kammela(a)intel.com>
---
meta-luv/recipes-core/images/luv-live-image.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-luv/recipes-core/images/luv-live-image.bb b/meta-luv/recipes-core/images/luv-live-image.bb
index 722926275f96..69fdc869847a 100644
--- a/meta-luv/recipes-core/images/luv-live-image.bb
+++ b/meta-luv/recipes-core/images/luv-live-image.bb
@@ -10,7 +10,7 @@ LABELS = "luv"
INITRD_IMAGE = "core-image-efi-initramfs"
INITRD = "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE}-${MACHINE}.cpio.gz"
MACHINE_FEATURES += "efi"
-APPEND = "crashkernel=256M console=ttyS0,115200 console=ttyPCH0,115200"
+APPEND = "debug crashkernel=256M console=ttyS0,115200 console=ttyPCH0,115200 console=tty0,115200 ip=dhcp log_buf_len=1M netconsole=@,64001@10.11.12.13/"
APPEND_aarch64 = "crashkernel=256M console=ttyAMA0 uefi_debug acpi=force"
SPLASH_IMAGE = "blue-luv.jpg"
--
1.9.1
5 years, 9 months
[PATCH 1/6] core-image-efi-initramfs.bb: Add network utilites to support netconsole in LUV
by Gayatri Kammela
Modify core-image-efi-initramfs.bb to include ntework utilites
like iproute2 and iputils to provide netconsole support
Also include kernel-modules utility to support loadable kernel
modules in LUV (for example netconsole module here)
Cc: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com>
Signed-off-by: Gayatri Kammela <gayatri.kammela(a)intel.com>
---
meta-luv/recipes-core/images/core-image-efi-initramfs.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta-luv/recipes-core/images/core-image-efi-initramfs.bb b/meta-luv/recipes-core/images/core-image-efi-initramfs.bb
index 4e8ca3ff3a84..fdb9add6e36c 100644
--- a/meta-luv/recipes-core/images/core-image-efi-initramfs.bb
+++ b/meta-luv/recipes-core/images/core-image-efi-initramfs.bb
@@ -4,8 +4,8 @@ EFI tests."
IMAGE_INSTALL = "\
base-files base-passwd netbase udev sysvinit initscripts keymaps \
- kernel-image fwts bash coreutils gawk grep util-linux-agetty \
- util-linux-mount util-linux-umount kmod sed tar net-tools \
+ kernel-image kernel-modules fwts bash coreutils gawk grep util-linux-agetty \
+ util-linux-mount iputils iproute2 util-linux-umount kmod sed tar net-tools \
shadow util-linux procps efivarfs-test \
psplash kernel-efi-warnings \
"
--
1.9.1
5 years, 9 months
Re: [Luv] How to decide which test to run under Windows enviroment
by Neri, Ricardo
Hi Lucy,
On Tue, 2015-12-22 at 16:44 -0800, Lucy(Dong) Yan wrote:
> Hi Ricardo,
>
> Thanks for your help! Your solution works pretty well. Just one follow
> up question, how to quit when I'm done. If I turn off the server without
> quitting LUV, the test result won't be in the USB stick.
I am glad this worked. You can save the results by doing the following
from the LUV prompt:
$mkdir /tmp/x
$mount /dev/disk/by-uuid/05D6-1523 /tmp/x
$fwts uefirtvariable > /tmp/x/results.txt 2>&1
$umount /tmp/x
This will save the results in the USB stick you use to boot LUV. You
should be able to inspect the results from your Windows machine.
Unfortunately, at the moment we don't support the execution of tests at
the unit-test granularity. We could potentially plan on implementing
this feature. What are your thoughts?
Thanks and BR,
Ricardo
>
> Thanks,
>
> Lucy
>
> On 12/18/2015 6:58 PM, Neri, Ricardo wrote:
> > Hi Lucy,
> >
> > Thanks for your e-mail.
> >
> > On Fri, 2015-12-18 at 11:19 -0800, Dong Yan wrote:
> >> Hi there,
> >>
> >> I got a question for running the LUV test. I was trying to run
> >> specific test on our server. This is the link for our server
> >> https://www.oracle.com/servers/x86/x5-4/index.html
> >>
> >> I used to follow the instructions on
> >> https://01.org/zh/linux-uefi-validation/documentation/flashing-your-usb-s... for windows users. It worked but just run the whole package. And I actually didn't see GUN GRUB page showing up when I did it. Do you know if there's other ways to decide which test to run under such condition? Say I just want to run fwts/uefirtvar.
> > Actually, we reverted the menu is described in the video as the user
> > experience was not optimal. That menu allowed to select the tests suites
> > you wanted but not the particular test cases in a particular test suite.
> > For this purpose, there are several things that you can do. Here are
> > some steps:
> >
> > 1) once you are done creating your USB stick you can use a Linux system
> > to modify your stick. In the mount partition you can modify the file
> > EFI/BOOT/grub.cfg and change the line "default=bits" to "default=luv"
> >
> > at the end of the linux line you can add "noluv" so that it looks like
> > this:
> > linux /vmlinuz ${SYSLINUX_ROOT} crashkernel=256M console=ttyS0,115200
> > console=ttyPCH0,115200 noluv
> >
> > If you are using a console, once you are prompted for a login, you enter
> > root with no password. Once in the command line you can just do
> >
> > fwts uefirtvariable.
> >
> > I know this sounds convoluted. If you need help I could help you. Also,
> > if you are interested in a custom image for you we could look into that
> > as well.
> >
> > Thanks and BR,
> > Ricardo
> >
> >>
> >>
> >>
> >> Thank you very much!
> >>
> >>
> >> Lucy Yan
> >>
> >> _______________________________________________
> >> Luv mailing list
> >> Luv(a)lists.01.org
> >> https://lists.01.org/mailman/listinfo/luv
>
5 years, 9 months
[PATCH] linux-yocto-efi-test: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down
by Ricardo Neri
Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced
that signals that the firmware PE/COFF loader supports splitting
code and data sections of PE/COFF images into separate EFI
memory map entries.
Unfortunately, this implies that memory regions need to be mapped
with with same address offset as in the EFI memory map. Otherwise,
boot crashes will occur.
This is to backport a patch pushed by Matt Fleming to Linux v4.3.
Reported-by: Sai Praneeth Prakhya <sai.praneeth.prakhya(a)intel.com>
Cc: Matt Fleming <matt(a)codeblueprint.co.uk>
Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com>
---
...-boot-crash-by-mapping-EFI-memmap-entries.patch | 174 +++++++++++++++++++++
.../linux/linux-yocto-efi-test_4.1.bb | 1 +
2 files changed, 175 insertions(+)
create mode 100644 meta-luv/recipes-kernel/linux/linux-yocto-efi-test/x86-efi-Fix-boot-crash-by-mapping-EFI-memmap-entries.patch
diff --git a/meta-luv/recipes-kernel/linux/linux-yocto-efi-test/x86-efi-Fix-boot-crash-by-mapping-EFI-memmap-entries.patch b/meta-luv/recipes-kernel/linux/linux-yocto-efi-test/x86-efi-Fix-boot-crash-by-mapping-EFI-memmap-entries.patch
new file mode 100644
index 0000000..5bd0677
--- /dev/null
+++ b/meta-luv/recipes-kernel/linux/linux-yocto-efi-test/x86-efi-Fix-boot-crash-by-mapping-EFI-memmap-entries.patch
@@ -0,0 +1,174 @@
+From a5caa209ba9c29c6421292e7879d2387a2ef39c9 Mon Sep 17 00:00:00 2001
+From: Matt Fleming <matt.fleming(a)intel.com>
+Date: Fri, 25 Sep 2015 23:02:18 +0100
+Subject: [PATCH] x86/efi: Fix boot crash by mapping EFI memmap entries
+ bottom-up at runtime, instead of top-down
+
+Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced
+that signals that the firmware PE/COFF loader supports splitting
+code and data sections of PE/COFF images into separate EFI
+memory map entries. This allows the kernel to map those regions
+with strict memory protections, e.g. EFI_MEMORY_RO for code,
+EFI_MEMORY_XP for data, etc.
+
+Unfortunately, an unwritten requirement of this new feature is
+that the regions need to be mapped with the same offsets
+relative to each other as observed in the EFI memory map. If
+this is not done crashes like this may occur,
+
+ BUG: unable to handle kernel paging request at fffffffefe6086dd
+ IP: [<fffffffefe6086dd>] 0xfffffffefe6086dd
+ Call Trace:
+ [<ffffffff8104c90e>] efi_call+0x7e/0x100
+ [<ffffffff81602091>] ? virt_efi_set_variable+0x61/0x90
+ [<ffffffff8104c583>] efi_delete_dummy_variable+0x63/0x70
+ [<ffffffff81f4e4aa>] efi_enter_virtual_mode+0x383/0x392
+ [<ffffffff81f37e1b>] start_kernel+0x38a/0x417
+ [<ffffffff81f37495>] x86_64_start_reservations+0x2a/0x2c
+ [<ffffffff81f37582>] x86_64_start_kernel+0xeb/0xef
+
+Here 0xfffffffefe6086dd refers to an address the firmware
+expects to be mapped but which the OS never claimed was mapped.
+The issue is that included in these regions are relative
+addresses to other regions which were emitted by the firmware
+toolchain before the "splitting" of sections occurred at
+runtime.
+
+Needless to say, we don't satisfy this unwritten requirement on
+x86_64 and instead map the EFI memory map entries in reverse
+order. The above crash is almost certainly triggerable with any
+kernel newer than v3.13 because that's when we rewrote the EFI
+runtime region mapping code, in commit d2f7cbe7b26a ("x86/efi:
+Runtime services virtual mapping"). For kernel versions before
+v3.13 things may work by pure luck depending on the
+fragmentation of the kernel virtual address space at the time we
+map the EFI regions.
+
+Instead of mapping the EFI memory map entries in reverse order,
+where entry N has a higher virtual address than entry N+1, map
+them in the same order as they appear in the EFI memory map to
+preserve this relative offset between regions.
+
+This patch has been kept as small as possible with the intention
+that it should be applied aggressively to stable and
+distribution kernels. It is very much a bugfix rather than
+support for a new feature, since when EFI_PROPERTIES_TABLE is
+enabled we must map things as outlined above to even boot - we
+have no way of asking the firmware not to split the code/data
+regions.
+
+In fact, this patch doesn't even make use of the more strict
+memory protections available in UEFI v2.5. That will come later.
+
+Suggested-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
+Reported-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
+Signed-off-by: Matt Fleming <matt.fleming(a)intel.com>
+Cc: <stable(a)vger.kernel.org>
+Cc: Borislav Petkov <bp(a)suse.de>
+Cc: Chun-Yi <jlee(a)suse.com>
+Cc: Dave Young <dyoung(a)redhat.com>
+Cc: H. Peter Anvin <hpa(a)zytor.com>
+Cc: James Bottomley <JBottomley(a)Odin.com>
+Cc: Lee, Chun-Yi <jlee(a)suse.com>
+Cc: Leif Lindholm <leif.lindholm(a)linaro.org>
+Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
+Cc: Matthew Garrett <mjg59(a)srcf.ucam.org>
+Cc: Mike Galbraith <efault(a)gmx.de>
+Cc: Peter Jones <pjones(a)redhat.com>
+Cc: Peter Zijlstra <peterz(a)infradead.org>
+Cc: Thomas Gleixner <tglx(a)linutronix.de>
+Cc: linux-kernel(a)vger.kernel.org
+Link: http://lkml.kernel.org/r/1443218539-7610-2-git-send-email-matt@codebluepr...
+Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
+---
+ arch/x86/platform/efi/efi.c | 67 ++++++++++++++++++++++++++++++++++++++++++++-
+ 1 file changed, 66 insertions(+), 1 deletion(-)
+
+diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
+index 1db84c0..6a28ded 100644
+--- a/arch/x86/platform/efi/efi.c
++++ b/arch/x86/platform/efi/efi.c
+@@ -705,6 +705,70 @@ out:
+ }
+
+ /*
++ * Iterate the EFI memory map in reverse order because the regions
++ * will be mapped top-down. The end result is the same as if we had
++ * mapped things forward, but doesn't require us to change the
++ * existing implementation of efi_map_region().
++ */
++static inline void *efi_map_next_entry_reverse(void *entry)
++{
++ /* Initial call */
++ if (!entry)
++ return memmap.map_end - memmap.desc_size;
++
++ entry -= memmap.desc_size;
++ if (entry < memmap.map)
++ return NULL;
++
++ return entry;
++}
++
++/*
++ * efi_map_next_entry - Return the next EFI memory map descriptor
++ * @entry: Previous EFI memory map descriptor
++ *
++ * This is a helper function to iterate over the EFI memory map, which
++ * we do in different orders depending on the current configuration.
++ *
++ * To begin traversing the memory map @entry must be %NULL.
++ *
++ * Returns %NULL when we reach the end of the memory map.
++ */
++static void *efi_map_next_entry(void *entry)
++{
++ if (!efi_enabled(EFI_OLD_MEMMAP) && efi_enabled(EFI_64BIT)) {
++ /*
++ * Starting in UEFI v2.5 the EFI_PROPERTIES_TABLE
++ * config table feature requires us to map all entries
++ * in the same order as they appear in the EFI memory
++ * map. That is to say, entry N must have a lower
++ * virtual address than entry N+1. This is because the
++ * firmware toolchain leaves relative references in
++ * the code/data sections, which are split and become
++ * separate EFI memory regions. Mapping things
++ * out-of-order leads to the firmware accessing
++ * unmapped addresses.
++ *
++ * Since we need to map things this way whether or not
++ * the kernel actually makes use of
++ * EFI_PROPERTIES_TABLE, let's just switch to this
++ * scheme by default for 64-bit.
++ */
++ return efi_map_next_entry_reverse(entry);
++ }
++
++ /* Initial call */
++ if (!entry)
++ return memmap.map;
++
++ entry += memmap.desc_size;
++ if (entry >= memmap.map_end)
++ return NULL;
++
++ return entry;
++}
++
++/*
+ * Map the efi memory ranges of the runtime services and update new_mmap with
+ * virtual addresses.
+ */
+@@ -714,7 +778,8 @@ static void * __init efi_map_regions(int *count, int *pg_shift)
+ unsigned long left = 0;
+ efi_memory_desc_t *md;
+
+- for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
++ p = NULL;
++ while ((p = efi_map_next_entry(p))) {
+ md = p;
+ if (!(md->attribute & EFI_MEMORY_RUNTIME)) {
+ #ifdef CONFIG_X86_64
+--
+1.9.1
+
diff --git a/meta-luv/recipes-kernel/linux/linux-yocto-efi-test_4.1.bb b/meta-luv/recipes-kernel/linux/linux-yocto-efi-test_4.1.bb
index 36e53ec..52203a6 100644
--- a/meta-luv/recipes-kernel/linux/linux-yocto-efi-test_4.1.bb
+++ b/meta-luv/recipes-kernel/linux/linux-yocto-efi-test_4.1.bb
@@ -59,6 +59,7 @@ require recipes-kernel/linux/linux-yocto.inc
# tree if you do not want to build from Linus' tree.
SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git;protocol=g..."
SRC_URI += "file://defconfig"
+SRC_URI += "file://x86-efi-Fix-boot-crash-by-mapping-EFI-memmap-entries.patch"
# While building for AArch64 architecture fetch latest Linus' tree
# and apply default config, which includes ACPI options enabled.
--
1.9.1
5 years, 9 months