Latest status for the MCCI USB drivers for Windows 10 ARM64 on the Raspberry Pi.
[Done] Get the drivers to build and run on Win10 PE with Alexei’s EFI BIOS.
[Done] Check the code back into MCCI’s source control.
[Done] Create a website for software distribution (not just for MCCI’s stuff, but we certainly need it): pi64.win.
[Done] Create a forum for discussions that is a little more flexible than github issues. (You’re reading it.)
[Done] Get MCCI release engineering set up to build the ARM64 drivers with VS2017 and the Win10 WDK.
[Done] fix INF signability problem found by latest InfVerif.
[Done] MCCI release engineering to use the automation to sign the drivers.
[Done] Test and confirm that we’ve not broken anything.
[Done] Adapt the click-through agreement; MCCI operations found a suitable starting point in the files. First release will be for evaluation only, as it’s not clear how anyone would get a commercial license from Microsoft for the core operating system.
[Done] Create an MCCI (not Microsoft) “brand” for these drivers. Build and review.
[Done] Create a release package and post.
[Done] Build with release version and without expiration date
[Done] Sign drivers
[Done] Pass release drivers to Terry
[Done] Integrate with Innosoft installer and license for release.
[Done] Build an Innosoft installer with RC drivers, and test (to cut down response time when I have drivers in hand).
[Done] We’ll handle bug reports and escalations via discourse for non-commercial users; for commercial users, we have an existing support portal, portal.mcci.com, which will suffice.
We sorted out MCCI release engienering’s build problems and we successfully built drivers on a clean system. (Lots of minor issues, but most important, we found that I’d forgotten to update the “packing list” that tells the automation the files that are part of the source tree. This is why we insist on doing release builds rather than releasing from developer sandboxes.)
Next step (maybe later today) is to put the drivers into a known-good SD card image in place of the ones that I did in Boston, and make sure the system boots up.
Logistics: license agreement has been dug out of our files, needs minor revisions, but should be easy. These drivers will be free for non-commercial use.
With luck, we might get through all the release gates by tomorrow evening
We were very much hoping to get something posted before the weekend… but the WDK gods did not cooperate. For some reason, the release engineering system found an INF problem with signability – no idea why my system accepted the INFs, but they’re clearly incorrect. I have older inftest exes on my system, and my guess is that I was picking up an old exe.
Our INF files are generated by a set of programs to make it easier to maintain brands. I’ve found the trouble area and I have a patch I’m about to test. But it looks like it will be a few more days. With luck, we’ll at least have passing INF files today.
I’ve pushed my changes. It worked for me and generates correct-looking INF files. I’m not sure Chris Brown (our release engineer) is online this weekend, but if so, I’ll post an update once he’s tested. Otherwise it will slip to Monday…
Your work is greatly appreciated. I think I check this more than I check my watch! It’s good to have someone who regularly updates this thread. I can’t wait to see these drivers in action on everyone’s setup.
Latest news: the INF file generation system is fixed, and doesn’t make that mistake any more when creating the INFs. As I couldn’t repro the InfVerif failure on my machine, we’ll have to wait for release engineering to take a look at the problem. (This kind of tool problem is why we’re so careful about having release engineering build drivers from version control, rather than having the developer build them. Happens a lot when building drivers, for some reason.)
I’ve created the release brand. Self-review is not ideal, but I’ve reviewed it and it’s acceptable. Passed link to release engineering. Updated status.
I’m assuming it probably wont happen tonight, but any hope of having this out tomorrow or Monday if all goes well with engineering? (Sorry for the repost - accidentally deleted the first one)
Not likely tomorrow. Probably early next week. Unluckily, I’m on business travel
most of next week, so if there are problems it will be difficult fixing. We’ll do our best!
Sounds good. I’ll just await the final post. I hate to say it again because it’s probably been in every post, but thank you so much. This is really what we need for this project.
They worked on the Win10 Core IoT build. I suspect that it will work fine. We tested a couple of in-box drivers with WinPE in January, and they worked well. The SMSC/Microchip driver isn’t in box, and we didn’t have a chance to test, but it would be surprising if they didn’t work, given that ASIX and Realtek-based USB-Ethernet adapters did work for us, at least in light testing.
It depends on whether there are built-in drivers in Windows, or ARM64 drivers from the vendor. If so, it should work. If not, then need to try to convince the vendor to release suitable drivers.
In the testing we did with the 32-bit driver, the only things that were still problematic were webcam drivers, because it was very hard to debug high-bandwidth isochronous on Win10 IOT, due to lack of drivers and apps. It should be relatively easy to resolve problems on real Windows. But we will have to see.
release-candidate drivers built; then we got stuck getting the drivers to Andrei for testing, due to the usual “dangerous attachment” thing.
figured out the release strategy; MCCI will post a install .exe file that puts the files on your system after asking you to click-through the license agreement.
I’ve traveling in California, got a trade show tomorrow (LoRa Alliance meeting in San Diego), so it may be that it still takes a few more days to get all this wrapped up…
That is great news! So what does that mean as far as testing goes? Is this a matter of Andrei testing it and giving the it green light for it to be posted by MCCI?
