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

Blue Swirl blauwirbel at gmail.com
Wed Dec 30 22:29:45 CET 2009


On Wed, Dec 30, 2009 at 7:55 PM, Igor Kovalenko
<igor.v.kovalenko at gmail.com> wrote:
> 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.

No, the framebuffer mapping is still OK. Linux installs an entry with
VA of 0x4000000 and PA of 0x1ffffc000 or something like that.

Now I think the MMU issues are solved. For example Debian 5.0.2:

boot: install console=ttyS0
Allocated 8 Megs of memory at 0x40000000 for kernel
Loaded kernel version 2.6.26
Loading initial ramdisk (4300466 bytes at 0xC00000 phys, 0x40C00000 virt)...
\
[    0.000000] PROMLIB: Sun IEEE Boot Prom 'OBP 3.10.24 1999/01/01 01:01'
[    0.000000] PROMLIB: Root node compatible: sun4u
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.26-2-sparc64 (Debian 2.6.26-17)
(dannf at debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian
4.1.2-25)) #1 Sun Jun 21 04:31:33 UTC 2009
[    0.000000] console [earlyprom0] enabled
[    0.000000] ARCH: SUN4U
[    0.000000] Ethernet address: 52:54:00:12:34:56
[    0.000000] Kernel: Using 1 locked TLB entries for main kernel image.
[    0.000000] Remapping the kernel... done.
[    0.000000] OF stdout device is: /pci at 80000000,0/pci at 1/pci at 1,1/ebus at 3/su at 1fe
[    0.000000] PROM: Built device tree with 32414 bytes of memory.
[    0.000000] Top of RAM: 0xfe80000, Total RAM: 0xfe80000
[    0.000000] Memory hole size: 0MB
[    0.000000] [0000000200000000-fffff80000800000] page_structs=131072
node=0 entry=0/0
[    0.000000] [0000000200000000-fffff80001400000] page_structs=131072
node=0 entry=1/0
[    0.000000] Zone PFN ranges:
[    0.000000]   Normal          0 ->    32576
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000]     0:        0 ->    32576
[    0.000000] Booting Linux...
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 32353
[    0.000000] Kernel command line: console=ttyS0
[    0.000000] PID hash table entries: 1024 (order: 10, 8192 bytes)
[    0.000000] clocksource: mult[a0000] shift[16]
[    0.000000] clockevent: mult[19999999] shift[32]
[    0.000000] Console: colour dummy device 80x25
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 131072 bytes)
[    0.000000] Memory: 243248k available (2592k kernel code, 944k
data, 176k init) [fffff80000000000,000000000fe80000]



More information about the OpenBIOS mailing list