• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

BrickOven™ PizzaBox Hack revisited . . .

I love it when my threads get hijacked, makes me feel less guilty when I . . .

So, do you think a BrickOven™ or RackOven™ could kick Lilith's @$$? }:)

 
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.

 
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. }:)

 
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 :) .

 
8-) 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. :p

 
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.

 
8-o ICK!!!! :p 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:

Code: 
./build.sh -m mac68k -R /usr/build/releasedir -O /usr/build/objectdir -T /usr/build/tooldir -D /usr/build/destdir tools
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:

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=TECNEEQ
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.

 
trag suggested the SIMMs/source to me, he's my memory guru, so I'm not worried. That's one stick per 605/475 system, I don't think the 630 supports the 128mb SIMMs . . .

. . . but it would be nice to be surprised. ;)

 
This firmware/bootware/software crap gives me a headache
Click to expand...
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

 
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:

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 Free
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.

 
That's a nice hack. Any chance your patches find their way into the NetBSD source tree? You can use send-pr(1) to do it.

Finally i have a reason to buy 128MB SIMMs! BTW, is there a RSS feed on your homepage?

Can't wait for the "NetBSD/mac68k Work Entry #2". |)

 
Thanks, I'm traveling for a few days so no progress for a little while.

I am working with some netbsd folks to incorporate the change, but what's that 90/90 rule?

Going from a neat hack to a supportable change will take some time, but I'm working on it.

 
,,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:

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:

 
You must log in or register to reply here.
Back
Top