Re: [OpenBIOS] r648 - in trunk/openbios-devel: arch/sparc64 drivers
On Mon, Dec 28, 2009 at 1:15 PM, <svn@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@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) -- Kind regards, Igor V. Kovalenko
On Tue, Dec 29, 2009 at 9:15 PM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote:
On Mon, Dec 28, 2009 at 1:15 PM, <svn@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@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.
On Wed, Dec 30, 2009 at 12:27 AM, Blue Swirl <blauwirbel@gmail.com> wrote:
On Tue, Dec 29, 2009 at 9:15 PM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote:
On Mon, Dec 28, 2009 at 1:15 PM, <svn@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@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 -- Kind regards, Igor V. Kovalenko
On Wed, Dec 30, 2009 at 6:08 AM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote:
On Wed, Dec 30, 2009 at 12:27 AM, Blue Swirl <blauwirbel@gmail.com> wrote:
On Tue, Dec 29, 2009 at 9:15 PM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote:
On Mon, Dec 28, 2009 at 1:15 PM, <svn@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@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.
On Wed, Dec 30, 2009 at 12:48 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
On Wed, Dec 30, 2009 at 6:08 AM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote:
On Wed, Dec 30, 2009 at 12:27 AM, Blue Swirl <blauwirbel@gmail.com> wrote:
On Tue, Dec 29, 2009 at 9:15 PM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote:
On Mon, Dec 28, 2009 at 1:15 PM, <svn@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@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
On Wed, Dec 30, 2009 at 7:55 PM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote:
On Wed, Dec 30, 2009 at 12:48 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
On Wed, Dec 30, 2009 at 6:08 AM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote:
On Wed, Dec 30, 2009 at 12:27 AM, Blue Swirl <blauwirbel@gmail.com> wrote:
On Tue, Dec 29, 2009 at 9:15 PM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote:
On Mon, Dec 28, 2009 at 1:15 PM, <svn@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@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@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@80000000,0/pci@1/pci@1,1/ebus@3/su@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]
On Thu, Dec 31, 2009 at 12:29 AM, Blue Swirl <blauwirbel@gmail.com> wrote:
On Wed, Dec 30, 2009 at 7:55 PM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote:
On Wed, Dec 30, 2009 at 12:48 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
On Wed, Dec 30, 2009 at 6:08 AM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote:
On Wed, Dec 30, 2009 at 12:27 AM, Blue Swirl <blauwirbel@gmail.com> wrote:
On Tue, Dec 29, 2009 at 9:15 PM, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote:
On Mon, Dec 28, 2009 at 1:15 PM, <svn@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@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@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@80000000,0/pci@1/pci@1,1/ebus@3/su@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]
Now we need timers I believe. -- Kind regards, Igor V. Kovalenko
participants (2)
-
Blue Swirl -
Igor Kovalenko