Talk:Installing 386BSD on BOCHS
FYI once patchkit 1's kernel is built, it'll run on Qemu!!.. and a zillion times faster to rebuild world that way...!
0.11.0 works great.. 0.12.3 not so great.
neozeed 03:12, 17 April 2010 (UTC)
I tried the windows package you made. Works like a charm. Judging machdep.c you can tone down -m to 64 though.
Yeah I kind of figured... It's like NT 3.1 back in the day, those boards could only go to 64MB, and we were RICH if we had 16..! I managed to build gcc 2.5.8 on 0.1 pl 24 (is that the right name for it?!), but where to go from here...? I guess X11 is the next big hurdle.. Then I guess Quake or Doom, but after that... I guess just a matter of keeping it around.
neozeed 17:29, 21 April 2010 (UTC)
Well, machdep.c is easy to fix to support more RAM, but then I would be forking it into dugoBSD. That seems a bit out of scope here.
Not sure what Rodney intended with the version numbers, the last released kit is numbered 0.2.4-B1 or just 0.2.4. I suppose if Jolitz would have given his blessings the kits would bring it to 386BSD 0.2.4, but the kits remained unofficial. Patchlevel refers to individual files and count the number of times they are patched in this context, I think, w/ eg. wd.c going up to patchlevel level 6.
I don't think this needs to go a lot further, we have a description how to get 386BSD 0.1 to work and how to run the historically significant patch kits. OTOH, it is very cool to see how far this old geezer can be pushed. There is no limit to it. I will not rest until I have it run headless w/ sshd and operating a root nameserver *g*. Would be nice to get that 386BSD.ISO FreeeBSD hosts mounted, which brings me to X.
Check that CD, there is a bunch of X related stuff on it in dirs with `cons' in the name. At first glance patches and binaries for mono and color and few tools like xroach, xscreensaver. I didn't run into the full xfree86 sources on that CD yet. Will dig.
Dugo 12:37, 24 April 2010 (UTC)
Adding disks. Broken, or I'm Doing It Wrong(TM)
Sometimes you get carried away and want too much. Things don't always work the way you expect them to. Here an example of such a tale.
With an extra controller in bochsrc you can have 4 disks. I added to the bochsrc
ata1: enabled=1, ioaddr1=0x170, ioaddr2=0x370, irq=15 ata0-slave: type=disk, path="disk1.img", mode=flat, cylinders=1024, heads=16, spt=63, translation=none, model=generic1 ata1-master: type=disk, path="disk2.img", mode=flat, cylinders=1024, heads=16, spt=63, translation=none, model=generic2 ata1-slave: type=disk, path="disk3.img", mode=flat, cylinders=1024, heads=16, spt=63, translation=none, model=generic3
Boot and as usual do
rm -r /sys/compile/* cd /sys/i386/conf
Edit the disk parts of BOCHS to:
controller wd0 at isa? port "IO_WD1" bio irq 14 vector wdintr controller wd1 at isa? port "IO_WD2" bio irq 15 vector wdintr disk wd0 at wd0 drive 0 disk wd1 at wd0 drive 1 disk wd2 at wd1 drive 0 disk wd3 at wd1 drive 1
Compile the kernel
config BOCHS cd /sys/compile/BOCHS make newvers make depend make mv /386bsd /386bsd.old cp 386bsd /386bsd
mknod the new devices:
cd /dev sh /dev/MAKEDEV wd2 wd3
reboot
sync; sync; sync shutdown -rf now
At boot there are, the controllers, but not completely as expected, 8 instead of the 4 slots. It is not making sense.
wd0 0:<generic> 1:<generic1> 2:<generic> 3:<generic1> 4:<generic> at 0x1f0 irq 1 4 on isa wd1 0:<generic> 1:<generic3> 2:<generic> 3:<generic1> 4:<generic> at 0x170 irq 1 5 on isa
They mount fine.
mkdir /mnt/1 /mnt/2 /mnt/3 mount /dev/wd1a /mnt/1 mount /dev/wd2a /mnt/2 mount /dev/wd3a /mnt/3
But, when you try to map them back to your emulated disks, on guest:
echo XXX_wd1XXX >/mnt/1/driveno echo XXX_wd2XXX >/mnt/2/driveno echo XXX_wd3XXX >/mnt/3/driveno
on host:
$ for i in disk1.img disk2.img disk3.img ; do printf "$i: ";strings $i |grep XXX_wd; echo ;done|grep . disk1.img: XXX_wd3XXX disk2.img: disk3.img: XXX_wd1XXX
One & three got swapped and 2 seems missing. Not good.
Dugo 11:28, 9 May 2010 (UTC)
