UEFI for Pine64

[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.