[arch-releng] [RFC] [PATCH] [configs/releng] Add UEFI boot support via linux >= 3.3 EFI boot stub on x86_64
Gerardo Exequiel Pozzi
vmlinuz386 at yahoo.com.ar
Thu Apr 5 12:41:26 EDT 2012
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.
--
Gerardo Exequiel Pozzi
\cos^2\alpha + \sin^2\alpha = 1
More information about the arch-releng
mailing list