UEFI for Pine64

[z4v4l]

Sup niggaz. Hi, all. First sorry for my awful english. Next, let's go to the topic.
I am working on UEFI implementation. As an individual and it is in a very beginning stage by now. Nevertheless, if it succeeded, it might be useful not only for me. Uefi is an advanced firmware standard, and it can give a rich set of booting possibilities for end users. Of mini PC range as well. It's not tight to servers at all. GPT partitioning, exhaustive list of boot options from any imaginable media and protocol - eMMC modules, SD cards, USB sticks, SSD drives, SATA and SCSI HDD drives, CD roms, network, UART, etc. It has security options (if needed). It's a modern industrial standard having close relations with other modern and important standards like Acpi.
However there is no working and usable implementation of Uefi for mini PC range, and this was one of the reasons I decided to work on it. I won't tell about my uboot dissatisfaction here. I just say I am going to bring up Uefi here, on the arm miniPC range. At least for some boards. We know, Uefi has its place in the modern x86 desktop/server world, and it will be presented at the yet illusory armv8 server range when (and if) it comes out. But for armv7 and low cost machines with "little" armv8 cores (like A53), it is not presented. So I decided to fill this gap.
My target acrhitectures are armv7, armv8, mips (yes its support is even not declared in the spec, but this couldn't be a stop factor, there is no real (technical) prevention from implementing Uefi on mips, and also - the support can have been added later). And as such, I've chosen few development boards with these acrhitectures as target machines I will work on. For armv8, I have an rk3368 box and also I am waiting for my Pine64+ 2GB to arrive. So while it is being shipped, I, from the procrastination, have decided to create this thread, telling this story and asking about possible interest of general public. Kind of survey (for this, the poll is attached, please, don't hesitate to participate, and be serious, it's freaking serious question ).
So in essence, I want to ask you, guys, would you be interested in having Uefi firmware on your boards, you are playing with? In particular - on Pine64? I understand, for the end user the main interest is the working board with working FW/SW on it. But considering reality, how it goes, would you consider trying this firmware if it were available for download? Or maybe you want to say something about this. Share your thoughts it's very important for us!
For me this project is important and interesting. I would be happy if it succeeded and lived as a standalone project and were useful for others. It's for the future and now it would be interesting to have an input from the potential users.

[ssvb]

You seem to be claiming that modern U-Boot is not implementing the UEFI support. Please have a look at http://git.denx.de/?p=u-boot.git;a=blob_...README.efi

Anyway, good luck. And I really mean it. You seem to have picked an entertaining task for yourself and it would be very interesting to see if you can do a much better job than U-Boot. BTW, is this new firmware going to be open source?

[longsleep]

Assuming it is possible without help from allwinner this seems a colossal waste of time. what's the use in comparison to modern u-boot?

[z4v4l]

You seem to be claiming that modern U-Boot is not implementing the UEFI support. Please have a look at http://git.denx.de/?p=u-boot.git;a=blob_...README.efi

I heard about this and watched some code there recently. If I understood right, they are trying to implement the support for running what they call "uefi payloads" - uefi OS loaders I believe. This is way not a UEFI support at least yet. And looking at their code I have found stubs in place of the core services (I was checking some crucial boot services like ConnectController(), RaiseTPL() etc). But I may be wrong. Good for them anyway. My project is pure UEFI from scratch. And in fact this is a part of bigger plans. So I need this anyway and I am better off writing my own things than learning other's.)))

Anyway, good luck. And I really mean it.

Thank you.

You seem to have picked an entertaining task for yourself and it would be very interesting to see if you can do a much better job than U-Boot. BTW, is this new firmware going to be open source?

Really.) It is.
As to "better" than, It's too early to say anything on this, but I don't mind it if it comes out to be better. I'll try my best. I believe standardized approach is better than chaotic though.
And also, I don't mind it to be an open-source (bsd-like licensed), because definitely it's huge and evolving into numerous participants community, might result into something much bigger and developed, than that from a single enthusiast. But there might be barriers for this, namely if a vendor is agreeing to reveal needed information on the condition of not disclosing it. But in generally the status of it is not yet decided.

---

