After reading the main part of the USB specs, I moved on to the UHCI driver specs this week-end. I can now say, that implementing the isochronous part to the UHCI driver is a lot easier than I thought, and I guess Micheal can confirm. While reading the UHCI specs I followed Micheal’s code, and I have some questions about it, but I’ll write him an email for that. By the way, is R1 intended only for x86?
My name is Andre Garzia and I live in Brazil. I am one of the summer of code students that will be working with Haiku. My project is the Network Preferences Application. I do most of my work on macs, most of my work is related to custom servers or web apps. I have a hobby which is to collect operating systems and machines and network them all. Right now I have couple macs (both classic and mac os x), linux, solaris, zeta, haiku, windows mobile, newtons and a magic cap machine, all networked, so I’ve felt the pain and joy of configuring different kinds of machines with different needs.
Who would have thought that something like me being chosen as a student for GSoC would actually happen. But it did. Blissfully indeed.
Anyway, designing a good user interface is not as easy as it seems. The truth is, not even for a second did I think it was, really. On my project road map, I’ve set designing the installer UI as my first task. Following the discussions with the Usability Team, a satisfactory concept came to life.
<p> <b>This article contains outdated information, please read with caution.</b> </p> <p> Mainly in the second half of the last year the Haiku USB stack has matured a great deal. Not only has it stabilized a bit, it has also seen the addition of an EHCI driver to support USB 2.0 devices. A rewritten UHCI driver and a new implementation of the USBKit library are other steps to a complete stack.
I’ve been reading some more code and I’m getting more confident with it.
Basically data transfer is done with memcpy.
In the ehci controller, registers are mapped every time a controller is found. This is done in the controller constructor.
As the ehci specs says: Register Space. Implementation-specific parameters and capabilities, plus operational control and status registers. This space, normally referred to as I/O space, must be implemented as memory-mapped I/O space.
I said it already, but I’m going to say it a million of times, I’ve never EVER would expected to work on such a project for the Google Summer of Code, I actually didn’t even think I would get in the soc. But anyway, here I am… so let’s begin!
Last night after I got bored reading the Kernel Kit section of the Be Book (it was about threads and related functions), I opened my shell and I dived right into the USB stack code.
- Updates to Mesa 6.5.2 and binutils 2.17
- Consoled debugging of app server, input server and the registrar
- CPU initialisation fixes
- Introduction of the UserlandFS
- Addition of class screensavers
- Customisable CFLAGS
- Useful URI to application redirects
- Syscall benchmarks and results
- Introduction of USBKit reimplementation
- Interesting local message passing optimisations
- VMWare vmdk tools
- vmdk image generator
- vmdk jam target: haiku-vmware-image
- Beginnings of AHCI support
- Hardware cache flush for SCSI
- Stability fixes for the USB stack
- Port of the following filesystems