Re: #9318 NORM 1.5-ATe: Via framebuffer failure on 1.5
Hi Harald, this means you need to boot with vmalloc=something-bigger. The framebuffer needs to be vmalloc'ed. So if you have a relatively small amount of RAM, and the BIOS is configured for 256MB framebuffer size, the kernel-selected vmalloc area is smaller than what we need for the framebuffer. So you have three options: Thanks very much; with vmalloc=256M I can use viafb from OFW. Viafb takes about twenty seconds to load, perhaps because we rerouted the EDID pins away from the VGA connector to the panel instead.. However, I haven't worked out why the vmalloc increase is necessary. OFW passes an FB size of 0x4000, which should be: case 0x4000: VideoMemSize = (64 20); /*64M */ (Don't worry about trying to diagnose any of this in the absence of hardware; it can wait until we're able to make some developer boards available.) - Chris. -- Chris Ball c...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #9318 NORM 1.5-ATe: Via framebuffer failure on 1.5
Hi Chris, On Wed, Jun 03, 2009 at 01:59:41AM -0400, Chris Ball wrote: Hi Harald, this means you need to boot with vmalloc=something-bigger. The framebuffer needs to be vmalloc'ed. So if you have a relatively small amount of RAM, and the BIOS is configured for 256MB framebuffer size, the kernel-selected vmalloc area is smaller than what we need for the framebuffer. So you have three options: Thanks very much; with vmalloc=256M I can use viafb from OFW. Viafb takes about twenty seconds to load, perhaps because we rerouted the EDID pins away from the VGA connector to the panel instead.. That 20second load time is indeed very surprising, but yes, the I2C might be an issue, since the driver tries to probe for external TV encoders and the like on that I2C bus. The respective code would have to be deactivated on a OLPC. OFW passes an FB size of 0x4000, which should be: case 0x4000: VideoMemSize = (64 20); /*64M */ ok, that is strange. (Don't worry about trying to diagnose any of this in the absence of hardware; it can wait until we're able to make some developer boards available.) Ok, I can commit to look into all issues, i,e: * 20second module load time * why does it need vmalloc= * support for your panel once I have access to hardware. Please contact me before you want to ship anything, as my travel schedule determines where to send the device at which date. Regards, -- - Harald Welte hwe...@hmw-consulting.de http://www.hmw-consulting.de/ = Consultant for Linux networking, network security, Linux driver development ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #9318 NORM 1.5-ATe: Via framebuffer failure on 1.5
On Fri, May 29, 2009 at 03:01:02AM -0400, Chris Ball wrote: It can't, but I don't mind communicating by e-mail and updating the tracker afterwards if you'd prefer. I'll respond by mail now, but will check out the tracker later. Just arrived back from 4 days offline and have tons of backlog mh, the problem must be related to that particular board, as I've tested the code on both VX800 and VX855 (including a VX800 based laptop with panel). But thanks for letting me know. viafb was working on the device before? What about the external VGA? I've tried with a VX800 laptop with CRT+panel, and the 1.5 board with CRT, and neither worked. The fb init does not complete: [ 24.128168] vmap allocation for size 268439552 failed: use vmalloc=size to increase size. [ 24.136654] ioremap of fbmem failed this means you need to boot with vmalloc=something-bigger. The framebuffer needs to be vmalloc'ed. So if you have a relatively small amount of RAM, and the BIOS is configured for 256MB framebuffer size, the kernel-selected vmalloc area is smaller than what we need for the framebuffer. So you have three options: 1) tell the BIOS to configure the north bridge to only use 64MB or 128MB for the framebuffer 2) put more memory in the system (the kernel will grow the vmalloc area based on total amount of ram available) 3) use 'vmalloc=XXX' to tell the kernel to have a bigger vmalloc area. -- - Harald Welte hwe...@hmw-consulting.de http://www.hmw-consulting.de/ = Consultant for Linux networking, network security, Linux driver development ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #9318 NORM 1.5-ATe: Via framebuffer failure on 1.5
[ I hope your bug tracker can take email responses, please tell me if not ] On Fri, May 29, 2009 at 02:30:58AM -, Zarro Boogs per Child wrote: Hi Harald, looks like the new viafb patches have some problems. I just pulled out a VX800 laptop with panel to try on that too, and the screen fades to white when viafb loads there. mh, the problem must be related to that particular board, as I've tested the code on both VX800 and VX855 (including a VX800 based laptop with panel). But thanks for letting me know. viafb was working on the device before? What about the external VGA? After loading viafb from your xo-1.5 branch on the XO1.5 or the VIA VX855 reference board, you should definitely get working output on the VGA out. If even that doesn't work, something must have gone wrong while rebasing my patches against the XO1.5 kernel tree. [I'm offline till tuesday, will look into that after I return] -- - Harald Welte hwe...@hmw-consulting.de http://www.hmw-consulting.de/ = Consultant for Linux networking, network security, Linux driver development ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #9318 NORM 1.5-ATe: Via framebuffer failure on 1.5
Hi Harald, [ I hope your bug tracker can take email responses, please tell me if not ] It can't, but I don't mind communicating by e-mail and updating the tracker afterwards if you'd prefer. mh, the problem must be related to that particular board, as I've tested the code on both VX800 and VX855 (including a VX800 based laptop with panel). But thanks for letting me know. viafb was working on the device before? What about the external VGA? I've tried with a VX800 laptop with CRT+panel, and the 1.5 board with CRT, and neither worked. The fb init does not complete: [ 24.128168] vmap allocation for size 268439552 failed: use vmalloc=size to increase size. [ 24.136654] ioremap of fbmem failed [ 24.140759] viafb: probe of :00:01.0 failed with error -5 It looks like it's trying to do DVI/panel output even though I only had CRT connected, in this case (see the dmesg posted in the bug). I'll look into it a little more, just wanted to give you a heads-up. After loading viafb from your xo-1.5 branch on the XO1.5 or the VIA VX855 reference board, you should definitely get working output on the VGA out. 'fraid not. If even that doesn't work, something must have gone wrong while rebasing my patches against the XO1.5 kernel tree. [I'm offline till tuesday, will look into that after I return] That's fine, thanks for looking at it. It's not on the critical path, so no rush. - Chris. -- Chris Ball c...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #9318 NORM 1.5-ATe: Via framebuffer failure on 1.5
Why is viafb trying to allocate 268 MB of memory ? That seems like a lot for a simple fb driver.. wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #9318 NORM 1.5-ATe: Via framebuffer failure on 1.5
Hi, Why is viafb trying to allocate 268 MB of memory ? That seems like a lot for a simple fb driver.. Answer: Because the BIOS told it to. Question #2: What happens if you change the framebuffer size in the BIOS to 32M? Answer #2: It works. :) There's some sort of corruption in the logo, but that might just be an incorrectly-set depth; I haven't tried specifying a mode yet. - Chris. -- Chris Ball c...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
