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).
NetBSD/alpha and NetBSD/sparc. This fixes PR#34751.
The problem most likely started to show in gcc4 and is caused by the use of
a casting to an uint32_t pointer that is later copied from using memcpy.
Gcc detects the copying of 4 bytes from an uint32_t pointer and decides to
just replace it with an aligned copy causing the trap.
Fix provided by Izumi Tsutsui and ok'd by Martin.
INTPTR_IS_LONG, not INTPTR_IS_ULONG -- the latter is unused in
other parts of lint's code. This stops vax's lint from complaining
about conversion of integer constants to 'unsigned long' in function
argument lists, via a proper define of INT_RSIZE in common/inittyp.c.
sh3 defined this to 0, so was actually not affected, but better to
eradicate the typo there as well.
- 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.
in cpu_initclocks(9), and then remove "if (cold)" check in decr_intr().
Fixes long delay during config_process_deferred() for interrupt_config_queue,
OK'ed by macallan.
from Kentaro A. Kurahone, with minor adjustments by me.
the ack prediction part of the original patch was omitted because
it's a separate change. reviewed by Rui Paulo.
