Linux on the DEC 3000

Home | System Info | Documentation | Log Book

Linux/DEC 3000 Log Book


November 27th	Just got back from Thanksgiving (burp) with my folks down in Ft. Myers. Have tweaked the System Info page with the memory part numbers. Also, plugged in the "new" 3000/300LX at home. Plan, beginning tonight: Re-acclimate. Break up patches into logical parts. Continue with 2.2.9 until 2.2.14 is released, then merge whatever I've got.

November 22nd	After (another) long hiatus, I'm back. This time for a couple weeks, I hope. I've updated the web pages, and added the System Info page. Now to re-acclimate myself and get coding!

September 3rd	I've updated the aboot sources on the main page, and provided an SRPM (my first!). Am trying to find the aboot maintainer now. Not much work has gone in lately - still reading docs when I can, trying to understand what the interrupt code is doing. I started to add some Turbochannel probing code, but it doesn't work yet. Am past the `tbia()` crash, though. Installed NetBSD on the 3000/500 at work. Should be pretty useful, as I can read the code and put lots of printf()s in to learn more about what a working system has to do!

August 15th	Well, it's been nearly 2 months since I updated this page... Time to fill in all the listeners out there :) Not too much happened at the end of June and in July - I was in Ithaca for most of that time, and it was all work and no play (linux-wise, anyway). Since I've been back, I've gotten a few things done; we are not much farther in the kernel, though. Here's what has gone on: Hardware At home, I now have 2 DECstations - picked one up while I was in Ithaca and the other after I got back to Florida. One is a 5000/120 and the other is a 5000/240. Not running linux yet, but they might come in handy to make sure we don't break anything for them (we'll be using some of the same turbochannel stuff). At work, I got a DEC 3000/500 out of the dungeon (the place where computers go to die) and put it on the network in my office. So I can work on this easily from work, too. Kernel patches & modified aboot sources are on the web. But before you try them, see README.patches . And just found this out this morning - I made a mistake in making system-specific `tbia()` and `tbiap()` functions... Originally `paging_init()` ended us up in a machine check (never returned from `tbia()`). I altered `tbia()` - incorrectly - though the incorrect code avoided the machine check. There seems to be nothing wrong with the original `tbia()` - "correct" modifications result in the same machine check. So now we are back to crapping out in `tbia()` with our old nemesis: `?06 DBL MCHK PC= 00000000.00060401 PSL= 00000000.00000007` Kinda funny how that is the same error I was getting way back when with `cons_puts`...

June 22nd	Milestone! I added the necessary Flamingo and Pelican hooks to `alpha_machine_vec` and some `srm_printk` calls in `alpha/arch/kernel/setup.c`. Lo, and behold: `aboot: Linux/Alpha SRM bootloader version 0.5 aboot: switching to OSF/1 PALcode version 1.45 aboot: ok, now starting the kernel... Booting on Flamingo using machine vector FLAMINGO ?05 HLT INSTR PC= FFFFFC00.00310088 PSL= 00000000.00000007` grin For now, all members of the Flamingo (DEC 3000/[4-9]00) and Pelican (DEC 3000/300*) families are the same; I'm not sure yet if the kernel needs to know about differences between models within a given family. But the structure is there to easily add that if need be. The Halt is coming from `__set_hae(alpha_mv.hae_cache)`, which is not surprising, as most of the machine specific stuff besides the names are either dummies or incorrect.

