[OpenBIOS] r648 - in trunk/openbios-devel: arch/sparc64 drivers

Igor Kovalenko igor.v.kovalenko at gmail.com
Wed Dec 30 20:55:25 CET 2009


On Wed, Dec 30, 2009 at 12:48 PM, Blue Swirl <blauwirbel at gmail.com> wrote:
> On Wed, Dec 30, 2009 at 6:08 AM, Igor Kovalenko
> <igor.v.kovalenko at gmail.com> wrote:
>> On Wed, Dec 30, 2009 at 12:27 AM, Blue Swirl <blauwirbel at gmail.com> wrote:
>>> On Tue, Dec 29, 2009 at 9:15 PM, Igor Kovalenko
>>> <igor.v.kovalenko at gmail.com> wrote:
>>>> On Mon, Dec 28, 2009 at 1:15 PM,  <svn at openbios.org> wrote:
>>>>> Author: blueswirl
>>>>> Date: 2009-12-28 11:15:33 +0100 (Mon, 28 Dec 2009)
>>>>> New Revision: 648
>>>>>
>>>>> Modified:
>>>>>   trunk/openbios-devel/arch/sparc64/entry.S
>>>>>   trunk/openbios-devel/drivers/pci.c
>>>>>   trunk/openbios-devel/drivers/vga_vbe.c
>>>>> Log:
>>>>> Map VGA buffer only during PCI probe
>>>>>
>>>>> Also pass physical addresses instead of bus addresses to VGA init.
>>>>>
>>>>> Signed-off-by: Blue Swirl <blauwirbel at gmail.com>
>>>>>
>>>>> Modified: trunk/openbios-devel/drivers/vga_vbe.c
>>>>> ===================================================================
>>>>> --- trunk/openbios-devel/drivers/vga_vbe.c      2009-12-21 09:57:53 UTC (rev 647)
>>>>> +++ trunk/openbios-devel/drivers/vga_vbe.c      2009-12-28 10:15:33 UTC (rev 648)
>>>>> @@ -25,6 +25,7 @@
>>>>>  #include "asm/io.h"
>>>>>  #include "libc/vsprintf.h"
>>>>>  #include "video_subr.h"
>>>>> +#include "ofmem.h"
>>>>>
>>>>>  /* VGA init. We use the Bochs VESA VBE extensions  */
>>>>>  #define VBE_DISPI_INDEX_ID              0x0
>>>>> @@ -142,7 +143,10 @@
>>>>>                depth = d;
>>>>>                linebytes = (width * ((depth + 7) / 8));
>>>>>        }
>>>>> +#ifdef CONFIG_SPARC64
>>>>> +        ofmem_map_page_range(fb, fb, fb_size, 0x36);
>>>>>  #endif
>>>>> +#endif
>>>>>
>>>>>        vga_vbe_set_mode(width, height, depth);
>>>>
>>>> You pass flags so mapping is unlocked, this can cause
>>>> problems with translations being evicted from tlb table.
>>>> Do you see any issues? Linux kernel has it's own idea
>>>> of address translations, and we still do not switch trap
>>>> handlers so probably framebuffer should be mapped
>>>> locked into tlb table (mode=0x76)
>>>
>>> If I use locked entries, with 8k pages there are soon no free TLB
>>> entries left. I've tried to fix this with the attached patch which
>>> adds support for 64k, 512k and 4M pages, then the entry can be changed
>>> to locked one.
>>>
>>> However I get regressions with some tests. The new MMU entries created
>>> by the miss handler look OK but Linux creates a bogus entry.
>>
>> You can use ofmem_map instead of ofmem_map_page_range
>> to install locked entries. It uses ofmem_arch_early_map_pages
>> so is able to install 4M locked entries as well. Something
>> suggests we should use only page-sized unlocked translations.
>>
>> Also it would be good to provide framebuffer for client.
>> Since client gets framebuffer address from device tree
>> we are required to map framebuffer in 32bit space.
>>
>> The following change combines both suggestions.
>> I think recent linux kernel would be now able to use
>> framebuffer console driver.
>>
>> diff --git a/drivers/vga_vbe.c b/drivers/vga_vbe.c
>> index 783125a..3c9b7b1 100644
>> --- a/drivers/vga_vbe.c
>> +++ b/drivers/vga_vbe.c
>> @@ -144,7 +144,11 @@ void vga_vbe_init(const char *path, unsigned long
>> fb, uint32_t fb_size,
>>                linebytes = (width * ((depth + 7) / 8));
>>        }
>>  #ifdef CONFIG_SPARC64
>> -        ofmem_map_page_range(fb, fb, fb_size, 0x36);
>> +#define VGA_VADDR  0xfe000000
>> +        ofmem_claim_phys(fb, fb_size, 0);
>> +        ofmem_claim_virt(VGA_VADDR, fb_size, 0);
>> +        ofmem_map(fb, VGA_VADDR, fb_size, 0x76);
>> +        fb = VGA_VADDR;
>>  #endif
>>  #endif
>
> That does help. I guess Linux gets confused with the 4M page entries.

More likely the issue is with linux startup process evicting unlocked
entries, then kernel fails trying to map for mmu miss done by openbios
while accessing framebuffer.

-- 
Kind regards,
Igor V. Kovalenko



More information about the OpenBIOS mailing list