Older blog entries for lethal (starting at number 6)

Falling behind on posting again, so here's a quick recap on what I've been hacking on recently.

Made quite a lot of progress on everything DMAC related the last few days. We're now much closer to something resembling a real subsystem, though there's still a few minor things to work out (including polling threads per DMA engine for doing large unblocked transfers). As a test, I also wrote a quick and dirty clear_page() and copy_page() using a dual-address mode configured channel on the SH DMAC, which ended up working quite well, despite some icache oddities in the clear_page() case which still need further debugging.

With the birth of the new SH-specific dma subsystem, I was also prompted to move the PCI stuff around again, and now we have a nice new shiny arch/sh/drivers/ where pci and dma stuff live. In the future, I suppose I'll move the sh cpufreq stuff here as well, as it really has no place in the arch/sh/kernel/ heirarchy .. though that's something for another day.

Anyways, now that I've got dual-address mode DMA as well as cascading to the PVR2 DMA in the Dreamcast, I suppose it's time to try to figure out how to tie this into pvr2fb in some sane fashion. For one, I don't seem to be able to use the user address of the write buffer as a source address for the DMA transaction, so something needs to be done here so we don't have to have the copy_from_user() overhead before we can start up the DMA transfer. Not entirely sure how DRM/DRI deals with this sort of stuff, though I suppose that's the next logical point to start looking at.

This would be much less of a headache in uClinux.. ;-)

Falling somewhat behind in posting frequency, so I suppose now's a good time to make yet another entry. Nothing overly eventful lately, managed to finish off most of the remaining issues with the store queue API I've been working on, which was nice. Unfortunately the only way I could get the cleanup and flushing for userspace mappings implemented in a clean fashion entailed adding back in the unmap and sync ops to the vm_operations_struct. These seem to have been removed in 2.4-test time, mostly because no one was using them. Hopefully it won't be too much of a fight to try and get these merged back into 2.6 proper .. otherwise it'll just be another thing stopping sh from working out of the box on vanilla 2.6.

On another note, it appears that mrbrown's ps2 "exploit" has been slashdotted. This wouldn't be much of a problem, except for the fact that that exploit happens to be posted on the same machine I use as a mailserver and for my IRC sessions. Lag suddenly has new meanings. This particular exploit is quite exciting though, I'm almost tempted to take one of my ps2s and write a native pong clone that doesn't happen to be RTE or reload1 encumbered .. though I shouldn't get carried away. Unfortunately for some (particularly certain petty individuals with some inferiority issues to work out), this is instantly viewed as a method for furthering rampant piracy. Regardless, this certainly seems like good news for the ps2dev community.

Did a number of non-kernel things today -- which in itself doesn't seem to happen very often. Ported uClibc CVS HEAD to sh64 this morning, based off of some ancient patches from SuperH. Nothing too exciting port-wise, static linking is the only thing that really works at the moment, as I still have to sit down and hack on the ldso and libpthread interfaces, but I'll leave that for another day. A static hello world stripped comes in at a hefty 41k, which certainly has glibc beat. Patches off to andersee, and should hopefully be merged soon. So far so good.

Also spent some time hacking on a simple RDF/RSS parser using libxml2. This is a result of not being able to find a suitable tool that did what I wanted. Originally I was going to hack this into mutt directly, but it seems much more logical to roll this into some sort of fetchmail-like tool for doing the initial fetching/parsing/sorting. Then I can dump this stuff straight into mbox format and pick it up through mutt that way (since I can also add the mailboxes directly and get notification on updates, while keeping the fetching tool running in the background). I suppose another alternative would be to hack this into fetchmail directly, but the tools are different enough that this probably isn't an overly useful approach (not to mention the blatant disregard for sane headers).

Today was mostly PCI cleanup day, as the vast majority of the day was spent cleaning up most of the PCI mess for sh on 2.6. Managed to hunt down a rather obscure bug with the PCI auto code (cloned from MIPS, whhich cloned it from PPC, etc.), which was causing the dreamcast BBA to not respond properly. This ended up being a problem when poking the mem BAR to read its size and then writing out a new auto configured value for the BAR. As a workaround, we have to write back the pre-configured address that it comes up with after being powered on. It's not exactly obvious why this is the case, especially given the fact that the BAR value isn't even the same as the address range that we use for accessing the board later on. Presumably a good chunk of this still needs further debugging. The odd thing is that this doesn't end up being a problem for the I/O BAR, but even when using PIO for device programming, the MAC still comes back garbled. Given the fact that some similar issues are showing up on 7751R, I suspect there's still something else that needs fixing. Most annoying.

