Skip to content
This repository has been archived by the owner on Mar 11, 2021. It is now read-only.

Add USB and Ethernet drivers to support the Raspberry Pi 4 #64

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

alotipac
Copy link

@alotipac alotipac commented Aug 4, 2020

These commits to support the Raspberry Pi 4 add a filter driver that enables the USB 3 controller with RAM above 3 GB and a driver for the Ethernet controller, which partially resolves #55.

@ghost
Copy link

ghost commented Aug 4, 2020

CLA assistant check
All CLA requirements met.

@worproject
Copy link

Genet works wonderfully. Thanks for the great work!

We've also tested the USB filter driver and it sets the 32-bit accesses flag correctly, but removing the 3 GB limit leads to non-working USB ports on Windows 10 ARM64. Any clues on that?

@alotipac
Copy link
Author

Try disabling fast startup:

"HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power"
  DWORD HiberbootEnabled = 0

@NiQ1
Copy link

NiQ1 commented Aug 20, 2020

Genet works wonderfully. Thanks for the great work!

We've also tested the USB filter driver and it sets the 32-bit accesses flag correctly, but removing the 3 GB limit leads to non-working USB ports on Windows 10 ARM64. Any clues on that?

Seems that if you have patched USBXHCI.SYS it'll break USB (no matter how much RAM) - After installing the driver I needed to revert back to the original USBXHCI.SYS.

@pbatard
Copy link

pbatard commented Aug 20, 2020

Seems that if you have patched USBXHCI.SYS it'll break USB (no matter how much RAM) - After installing the driver I needed to revert back to the original USBXHCI.SYS.

Yes, that's intentional. The patch values I provided for winpatch, that everybody seems to be using, revert the 32 vs 64-bit access logic. I did that so that, if Microsoft ever patched the driver to use 32-bit access on RPi4 with an insider release, people would complain that they couldn't boot any more, and I'd know that something had changed...

So, if you do apply the HKLM\System\CurrentControlSet\Control\Compatibility\Device\USBXHCI:ACPI!VEN_PNP&DEV_0D10 USBXHCI registry key patch, that sets accesses to 32-bit, as per @alotipac's driver (Very nice work figuring that we could set the flag there!), then the patch will invert that logic to force 64-bit access and you'll be back to square one.

In other words, you should not use both a patched USBXHCI.SYS and the USBXHCI registry flags override. Instead you should only use the registry flags, as it's the much better solution (since it's resilient to a Microsoft driver update and doesn't require breaking the driver signature).

@pbatard
Copy link

pbatard commented Aug 20, 2020

Try disabling fast startup:

"HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power"
  DWORD HiberbootEnabled = 0

That was it. 😄

@alotipac, you are awesome. I don't think we can ever thank you enough for your contributions!!

@NiQ1
Copy link

NiQ1 commented Aug 20, 2020

Try disabling fast startup:

"HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power"
  DWORD HiberbootEnabled = 0

That was it. 😄

@alotipac, you are awesome. I don't think we can ever thank you enough for your contributions!!

Works even without it. Just need to revert USBXHCI.SYS and remove the 3GB restriction in the BIOS.

@pbatard
Copy link

pbatard commented Aug 20, 2020

Works even without it. Just need to revert USBXHCI.SYS and remove the 3GB restriction in the BIOS.

Didn't work for me when I tested it. But I did boot Windows with 3 GB first and then removed the limit, so fast startup was active, as opposed to disabling on first install.

I'm just going to add that this will probably be how most people do it, as the UEFI firmware has to have the 3 GB limit on by default for most OSes. But it shouldn't be too difficult to have the image application utility, or even the driver itself, take care of that registry key...

@NiQ1
Copy link

NiQ1 commented Aug 20, 2020

Works even without it. Just need to revert USBXHCI.SYS and remove the 3GB restriction in the BIOS.

Didn't work for me when I tested it. But I did boot Windows with 3 GB first and then removed the limit, so fast startup was active, as opposed to disabling on first install.

I'm just going to add that this will probably be how most people do it, as the UEFI firmware has to have the 3 GB limit on by default for most OSes. But it shouldn't be too difficult to have the image application utility, or even the driver itself, take care of that registry key...

So did I...
One thing that I noticed is that the Windows 10 splash screen disappears. It appears to hang on the UEFI boot screen (the PI logo) and it takes a couple of mins. The USB indeed stops working for a short while while Windows starts but by the time it reaches the login screen it works again.

@NiQ1
Copy link

NiQ1 commented Aug 20, 2020

