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

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

Hello,

On Tue, 02 Apr 2013 10:38:51 +0400
Phileas Fogg <phileas-fogg%mail.ru@localhost> wrote:

> 
> >> 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?
> 
> Else i have to enclose copy_rom_font with #ifdef #endif too but i can fix it, 
> no problem.

Yeah, that's what I figured immediately after sending that mail ;)
As I said, minor nit.

> >> 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.
> >
> 
> Yeah, you are right, i can get it from rascons_console_screen, i haven't 
> noticed it.
> Will fix it.

Thanks!

> >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?

> Hmm, how did you figure it crashed there ?

Backtrace from ddb, then using gdb on the kernel image on another
macppc box to find which function it falls into ( as in, 'disassemble
0xwhatever' ). You can also build a cross-gdb for whatever you use to
build your kernels.

> It shouldn't crash here at all for we are still in real mode and the
> machine shouldn't care at all if we zero it out or not. Very odd. No
> idea right now what could be wrong here.

Ok, I'll look into this a bit further then.

> For debugging my G5 kernel before MMU is enabled i used a simple function,
> which just paints the top of the display red, that way i could test if the 
> CPU reaches a
> certain place in code.

Heh, I've been using similar trickery myself.

have fun
Michael