NetBSD Documentation: NetBSD/acorn26 TODO

This is a list of things I (bjh21) think should be done with NetBSD/acorn26. Entries higher up the list are ones I intend to do first. If you want to help, you'd be well-advised to start further down.

The unsupported hardware list may also be of interest.

• Functionality on four-megabyte machines
• RISC iX binary compatibility
• Faster soft interrupt handling
• Merging acorn26 and acorn32 podulebus drivers
• Faster bus_space operations
• Rasops improvements
• DDB single-stepping and breakpoints

Functionality on four-megabyte machines (top)

At present, NetBSD/acorn26 cannot be booted (even to a single user shell) on a four-megabyte machine. This must be fixed, since few of the target machines have more than four megabytes of RAM.

RISC iX binary compatibility (top)

RISC iX is a 4.3BSD derivative, and as such, binary compatibility with it ought not to be too hard to attain. Almost entirely useless of course, but when has that ever stopped me?

Faster soft interrupt handling (top)

At the moment, all the soft interrupts in NetBSD/acorn26 are kept in a single linked list, sorted by priority, and soft interrupts are handled by searching this list for pending interrupts above the current priority. This is slow, and should be replaced by something better. A linked list for each priority and maybe a variable containing the highest priority at which a soft interrupt can happen sounds like a good approach.

Merging acorn26 and acorn32 podulebus drivers (top)

Currently, the acorn26 and acorn32 ports have their own similar but distinct podulebus drivers. This is silly and should be fixed.

Faster bus_space operations (top)

The bus_space_{read,write}_{multi,region}_2 routines are used quite heavily in NetBSD/acorn26, since the hardware (mostly) doesn't support DMA. NetBSD/arm has fast routines to do roughly the right thing in sys/arch/arm/arm/blockio.S. We should use these, or derivatives thereof.

Rasops improvements (top)

The dev/rasops code doesn't currently work on the Arc in <8 bpp, apparently due to bogus endianness assumptions in the rasops code. This should be fixed, and a 4bpp mode for rasops written (4bpp would be good for a colour console terminal).

DDB single-stepping and breakpoints (top)

DDB support for single-stepping and breakpoints is rather dodgy and really should be improved.

Home page

Supported Architectures