June 20th	Out of sheer curiosity, I tried booting from the new 164SX running RH6.0, kernel 2.2.9, and aboot 0.5-10. No help - still death after the first `printf`, no matter where it is. It turns out... Aboot was crapping out in `cons_puts` (which is where all of aboot's printf calls end up). I modified aboot to do something more like what the kernel does when it wants to dispatch(PUTS...) (`linux/arch/alpha/lib/srm_puts.c`) - it just works : `aboot: Linux/Alpha SRM bootloader version 0.5 aboot: switching to OSF/1 PALcode version 1.45 aboot: ok, now starting the kernel... ?06 DBL MCHK PC= 00000000.00060401 PSL= 00000000.00000007` Woo hoo! This will probably also solve problems booting the Jensen with the most modern firmware, which seems like the same problem. The error above looks like a machine check - not too surprising, as the kernel which I used was for a 164SX :) I littered printf's all over aboot - we do indeed make it into run_kernel. I've started adding code to kernel - I added the Makefile stuff for all the DEC 3000 machines. The netbsd sources were helpful in getting the family/name/alias stuff worked out for the models I didn't already know. Here are the modified entries to `Documentation/Config.help`. Let me know if any of this is in error. I also hacked up a template for the Turbochannel ASIC stuff, which I stole from the existing Linux/Alpha APECS (PCI based) code, and just dummied out a lot of the functions, etc. I certainly don't expect this to work out of the box - I've got a lot of consulting with documentaiton to do. But I did build a "Flamingo" kernel. Here's what happened when I tried to netboot it. `aboot: Linux/Alpha SRM bootloader version 0.5 aboot: switching to OSF/1 PALcode version 1.45 aboot: ok, now starting the kernel... ?05 HLT INSTR PC= FFFFFC00.00310088 PSL= 00000000.00000007` Well, looks like we halt this time instead of ending up in a machine check - this is good news (I think). Now, I just gotta find out where that halt is coming from, and go from there. As an aside, it seems RedHat no longer ships the BOOTP package with their distribution. I tried DHCP out, but caradhras kept "RETRYing". Probably 'cuz there was no entry like BOOTP's `:hn:vm=rfc1048:` for the client (I didn't see anything like that in DHCP's various man pages). Admittedly, I didn't try to get DHCP working for very long, though - maybe it can work. In any case, I just grabbed the BOOTP sources from the RedHat 5.2 distribution, compiled and installed them. No problems. All in all, a good weekend. But now, I think it starts to get hard.

June 16th	Tried to BOOTP a kernel to see how far I got. Built aboot-0.5-9 from sources. Funny - `$(OBJSTRIP)` is not defined in the Makefile, which causes it to crap out when you try to `make netboot`. I fixed that... Well, it turns out that I get to aboot's first `printf`, and then the DEC 3000 hangs, as George Armhold documented on his page. At least that is consistent... (looking for something positive). George also documents that aboot actually works with some older firmware. I think what I will try to do is make aboot work with the v7.0 firmware. The reasons for this are: Since we can BOOTP the firmware, it seems like the "fault" for the failure lies with aboot I don't have access to any old firmware (though I can probably find some locally) I suspect a large part of the DEC 3000 world is also using v7.0 firmware I should point out also that the NetBSD folk also had problems (until last month) netbooting on DEC 3000 with v7.0 firmware, though the `:hn:vm=rfc1048:` in `/etc/bootptab` seems to have solved their problems. If I can't get past this, I'll find some older firmware and try it out.

June 15th	Went searching on the net for a solution to the problems caradhras has netbooting. Bad news and good news. Bad news first - this is a firmware problem, and people have been having problems netbooting DEC 3000s for a long, long time. But the good news is that there is now a solution! Apparently, the "hn:vm=rfc1048:" entries in the BOOTP server's bootptab are necessary for the DEC 3000 with most recent firmwares; thanks to George Armhold for putting this on his web pages, and to Dave Johnson for posting his results to fa.netbsd.ports.alpha (server: i386 Linux, client: DEC 3000/300). Also note that Aaron Grier reports that DHCP also works with these flags (server: DecStation 5000/240 running NetBSD 1.4, client: DEC 3000/400). Here's my working bootptab: `.global:\ :hd=/tftpboot:\ :ds=192.168.0.1:\ :sa=192.168.0.2:\ :sm=255.255.255.0:\ :hn:vm=rfc1048:\ :to=0: caradhras:ht=1:ha=08002bxxxxxx:\ :bf=m400_v7_0.btp:\ :ip=192.168.0.10:\ :tc=.global:` Note that `m400_v7_0.btp` is the firmware upgrade from DEC's ftp site. So it is possible to use BOOTP with the most recent firmware. It turns out that George is working on a Linux port to the DEC 3000/300 - here is his porting diary. I should send him a mail - maybe we can work together on this. His experience, however, was that aboot will not work with version 7.0 of the firmware. I'll try it out.

June 14th	Well, I've done almost nothing for the last 6 weeks on this. It is time to start having some fun! Set up the AlphaStation 250 4/266 as a BOOTP server. Successfully upgraded firmware on the AlphaStation 200 4/233 via BOOTP. So far so good - at least the BOOTP server is functioning correctly. Had to allow 0.0.0.0 to come in. Originally, I had ALL: ALL in my hosts.deny, and only had machines with IP addresses on my private network permitted in hosts.allow. However, firmware update for the DEC 3000/600 didn't work... not sure why. The BOOTP server responds ok, and the DEC 3000 knows it, but the NIC apparently times out. Here's what is on the console for the client: `>>> boot ez0 INIT-S-CPU... INIT-S-RESET_C... INIT-S-ASIC... INIT-S-MEM... INIT-S-NVR... INIT-S-SCC... INIT-S-NI... INIT-S-SCSI... INIT-S-ISDN... AUDIT-BOOT-STARTS... AUDIT-BOOT-REQ... Host server IP address is 192.168.0.2 AUDIT_BSERVER_FOUND... ? T_ERR_NI- RECEIVE TIMEOUT 84 FAIL` I'll have to figure this one out. `TEST NI` doesn't show any errors, and the network seems ok. caradhras was previously running DU 4.0D on this network, and wasn't having any problems. ponder (the BOOTP server IP address is correct)

Craig Prescott <prescott@phys.ufl.edu>