Assuming it is possible without help from allwinner this seems a colossal waste of time. what's the use in comparison to modern u-boot?

The use is the same - booting OS, it's what it is intended for. The difference is in variety of options to boot. Given the required by the specification features are implemented, it provides a lot more both for the end user and for driver developer in comparison of what uboot gives here and now for the particular board.
it has a way to easier add support for what is lacking. I mean it's easier to implement uefi driver providing new support for something, easier to add support for booting new OS, than to extend uboot for this, uboot even doesn't have a normal documentation and it is unpleasantly fitted to only linux. You don't need recompile your own uboot! just develop the driver and put it together with the core. uefi gives a very powerful and well defined set of services for implementing device support, it has well developed UEFI driver model. End users would advantage of this having more abilities to boot their OSes, this is especially relevant for development boards on which often there is a need to try many builds of different OSes or to have easily achieved and managed multi boot options. Uefi is designed for this. You are inserting your SD card with as many GPT partitions as you want with tons of OSes installed on them, insert USB stick, plug in an HDD and network, and are able to boot from any of this media choosing options in boot menu. Of course, it's kind of idyll, but it's possible.
The minimal sufficient help from allwinner is the required information on their SoC.

[ssvb]

I heard about this and watched some code there recently. If I understood right, they are trying to implement the support for running what they call "uefi payloads" - uefi OS loaders I believe.

They are trying to implement whatever has practical value. And nothing is set in stone, the work is still being done.

This is way not a UEFI support at least yet.

However U-Boot currently has much better UEFI support than your implementation. Simply because your implementation does not exist yet

And looking at their code I have found stubs in place of the core services (I was checking some crucial boot services like ConnectController(), RaiseTPL() etc).

Well, you can always try to fix this yourself. Sending patches to the U-Boot mailing list is easy.

But I may be wrong. Good for them anyway. My project is pure UEFI from scratch. And in fact this is a part of bigger plans. So I need this anyway and I am better off writing my own things than learning other's.)))

Do you realize that "Uefi is an advanced firmware standard, and it can give a rich set of booting possibilities for end users. Of mini PC range as well. It's not tight to servers at all. GPT partitioning, exhaustive list of boot options from any imaginable media and protocol - eMMC modules, SD cards, USB sticks, SSD drives, SATA and SCSI HDD drives, CD roms, network, UART, etc. It has security options (if needed)" is not something that automatically comes as given with UEFI? It is just a big task list for you. Can you handle all of this work alone and in a reasonable time frame?

As to "better" than, It's too early to say anything on this, but I don't mind it if it comes out to be better. I'll try my best. I believe standardized approach is better than chaotic though.

And I believe that U-Boot is doing a reasonably good job. Standards exist for interoperability and U-Boot implements them. This works.

And also, I don't mind it to be an open-source (bsd-like licensed), because definitely it's huge and evolving into numerous participants community, might result into something much bigger and developed, than that from a single enthusiast. But there might be barriers for this, namely if a vendor is agreeing to reveal needed information on the condition of not disclosing it. But in generally the status of it is not yet decided.

If your implementation is not open source, then it has no realistic chance to compete with open source alternatives. People generally don't dislike standards, but they dislike closed source implementations because closed source provides too many opportunities for the firmware to secretly do bad things.

---

Assuming it is possible without help from allwinner this seems a colossal waste of time. what's the use in comparison to modern u-boot?

The use is the same - booting OS, it's what it is intended for. The difference is in variety of options to boot. Given the required by the specification features are implemented, it provides a lot more both for the end user and for driver developer in comparison of what uboot gives here and now for the particular board.
it has a way to easier add support for what is lacking. I mean it's easier to implement uefi driver providing new support for something, easier to add support for booting new OS, than to extend uboot for this, uboot even doesn't have a normal documentation and it is unpleasantly fitted to only linux.

U-Boot is on the way to support booting Windows: http://lists.denx.de/pipermail/u-boot/20...55532.html

You don't need recompile your own uboot! just develop the driver and put it together with the core.

Which core?

