From: Chris D. <chr...@gm...> - 2007-02-26 23:17:13
|
Its the Alps LFH8P4032B. The datasheet is located here http://hubbard.engr.scu.edu/embedded/lcd/lfh8p4032b/lfh8p4032b.html The configs that I'm passing the driver aren't really documented anywhere... its just the best I've found thru google and some sources outside the mailing list. Chris On 2/26/07, Craig Hughes <cr...@gu...> wrote: > 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 > > > ------------------------------------------------------------------------- > 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 23:20:30
|
Thanks C On Feb 26, 2007, at 3:17 PM, Chris Dollar wrote: > Its the Alps LFH8P4032B. The datasheet is located here > http://hubbard.engr.scu.edu/embedded/lcd/lfh8p4032b/lfh8p4032b.html > > The configs that I'm passing the driver aren't really documented > anywhere... its just the best I've found thru google and some sources > outside the mailing list. > > Chris > > On 2/26/07, Craig Hughes <cr...@gu...> wrote: >> 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 >> >> >> --------------------------------------------------------------------- >> ---- >> 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: Steven A. F. <sa...@op...> - 2007-02-24 13:45:59
|
I am using 2.6.18-rt7gum on my NTP clock. I have made a few mods to the driver, because it had some problems in monochrome mode, and because my display looks better if I have control of the ac-bias frequency. I don't plan to update the software, because the clock is providing time services to my network. However, I have a second gumstix which I can experiment with. Currently no display on that unit. Steve Chris Dollar wrote: > Hi Steve, > > Just curious if you've had a chance to try the framebuffer on the > latest 2.6.20 kernel? I've been using the pxafb stuff since probably > 2.6.13 with no issues till 2.6.20. (I've always compiled it directly > into the kernel as well). > > Chris > > On 2/23/07, Steven A. Falco <sa...@op...> wrote: > >> 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 >> >> >> > > ------------------------------------------------------------------------- > 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: DJ D. <dj...@de...> - 2007-02-15 21:01:22
|
# cat /proc/cpuinfo Processor : XScale-PXA255 rev 6 (v5l) BogoMIPS : 397.31 That's my connex 400. A 200 should give about half the number of bogomips. And for the next questions: # cat /proc/meminfo MemTotal: 63436 kB 64Mb RAM # df Filesystem Size Used Available Use% Mounted on /dev/mtdblock1 15.8M 4.7M 11.0M 30% / 16Mb flash |