# loader and makefs documentation



## escape (Oct 25, 2019)

Does anyone know good material to read about the 'loader', especially loader.efi and 'makefs' ?

The EFI is now recommended across platforms. The URL: https://www.freebsdfoundation.org/freebsd-uefi-secure-boot/  introduces to a concept of a loader root filesystem. A complete kernel is put inside the 'loader.efi' with these tools. It would be good to know how it does that. 

For example
`/usr/src/sys/tools/embed_mfs.sh ./loader.efi ./bootfs.img
Can't locate mfs section within  ./loader.efi` .
Does the kernel in the filesystem have to have MD_ROOTSIZE in it? Where is this bootfs image going in the 'loader.efi' file? An introduction to solid-state installation with the memory root filesystem was in URL: https://www.freebsd.org/doc/en/articles/solid-state . Manual pages exist but these are merely a command line reference.

best

e


----------



## SirDice (Oct 25, 2019)

Start with uefi(8).


----------



## escape (Oct 25, 2019)

I'm able to boot the device to loader.efi and the actual problem was to find a correct root device. Next test will show if loader.conf
`vfs.root.mountfrom="ufs:/dev/ada0s2a"` solves the next step. Still the instructions add the existence of the `/etc/fstab` used by the 'loader.efi' loaded by the documented commands in `/usr/src/stand`. The 'stand' is outside of the kernel directory and was not easy to find. '/usr/src/stand' documentation would be good to know as well. UEFI is old news.


----------



## k.jacker (Oct 25, 2019)

I'd first drop MBR and/or BSD labels and use GPT partitioning scheme.

I'v never looked into what you are trying to do, but when I wanted to learn about how UEFI should work, the only real source is https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
I could also imagine that you'll still find recent hardware, where UEFI booting may not work as intended, by the UEFI specification.


----------



## escape (Oct 25, 2019)

There is a filesystem inside the loader.efi containing a kernel and a fstab file. This should be a 'root' where the filesystems '/', '/usr', '/var' (and so on) are mounted. Operating systems in general have a filesystem and if everything needed is the loader, it would be good to now some more about it. As much I've tested U-Boot, GPT has been supported. U-Boot adds some binary outside the filesystems if the board does not have external storage, some nvram for example for the purpose. What are the addresses, I don't at the moment know. To say that the EFI is now recommended, there are many ways to boot a device, one of them is the EFI and I'm trying this alternative. The recomendation came from the FreeBSD project. e


----------



## SirDice (Oct 28, 2019)

escape said:


> There is a filesystem inside the loader.efi containing a kernel and a fstab file.


This doesn't sound right. The loader.efi is just the EFI version of loader(8).

Note that FreeBSD boots differently compared to Linux. Linux boots from a memory disk that includes the kernel, FreeBSD loads the kernel directly (at stage 3).

It's somewhat old and doesn't cover GPT or EFI but the basic stages still work the same: Chapter 12. The FreeBSD Booting Process


----------



## escape (Nov 22, 2019)

SirDice said:


> This doesn't sound right. The loader.efi is just the EFI version of loader(8).



I've just tried this. The kernel bacame too big, it was maby recursively loaded or other error. The idea in the link was to use the FreeBSD keys to detect the binary to be genuine at boot. New notebooks and laptops have this feature in the firmware (BIOS) when they boot (UEFI). The loader is found from the 
	
	



```
/usr/src/stand
```
. 

The kernel became too big and the section names were not anymore the same as in the link. If the kernel was needed to load to check the certificates maby. If this feature is old, it is still interesting because the kernel and the filesystem is included allredy in the loaderfile. This opens new possibilities in the embedded devices.

e


----------



## CraigHB (Nov 23, 2019)

SirDice said:


> Note that FreeBSD boots differently compared to Linux. Linux boots from a memory disk that includes the kernel, FreeBSD loads the kernel directly (at stage 3).



That's one of the things I really like about FreeBSD, that it loads the kernel in the clear from physical disk.  Linux used to be that way years ago, but then they went to an "initrd" system which makes dealing with a custom kernel more involved. What's the advantage of using a memory disk there?  Seems to me like a case of making things more complicated for the sake of making things more complicated, which is usually what happens when corporations get involved.


