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.
