The MEGA Windows on Arm thread about raspberrypipkg HOT 2102 OPEN

Folks, I've updated the readme.md file with the steps required to build arm64 WinPE USB media. You should be able to follow them provided you have a Windows 10 machine (any will do, x86, amd64 or arm64).

Also, see https://github.com/andreiw/RaspberryPiPkg/tree/master/Binary/prebuilt/2018Apr21-GCC49, which should make it more obvious what is happening. See screenshot. You should be able to repeat my "success" (for lack of a better term, given that we're crashing somewhere in NT after UEFI exits).

Since the current version (Apr 21st) and latest WoA WinPE bits seem to act much more reasonably than this ticket implies, I'm closing it as resolved.

from raspberrypipkg.

OK, I pushed the local working state of my USB driver to nta/dwusb.

As to patching the HAL at runtime, it should be noted that winload.efi will check both the PE checksum as well as a digital signature at load-time, so if intercepting FS requests, this file should be patched as well. It does appear such checks aren't made if boot debugging is enabled, however, but that'd not get rid of the need for a live serial connection.

from raspberrypipkg.

I'll see if I can make any progress on SMP.

It would be nice to figure out where the MCCI (https://twitter.com/NTAuthority/status/957886027594641409) USB driver for DWC_OTC can be found.

The rest of the RPi3 drivers are open source and could be hypothetically build with the EWDK (https://github.com/ms-iot/bsp/tree/master/drivers) - untried, but it seems like @NTAUTHORITY built some.

from raspberrypipkg.

Guys, take a look at https://github.com/andreiw/RaspberryPiPkg/tree/master/Binary/prebuilt/2018Apr22-GCC49 and the latest notes in readme.md. Everything you need to repeat is in there.

I can get WinPE booting. If it wasn't for https://twitter.com/ntauthority 's helpful hint, wouldn't be anywhere close.

from raspberrypipkg.

The original USB driver was built for ARM32 only and therefore wouldn't work on ARMv8 Windows, I should probably open-source my hacky attempt at an UCX-based USB driver since I've not had time to work on it for a while now.

Windows Phone devices used a Synopsys DesignWare USB controller as well, however this was the USB3 variant, which is pretty much distinct from the USB2 one used by Broadcom.

Also, yeah, I've noticed that the current SD UEFI driver is slow when booting Windows from the SD card, other than that, wonderful work on the project in general, @andreiw. 🙂

from raspberrypipkg.

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.

RPI_EFI_WoA.FD.zip

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.

from raspberrypipkg.

Do me a favor and repeat your experiment with the input being done over the serial input instead of USB. I bet you’ll discover similar behavior.

Actually, please send me a serial log of your experiments produced by a debug build of the UEFI firmware. That should help immensly.

I’ve seen something similar with winload.efi - it draws the pretty “uh-oh” blue screen, but the keys to reboot or exit to firmware don’t work - almost as if the code is waiting for a debugger or if interrupts are disabled. With a debug edk2 build I saw periodic UEFI messages stop printing as well.

from raspberrypipkg.

@falkor2k15 https://github.com/andreiw/RaspberryPiPkg/blob/master/readme.md#64-bit-windows-on-arm-17125rs4_release_prs180315-1454 has the exact steps you need to follow.

from raspberrypipkg.

@falkor2k15

Just to clarify, this has nothing to do with virtualization or KVM. RaspberryPiPkg is UEFI firmware for the bare metal Pi. Traditionally, Pi deployments either use no Arm firmware (Raspbian) or U-boot (openSuse or FreeBSD). RaspberryPiPkg allows booting 64-bit Arm operating systems that expect UEFI, such as FreeBSD, various flavors of Linux and (to a degree now) WoA.

Again, this specific thread documents getting Windows on Arm running natively on the Pi. No virtualization - Windows is started in EL2 (hypervisor privilege) and puts itself into EL1 (kernel privilege).

from raspberrypipkg.

@falkor2k15

Copy https://github.com/andreiw/RaspberryPiPkg/tree/master/Binary/prebuilt/2018Apr22-GCC49/RELEASE to an SD card and you’re off to the races.

from raspberrypipkg.

Oh wow that time difference, Would it be possible to add a RTC to the pi or just emulating one would probably be easier. After a some googling i did find that there is addon boards that can add a RTC tho im not sure of the possibility on how it would talk to the UEFI or WoA
https://www.adafruit.com/product/3386

from raspberrypipkg.

@falkor2k15

You can use a real ISO if you have one. I don’t. I can legally get the ADK (and you can, too), which lets me create a WinPE image that doesn’t need any I/O facilities to boot, it’s a ramdisk. Remember, that Windows ISO you have actually lacks drivers for the Pi, so by itself it’s not a great vehicle for developing Pi support.

To recap - no, you won’t be able to boot a stock ISO of Windows. Eventually, you may be able to boot an ISO that has the relevant drivers slipstreamed.

from raspberrypipkg.

SMP support is in. The issue was non-zero cntvoff_el2 on the APs. See andreiw/raspberry-pi3-atf@3565e73.

https://github.com/andreiw/RaspberryPiPkg/tree/master/Binary/prebuilt/2018Apr24-GCC49

from raspberrypipkg.

I've also tried two different keyboards both seem to not have an effect.

from raspberrypipkg.

You can try applying the wim file manually,make two partitions on your sdcard or USB,one FAT and one NTFS,then use dism to apply the image and bcdboot to create boot files.

from raspberrypipkg.

AFAIK,using the latest firmware Windows still hang at the boot screen,there seems no sign of loading and no 0xc0000225

from raspberrypipkg.

Sadly i don't have a serial cable to hook up to the pi, tho im not too sure how to communicate with it that way my guess is a serial to usb and putty on my pc. I've seen people posting images of the 0xc0000225 blue screen and i have no idea how they are even getting that far.

from raspberrypipkg.

Juat as I said,apply the install.wim manually

from raspberrypipkg.

Wow you guys got pretty far, I'm gonna try this in a bit and see what happens.

from raspberrypipkg.

wow That's amazing!
Is it possible to use PSCI to get SMP?WOA needs either mppp or psci to get multicore.
According to https://zhuanlan.zhihu.com/p/34572676
Windows has built in support for BCM interrupts,and what's the problem that prevents windows from starting up?

from raspberrypipkg.

This firmware already exposes PSCI support (go boot Linux and see ;-)), but the ACPI tables are as-is from MS-IoT and thus still report MPPP and no PSCI in FADT.

from raspberrypipkg.

In the earlier versions there were acpi tables for psci ,I wonder whether adding only dsdt ,csrt,dbg2 could help or not.

from raspberrypipkg.

@thchi12, nope, unrelated.

from raspberrypipkg.

As far as RPi3 support there appears to be a check in Hal validating PIC is not a BCM PIC. That’s why you need a debugger attached to patch out the ‘bls’ following the subtraction and compare.

from raspberrypipkg.

Would it be possible to use the usb driver from the windows IoT? Cause im trying to get my hands on the file for it.

from raspberrypipkg.

I don't think arm32 drivers can be used on arm64@daveb778

from raspberrypipkg.

@thchi12 Good point i didnt think that through.

from raspberrypipkg.

You need a 64-bit driver. IoT core is 32-bit. Hypothetically, if I understood @NTAUTHORITY correctly, the driver might have shipped as part of the NT-based 64-bit Wndows Mobile. I don’t know much about the later, in terms of which version first had AArch64 support (8.1 or 10...).

from raspberrypipkg.

@andreiw I see, i guess the does beg the question how do we get hold of it.

from raspberrypipkg.

It seems that rx-130 phones may have win10m arm64

from raspberrypipkg.

Oh, also trying to make the pe disk but i keep running into errors. https://puu.sh/A8iYa/2f307aa6a4.png

from raspberrypipkg.

Well you can try to grab uup and make an installtion media,keeping only the efi and boot.wim under sources

from raspberrypipkg.

Nvm just tried a smaller sdcard that did the trick.

from raspberrypipkg.

http://tieba.baidu.com/p/5650553455?share=9105&fr=share&see_lz=0&sfc=copy&client_type=2&client_version=9.4.8.4&st=1524405579&unique=17AB6B5F22E960726FBC25BC1894B03E
Here's my only known win10m aarch64 .(Don't worry as English translation is done below.I don't know whether it helps or not

from raspberrypipkg.

I dont know if we can even get the drivers from the backup. Also i just placed an order for a serial adapter so that should be a big help.

from raspberrypipkg.

Yeah you pretty much need the serial adapter today to have that windbg connection, until I figure out how to hot-patch the Hal... That’s probably where most of my current interest around WoA, after I resolve the PSCI issue. So if someone wants to focus on locating and validating the USB controller driver (https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-and-remove-drivers-to-an-offline-windows-image), that would be fantastic.

from raspberrypipkg.

@daveb778 until I add high-speed support to the SD host controller UEFI driver, I recommend you use USB keys for your OSes (Linux, FreeBSD, WoA), unless you really like waiting. USB is much faster. Your SD card should pretty much just contain UEFI.

from raspberrypipkg.

@andreiw Ahh kk, i've been mostly doing just this. But yea im basically stuck waiting for a serial adapter from amazon for now. Also im not too sure how to track down the usb driver, ive been looking with no luck so far.

from raspberrypipkg.

@nta - wow, I feel your pain...having spent a few months off-and-on rewriting the crappy UEFI DwUsbHostDxe driver I found. Kudos for diving in and writing your own! My UEFI driver is wrong in principle (I still have no idea how this hardware is supposed to do periodic transfers), and CBI devices are still a mystery to me. It's frustrating that there are still no reasonable docs on the chip (the best I could find is https://www.quicklogic.com/assets/pdf/data-sheets/QL-Hi-Speed-USB-2.0-OTG-Controller-Data-Sheet.pdf). Maybe I should have just taken the BSD one as a base...

As far as patching the HAL I've been sort of eyeing dreamboot (https://github.com/quarkslab/dreamboot) and UEFI-Bootkit (https://github.com/dude719/UEFI-Bootkit).

Idea 1: boot WoA in EL1. Use a passthru "hypervisor" and stage 2 mappings to ensure patched EL1 VPN are either executable and not readable (then they contain patched code) or readable and XN (when code tries measuring itself we can feed it the original copy). This avoids the need to figure out how to disable patch guard.

Idea 2: rely on an EL3 agent in ATF (via an SMC) to manipulate VAs. Still have to disable patch guard, but because EL3 can use AT to translate EL1 VPNs to MPNs and access directly, we don't need to worry about non-writable mappings.

Of course, maybe some kind soul in Microsoft could just fix the check ;-D?

from raspberrypipkg.

So the good news is that I have PSCI working in WoA, with all 4 cores online.

The bad news is that I have a crash. Lack of checked kernel is making this hard (I didn't find checked kernel/hal in either the 17125 EWDK or 17125 WDK), so the names of the functions in the call stack don't mean anything - they were just the closest symbol ;-(.

Bug check is 0x6b (PROCESS1_INITIALIZATION_FAILED). https://neosmart.net/wiki/0x0000006b/ implies this has something to do with ntdll.dll.

BUGCHECK_P1: ffffffffc0000605 (NTSTATUS??? -> STATUS_IMAGE_CERT_EXPIRED???)
BUGCHECK_P2: 3
BUGCHECK_P3: 0
BUGCHECK_P4: 0

I don't really understand what booting with more than 1 CPU has to do with it, though... And this is a WinPE system where everything is in RAM. Really - if I set the "Processor Enabled" flag to 0 for the other 3 GIC entries in Madt.aslc, the system boots. The must be some state between the the BSP and APs that is not identical, but I haven't yet sorted out what that could be. ATF handles all the dirty work of EL3 initialization (and it was good enough for Linux), and even the timer is configured as expected (19.2Mhz).

from raspberrypipkg.

Maybe there's still something needed to do with the bcm interrupt?

from raspberrypipkg.

Hmm, actually the TARGET_TIME is conspicuous. RPi3 has no RTC, so it is being faked out.

The OSBUILD_TIMESTAMP is 2018-03-15 21:28:59.

In a "good" boot TARGET_TIME was 2018-03-16T01:35:12. In the 0x6b case, the TARGET_TIME is 2052-04-16T16:31:52. That does explain the cert failure...

from raspberrypipkg.

Hmmm...
How about 17128+?Fetching uup files then converting into an iso and get the boot.wim.
17128+ has no timebomb

from raspberrypipkg.

from raspberrypipkg.

BTW I'm wondering how the time goes to 2052,I tried 14282 before this thread opened and it didn't show me the digital siganature problem.And the bomb for it should before 2016

from raspberrypipkg.

Before 2016 July

from raspberrypipkg.

I’ve spent a few hours “fixing” the UEFI RT RTC implementation, before realizing it’s not actually used by the Hal. HalpQueryAcpiRealTimeClock returns 0xc0000002 as it should (no TAD device in DSDT), so this narrows the focus down to the Arm generic timer on secondaries. It’s unfortunate that the ‘rM’ command doesn’t dump any of the CNT MSRs with any mask (and the rdmsr command for Arm64 windbg is undocumented), so I can’t validate that register state is sane across all cores yet.

from raspberrypipkg.

How can I download and add a UEFI partition to my external hard drive that will allow Windows 10 on ARM ISO to boot up on a Raspberry Pi 3 B+? Has anyone managed to get KVM to work on qemu-system-aarch64 with graphics output at the same time?

from raspberrypipkg.

@falkor2k15 Are you asking about Windows on Arm in a KVM VM? If so, https://withinrafael.com/2018/02/11/boot-arm64-builds-of-windows-10-in-qemu/.

from raspberrypipkg.

Wow, excellent work and nice write-up!

Wish I was more technical and less of a noob to understand... So the 64-bit Windows on ARM steps depend on first having the UEFI partition for Pi3 that you can then use to boot any ARM64 OSs, including Linux? Not sure why WinPE comes into it when we can just grab a Windows 10 on ARM ISO as per Rafael's guide? I must be missing a concept there. Most importantly, how can we get the UEFI partition on the Pi3?
The link within "As a starting point, take the latest prebuilt image directories and copy to empty boot media" is currently broken. There is mention of EFI.fd files, which I am more familiar in a Qemu context, but the RPi3 supports only the following filetypes, including DTB files:
https://s9.postimg.cc/kt2y2e3y7/firmware.png

Rafael's guide can run Windows 10 on ARM using Qemu, but only with KVM disabled (due to a problem with emulating the VGA framebuffer and a lack of VirtIO and other graphics drivers), so it runs extremely slow. This is using any ARM64 Host with a KVM-enabled kernel, such as Gentoo built by sakaki.

from raspberrypipkg.

I created a bootable USB from a working IMG file (compatible with Pi3 & Pi3b+). I then replaced the boot files on the small FAT32 boot partition with the ones from here:
https://github.com/andreiw/RaspberryPiPkg/tree/master/Binary/prebuilt/2018Apr22-GCC49/RELEASE

I began by copying/replacing:
config.txt
RPI_EFI.fd
That got me as far as the rainbow screen, but when I replaced the rest of the files my Pi3 fails to display anything:
start.elf
fixup.dat
bootcode.bin

Could it be that those 3 are incompatible with my Pi3 B+ model board?

from raspberrypipkg.

I wouldnt know to be honest but i found the best thing is to remove everything from that directory and transfer all the uefi files in. I found that worked for me but im not on a b+.

from raspberrypipkg.

@falkor2k15 https://puu.sh/A9gWs/12b8c7eebc.png if you need an visual as to what i have.

from raspberrypipkg.

@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).

from raspberrypipkg.

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).

from raspberrypipkg.

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

from raspberrypipkg.

@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).

