Project Mu

[hansmbakker]

Well done on what you already achieved!

I'm wondering whether you have considered using Project Mu to support the development that you are doing (which, as I understand, is a UEFI based on TianoCore)?

Microsoft open sourced the core of their TianoCore-based UEFI (which they use for Surface), and documented how to best manage development and releases.

[driver1998]

Are there any advantages of Project Mu over stock TianoCore? I know it has a nice GUI with touch support, but RPi is not a touch device anyway.

[hansmbakker]

A modern GUI is nice indeed, and additionally they say they set up ways to develop and release in a better way. Some quotes:

It represents a variant of TianoCore that was customized within Microsoft for scaling and maintainability.

It is our goal to continue to treat TianoCore as a true upstream. Our release branches will always be based on the latest stable TianoCore release, and we will always try to PR viable fixes and features into the TianoCore project.

Source: https://microsoft.github.io/mu/faq/

The features page lists some of the development / testing tools they offer.

[andreiw]

Hi Hans,

Pete Batard has been actively working on upstreaming this Pi support as an “official” edk2 platform. Once that’s done and there is a wider community engagement around the UEFI Pi port, that will be a good time to integrate Mu components or re-base where appropriate.

https://github.com/andreiw/RaspberryPiPkg/issues/88

A

15 янв. 2019 г., в 16:42, Hans Bakker notifications@github.com написал(а):

A modern GUI is nice indeed, but the point was that they say they set up ways to develop and release in a better way. Some quotes:

It represents a variant of TianoCore that was customized within Microsoft for scaling and maintainability.

It is our goal to continue to treat TianoCore as a true upstream. Our release branches will always be based on the latest stable TianoCore release, and we will always try to PR viable fixes and features into the TianoCore project.

Source: https://microsoft.github.io/mu/faq/

The features page lists some of the development / testing tools they offer.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[andreiw]

Closing in the mean time.

[hansmbakker]

@andreiw interesting, thank you for the explanation!

Keep up the good work!

[hansmbakker]

@andreiw @pbatard I believe the upstreaming is done now - what are your views on this issue?

[andreiw]

I think its all interesting, but right now I am scrambling to rehost on top of edk2-platforms to start working the Pi 4 support. How hard is it to adopt Mu components?

[pbatard]

I'm going to be super cynical here, but I don't like Mu. At all.

For one thing, I can't for the life of me figure why, if they though the EDK2 code wasn't exactly suitable for the Surface, which is a consumer product where it's hard to see the limited performance loss from using perhaps a less than optimized boot process having much of an impact on the platform user, they didn't try to work with the EDK2 to get that sorted. Maybe the story is different for Hyper-V, but then there's something a bit fishy in mentioning the Surface in there. So, something just doesn't smell right for me, and, as is the case with the bullshit excuse Microsoft provided for explaining their refusal to sign any GPLv3 code for Secure Boot (when they are happy to sign shims that will, in turn, invoke GPLv3 code), I fear that, through Mu, Microsoft is simply trying to push for both themselves and other corporations with the ability to exert more control over what users can and cannot do with their hardware. For one thing, their whole spiel seems to be unnervingly concentrated with business and legal matters, which, in most instances, spells bad news for end users.

You just have to look at the following spiel from https://microsoft.github.io/mu starting with this: "Mu is built around the idea that shipping and maintaining a UEFI product is an ongoing collaboration between numerous partners." which pretty much translate to "Microsoft knows that hardware manufacturers don't want to have to bother investing resources to support end-user firmwares, and boy do we want to help you with that!". And then it only gets better with "To build most products it often requires both closed-source, proprietary assets as well as open source and industry standard code." which translate to "We'll help you make sure that you can conceal code in what should rightfully be a fully Open Source product,..." (because who in their right mind wants to promote the use of closed source in the binary that boots your device. We have enough unnerving questions on how Intel ME could be subverted already) "...so that end users are going to be left seriously stranded the day they need to fix an issue in a part of the code that you've decided to keep to yourself and long ceased to support".

And then you get "Entice partners", "Lower costs" (which, contrary to what Microsoft is trying to push, I've hardly ever seen associated with "Higher quality", on the contrary), "Less is more" (meaning, that they are likely to remove features that consumers might need/want), and so on.

Well, every single time I have seen that kind of direction being advocated, and a company going over the established project (here the EDK2) to do their own thing, I have also seen the end user pay the price, with a power balance utterly skewed towards corporations rather than consumers. And once again, we have repeated evidence (Microsoft forcing manufacturers of early Windows on ARM to prevent the disabling of Secure Boot, arbitrary choice of what license can and cannot be accepted for Secure Boot signing, etc.) that Microsoft cannot exactly be trusted to do what's best for the end user in that area. So, personally, I wouldn't touch Mu with a 10 foot pole.

As a Free Software developer, if I see that one of your project's goal is to foster the use of proprietary code in a product that general consumers are going to use (and what's more, to use for booting their device), that's not something I can see myself endorsing. Then again, that's just my opinion, and I'm not going to prevent others from doing so if they so wish.

I've also seen no evidence so far that Microsoft tried to work with the EDK2 to try to get their desired features discussed, let alone integrated (granted, some of these are tied to Windows, but that doesn't mean they should just go over the EDK2 with the whole thing). It just seems to me like, even as they forked their own project on top of it, they didn't bother discussing their plans and goals with the EDK2, and one can only be left to wonder why that is...

[hansmbakker]

I believe it is not that black/white.

While their setup might facilitate hardware vendors to get away with binary blobs, I do not believe that is something that will then automatically apply to projects using project mu. If Raspberry Pi developers would use it they would not be forced to use binary blobs.

I believe that text you quoted is more written out of pragmatism - they probably can’t force hardware vendors to open source everything (although I agree it would be good) but still want to improve the UEFI building process and want others to join.

As for their collaboration with EDK2 I can’t judge since I’m not part of that community.

As for what happened to the first WinRT devices (first Surface tablet devices) I agree that wasn’t nice, but I believe Microsoft has come a long way since then (with Satya Nadella the company has become much more open-source friendly than it was before). Whether that is enough is for everybody to judge.

[hansmbakker]

How hard is it to adopt Mu components? @andreiw I have no experience building it, so I can't say unfortunately