Older blog entries for zx80user (starting at number 10)

<aside>Anybody else think the Advogato UI is less than optimal?</aside>
Anyway, made a little progress on the driver - though spent a lot of the last week's spare time building a PC from scratch (for the first time) as the old one relied on a not very stable wireless driver and accordingly locked up every 48 hours or so - but the box was far, far too noisy to move to the living room and plug into the ethernet.
Anyway, driver still does nothing real but now (at least partially) properly handles the kobject model in the 2.6 kernels...

Just a brief one - as i won't be about for a few days. Wondered why my driver didn't show up in /proc and then realised that was because I wasn't registering the device. So fixed that - so proc now acknowledges my existence.
Reading the diary entries below, from the first iteration of this effort worried me a bit last night - because it suggested that I was going wrong... hmmm. Well, the last time round went nowhere so I hope that was the wrong one :)

Ok, it's almost two years since I last was here and the funny thing is nothing much has changed ... still looking to write an ALSA module for the Dreamcast.
In the last two years my Linux knowledge has come on leaps and bounds - after 4 years of the OS I no longer feel like a newbie all the time and can even answer other people's questions on my LUG email group with a little authority (well, some of them anyway).
C coding has taken a back seat though I've hacked quite a lot of perl in the last two years.
Now I've helped inject a little bit of life into the Dreamcast port of SH (general work was powering ahead, but the DC side of it was pretty dead) by posting up a working kernel on my website (here) and have at least written a few lines of code to get the ALSA port started again (on my subversion repository if you're interested).
Progress will be slow - despite a little effort at trying to get myself a job as a hacker based on the perl stuff, I am still working in communications, so this is strictly part time :)

So, it is finally September. To be honest it has mentally been September for me since I came back from Ireland just over a week ago. Depression seeps over me at the thought of the dark winter ahead.

On the coding front have managed to make some progress - and boy is ALSA complex in comparison to the throw it all together and add a few ioctls approach of OSS/Free.

Discovered that I needed (at least) alsa-lib and alsa-utils to build my driver and went through a few days of difficulty to get them cross (and static) built. Some of the bits and pieces still aren't built statically (there seems to be a problem with the way the alsa-lib configure script handles static builds - it built the main libs as static, but not the rest).

The people on the alsa-dev mailing list and the #alsa channel on freenode have been helpful at all times though.

OK, now have the tools to test my driver (to see if I am headed in the right direction), when I discover the need to built in some mixer code (another change from OSS - I could build a very simple driver without any mixer ioctls though obviously it would be all but useless, here it just won't work without proper mixer code).

Despite the moaning, I can see the power alsa brings - the OSS driver and the recently completed BSD driver - use only two out of 64 channels - if I can get the ARM7 code right then alsa will allow me to use all 64 :)

27 Aug 2003 (updated 1 Sep 2003 at 23:05 UTC) »

Started to make some progress on the ALSA sound driver at last. But it's been 18 months since I wrote the OSS one and the technical language of pulse code modulation is slow to return to the active bits of my brain.