from raspberrypipkg.

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.

from raspberrypipkg.

@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?

from raspberrypipkg.

@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.

from raspberrypipkg.

Correction: APQ8016 (DB410c) uses ChipIdea USB 2.0 IP Blocks. Later models w/ USB 3.0 use Synposys USB IP Blocks.

from raspberrypipkg.

Ok so finally got the serial adapter, and just when i thought i could have some fun i cant connect to the pi.

from raspberrypipkg.

@daveb778 Did you enable debugging in the WinPE with bcdedit?

from raspberrypipkg.

I did, uart is also enabled. maybe i have the pinout wrong?
https://cdn.discordapp.com/attachments/99288948077002752/438376344384962560/IMG_20180424_123035.jpg

from raspberrypipkg.

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.

from raspberrypipkg.

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?

from raspberrypipkg.

from raspberrypipkg.

Ok, i did it all again to be sure. Yea this is very strange, im not too sure why this isnt working.

from raspberrypipkg.

from raspberrypipkg.

from raspberrypipkg.

Everything i have is the latest version.

from raspberrypipkg.

Ok just using putty it seems to hang here.

from raspberrypipkg.

from raspberrypipkg.

The windows build is 17125, ahhh i dun goofed. Its the Apr21 build i was using. Sorry about that, i am getting further now.

