with  some minor tweaking my G4 w/ 2GB SDRAM is now running OK.
there are a couple issues:

1. int physmem:

   the page hash table is auto-sized in pmap_bootstrap()\pmap.c:

	#ifdef  HTABENTS
		ptab_cnt = HTABENTS;
	#else /* HTABENTS */
		ptab_cnt = 1024;
		while ((HTABSIZE << 7) < ctob(physmem))
			ptab_cnt <<= 1;
	#endif /* HTABENTS */

   with >= 2GB RAM, ctob(physmem) as a signed quantity 
   will evaluate negative right off so ptab_cnt never gets
   adjusted upwards.  The result is overflow of the (puny)
   page table during startup before VM is initialized
   which results in panic("poalloc").

   three possible fixes:

	a. manually configure HTABENTS, which is not great
	   if you want to run the same kernel on a small
	   memory system.

	b. cast the values being compared in the above while loop
	   to unsigned.

	c. re-declare physmem as unsigned (in pmap.c and systm.h).
	   one might wonder why, aside from historical oversight,
	   physmem would need to be signed.

   of course, anywhere else you see something like ctob(physmem)
   or its equivalent (physmem << PGSHIFT) is worth a look.
   the one other case I found seemed relatively harmless if incorrect,
   specifically in sbin/sysctl/sysctl.[ch] & sys/kern/kern_sysctl.c:
   incorrect as there is no currently existing CTLTYPE for 
   unsigned int (should be pretty straightforward to add); 
   harmless depending on who/what ever looks at the value reported 
   by sysctl.

2. buffer sizing:

   the "traditional" method of auto-sizing the I/O buffer pool
   i.e. 10% of the first 2MB and 5% of the remaining,
   is broken for large memory systems, for the macppc kernel
   anyway.  with 2GB RAM, 5% is > 100MB, which can really put
   a dent in your kernel virtual space, if you had that 
   much to spare.  for me it was
 
	panic: startup: cannot allocate VM for buffers
   
   The obvious workaround there is to manually configure
   a buffer pool that will fit.  again, that's not a great
   solution if you want to run the same kernel on a 
   not-huge memory system, so perhaps a modification on the
   traditional forumla would be in order, perhaps a cap
   on how big the pool can be, perhaps modulated by how
   much kernel virtual space is available?

3. cpu_startup()\machdep.c calls format_bytes()\kern_subr.c
   to format up a pretty string to report memory size.
   format_bytes expects the 3rd arg to be a u_int64_t;
   so the call in cpu_startup may deserve a type cast on
   that arg.

on the whole 2G was not a big deal, and it's to the credit of 
netbsd and the macppc port in particular that this was
as painless as it was.  hope the above data helps,
in case anyone ever wants to run with lots-o-RAM.

regards,
	-cliff-

---
cliff neighbors
allegro networks, inc.
cliff@allegronetworks.com
408-281-5532
---