[arch-releng] [RFC] [PATCH] [configs/releng] Add UEFI boot support via linux >= 3.3 EFI boot stub on x86_64

[Keshav P R]

On Wed, Apr 4, 2012 at 23:50, Gerardo Exequiel Pozzi
<vmlinuz386 at yahoo.com.ar> 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
>>> <vmlinuz386 at yahoo.com.ar>  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<vmlinuz386 at yahoo.com.ar>
>>>> ---
>>>>  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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: archiso_efistub_loop_fs_mp.patch
Type: application/octet-stream
Size: 2267 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-releng/attachments/20120405/02240e91/attachment.obj>