On another note, it looks like the rest of my sh updates made it in in time for 2.4.22-rc1, which means that -rc1 should now be in pretty good shape for both sh _and_ sh64. This is definitely good, since the sh stuff was way out of sync for way too long. This should at least cut down on how much time I'll have to spend maintaining the 2.4 stuff. Now it's just 2.6 that needs more attention.. particularly for sh64, which I still need to port *grumble*.

Yesterday was mostly spent working on a new API for the SH-4 store queues. This ended up going pretty well, except now there's still some address translation issues to work out. Namely, we have to have an implicit mapping from the store queue virtual address to the associated physical address. Doing this by hand works fine, but then we lose the mapping when the TLB is flushed. Alternatives here are either wiring the TLB entry (which also entails moving the rest of the SH stuff over to array access of the UTLB), or putting together a pte and shoving it in the page tables by way of update_mmu_cache() or something similar. Wiring the entry is the best way to go if we end up using the queues quite heavily at a given point in time, since we can keep the translation around and survive a context switch which may flush the TLB on an ASID counter wrap around. However, if we aren't using the queues, it makes no sense to keep the TLB entry locked down. As such, I'll probably have to go with both methods, or some sort of hybrid between them. Will have to look into this more later.. back to profiling the TLB flushing overhead for now, and then off to start implementing array access and porting over my sh64 tlb interface for doing mostly the same thing.

Put off hacking on the DMAC stuff, since it still isn't appealing any way you want to look at it. I'll probably get to this later once I'm done with some other things, or when I get bored enough to want to actually look at it again.

Spent a few hours being blinded by my IRC client while hunting down various new fansubbed anime. As anyone who has done this before in a console IRC client can tell you, it's not pretty. Thankfully, ripping out mIRC color support made things somewhat more bearable, but not much. Now if only usenet/freenet/<insert random buzzword compliant network of the month here> were more practical for this sort of thing.. although it does seem that BitTorrent is slowly making inroads here, so perhaps this won't be such a headache in the future.

While letting that and BitKeeper play the "lets see who can trash my dialup the most" game, I actually managed to get some work done. Spent the last couple of hours beating more of the sh boards into submission for the 2.6 tree, which mostly entailed ripping out huge chunks of I/O routines which we now deal with through generic wrappers that are filled in at run-time instead. This has made a large number of board-specific code a lot cleaner, and generally smaller. Now it's time to start gutting useless hacks to appease gcc 2.x, since for one, sh is hopelessly broken there, and two, we can't even rely on it to build the kernel reliably anymore. At least this will clean up some of the machvec and syscall code some.

Nothing overly eventful today. Spent entirely too much time configuring my advogato statistics, project involvement statistics, and so forth. Managed to get mrbrown and zx80user up and running on advogato, that should prove to turn out interesting. Now I just need a decent console based tool for managing RSS feeds/subscriptions. Evolution seems to do this quite well, though unfortunately I'm not in X long enough in any given day for this to be overly useful.

Spent quite a bit of time getting irritated with the various DMA APIs in the kernel. The old API for PC-like ISA DMA would work quite well for me, except for the brain-dead PC/ISA assumptions about reserving a channel for cascading, having to keep track of a DMA buffer, and its inability to have any concept of DMA modes involving dual-addressing (or rather, specifying both SAR and DAR values per-channel without worrying about tracking a DMA buffer). This unfortunately creates quite a headache for both sh and sh64 where the vast majority of channels in the DMAC only support the dual modes. Which ultimately means that I'll probably have to end up doing this in some inane architecture-specific API fashion, which isn't particularly appealing.

After reading jejb's OLS paper on integrating DMA into the device model, I can't say that the new API seems to deal with any of this any better. Great. Looks like ugly architecture-specific API is the way to go..

Following with the trend of having an account here, I've taken the plunge and created one. Or rather, posted an entry under an account I created quite awhile ago but just never did anything with. Hopefully the frequency of posts will be somewhat more current then the time between initial account creation (which I can't seem to recall at this point in time either) and this initial post.