- only install it by default on x86, set new MKRADEONFIRMWARE variable
- install in /libdata, so that separate /usr systems work
(this still doesn't solve PR#49811, which possibly could be handled by
having them being a kernel module loaded by /boot.)
these were sourced from:
- linux kernel sources, firmware/radeon/
- people.freedesktop.org/~agd5f/radeon_ucode/
LICENSE.radeon has the full license, which my simple reading sees as
being largely similar to other re-distributable licenses for firmware
(ie, does not include de-compliation or reverse engineering.)
some firmware sizes are the expected size. (XXX make all.)
based upon similar changes seen in the linux radeon drm driver.
this saves about 250KB in the kernel or module.
Add support for the Broadcom BCM5709 and BCM5716 chips. This upgrade
the B06 firmware, and add the B09 firmware required by the BCM5709.
Remplace TX dmamap array with a dynamically-grown list.
Tested with:
bnx0 at pci4 dev 0 function 0: Broadcom NetXtreme II BCM5708 1000Base-T
and
bnx0 at pci0 dev 0 function 0: Broadcom NetXtreme II BCM5709 1000Base-SX
Reintroduce more of a 'channel' concept in preparation for NP-IV support.
This gets rid of the chanA/chanB concept as the 2400 can have up to 128
virtual channels. Actually, with MID firmware you can also have the 2200
and 2300 support 'channels, but they do it with an FL-Port topology.
Because FC cards can now have 'channels', just about every support
function for fibre channel had to be redone to have a channel index
as well. Rototill isp_ioctl.h for channel stuff as well.
Pick up a lot of work about fabric management (hopefully better) and keep
work in place that will allow for dynamic attachment/detachment of devices
(if I can figure out how to make the midlayer support it).
Merge the target code with external trees. Eventually it might even
be sorted out on NetBSD.
Update some firmware stuff.
The major changes are:
+ 4Gb (24XX) card support
+ Rewritten fabric and loop evaluation code
+ New f/w sets
The 4Gb changes required major rototilling, which caused a rewrite of
fabric and loop eval code. The latter can now be set up to tune for
dynamic device arrival/departure if the framework is set up for it,
or to be firm about waiting for devices.
Testing has been principally on amd64, i386 and sparc64 and seems to
not have broken things for me.
mrg