These commits to support the Raspberry Pi 4 add a filter driver that enables the USB 3 controller with RAM above 3 GB and a driver for the Ethernet controller, which partially resolves #55.

Mind if I post binaries?

@pbatard
Copy link

pbatard commented Aug 20, 2020

I already posted some in the windows-on-arm discord channel. These are drivers that I signed using my Authenticode credentials (so that, even if this isn't enough to get the driver accepted without disabling test signing, we get better accountability and provenance than a self-signed cert) and that also adds the following to the rpiuxflt.inf to disable fast boot:

HKLM,System\CurrentControlSet\Control\Session Manager\Power,\
    HiberbootEnabled,0x10001,0x00000000

You can find a built of these drivers in my cloned version of rpi-iotcore, that has the above patches applied along with the additional changes I applied to produce the binaries.

The binary downloads can be obtained here or through the links below:

@QuimoDrivers
Copy link

I already posted some in the windows-on-arm discord channel. These are drivers that I signed using my Authenticode credentials (so that, even if this isn't enough to get the driver accepted without disabling test signing, we get better accountability and provenance than a self-signed cert) and that also adds the following to the rpiuxflt.inf to disable fast boot:


HKLM,System\CurrentControlSet\Control\Session Manager\Power,\

    HiberbootEnabled,0x10001,0x00000000

I'm attaching these drivers below:

To be completely open, I will also post a link to my rpi-iotcore clone, that contains all the changes I applied to produce the binaries above. I'll edit this post once I have done so.

What is the first driver linked used for?

@NiQ1
Copy link

NiQ1 commented Aug 20, 2020

I already posted some in the windows-on-arm discord channel. These are drivers that I signed using my Authenticode credentials (so that, even if this isn't enough to get the driver accepted without disabling test signing, we get better accountability and provenance than a self-signed cert) and that also adds the following to the rpiuxflt.inf to disable fast boot:


HKLM,System\CurrentControlSet\Control\Session Manager\Power,\

    HiberbootEnabled,0x10001,0x00000000

I'm attaching these drivers below:

To be completely open, I will also post a link to my rpi-iotcore clone, that contains all the changes I applied to produce the binaries above. I'll edit this post once I have done so.

What is the first driver linked used for?

Allows you to use more than 3GB of RAM without breaking USB.

@QuimoDrivers
Copy link

Hey guys, is there any GPU Drivers for RPI 4

@worproject
Copy link

@alotipac have you tried booting from USB with the Use32BitAccesses registry flag set? This doesn't seem to work on all boards.
Patching the XilRegister_ReadULong64/WriteULong64 functions in the USBXHCI driver using winpatch or by hand does work fine.

@QuimoDrivers wrong place, but the answer is no.

@QuimoDrivers
Copy link

Is there any audio drivers for rpi4 in the works. If so can i have a download link to develop on it

@NiQ1
Copy link

NiQ1 commented Aug 21, 2020

Is there any audio drivers for rpi4 in the works. If so can i have a download link to develop on it

This is not a place to ask questions. This is for discussing the specific PR.
Someone on Discord said he wants to work on audio but I'm not sure if he's actually going to do it.

@Marcinoo97
Copy link

Marcinoo97 commented Aug 23, 2020

Genet driver is amazing however usb filter causes a lot of issues with stability and smoothness of the operating system. Many people reported that their usb audio devices no longer work and only 2 out of 700 people managed to boot from usb stick with filter driver enabled.

@pbatard
Copy link

pbatard commented Aug 23, 2020

One thing I'd like to know is how many of these 700 managed to boot with winpatch, because recent updates of Windows seems to have broken both. At least none of winpatch or the filter driver work for me when booting 19041.450 from USB, whereas any of these methods works when booting 19041.330.

In other words, if .450 broke USB boot elsewhere (as my testing seems to indicate) and you are asking 700 people who created recent 19041 image from uup whether they managed to boot from USB, and they also happen to be using the filter driver (because that's what's included as part of the default driver pack) you're gonna get 700 reports of "I wasn't able to boot", but that still doesn't mean that the filter driver is the issue unless those folks can also report that they did try to create a USB media using winpatch, without the filter driver, and that worked for them.

Again, as far as my testing shows, .330 boots fine from USB, be it with the filter driver or winpatch. But .450 doesn't boot at all from USB, be it with the filter driver or winpatch, which hints at all those boot breakage reports not having anything to do with the filter driver.

@NiQ1
Copy link

NiQ1 commented Aug 23, 2020

One thing I'd like to know is how many of these 700 managed to boot with winpatch, because recent updates of Windows seems to have broken both. At least none of winpatch or the filter driver work for me when booting 19041.450 from USB, whereas any of these methods works when booting 19041.330.

In other words, if .450 broke USB boot elsewhere (as my testing seems to indicate) and you are asking 700 people who created recent 19041 image from uup whether they managed to boot from USB, and they also happen to be using the filter driver (because that's what's included as part of the default driver pack) you're gonna get 700 reports of "I wasn't able to boot", but that still doesn't mean that the filter driver is the issue unless those folks can also report that they did try to create a USB media using winpatch, without the filter driver, and that worked for them.

Again, as far as my testing shows, .330 boots fine from USB, be it with the filter driver or winpatch. But .450 doesn't boot at all from USB, be it with the filter driver or winpatch, which hints at all those boot breakage reports not having anything to do with the filter driver.

Works for me on a 4GB model with this driver and latest updates.
The last update (Aug 2020) updated the USBXHCI.SYS driver so if using the winpatch approach it needs to be patched again but winpatch still works.

@pbatard
Copy link

pbatard commented Aug 23, 2020

Works for me on a 4GB model with this driver and latest updates.

Does it mean when creating a USB media from an install.wim or ISO you recently created from UUP?

Because if, on the other hand, you mean that you managed to update an existing working installation and it didn't break anything, then I got that too (i.e. I can get a working .330, booting from USB, and update it to .450 without breaking anything). But that still doesn't tell us if the .450 installation process from scratch is broken or not.

The last update (Aug 2020) updated the USBXHCI.SYS driver

Yes. That is why the filter driver approach is better. And I did test that using the .330 driver in a .450 installation from scratch didn't change anything (i.e. it still BSOD's during first boot), which further seems to indicate that the issues people encounter with booting recent Windows installs from USB are unlikely to have anything to do with the filter driver or USBXHCI.sys, as further evidenced by the fact that I have yet to manage to get a .450 installed from scratch to boot, regardless of the method used.

It may also very well be that the UUP scripts are broken...

Once you get it running, .450 seems to be fine regardless of whether you are using the filter driver and the updated version of USBXHCI.SYS. It's just getting it to boot from scratch that seems to be the issue. Thus, until someone can demonstrate otherwise (by showing for instance that winpatch works where the filter driver doesn't), I don't believe the USB boot issues have anything to do with the filter driver.

@pbatard
Copy link

pbatard commented Aug 23, 2020

Just recreated a .330 ISO from https://uupdump.ml and Feature update to Windows 10, version 2004 (19041.330) arm64 works fine with the filter driver including USB boot.

Just download that if you are having issues, and then use Windows Update to bring it up to date. Microsoft broke something between .330 and .450 so just don't use anything later than .330 until we have a clear idea what got broken.

The DMA adapter filter limited the USB host controller to a single
simultaneous bounce buffer, which prevented more than one device
using bulk transfers (such as storage devices or Bluetooth adapters)
from operating at the same time. This change allows for multiple
buffers. Only one buffer per concurrently active bulk transfer endpoint
should be needed.

Also switch asserts to be present in release builds.
@pbatard
Copy link

pbatard commented Aug 26, 2020

Updated the drivers from my fork with the latest patch and I also took this opportunity to add driver version + date (which should help making sure people can find out what drivers they actually installed).
You can download them from: https://github.com/pbatard/rpi-iotcore/releases/tag/rpi4-drivers-1.1

@NiQ1
Copy link

NiQ1 commented Sep 1, 2020

@alotipac
The latest version of the driver (multiple bounce buffers) completely broke USB to the point of requiring a complete wipe and reflash. Getting a code 43 error (port reset failed).
Even rolling back doesn't work -
* Installing the old INF back - Failed
* Removing the new version completely and installing the old one - Failed
* Removing every single trace of rpiuxflt from both file system and registry, re-patching USBXHCI.SYS with winpatch and re-enabling 3GB limit - Failed
No way of getting USB back up.

EDIT: I'll keep the broken installation for a few hours in case someone replies with more things to try. Tomorrow I'm wiping since I don't have a spare SD card.
EDIT 2: USB does work in safe mode.

SOLVED!
Seems that if you've ever patched USBXHCI.SYS with winpatch.exe Windows will think that the patched file is a newer version and will "upgrade" to it from a copy in DriverStore and/or WinSxS whenever you upgrade a USB-related driver, which breaks USB because the rpiuxflt driver expects the original USBXHCI.SYS.
Replace it back then delete the patched file from both DriverStore and WinSxS and it'll work. This problem will not happen if you directly installed rpiuxflt and have never used winpatch.
Tested version: 450

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update Board Support Package to support Raspberry Pi 4
6 participants