Implement functionality to fetch BSP Products off the Unified Update Platform

[gus33000]

This PR is meant to add a new feature designed to fetch a new kind of update, primarily used on ARM64 Windows Machines, BSP Products.

BSP Products contain all drivers and firmware files in a single update package for a given device, are bound to a product applicability (defined by one unique scrambled HWID formed from various SMBIOS value combinations).

BSP Products do not follow the same Composition Database conventions as traditional products, as in, the naming of the files differs, and such products may even contain extra files with the same names.

These products recently gained enough attention to warrant a tool designed to fetch them in an easy matter, in a platform agnostic matter, with enough configurability to make it possible to fetch for any given in market device provided you know the SMBIOS data, but not too many to cripple the ability to do so.

A Proof of concept implementation was previously implemented in the temp/driverfetch branch, mainly designed as a reference code basis to generate the contents of the WOA-Project/Qualcomm-Reference-Drivers repository. This code being single use designed, contains mainy problems not making it ideal for other use cases other than downloading every driver update online and for many devices.

The features needed should be:

• The ability to download BSP Products with ease
• Such BSP Products must be named properly according to the BSP Composition Database XML file
• Need to support all current features of UUPDownload (download resume, esrp decryption as needed, hash verificiation)
• Need to not break existing UUPDownload functionality
• By default, only the latest product should be downloaded
• The ability to fetch the current latest version of a given BSP Product
• The ability to fetch a precise version of a given BSP Product (by using SyncCurrentVersion)
• The ability to opt in to Driver Flights and the ability to specify the flight ring name (instead of always hardcoding the standard "Drivers" flight
• Optionally, the ability to fetch smbios data from the live machine
• Optionally, the ability to bulk download all past updates as well in one go
• Optionally, the ability to generate a changelog for all updates (repo scenario from above)
• In the command line, the user should be able to specify as many smbios args as they want (product, sku, manufacturer).
• The tool should use said data to generate multiple hwids, and add them as BSP Product targets under the SyncUpdate request (much like Windows Update does), this way there is no need to figure out which specific combination is valid

Anything else?

This PR remains a draft til all fonctionality and features are decided and implemented

[gus33000]

Im also hearing from specific end users (and not just developers) they would really like a GUI to also do this with ease, potentially, we may want to look into bringing back some of the older GUI as well

[gus33000]

The fusion both the driver dl functionality and the os update functionality without breaking either into uupdownload is completed.

Added auto fetch of smbios data as an option on top of being able to dial specifically what params to check into uupdownload

Here is a few command examples, as things stand right now:

• This command downloads version 200.0.9.0 of the BSP of the current running computer (Windows Only):

uupdownload.exe request-bsp-download3 -s Professional -v 10.0.26200.2483 -t arm64 -r Retail -b Retail -a CB -c ge_release -o C:\Users\gus33\Documents\GitHub\WOA-Project\Reference\Qualcomm-Reference-Drivers\TESTING -y --bsp-product-version 200.0.9.0

• This command downloads version 200.0.9.0 of the BSP for a device following specific targeting rules:

uupdownload.exe request-bsp-download -s Professional -v 10.0.26200.2483 -t arm64 -r Retail -b Retail -a CB -c ge_release -o C:\Users\gus33\Documents\GitHub\WOA-Project\Reference\Qualcomm-Reference-Drivers\TESTING --targeting-manufacturer "Microsoft Corporation" --targeting-family "Surface" --targeting-productname "Microsoft Surface Pro, 11th Edition" --targeting-skunumber "Surface_Pro_11th_Edition_2076" --targeting-biosvendor "Microsoft Corporation" --targeting-baseboardmanufacturer "Microsoft Corporation" --targeting-baseboardproduct "Microsoft Surface Pro, 11th Edition" --targeting-enclosuretype "9" --targeting-biosversion "160.2002.235" --targeting-biosmajorrelease "ff" --targeting-biosminorrelease "ff" -y --bsp-product-version 200.0.9.0

• This command does the old, QUALCOMM-reference-drivers behavior using the json file in current working dir to essentially generate the repo as it stands today:

uupdownload.exe request-bsp-download2 -s Professional -v 10.0.26200.2483 -t arm64 -r Retail -b Retail -a CB -c ge_release -o C:\Users\gus33\Documents\GitHub\WOA-Project\Reference\Qualcomm-Reference-Drivers\TESTING

If you omit -y and the version field from above first two commands then its going to fetch the very latest instead of the version specific version (much like os updates)

I still need to refactor a few things, cleanup, and add 2/3 minor features and this feature spree is done.

It is worth noting not all params are required.

The tool inserts every single possible computerhardwareid into the wu requests so if you provide a lot of targeting info, you are going to get a lot of those and are also going to maximize your chances of getting updates, but in above example, you can also do something like this (which seems to be the minimal set of required data for the Surface Pro 11) and you will get the very same updates:

uupdownload.exe request-bsp-download -s Professional -v 10.0.26200.2483 -t arm64 -r Retail -b Retail -a CB -c ge_release -o C:\Users\gus33\Documents\GitHub\WOA-Project\Reference\Qualcomm-Reference-Drivers\TESTING --targeting-manufacturer "Microsoft Corporation" --targeting-family "Surface" --targeting-productname "Microsoft Surface Pro, 11th Edition" --targeting-skunumber "Surface_Pro_11th_Edition_2076" -y --bsp-product-version 200.0.9.0

[gus33000]

@lumag I would be interested in feedback over the usage scenarios mentioned above, they currently work as described in the branch linked to this PR but Im wondering if you have any idea or suggestions to the command line syntax and how this works overall. If you could also try it and let me know if this is alright or you may want additional features or changes (like currently the tool will also put them in a specifically named folder on download maybe this is undeseriable)

Let me know anyway!

[lumag]

@gus33000 works like a charm, thank you!
Do you know by chance if there is a way to pack it into a single binary together with the dotnet runtime (Linux, of course, MS doesn't have the problem)?

[lumag]

Ok, -p:SelfContained=true did the trick. So it's even better now.

[gus33000]

Perfect! I am going to revamp a bit the command line arguments before this ships in a stable release and implement the other features of the checklist above in the near future. I did not figure out with which names to go so far for a few of these arguments and some are not exactly needed either for scanning BSP packages off Windows Update. Aside from a couple renames and simplifications this should be fairly stable already.

[lumag]

Maybe the last idea / request would be to be able to specify downloaded cabinets.

[gus33000]

I was thinking about adding the same thing. Im just wondering if you would also have a need for pattern matches for files or just giving an exact file name? I am noticing through qualcomm-reference-drivers that some manufacturers do end up renaming a few files from time to time and also providing more than one variant depending on their newly introduced device variants. But i guess you could always just manually fetch another.

[lumag]

I'm fine with the exact filenames.