----------



## escape (Dec 14, 2019)

File system could be run in memory only to not to fragment it. It would reset in boot instead of the mysterious hangup at the fsck .  e


----------



## escape (Jan 11, 2020)

There is not much documentation about the loader. The loader has moved to /usr/src/stand separately from the kernel, good. It is still too difficult to cross-compile it separately from the buildworld. If the solution exists, the commandline would be good to add in the /usr/src README -file or in the Makefile or elsewhere where the documentation is at. It would be good to add text to compile 'ubldr' separately as well. Thanks.

There are possibilities to bypass the loader.efi with some other loader. Here are some links (from the weekend).

From the source the boot1.c needs the following UEFI variables from efilib: _BootCurrent_ with a value in the form _BootXXXX_. Additionally 'rootdev' from a normal environment variable. Should the devices loader (U-Boot/elilo/UEFI shell/BIOS) provide these?

Good sources of information:
[http://blog.khubla.com/freebsd/spelunking-the-crochet-freebsd-wandboard-boot]
[https://github.com/freebsd/crochet/wiki/How-to-Build-a-Disk-Image]
UEFI with variables at arm.com [https://developer.arm.com/architectures/platform-design/embedded-systems]
[https://wiki.freebsd.org/FlattenedDeviceTree]

*How to boot the system without boot1*

Boot directly the kernel with some other loader. Boot directly the loader.efi with some other loader. Loaders to replace boot1: Use UEFI shell instead. Use U-Boot and ubldr instead. Use elilo.

*How to boot the system without U-Boot

elilo*, the crochet has had an option to use this one. 'startup.nsh' can be used to configure it. It may be confusing if the automated 'crochet' image used this instead of some other loader. Redhat instructions can be found from a link.

Some *UEFI shell* if BIOS or the device supports it. Can be used with U-Boot as well. *Tianocore* [https://github.com/tianocore] [http://www.tianocore.org], an open source UEFI shell Intel project. EFI instructions from Intel [https://www.intel.com/content/dam/s...s/motherboards/server/sb/efi_instructions.pdf]. *Linux kernel EFI stub*. The Linux kernel needs to be compiled with the EFI stub support if the binary can't be get elsewhere.

*How to boot the system with U-Boot

ubldr* is an executable using the U-Boot API found in '_/usr/src/stand/arm/uboot_'. It can be used with uEnv.txt of the U-Boot.

RPI3 has apparently been booted with *just loader.efi*. Where the UEFI variables are set or how is it booted would be interesting to know, URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227879 . It would be nice to find the location where the RPI3 FreeBSD additions are to read them.

*Kernel only*. There are some kernel variables to know about to compile in the memory address where the kernel is loaded and some other variables from the previous for example the URL: https://svnweb.freebsd.org/base/head/sys/arm/freescale/imx/std.imx6?revision=257483&view=markup

*elilo.efi* from U-Boot EFI/BOOT/bootaa64.efi .


What possibility is the easiests? Which work?

Most likely some loader providing UEFI since at least the BIOS UEFI works in desktop machines. Link to RPI3 FreeBSD repository would be revealing.

escape


----------



## ColdfireMC (Apr 25, 2020)

CraigHB said:


> That's one of the things I really like about FreeBSD, that it loads the kernel in the clear from physical disk.  Linux used to be that way years ago, but then they went to an "initrd" system which makes dealing with a custom kernel more involved. What's the advantage of using a memory disk there?  Seems to me like a case of making things more complicated for the sake of making things more complicated, which is usually what happens when corporations get involved.


Is just for compatibility. For example if you boot UEFI, most systems don't have native EXT filesystem support, so boot directly would be a painfully slow process because drivers have to be load on the fly, and kernel its also bigger by itself. Besides this remains from the ages that not all hardisks or memory controllers had support directly on boot(and Intel x86 Real Mode), so drivers or initializations can be added in the ram image.


----------

