- On TX, vge(4) seems to assume that tags are written in little endian.
We already use htole32() to write values into descriptors,
so extra byteswap by htons() is not needed there.
- On RX, vge(4) seems to store tags in network byteorder.
We have to swap byteorder regardless of host's byteorder
(i.e. we have to use bswap16() rather than ntohs())
because we already use le32toh() to read values from descriptors.
Anyway, no need to use htons()/ntohs() because there is no stream data.
Tested on both i386 and macppc, and OK'ed by Pavel Cahyna.
newer server chipsets) to wm(4), from the FreeBSD em(4) driver.
While there, add a few other Intel Ethernet controller that should work as
is.
Properly update the RX error and TX collision counters.
Add ikphy(4), a driver for the Intel i82563 Kumeran 10/100/1000 Ethernet PHYs
at an odd address (0xd9) and noted "8 bit" in rtl81x9reg.h.
XXX: FreeBSD and OpenBSD also use CSR_WRITE_1() to write RTK_GTXSTART
XXX: for 8169 even though there is a "16 bits" comment at GTXSTART macro.
XXX: Which is correct?
I can't think of a good way to avoid race condition between writeback and
DMA write against descriptors if cachelinesize > sizeof(struct rtk_desc)...
Anyway, now re(4) is functional on O2 (and probably other mips ports).
- make DMA descripter members volatile
Now re(4) works on sgimips O2.
XXX: Still re(4) sometimes stalls on NFS load on sgimips,
XXX: but I'm not sure it's sgimips specific or not.
Specifically, the SPI flash now operates as a nearly fully functional block
device (other than lacking disklabel support). It does some basic translation
stuff, so that if you attempt to write a block, the underlying flash sectors
(usually 64k in size) will be read, erased and rewritten.
To minize thrashing, the spiflash strategy routine attempts to gather writes
to the same sector together, so that in the typical case you will not have to
repeatedly erase/rewrite the sector. It also attempts to check and verify
whether an erase cycle is truly needed. There are still access patterns that
will cause multiple erases to occur, and so I heartily discourage the use
of these flash devices for storing anything other than small configuration
data, or write-once images. If you want to do more than that, then someone
should try to write a real flash translation layer.
The drivers attempt to provide some level of asynchronous operation, so that
while you are erasing or writing to the flash, other things can reasonably
take place.
Note that spiflash does not do bad block remapping. It also doesn't detect
when a device is in read-only mode, or if some sectors are read-only. It
only supports uniform sectored NOR flash. It lacks any code to deal with
disklabels, and does not offer any disk related ioctls.
These limitations aside, it would not be terribly hard, I think, to break
out the code I've done to create a generic "norflash" driver, backed by
a "common" spiflash module. Then other flash drivers (e.g. athflash, etc.)
could benefit from the ability to use this as a block device. I've tried
to architect it to support that, if someone else wants to do the work.
(Hi Jared!)
The primary reason that I've not added code to deal with disklabels is that
I had a difficult time figuring out which framework (disklabels or wedges)
to use, and which bits of code were necessary to implement. In the case of
the flash devices I'm working with, a parser to deal with redboot FIS images
(partitions) would need to be added. I was prepared to do this, but gave
up owing to the complete and total lack of any API or design documentation
pertaining to the requirements for disk drivers and disklabel management or
wedges. I would strongly encourage someone who knows something about
wedges or disklabels to write a simple document (or even a dummy driver)
showing which interfaces should be provided in new mass storage drivers.
This work was funded by the Champaign-Urbana Community Wireless Network
Project.
"#if defined(__i386__) || defined(__x86_64__)".
XXX: What will happen if RTL8168B is used on !__NO_STRICT_ALIGNMENT hosts?
XXX: If 8168B can't handle RX DMA into 32bit-unaligned memory, should we
XXX: implement some code to copy RX buffers like vge(4)?
XXX: Or is 8168B available only for on-board NIC for PCs?
right after vge_reset() could be corrupted. For workaround, add a
dummy EEPROM read in vge_reset() so that MAC address is properly
set on the machine.
While here, add a DELAY() in busy loop in vge_read_eeprom().
tsutsui