UEFI for Pine64

[MarkHaysHarris777]

UEFI may make some sense for these tiny boards from an educational standpoint and from a security standpoint, as long as major corporations don't control it. I would encourage you to give it a shot and see where it goes; why not?

If you get down the road with it a ways and need some beta testers let me know; I'll play.

[ssvb]

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.

For the sake of clarity, do these boards have names? If they are very new, then their situation may be very similar to Pine64 and the work adding support for the missing features might be already under way.

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.

U-boot does have a bit of documentation and it is easy/usable enough. I have already provided two links to you in this discussion thread. I'm pretty sure that you can find most of the needed information yourself if you put some effort into it.

---

UEFI may make some sense for these tiny boards from an educational standpoint and from a security standpoint, as long as major corporations don't control it.

Yes, modern ARM systems rely on the firmware remaining active all the time and providing some services for the operating system running under it. At the very minimum the firmware is providing the PSCI interface, which is used for bringing up secondary CPU cores and implementing SMP. In the case of older 32-bit Allwinner chips, the U-Boot bootloader is responsible for starting this firmware and it is fully open source. In the case of Allwinner A64, the firmware is maintained not as a part of U-Boot, but as a separate ATF project. Things are a little bit more complicated by the fact that Allwinner SoCs also have a supplementary OpenRISC core,  which can provide some assistance for implementing a decent suspend-to-ram support and power management handling in general. This part of code is closed source in the Allwinner's BSP, but it is more or less optional and the mainline U-Boot & Linux kernel can run without it. Moreover, we can compile and run arbitrary code on the OpenRISC core too, but just have not implemented a usable firmware for it yet. As mentioned earlier, UEFI is a useful standard, it already has basic support in U-Boot and things will improve even more in the future.

Alternative firmware & bootloader implementations are surely welcome. But from the purely practical point of view, they need to bring something useful to the table in order to successfully compete with the existing solutions. Especially considering that the existing solutions are not standing still either.

The corporations can't have control even if they wanted to because Allwinner SoCs are perfectly open source friendly and don't require any signed blobs. The first stage bootloder code starts with full privileges and is not restricted by the boot ROM in any way. You don't normally have this kind of complete unrestricted freedom with the SoCs from Samsung or other big corporations. It is in fact one of the reasons why Allwinner is so popular and has an active open source community around it.

[xalius]

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.

For the sake of clarity, do these boards have names? If they are very new, then their situation may be very similar to Pine64 and the work adding support for the missing features might be already under way.

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.

U-boot does have a bit of documentation and it is easy/usable enough. I have already provided two links to you in this discussion thread. I'm pretty sure that you can find most of the needed information yourself if you put some effort into it.

---

UEFI may make some sense for these tiny boards from an educational standpoint and from a security standpoint, as long as major corporations don't control it.

Yes, modern ARM systems rely on the firmware remaining active all the time and providing some services for the operating system running under it. At the very minimum the firmware is providing the PSCI interface, which is used for bringing up secondary CPU cores and implementing SMP. In the case of older 32-bit Allwinner chips, the U-Boot bootloader is responsible for starting this firmware and it is fully open source. In the case of Allwinner A64, the firmware is maintained not as a part of U-Boot, but as a separate ATF project. Things are a little bit more complicated by the fact that Allwinner SoCs also have a supplementary OpenRISC core,  which can provide some assistance for implementing a decent suspend-to-ram support and power management handling in general. This part of code is closed source in the Allwinner's BSP, but it is more or less optional and the mainline U-Boot & Linux kernel can run without it. Moreover, we can compile and run arbitrary code on the OpenRISC core too, but just have not implemented a usable firmware for it yet. As mentioned earlier, UEFI is a useful standard, it already has basic support in U-Boot and things will improve even more in the future.

Alternative firmware & bootloader implementations are surely welcome. But from the purely practical point of view, they need to bring something useful to the table in order to successfully compete with the existing solutions. Especially considering that the existing solutions are not standing still either.

The corporations can't have control even if they wanted to because Allwinner SoCs are perfectly open source friendly and don't require any signed blobs. The first stage bootloder code starts with full privileges and is not restricted by the boot ROM in any way. You don't normally have this kind of complete unrestricted freedom with the SoCs from Samsung or other big corporations. It is in fact one of the reasons why Allwinner is so popular and has an active open source community around it.

Thanks again for this information, I learned a lot about how those SoC boot and operate from the efforts of linux-sunxi development community, keep up the good work

[z4v4l]

The corporations can't have control even if they wanted to because Allwinner SoCs are perfectly open source friendly and don't require any signed blobs. The first stage bootloder code starts with full privileges and is not restricted by the boot ROM in any way. You don't normally have this kind of complete unrestricted freedom with the SoCs from Samsung or other big corporations. It is in fact one of the reasons why Allwinner is so popular and has an active open source community around it.

Does Allwinner let you implememt your own Monitor? And I mean not just entering secure state, after BROM, I mean the monitor mode handler, who manages SMC's?

[ssvb]

Does Allwinner let you implememt your own Monitor? And I mean not just entering secure state, after BROM, I mean the monitor mode handler, who manages SMC's?

PSCI is implemented as a secure monitor and provides an SMC based interface. You can check the U-Boot code for more details, or look at the following patch sets:
http://lists.denx.de/pipermail/u-boot/20...52872.html
http://lists.denx.de/pipermail/u-boot/20...67594.html