from raspberrypipkg.

from raspberrypipkg.

Getting closer,
Update: Got it booted.

from raspberrypipkg.

Thats amazing!

from raspberrypipkg.

Also did you get usb working? Cause i have no other idea how you'd type in that command to show the cpu.

from raspberrypipkg.

from raspberrypipkg.

Ahh i see

from raspberrypipkg.

I am getting errors when I compile the USB controller driver. Do you upload for me ?

from raspberrypipkg.

I'm also getting endless errors when compiling.

from raspberrypipkg.

@XperfectTR @thchi12 sorry dudes, haven't touched the USB driver yet, no idea.

from raspberrypipkg.

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

from raspberrypipkg.

@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.

from raspberrypipkg.

Maybe we can try the usb driver and start a full system on a usb mass storage device

from raspberrypipkg.

Well I can compile the debug usb driver but maybe certification problems.Still failing to build as release

from raspberrypipkg.

Well it seems that I should compile sdhc...USB driver added but windows
doesn't like it(0x7B)

from raspberrypipkg.

@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

from raspberrypipkg.

My friends built the driver in release and I'm now facing a BSOD with error:NTFS_FILE_SYSTEM

from raspberrypipkg.

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.

from raspberrypipkg.

@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.

from raspberrypipkg.

from raspberrypipkg.

@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?

from raspberrypipkg.

@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.

from raspberrypipkg.

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.

from raspberrypipkg.

from raspberrypipkg.

@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.

from raspberrypipkg.

@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.

from raspberrypipkg.

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.

from raspberrypipkg.