Thread
BrickOven™ PizzaBox Hack revisited . . .
. . . but not in the same vein . . .
I've mentioned this Hack in passing recently, here's linkage to the genesis of the project . . .
BrickOvenCube/6/605/MicroQuadraCluster
. . . none of Bigsadhu's MicroQuadraFeetsMacs™ ever made it to from the Isle of Kiwi to the Isle of Big Apple, but I'm concurrently completing/consolidating my collection . . .
. . . a hopeless task and more than likely thankless when the grlf inspects the level of clutter reduction that I'll ever manage (or wish) to achieve. :
This unrealized Design Study will help somewhat and hopefully look really cool at the same time . . .
pic
pic
New Config:
Suggestions on what Cool Card might tempt me into adding another sub-Quadra level LC to the stack?
I've mentioned this Hack in passing recently, here's linkage to the genesis of the project . . .
BrickOvenCube/6/605/MicroQuadraCluster
. . . none of Bigsadhu's MicroQuadraFeetsMacs™ ever made it to from the Isle of Kiwi to the Isle of Big Apple, but I'm concurrently completing/consolidating my collection . . .
. . . a hopeless task and more than likely thankless when the grlf inspects the level of clutter reduction that I'll ever manage (or wish) to achieve. :
This unrealized Design Study will help somewhat and hopefully look really cool at the same time . . .
pic
pic
New Config:
Looks like I'll need to add a third MoBo to the mix to retain the symmetry of the OvenStack, maybe another MicroQuadraFeetsMac™ :?:
Suggestions on what Cool Card might tempt me into adding another sub-Quadra level LC to the stack?
What is the point of the orange loudspeakers?
BTW, i imagine this could be really an epic cluster for image rendering. Slap NetBSD on it (6.1 is nearly done and works smoothly on my Q650), add some Beowulf from PKGSRC as well as some kind of raytracer and you are done!
Or a distcc compile farm for 68k packages.
Not fast, but epic and awesome.
I say go for it. Do it. Do it now! I can't, i have only one LC475.
BTW, i imagine this could be really an epic cluster for image rendering. Slap NetBSD on it (6.1 is nearly done and works smoothly on my Q650), add some Beowulf from PKGSRC as well as some kind of raytracer and you are done!
Or a distcc compile farm for 68k packages.
Not fast, but epic and awesome.
I say go for it. Do it. Do it now! I can't, i have only one LC475.
Those are semi-scaled renditions of the brassy speakers in the bottom of each of the six 'zaBoxen, only three of the fans are utilized, the contrast is for differentiation. [
] ]'>
I've always wanted to get under the hood of Linux, but decided against it, I enjoy playing with the toys in the physical realm, drivers and cards are where it's at for me.
] ]'>I've always wanted to get under the hood of Linux, but decided against it, I enjoy playing with the toys in the physical realm, drivers and cards are where it's at for me.
I see.
Your BrickOven could solve a NetBSD problem. NetBSD comes, in contrast to Linux, out of one hand, one source code repository. This has NetBSD enabled to use crosscompiling (compiling is the task of generating machine code or binaries from human written code). That means, i can compile the Operating System (kernel, shell, libs, apps, install media, X11 GUI, everything) for a slow architecture such as mac68k on a fast architecture such as amd64 or i386.
NetBSD comes with all the tools one needs to start being productive. For example, a compiler, and GUI editor, a GUI mailer. But not everything is there. For example, there is no browser. You can add a package. But those packages have to be compiled at some time. For this, NetBSD has a system called PKGSRC, basically a directory tree that contains scripted instructions on where to download sourcecode and how to compile it. There are over 12000 packages to be built with each release, for each architecture.
Since the sourcecode in those thousands of packes comes from different sources, it can't be crosscompiled. Which is why you need to compile it on the target architecture. And there you have the problem. Mac68k is incredibly slow. Compiling a few packages needs days. The BrickOven could shorten the time to compile packages significantly. Indeed, one or two BrickOven and a fast networked fileserver could reduce the compiletime of all packages from several month to mere weeks. 8-o
So, where can i order a 8 Node BrickOven with LC475 boards clocked to 40MHz, NIC, 256MB Ram each and a basic NetBSD with distcc and ccache preinstalled? ;D
Your BrickOven could solve a NetBSD problem. NetBSD comes, in contrast to Linux, out of one hand, one source code repository. This has NetBSD enabled to use crosscompiling (compiling is the task of generating machine code or binaries from human written code). That means, i can compile the Operating System (kernel, shell, libs, apps, install media, X11 GUI, everything) for a slow architecture such as mac68k on a fast architecture such as amd64 or i386.
NetBSD comes with all the tools one needs to start being productive. For example, a compiler, and GUI editor, a GUI mailer. But not everything is there. For example, there is no browser. You can add a package. But those packages have to be compiled at some time. For this, NetBSD has a system called PKGSRC, basically a directory tree that contains scripted instructions on where to download sourcecode and how to compile it. There are over 12000 packages to be built with each release, for each architecture.
Since the sourcecode in those thousands of packes comes from different sources, it can't be crosscompiled. Which is why you need to compile it on the target architecture. And there you have the problem. Mac68k is incredibly slow. Compiling a few packages needs days. The BrickOven could shorten the time to compile packages significantly. Indeed, one or two BrickOven and a fast networked fileserver could reduce the compiletime of all packages from several month to mere weeks. 8-o
So, where can i order a 8 Node BrickOven with LC475 boards clocked to 40MHz, NIC, 256MB Ram each and a basic NetBSD with distcc and ccache preinstalled? ;D
Interesting application you've got there. It's all too Greek a GeekSpeak for me to do much more than grok the surface, but it sounds cool.
When all those MicroQuadras were headed to the recycler/dump down under, this was the only reasonably efficient way I could come up with to get some of the goodies off the streets of Oz and into a small package for repackaging here in the States. Doing a SETI work unit (delivered too slowly to be practical) was the only application I had in mind for it at the time.
It was a pipe dream kinda thing, but I'm looking into doing the Rev II version for real this time. I'll make up the plans as I go, I'm thinking a cold-plug drawer/carrier will be in order for expansion card playtime, but unnecessary for your application.
The dearth of individual 2.5" SCSI boot drives almost 11 years later is a major concern. :-/
When all those MicroQuadras were headed to the recycler/dump down under, this was the only reasonably efficient way I could come up with to get some of the goodies off the streets of Oz and into a small package for repackaging here in the States. Doing a SETI work unit (delivered too slowly to be practical) was the only application I had in mind for it at the time.
It was a pipe dream kinda thing, but I'm looking into doing the Rev II version for real this time. I'll make up the plans as I go, I'm thinking a cold-plug drawer/carrier will be in order for expansion card playtime, but unnecessary for your application.
The dearth of individual 2.5" SCSI boot drives almost 11 years later is a major concern. :-/
If you made them out of the IDE-equipped performas you could load up on CF adapters and solve that problem. You could also then make a backplane because all the boards would have their connections in one spot.
Could also then use something like an ATX power supply to drive it all with a single keyswitch that shorts PWR_OK to GND to turn the whole thing on.
Could also then use something like an ATX power supply to drive it all with a single keyswitch that shorts PWR_OK to GND to turn the whole thing on.
No need for disks, netboot. Use a simple loader on a floppy.
As for my previous text, i guess one could compress it like that: NetBSD itself can be made on fast machines for slow targets. But the packages must be made on that slow target which takes month. A bunch of BrickOven would reduce the time to weeks, maybe even days, thus improving release cycles.
I'm just wondering, what would be your usage for a BrickOven? It's nice to build a cluster and all, but it should have something to do, right? :approve:
As for my previous text, i guess one could compress it like that: NetBSD itself can be made on fast machines for slow targets. But the packages must be made on that slow target which takes month. A bunch of BrickOven would reduce the time to weeks, maybe even days, thus improving release cycles.
I'm just wondering, what would be your usage for a BrickOven? It's nice to build a cluster and all, but it should have something to do, right? :approve:
You could put your loader and maybe evev the OS on dougg3's ROM SIMM if you populate the empty SIMM Slot pads on all the MicroQuadra boards.
Stacking a rack of Quadra 650 boards for your NetBSDbox would be even better, full .040s and AAUI all around with oodles of lovely 72pin SIMM Slots for trag's 32MB sticks! }
Stacking a rack of Quadra 650 boards for your NetBSDbox would be even better, full .040s and AAUI all around with oodles of lovely 72pin SIMM Slots for trag's 32MB sticks! }
@bbraun: I don't have one of dougg3s SIMMs and i don't have the skill to add any sockets either, i'm afraid. I just recently started soldering crystals and caps.
NetBSD would benefit if the used virtual memory would otherwise approach the amount of physical memory. With more ram there would be still room for file caches and no need to swap out memory.
But there are other positive effects of more ram. You could use --pipe while compiling code. That way the compiler wouldn't have to use as much temporary files on disk, which is a very costly operation in terms of time. So, more physical memory could speed up compilation quite a bit if the right compiler flags are set.
One could even dare to try using make -j2 AND --pipe together, with that much ram. That should keep the CPU constantly under load, not wasting any time while accessing the net or disk.
@Trash80toHP_Mini: Yes, one could do a BrickOvenPro with Q650 boards, but where does one get the boards? Also the boards are larger and probably use up more energy compared to a Q605 and a NIC (same CPU, same clockspeed).
Don't forget, most people here didn't have macs back then, they had mostly C64/Amiga and then PCs. That's why almost all early macs are more rare here. Also a bit more pricey. Some things you can't find at all. For example, there are no NUBUS or PDS cards listed at ebay. Not one! Accelerator cards? I haven't seen any at Ebay germany. Ever.
NetBSD would benefit if the used virtual memory would otherwise approach the amount of physical memory. With more ram there would be still room for file caches and no need to swap out memory.
But there are other positive effects of more ram. You could use --pipe while compiling code. That way the compiler wouldn't have to use as much temporary files on disk, which is a very costly operation in terms of time. So, more physical memory could speed up compilation quite a bit if the right compiler flags are set.
One could even dare to try using make -j2 AND --pipe together, with that much ram. That should keep the CPU constantly under load, not wasting any time while accessing the net or disk.
@Trash80toHP_Mini: Yes, one could do a BrickOvenPro with Q650 boards, but where does one get the boards? Also the boards are larger and probably use up more energy compared to a Q605 and a NIC (same CPU, same clockspeed).
Don't forget, most people here didn't have macs back then, they had mostly C64/Amiga and then PCs. That's why almost all early macs are more rare here. Also a bit more pricey. Some things you can't find at all. For example, there are no NUBUS or PDS cards listed at ebay. Not one! Accelerator cards? I haven't seen any at Ebay germany. Ever.
I love this idea, I've got four 475/605 Mobos to recap and a couple of NICs already. One of the MoBos has a factory installed SIMM slot to test the ROMboot/bootstrapping netboot options.
If nyone interested in this test, keep an eye out on eBay.US for fugly 475/605s I can bottom fish and for good deals on those and the 128 MB SIMMs-n-NICs and full '040s/donors. I can build one (or both) versions while I'm at it. It'll be fun to test this application. I've probably got six full '040s for the testing phase
Can you run it remotely from Germany to do your compiling? }
If nyone interested in this test, keep an eye out on eBay.US for fugly 475/605s I can bottom fish and for good deals on those and the 128 MB SIMMs-n-NICs and full '040s/donors. I can build one (or both) versions while I'm at it. It'll be fun to test this application. I've probably got six full '040s for the testing phase
Can you run it remotely from Germany to do your compiling? }
I kind of have a similar concept in mind, but for space reasons. To have a single tower with logic boards containing each 68k architecture, from 68000 up to '040, with a KVM, so one box can run any existing 68k Mac application without taking up half a room.
Not at all. A properly designed backplane would replace all the ribbon cables with PCB traces.
Maybe you could buy this and make a 72 Ghz Intel Atom Cluster
http://www.ebay.com/itm/Bulk-Lot-of-45-HP-t5740-Thin-Client-Computer-Intel-Atom-1-6GHz-4GB-Ram-4GB-Flash-/310639718370?pt=US_Thin_Clients&hash=item485391efe2
http://www.ebay.com/itm/Bulk-Lot-of-45-HP-t5740-Thin-Client-Computer-Intel-Atom-1-6GHz-4GB-Ram-4GB-Flash-/310639718370?pt=US_Thin_Clients&hash=item485391efe2
On monitor mounts, no less.
As JT mentioned, please don't do this. It literally adds nothing to the thread. Like, it contributes even less than "me too" and in general, it's not a very good schtick.
Also, as a general rule, I approve significantly of what's going to end up being 68k Mac blades.
I would approve significantly of a version of this based on Performa 630/6200/6400 boards, especially if you can figure out how to make the units share an optical drive without restarting or shutting down every system in the enclosure, and of course KVM into a well-integrated enclosure is always a plus.
Something like the tower version of this: http://www.fujitsu.com/fts/products/computing/servers/primergy/blades/bx400/ -- In fact, if you put it on castors, the whole thing becomes even better.
Yes, sir, i believe i can :approve: . I'll look into netbooting NetBSD on a LC475 from a floppy this weekend. Custom ROMs are fine, but maybe not really needed just yet.
It probably would be best and least intrusive to use a virtual machine to run the needed network services. What kind of VM can you run? Can you run VMWare virtual machines?
Getting the BrickOven to run stable under load (that means, providing proper networking connections, proper power supply, electromagnetic shielding, stable and plenty ram), that is the real problem. The software side could be done by every two-bit Unix admin.
Therein lies the rub. I'm not an admin of any type, by any stretch of the imagination . . .
. . . unless SneakerNet counts? :lol:
Would giving each MicroQuadra its own dedicated SCA drive help at all?
I'll look into the Quadra 630/Performa 6xx angle, that'd be really easy. I wouldn't even bother trying to make a backplane, just remove all the plastics and bolt 'em up with standoffs . . .
. . . ooooh!!!!! :O
< scampers off to play with hardware >
I can mount 'em vertically in bricks of four on the TelCo rack. Two bricks will fit under the 32" HDTV with room left over for a KM drawer.
Unfortunately the Two SIMM Slotted 640 DOS variant is in demand, those would rock, but I only have the one Q630 MoBo ATM. :-/
CS1 NICs will be difficult to source as well I think.
I've already got The OmniView Mac converter and MiniView four port PS/2 KVM, the cables for which can easily be converted to ADB. Would a "KVM'd" serial port connection be of any use?
-- Chassis would be a galvanized sheet metal enclosure behind the uprights for added cubic
-- largest cooling fan available to boost airflow on back of chassis
-- weatherstrip guide the exhaust fans, directing airflow toward auxiliary fan on backplane
-- MiniView four port PS/2 KVM with converted input connectors
-- Power Strip
Advantages:
-- retains Class A RFI shielding
-- retains UL approved packaging
-- available FDDs for boot
-- IDE a/o CD bay SCA converter options
I've got the MiniView A/B switch to gang two bricks of four Nodes each already hooked up to the Mac Converter . . .
. . . with four more 4 Port Miniview KVMs I can handle 4 Bricks/Sixteen nodes . . .
. . . and a Foundry Networks 24 port thingamajig If I decide to fill the Rack . . .
. . . to run it as a space heater for the winter months. :lol:
. . . unless SneakerNet counts? :lol:
Would giving each MicroQuadra its own dedicated SCA drive help at all?
I'll look into the Quadra 630/Performa 6xx angle, that'd be really easy. I wouldn't even bother trying to make a backplane, just remove all the plastics and bolt 'em up with standoffs . . .
. . . ooooh!!!!! :O
< scampers off to play with hardware >
I can mount 'em vertically in bricks of four on the TelCo rack. Two bricks will fit under the 32" HDTV with room left over for a KM drawer.
Unfortunately the Two SIMM Slotted 640 DOS variant is in demand, those would rock, but I only have the one Q630 MoBo ATM. :-/
CS1 NICs will be difficult to source as well I think.
I've already got The OmniView Mac converter and MiniView four port PS/2 KVM, the cables for which can easily be converted to ADB. Would a "KVM'd" serial port connection be of any use?
-- Chassis would be a galvanized sheet metal enclosure behind the uprights for added cubic
-- largest cooling fan available to boost airflow on back of chassis
-- weatherstrip guide the exhaust fans, directing airflow toward auxiliary fan on backplane
-- MiniView four port PS/2 KVM with converted input connectors
-- Power Strip
Advantages:
-- retains Class A RFI shielding
-- retains UL approved packaging
-- available FDDs for boot
-- IDE a/o CD bay SCA converter options
I've got the MiniView A/B switch to gang two bricks of four Nodes each already hooked up to the Mac Converter . . .
. . . with four more 4 Port Miniview KVMs I can handle 4 Bricks/Sixteen nodes . . .
. . . and a Foundry Networks 24 port thingamajig If I decide to fill the Rack . . .
. . . to run it as a space heater for the winter months. :lol:
I'm not sure, but i believe that 10 MBit ethernet to a fast fileserver with large buffers and maybe even a SSD is faster than any local disk. Mind you, sustained read or write isn't important, only random access times count.
At the weekend i'll play with the software side. :approve:
At the weekend i'll play with the software side. :approve:
Just to let you know, you are not the first planning a 68k-mini-cluster. And i am not the first to connect the dots and think package-compile-cluster:
http://comments.gmane.org/gmane.os.netbsd.ports.mac68k/5448
Can't wait for the weekend to test some things. Haven't really played with the obscure stuff in NetBSD for years. I believe there is no easy netboot solution yet, i have to compile a special kernel. The generic kernel is 3.6 MB uncompressed, so i have to shrink it quite a bit, too. :approve:
As for disks, maybe they are a tad faster after all at random access, they are for sure at continuous transfers. This can be tested.
But the idea of not having them in the BrickOven is not without value. Imagine, no noise. If you assume a BrickOven with 7 nodes, you would have about 70 watts peak power you would have to provide on top. Not to speak of heat dissipation and maintenance.
http://comments.gmane.org/gmane.os.netbsd.ports.mac68k/5448
Can't wait for the weekend to test some things. Haven't really played with the obscure stuff in NetBSD for years. I believe there is no easy netboot solution yet, i have to compile a special kernel. The generic kernel is 3.6 MB uncompressed, so i have to shrink it quite a bit, too. :approve:
As for disks, maybe they are a tad faster after all at random access, they are for sure at continuous transfers. This can be tested.
But the idea of not having them in the BrickOven is not without value. Imagine, no noise. If you assume a BrickOven with 7 nodes, you would have about 70 watts peak power you would have to provide on top. Not to speak of heat dissipation and maintenance.
Why not just use remote desktop software to access each system? If you run MacOS you got Apple Remote Access and if you do run a BSD you got pretty much every other method to access the system. A KVM arrangement will give you a stupid large mess of cables. I still do not see why you need a CD drive for each. If you're networked you only need to mount a remote volume and pull data from there. Running SCA drives will also require another layer for each two slices you run. You build a disk image on one system and clone it to multiple CF cards.
I thought stupid large messes of cables were teh point of having a rack! :lol:
BrickOven2™ is meant for playing with each level independently over KVM. Having LC, LCII, LCIII, and three LC475/Q605 layers to make up the six CPU PDS Expansion Card PlayStation, so it needs KVM.
The original BrickOven™ was a six level 68040 hack looking for an application. It was a design exercise intended to hoover up some of the large excess of MicroQuadra™ boards in Aus.
The RackOven™ is just a day old design exercise. It's more feasible to run 1 to 6 bricks of four Q630 nodes each in a TelCo Rack than to build even one BrickOven™ if you really think about it. As far as CDs go, only one person mentioned using a single one for the array. I think using the CD Bay in each of the 6xx boxen for an adapted, fast access U160 or SCA Drive makes the most sense. No need for NetBooting or startup floppies and plenty of space for VM/scratch disk/whatever.
I'm not a UNIX geek or Network admin of any sort, I HATE networking, but KVMs and SneakerNet I've got down pat.
) Your OKness is the least of concerns. :lol:
One nice thing about going with the 6xx version is that the case parts are pretty much flat slabs for storage, as opposed to the complex, voluminous forms of the 'zaBoxen.
I got a kick out of knocking the LisaP graphic out in AI this morning, I think I'll do a front view of what a six brick/24 node RackOven™ might look like in my TelCo Rack. [}] ]'>
One nice thing about going with the 6xx version is that the case parts are pretty much flat slabs for storage, as opposed to the complex, voluminous forms of the 'zaBoxen.
I got a kick out of knocking the LisaP graphic out in AI this morning, I think I'll do a front view of what a six brick/24 node RackOven™ might look like in my TelCo Rack. [}
] ]'>This whole thing really tickles my geek bone.
I sat down today to check out the source tree for NetBSD. Turns out quite a bit has changed since the old days. But i managed to crosscompile a custom kernel which compresses to about 1 mb. Now i'm looking at tricks to shave a few more kb from the kernel.
So, what would a minimal system 7 floppy cost me in terms of size? I really just need it to get starting and run the bootloader. I don't need fonts, drivers, symbols or anything at all.
I sat down today to check out the source tree for NetBSD. Turns out quite a bit has changed since the old days. But i managed to crosscompile a custom kernel which compresses to about 1 mb. Now i'm looking at tricks to shave a few more kb from the kernel.
So, what would a minimal system 7 floppy cost me in terms of size? I really just need it to get starting and run the bootloader. I don't need fonts, drivers, symbols or anything at all.
I believe a diskless BrickOven would perform better if files reside on a fast NFS server. Also it saves about 10 watt per node peak power need. Say you have 30 watt per node peak, with moving disk this would be 40 watt. If you use 7 nodes (wich is a perfect number for network switching reasons, i'll use it as an example) per BrickOven that would be the difference between transporting away 210 watts or 280 watts of heat.
Now, the numbers are just pulled out of my still incredibly good looking butt, but you probably get the way i think. The less hardware, the more dense the package can be packed without heat problems. Also it would be the difference between 35 kw/h and 47 kw/h for a week of serious work.
You might think that heat and energy isn't a problem. It becomes a problem when all nodes do serious work. How much energy does a floppy waste when idle?
If you want to use disks, why not, do it. But i want to research the floppy option regardless.
Now, the numbers are just pulled out of my still incredibly good looking butt, but you probably get the way i think. The less hardware, the more dense the package can be packed without heat problems. Also it would be the difference between 35 kw/h and 47 kw/h for a week of serious work.
You might think that heat and energy isn't a problem. It becomes a problem when all nodes do serious work. How much energy does a floppy waste when idle?
If you want to use disks, why not, do it. But i want to research the floppy option regardless.
Another option must be found. :O
A floppy holds about 1.4 mb of files. My smallest possible kernel is 930 kb compressed. I need another 100 kb for the bootloader and 550 kb for the System file (system 7 de from the install floppy). I'll also need space for the right enabler.
I'm not aware of any System 7 file that is smaller. System 6 doesn't work, i need it 32 bit safe for the bootloader.
So it seems i can not use a simple floppy (i have a bunch of factory new 2 mb floppys for IBM PS/2 50 and up, alas, there is no support in the drives or mac firmware for them).
Maybe another approach should be tested. Suppose i have a netatalk server with a share that holds the bootloader and the NetBSD kernel. All i need is a system 7 floppy that is network aware, logs in automagically, and then starts the bootloader. Piece of cake, right?
A floppy holds about 1.4 mb of files. My smallest possible kernel is 930 kb compressed. I need another 100 kb for the bootloader and 550 kb for the System file (system 7 de from the install floppy). I'll also need space for the right enabler.
I'm not aware of any System 7 file that is smaller. System 6 doesn't work, i need it 32 bit safe for the bootloader.
So it seems i can not use a simple floppy (i have a bunch of factory new 2 mb floppys for IBM PS/2 50 and up, alas, there is no support in the drives or mac firmware for them).
Maybe another approach should be tested. Suppose i have a netatalk server with a share that holds the bootloader and the NetBSD kernel. All i need is a system 7 floppy that is network aware, logs in automagically, and then starts the bootloader. Piece of cake, right?
I've finally taken a look at mac68k netbsd.
Given what I've posted here, I'm 99% positive it's entirely feasible to create a MacOS-less booter for netbsd. Not that I'm volunteering for such a thing, just pointing out that it is possible. Then maybe the netbsd mac68k installation process could be a little less painful with a bootable iso or something.
A couple thoughts on how to accomplish this:
1) bootblocks with the right version let you execute arbitrary code right from the boot blocks. Best case, this would let you get away with no HFS partitions at all. Worst case, you have a MacOS-less HFS filesystem the bootloader loads from.
2) If the bootblocks approach fails, you can always fall back to creating a pseudo-System file, and the 'boot' resources will be executed by the ROM at boot. Do the booting here.
The NetBSD kernel is currently relying on the bootloader passing in a bunch of information, such as the address of the framebuffer, the amount of memory, and also relying on the ROM/MacOS's MMU setup. For instance, since NetBSD does no initialization of any mac memory controller, it is relying on RAM being contiguous and mapped at address 0 and whatever size the bootloader passed in. It would still be possible to preserve this model with MacOS-less booting, but it'd be nice to move away from that and initialize and map memory yourselves, so you can do useful things like use 128MB SIMMs on djMEMC based machines without needing custom ROMs.
Additionally, there's some pretty low hanging performance improvements (ok, not so much low hanging fruit as much as tripping over watermelons on the ground), particularly in the area of libc. You can probably get fairly substantial improvements in build times with some rather mundane changes to libc, just to improve executable launch time, reduce io and memory overhead.
Since I've finally got netbsd installed, I'll start poking around a bit more.
Given what I've posted here, I'm 99% positive it's entirely feasible to create a MacOS-less booter for netbsd. Not that I'm volunteering for such a thing, just pointing out that it is possible. Then maybe the netbsd mac68k installation process could be a little less painful with a bootable iso or something.
A couple thoughts on how to accomplish this:
1) bootblocks with the right version let you execute arbitrary code right from the boot blocks. Best case, this would let you get away with no HFS partitions at all. Worst case, you have a MacOS-less HFS filesystem the bootloader loads from.
2) If the bootblocks approach fails, you can always fall back to creating a pseudo-System file, and the 'boot' resources will be executed by the ROM at boot. Do the booting here.
The NetBSD kernel is currently relying on the bootloader passing in a bunch of information, such as the address of the framebuffer, the amount of memory, and also relying on the ROM/MacOS's MMU setup. For instance, since NetBSD does no initialization of any mac memory controller, it is relying on RAM being contiguous and mapped at address 0 and whatever size the bootloader passed in. It would still be possible to preserve this model with MacOS-less booting, but it'd be nice to move away from that and initialize and map memory yourselves, so you can do useful things like use 128MB SIMMs on djMEMC based machines without needing custom ROMs.
Additionally, there's some pretty low hanging performance improvements (ok, not so much low hanging fruit as much as tripping over watermelons on the ground), particularly in the area of libc. You can probably get fairly substantial improvements in build times with some rather mundane changes to libc, just to improve executable launch time, reduce io and memory overhead.
Since I've finally got netbsd installed, I'll start poking around a bit more.
BTW, this is the box that builds all the m68k packages (actually a few architectures use these packages):
http://lilith.ziaspace.com/
@Trash80toHP_Mini: i feel guilty that i have shanghaied your thread with all that NetBSD nonsense. :lol:
http://lilith.ziaspace.com/
@Trash80toHP_Mini: i feel guilty that i have shanghaied your thread with all that NetBSD nonsense. :lol:
I would say that depends on how clever all the software parts come together and how stable the hardware part gets.
Let's just assume that any 68k machine can be beaten when doing a job that can be broken into many smaller jobs. Compiling code using makefiles is such a job. One board compiles something, another board compiles something else, a third links the results and a fourth compresses everything into a neat package. Meanwhile the first starts compiling the next piece of code.
Lilith has to do it all by itself. So, even if it is, because of it's advanced hardware, 5 times faster, we can use 5 or more boards. I have no real preference towards BrickOven or RackOven, I guess one should benchmark the boards properly and then decide. Also availability could be a question.
However, there is no rule that all boards have to be the same or even have to have the same clock speed. Even a 68030+FPU here or there would be acceptable. As long as the hardware is stable under load.
Let's just assume that any 68k machine can be beaten when doing a job that can be broken into many smaller jobs. Compiling code using makefiles is such a job. One board compiles something, another board compiles something else, a third links the results and a fourth compresses everything into a neat package. Meanwhile the first starts compiling the next piece of code.
Lilith has to do it all by itself. So, even if it is, because of it's advanced hardware, 5 times faster, we can use 5 or more boards. I have no real preference towards BrickOven or RackOven, I guess one should benchmark the boards properly and then decide. Also availability could be a question.
However, there is no rule that all boards have to be the same or even have to have the same clock speed. Even a 68030+FPU here or there would be acceptable. As long as the hardware is stable under load.
Interesting, that sounds a lot like Systolic Multi-Processing. I was just reading about that in my RocketShare 1.0 Manual.
The BrickOven PizzaPaddles can address more memory, but lack the IDE<->CF boot option of the RackOven.
Under NetBSD, could an IDE SSD boot disk/VM option in the 630 best the PizzaPaddle's 132MB of DRAM?
I just ordered a pair of 128MB SIMMs. }
The BrickOven PizzaPaddles can address more memory, but lack the IDE<->CF boot option of the RackOven.
Under NetBSD, could an IDE SSD boot disk/VM option in the 630 best the PizzaPaddle's 132MB of DRAM?
I just ordered a pair of 128MB SIMMs. }
Good question.
I would benchmark it, but it appears my Performa 630 is half dead. It boots into the system, then, after a few seconds it starts to beep frantically, as if someone is sitting on the keyboard, then it hangs. Keyboard is known good, PRAM zapped, battery full.
I can tell you this, Win98 running on a 512 MB CF card with a cheap IDE-adaptor is mighty fast on a pentium 66. But only at starting/reading/writing stuff. Actual computation is only as fast as the CPU/memory interface allows. Compiling pkgsrc is a mix out of computation (the actual compiling) and reading/writing (functions, header files, libs, linking and so on).
Hard to say .
I would benchmark it, but it appears my Performa 630 is half dead. It boots into the system, then, after a few seconds it starts to beep frantically, as if someone is sitting on the keyboard, then it hangs. Keyboard is known good, PRAM zapped, battery full.
I can tell you this, Win98 running on a 512 MB CF card with a cheap IDE-adaptor is mighty fast on a pentium 66. But only at starting/reading/writing stuff. Actual computation is only as fast as the CPU/memory interface allows. Compiling pkgsrc is a mix out of computation (the actual compiling) and reading/writing (functions, header files, libs, linking and so on).
Hard to say
. I'm likin' this project more & more with every new question.A pair of 128MB SIMMs were supposed to have been delivered yesterday, but the order got mixed up, I got someone else's DIMMs. When I get that squared away, it'll be time to start playing games with Quadra 605 & Quadra 630 variants. I can start collecting more LC style NICs, they're compatible with both platforms, neh?
bbraun, what's the likelihood of putting an acceptably customized NetBSD BootROM in a populated ROM Slot of either the 605 or 630? Might we need neither the FDD nor HDD for each blade/box?
Dunno, local fast storage has always been my goal, I still don't trust, and have always hated, networking.
I put a ROM socket on my 630 a while back and tested it out. I can't remember the exact results, but I believe it worked it just doesn't share any overlap with other ROMs so any customizations would be 630 specific, which made it a bit uninteresting at the time (especially considering they rom socket is unpopulated).
But, non-AV 040 machines don't seem to map more than 1MB of ROM, so no ROM disk anyway.
I have been working on trying to have netbsd reconfigure the djmemc on 610/650/800 machines to support up to 520MB of RAM, with mixed success. Essentially the djmemc has a configuration register per bank that decides what physical address each bank responds to (you only get to control address bits 22-29). And you want all the memory to be contiguous, you don't want any holes. For example, on an 8MB (soldered) 650, the first 2 banks are 4MB each, so bank 0 would be at address "0", bank 1 would start 4MB above bank 0, and so on. When doing this in ROM on boot, it's fairly straightforward. You're running from ROM so you don't have any danger of pulling the rug out from under yourself, and you can setup banks however you want. But when doing it from the NetBSD kernel, you're running from RAM, and you need to insert new memory in between existing allocations. For example, the stock ROM will only allocate 32MB/bank. All the memory is tightly packed on 32MB boundaries. To enable 64MB/bank, you need to push out all subsequent banks by the extra 32MB. And make sure the code you're running from didn't just get moved out. And then there's interleaving, where if you change that, you've just scrambled the contents of those banks.
Anyway, I believe I have a hacked up version that works, but there seems to be some rather fundamental problems with the NetBSD page map, at least on the mac68k port. Even with a stock kernel, doing large allocations, or even just touching lots of pages causes panics. I've gotten a half dozen or so distinct pmap panics on the stock kernel, all just while trying to test that the extra physical memory is usable. But even without my changes, NetBSD seems to panic just using the stock ROM allocations.
So, it looks like I get to try to track down these other bugs before I can even validate my own changes. In order to determine if this is mac68k port specific or general to the m68k implementation (most of the pmap implementation seems to be shared among all 68k ports), I'm trying to get netbsd/hp300 going on 425e. Unfortunately, the 425e doesn't support serial console in ROM, and NetBSD doesn't support the framebuffer, and then the netbsd bootloader is trying to use the framebuffer it doesn't support, rather than just switching over to serial console. So... Now I'm building an entire cross compiling hp300 setup so I can fix the hp300 bootloader so I can test pmap bugs so I can test my own changes. AFAICT, NetBSD/mac68k isn't well tested on >128MB configs in general, and isn't tested at all on >256MB configs.
I already had to modify the NetBSD/mac68k booter, since it is using an unsigned char to represent the number of MB of RAM in the machine, which then gets passed to the NetBSD kernel. Even stock, you can put 260MB in a 650 or 800, and the booter is incapable of representing that. Anyway, I've got those changes done, but holy cow.
But, non-AV 040 machines don't seem to map more than 1MB of ROM, so no ROM disk anyway.
I have been working on trying to have netbsd reconfigure the djmemc on 610/650/800 machines to support up to 520MB of RAM, with mixed success. Essentially the djmemc has a configuration register per bank that decides what physical address each bank responds to (you only get to control address bits 22-29). And you want all the memory to be contiguous, you don't want any holes. For example, on an 8MB (soldered) 650, the first 2 banks are 4MB each, so bank 0 would be at address "0", bank 1 would start 4MB above bank 0, and so on. When doing this in ROM on boot, it's fairly straightforward. You're running from ROM so you don't have any danger of pulling the rug out from under yourself, and you can setup banks however you want. But when doing it from the NetBSD kernel, you're running from RAM, and you need to insert new memory in between existing allocations. For example, the stock ROM will only allocate 32MB/bank. All the memory is tightly packed on 32MB boundaries. To enable 64MB/bank, you need to push out all subsequent banks by the extra 32MB. And make sure the code you're running from didn't just get moved out. And then there's interleaving, where if you change that, you've just scrambled the contents of those banks.
Anyway, I believe I have a hacked up version that works, but there seems to be some rather fundamental problems with the NetBSD page map, at least on the mac68k port. Even with a stock kernel, doing large allocations, or even just touching lots of pages causes panics. I've gotten a half dozen or so distinct pmap panics on the stock kernel, all just while trying to test that the extra physical memory is usable. But even without my changes, NetBSD seems to panic just using the stock ROM allocations.
So, it looks like I get to try to track down these other bugs before I can even validate my own changes. In order to determine if this is mac68k port specific or general to the m68k implementation (most of the pmap implementation seems to be shared among all 68k ports), I'm trying to get netbsd/hp300 going on 425e. Unfortunately, the 425e doesn't support serial console in ROM, and NetBSD doesn't support the framebuffer, and then the netbsd bootloader is trying to use the framebuffer it doesn't support, rather than just switching over to serial console. So... Now I'm building an entire cross compiling hp300 setup so I can fix the hp300 bootloader so I can test pmap bugs so I can test my own changes. AFAICT, NetBSD/mac68k isn't well tested on >128MB configs in general, and isn't tested at all on >256MB configs.
I already had to modify the NetBSD/mac68k booter, since it is using an unsigned char to represent the number of MB of RAM in the machine, which then gets passed to the NetBSD kernel. Even stock, you can put 260MB in a 650 or 800, and the booter is incapable of representing that. Anyway, I've got those changes done, but holy cow.
8-o ICK!!!! This firmware/bootware/software crap gives me a headache every time I even think about it. Nice work you've been doing, b.
I'll stick to hardware . . . I think I finally had stroke of luck getting the impossible thing purring along in the IIsi, the Rocket appears to be just about about as happy as can be.
This firmware/bootware/software crap gives me a headache every time I even think about it. Nice work you've been doing, b.I'll stick to hardware . . . I think I finally had stroke of luck getting the impossible thing purring along in the IIsi, the Rocket appears to be just about about as happy as can be.
bbraun. it seems you are doing good work. I believe it would benefit your goal if you would discuss your findings on the appropriate mailing lists (which are also available via gmane, in case you prefer web or nntp). Some of the original hackers are still around. There isn't much development going on on mac68k these days. But i guess it is to be expected, if you consider that the platform is obsolete for about 20 years. |)
Building the cross toolchain is as easy as checking out the source tree (i think it's best if you worked on HEAD) and typing this:
Where /usr/build/ is a directory with lots of space. mac68k can be replaced with the architecture of your liking, sparc, macppc, hp300. Building your own kernel is as easy:
TECNEEQ is my kernel config file in /usr/src/sys/arch/mac68k/conf/TECNEEQ. The result will be /usr/build/releasedir/mac68k/binary/kernel/netbsd-TECNEEQ.gz, a good directory to export with netatalk, so you can boot directly from there.
Adjust the path for hp300 accordingly. Pity that you got one of the few models without framebuffer support. :'(
I wouldn't hang myself up on RAM, even 64 MB should do. You can always just add more nodes to mitigate the smaller file caches and resulting performance penalty from possible swapping. The work, that is package building, can be split over as many nodes as are available.
As for the Q650, it's the first time that i hear it supports 260 MB. My source says 136 MB max for the 8MB model. The same for Q800. Also let me remind you that, at the time the booter was written and the port was done, 32 MB (noncomposite) SIMM was about 2000 bucks. That means, to get the 136 MB one would have to fork over the tiny sum of $8000. That was a rare case then and nobody thought about 64 MB SIMMs because there was no 64MB SIMM in the beginning, so i guess that is the reason why nobody noticed the problem with the booter.
Until now that is, good work. :approve:
BTW, are you sure your RAM is noncomposite? It seems that the timing of composite RAM is sometimes off (the Q800 appears to be extremely picky when it comes to timings), which either result in a sad mac at boot, or random panics.
Building the cross toolchain is as easy as checking out the source tree (i think it's best if you worked on HEAD) and typing this:
Code:
./build.sh -m mac68k -R /usr/build/releasedir -O /usr/build/objectdir -T /usr/build/tooldir -D /usr/build/destdir tools
Code:
./build.sh -m mac68k -R /usr/build/releasedir -O /usr/build/objectdir -T /usr/build/tooldir -D /usr/build/destdir tools kernel=TECNEEQ releasekernel=TECNEEQAdjust the path for hp300 accordingly. Pity that you got one of the few models without framebuffer support. :'(
I wouldn't hang myself up on RAM, even 64 MB should do. You can always just add more nodes to mitigate the smaller file caches and resulting performance penalty from possible swapping. The work, that is package building, can be split over as many nodes as are available.
As for the Q650, it's the first time that i hear it supports 260 MB. My source says 136 MB max for the 8MB model. The same for Q800. Also let me remind you that, at the time the booter was written and the port was done, 32 MB (noncomposite) SIMM was about 2000 bucks. That means, to get the 136 MB one would have to fork over the tiny sum of $8000. That was a rare case then and nobody thought about 64 MB SIMMs because there was no 64MB SIMM in the beginning, so i guess that is the reason why nobody noticed the problem with the booter.
Until now that is, good work. :approve:
BTW, are you sure your RAM is noncomposite? It seems that the timing of composite RAM is sometimes off (the Q800 appears to be extremely picky when it comes to timings), which either result in a sad mac at boot, or random panics.
Me too!
tecneeq: thanks, I've been cross compiling the kernel and whatnot a bit (that's how I did the kernel hack that I think enables the djmemc bank configuration). I was able to get an hp300 bootloader built that works for my setup and a netbooting hp300. Unfortunately, it's not an exact comparison since the hp I'm using maxes out at 48MB, but at least it's an 040 vs. 040 comparison. The hp300 port seems to be pretty stable under memory pressure and large memory allocations, although unfortunately it's swapped in my case instead of physical on the mac68k machine. I could try reducing the mac's memory down to something comparable and rerun the test to see if it panics.
The 650 and 800 with a stock ROM work with up to 32MB per bank, with 2 banks / SIMM slot, and 4 SIMM slots. So that gives 256MB, plus the 8MB onboard for 264MB. To get that, you need 128MB SIMMs and then just lose half the RAM due to the ROM's lame djmemc configuration. Same deal with the 610, you just only have 2 SIMM slots. This is all the same as the 605, it's just the ROM initializes the 605's djmemc correctly, which is all I'm really doing: copying the 605's configuration.
As for not worrying about RAM, you're not going to get a faster backing store than RAM. And with 520MB, you can fit quite a bit. Like putting your objdir in RAM, which would make linking as fast as it'll ever get.
Plus, it's my thing. Coercing the kernel into reconfiguring the memory controller is waaaay more interesting to me than building packages.
If it happens to help, great!The ram is recommended by trag, and is fine with macos and a/ux, and with all my poking at the memory controller from macsbug. So I'm pretty confident in the RAM at this point. This is the system I used to develop/test all the 040 and djmemc ROM mods I've done, which include using huuuuge RAM disks and all kinds of other fun stuff.
Now that I've got a diskless hp300, I'm thinking of putting macos & the netbsd booter in ROM for the IIfx and running that diskless too. Being an 030, it'll be slower, but doesn't have the ROM addressing limitations I've encountered on the 040's.
Trash80: the 630 can take 128MB SIMMs, they just have to be the special ones. link
Looks like some 631's & 640's might be worth collecting on a lark. How should configuring VM on an SSD with some of this library crap work out in terms of a performance hit as opposed to RAM? Any better than just having it stashed on a Chiplet on the IDE bus?
Three more MicroQuadra boards might be nice to have on hand as well, maybe set up both code-cookers to benchmark and then have them crunchin' cooperatively if I can scrounge up enough 68040s, SIMMs & NICs for both. }
I'll have to decide what to sell to make room and acquire funds. At least the LC-NICs and RAM will work on both systems! ;D
Three more MicroQuadra boards might be nice to have on hand as well, maybe set up both code-cookers to benchmark and then have them crunchin' cooperatively if I can scrounge up enough 68040s, SIMMs & NICs for both. }
I'll have to decide what to sell to make room and acquire funds. At least the LC-NICs and RAM will work on both systems! ;D
Since I mentioned the project here, I'll follow up on it here.
Using 128MB SIMMs on NetBSD with a stock ROM, stock everything centris 650:
Using tmpfs:
That's 400MB of tmpfs (RAMdisk in MacOS terms. ), and a total of 456MB physical RAM being used. It's not 520MB because I couldn't touch the first 2 banks (interleaving means if it touches one, it touches both) of RAM SIMMs since the kernel and supporting data exceeds the soldered 8MB of physical RAM.
But hey. That's a respectable amount of RAM for these systems.
Using 128MB SIMMs on NetBSD with a stock ROM, stock everything centris 650:
Using tmpfs:
Code:
c650# df -hl
Filesystem Size Used Avail %Cap Mounted on
/dev/sd0a 3.7G 749M 2.8G 20% /
kernfs 1.0K 1.0K 0B 100% /kern
ptyfs 1.0K 1.0K 0B 100% /dev/pts
procfs 4.0K 4.0K 0B 100% /proc
tmpfs 1.3G 400M 936M 29% /mnt
Code:
load averages: 0.28, 0.96, 0.96; up 0+00:25:12 01:17:12
19 processes: 18 sleeping, 1 on CPU
CPU states: 0.7% user, 0.0% nice, 1.0% system, 0.0% interrupt, 98.3% idle
Memory: 419M Act, 4608K Exec, 7252K File, 12M Free
Swap: 922M Total, 922M FreeBut hey. That's a respectable amount of RAM for these systems.
,,The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.''
-- Tom Cargill, Bell Labs
:lol:
Anyways, glad you are in contact. NetBSD/mac68k could live 20 years without it, so a few weeks or month don't make a difference. In the meantime i can collect ram.
Look, my latest daily cronjob:
-- Tom Cargill, Bell Labs
:lol:
Anyways, glad you are in contact. NetBSD/mac68k could live 20 years without it, so a few weeks or month don't make a difference. In the meantime i can collect ram.
Look, my latest daily cronjob:
Code:
test 269 -eq $(wget -q -O- http://www.synack.net/~bbraun/ | wc -l) || echo "Note to self: take a look"EEK!!!! I'd better buy the enough 128MB SIMMs for the project before legions of NetBSD/mac68k fanatics drive the price beyond my reach. ;D
While it's clear that Tom Cargill must have done PostDoc work at NYU's Lawrence Peter Berra School of Statistics while doing debugger research at Murray Hill, other questions remain . . .
. . . was he a very astute programmer to have realized that time estimation overruns of 80% were common occurrences or . . .
. . . was he a rather dull software project manager to have missed the 200% overrun estimation common in the industry . . .
. . . my guess is that his wry comment is funnier from either point of view and the elegant, next level quip of a brilliant research scientist. :lol:
While it's clear that Tom Cargill must have done PostDoc work at NYU's Lawrence Peter Berra School of Statistics while doing debugger research at Murray Hill, other questions remain . . .
. . . was he a very astute programmer to have realized that time estimation overruns of 80% were common occurrences or . . .
. . . was he a rather dull software project manager to have missed the 200% overrun estimation common in the industry . . .
. . . my guess is that his wry comment is funnier from either point of view and the elegant, next level quip of a brilliant research scientist. :lol:
So, what you're saying is that you DID in fact get a 128MB SIMM to work in a 630?
I'm curious what would happen if I tried putting one in mine. I have a Rev. A logic board with two SIMM slots, one says it supports 16MB and smaller, and the other supports up to 32MB SIMMS. I confirmed this years ago, it will not boot at all, and I never get video with a 32MB SIMM in the 16MB slot (also tried with various sizes in the 32MB slot, no change.)
Do you know offhand what rev your board is?