Re: Invalid memory address failures due to copy_rom_font

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

Hello,

On Mon, 20 Jan 2020 16:32:57 -0500
Julio Merino <julio%meroh.net@localhost> wrote:

> I've been trying to get NetBSD (any version really...) to run on this
> old PowerBook6,8 (G4, 12") and every single attempt has failed. After
> some digging, I found the two blockers for booting. One is the need to
> define FIRMWORKSBUGS, which I'll skip for now but I'm mentioning for
> completeness.

I've seen copy_rom_font() fail on G5, which is why all the G5 kernel
configs have
options		OFWOEA_WSCONS_NO_ROM_FONT
Also, my TiBook needs FIRMWORKSBUGS to boot - apparently the real mode
OF interface doesn't work right on those models. I had no idea other
machines were affected.
( that's what options FIRMWORKSBUGS actually does - use the virtual
mode interface and switch address spaces around during OF calls )

> The other is described below, and is the cause behind
> all "Invalid memory access" and "Decrementer exception" problems I
> encountered at early boot time. With these, I've gotten 9.99.36 to
> work!
> 
> The problem comes from the copy_rom_font functionality in
> ofw_rascons.c. Attempting to use the ROM font results in the "Invalid
> memory access" errors above. Disabling this functionality lets the
> kernel boot just fine.
> 
> Now, I'm wondering how this has ever worked, and what a good solution would be.
> 
> What this code does is construct a wsfont descriptor for the font in
> the ROM and points that descriptor the memory address where the font
> lives. Now... the code has a comment like: "Convert to physical
> address.  We cannot access to Open Firmware's virtual address space."
> which I think is where the root of the problems live.
> 
> * Using the font-adr virtual address as returned from OpenFirmware,
> without conversion to a physical address does "work". If I disable the
> translate call, the kernel is able to print some messages until it
> crashes, which I suspect happens when the kernel takes over the page
> table because it knows nothing about this area (?).
> 
> * I've tried adding pmap_enter for these addresses (inspired by what
> ofwea_machdep.c does for the framebuffer) in an attempt to make the
> above work... but I really don't know what I'm doing here.
> 
> * Accessing memory through the physical address right after the
> conversion via OF's translate results in an immediate "Invalid memory
> address" exception. So I'm wondering... how has this ever worked or
> how does this work in some machines but not others?

I think this is all related to FIRMWORKSBUGS and the real mode vs.
virtual mode OF interfaces. There were other related bugs which I
fixed when making the TiBook work.
Basically what happens is this - OF runs in its own virtual address
space, we acquire a pointer to the font *in that address space*, then
switch back to the kernel's address space and the pointer becomes
invalid. Other OF calls get around that by copying arguments and
results into a memory range mapped into both spaces. We should probably
do something similar for copy_rom_font().

> * I've tried modifying copy_rom_font to copy the font data out of the
> ROM and into our own static buffer -- and things work.

See above ;)

> * But soon after boot, the kernel ignores the copied font, clears the
> screen, and uses its own font. Which makes me wonder if it's worth
> going that path at all. Maybe copy_rom_font can be ifdefed out? On
> macppc?

The console code will pick a font that gets closest to providing an
80x25 terminal. You can change the requested size by defining 
options RASOPS_DEFAULT_WIDTH <something> and options
RASOPS_DEFAULT_HEIGHT.
In theory, if the ROM font is the best match it should get picked.

> * It'd also be nice to register the ROM font with wsfont_add() so that
> it'd remain usable throughout the boot process. Right? But wsfont_add
> is unusable that early in the boot process due to its use of malloc()
> as I understand it.

I need to look into that. IIRC we only need *alloc() to generate line
drawing characters and such. If nothing else we can keep the font
around and add it just before autoconfig.

> Any ideas for a good fix (that's not one more ifdef)?

The copy_rom_font() dance exists mainly to mimic firmware output until
a driver takes over. 

have fun
Michael