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

Thu Apr 5 13:00:46 EDT 2012

On Thu, Apr 5, 2012 at 22:11, Gerardo Exequiel Pozzi
<vmlinuz386 at yahoo.com.ar> wrote:
> On 04/05/2012 02:26 AM, Keshav P R wrote:
>>
>> 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
>
>
> 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