On 04/04/2012 10:48 AM, Keshav P R wrote:

On Mon, Apr 2, 2012 at 05:07, Gerardo Exequiel Pozzi 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 --- 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/UefiShe... You need to use https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/Full... 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.

Thanks for your work on UEFI things, and thanks for the feedback.

...

+ umount ${work_dir}/efiboot + fi + :> ${work_dir}/build.${FUNCNAME} + fi +} + # Prepare /${install_dir}/boot/syslinux make_syslinux() { if [[ ! -e ${work_dir}/build.${FUNCNAME} ]]; then @@ -259,6 +282,7 @@ make_common_single() { make_packages make_setup_mkinitcpio make_boot + make_boot_efi make_syslinux make_isolinux make_customize_root_image -- 1.7.9.5

-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1

On Wed, Apr 4, 2012 at 23:50, Gerardo Exequiel Pozzi 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  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 ---  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/UefiShe...

You need to use

https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/Full... 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

On Thu, Apr 5, 2012 at 22:11, Gerardo Exequiel Pozzi wrote:

On 04/05/2012 02:26 AM, Keshav P R wrote:

...

On Wed, Apr 4, 2012 at 23:50, Gerardo Exequiel Pozzi  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    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 ---  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/UefiShe...

You need to use

https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/Full... 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.

I think not all mappings will have \EFI\archiso\vmlinuz.efi . So this loop is fine. This could be solved if the shell supports searching via Volume Label (shell "vol" command). But this is definitely something that we should ask Tianocore devs (edk2-devel ML in sourceforge.net). Regards. Keshav