From: Julien L. <les...@ho...> - 2007-02-24 09:59:04
|
Hi Steve, Thanks for your answer, Actually in the bootlog I see it crashing :D LOL The kernel try to probe it, and fail with error -12. Just before that I got strange errors about the BUG: at kernel/sched.c:4035 __schedule() [<c0021d60>] (dump_stack+0x0/0x14) from [<c0189190>] (__schedule+0x6f0/0x740) [<c0188aa0>] (__schedule+0x0/0x740) from [<c01893d4>] (schedule+0xd0/0x118) [<c0189304>] (schedule+0x0/0x118) from [<c00423d0>] (kthread+0xc8/0x128) r4 = 00000000 [<c0042308>] (kthread+0x0/0x128) from [<c0030330>] (do_exit+0x0/0x85c) r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000 And in the source code, it is the first function => schedule_work. And yes, the framebuffer module won't unload, even with force, or wait command and with those options enabled in the kernel (force unload module ...) I also use the printk function for debugging my LCD driver :) I think I'll put it in the framebuffer driver too now :p Regards, Julien > >I agree that modules can be useful. But what I found was that the >frame-buffer module could not be unloaded - it always seemed to be busy. >So I had to reboot anyway. And once I had to reboot, then it was easier to >just compile the driver in. That is why I made my recommendation to >compile it in - it eliminates one variable. > >Do you see any evidence that the driver is doing anything? Are there any >messages when the kernel boots, or anything in dmesg? If there are no >messages at all, then that suggests that the driver is not even being >called. > >My next step would be to add a few printk() statements, to see what is >happening. For example, the routines pxafb_init() and pxafb_probe() should >be called, so adding printk there will tell you if the initialization is >happening. If you have never used printk, it works just like printf in >user programs. Just give it a format string and arguments, and you should >see messages on the console serial port. Simple usage would be just >something like: > > printk("got here\n"); > >I used this technique when debugging my display. It is a little painful at >first, but it will tell you whether the driver is even being called. > > Steve > > >Julien Lebot wrote: >>Hi Dave, >> >>That's me, Julien, who posted the question, just to make sure nobody gets >>confused, I'm not talking for Steve :) >> >> >>>Hi Steve, >>> >>> >>>>Ok now a couple of nasty question (sorry, noob inside): >>>> >>>>First, can I transfer only the kernel to the gumstix without having to >>>flash >>> >>>>it ? Because I don't touch anymore the package selection, just the >>>kernel >>> >>>>configuration. >>>> >>>Provided that the kernel that was there came from your buildroot, and >>>you have enough space (preferably an XM), then yeah you can do it. >>> >>>You could remove the old uImage and copy the new one in. Worst case, >>>is you need to download the whole thing. >>> >>>If you compiled the driver as a module, then you just need to copy the >>>module over, and you can leave the kernel alone. >>> >>>For developing a new driver, I really like having it as a module, >>>cause you can load and unload and if it really screws up you just >>>reboot. >>> >>>-- >>> >> >>I have to agree with you, when developing it's useful, if it doesn't work, >>unload and upload a new version. But it's about the framebuffer, it just >>doesn't show up... >>But I recall now that after compiling the framebuffer as a part of the >>kernel, I have a file "fb" in my /proc folder... may it be the Graal I'm >>looking for ?? >>Then how do I access it from the kernel driver ? >> >>Thanks for your answer, >>Julien >> >>_________________________________________________________________ >>MSN Messenger : discutez en direct avec vos amis ! >>http://www.msn.fr/msger/default.asp >> >> >>------------------------------------------------------------------------- >>Take Surveys. Earn Cash. Influence the Future of IT >>Join SourceForge.net's Techsay panel and you'll get the chance to share >>your >>opinions on IT & business topics through brief surveys-and earn cash >>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>_______________________________________________ >>gumstix-users mailing list >>gum...@li... >>https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share >your >opinions on IT & business topics through brief surveys-and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >gumstix-users mailing list >gum...@li... >https://lists.sourceforge.net/lists/listinfo/gumstix-users _________________________________________________________________ MSN Messenger : appels gratuits de PC à PC ! http://www.msn.fr/newhotmail/Default.asp?Ath=f |
From: Steven A. F. <sa...@op...> - 2007-02-24 14:04:20
|
Error -12 is ENOMEM (see file include/asm-generic/errno-base.h). Looking at the probe routine, this is the default error return, so you will probably have to put in some printk to see exactly where it is failing. But the crash is more important. If it is happening first, then you have to fix it before you have any hope of getting the error -12 fixed. I don't have your exact source code, so I don't know where kernel/sched.c:4035 is. Im my source code, schedule_work seems to be defined in workqueue.c, so that doesn't correspond to the bug you posted. Does this crash still happen if you remove the fb driver? Steve Julien Lebot wrote: > Hi Steve, > > Thanks for your answer, > Actually in the bootlog I see it crashing :D LOL > The kernel try to probe it, and fail with error -12. Just before that I got > strange errors about the > > BUG: at kernel/sched.c:4035 __schedule() > [<c0021d60>] (dump_stack+0x0/0x14) from [<c0189190>] > (__schedule+0x6f0/0x740) > [<c0188aa0>] (__schedule+0x0/0x740) from [<c01893d4>] (schedule+0xd0/0x118) > [<c0189304>] (schedule+0x0/0x118) from [<c00423d0>] (kthread+0xc8/0x128) > r4 = 00000000 > [<c0042308>] (kthread+0x0/0x128) from [<c0030330>] (do_exit+0x0/0x85c) > r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000 > > And in the source code, it is the first function => schedule_work. > And yes, the framebuffer module won't unload, even with force, or wait > command and with those options enabled in the kernel (force unload module > ...) > I also use the printk function for debugging my LCD driver :) > I think I'll put it in the framebuffer driver too now :p > > Regards, > Julien > > >> I agree that modules can be useful. But what I found was that the >> frame-buffer module could not be unloaded - it always seemed to be busy. >> So I had to reboot anyway. And once I had to reboot, then it was easier to >> just compile the driver in. That is why I made my recommendation to >> compile it in - it eliminates one variable. >> >> Do you see any evidence that the driver is doing anything? Are there any >> messages when the kernel boots, or anything in dmesg? If there are no >> messages at all, then that suggests that the driver is not even being >> called. >> >> My next step would be to add a few printk() statements, to see what is >> happening. For example, the routines pxafb_init() and pxafb_probe() should >> be called, so adding printk there will tell you if the initialization is >> happening. If you have never used printk, it works just like printf in >> user programs. Just give it a format string and arguments, and you should >> see messages on the console serial port. Simple usage would be just >> something like: >> >> printk("got here\n"); >> >> I used this technique when debugging my display. It is a little painful at >> first, but it will tell you whether the driver is even being called. >> >> Steve >> >> >> Julien Lebot wrote: >> >>> Hi Dave, >>> >>> That's me, Julien, who posted the question, just to make sure nobody gets >>> confused, I'm not talking for Steve :) >>> >>> >>> >>>> Hi Steve, >>>> >>>> >>>> >>>>> Ok now a couple of nasty question (sorry, noob inside): >>>>> >>>>> First, can I transfer only the kernel to the gumstix without having to >>>>> >>>> flash >>>> >>>> >>>>> it ? Because I don't touch anymore the package selection, just the >>>>> >>>> kernel >>>> >>>> >>>>> configuration. >>>>> >>>>> >>>> Provided that the kernel that was there came from your buildroot, and >>>> you have enough space (preferably an XM), then yeah you can do it. >>>> >>>> You could remove the old uImage and copy the new one in. Worst case, >>>> is you need to download the whole thing. >>>> >>>> If you compiled the driver as a module, then you just need to copy the >>>> module over, and you can leave the kernel alone. >>>> >>>> For developing a new driver, I really like having it as a module, >>>> cause you can load and unload and if it really screws up you just >>>> reboot. >>>> >>>> -- >>>> >>>> >>> I have to agree with you, when developing it's useful, if it doesn't work, >>> unload and upload a new version. But it's about the framebuffer, it just >>> doesn't show up... >>> But I recall now that after compiling the framebuffer as a part of the >>> kernel, I have a file "fb" in my /proc folder... may it be the Graal I'm >>> looking for ?? >>> Then how do I access it from the kernel driver ? >>> >>> Thanks for your answer, >>> Julien >>> >>> _________________________________________________________________ >>> MSN Messenger : discutez en direct avec vos amis ! >>> http://www.msn.fr/msger/default.asp >>> >>> >>> ------------------------------------------------------------------------- >>> Take Surveys. Earn Cash. Influence the Future of IT >>> Join SourceForge.net's Techsay panel and you'll get the chance to share >>> your >>> opinions on IT & business topics through brief surveys-and earn cash >>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >>> > > > >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share >> your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> > > > >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > _________________________________________________________________ > MSN Messenger : appels gratuits de PC à PC ! > http://www.msn.fr/newhotmail/Default.asp?Ath=f > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |
From: Julien L. <les...@ho...> - 2007-02-24 14:09:12
|
>Error -12 is ENOMEM (see file include/asm-generic/errno-base.h). Looking >at the probe routine, this is the default error return, so you will >probably have to put in some printk to see exactly where it is failing. Ok so it can't allow memory ?? >But the crash is more important. If it is happening first, then you have >to fix it before you have any hope of getting the error -12 fixed. I don't >have your exact source code, so I don't know where kernel/sched.c:4035 is. >Im my source code, schedule_work seems to be defined in workqueue.c, so >that doesn't correspond to the bug you posted. The schedule_work is in pxafb.c, it's the first function. >Does this crash still happen if you remove the fb driver? > > Steve As soon as I go back under linux I'll recompile the kernel w/o the fb. And I'll try to have a deeper look to the schedule_work function. Julien _________________________________________________________________ MSN Messenger : appels gratuits de PC à PC ! http://www.msn.fr/newhotmail/Default.asp?Ath=f |
From: Steven A. F. <sa...@op...> - 2007-02-24 14:33:35
|
I think I missed something the first time I read this email thread. Are all the problems related to kernel 2.6.20? Does kernel 2.6.18 work correctly? > Ok so it can't allow memory ?? I would not conclude that - it is unlikely that you are really out of memory. Like I said, this is the default error return, so it just gives you a general area to look in. You have to add some printk to get more information. > The schedule_work is in pxafb.c, it's the first function. schedule_work is a way of deferring some activity until the appropriate time to do that activity. You typically see it used by interrupt handlers (which have to return quickly). So, they defer much of their processing using schedule_work. What should happen is that a pointer to the pxafb_task is passed to schedule_work. Perhaps a bad pointer is being passed, or perhaps pxafb_task itself is doing something wrong. > As soon as I go back under linux I'll recompile the kernel w/o the fb. And > I'll try to have a deeper look to the schedule_work function. > > Julien > > _________________________________________________________________ > MSN Messenger : appels gratuits de PC à PC ! > http://www.msn.fr/newhotmail/Default.asp?Ath=f > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |
From: Alexis C. <chi...@ya...> - 2007-02-24 14:46:08
|
Yes, I suppose it is only related to 2.6.20, as I dowgraded to the last release using 2.6.18 (1285) and everything works perfect. For your information, the schedule error shows up even without the framebuffer driver trying to load. Best, Alexis. ----- Original Message ----- From: "Steven A. Falco" <sa...@op...> To: "General mailing list for gumstix users." <gum...@li...> Sent: Saturday, February 24, 2007 9:33 AM Subject: Re: [Gumstix-users] About the gumstix kernel / UCB1400 / Framebuffer I think I missed something the first time I read this email thread. Are all the problems related to kernel 2.6.20? Does kernel 2.6.18 work correctly? > Ok so it can't allow memory ?? I would not conclude that - it is unlikely that you are really out of memory. Like I said, this is the default error return, so it just gives you a general area to look in. You have to add some printk to get more information. > The schedule_work is in pxafb.c, it's the first function. schedule_work is a way of deferring some activity until the appropriate time to do that activity. You typically see it used by interrupt handlers (which have to return quickly). So, they defer much of their processing using schedule_work. What should happen is that a pointer to the pxafb_task is passed to schedule_work. Perhaps a bad pointer is being passed, or perhaps pxafb_task itself is doing something wrong. > As soon as I go back under linux I'll recompile the kernel w/o the fb. And > I'll try to have a deeper look to the schedule_work function. > > Julien > > _________________________________________________________________ > MSN Messenger : appels gratuits de PC à PC ! > http://www.msn.fr/newhotmail/Default.asp?Ath=f > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Chris D. <chr...@gm...> - 2007-02-24 14:57:46
|
Yep - it does work with 2.6.18. There was another issue with cf not working with 2.6.20 from this thread http://thread.gmane.org/gmane.linux.distributions.gumstix.general/21= 309 and it too was failing with the "probe of XX failed with error -12" message. In this case I was able to figure out that it was a misconfigured kernel for the pcmcia driver (or at least changing that got it to work for me). So I first started looking into the 2.6.20 kernel .config to see if something jumped out at me but I couldn't find anything. If you diff the pxafb.c file from 2.6.18 to 2.6.20 you can see that there are a lot of changes, but I'm not familiar enough with the kernel/c to really know what is going on. Looking on google found some hits on openembedded's site referring to mode changes in the pxafb module starting with 2.6.19, but I never actually found a patch or anything. I really have no need to update to 2.6.20 other than that I like to keep current with the buildroot head. I'm going to keep plugging away at trying to find a solution. Steve, given that 2.6.18 works, do you have any idea on where to start looking for a fix? I was assuming the stuff with schedule_work was just a bug in the RT kernel patches and not anything to do with the fb, but I could be wrong there??? Chris On 2/24/07, Alexis Chiarello <chi...@ya...> wrote: > Yes, I suppose it is only related to 2.6.20, as I dowgraded to the last > release using 2.6.18 (1285) and everything works perfect. > > For your information, the schedule error shows up even without the > framebuffer driver trying to load. > > Best, > > Alexis. > ----- Original Message ----- > From: "Steven A. Falco" <sa...@op...> > To: "General mailing list for gumstix users." > <gum...@li...> > Sent: Saturday, February 24, 2007 9:33 AM > Subject: Re: [Gumstix-users] About the gumstix kernel / UCB1400 / > Framebuffer > > > I think I missed something the first time I read this email thread. Are > all the problems related to kernel 2.6.20? Does kernel 2.6.18 work > correctly? > > > Ok so it can't allow memory ?? > I would not conclude that - it is unlikely that you are really out of > memory. Like I said, this is the default error return, so it just gives > you a general area to look in. You have to add some printk to get more > information. > > The schedule_work is in pxafb.c, it's the first function. > schedule_work is a way of deferring some activity until the appropriate > time to do that activity. You typically see it used by interrupt > handlers (which have to return quickly). So, they defer much of their > processing using schedule_work. What should happen is that a pointer to > the pxafb_task is passed to schedule_work. Perhaps a bad pointer is > being passed, or perhaps pxafb_task itself is doing something wrong. > > As soon as I go back under linux I'll recompile the kernel w/o the fb. = And > > I'll try to have a deeper look to the schedule_work function. > > > > Julien > > > > _________________________________________________________________ > > MSN Messenger : appels gratuits de PC =E0 PC ! > > http://www.msn.fr/newhotmail/Default.asp?Ath=3Df > > > > > > -----------------------------------------------------------------------= -- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share > > your > > opinions on IT & business topics through brief surveys-and earn cash > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID= =3DDEVDEV > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share y= our > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share y= our > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Julien L. <les...@ho...> - 2007-02-24 15:01:14
|
Hi, The lazy guy way could work here ? I mean, copy the 2.6.18 framebuffer source code to the 2.6.20 XD and compile it :D ?? >Yep - it does work with 2.6.18. > >There was another issue with cf not working with 2.6.20 from this >thread >http://thread.gmane.org/gmane.linux.distributions.gumstix.general/21309 >and it too was failing with the "probe of XX failed with error -12" >message. In this case I was able to figure out that it was a >misconfigured kernel for the pcmcia driver (or at least changing that >got it to work for me). So I first started looking into the 2.6.20 >kernel .config to see if something jumped out at me but I couldn't >find anything. If you diff the pxafb.c file from 2.6.18 to 2.6.20 you >can see that there are a lot of changes, but I'm not familiar enough >with the kernel/c to really know what is going on. Looking on google >found some hits on openembedded's site referring to mode changes in >the pxafb module starting with 2.6.19, but I never actually found a >patch or anything. > >I really have no need to update to 2.6.20 other than that I like to >keep current with the buildroot head. I'm going to keep plugging away >at trying to find a solution. > >Steve, given that 2.6.18 works, do you have any idea on where to start >looking for a fix? I was assuming the stuff with schedule_work was >just a bug in the RT kernel patches and not anything to do with the >fb, but I could be wrong there??? > >Chris > >On 2/24/07, Alexis Chiarello <chi...@ya...> wrote: > > Yes, I suppose it is only related to 2.6.20, as I dowgraded to the last > > release using 2.6.18 (1285) and everything works perfect. > > > > For your information, the schedule error shows up even without the > > framebuffer driver trying to load. > > > > Best, > > > > Alexis. > > ----- Original Message ----- > > From: "Steven A. Falco" <sa...@op...> > > To: "General mailing list for gumstix users." > > <gum...@li...> > > Sent: Saturday, February 24, 2007 9:33 AM > > Subject: Re: [Gumstix-users] About the gumstix kernel / UCB1400 / > > Framebuffer > > > > > > I think I missed something the first time I read this email thread. Are > > all the problems related to kernel 2.6.20? Does kernel 2.6.18 work > > correctly? > > > > > Ok so it can't allow memory ?? > > I would not conclude that - it is unlikely that you are really out of > > memory. Like I said, this is the default error return, so it just gives > > you a general area to look in. You have to add some printk to get more > > information. > > > The schedule_work is in pxafb.c, it's the first function. > > schedule_work is a way of deferring some activity until the appropriate > > time to do that activity. You typically see it used by interrupt > > handlers (which have to return quickly). So, they defer much of their > > processing using schedule_work. What should happen is that a pointer to > > the pxafb_task is passed to schedule_work. Perhaps a bad pointer is > > being passed, or perhaps pxafb_task itself is doing something wrong. > > > As soon as I go back under linux I'll recompile the kernel w/o the fb. >And > > > I'll try to have a deeper look to the schedule_work function. > > > > > > Julien > > > > > > _________________________________________________________________ > > > MSN Messenger : appels gratuits de PC à PC ! > > > http://www.msn.fr/newhotmail/Default.asp?Ath=f > > > > > > > > > >------------------------------------------------------------------------- > > > Take Surveys. Earn Cash. Influence the Future of IT > > > Join SourceForge.net's Techsay panel and you'll get the chance to >share > > > your > > > opinions on IT & business topics through brief surveys-and earn cash > > > >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > _______________________________________________ > > > gumstix-users mailing list > > > gum...@li... > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > > > > > >------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share >your > > opinions on IT & business topics through brief surveys-and earn cash > > >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > >------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share >your > > opinions on IT & business topics through brief surveys-and earn cash > > >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share >your >opinions on IT & business topics through brief surveys-and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >gumstix-users mailing list >gum...@li... >https://lists.sourceforge.net/lists/listinfo/gumstix-users _________________________________________________________________ MSN Messenger: appels gratuits de PC à PC ! http://www.msn.fr/newhotmail/Default.asp?Ath=f |
From: Craig H. <cr...@gu...> - 2007-02-26 23:00:22
|
On Feb 24, 2007, at 6:57 AM, Chris Dollar wrote: > Yep - it does work with 2.6.18. > > There was another issue with cf not working with 2.6.20 from this > thread http://thread.gmane.org/ > gmane.linux.distributions.gumstix.general/21309 > and it too was failing with the "probe of XX failed with error -12" > message. In this case I was able to figure out that it was a > misconfigured kernel for the pcmcia driver (or at least changing that > got it to work for me). So I first started looking into the 2.6.20 > kernel .config to see if something jumped out at me but I couldn't > find anything. If you diff the pxafb.c file from 2.6.18 to 2.6.20 you > can see that there are a lot of changes, but I'm not familiar enough > with the kernel/c to really know what is going on. Looking on google > found some hits on openembedded's site referring to mode changes in > the pxafb module starting with 2.6.19, but I never actually found a > patch or anything. > > I really have no need to update to 2.6.20 other than that I like to > keep current with the buildroot head. I'm going to keep plugging away > at trying to find a solution. > > Steve, given that 2.6.18 works, do you have any idea on where to start > looking for a fix? I was assuming the stuff with schedule_work was > just a bug in the RT kernel patches and not anything to do with the > fb, but I could be wrong there??? I took a look -- I think the change that's needed for 2.6.20 is that you need to call set_pxa_fb_info() from arch/arm/mach-pxa/gumstix.c, passing in args for your particular screen. See arch/arm/mach-pxa/ lubbock.c for how they do it there. C |
From: Steven A. F. <sa...@op...> - 2007-02-24 16:59:20
|
I am using the RT patches with 2.6.18, and that combination works. I don't know if something changed in 2.6.20 that broke the RT patches, or if the pxafb changes in 2.6.20 are broken. I will download 2.6.20 and take a look, to see if I can see anything obvious. I'm not sure what the best approach to debugging this is. You can start with something that works, then do a binary search of the different revisions of the gumstix-buildroot to find exactly where the bug was introduced. But, you are likely to find that it happened after a massive change, like jumping from 2.6.18 to 2.6.20. In that case, you would have to explore the patches that were applied to the kernel itself as it changed from 2.6.18 to 2.6.20. I'm not sure where to find these patches. Presumably you could use "git" to explore, but I have never done that. Or you can try printk or kgdb to go after the crash directly. Steve Chris Dollar wrote: > Yep - it does work with 2.6.18. > > There was another issue with cf not working with 2.6.20 from this > thread http://thread.gmane.org/gmane.linux.distributions.gumstix.general/21309 > and it too was failing with the "probe of XX failed with error -12" > message. In this case I was able to figure out that it was a > misconfigured kernel for the pcmcia driver (or at least changing that > got it to work for me). So I first started looking into the 2.6.20 > kernel .config to see if something jumped out at me but I couldn't > find anything. If you diff the pxafb.c file from 2.6.18 to 2.6.20 you > can see that there are a lot of changes, but I'm not familiar enough > with the kernel/c to really know what is going on. Looking on google > found some hits on openembedded's site referring to mode changes in > the pxafb module starting with 2.6.19, but I never actually found a > patch or anything. > > I really have no need to update to 2.6.20 other than that I like to > keep current with the buildroot head. I'm going to keep plugging away > at trying to find a solution. > > Steve, given that 2.6.18 works, do you have any idea on where to start > looking for a fix? I was assuming the stuff with schedule_work was > just a bug in the RT kernel patches and not anything to do with the > fb, but I could be wrong there??? > > Chris > > On 2/24/07, Alexis Chiarello <chi...@ya...> wrote: > >> Yes, I suppose it is only related to 2.6.20, as I dowgraded to the last >> release using 2.6.18 (1285) and everything works perfect. >> >> For your information, the schedule error shows up even without the >> framebuffer driver trying to load. >> >> Best, >> >> Alexis. >> ----- Original Message ----- >> From: "Steven A. Falco" <sa...@op...> >> To: "General mailing list for gumstix users." >> <gum...@li...> >> Sent: Saturday, February 24, 2007 9:33 AM >> Subject: Re: [Gumstix-users] About the gumstix kernel / UCB1400 / >> Framebuffer >> >> >> I think I missed something the first time I read this email thread. Are >> all the problems related to kernel 2.6.20? Does kernel 2.6.18 work >> correctly? >> >> >>> Ok so it can't allow memory ?? >>> >> I would not conclude that - it is unlikely that you are really out of >> memory. Like I said, this is the default error return, so it just gives >> you a general area to look in. You have to add some printk to get more >> information. >> >>> The schedule_work is in pxafb.c, it's the first function. >>> >> schedule_work is a way of deferring some activity until the appropriate >> time to do that activity. You typically see it used by interrupt >> handlers (which have to return quickly). So, they defer much of their >> processing using schedule_work. What should happen is that a pointer to >> the pxafb_task is passed to schedule_work. Perhaps a bad pointer is >> being passed, or perhaps pxafb_task itself is doing something wrong. >> >>> As soon as I go back under linux I'll recompile the kernel w/o the fb. And >>> I'll try to have a deeper look to the schedule_work function. >>> >>> Julien >>> >>> _________________________________________________________________ >>> MSN Messenger : appels gratuits de PC à PC ! >>> http://www.msn.fr/newhotmail/Default.asp?Ath=f >>> >>> >>> ------------------------------------------------------------------------- >>> Take Surveys. Earn Cash. Influence the Future of IT >>> Join SourceForge.net's Techsay panel and you'll get the chance to share >>> your >>> opinions on IT & business topics through brief surveys-and earn cash >>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >>> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |
From: Craig H. <cr...@gu...> - 2007-02-26 22:54:53
|
On Feb 24, 2007, at 6:09 AM, Julien Lebot wrote: >> Does this crash still happen if you remove the fb driver? >> >> Steve > > As soon as I go back under linux I'll recompile the kernel w/o the > fb. And > I'll try to have a deeper look to the schedule_work function. > Yes, that message seems to show up no matter what with the 2.6.20 kernel with RT stuff. The code snippet in sched.c is: 1 reacquire_kernel_lock(current); 1 if (!irqs_disabled()) { 1 static int once = 1; 1 if (once) { 1 once = 0; 1 print_irqtrace_events(current); 1 WARN_ON(1); 1 } 1 } right at the tail end of __schedule() -- the "1" prefix there shows that all those lines were added by the RT patch. C |
From: Dave H. <dhy...@gm...> - 2007-02-24 17:24:39
|
Hi guys, > But the crash is more important. If it is happening first, then you have to > fix it before you have any hope of getting the error -12 fixed. Th crash seems to happen on kernels with no fb too. I see it on mine as well. It seems to be related to the RT stuff (at leat that was what I concluded when I looked at the problem). So you might want to try rebuilding with the RT stuff turned off and at least that crash will go away. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Steven A. F. <sa...@op...> - 2007-02-24 21:45:32
|
I tried compiling with kernel feature "preemption mode" set to "no forced preemption", and with no frame buffer. I get this bug: BUG: at kernel/sched.c:4035 __schedule() [<c001cbc8>] (dump_stack+0x0/0x14) from [<c01379ac>] (__schedule+0x62c/0x678) [<c0137380>] (__schedule+0x0/0x678) from [<c0137af0>] (schedule+0xd0/0x118) [<c0137a20>] (schedule+0x0/0x118) from [<c0137efc>] (wait_for_completion+0x98/0xfc) r4 = C0263ED0 [<c0137e64>] (wait_for_completion+0x0/0xfc) from [<c003adf0>] (keventd_create_kthread+0x3c/0x60) r6 = C0263F1C r5 = 00000002 r4 = C0263F40 [<c003adb4>] (keventd_create_kthread+0x0/0x60) from [<c003ae94>] (kthread_create+0x80/0xcc) r6 = C0262000 r5 = C0263F1C r4 = 00000000 [<c003ae14>] (kthread_create+0x0/0xcc) from [<c003c074>] (posix_cpu_thread_call+0x40/0xb8) r3 = 00000000 r2 = C0167308 r5 = C00164B0 r4 = 00000000 [<c003c034>] (posix_cpu_thread_call+0x0/0xb8) from [<c000f6b4>] (posix_cpu_thread_init+0x24/0x40) r5 = C00164B0 r4 = C018DFA8 [<c000f690>] (posix_cpu_thread_init+0x0/0x40) from [<c0018068>] (init+0x3c/0x284) r4 = 00000000 [<c001802c>] (init+0x0/0x284) from [<c0029d34>] (do_exit+0x0/0x804) r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000 With preemption set to "realtime" I get: BUG: at kernel/sched.c:4035 __schedule() [<c001cd48>] (dump_stack+0x0/0x24) from [<c0143888>] (__schedule+0x6c8/0x718) [<c01431c0>] (__schedule+0x0/0x718) from [<c0143ac8>] (schedule+0xd0/0x118) [<c01439f8>] (schedule+0x0/0x118) from [<c003d2ac>] (kthread+0xc8/0x128) r4 = 00000000 [<c003d1e4>] (kthread+0x0/0x128) from [<c002b1b8>] (do_exit+0x0/0x85c) r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000 --------------------------- | preempt count: 00000000 ] | 0-level deep critical section nesting: ---------------------------------------- So, if the RT patch is relevant, then just changing that configuration setting is insufficient. It looks like this bug is triggered by interrupts being enabled when they should not be. I'm wondering if this discussion should be moved over to the linux-kernel mailing list where a larger group of developers can be consulted. Steve Dave Hylands wrote: > Hi guys, > > >> But the crash is more important. If it is happening first, then you have to >> fix it before you have any hope of getting the error -12 fixed. >> > > Th crash seems to happen on kernels with no fb too. I see it on mine > as well. It seems to be related to the RT stuff (at leat that was what > I concluded when I looked at the problem). So you might want to try > rebuilding with the RT stuff turned off and at least that crash will > go away. > > |
From: Chris D. <chr...@gm...> - 2007-02-25 01:47:52
|
I just compiled the 2.6.20 kernel with 'no forced preemption' and get the same results as you, Steve. I've never posted to the kernel list.... are you planning on doing that? Or does any one else have any other ideas? Chris On 2/24/07, Steven A. Falco <sa...@op...> wrote: > > I tried compiling with kernel feature "preemption mode" set to "no forced > preemption", and with no frame buffer. I get this bug: > > BUG: at kernel/sched.c:4035 __schedule() > [<c001cbc8>] (dump_stack+0x0/0x14) from [<c01379ac>] > (__schedule+0x62c/0x678) > [<c0137380>] (__schedule+0x0/0x678) from [<c0137af0>] (schedule+0xd0/0x118) > [<c0137a20>] (schedule+0x0/0x118) from [<c0137efc>] > (wait_for_completion+0x98/0xfc) > r4 = C0263ED0 > [<c0137e64>] (wait_for_completion+0x0/0xfc) from [<c003adf0>] > (keventd_create_kthread+0x3c/0x60) > r6 = C0263F1C r5 = 00000002 r4 = C0263F40 > [<c003adb4>] (keventd_create_kthread+0x0/0x60) from > [<c003ae94>] (kthread_create+0x80/0xcc) > r6 = C0262000 r5 = C0263F1C r4 = 00000000 > [<c003ae14>] (kthread_create+0x0/0xcc) from [<c003c074>] > (posix_cpu_thread_call+0x40/0xb8) > r3 = 00000000 r2 = C0167308 > r5 = C00164B0 r4 = 00000000 > [<c003c034>] (posix_cpu_thread_call+0x0/0xb8) from > [<c000f6b4>] (posix_cpu_thread_init+0x24/0x40) > r5 = C00164B0 r4 = C018DFA8 > [<c000f690>] (posix_cpu_thread_init+0x0/0x40) from > [<c0018068>] (init+0x3c/0x284) > r4 = 00000000 > [<c001802c>] (init+0x0/0x284) from [<c0029d34>] (do_exit+0x0/0x804) > r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000 > > With preemption set to "realtime" I get: > > BUG: at kernel/sched.c:4035 __schedule() > [<c001cd48>] (dump_stack+0x0/0x24) from [<c0143888>] > (__schedule+0x6c8/0x718) > [<c01431c0>] (__schedule+0x0/0x718) from [<c0143ac8>] (schedule+0xd0/0x118) > [<c01439f8>] (schedule+0x0/0x118) from [<c003d2ac>] (kthread+0xc8/0x128) > r4 = 00000000 > [<c003d1e4>] (kthread+0x0/0x128) from [<c002b1b8>] (do_exit+0x0/0x85c) > r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000 > --------------------------- > | preempt count: 00000000 ] > | 0-level deep critical section nesting: > ---------------------------------------- > > So, if the RT patch is relevant, then just changing that configuration > setting is insufficient. > > It looks like this bug is triggered by interrupts being enabled when they > should not be. I'm wondering if this discussion should be moved over to the > linux-kernel mailing list where a larger group of developers can be > consulted. > > Steve > > Dave Hylands wrote: > Hi guys, > > > > But the crash is more important. If it is happening first, then you have to > fix it before you have any hope of getting the error -12 fixed. > > Th crash seems to happen on kernels with no fb too. I see it on mine > as well. It seems to be related to the RT stuff (at leat that was what > I concluded when I looked at the problem). So you might want to try > rebuilding with the RT stuff turned off and at least that crash will > go away. > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |
From: Steven A. F. <sa...@op...> - 2007-02-25 16:21:02
|
I'm not on that list either - I don't do enough with the kernel to deal with the message volume. :-) Are any of the gumstix software engineers able to post the question? Steve Chris Dollar wrote: > I just compiled the 2.6.20 kernel with 'no forced preemption' and get > the same results as you, Steve. > > I've never posted to the kernel list.... are you planning on doing > that? Or does any one else have any other ideas? > > Chris > > On 2/24/07, Steven A. Falco <sa...@op...> wrote: > >> I tried compiling with kernel feature "preemption mode" set to "no forced >> preemption", and with no frame buffer. I get this bug: >> >> BUG: at kernel/sched.c:4035 __schedule() >> [<c001cbc8>] (dump_stack+0x0/0x14) from [<c01379ac>] >> (__schedule+0x62c/0x678) >> [<c0137380>] (__schedule+0x0/0x678) from [<c0137af0>] (schedule+0xd0/0x118) >> [<c0137a20>] (schedule+0x0/0x118) from [<c0137efc>] >> (wait_for_completion+0x98/0xfc) >> r4 = C0263ED0 >> [<c0137e64>] (wait_for_completion+0x0/0xfc) from [<c003adf0>] >> (keventd_create_kthread+0x3c/0x60) >> r6 = C0263F1C r5 = 00000002 r4 = C0263F40 >> [<c003adb4>] (keventd_create_kthread+0x0/0x60) from >> [<c003ae94>] (kthread_create+0x80/0xcc) >> r6 = C0262000 r5 = C0263F1C r4 = 00000000 >> [<c003ae14>] (kthread_create+0x0/0xcc) from [<c003c074>] >> (posix_cpu_thread_call+0x40/0xb8) >> r3 = 00000000 r2 = C0167308 >> r5 = C00164B0 r4 = 00000000 >> [<c003c034>] (posix_cpu_thread_call+0x0/0xb8) from >> [<c000f6b4>] (posix_cpu_thread_init+0x24/0x40) >> r5 = C00164B0 r4 = C018DFA8 >> [<c000f690>] (posix_cpu_thread_init+0x0/0x40) from >> [<c0018068>] (init+0x3c/0x284) >> r4 = 00000000 >> [<c001802c>] (init+0x0/0x284) from [<c0029d34>] (do_exit+0x0/0x804) >> r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000 >> >> With preemption set to "realtime" I get: >> >> BUG: at kernel/sched.c:4035 __schedule() >> [<c001cd48>] (dump_stack+0x0/0x24) from [<c0143888>] >> (__schedule+0x6c8/0x718) >> [<c01431c0>] (__schedule+0x0/0x718) from [<c0143ac8>] (schedule+0xd0/0x118) >> [<c01439f8>] (schedule+0x0/0x118) from [<c003d2ac>] (kthread+0xc8/0x128) >> r4 = 00000000 >> [<c003d1e4>] (kthread+0x0/0x128) from [<c002b1b8>] (do_exit+0x0/0x85c) >> r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000 >> --------------------------- >> | preempt count: 00000000 ] >> | 0-level deep critical section nesting: >> ---------------------------------------- >> >> So, if the RT patch is relevant, then just changing that configuration >> setting is insufficient. >> >> It looks like this bug is triggered by interrupts being enabled when they >> should not be. I'm wondering if this discussion should be moved over to the >> linux-kernel mailing list where a larger group of developers can be >> consulted. >> >> Steve >> >> Dave Hylands wrote: >> Hi guys, >> >> >> >> But the crash is more important. If it is happening first, then you have to >> fix it before you have any hope of getting the error -12 fixed. >> >> Th crash seems to happen on kernels with no fb too. I see it on mine >> as well. It seems to be related to the RT stuff (at leat that was what >> I concluded when I looked at the problem). So you might want to try >> rebuilding with the RT stuff turned off and at least that crash will >> go away. >> >> >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> >> > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |
From: Chris D. <chr...@gm...> - 2007-02-25 20:36:42
|
So I thought I'd pass on what I have found so far on the pxafb changes. It looks like they changed the driver to allow fixed modes to lessen the chance that someone passed bad params to the driver to the point that it fries an lcd screen. Here is the thread discussion on the arm kernel list http://marc2.theaimsgroup.com/?t=115101413400004&r=1&w=2 If I read the thread correctly it looks like if you want to use the fb you have to patch the kernel with a specific mode for you display (like they did for the different zauruses)?? Am I reading that correctly? And you can see the git commit on the kernel here http://gateway.total-knowledge.com/cgi-bin/gitweb.cgi?p=linux-mips.git;a=commit;h=d14b272bc63f35a8f20b4b1df16c080b8d24f8f1 I put some printks in the driver, and I can see that it fails at this call in int __init pxafb_probe(struct platform_device *dev): inf = dev->dev.platform_data; ret = -ENOMEM; fbi = NULL; if (!inf) goto failed; the driver change doesn't set platform_data anymore, so it is null and is causing the driver to fail with -ENOMEM. Could someone tell me if I'm reading that thread/code correctly? Thanks, Chris On 2/25/07, Steven A. Falco <sa...@op...> wrote: > > I'm not on that list either - I don't do enough with the kernel to deal > with the message volume. :-) > > Are any of the gumstix software engineers able to post the question? > > Steve > > > Chris Dollar wrote: > I just compiled the 2.6.20 kernel with 'no forced preemption' and get > the same results as you, Steve. > > I've never posted to the kernel list.... are you planning on doing > that? Or does any one else have any other ideas? > > Chris > > On 2/24/07, Steven A. Falco <sa...@op...> wrote: > > > I tried compiling with kernel feature "preemption mode" set to "no forced > preemption", and with no frame buffer. I get this bug: > > BUG: at kernel/sched.c:4035 __schedule() > [<c001cbc8>] (dump_stack+0x0/0x14) from [<c01379ac>] > (__schedule+0x62c/0x678) > [<c0137380>] (__schedule+0x0/0x678) from [<c0137af0>] (schedule+0xd0/0x118) > [<c0137a20>] (schedule+0x0/0x118) from [<c0137efc>] > (wait_for_completion+0x98/0xfc) > r4 = C0263ED0 > [<c0137e64>] (wait_for_completion+0x0/0xfc) from [<c003adf0>] > (keventd_create_kthread+0x3c/0x60) > r6 = C0263F1C r5 = 00000002 r4 = C0263F40 > [<c003adb4>] (keventd_create_kthread+0x0/0x60) from > [<c003ae94>] (kthread_create+0x80/0xcc) > r6 = C0262000 r5 = C0263F1C r4 = 00000000 > [<c003ae14>] (kthread_create+0x0/0xcc) from [<c003c074>] > (posix_cpu_thread_call+0x40/0xb8) > r3 = 00000000 r2 = C0167308 > r5 = C00164B0 r4 = 00000000 > [<c003c034>] (posix_cpu_thread_call+0x0/0xb8) from > [<c000f6b4>] (posix_cpu_thread_init+0x24/0x40) > r5 = C00164B0 r4 = C018DFA8 > [<c000f690>] (posix_cpu_thread_init+0x0/0x40) from > [<c0018068>] (init+0x3c/0x284) > r4 = 00000000 > [<c001802c>] (init+0x0/0x284) from [<c0029d34>] (do_exit+0x0/0x804) > r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000 > > With preemption set to "realtime" I get: > > BUG: at kernel/sched.c:4035 __schedule() > [<c001cd48>] (dump_stack+0x0/0x24) from [<c0143888>] > (__schedule+0x6c8/0x718) > [<c01431c0>] (__schedule+0x0/0x718) from [<c0143ac8>] (schedule+0xd0/0x118) > [<c01439f8>] (schedule+0x0/0x118) from [<c003d2ac>] (kthread+0xc8/0x128) > r4 = 00000000 > [<c003d1e4>] (kthread+0x0/0x128) from [<c002b1b8>] (do_exit+0x0/0x85c) > r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000 > --------------------------- > | preempt count: 00000000 ] > | 0-level deep critical section nesting: > ---------------------------------------- > > So, if the RT patch is relevant, then just changing that configuration > setting is insufficient. > > It looks like this bug is triggered by interrupts being enabled when they > should not be. I'm wondering if this discussion should be moved over to the > linux-kernel mailing list where a larger group of developers can be > consulted. > > Steve > > Dave Hylands wrote: > Hi guys, > > > > But the crash is more important. If it is happening first, then you have to > fix it before you have any hope of getting the error -12 fixed. > > Th crash seems to happen on kernels with no fb too. I see it on mine > as well. It seems to be related to the RT stuff (at leat that was what > I concluded when I looked at the problem). So you might want to try > rebuilding with the RT stuff turned off and at least that crash will > go away. > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |
From: Chris D. <chr...@gm...> - 2007-02-25 23:44:16
Attachments:
gumstix-dev-fb.patch
|
Ok, so I got it figured out. The change to the driver makes you call the new 'void __init set_pxa_fb_info(struct pxafb_mach_info *info)' when the machine inits itself. This means that (as far as I can tell) you have to create some sort of fb config initially, which you can then override with the pxafb stuff in your kernel bootargs. Attached is the patch I used to get it to work. The patch should be placed in <gumstix-buildroot>/target/device/Gumstix/basix-connex/kernel-patches and then you'll have to rebuild your kernel. If you have a look at the patch you can see how I setup the fb, which happens to be the setup for my alps lcd. You could easily change those values to suit another lcd. And again, you can always override those values with your bootargs assuming you build that option into your kernel (the one about framebuffer command line args). So it had nothing to do with the bug in sched.c, which I still see when I boot up. Chris On 2/25/07, Chris Dollar <chr...@gm...> wrote: > So I thought I'd pass on what I have found so far on the pxafb changes. > > It looks like they changed the driver to allow fixed modes to lessen > the chance that someone passed bad params to the driver to the point > that it fries an lcd screen. Here is the thread discussion on the arm > kernel list http://marc2.theaimsgroup.com/?t=115101413400004&r=1&w=2 > > If I read the thread correctly it looks like if you want to use the fb > you have to patch the kernel with a specific mode for you display > (like they did for the different zauruses)?? Am I reading that > correctly? > > And you can see the git commit on the kernel here > http://gateway.total-knowledge.com/cgi-bin/gitweb.cgi?p=linux-mips.git;a=commit;h=d14b272bc63f35a8f20b4b1df16c080b8d24f8f1 > > I put some printks in the driver, and I can see that it fails at this > call in int __init pxafb_probe(struct platform_device *dev): > inf = dev->dev.platform_data; > ret = -ENOMEM; > fbi = NULL; > if (!inf) > goto failed; > > the driver change doesn't set platform_data anymore, so it is null and > is causing the driver to fail with -ENOMEM. > > Could someone tell me if I'm reading that thread/code correctly? > > Thanks, > Chris > > On 2/25/07, Steven A. Falco <sa...@op...> wrote: > > > > I'm not on that list either - I don't do enough with the kernel to deal > > with the message volume. :-) > > > > Are any of the gumstix software engineers able to post the question? > > > > Steve > > > > > > Chris Dollar wrote: > > I just compiled the 2.6.20 kernel with 'no forced preemption' and get > > the same results as you, Steve. > > > > I've never posted to the kernel list.... are you planning on doing > > that? Or does any one else have any other ideas? > > > > Chris > > > > On 2/24/07, Steven A. Falco <sa...@op...> wrote: > > > > > > I tried compiling with kernel feature "preemption mode" set to "no forced > > preemption", and with no frame buffer. I get this bug: > > > > BUG: at kernel/sched.c:4035 __schedule() > > [<c001cbc8>] (dump_stack+0x0/0x14) from [<c01379ac>] > > (__schedule+0x62c/0x678) > > [<c0137380>] (__schedule+0x0/0x678) from [<c0137af0>] (schedule+0xd0/0x118) > > [<c0137a20>] (schedule+0x0/0x118) from [<c0137efc>] > > (wait_for_completion+0x98/0xfc) > > r4 = C0263ED0 > > [<c0137e64>] (wait_for_completion+0x0/0xfc) from [<c003adf0>] > > (keventd_create_kthread+0x3c/0x60) > > r6 = C0263F1C r5 = 00000002 r4 = C0263F40 > > [<c003adb4>] (keventd_create_kthread+0x0/0x60) from > > [<c003ae94>] (kthread_create+0x80/0xcc) > > r6 = C0262000 r5 = C0263F1C r4 = 00000000 > > [<c003ae14>] (kthread_create+0x0/0xcc) from [<c003c074>] > > (posix_cpu_thread_call+0x40/0xb8) > > r3 = 00000000 r2 = C0167308 > > r5 = C00164B0 r4 = 00000000 > > [<c003c034>] (posix_cpu_thread_call+0x0/0xb8) from > > [<c000f6b4>] (posix_cpu_thread_init+0x24/0x40) > > r5 = C00164B0 r4 = C018DFA8 > > [<c000f690>] (posix_cpu_thread_init+0x0/0x40) from > > [<c0018068>] (init+0x3c/0x284) > > r4 = 00000000 > > [<c001802c>] (init+0x0/0x284) from [<c0029d34>] (do_exit+0x0/0x804) > > r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000 > > > > With preemption set to "realtime" I get: > > > > BUG: at kernel/sched.c:4035 __schedule() > > [<c001cd48>] (dump_stack+0x0/0x24) from [<c0143888>] > > (__schedule+0x6c8/0x718) > > [<c01431c0>] (__schedule+0x0/0x718) from [<c0143ac8>] (schedule+0xd0/0x118) > > [<c01439f8>] (schedule+0x0/0x118) from [<c003d2ac>] (kthread+0xc8/0x128) > > r4 = 00000000 > > [<c003d1e4>] (kthread+0x0/0x128) from [<c002b1b8>] (do_exit+0x0/0x85c) > > r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000 > > --------------------------- > > | preempt count: 00000000 ] > > | 0-level deep critical section nesting: > > ---------------------------------------- > > > > So, if the RT patch is relevant, then just changing that configuration > > setting is insufficient. > > > > It looks like this bug is triggered by interrupts being enabled when they > > should not be. I'm wondering if this discussion should be moved over to the > > linux-kernel mailing list where a larger group of developers can be > > consulted. > > > > Steve > > > > Dave Hylands wrote: > > Hi guys, > > > > > > > > But the crash is more important. If it is happening first, then you have to > > fix it before you have any hope of getting the error -12 fixed. > > > > Th crash seems to happen on kernels with no fb too. I see it on mine > > as well. It seems to be related to the RT stuff (at leat that was what > > I concluded when I looked at the problem). So you might want to try > > rebuilding with the RT stuff turned off and at least that crash will > > go away. > > > > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > opinions on IT & business topics through brief surveys-and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > opinions on IT & business topics through brief surveys-and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > opinions on IT & business topics through brief surveys-and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > |
From: Chris D. <chr...@gm...> - 2007-02-26 00:34:00
Attachments:
gumstix.c
|
Well.... that patch doesn't work. Its not getting applied to the kernel when the other patches in the kernel-patched directory get applied. At any rate, attached is my modified gumstix.c file. Drop it over the <gumstix-buildroot>/build_arm_nofpu/linux-2.6.20gum/arch/arm/mach-pxa/gumstix.c file. Then I did a 'rm build_arm_nofpu/linux-2.6.20gum/arch/arm/mach-pxa/gumstix.o' and 'rm build_arm_nofpu/linux-2.6.20gum/arch/arm/boot/compressed/vmlinux' and then make from the main buildroot dir to get the kernel rebuilt. Chris On 2/25/07, Chris Dollar <chr...@gm...> wrote: > Ok, so I got it figured out. > > The change to the driver makes you call the new 'void __init > set_pxa_fb_info(struct pxafb_mach_info *info)' when the machine inits > itself. This means that (as far as I can tell) you have to create > some sort of fb config initially, which you can then override with the > pxafb stuff in your kernel bootargs. > > Attached is the patch I used to get it to work. The patch should be > placed in <gumstix-buildroot>/target/device/Gumstix/basix-connex/kernel-patches > and then you'll have to rebuild your kernel. > > If you have a look at the patch you can see how I setup the fb, which > happens to be the setup for my alps lcd. You could easily change > those values to suit another lcd. And again, you can always > override those values with your bootargs assuming you build that > option into your kernel (the one about framebuffer command line args). > > So it had nothing to do with the bug in sched.c, which I still see > when I boot up. > > Chris > > On 2/25/07, Chris Dollar <chr...@gm...> wrote: > > So I thought I'd pass on what I have found so far on the pxafb changes. > > > > It looks like they changed the driver to allow fixed modes to lessen > > the chance that someone passed bad params to the driver to the point > > that it fries an lcd screen. Here is the thread discussion on the arm > > kernel list http://marc2.theaimsgroup.com/?t=115101413400004&r=1&w=2 > > > > If I read the thread correctly it looks like if you want to use the fb > > you have to patch the kernel with a specific mode for you display > > (like they did for the different zauruses)?? Am I reading that > > correctly? > > > > And you can see the git commit on the kernel here > > http://gateway.total-knowledge.com/cgi-bin/gitweb.cgi?p=linux-mips.git;a=commit;h=d14b272bc63f35a8f20b4b1df16c080b8d24f8f1 > > > > I put some printks in the driver, and I can see that it fails at this > > call in int __init pxafb_probe(struct platform_device *dev): > > inf = dev->dev.platform_data; > > ret = -ENOMEM; > > fbi = NULL; > > if (!inf) > > goto failed; > > > > the driver change doesn't set platform_data anymore, so it is null and > > is causing the driver to fail with -ENOMEM. > > > > Could someone tell me if I'm reading that thread/code correctly? > > > > Thanks, > > Chris > > > > On 2/25/07, Steven A. Falco <sa...@op...> wrote: > > > > > > I'm not on that list either - I don't do enough with the kernel to deal > > > with the message volume. :-) > > > > > > Are any of the gumstix software engineers able to post the question? > > > > > > Steve > > > > > > > > > Chris Dollar wrote: > > > I just compiled the 2.6.20 kernel with 'no forced preemption' and get > > > the same results as you, Steve. > > > > > > I've never posted to the kernel list.... are you planning on doing > > > that? Or does any one else have any other ideas? > > > > > > Chris > > > > > > On 2/24/07, Steven A. Falco <sa...@op...> wrote: > > > > > > > > > I tried compiling with kernel feature "preemption mode" set to "no forced > > > preemption", and with no frame buffer. I get this bug: > > > > > > BUG: at kernel/sched.c:4035 __schedule() > > > [<c001cbc8>] (dump_stack+0x0/0x14) from [<c01379ac>] > > > (__schedule+0x62c/0x678) > > > [<c0137380>] (__schedule+0x0/0x678) from [<c0137af0>] (schedule+0xd0/0x118) > > > [<c0137a20>] (schedule+0x0/0x118) from [<c0137efc>] > > > (wait_for_completion+0x98/0xfc) > > > r4 = C0263ED0 > > > [<c0137e64>] (wait_for_completion+0x0/0xfc) from [<c003adf0>] > > > (keventd_create_kthread+0x3c/0x60) > > > r6 = C0263F1C r5 = 00000002 r4 = C0263F40 > > > [<c003adb4>] (keventd_create_kthread+0x0/0x60) from > > > [<c003ae94>] (kthread_create+0x80/0xcc) > > > r6 = C0262000 r5 = C0263F1C r4 = 00000000 > > > [<c003ae14>] (kthread_create+0x0/0xcc) from [<c003c074>] > > > (posix_cpu_thread_call+0x40/0xb8) > > > r3 = 00000000 r2 = C0167308 > > > r5 = C00164B0 r4 = 00000000 > > > [<c003c034>] (posix_cpu_thread_call+0x0/0xb8) from > > > [<c000f6b4>] (posix_cpu_thread_init+0x24/0x40) > > > r5 = C00164B0 r4 = C018DFA8 > > > [<c000f690>] (posix_cpu_thread_init+0x0/0x40) from > > > [<c0018068>] (init+0x3c/0x284) > > > r4 = 00000000 > > > [<c001802c>] (init+0x0/0x284) from [<c0029d34>] (do_exit+0x0/0x804) > > > r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000 > > > > > > With preemption set to "realtime" I get: > > > > > > BUG: at kernel/sched.c:4035 __schedule() > > > [<c001cd48>] (dump_stack+0x0/0x24) from [<c0143888>] > > > (__schedule+0x6c8/0x718) > > > [<c01431c0>] (__schedule+0x0/0x718) from [<c0143ac8>] (schedule+0xd0/0x118) > > > [<c01439f8>] (schedule+0x0/0x118) from [<c003d2ac>] (kthread+0xc8/0x128) > > > r4 = 00000000 > > > [<c003d1e4>] (kthread+0x0/0x128) from [<c002b1b8>] (do_exit+0x0/0x85c) > > > r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000 > > > --------------------------- > > > | preempt count: 00000000 ] > > > | 0-level deep critical section nesting: > > > ---------------------------------------- > > > > > > So, if the RT patch is relevant, then just changing that configuration > > > setting is insufficient. > > > > > > It looks like this bug is triggered by interrupts being enabled when they > > > should not be. I'm wondering if this discussion should be moved over to the > > > linux-kernel mailing list where a larger group of developers can be > > > consulted. > > > > > > Steve > > > > > > Dave Hylands wrote: > > > Hi guys, > > > > > > > > > > > > But the crash is more important. If it is happening first, then you have to > > > fix it before you have any hope of getting the error -12 fixed. > > > > > > Th crash seems to happen on kernels with no fb too. I see it on mine > > > as well. It seems to be related to the RT stuff (at leat that was what > > > I concluded when I looked at the problem). So you might want to try > > > rebuilding with the RT stuff turned off and at least that crash will > > > go away. > > > > > > > > > > > > ------------------------------------------------------------------------- > > > Take Surveys. Earn Cash. Influence the Future of IT > > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > > opinions on IT & business topics through brief surveys-and earn cash > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > _______________________________________________ > > > gumstix-users mailing list > > > gum...@li... > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > > > > > > > ------------------------------------------------------------------------- > > > Take Surveys. Earn Cash. Influence the Future of IT > > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > > opinions on IT & business topics through brief surveys-and earn cash > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > _______________________________________________ > > > gumstix-users mailing list > > > gum...@li... > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > > > > > > > ------------------------------------------------------------------------- > > > Take Surveys. Earn Cash. Influence the Future of IT > > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > > opinions on IT & business topics through brief surveys-and earn cash > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > _______________________________________________ > > > gumstix-users mailing list > > > gum...@li... > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > > > > > |
From: Julien L. <les...@ho...> - 2007-02-26 13:01:37
|
Hi, Thanks very much for finding a solution to it :) I was wondering, if I just need the framebuffer, but not the pxa LCD controller (I'm using those pins as GPIO), can I just put: static struct pxafb_mode_info gumstix_fb_mode = { .pixclock = 0, .xres = 128, .yres = 128, .bpp = 16, .hsync_len = 0, .left_margin = 0, .right_margin = 0, .vsync_len = 0, .upper_margin = 0, .lower_margin = 0, .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, }; ?? Regards, Julien NB: and again thanks for working a solution out :) >Well.... that patch doesn't work. Its not getting applied to the >kernel when the other patches in the kernel-patched directory get >applied. > >At any rate, attached is my modified gumstix.c file. Drop it over the ><gumstix-buildroot>/build_arm_nofpu/linux-2.6.20gum/arch/arm/mach-pxa/gumstix.c >file. Then I did a 'rm >build_arm_nofpu/linux-2.6.20gum/arch/arm/mach-pxa/gumstix.o' and 'rm >build_arm_nofpu/linux-2.6.20gum/arch/arm/boot/compressed/vmlinux' and >then make from the main buildroot dir to get the kernel rebuilt. > >Chris > _________________________________________________________________ MSN Messenger: appels gratuits de PC à PC ! http://www.msn.fr/newhotmail/Default.asp?Ath=f |
From: Chris D. <chr...@gm...> - 2007-02-26 15:12:06
|
Well... I'm not really sure ;) I think it could work, but it might depend on which pins you are trying to use as gpios. In my case, I have an 8bpp passive lcd, so I'm only using LDD0-7. And the only way I got the pxafb driver to work was to put it in 16bpp mode, so I think as far as the driver is concerned it believes I have lcd data lines tied to LDD0-15. I'm using the LDD15 (GPIO73) as the lcd enable pin, so I have it reconfigured as a gpio-out and that doesn't cause me any problems with the display (and I'm sure I could do the same for any of the LDD pins). I think the key is to configure the pin as a gpio after you load the fb driver (or just compile the driver directly into the kernel so it is just setup that way). You might get a different result if you try to reconfigure one of the lcd clock pins... I've never done that since I use them for the display. But as far as the driver is concerned, I would just give it a try and see what happens. If it doesn't load with the 'missing' values, throw some dummy ones in there and then just reconfigure the pins as gpios afterwards and see what you get. Good luck! Chris On 2/26/07, Julien Lebot <les...@ho...> wrote: > Hi, > > Thanks very much for finding a solution to it :) > I was wondering, if I just need the framebuffer, but not the pxa LCD > controller (I'm using those pins as GPIO), can I just put: > > static struct pxafb_mode_info gumstix_fb_mode =3D { > .pixclock =3D 0, > .xres =3D 128, > .yres =3D 128, > .bpp =3D 16, > .hsync_len =3D 0, > .left_margin =3D 0, > .right_margin =3D 0, > .vsync_len =3D 0, > .upper_margin =3D 0, > .lower_margin =3D 0, > .sync =3D FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, > }; > > ?? > > Regards, > Julien > > NB: and again thanks for working a solution out :) > > >Well.... that patch doesn't work. Its not getting applied to the > >kernel when the other patches in the kernel-patched directory get > >applied. > > > >At any rate, attached is my modified gumstix.c file. Drop it over the > ><gumstix-buildroot>/build_arm_nofpu/linux-2.6.20gum/arch/arm/mach-pxa/gu= mstix.c > >file. Then I did a 'rm > >build_arm_nofpu/linux-2.6.20gum/arch/arm/mach-pxa/gumstix.o' and 'rm > >build_arm_nofpu/linux-2.6.20gum/arch/arm/boot/compressed/vmlinux' and > >then make from the main buildroot dir to get the kernel rebuilt. > > > >Chris > > > > _________________________________________________________________ > MSN Messenger: appels gratuits de PC =E0 PC ! > http://www.msn.fr/newhotmail/Default.asp?Ath=3Df > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share y= our > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Julien L. <les...@ho...> - 2007-02-26 15:35:58
|
Hi ! I do owe you a beer for sure, I have been looking for that solution for sooo long :) It works with the 0 values (yep I was to excited to wait and already switched to linux, compiled, switched back to Win, and flashed it !). Well it is just overriding the values, that's what the kernel log tell me and I still have the bootargs set. Anyway I'll give my new 4D OLED LCD screen a try with it, it must work :) The only think I still can't get is how do I access the framebuffer from the kernel space, do I have to write directly to the memory or ? I've been googling for a while now but no solutions yet... Basically what I want to do is that my driver check periodically the framebuffer content, if something is different, update the LCD... shouldn't be too difficult... ? Otherwise I'll hook a 'classic' active matrix LCD screen (the PSP one :) ) but the 4D LCD get the size for it (soo small !) Kind regards, Julien _________________________________________________________________ MSN Messenger : discutez en direct avec vos amis ! http://www.msn.fr/msger/default.asp |
From: Ian S. <it...@cs...> - 2007-02-26 15:53:53
|
ive been wandering the wiki and cant seem to piece together what all needs to happen to make the a certain uart work on the breakout-gs. the uart im looking for is the one on the usb side of the board second cluster from the hirose connector. once its working what tty port will it use? any help would be appreciated -Ian |
From: Dave H. <dhy...@gm...> - 2007-02-26 18:29:27
|
Hi Julien, > I do owe you a beer for sure, I have been looking for that solution for sooo > long :) > It works with the 0 values (yep I was to excited to wait and already > switched to linux, compiled, switched back to Win, and flashed it !). > Well it is just overriding the values, that's what the kernel log tell me > and I still have the bootargs set. Anyway I'll give my new 4D OLED LCD > screen a try with it, it must work :) > > The only think I still can't get is how do I access the framebuffer from the > kernel space, do I have to write directly to the memory or ? I've been > googling for a while now but no solutions yet... Basically what I want to do > is that my driver check periodically the framebuffer content, if something > is different, update the LCD... shouldn't be too difficult... ? > > Otherwise I'll hook a 'classic' active matrix LCD screen (the PSP one :) ) > but the 4D LCD get the size for it (soo small !) What I did (on another non-gumstix project) was to allocate a buffer in kernel space (no pxafb - just allocate a buffer) and mmap it into microwindows (user mode program). Microwindows has function pointers to all of its drawing routines, so I installed my own function for each that updates a low & high dirty row, and then I call the original callback to draw into the frame buffer. Microwindows also has another hook which gets called just before it goes idle. This means that there are no further events for it to process, and is a good time to update the screen. So I examine the dirty row markers and if anything needs to be transferred, I then transfer the data to the LCD and reset the dirty rows. I created my own helper driver that Microwindows uses. The helper driver basically just takes care of allocating the frame buffer and doing the actual transfer of the frame buffer to the LCD. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Craig H. <cr...@gu...> - 2007-02-26 23:03:54
|
On Feb 25, 2007, at 4:33 PM, Chris Dollar wrote: > Well.... that patch doesn't work. Its not getting applied to the > kernel when the other patches in the kernel-patched directory get > applied. You need to add the patch to the "series" file too. Or else add it using quilt and quilt will update the series file for you. > At any rate, attached is my modified gumstix.c file. Drop it over the > <gumstix-buildroot>/build_arm_nofpu/linux-2.6.20gum/arch/arm/mach- > pxa/gumstix.c > file. Then I did a 'rm > build_arm_nofpu/linux-2.6.20gum/arch/arm/mach-pxa/gumstix.o' and 'rm > build_arm_nofpu/linux-2.6.20gum/arch/arm/boot/compressed/vmlinux' and > then make from the main buildroot dir to get the kernel rebuilt. I'll add in your patch for the ALPS screen, making it a config sub- option on the PXAFB config stuff. If anyone else has other panels they'd like me to add too, then please let me know what settings to put in there for your panel, and I'll stick them in as alternate config options. C |
From: Julien L. <les...@ho...> - 2007-02-27 03:05:50
|
Hi, The modification works even with 0 values for hsync etc.... so you could provide the file as it is and simply indicate people where to do the modifications if they plan to use the gumstix fb, no ? Now one should figure out, which one of the bootargs or the gumstix.c will override the other. Julien >I'll add in your patch for the ALPS screen, making it a config sub- >option on the PXAFB config stuff. If anyone else has other panels >they'd like me to add too, then please let me know what settings to >put in there for your panel, and I'll stick them in as alternate >config options. > >C _________________________________________________________________ MSN Hotmail sur i-mode : envoyez et recevez des e-mails depuis votre téléphone portable ! http://www.msn.fr/hotmailimode/ |
From: Craig H. <cr...@gu...> - 2007-02-26 23:11:02
|
Chris -- what model is the ALPS screen you're using, just so I can doc it properly in the config stuff I'm adding? Thanks C On Feb 25, 2007, at 4:33 PM, Chris Dollar wrote: > Well.... that patch doesn't work. Its not getting applied to the > kernel when the other patches in the kernel-patched directory get > applied. > > At any rate, attached is my modified gumstix.c file. Drop it over the > <gumstix-buildroot>/build_arm_nofpu/linux-2.6.20gum/arch/arm/mach- > pxa/gumstix.c > file. Then I did a 'rm > build_arm_nofpu/linux-2.6.20gum/arch/arm/mach-pxa/gumstix.o' and 'rm > build_arm_nofpu/linux-2.6.20gum/arch/arm/boot/compressed/vmlinux' and > then make from the main buildroot dir to get the kernel rebuilt. > > Chris > > On 2/25/07, Chris Dollar <chr...@gm...> wrote: >> Ok, so I got it figured out. >> >> The change to the driver makes you call the new 'void __init >> set_pxa_fb_info(struct pxafb_mach_info *info)' when the machine >> inits >> itself. This means that (as far as I can tell) you have to create >> some sort of fb config initially, which you can then override with >> the >> pxafb stuff in your kernel bootargs. >> >> Attached is the patch I used to get it to work. The patch should be >> placed in <gumstix-buildroot>/target/device/Gumstix/basix-connex/ >> kernel-patches >> and then you'll have to rebuild your kernel. >> >> If you have a look at the patch you can see how I setup the fb, which >> happens to be the setup for my alps lcd. You could easily change >> those values to suit another lcd. And again, you can always >> override those values with your bootargs assuming you build that >> option into your kernel (the one about framebuffer command line >> args). >> >> So it had nothing to do with the bug in sched.c, which I still see >> when I boot up. >> >> Chris >> >> On 2/25/07, Chris Dollar <chr...@gm...> wrote: >> > So I thought I'd pass on what I have found so far on the pxafb >> changes. >> > >> > It looks like they changed the driver to allow fixed modes to >> lessen >> > the chance that someone passed bad params to the driver to the >> point >> > that it fries an lcd screen. Here is the thread discussion on >> the arm >> > kernel list http://marc2.theaimsgroup.com/? >> t=115101413400004&r=1&w=2 >> > >> > If I read the thread correctly it looks like if you want to use >> the fb >> > you have to patch the kernel with a specific mode for you display >> > (like they did for the different zauruses)?? Am I reading that >> > correctly? >> > >> > And you can see the git commit on the kernel here >> > http://gateway.total-knowledge.com/cgi-bin/gitweb.cgi?p=linux- >> mips.git;a=commit;h=d14b272bc63f35a8f20b4b1df16c080b8d24f8f1 >> > >> > I put some printks in the driver, and I can see that it fails at >> this >> > call in int __init pxafb_probe(struct platform_device *dev): >> > inf = dev->dev.platform_data; >> > ret = -ENOMEM; >> > fbi = NULL; >> > if (!inf) >> > goto failed; >> > >> > the driver change doesn't set platform_data anymore, so it is >> null and >> > is causing the driver to fail with -ENOMEM. >> > >> > Could someone tell me if I'm reading that thread/code correctly? >> > >> > Thanks, >> > Chris >> > >> > On 2/25/07, Steven A. Falco <sa...@op...> wrote: >> > > >> > > I'm not on that list either - I don't do enough with the >> kernel to deal >> > > with the message volume. :-) >> > > >> > > Are any of the gumstix software engineers able to post the >> question? >> > > >> > > Steve >> > > >> > > >> > > Chris Dollar wrote: >> > > I just compiled the 2.6.20 kernel with 'no forced preemption' >> and get >> > > the same results as you, Steve. >> > > >> > > I've never posted to the kernel list.... are you planning on >> doing >> > > that? Or does any one else have any other ideas? >> > > >> > > Chris >> > > >> > > On 2/24/07, Steven A. Falco <sa...@op...> wrote: >> > > >> > > >> > > I tried compiling with kernel feature "preemption mode" set >> to "no forced >> > > preemption", and with no frame buffer. I get this bug: >> > > >> > > BUG: at kernel/sched.c:4035 __schedule() >> > > [<c001cbc8>] (dump_stack+0x0/0x14) from [<c01379ac>] >> > > (__schedule+0x62c/0x678) >> > > [<c0137380>] (__schedule+0x0/0x678) from [<c0137af0>] >> (schedule+0xd0/0x118) >> > > [<c0137a20>] (schedule+0x0/0x118) from [<c0137efc>] >> > > (wait_for_completion+0x98/0xfc) >> > > r4 = C0263ED0 >> > > [<c0137e64>] (wait_for_completion+0x0/0xfc) from [<c003adf0>] >> > > (keventd_create_kthread+0x3c/0x60) >> > > r6 = C0263F1C r5 = 00000002 r4 = C0263F40 >> > > [<c003adb4>] (keventd_create_kthread+0x0/0x60) from >> > > [<c003ae94>] (kthread_create+0x80/0xcc) >> > > r6 = C0262000 r5 = C0263F1C r4 = 00000000 >> > > [<c003ae14>] (kthread_create+0x0/0xcc) from [<c003c074>] >> > > (posix_cpu_thread_call+0x40/0xb8) >> > > r3 = 00000000 r2 = C0167308 >> > > r5 = C00164B0 r4 = 00000000 >> > > [<c003c034>] (posix_cpu_thread_call+0x0/0xb8) from >> > > [<c000f6b4>] (posix_cpu_thread_init+0x24/0x40) >> > > r5 = C00164B0 r4 = C018DFA8 >> > > [<c000f690>] (posix_cpu_thread_init+0x0/0x40) from >> > > [<c0018068>] (init+0x3c/0x284) >> > > r4 = 00000000 >> > > [<c001802c>] (init+0x0/0x284) from [<c0029d34>] (do_exit >> +0x0/0x804) >> > > r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000 >> > > >> > > With preemption set to "realtime" I get: >> > > >> > > BUG: at kernel/sched.c:4035 __schedule() >> > > [<c001cd48>] (dump_stack+0x0/0x24) from [<c0143888>] >> > > (__schedule+0x6c8/0x718) >> > > [<c01431c0>] (__schedule+0x0/0x718) from [<c0143ac8>] >> (schedule+0xd0/0x118) >> > > [<c01439f8>] (schedule+0x0/0x118) from [<c003d2ac>] (kthread >> +0xc8/0x128) >> > > r4 = 00000000 >> > > [<c003d1e4>] (kthread+0x0/0x128) from [<c002b1b8>] (do_exit >> +0x0/0x85c) >> > > r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000 >> > > --------------------------- >> > > | preempt count: 00000000 ] >> > > | 0-level deep critical section nesting: >> > > ---------------------------------------- >> > > >> > > So, if the RT patch is relevant, then just changing that >> configuration >> > > setting is insufficient. >> > > >> > > It looks like this bug is triggered by interrupts being >> enabled when they >> > > should not be. I'm wondering if this discussion should be >> moved over to the >> > > linux-kernel mailing list where a larger group of developers >> can be >> > > consulted. >> > > >> > > Steve >> > > >> > > Dave Hylands wrote: >> > > Hi guys, >> > > >> > > >> > > >> > > But the crash is more important. If it is happening first, >> then you have to >> > > fix it before you have any hope of getting the error -12 fixed. >> > > >> > > Th crash seems to happen on kernels with no fb too. I see it >> on mine >> > > as well. It seems to be related to the RT stuff (at leat that >> was what >> > > I concluded when I looked at the problem). So you might want >> to try >> > > rebuilding with the RT stuff turned off and at least that >> crash will >> > > go away. >> > > >> > > >> > > >> > > >> --------------------------------------------------------------------- >> ---- >> > > Take Surveys. Earn Cash. Influence the Future of IT >> > > Join SourceForge.net's Techsay panel and you'll get the chance >> to share your >> > > opinions on IT & business topics through brief surveys-and >> earn cash >> > > http://www.techsay.com/default.php? >> page=join.php&p=sourceforge&CID=DEVDEV >> > > _______________________________________________ >> > > gumstix-users mailing list >> > > gum...@li... >> > > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > >> > > >> > > >> > > >> --------------------------------------------------------------------- >> ---- >> > > Take Surveys. Earn Cash. Influence the Future of IT >> > > Join SourceForge.net's Techsay panel and you'll get the chance >> to share your >> > > opinions on IT & business topics through brief surveys-and >> earn cash >> > > http://www.techsay.com/default.php? >> page=join.php&p=sourceforge&CID=DEVDEV >> > > _______________________________________________ >> > > gumstix-users mailing list >> > > gum...@li... >> > > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > >> > > >> > > >> > > >> --------------------------------------------------------------------- >> ---- >> > > Take Surveys. Earn Cash. Influence the Future of IT >> > > Join SourceForge.net's Techsay panel and you'll get the chance >> to share your >> > > opinions on IT & business topics through brief surveys-and >> earn cash >> > > http://www.techsay.com/default.php? >> page=join.php&p=sourceforge&CID=DEVDEV >> > > _______________________________________________ >> > > gumstix-users mailing list >> > > gum...@li... >> > > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > >> > > >> > >> >> >> <gumstix.c> > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV________________________________ > _______________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |