Are there any porting efforts ongoing for WoA? It seems to be running on the rPi
If not what would be the main hurdles to getting it to work?
I am interested as well. I think it would be much better for it to run in KVM so Windows is not in charge of IO (even the Pi4 image is horribly slow). Please see my post https://forum.pine64.org/showthread.php?tid=8391
I think this is something useful to persue. Maybe it is best if someone official from Pine64 reaches out to the makers of WoA on the RPi? That will have more effect.
If this would be available, I think a lot more people would buy the PBP. Not from a FOSS perspective, but if it is possible I think it is very useful to have and in the end we can only benefit from it.
(11-21-2019, 09:25 AM)brent.thierens Wrote: I think this is something useful to persue. Maybe it is best if someone official from Pine64 reaches out to the makers of WoA on the RPi? That will have more effect.
If this would be available, I think a lot more people would buy the PBP. Not from a FOSS perspective, but if it is possible I think it is very useful to have and in the end we can only benefit from it.
If someone finds the dev(s), I think it'd be very acceptable to approach them as a Pine customer, and tell them we have users interested in WoA for this device, and ask if their willing to share resources so our community may emulate their efforts (if they aren't interested in participating themselves.)
Okay, so I contacted a few guys:
Quote:Hi Brent,
Thanks for reaching out. First of all, I think it would be awesome to support Windows on Arm on the RK3399-based Pinebook or on the whole lot of RK3399-based boards. More importantly, the Windows journey means finally bringing standards to the Rockchip ecosystem. You may have heard about the "Arm Server" hardware/firmware standards in the past, but what is really important is that these are no longer "server" standards. At the last Arm TechCon Arm announced that SBSA and SBBR compliance is the wave of the future for general-purpose OS support in any footprint. And even without Arm, we see /some/ adoption of at least UEFI and ACPI in the Windows on Arm laptops built with Qualcomm parts... And this is where I step back and point out that I work on the VMware ESXi/vSphere hypervisor for Arm, and so I'm actually very interested in having more-or-less standardized systems in the Edge footprint booting via UEFI+ACPI.
Anyway.
Yes, I did the full Pi 3 UEFI port - although it was based on a) some early code from Ard Biesheuvel (http://www.workofard.com/) and Microsoft's IoT 32-bit UEFI firmware for Pi 2/3. That code was subsequently upstreamed into edk2-platforms (https://github.com/tianocore/edk2-platforms) by Pete Batard (http://akeo.ie/).
I do have a WiP Rk3399 UEFI firmware that I based off a tree that Pete has, although it's not seeing much work. It should work on many Rk3399 platforms (modulo GPIO, PMIC differences and the like), but it was developed against the FriendlyElect NanoPi-M4. I added rudimentary xHCI support to it (but it only works with USB2 devices or USB3 devices when isolating the USB3 pins, because I don't bring up the PHY) and enough ACPI to boot ESXi. Actually showed it running at the TechCon Expo in the Infrastructure Zone in the VMware booth.
The last thing I was working on (the firmware is a hobby really, but one I have very little time for) was HDMI support but it didn't seem to work (no valid HDMI signal... unclear if I am driving VOP or HDMI encoder correctly!).
Anyway - https://github.com/andreiw/rk3399-edk2 is the code, as-is. If you take this code, I do suggest doing the work in a way where it's upstreamed or upstreamable into edk2-platforms.
I definitely won't be able to commit to develop it for you. I can provide UEFI/ACPI guidance as appropriate, maybe do some commits that further my own goals, and even help bring you folks into Arm's efforts in supporting more "Edge hardware" under their "Project Cassini" (https://community.arm.com/developer/ip-p...f-the-edge, if that's interesting to you - or to Rockchip). Like I mentioned, I'd love myself to have a product-grade Rk3399-based platform for ESXi-Arm myself. I'm not a Rockchip expert myself and been lucky that Rockchip is the only company that actively releases their TRMs to general public.
So... who else could help here technically? I don't think there's a WoA community per se.
- Pete Batard, since it's his Tiano UEFI tree that I forked. Maybe he'll be interested. I CC'ed him.
- Rockchip? They ought to be interested in UEFI+ACPI firmware for their chips. Again, it's where the ecosystem is going for this class of chips anyway.
- Alexander Graf from Suse/U-boot? He added UEFI support to U-boot. So maybe you can get away with U-Boot instead of going to Tiano. Unfortunately there's still no ACPI support. I'm sure they were interested in adding support for booting Windows too, though.
- Ben (@imbushuo, https://www.imbushuo.net/) did all the amazing Qualcomm device support. Don't have his contacts beyond Twitter.
- Arm? Laptop aside, maybe they would like to invest into Rk3399 firmware as part of Project Cassini?
A
Quote:Hi Brent,
I'm afraid that just like Andrei, while I would really want to see
Windows 10 running on RK3399 boards, my time and probably my knowledge
of all the intrinsics required to produce a working UEFI firmware, are
too limited to see it as something I can be involved with at this stage.
Now, if you do happen to find an experienced group of developers willing
to invest the time and effort to produce a working firmware able to run
Windows or vanilla Linux distros (e.g. Debian ARM64) on RK3399, then I
would be happy to help with upstreaming effort into the official EDK2,
similarly to what I did with Andrei's RPI3 UEFI firmware. But I don't
think I'll have much scope to help with this endeavour beyond that.
The problem of course is that, unless you have a platform that is being
sold in large volume, such as the one seen with Raspberry Pi boards,
it's going to be difficult to find someone who has all of the expertise,
interest in the hardware, as well as free time, to complete such a
development.
Most likely, what may happen is that, just as I tried to pick the
initial UEFI pieces produced by Rockchip to play with it a little bit,
and then Andrei picked on that to add some more, you're going to have to
wait for a 3rd or 4th person to build on what we currently have in the
hope that they will get to finalize that work since most of the easily
identifiable people who might help probably have their hands full. Or as
Andrei pointed out, you can try to make a case to Rockchip that having a
RK3399 platform that runs a full Windows 10 could be a game changer,
though this might be a hard sale...
At any rate, I genuinely wish you all the luck in trying to get the
resources needed to complete a full RK3399 UEFI firmware port. Once
again, I'll be happy to help with the official upstreaming process if
you do manage to complete that. But that's about all I can see myself
being able to help with.
Regards,
/Pete
I do not think we have the basis ready for them to jump in?
I also contacted ARM. They want to have a call next week, to find out more about the details and whether it is UEFI or WoA that we/I want. However, since I do not know the details of this, I was wondering if it isn't better if they contact @ Luke? I have the feeling this is getting a bit above my head  Maybe I also just don't know what they expect.
(11-26-2019, 03:03 PM)brent.thierens Wrote: Okay, so I contacted a few guys:
Quote:Hi Brent,
Thanks for reaching out. First of all, I think it would be awesome to support Windows on Arm on the RK3399-based Pinebook or on the whole lot of RK3399-based boards. More importantly, the Windows journey means finally bringing standards to the Rockchip ecosystem. You may have heard about the "Arm Server" hardware/firmware standards in the past, but what is really important is that these are no longer "server" standards. At the last Arm TechCon Arm announced that SBSA and SBBR compliance is the wave of the future for general-purpose OS support in any footprint. And even without Arm, we see /some/ adoption of at least UEFI and ACPI in the Windows on Arm laptops built with Qualcomm parts... And this is where I step back and point out that I work on the VMware ESXi/vSphere hypervisor for Arm, and so I'm actually very interested in having more-or-less standardized systems in the Edge footprint booting via UEFI+ACPI.
Anyway.
Yes, I did the full Pi 3 UEFI port - although it was based on a) some early code from Ard Biesheuvel (http://www.workofard.com/) and Microsoft's IoT 32-bit UEFI firmware for Pi 2/3. That code was subsequently upstreamed into edk2-platforms (https://github.com/tianocore/edk2-platforms) by Pete Batard (http://akeo.ie/).
I do have a WiP Rk3399 UEFI firmware that I based off a tree that Pete has, although it's not seeing much work. It should work on many Rk3399 platforms (modulo GPIO, PMIC differences and the like), but it was developed against the FriendlyElect NanoPi-M4. I added rudimentary xHCI support to it (but it only works with USB2 devices or USB3 devices when isolating the USB3 pins, because I don't bring up the PHY) and enough ACPI to boot ESXi. Actually showed it running at the TechCon Expo in the Infrastructure Zone in the VMware booth.
The last thing I was working on (the firmware is a hobby really, but one I have very little time for) was HDMI support but it didn't seem to work (no valid HDMI signal... unclear if I am driving VOP or HDMI encoder correctly!).
Anyway - https://github.com/andreiw/rk3399-edk2 is the code, as-is. If you take this code, I do suggest doing the work in a way where it's upstreamed or upstreamable into edk2-platforms.
I definitely won't be able to commit to develop it for you. I can provide UEFI/ACPI guidance as appropriate, maybe do some commits that further my own goals, and even help bring you folks into Arm's efforts in supporting more "Edge hardware" under their "Project Cassini" (https://community.arm.com/developer/ip-p...f-the-edge, if that's interesting to you - or to Rockchip). Like I mentioned, I'd love myself to have a product-grade Rk3399-based platform for ESXi-Arm myself. I'm not a Rockchip expert myself and been lucky that Rockchip is the only company that actively releases their TRMs to general public.
So... who else could help here technically? I don't think there's a WoA community per se.
- Pete Batard, since it's his Tiano UEFI tree that I forked. Maybe he'll be interested. I CC'ed him.
- Rockchip? They ought to be interested in UEFI+ACPI firmware for their chips. Again, it's where the ecosystem is going for this class of chips anyway.
- Alexander Graf from Suse/U-boot? He added UEFI support to U-boot. So maybe you can get away with U-Boot instead of going to Tiano. Unfortunately there's still no ACPI support. I'm sure they were interested in adding support for booting Windows too, though.
- Ben (@imbushuo, https://www.imbushuo.net/) did all the amazing Qualcomm device support. Don't have his contacts beyond Twitter.
- Arm? Laptop aside, maybe they would like to invest into Rk3399 firmware as part of Project Cassini?
A
Quote:Hi Brent,
I'm afraid that just like Andrei, while I would really want to see
Windows 10 running on RK3399 boards, my time and probably my knowledge
of all the intrinsics required to produce a working UEFI firmware, are
too limited to see it as something I can be involved with at this stage.
Now, if you do happen to find an experienced group of developers willing
to invest the time and effort to produce a working firmware able to run
Windows or vanilla Linux distros (e.g. Debian ARM64) on RK3399, then I
would be happy to help with upstreaming effort into the official EDK2,
similarly to what I did with Andrei's RPI3 UEFI firmware. But I don't
think I'll have much scope to help with this endeavour beyond that.
The problem of course is that, unless you have a platform that is being
sold in large volume, such as the one seen with Raspberry Pi boards,
it's going to be difficult to find someone who has all of the expertise,
interest in the hardware, as well as free time, to complete such a
development.
Most likely, what may happen is that, just as I tried to pick the
initial UEFI pieces produced by Rockchip to play with it a little bit,
and then Andrei picked on that to add some more, you're going to have to
wait for a 3rd or 4th person to build on what we currently have in the
hope that they will get to finalize that work since most of the easily
identifiable people who might help probably have their hands full. Or as
Andrei pointed out, you can try to make a case to Rockchip that having a
RK3399 platform that runs a full Windows 10 could be a game changer,
though this might be a hard sale...
At any rate, I genuinely wish you all the luck in trying to get the
resources needed to complete a full RK3399 UEFI firmware port. Once
again, I'll be happy to help with the official upstreaming process if
you do manage to complete that. But that's about all I can see myself
being able to help with.
Regards,
/Pete
I do not think we have the basis ready for them to jump in?
I also contacted ARM. They want to have a call next week, to find out more about the details and whether it is UEFI or WoA that we/I want. However, since I do not know the details of this, I was wondering if it isn't better if they contact @Luke? I have the feeling this is getting a bit above my head Maybe I also just don't know what they expect.
Great job getting this rolling. Sure, I can join in on a call (granted its not scheduled for middle of the night for me), but I am afraid that my technical skills are that of a baboon with a wrench. In other words, I think that you'd probably want someone like @ Mrfixit2001, or @ xalius or @ ayufan on the call too. PM me in Discord or on Telegram please? (IRC too - but there I can accidentally miss your PM).
Further clarification on the 'vanilla' Linux:
Quote:Hi Brent,
Yeah, I mean that you know you have a stable UEFI firmware when you can
take an ISO like Debian ARM64 or Ubuntu ARM64 (or Manjaro ARM64 if they
get to that stage) and get it to install in a relatively generic manner,
like what's described in
https://github.com/tianocore/edk2-platfo...Systems.md
for instance.
In short, you want to get to an installation experience that is as close
as possible as the one you'd get on a UEFI x86 PC (so that usually means
the EFI versions of GRUB or Syslinux should work), and remove all
reliance on any U-boot or custom boot environment.
Now of course, there are always some quirks and gotchas to doing that,
the first one being that the maintainers of these vanilla distros must
user a kernel and modules that can effectively support your hardware (as
opposed to relying on something like Armbian, where images are tailored
for specific hardware), and the installer scripts may in some case need
some platform awareness. But if you get to the point where it becomes
relatively easy to point a non tech-savvy user to a set of instructions
that remains close to "pick this vanilla ISO, extract it to a FAT32
formatted flash based media, plug it to your RK3399 platform and follow
the installation prompts", and you're not relying on anything but the
UEFI firmware to be able to accomplish that, then your UEFI firmware can
be considered mature enough for official EDK2 integration.
Regards,
/Pete
I again do not think that is something we have right now. The closest we have is the Manjaro mainline kernel, but that still requires custom packages, so does not qualify I think?
as a quick question, does this mean there is a BSP already for the pine board compatible with the IoT Core Arm architecture?
|