Still trying to get 2.6.0-test4 to compile for SH. Have been let down by SF anon CVS and then have struggled with a poor internet connection this afternoon :(. Going to pub now, so that's the end of that :).

OK, back from holiday - here are some notes I made when I was away and completely isolated from the internet...

21 August

Writing this for later upload to advogato. Looking out at a rain lashed Donegal scene, after finally giving up on trying to get a serial console to appear on my Thinkpad - because I now know I cannot make it happen and why. A pity - as I know that the Dreamcast I am using is booting and mounting the nfs based file system, but I had blithely packed up the TP 600 (which I regarded as a fantastically powerful box only four years ago) workhorse, along with the cross over cable I had been given for free (as it is incorrectly marked as a patch), and the serial DC coders' cable and brought them all here without actually testing the combination.
After reading through lots of man files I now realise that I need to have the thinkpad kernel module installed to be able to correctly setup /dev/ttyS1 and so actually connect. I do have a (binary) version of the module but unfortunately it is for a 2.4.18 kernel (for some reason that is what apt/fedora downloaded) and I cannot even force load it against the 2.4.20 kernel I have. And needless to say I have no internet access and even though both my mobile phone and the TP have IR ports - I need the kernel module to set up the IR modem :(. In any case I wouldn't use the phone for downloading such huge volumes - been there, done that, paid the phone bills (or, rather, my employer did).
Still, I feel I have learned something more about how linux and the standard PC BIOS interact (having read the setserial man page) and, in the course of building the kernel found a bug/feature in ALSA. Hoping I can be the first to point this out and will not look silly! Essentially, one cannot actually build a PCM capable ALSA system unless the OSS emulation is selected. That is not a problem, except for the fact that these are separate options for kernel building. Maybe it is because one can build an ALSA MIDI system? (I haven't tried) Anyway, I think the kbuild system could be simplified and clarified on this point.

[Later same day]
Thought I'd solved my problem when I stumbled across the ``cyber cafe'' in Donegal town. But it was closed due to ``internet connection problems'', so that was the end of that. Wandering around the town I also found copies of ``Linux Format'' magazine on sale in one of the newsagents. So the revolution is spreading even to this corner of Europe, but at 11 euro a copy for what is quite thin fare I decided to let a local benefit from its contents.


22 August

Well, came close to solving all my problems with the DC and then failed at the last moment - because of inadequate preparation two weeks ago (on the last day of the holiday I could not have accomplished much anyway).
Discovered I had actually got the sources for the Thinkpad module on the TP after all, but they required the 2.4.20 kernel sources to build. Hadn't got those, but did have the 2.6.0-test2 sources (as that is what I built the DC kernel from). So, I thought, build the 2.6.0-test2 sources and (as I hadn't got the up-to-date mod tools) integrate the Thinkpad code into the kernel kbuild and build it static.
Of course, without the correct mod tools I also had to build the 2.6 kernel without modules. Started work on that at 10pm, still hadn't got a good build by 2am, so went to bed. A bit of fiddling in the morning and low-and-behold 2.6 will boot the TP (which therefore becomes first i386 machine I have managed to boot with the 2.5/2.6 series - failed many times with 2.5 kernels). Do some more tinkering to get a slightly less unwieldy kernel (another 2 hour build on this box) and then sit down to integrate the Thinkpad module into the kbuild when I notice that dmesg is actually reporting a /dev/ttyS0 and /dev/ttyS1 - so seems the Thinkpad module is redundant for that at least.
Sure enough, fire up the DC and minicom and watch DC boot. Very exciting, but also time to take kids out the the beach (this is a family holiday!).
When I get back and kids are safely off to bed, and we're all packed for morning's journey, have another go, but realise I don't have the SH mod tools either. Even when I unpack the old ramdisk initrd and mount that on loop, they aren't there either! A stupid mistake and if I'd thought about this for a few minutes when I was setting up this box to go in London, I'd have realised.
So code is there, module is built, but I won't be able to load it till I am back in London again.
On the beach finished ``Cathedral and the Bazaar'', have to say I found it all rather less than illuminating and too keen to push its (rightist libertarian) political slant while attacking everybody else for bringing politics to the table. Also looks very over blown in the light of the continuing IT slump.

Hottest day since records began in London has just ended. Sweltering. Went to Seville in May to see the bhoys and this was way hotter. Played a lot of unreal tournament in the office :)

Just posted a patch to lethal to at least get the bare basics of sound in the linux-sh drop in tree for 2.6.

Did RTFM for ALSA last night and clearly I need to do a lot more code browsing so I can see how others have done it.

5 Aug 2003 (updated 6 Aug 2003 at 19:56 UTC) »

A little more progress on the driver, seems to handle all the basic interfaces with /proc etc, but discovered that I had misunderstood the ALSA memory alloacation API: time to RTFM (again, but properly this time!).

As a result saw a lot of lethal's rewritten kernel oops handling in SH-Linux for the 2.6 kernels. Nice work.

Well, last night decided I was wasting my time trying to escape the clutches of kbuild and wrote an appropriate Kconfig and makefile to integrate my snd-aica module into the kernel build and after a bit of footering to get it all right, built an empty shell snd-aica module.

One difficulty I have found is that modules_install installs the modules under 2.6.0-test2-sh while the sh system itself regards itself as pure 2.6.0-test2, so I have had to move the modules by hand.

The lack of BusyBox support for 2.5/2.6 type modules is also a pain, but I know they are addressing that.

Anyway, just built a slightly less shell like snd-aica module that does the proper ALSA thing of registering cards and chips.

More to do, more to do...

1 older entry...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!