Open diydavindra opened 6 years ago
@falkor2k15 https://puu.sh/A9gWs/12b8c7eebc.png if you need an visual as to what i have.
@falkor2k15
RaspberryPiPkg has not been validated on the Pi3B+ and doesn’t suppport it.The distributed VC firmware is for the Pi3 only.
If you have a serial cable, I would like to see the log from running the DEBUG bits (not RELEASE). But please file an issue for the Pi3b+ so I keep track of it (not here).
OK thanks guys - I guess it's a B+ incompatibility then - as I just replicated the setup in Dave's pic. Well, if you guys can eventually get Windows 10 on ARM running in a useable state I'll happily downgrade to the Pi3 and even offer a donation (and encourage others) to support the work. To be honest though, I thought the next logical step for Andreiw, NT Authority and co. would be to get the KVM issues sorted out in Qemu ahead of this native Pi3 solution; that way, Windows 10 on ARM could boot up at near-native speeds (despite not being a bare-metal solution) on any ARM64 host/board (not just the Pi3).
The Pi efforts are going to be a bit of a science project, given the need to hot-patch Win10 Hal today just to boot. If you want something tangible, you could get https://store.hp.com/us/en/pdp/hp-envy-x2-12-e011nr?jumpid=cp_r12136_us/en/psg/envy_x2_qualcom/sticky-nav/buy-now (out of stock, again?) or the ASUS NovaGo whenever that comes out.
Alternatively, Windows has been demonstrated to run out of the box on some SBSA servers (scroll to 12:10 for Windows on the Ampere eMAG, https://youtu.be/RNzL9lFH_sA).
There is an ongoing UEFI port capable of running WoA on a $75 96board (Qualcomm 410c), that will be coming out soon, too: https://imbushuo.net/blog/archives/590
@falkor2k15, best way to support is to start working on building, packaging and validating the drivers (https://github.com/nta/dwusb, and https://github.com/ms-iot/bsp).
My previous experimental with DB410c has 4 cores {Parking Protocol Version = 0, GIC address set}, PSCI compliant bit set in FADT. Four cores brought up fine without problems. BCM2837/8 might be a weird one, since it doesn't have a GIC controller.
Windows starts at EL1 (Only EL0/1 can be accessed on Qualcomm devices, EL2/3 are Qualcomm's land).
That Nokia RX-130 is another weird device. It has PSCI compliant and HVC required bit (the HVC required bit actually confuses me, my initial attempt on 410c set it too, then I got INTERNAL_POWER_ERROR
. Removing that HVC bit makes everything fine), and Parking Protocol set to 1. MPPark is implemented in firmware. I am not sure if Windows uses PSCI or MPPark on RX-130 yet.
@imbushuo, how is the I/O looking on the 410c? Are these standard MMIO EHCI/SDHCI/... IP blocks, or do drivers need to be written to support current Win10 builds?
@andreiw Most drivers can be reused from Little Kernel.
I have a copy of Qualcomm BSP, my initial attempt reused it a lot (so I am running cleanup now, make sure related stuffs are replaced with open-source drivers).
Later attempts, including the one on retail Lumia 950 XL replaced them with drivers from Little Kernel. eMMC/UFS is standard MMIO. USB uses Synposys IP block too. Display is Qualcomm proprietary, but I can re-use FrameBuffer pointer from earlier stage bootloader.
There are two open source implementations of the USB controller driver, one from LK (slave mode), the other from U-Boot (host mode). EFIDroid project has done the ground work for us.
Drivers need to be written to support current Windows 10 builds. Device documentation and reference implementation (Linux though) is available.
Correction: APQ8016 (DB410c) uses ChipIdea USB 2.0 IP Blocks. Later models w/ USB 3.0 use Synposys USB IP Blocks.
Ok so finally got the serial adapter, and just when i thought i could have some fun i cant connect to the pi.
@daveb778 Did you enable debugging in the WinPE with bcdedit?
I did, uart is also enabled. maybe i have the pinout wrong? https://cdn.discordapp.com/attachments/99288948077002752/438376344384962560/IMG_20180424_123035.jpg
That looks wrong, but I don’t have a picture for you now (can post in the evening). Try flipping TX and RX pins.
The basic test is attaching PuTTY at 115200, and you should be able to interact with UEFI. the DEBUG build has more spew.
Ok i see stuff in putty after that so im guessing the bcd edit didnt work, tho it said successfully completed. Is there any other way of editing the bcd?
Can you post your exact commands and the results of “bcdedit /store path/to/bcd”?
Also remember to safely eject media to flush fs and block buffers...
A
24 апр. 2018 г., в 13:03, Davindra notifications@github.com написал(а):
Ok i see stuff in putty after that so im guessing the bcd edit didnt work, tho it said successfully completed. Is there any other way of editing the bcd?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Ok, i did it all again to be sure. Yea this is very strange, im not too sure why this isnt working.
Okay, keep PuTTY running and just boot Windows. You should see spew from the debugging stubs once Windows crashes.
A
24 апр. 2018 г., в 13:32, Davindra notifications@github.com написал(а):
Ok, i did it all again to be sure. Yea this is very strange, im not too sure why this isnt working.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
And you’re using the latest bits, right?
A
24 апр. 2018 г., в 13:32, Davindra notifications@github.com написал(а):
Ok, i did it all again to be sure. Yea this is very strange, im not too sure why this isnt working.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Everything i have is the latest version.
Ok just using putty it seems to hang here.
This is the Apr22nd build? Weird. What windows build?
A
24 апр. 2018 г., в 13:45, Davindra notifications@github.com написал(а):
Ok just using putty it seems to hang here.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
The windows build is 17125, ahhh i dun goofed. Its the Apr21 build i was using. Sorry about that, i am getting further now.
Yeah, now hit Ctrl-Alt-K, type in .reboot and wait...
A
24 апр. 2018 г., в 13:54, Davindra notifications@github.com написал(а):
The windows build is 17125, ahhh i dun goofed. Its the Apr21 build i was using. Sorry about that, i am getting further now.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Getting closer, Update: Got it booted.
SMP support is in. The issue was non-zero cntvoff_el2 on the APs. See https://github.com/andreiw/raspberry-pi3-atf/commit/3565e7390b6e67d8e589a8586f9bf527c980d214.
https://github.com/andreiw/RaspberryPiPkg/tree/master/Binary/prebuilt/2018Apr24-GCC49
Thats amazing!
Also did you get usb working? Cause i have no other idea how you'd type in that command to show the cpu.
I edited \Windows\system32\startnet.cmd inside \sources\boot.wim.
You can use 7zip to manipulate the wim file.
Didn’t touch the drivers.
A
25 апр. 2018 г., в 0:37, Davindra notifications@github.com написал(а):
Also did you get usb working? Cause i have no other idea how you'd type in that command to show the cpu.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Ahh i see
I am getting errors when I compile the USB controller driver. Do you upload for me ?
I'm also getting endless errors when compiling.
Okay, this is a little raw in terms of code, but I wanted to share this 😀
The image below will allow you to boot WoA build 17125 without a debugger. No dongles.
I made the observation that only the HAL was making SMC calls to PSCI (implemented by ATF). It was the HAL that I needed to patch, too. And the PSCI calls come much earlier than HalpInterruptRegisterController+0x6c
. The function that does the SMC calls is HalpPowerInvokeSmc
, and inside the ATF SMC handler, ELR_EL3 corresponds to HalpPowerInvokeSmc+0xc
. The distance between these two is 0x7680.
So all we have to do is add 0x7680 to the ELR_EL3 value, translate the resulting non-secure VA to a physical address corresponding to HalpInterruptRegisterController+0x6c
, and patch to convert the bls hal!HalpInterruptRegisterController+0x78
into an unconditional branch.
...and we don't need to care about ASLR, locating the NT kernel base, module list, etc. Very simple.
@XperfectTR @thchi12 sorry dudes, haven't touched the USB driver yet, no idea.
OMG!! So we only need to solve the driver problems? The bsp provided by ms-iot seems to support ARM only(arm64 available for uart
@thchi12 well, more or less. I still need to refine, clean up and push the "boot kit" code into the https://github.com/andreiw/raspberry-pi3-atf repo , and it will need to be continuously updated as new builds come out. And I'm kind of hoping MS won't further cripple Win 10 on the Pi in other random ways... Without the serial umbilical cord it boots reasonably fast, much faster than it takes openSUSE Leap to show me a desktop. Ha ha. But this is a WinPE image... If we get any storage going we could try a real install 🤣.
The BSP is in source form, and there's no reason (beyond the usual massaging) these drivers shouldn't build for or run on arm64 (but I haven't tried). E.g. https://github.com/ms-iot/bsp/tree/master/drivers/sd/bcm2836/bcm2836sdhc.
Maybe we can try the usb driver and start a full system on a usb mass storage device
Well I can compile the debug usb driver but maybe certification problems.Still failing to build as release
Well it seems that I should compile sdhc...USB driver added but windows doesn't like it(0x7B)
@thchi12 upload the driver. i try in a different way.
look https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/drvload-command-line-options
My friends built the driver in release and I'm now facing a BSOD with error:NTFS_FILE_SYSTEM
It looks like you might need to end up including a SDC2
node with the correct child methods inside your ACPI DSDT table as well as configuring the pin configuration to make the microSD port on the board connect to the Broadcom SD host controller.
Refer to: https://github.com/ms-iot/RPi-UEFI/blob/ms-iot/Pi3BoardPkg/AcpiTables/Sdhc.asl as well as https://github.com/ms-iot/bsp/tree/master/drivers/sd/bcm2836/rpisdhc for the correct driver used (as the .inf file matches the ACPI\SDHST
node).
Bytepatching inside ATF with hardcoded offsets may not necessarily be the best idea as well, perhaps fuzzy byte pattern matching might be a better idea.
@thchi12 I think you might need to disable driver signature check in bcd tho im not too sure how you'd do that. The BSOD seems like something else is wrong tho.
@winocm Thanks - it’s missing for a reason, as it wouldn’t work out of the box without further UEFI changes. UEFI uses the Arasan controller today (mostly because that was the one pinmuxed by the VC firmware). I’ll probably go for the Arasan controller driver in Win10, if I get that far, since I’ve already sunk the time to debug through the abominable SDHCI misimplementation that Arasan put together ;-(. When/if I get to drivers, it will be USB first.
A
25 апр. 2018 г., в 9:22, Sarah Purohit notifications@github.com написал(а):
It looks like you might need to end up including a SDC2 node with the correct child methods inside your ACPI DSDT table as well as configuring the pin configuration to make the microSD port on the board connect to the Broadcom SD host controller.
Refer to: https://github.com/ms-iot/RPi-UEFI/blob/ms-iot/Pi3BoardPkg/AcpiTables/Sdhc.asl as well as https://github.com/ms-iot/bsp/tree/master/drivers/sd/bcm2836/rpisdhc for the correct driver used (as the .inf file matches the ACPI\SDHST node).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
@thchi12 bcdedit /store path\to\store \set {default} testsigning on
?
Edited: nevermind, I didn't see the 0x7B. Are you testing this with WinPE or an installer image?
@winocm the ATF HAL patcher is a really raw PoC now... thanks, something that can automatically adapt to code movement across HAL builds would be optimal.
Excellent progress!!! Are you able to get the explorer start menu and taskbar to show yet and work file explorer? Would be a nice to see a video of this booting up.
@falkor2k15 this is all done so far with a WinPE build, no start menu and no explorer AFAIK.
A
25 апр. 2018 г., в 15:06, falkor2k15 notifications@github.com написал(а):
Excellent progress!!! Are you able to get the explorer start menu and taskbar to show yet and work file explorer? Would be a nice to see a video of this booting up.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
@falkor2k15 This is only windows pe, no start menu or desktop. I'll upload a video for you in a bit, but there isnt any usb drivers yet so that would be a problem to get to a desktop.
@falkor2k15 https://www.youtube.com/watch?v=B-aiiDCwjUk Its just like booting any other os on the pi, but heres a quick little video showing it booting.
I was using a complete image.After setting testsigning on and no integrity checks 0x7B disappear,but I'm facing several different BSoD and it seems sth. is wrong with the USB driver.
So i've gotten pretty close to getting windows 10 arm to boot. But for some reason after selecting the boot device it wont no longer detect the keyboard, when the press any key to continue prompt arrives. The numlock light will turn on but no matter what button i press nothing happens. Also since it doesnt detect a keyboard input it will go back to the last screen and the system seems to lock up at that point.