Are you interested in using UEFI on Pine64 or other arm board as the board's firmware?
Yes, it would be interesting if it works.
63.33%
19
Yes, it's interesting, but where the download link?
6.67%
2
Maybe, but for me uboot is enough.
23.33%
7
I am happy with uboot and religiously deny to use Uefi, because it comes from evil corporations!
6.67%
2
What's Uefi? Can it run Kodi?
0%
0
30 vote(s)
* You voted for this item. [Show Results]

UEFI for Pine64
#1
Information 
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. Big Grin
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. Angel 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 Big Grin).
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! Big Grin
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. Smile
  Reply
#2
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?
  Reply
#3
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?
  Reply
#4
(06-11-2016, 03:40 PM)ssvb Wrote: 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.)))
Quote:Anyway, good luck. And I really mean it.
Thank you.
Quote: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.

(06-11-2016, 04:08 PM)longsleep Wrote: 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.
  Reply
#5
(06-11-2016, 05:03 PM)z4v4l Wrote: 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.

Quote: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 Wink

Quote: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.

Quote: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?

Quote: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.

Quote: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.

(06-11-2016, 05:03 PM)z4v4l Wrote:
(06-11-2016, 04:08 PM)longsleep Wrote: 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


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

Quote: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.
  Reply
#6
(06-11-2016, 06:02 PM)ssvb Wrote: 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.
Quote:However U-Boot currently has much better UEFI support than your implementation. Simply because your implementation does not exist yet Wink
I agree, U boot is better than what doesn't exist yet. Big Grin
Quote: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. Smile
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.
Quote: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").
Quote: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.
Quote: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.
Quote:
Quote: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. Big Grin
  Reply
#7
(06-12-2016, 06:40 AM)z4v4l Wrote: 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 Smile

Quote: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. Big Grin
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.
  Reply
#8
(06-12-2016, 10:56 AM)ssvb Wrote: 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  Smile
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.
Quote: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.
  Reply
#9
(06-12-2016, 04:44 PM)z4v4l Wrote: 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.
  Reply
#10
(06-20-2016, 05:14 AM)ssvb Wrote: 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.
Quote: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.
  Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
Information Pine64 Head Unit Zoidiano0 100 27,993 11-19-2019, 04:35 AM
Last Post: rogatip79
  PINE64 to allow use of SATA disk on network/FTP mwelbourne 10 127 11-18-2019, 04:09 PM
Last Post: evilbunny
  Pine64 E-ink screen - Android projectileobjects 3 1,838 06-25-2019, 07:31 AM
Last Post: clamum
  How to setup VNC on your Pine64 (Debian, SSH, headless) pine64nutz 20 15,139 04-16-2019, 08:00 AM
Last Post: hg6806
  Setup Pine64+ with OP-TEE stdys 0 301 09-13-2018, 03:23 PM
Last Post: stdys
  Domoticz + PINE64 Z-Wave Module + Open Z-Wave klliew 4 3,158 04-19-2018, 02:23 AM
Last Post: Harlan Mueller
  Pine64 as Security Camera / Baby Monitor utdrmac 2 1,968 02-01-2018, 07:49 AM
Last Post: davidbrucs
Photo Nextcloud running on Pine64 gbjensen 1 1,415 01-18-2018, 05:51 AM
Last Post: Luke
  smartphone based on a pine64 Little_Johnny 9 1,642 10-28-2017, 02:57 AM
Last Post: Little_Johnny
  Does my idea is possible ? Use of pinebook + rock64 + pine64 liochan 0 899 07-17-2017, 06:48 AM
Last Post: liochan

Forum Jump:


Users browsing this thread: 1 Guest(s)