uefi gives a very powerful and well defined set of services for implementing device support, it has well developed UEFI driver model. End users would advantage of this having more abilities to boot their OSes, this is especially relevant for development boards on which often there is a need to try many builds of different OSes or to have easily achieved and managed multi boot options. Uefi is designed for this. You are inserting your SD card with as many GPT partitions as you want with tons of OSes installed on them, insert USB stick, plug in an HDD and network, and are able to boot from any of this media choosing options in boot menu. Of course, it's kind of idyll, but it's possible.

So what? You are listing the features that are already provided by U-Boot.

[z4v4l]

They are trying to implement whatever has practical value. And nothing is set in stone, the work is still being done.

It sounds very subjective. Who's deciding on that "practical value"? Some standard may be whether supported or not supported. There is no such a thing like "partially pregnant".)
Anyway I wish them success, I am not fighting uboot, I am just trying to implement UEFI firmware on few arm/mips SBC's. With the intention to give it to grow and evolve if it succeeds and is interesting for others.

However U-Boot currently has much better UEFI support than your implementation. Simply because your implementation does not exist yet

I agree, U boot is better than what doesn't exist yet.

Do you realize that "Uefi is an advanced firmware standard, and it can give a rich set of booting possibilities for end users. Of mini PC range as well. It's not tight to servers at all. GPT partitioning, exhaustive list of boot options from any imaginable media and protocol - eMMC modules, SD cards, USB sticks, SSD drives, SATA and SCSI HDD drives, CD roms, network, UART, etc. It has security options (if needed)" is not something that automatically comes as given with UEFI? It is just a big task list for you. Can you handle all of this work alone and in a reasonable time frame?

Clearly, it's big, it's huge, but fear is not a rational argument.
Well, I've enumerated all the possibilities that Uefi can handle, this not necessarily is presented on every machine. For example miniPC's don't have PCI, and SCSI hard drives aren't often used there. CD drives also.
So I will begin with only a subset of peripherals which are presented on SBC's - eMMC, NAND, SD, USB, UART, network. And then someone interested might add.

And I believe that U-Boot is doing a reasonably good job. Standards exist for interoperability and U-Boot implements them. This works.

I didn't say it's doing a bad job, it just has its way. But to be honest, it doesn't implement standards (yet). At most it does it partially, like with this awkward Uefi adoption or Device Tree support pulled off from OpenFirmware. Does it use device tree at all, or just blindly gives it away for the linux kernel?
But of course, It has an undoubtful advantage - it already works (at least by the principle "better than nothing").

U-Boot is on the way to support booting Windows: http://lists.denx.de/pipermail/u-boot/20...55532.html

This. The normal firmware should boot every appropriate client from the very beginning. And not invent for itself after decade of existing, that there are other clients except linux. This is for what such standards like ARC/OF/UEFI existed and exist - they provide a unified standardized way for FW to interact with OS (loaders). And every OS, aware of this standard can be loaded by the normal fw without any special efforts.

Which core?

Uefi core. If you are a Uefi driver developer, you write your driver and when it is finished, you just install it on the board among the already installed uefi. Uefi finds it and loads and runs it.
You don't have to learn all Uefi internals and compile it in order to add your driver. or a test application. or an OS loader. And the main thing - writing such a driver for Uefi is easier than extending uboot. Because it has a well defined driver model and the core gives you a very rich set of services to facilitate your work. It's not only helper fuinctions, it's the whole API and rules and model. it is developed very well. just read how driver binding in uefi occurs, what ConnectController() does for this. for example. very much burden is put into uefi core, and thus the driver developer may take advantage of this.

uefi gives a very powerful and well defined set of services for implementing device support, it has well developed UEFI driver model. End users would advantage of this having more abilities to boot their OSes, this is especially relevant for development boards on which often there is a need to try many builds of different OSes or to have easily achieved and managed multi boot options. Uefi is designed for this. You are inserting your SD card with as many GPT partitions as you want with tons of OSes installed on them, insert USB stick, plug in an HDD and network, and are able to boot from any of this media choosing options in boot menu. Of course, it's kind of idyll, but it's possible.

So what? You are listing the features that are already provided by U-Boot.

