Amend manpage as per ziaee's suggestions

In D59920#1383291, @adrian wrote:

Just out of curiousity - how big is the final firmware bundle on disk?

Add LICENSE file from rtwn again (not sure how this got dropped)
Update the rtlbtfw manpage

In D59920#1383172, @wulf wrote:

Remove duplicate config files and replace them with symlinks

IMO it will make updating of linked files less intuitive.

To clarify what I'm talking about, here's a before and after of the splash screen:

For some more info, the laptop is a dell latitude e7440.

hw rev 0x140, fw ver 17.352738.0

I think this is good now. I have a minor style nit, but that can be fixed when landing.

• Remove firmware for unsupported chips
• Add firmware files to OptionalObsoleteFiles.inc
• Update firmware blobs from the linux repo. Updated: rtl8852au_fw.bin, rtl8852btu_fw.bin, and rtl8852bu_fw.bin
• Remove duplicate config files and replace them with symlinks
• Drop CLEANFILES, since the files aren't uuencoded anymore

Add LICENSE file from rtwn

Move firmware files to share/firmwares/rtlbt
Add all firmware files from the rtlbt-firmware port except for rtl8761b (which isn't used by rtlbtfw), and the SDIO chips since they do bluetooth over UART, which we don't support.

s/chipset/chip

err, meant to leave a comment up there.

Update license text.

Change email in copyright notices and document which bits of txdw6 are passed through.

Move entry to the correct place in the hardware list

Move sentence to its own line

Vendor driver used for reference: https://github.com/lwfinger/rtl8723bu

I think defining R92C_TRXDMA_CTRL_QMAP_M differently depending on the header can cause a bit of confusion, but I didn't want to break the naming conventions...

In D59107#1356069, @adrian wrote:

Locally tested on RTL8821AU . We should test it on a few more just to make sure it's okay.

These two patches are precursors to adding support for the rtl8723bu. The main patch is mostly complete, but I'm still chipping away at cleaning it up. Adrian suggested we just get these out of the way now. The non cleaned up version can be found here: https://github.com/freebsd/freebsd-src/compare/main...VexedUXR:freebsd-src:rtwn

LOADER_DISK_SUPPORT is also checked in stand/defs.mk, otherwise looks good to me.

Better wording

In D57568#1319455, @kib wrote:

In D57568#1319454, @vexeduxr wrote:

In D57568#1319451, @kib wrote:

why not change the word 'protected' to 'long'?

I'm not sure how the CPU mode is relevant to the rest of the text. Shouldn't the CPU be susceptible to faults regardless of the mode?

It is quite involved to make CPU fault in real mode. In VM86 mode it is somewhat easier but still not straight. The mention of the mode is to compare it with the old pre-EFI BIOS where loader practically cannot cause CPU faults.

Implement kib's suggestions.

Keep the sentence intact but change x86 protected mode to 64-bit long mode.

In D57568#1319451, @kib wrote:

why not change the word 'protected' to 'long'?

Can confirm that it boots fine with the things I mentioned below fixed.
Thanks!

Wouldn't the ia32 loader need this too?

I wanted to let this sit for a while since I didn't like that we had to build everything twice, but I can't seem to find a better solution for now.

Make the LIB*32 variable assignment more seamless.