Re: Understanding EFI

I think I have grasped the intended meaning of machine independence. So what I have found out is that in the ARM world there is difference in architectures as well as what is physically present on the machine i.e. peripherels and board specific stuff. Because of this the kernel (and/or the bootloader) has to be modified for each device/machine and so this where FDT comes. The idea is that we move the variable information to the device tree and keep a generic kernel (and/or bootloader).

Am I correct? Can you have a look at (*1) to check if I am understanding the process correctly.

(*1): https://wiki.netbsd.org/projects/project/efi/

Port-arm folks this is the relevant part I wanted to ask to you guys:

I also had some questions regarding U-boot. (*2) looked similar to my project but after reading it I am a bit confused. The problem is that is Wikipedia says that U-boot is a bootloader but the milestones in my project say that we need to use U-boot's EFI services to run NetBSD's bootloader. I am assuming that the U-boot bootloader will be the first to boot and then it will boot our EFI bootloader as an EFI application.

(*2): https://www.suse.com/media/article/UEFI%20on%20Top%20of%20U-Boot.pdf

On Tue, Mar 27, 2018 at 2:39 AM, Saad Mahmood Mughal <saadmahmoodmughal%gmail.com@localhost> wrote:

Thank you for the detailed email. It is helping a lot. I do have some questions that I wanted to ask

1). Will OSdev and Vincent Zimmer's docs on github suffice for my project or the book Beyond Bios also be necessary?

2). My project is to make a machine independent bootloader. My understanding of machine independence is that their should be a unified bootloader for all architectures like armv7 and armv8. The OpenBSD efi bootloader implementation for armv7 works in Thumb mode while for aarch64 it runs A64. My question relating to this is whether my understanding is correct i.e. a single implementation for both armv7 and armv8? We can make a single implementation because armv8 can be run in 32bit mode and hence we might be able to use the same armv7 bootloader implementation for armv8.

P.S. Thanks for introducing me to Vincent's blog. He feels like a master on EFI.

On Mon, Mar 26, 2018 at 12:39 PM, Kimihiro Nonaka <nonakap%gmail.com@localhost> wrote:
Hi,

If you have something to ask, please email me.

NetBSD/x86 efiboot(*1) is based on OpenBSD/amd64 efiboot(*2).
OpenBSD have already armv7 efiboot(*3) and arm64 efiboot(*4).
I think that it is good to refer to these.

NetBSD/x86 efiboot use gnu-efi library(*5).
gnu-efi has been imported into NetBSD base source(*6),
but arm and aarch64 support are not available because version is a bit older.
So, you need to import new gnu-efi library.

NetBSD/x86 efiboot is also based on BIOS boot loader(*7).
Therefore, there is processing that uses the specification of BIOS as it is.
ex.) biosdisk, basemem, extmem, dev2bios, bios2dev, etc....
You probably need to change this BIOS dependent code.

(*1) https://github.com/NetBSD/src/tree/trunk/sys/arch/i386/stand/boot
(*2) https://github.com/openbsd/src/tree/master/sys/arch/amd64/stand/efiboot
(*3) https://github.com/openbsd/src/tree/master/sys/arch/armv7/stand/efiboot
(*4) https://github.com/openbsd/src/tree/master/sys/arch/arm64/stand/efiboot
(*5) https://sourceforge.net/projects/gnu-efi/
(*6) https://github.com/NetBSD/src/tree/trunk/sys/external/bsd/gnu-efi
(*7) https://github.com/NetBSD/src/tree/trunk/sys/arch/i386/stand/boot

netbsd-src/sys/arch/i386/stand/efiboot files.

- boot.c: non-EFI misc. routines.
XXX violate some functions.
- conf.c: misc. data for libsa open().
- devopen.c: handle disk/net device routines for libsa open().
- efiboot.c: EFI specific main() function and misc.
- eficons.c: EFI specific console
- efidelay.c: EFI specific delay
- efidev.c: EFI specific device utilities
- efidisk.c: EFI specific disk I/O
- efidisk_ll.c: EFI specific low level(ll) disk I/O
- efigetsecs.c: EFI specific getsecs for timeout
- efimemory.c: EFI specific memory related
- panic.c: provide Panic() for gnu-efi and _rtt() for efiboot
- self_reloc.c: relocate efiboot relocatable objects.
You may use gnu-efi's gnuefi/reloc_*.c.
- version: version information. vers.c is created by this file.
- boot*/start.S: architecture specific startup.
You may use gnu-efi's gnuefi/crt0-efi-*.S.
- boot*/startprog*.S: boot kernel.
- relocate the kernel text/data to actual load address.
- make a bootinfo and pass it to kernel.
- make a page table that kernel assumes and load it.
- jump kernel entry address.
- boot*/efiboot*.c: machine depend boot routines.
- efi_md_init(): Allocate memory near the top memory address
and copy startprog*.S:startprog*_start routine.
This is because efiboot itself may be destroyed when
relocate the kernel text/data to the actual load address
at startprog* routine.
- startprog(): Jump to copied startprog* routine.

FYI, following URLs are my initial efiboot commit log and diff.
http://mail-index.netbsd.org/source-changes/2017/01/24/msg081290.html
https://github.com/NetBSD/src/commit/35f90d0420b3a9c5bf09b9a8a865da114f3b688f?diff=unified

And I taught my acquaintance's UEFI guru resources that might be helpful.

- Web
* https://wiki.osdev.org/UEFI
* https://github.com/vincentjzimmer/Documents
* http://vzimmer.blogspot.jp/

- Code
* EDK2 EfiShell
https://github.com/tianocore/edk2/tree/master/ShellPkg/Application/Shell

- Book
* https://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1501514784

2018-03-26 7:54 GMT+09:00 Saad Mahmood Mughal <saadmahmoodmughal%gmail.com@localhost>:
> Hi!
>
> I am working on the ARM EFI bootloader as a GSoC project and have been a bit
> slow on understanding the EFI. I was recommended by a fellow NetBSD dev to
> go through i386 EFI bootloader implementation. I have to say its a very well
> written and easier to follow implementation but still my lack of awareness
> on EFI is a major hindrance to my project. I thought that I should ask you
> for pointers on EFI like some sort of reading material or general guidelines
> that can help me get better. I am also available for a skype session if you
> think it would be better.

Regards,
--
Kimihiro Nonaka

--
SAAD MAHMOOD
Bachelors of Electrical Engineering | Class of 2018
School of Electrical Engineering and Computer Sciences (SEECS)
National University of Sciences and Technology (NUST)
Sector H-12, Islamabad
Pakistan

SAAD MAHMOOD

Bachelors of Electrical Engineering | Class of 2018

School of Electrical Engineering and Computer Sciences (SEECS)

National University of Sciences and Technology (NUST)
Sector H-12, Islamabad
Pakistan