Let's be honest, the maximum you have on a particular board now is an ability to boot from SD/eMMC. And possibly through TFTP. And board vendors obviously are struggling to add in uboot something yet (like USB boot), despite these features are often requested. Easiness of multiboot and from any media on uboot exists only theoretically, the same as my Uefi implementation.

[ssvb]

You don't have to learn all Uefi internals and compile it in order to add your driver. or a test application. or an OS loader. And the main thing - writing such a driver for Uefi is easier than extending uboot. Because it has a well defined driver model and the core gives you a very rich set of services to facilitate your work.

Yeah, that's a nice fairy tale. You still need to be able to debug the drivers, that's where the things usually become ugly

Let's be honest, the maximum you have on a particular board now is an ability to boot from SD/eMMC. And possibly through TFTP. And board vendors obviously are struggling to add in uboot something yet (like USB boot), despite these features are often requested. Easiness of multiboot and from any media on uboot exists only theoretically, the same as my Uefi implementation.

Huh? Of course U-Boot supports booting from SD cards, USB sticks, SATA, Ethernet (both TFTP and PXE), USB OTG and pretty much every other possible option. Instead of speculating, just get some Allwinner board with an older SoC and you will see it yourself. Or read about it here: http://git.denx.de/?p=u-boot.git;a=blob;...DME.distro

The Pine64 board is a bit special case, because it is the first Allwinner 64-bit SoC. That's why it needs more work (also partially because we surely want to have UEFI working on AArch64 too). But the Allwinner A64 and Pine64 support in U-Boot is progressing nicely (some initial support is already there!) and we are likely only a few months away until it is in a perfectly usable shape.

[z4v4l]

Yeah, that's a nice fairy tale. You still need to be able to debug the drivers, that's where the things usually become ugly  

This fact doesn't deny what I've said, - a much more developed Uefi interface, makes it easier to implement board support. Not easy, but easier.

Huh? Of course U-Boot supports booting from SD cards, USB sticks, SATA, Ethernet (both TFTP and PXE), USB OTG and pretty much every other possible option. Instead of speculating, just get some Allwinner board with an older SoC and you will see it yourself. Or read about it here: http://git.denx.de/?p=u-boot.git;a=blob;...DME.distro

The Pine64 board is a bit special case, because it is the first Allwinner 64-bit SoC. That's why it needs more work (also partially because we surely want to have UEFI working on AArch64 too). But the Allwinner A64 and Pine64 support in U-Boot is progressing nicely (some initial support is already there!) and we are likely only a few months away until it is in a perfectly usable shape.

I love that with allwinner's SoC's there is such an (almost) idyll. Not everywhere this is the case. Some boards, decent ones, by the hardware, have uboot that can only boot from SD/eMMC.

[ssvb]

I love that with allwinner's SoC's there is such an (almost) idyll. Not everywhere this is the case. Some boards, decent ones, by the hardware, have uboot that can only boot from SD/eMMC.

This is not idyll, but rather normal. Which "decent" boards do you have in mind? My guess is that these are probably some very old boards, using a very old version of U-Boot and most likely having almost no real users remaining nowadays (because the boards are old, not sold anymore and used to be relatively expensive).

You can probably implement your UEFI firmware for these decent boards. Or just bring U-Boot support up to date and add the missing features, which is likely orders of magnitude easier.

[z4v4l]

This is not idyll, but rather normal. Which "decent" boards do you have in mind? My guess is that these are probably some very old boards, using a very old version of U-Boot and most likely having almost no real users remaining nowadays (because the boards are old, not sold anymore and used to be relatively expensive).

no, those aren't old boards, they are current. this is not allwinner SoC's boards, and their uboot doesn't support much. features are just not implemented.

You can probably implement your UEFI firmware for these decent boards. Or just bring U-Boot support up to date and add the missing features, which is likely orders of magnitude easier.

I don't think it is easier. As I've said - UEFI is a standard, it has a complete documentation. It's much easier to get what it means what its philosophy and stuff. And its modular - I write the core, and then I and other write needed drivers. It lets you to start with something tiny and expand it continuously. uboot on the other hand is a not structured, not documented mess. in order to get how to work for it, one needs learn through its entire codebase, it would not be easier and not that fun at all.