Re: [PATCH] Incorrect segment 0 initialization for PMAC G5

[Michael <macallan%netbsd.org@localhost>]

Hello,

On Mon, 01 Apr 2013 17:25:30 +0200
Phileas Fogg <phileas-fogg%mail.ru@localhost> wrote:

> i prepared the first bunch of patches for G5 support.
> These patches fix MMU issues on G5.
> I tested the patches with NetBSD HEAD.
> Please review them and tell me if it's OK.
> After applying these patches your NetBSD kernel should boot in virtual
> mode and panic in init_interrupt. All patches were tested by me
> with netbooting.



> POWERMAC_G5_11_2.patch   :  My kernel config which i used

Nothing to complain about here.

> locore.S.patch           :  Enable 64bit bridge mode at boot
> 
> trap_subr.S.patch        :  Enable 64bit bridge mode when entering an
>                              exception handler

I don't see anything wrong with these but since I'm not exactly familiar with 
PowerPC assembly I'll wait for matt@'s opinion.

> pmap.c.patch             :  Disable kernel map in pmap_bootstrap

Seems to have no ill side effects on my G3.

> ofw_rascons.c.patch      :  Do not use ROM font if kernel option
>                              OFWOEA_WSCONS_NO_ROM_FONT is defined.
>                              I'm having problems with ROM font currently,
>                              my machine hangs, so that's why i added
>                              a new kernel option.

Minor nit - why call copy_rom_font() when you're going to discard the result on 
G5 anyway?

> ofwoea_machdep.c.patch   :  Make OFW code+data mapping machine
>                              independent and map video frame buffer into
>                              pmap_kernel for console.
>                              Also fix ofw_map segments.

Minor nit - no need to get the video memory parameters from OF again, either 
rascons_console_screen is filled in or we don't use the framebuffer console.

That said, my G5 crashes in pmap_bootstrap() when zeroing
pmap_pteg_table, the memory region returned by pmap_boot_find_memory()
is 0x2000000 size 0x2000000, which falls into the available regions.
Memory size is correctly detected ( I found some old code to deal with
64bit addresses in /memory/regs - should probably commit it now before
reinventing the wheel ) - 2GB for 32bit kernels, with another 2GB upper
memory ignored. Any idea what I might be missing here?

have fun
Michael