Re-partitioning; Adding swap partition; Using GPT partitions

[Jeremiah Cornelius]

Hi @z4v4l, for UEFI I think completeness is best defined by the ability to accomplish useful tasks, such as booting an installer from SD card and installing a (working  ) OS to eMMC.

<SNIP>

interacting with grub via the serial port is a lousy user experience.

<SNIP>

Maybe we will reach a point where improving the completeness of the generic u-boot UEFI support is a road block that must be overcome to unlock another use-case. However that, IMHO would be a success, not a failure, since it would be an indicator of how far the PBP has come!

This is a very good approach to boiling the ocean, Daniel. Start one drop at a time. :-)

Regarding GRUB from serial, I have to remind myself of toggling hw registers on a PDP — or POKEing ROM addresses on an Apple ][. You obviously don't want this kind of interaction when you're really just trying to get WiFi sitting on a flight in tourist class!

[z4v4l]

Hi @z4v4l, for UEFI I think completeness is best defined by the ability to accomplish useful tasks, such as booting an installer from SD card and installing a (working  ) OS to eMMC.

I don't want to argue in vain on the topic of what is the best measurement for the completeness of a standard implementation, but what you show above as an example is what uboot exactly lacks to acomplish by means of its UEFI part. because what you described, does require Boot#### variable and Co support. I mean if one would want to install the OS through  the UEFI environment mechanism. we weren't about grub or any other addons. if an implementation is complete/comformant, then it lets you do what you described just by means specified in the spec. uboot doesn't have Boot Manager at all.

Ultimately the minimum feature set needed to be UEFI complaint is surprisingly small (and, with the latest spec update, includes the option to return EFI_UNSUPPORTED for all runtime services) and I think it is better to measure "completeness" in what percentage of *use-cases* work rather than what percentage of *features* are implemented.

As a concrete example personally I would prioritize support for the eDP panel over support for setting non-volatile variables (neither of which is required to be compliant). This is because multiple Linux installers can install a bootable OS on UEFI systems where EFI_RUNTIME_SERVICES.SetVariable() is not implemented but interacting with grub via the serial port is a lousy user experience. To be clear SetVariable() is a good thing to implement but for my own hacking it is not on the radar yet.

you are very optimistic about the UEFI requirements "minimalism". namely, the aforementioned NVRAM variables are defined and required, - without them it's impossible to install an OS, the UEFI way. the fact linux "can" do something with grub is kewl, but it's not UEFI, an OS that relies on the latter and gives no sh1t about grub would fail to install. I realize, an OS for PBP means linux only so far, but it may change (hopefully ), the point is we were talking about if UEFI in uboot is usable, not about halfassed ways that linux can be somehow installed. funny enough, but with eDP from your example, I don't know where you read so liberal requirements, in my book (again, i am away from the computer and the tablet is killing me, so I only check quickly with what is present locally and this is v2.4), so the "requirements" section clearly says - if a platform has a "video output device", the implementation must support it (through the bunch of related protocols like GOP and others). so your example actually confirms uboot incompliance even by the subjective "usefulness" criterion.

[danielt]

@z4v4l , absolutely, totally optimistic (mostly because I'm an eternal optimist and don't see any need to break my traditional habit here)!

The generic EFI code in upstream u-boot has support for the BootXXX variables and graphics output protocol. It also has support for SetVariable() at runtime (if running on a platform that has hardware that can support it... and the PBP can). What is missing are the u-boot drivers... By the time we push the limits of the generic code I still think we'd be in a very good position.

[z4v4l]

by no means i want to lower uboot capabilities, what you say sounds fantastic for me too, because my interest is exactly to have proper UEFI in the uboot, but you say "uboot supports GOP" and yet "it lacks (its drivers) for eDP". well, that means uboot doesn't have yet the support for eDP. because exactly such a driver would produce a GOP instance for the PBP panel and that instance would be fullfilled with functionality. UEFI protocols are interfaces for exposing functionality in a defined way. no driver means no functionality. good luck with that anyway. are you involved in the uboot development? if not a secret, of course.

[danielt]

The summary above now looks rather similar to the one I originally offered @Arwen! There are driver gaps for Pinebook Pro but as soon as the PBP specific u-boot drivers (the most difficult of which is to add code to light up the panel) are written then UEFI support should essentially be "free".

I'm not really a u-boot developer. I have sent the odd patch here and there over the years but it has all been drive-by contributions, nothing longer than a couple of lines.

My interest in all this is very single minded to be honest: I want the official upstream generic Debian Arm64 ISO to work on Pinebook Pro as well as it does on a regular PC and plan to work on whatever the most immediate obstacle is... although be warned that I may get interested in something else before reaching the finishing line (and especially so when my PineTime arrives).

The unofficial Debian installer I shared (https://forum.pine64.org/showthread.php?tid=8487 ) represented my work to date! The initial obstacle[1] was getting Debian running well on the PBP with the fewest hacks possible: sneaky hacks tend not to work with generic installers so it is important to find out what the hacks are and eliminate them. u-boot isn't the next obstacle yet (I want to look a bit deeper at kernel packaging first since there are still a few shortcuts I took that I need to tidy up) but I think it will be soon! Note also that the default partitioning and firmware scheme was also an early minor obstacle which I addressed in the unofficial installer and shared on this thread.


[1] Actually strictly speaking the initial obstacle was having a close-to-mainline kernel to develop against; I started working on that but when @tsys published his work I saw he was much further along than me so I rebased on his kernel instead.