[z4v4l]

Does Allwinner let you implememt your own Monitor? And I mean not just entering secure state, after BROM, I mean the monitor mode handler, who manages SMC's?

PSCI is implemented as a secure monitor and provides an SMC based interface. You can check the U-Boot code for more details, or look at the following patch sets:
http://lists.denx.de/pipermail/u-boot/20...52872.html
http://lists.denx.de/pipermail/u-boot/20...67594.html

Ok, thanks. They seem to have reinvented the UEFI Runtime Services wheel. But the links are mostly about enabling an easier way for the virtualization stuff. It's not the monitor in its entirety. But thank you for the info. I found I have the spec on PSCI on my computer for the long time.
So you say, with Allwinner SoC's, any 3rd party developer can implement its own Monitor and give their users all Secure world stack? Sounds too cool to be a reality. In fact, the standard by Arm implies this layer is owned by silicon vendor and it is not available to freely implement your own. They provide PSCI as a recommendation standard and they provide a reference implementation for it. But they say PSCI should reside in SPF (secure platform firmware), which in turn is owned by the silicon vendor and you can not provide your own. You only may somehow get certified for your TrustedOS, but I have no idea how much it costs this does work. Still, you will not be able to supply SPF. This is how I understand this mess thing on the arm architecture. If I am wrong, please correct me.

[ssvb]

But the links are mostly about enabling an easier way for the virtualization stuff. It's not the monitor in its entirety.

Are you sure? Have you checked the MVBAR setup code?

So you say, with Allwinner SoC's, any 3rd party developer can implement its own Monitor and give their users all Secure world stack? Sounds too cool to be a reality.

Just get your Pine64 board and you will see it yourself. I'm pretty sure that you will like this hardware.

[z4v4l]

But the links are mostly about enabling an easier way for the virtualization stuff. It's not the monitor in its entirety.

Are you sure? Have you checked the MVBAR setup code?

No, I am not sure. I just read the abstracts given in those links. there virtualization was emphasized heavily.
If it deals with the Monitor handler part of the architecture, I definitely need to check it. It's just too much to check out now.)

So you say, with Allwinner SoC's, any 3rd party developer can implement its own Monitor and give their users all Secure world stack? Sounds too cool to be a reality.

Just get your Pine64 board and you will see it yourself. I'm pretty sure that you will like this hardware.

I am waiting to get it indeed.)
My love to arm sbc's would not hurt much, if the Monitor implementation on them isn't possible. UEFI doesn't need it, all in all (it might use those "secret" barely implemented by the vendor SMC calls). I just wanted to figure out this question. Because what I have learnt before was indicating there is no easy way to install it by the third parties, especially community/enthusiasts etc, what you are saying is that there is an open source implementation of something that looks like the Monitor software.
But there is a chain of trust established if the Secure extension is present (it is), and it cannot be easy to insert yourself into it. So, how that software gets verified and becomes a part of the chain-of-trust? How does it get its way into a SoC? You need vendor's bless for that. And that is not an easy thing, because why should they bother, right? they may just reject saying that is not needed for them. I was asking similar question yet another arm soc vendor and got silence. ah, well I asked allwinner too. they didn't answer as well. well they are busy and I am just having fun, a logical outcome.)
I thought that PSCI reference implementation is for vendors.

[z4v4l]

Are you sure? Have you checked the MVBAR setup code?

Yeah, I had a look at the code, and it is definitely supposed to run in the Monitor Mode - it supplies the monitor vector, yes. But I have no idea yet how this code is supposed to get installed on the SoC.
If such a code is freely installable on the platform this means two things, first: you can easily do your own monitor and be happy, you wanted this, and second: the whole security thing is f&&&ed up entirely with such a frivolous approach. xD

[z4v4l]

just came up to say the project is alive and slowly moving forward. well, it's an individual spare time effort, so it's slow as hell.

currently, I am messing around with ci20 board, but cubieboard2 and pine64+ are just lying next to it on my desk. After I finish a first pass of the Sec phase on ci20, I plan to recreate this on both armv7 and armv8 boards in parallel. Sec phase it's like uboot's SPL, kind off. It initializes SDRAM and loads the FW's "core" into it from SD/MMC/NAND etc. The core here is Dxe core, the main internal UEFI part. It has been partially written, but not yet tested - even though most services are RAM only requiring, they don't need peripherals working to provide their functionality, still a solid start sequence and decent memory management are needed. After having the first working (Sec phase - PLLs, SDRAM, SD read, HOB list, PE loader), I'll begin with the second (proper memory manager). And then, I can start to create numerous Dxe drivers doing all the job (mainly storage, network, hdmi/lcd for pretty GUI). Haha. Never expected it to be easy.
Here is a screenshot of a putty output showing Efify happily reports SDRAM init success. Which means it has done with clocks/dividers, uart and sdram.



Meanwhile the Rock64 board has been released. And looks very attractive for this. USB3, 4GB of RAM, and finally SPI NOR which I so badly lack - are all the most desirable things! Kewl. The only annoying thing is not yet available SDRAM init sequence, so that you could at least repeat after it (what else to do if the spec is silent). But this is going to change, thanks to Rockchip's desire to be more open.

Whenever I make progress with my Allwinner boards, which, I believe, are of interest here, I'll report it here.