On 04/05/2012 02:26 AM, Keshav P R wrote:
On Wed, Apr 4, 2012 at 23:50, Gerardo Exequiel Pozzi
<[email protected]> wrote:
On 04/04/2012 12:21 PM, Gerardo Exequiel Pozzi wrote:
On 04/04/2012 10:48 AM, Keshav P R wrote:
On Mon, Apr 2, 2012 at 05:07, Gerardo Exequiel Pozzi
<[email protected]> wrote:
This only works via EFI shell because we need to pass boot params to
kernel.
An aditional EFI shell is provided with an startup script for automatic
booting.
Signed-off-by: Gerardo Exequiel Pozzi<[email protected]>
---
README | 3 +++
configs/releng/build.sh | 24 ++++++++++++++++++++++++
2 files changed, 27 insertions(+)
diff --git a/README b/README
index 57c87e3..711e51d 100644
--- a/README
+++ b/README
@@ -153,6 +153,9 @@ if nothing is specified on command line.
+ squashfs-tools for mksquashfs
+ libisoburn for xorriso
+** For configs/releng build.sh needs theses packages (build host):
+ + dosfstools for mkfs.vfat
+
** For these hooks needs these packages (on target root-image)
* archiso
+ (none)
diff --git a/configs/releng/build.sh b/configs/releng/build.sh
index 2faf210..c041953 100755
--- a/configs/releng/build.sh
+++ b/configs/releng/build.sh
@@ -58,6 +58,29 @@ make_boot() {
fi
}
+# Prepare EFI "El Torito" boot image (using Linux>= 3.3 EFI boot stub)
+make_boot_efi() {
+ if [[ ! -e ${work_dir}/build.${FUNCNAME} ]]; then
+ if [[ ${arch} == "x86_64" ]]; then
+ mkdir -p ${work_dir}/iso/EFI/archiso
+ dd of=${work_dir}/iso/EFI/archiso/efiboot.img bs=1 seek=20M
count=0
+ mkfs.vfat ${work_dir}/iso/EFI/archiso/efiboot.img
+ mkdir -p ${work_dir}/efiboot
+ mount ${work_dir}/iso/EFI/archiso/efiboot.img
${work_dir}/efiboot
+ mkdir -p ${work_dir}/efiboot/EFI/archiso
+ cp ${work_dir}/iso/${install_dir}/boot/x86_64/vmlinuz
${work_dir}/efiboot/EFI/archiso/vmlinuz.efi
+ cp ${work_dir}/iso/${install_dir}/boot/x86_64/archiso.img
${work_dir}/efiboot/EFI/archiso/archiso.img
+ # Always provide an EFI shell for systems without it (most
real hardware for home-end-users?).
+ mkdir -p ${work_dir}/efiboot/EFI/boot
+ wget -O ${work_dir}/efiboot/EFI/boot/bootx64.efi
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi
You need to use
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi
as ShellBinPkg shell will work only in 2.2+ systems (most of the Arch
Lenovo UEFI users reported ShellBinPkg Shell.efi as not working. More
info at http://sourceforge.net/mailarchive/message.php?msg_id=28690732
.
Technically needs 2.3+.
I thinking to EdkShellBinPkg that is based on (pre)UEFI 2.0. Looks like
there are lots of of poor/old UEFI implementation even in newer hardware so
can be more safe to provide and old shell.
This is temporary until EFI_STUB understand "linux.conf" (maybe in
Linux-3.5, since 3.4 merge window is closed without it).
Anyway I think that providing a shell with script, is much more flexible,
since you can skip it then execute vmlinuz.efi with custom boot params if
needed.
+ # Added an EFI shell script for automatic boot if ESC-key
is not pressed.
+ echo "\EFI\archiso\vmlinuz.efi
initrd=\EFI\archiso\archiso.img archisolabel=${iso_label}">
${work_dir}/efiboot/EFI/boot/startup.nsh
Are you sure this will work without cd'ing into fso: first? Did you
test this in real hardware like ENV (like DUET
http://www.rodsbooks.com/bios2uefi/index.html)
Yes, indeed I use DUET even for qemu since with OVMF has video issues
(there is no video output from Linux).
Think that when boot/bootx64.efi is executed you are currently on fs0: ;)
Maybe a poor UEFI implementation fails, who know?, anyway you are dropped to
the shell, and if shell fails, this is very very bad, we can not support
broken hardware addding exceptions.
When using older shell, is needed to change first to fs0:. I Added it to
startup.nsh
There is no guarantee that the files will always be in fs0: , same
like no guarantee that root partition will always be /dev/sdb3 . New
patch (archiso_efistub_loop_fs_mp.patch attached) that should work.
Apply against your efi_stub head.
Regards.
Keshav
Thanks you, I will merge with a minor syntax modification 0 1 2 3 4 5 6
7 8 9 can be (0 9) ;) but first some discussion:
Again, something is wrong with the older shell (1.0)?, because all
drives appears in %path% so \path\to\an\executable should work from any
place, like in new shell (2.0).
2.0 Shell> set path
path =
.\;FS0:\efi\tools\;FS0:\efi\boot\;FS0:\;FS1:\efi\tools\;FS1:\efi\boot\;FS1:\
Shell> set path
* path :
.;hd12a1:\efi\tools;hd12a1:\efi\boot;hd12a1:\;cd12c1:\efi\tools;cd12c1:\efi\boot;cd12c1:\
The only difference is that while shell 2.0 use fs# style in path, shell
1.0 uses consistent mapping name.
So if "fs0" is not always the boot media,I am thinking that, if there
are other \EFI\archiso\vmlinuz.efi in other drives, there is no guarante
that you are executing what your want. For example CD-ROM (boot from it)
is mapped to fs1, but you have another drive (an hdd) mapped as fs0 with
the same executable (this also applies to shell 2.0 too). Of course this
can be considered an "extreme case".
The question what are the rules of consistent mapping name, "cd" is
cd-rom/dvd-rom, but 12c1? Looking at source code does not appears show
something quickly (Shell/Library/ConsistMapping.c). But maybe we can use it.
--
Gerardo Exequiel Pozzi
\cos^2\alpha + \sin^2\alpha = 1
