Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
On 12/2/2009 1:59 PM, Eino-Ville Talvala wrote: snip Thanks for all the suggestions, but nothing seems to have worked so far. It looks like X picks up all sorts of configuration settings automatically, since xorg.conf is essentially full of 'default internal device' options. What I can't figure out is how it decides on the requested resolution. The defaults, with omapfb.rotate=1 in bootargs, result in omapfb selecting a virtual resolution of 640x480, but Xorg on boot still tries, based on dmesg, to get a 480x640 overlay somehow (at least that's what my interpretation of the situation is). I've tried adding a screen subsection to xorg.confg, with virtual 640 480 - no effect. I've tried adding in a modeline for 640x480, no effect. I tried rebuilding Angstrom with a few extra lines in /conf/machine/omap3evm.conf (MACHINE_DISPLAY_WIDTH_PIXELS=640, etc), with no effect. Does anyone know exactly how Xorg autoconfigures the default panel in this sort of a situation? My current guess is that it's getting 480x640 from some panel driver somewhere, but I haven't been able to find the source. For compleness, I've attached the Xorg log, xorg.conf, and the kernel log when I try to boot up Xorg (just Xorg, no gpe anything). check the settings for fb0, fb1 and fb2 with fbset. regards, Koen r...@omap3evm:~# fbset -fb /dev/fb0 mode 640x480-59 # D: 19.200 MHz, H: 28.614 kHz, V: 59.243 Hz geometry 640 480 640 480 16 timings 52083 1 28 1 1 2 1 accel false rgba 5/11,6/5,5/0,0/0 endmode r...@omap3evm:~# fbset -fb /dev/fb1 mode 640x480-59 # D: 19.200 MHz, H: 28.614 kHz, V: 59.243 Hz geometry 640 480 640 480 16 timings 52083 1 28 1 1 2 1 accel false rgba 5/11,6/5,5/0,0/0 endmode r...@omap3evm:~# fbset -fb /dev/fb2 mode 0x0-0 # D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz geometry 0 0 0 0 0 timings 0 0 0 0 0 0 0 accel false rgba 0/0,0/0,0/0,0/0 endmode FB2 is suspicious, since that's what Xorg uses, I believe. Attempting to set it to something like fb0 and fb1 with: fbset -fb /dev/fb2 -g 640 480 640 480 16 -t 52083 1 28 1 1 2 1 made no difference to Xorg, however. I tried upping the amount of memory allocated to fb2 (I'd forgotten to give it any on the bootargs), with no luck. So fb0 and fb1 are getting defaults from somewhere, but fb2 isn't. Bootargs currently: mem=128M console=ttyS0,115200n8 noinitrd rw root=/dev/mmcblk0p2 rootfstype=ext2 rootwait omapfb.rotate=1 omapfb.vrfb=y omapfb.debug=y omapdss.debug=y vram=32M omapfb.vram=0:8M,1:8M,2:8M Thanks for the suggestion! Just in case it would be of use to others later, I did finally find a resolution to this problem. The short story is that the current xf86-video-omafb driver can't handle VRFB rotation, even if it's defined on the kernel command line, because the driver assumes that the output framebuffer is contiguous, which is very much not true with VRFB. There's also a problem with the order in which it reads and writes framebuffer parameters, because with the omapfb driver, the frame buffer fixed info will have to be reread after changing rotation settings or pixel type, as the stride can change. I've hacked up enough of the xf86-video-omapfb driver to get X running in the proper orientation with VRFB and rotation defined on the kernel command line, on the OMAP3 EVM (so X runs at 640x480 on the built-in 480x640 LCD). I haven't gotten the XV extension part of the driver working right yet. If anyone wants the ugly results, I'm happy to share, but I doubt I'll have time to clean them up anytime soon. Thanks, Eino-Ville Talvala Computer Graphics Lab Stanford University -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM CROSS COMPILATION
On 12/17/2009 10:20 PM, Niamathullah sharief wrote: Hello, I am trying to compile my kernel for ARM Processor. when i do that i am getting some following error. I didnt find what will be the problem. Hi, r...@ariem-desktop:/home/ariem/Desktop/kernels/linux-2.6.28-006rc8# make CROSS_COMPILE=/home/ariem/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi- uImage CHK include/linux/version.h make[1]: `include/asm-arm/mach-types.h' is up to date. CHK include/linux/utsrelease.h SYMLINK include/asm - include/asm-arm CALLscripts/checksyscalls.sh stdin:1097:2: warning: #warning syscall fadvise64 not implemented stdin:1265:2: warning: #warning syscall migrate_pages not implemented stdin:1321:2: warning: #warning syscall pselect6 not implemented stdin:1325:2: warning: #warning syscall ppoll not implemented stdin:1365:2: warning: #warning syscall epoll_pwait not implemented CC init/main.o /tmp/cczCT0T5.s: Assembler messages: /tmp/cczCT0T5.s:255: Error: selected processor does not support `cpsie i' /tmp/cczCT0T5.s:704: Error: selected processor does not support `cpsid i' /tmp/cczCT0T5.s:712: Error: selected processor does not support `cpsid i' /tmp/cczCT0T5.s:726: Error: selected processor does not support `cpsid i' /tmp/cczCT0T5.s:740: Error: selected processor does not support `cpsid i' /tmp/cczCT0T5.s:812: Error: selected processor does not support `cpsid i' /tmp/cczCT0T5.s:837: Error: selected processor does not support `cpsie i' make[1]: *** [init/main.o] Error 1 make: *** [init] Error 2 r...@ariem-desktop:/home/ariem/Desktop/kernels/linux-2.6.28-006rc8# Kindly help me -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Unless you're using an OMAP-based ARM processor, this is probably not the right list to be asking this. You're also not giving sufficient information for anyone to help you much - what processor and what hardware platform are you compiling for? In any case, have you run the proper defconfig for your board - see, for example, the discussion below: http://linux.omap.com/pipermail/linux-omap-open-source/2007-August/010792.html Good luck! Eino-Ville Talvala Computer Graphics Lab Stanford University -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
snip The xorg boot log appears reasonably sane until a crash - 640x480 is what the xf86 omapfb driver picks up, so I assume something else is the problem. I'll try to poke at the omapfb source some to see if something is being passed around wrong - I'd appreciate any suggestions on where to look. === ... (II) LoadModule: omapfb (II) Loading /usr/lib/xorg/modules/drivers//omapfb_drv.so (II) Module omapfb: vendor=X.Org Foundation compiled for 1.6.1, module version = 0.1.1 ABI class: X.Org Video Driver, version 5.0 (II) omapfb: Driver for OMAP framebuffer (omapfb) and external LCD controllers: omap1/2/3, S1D13745, HWA742 (WW) Falling back to old probe method for OMAPFB (II) Running in FRAMEBUFFER Mode (WW) Error opening /sys/devices/platform/omapfb/ctrl/name: No such file or direc tory (WW) Can't autodetect LCD controller, assuming internal (II) LCD controller: internal (II) omapfb(0): VideoRAM: 1920KiB (SDRAM) (--) omapfb(0): Depth 16, (==) framebuffer bpp 16 (==) omapfb(0): RGB weight 565 (==) omapfb(0): Default visual is TrueColor (--) omapfb(0): Virtual size is 640x480 (pitch 640) (**) omapfb(0): Built-in mode current (==) omapfb(0): DPI set to (96, 96) (II) Loading sub module fb (II) LoadModule: fb (II) Loading /usr/lib/xorg/modules//libfb.so (II) Module fb: vendor=X.Org Foundation compiled for 1.6.1, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) omapfb(0): DPMS enabled (II) omapfb(0): Video plane capabilities: (II) omapfb(0): Video plane supports the following image formats: (II) omapfb(0): XVideo extension initialized (==) RandR enabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE Backtrace: 0: Xorg(xorg_backtrace+0x28) [0xd2540] Fatal server error: Caught signal 11. Server aborting === Does your xorg.conf enable GLX? You may want to try disabling it. ~sanjeev Thanks for all the suggestions, but nothing seems to have worked so far. It looks like X picks up all sorts of configuration settings automatically, since xorg.conf is essentially full of 'default internal device' options. What I can't figure out is how it decides on the requested resolution. The defaults, with omapfb.rotate=1 in bootargs, result in omapfb selecting a virtual resolution of 640x480, but Xorg on boot still tries, based on dmesg, to get a 480x640 overlay somehow (at least that's what my interpretation of the situation is). I've tried adding a screen subsection to xorg.confg, with virtual 640 480 - no effect. I've tried adding in a modeline for 640x480, no effect. I tried rebuilding Angstrom with a few extra lines in /conf/machine/omap3evm.conf (MACHINE_DISPLAY_WIDTH_PIXELS=640, etc), with no effect. Does anyone know exactly how Xorg autoconfigures the default panel in this sort of a situation? My current guess is that it's getting 480x640 from some panel driver somewhere, but I haven't been able to find the source. For compleness, I've attached the Xorg log, xorg.conf, and the kernel log when I try to boot up Xorg (just Xorg, no gpe anything). Thanks, Eino-Ville Talvala Stanford University dmesg: omapdss OVERLAY: check_overlay 0: (0,0 480x640 - 640x480) disp (480x640) omapdss MANAGER: omap_dss_mgr_apply(lcd) omapdss OVERLAY: check_overlay 0: (0,0 480x640 - 640x480) disp (480x640) omapdss MANAGER: configure_overlay(0) omapdss DISPC: dispc_setup_plane 0, pa 7100, sw 2048, 0,0, 480x640 - 640x48 0, ilace 0, cmode 40, rot 1, mir 0 omapdss MANAGER error: dispc_setup_plane failed for ovl 0 omapdss DISPC: dispc_enable_plane 0, 0 omapdss MANAGER error: configure_overlay 0 failed omapdss DISPC: GO LCD omapdss MANAGER: omap_dss_mgr_apply(lcd) _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/omap3evm:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 (WW) Failed to open protocol names file /usr/lib/xorg/protocol.txt X.Org X Server 1.6.1 Release Date: 2009-4-14 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.24-24-generic i686 Current Operating System: Linux omap3evm 2.6.32-rc7-07318-g8979e82 #320 Wed Nov 25 15:02:04 PST 2009 armv7l Build Date: 02 December 2009 02:23:08AM Before reporting problems, check http
Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
On 12/2/2009 12:52 PM, Koen Kooi wrote: Op 2 dec 2009, om 21:02 heeft Eino-Ville Talvala het volgende geschreven: snip The xorg boot log appears reasonably sane until a crash - 640x480 is what the xf86 omapfb driver picks up, so I assume something else is the problem. I'll try to poke at the omapfb source some to see if something is being passed around wrong - I'd appreciate any suggestions on where to look. === ... (II) LoadModule: omapfb (II) Loading /usr/lib/xorg/modules/drivers//omapfb_drv.so (II) Module omapfb: vendor=X.Org Foundation compiled for 1.6.1, module version = 0.1.1 ABI class: X.Org Video Driver, version 5.0 (II) omapfb: Driver for OMAP framebuffer (omapfb) and external LCD controllers: omap1/2/3, S1D13745, HWA742 (WW) Falling back to old probe method for OMAPFB (II) Running in FRAMEBUFFER Mode (WW) Error opening /sys/devices/platform/omapfb/ctrl/name: No such file or direc tory (WW) Can't autodetect LCD controller, assuming internal (II) LCD controller: internal (II) omapfb(0): VideoRAM: 1920KiB (SDRAM) (--) omapfb(0): Depth 16, (==) framebuffer bpp 16 (==) omapfb(0): RGB weight 565 (==) omapfb(0): Default visual is TrueColor (--) omapfb(0): Virtual size is 640x480 (pitch 640) (**) omapfb(0): Built-in mode current (==) omapfb(0): DPI set to (96, 96) (II) Loading sub module fb (II) LoadModule: fb (II) Loading /usr/lib/xorg/modules//libfb.so (II) Module fb: vendor=X.Org Foundation compiled for 1.6.1, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) omapfb(0): DPMS enabled (II) omapfb(0): Video plane capabilities: (II) omapfb(0): Video plane supports the following image formats: (II) omapfb(0): XVideo extension initialized (==) RandR enabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE Backtrace: 0: Xorg(xorg_backtrace+0x28) [0xd2540] Fatal server error: Caught signal 11. Server aborting === Does your xorg.conf enable GLX? You may want to try disabling it. ~sanjeev Thanks for all the suggestions, but nothing seems to have worked so far. It looks like X picks up all sorts of configuration settings automatically, since xorg.conf is essentially full of 'default internal device' options. What I can't figure out is how it decides on the requested resolution. The defaults, with omapfb.rotate=1 in bootargs, result in omapfb selecting a virtual resolution of 640x480, but Xorg on boot still tries, based on dmesg, to get a 480x640 overlay somehow (at least that's what my interpretation of the situation is). I've tried adding a screen subsection to xorg.confg, with virtual 640 480 - no effect. I've tried adding in a modeline for 640x480, no effect. I tried rebuilding Angstrom with a few extra lines in /conf/machine/omap3evm.conf (MACHINE_DISPLAY_WIDTH_PIXELS=640, etc), with no effect. Does anyone know exactly how Xorg autoconfigures the default panel in this sort of a situation? My current guess is that it's getting 480x640 from some panel driver somewhere, but I haven't been able to find the source. For compleness, I've attached the Xorg log, xorg.conf, and the kernel log when I try to boot up Xorg (just Xorg, no gpe anything). check the settings for fb0, fb1 and fb2 with fbset. regards, Koen r...@omap3evm:~# fbset -fb /dev/fb0 mode 640x480-59 # D: 19.200 MHz, H: 28.614 kHz, V: 59.243 Hz geometry 640 480 640 480 16 timings 52083 1 28 1 1 2 1 accel false rgba 5/11,6/5,5/0,0/0 endmode r...@omap3evm:~# fbset -fb /dev/fb1 mode 640x480-59 # D: 19.200 MHz, H: 28.614 kHz, V: 59.243 Hz geometry 640 480 640 480 16 timings 52083 1 28 1 1 2 1 accel false rgba 5/11,6/5,5/0,0/0 endmode r...@omap3evm:~# fbset -fb /dev/fb2 mode 0x0-0 # D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz geometry 0 0 0 0 0 timings 0 0 0 0 0 0 0 accel false rgba 0/0,0/0,0/0,0/0 endmode FB2 is suspicious, since that's what Xorg uses, I believe. Attempting to set it to something like fb0 and fb1 with: fbset -fb /dev/fb2 -g 640 480 640 480 16 -t 52083 1 28 1 1 2 1 made no difference to Xorg, however. I tried upping the amount of memory allocated to fb2 (I'd forgotten
Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
On 11/29/2009 9:47 PM, Hiremath, Vaibhav wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tomi Valkeinen Sent: Thursday, November 26, 2009 7:50 PM To: ext Eino-Ville Talvala Cc: linux-omap@vger.kernel.org Subject: Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation Hi, On Wed, 2009-11-25 at 01:14 +0100, ext Eino-Ville Talvala wrote: Hi, I'm trying to get Xorg running on an Angstrom distro image on the OMAP3 EVM, with a rotated framebuffer. The default screen orientation on the EVM is portrait, and I'm trying to change this to landscape. Without any tweaking, using a kernel with your latest v5 DSS patches added on top (and Vaibhav's OMAP3 EVM DSS patches), DSS works and Angstrom happily displays both its initial bootup screen, and then the X server starts successfully. Using the omapfb.rotate=1 kernel command-line option, the initial bootup screen still works, but as soon as the X server tries to start up, I get the following error on the console: Starting GPE display manager: gpe-dm omapdss MANAGER error: dispc_setup_plane failed for ovl 0 omapdss MANAGER error: configure_overlay 0 failed It sounds to me that gpe-dm (or something running after that) is trying to configure the overlay to 480x640 mode, and failing. If the initial [Hiremath, Vaibhav] I think this is the issue, I have seen many peoples doing same mistakes, and it ends up to the application, which doesn't care about rotation and tries to set 480x640 in all rotation angles. The xorg boot log appears reasonably sane until a crash - 640x480 is what the xf86 omapfb driver picks up, so I assume something else is the problem. I'll try to poke at the omapfb source some to see if something is being passed around wrong - I'd appreciate any suggestions on where to look. === ... (II) LoadModule: omapfb (II) Loading /usr/lib/xorg/modules/drivers//omapfb_drv.so (II) Module omapfb: vendor=X.Org Foundation compiled for 1.6.1, module version = 0.1.1 ABI class: X.Org Video Driver, version 5.0 (II) omapfb: Driver for OMAP framebuffer (omapfb) and external LCD controllers: omap1/2/3, S1D13745, HWA742 (WW) Falling back to old probe method for OMAPFB (II) Running in FRAMEBUFFER Mode (WW) Error opening /sys/devices/platform/omapfb/ctrl/name: No such file or direc tory (WW) Can't autodetect LCD controller, assuming internal (II) LCD controller: internal (II) omapfb(0): VideoRAM: 1920KiB (SDRAM) (--) omapfb(0): Depth 16, (==) framebuffer bpp 16 (==) omapfb(0): RGB weight 565 (==) omapfb(0): Default visual is TrueColor (--) omapfb(0): Virtual size is 640x480 (pitch 640) (**) omapfb(0): Built-in mode current (==) omapfb(0): DPI set to (96, 96) (II) Loading sub module fb (II) LoadModule: fb (II) Loading /usr/lib/xorg/modules//libfb.so (II) Module fb: vendor=X.Org Foundation compiled for 1.6.1, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) omapfb(0): DPMS enabled (II) omapfb(0): Video plane capabilities: (II) omapfb(0): Video plane supports the following image formats: (II) omapfb(0): XVideo extension initialized (==) RandR enabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE Backtrace: 0: Xorg(xorg_backtrace+0x28) [0xd2540] Fatal server error: Caught signal 11. Server aborting === Thanks, Eino-Ville Talvala Stanford University -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FYI - Frankencamera is open source, runs on Linux
Have you seen this post on N95 camera using linux by Stanford Team - http://news.cnet.com/8301-17938_105-10345557-1.html Is this running on OMAP?-- The board in the youtube video looks a lot like the omap3evm, so I guess it's safe to say it's omap3 based. regards, Koen I'm one of the graduate students at Stanford working on this project. Yes, we're using an OMAP3 EVM (needed the camera interface pins) connected to a small custom daughtercard that interfaces to an Elphel 10338 camera tile, with an Aptina MT9P031 on it. Plus a bunch of other off-the-shelf hardware, but the OMAP3 is at the heart of it. Eino-Ville (Eddy) Talvala Graduate Research Assistant Stanford University -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems configuring OMAP35x ISP driver
Zach, We've gotten a Aptina MT9P031 driver working with the latest ISP patchset, both with YUV and RAW data. I don't know what the problem might be with YUYV data - we get useful YUYV data without any changes to the ISP defaults. However, to request RAW data, that simply uses the CCDC and bypasses all the processing in the ISP, request the pixelformat of V4L2_PIX_FMT_SGRBG10. This will give you two bytes per pixel, at least in our case (although we have a 12-bit sensor cut down to 10 bits), so be prepared to throw out every other byte. Hope this helps, Eino-Ville (Eddy) Talvala Computer Graphics Lab Stanford University On 7/14/2009 9:49 AM, Zach LeRoy wrote: Hello Sergio, I spoke with you earlier about using the ISP and omap34xxcam drivers with a micron mt9d111 SOC sensor. I have since been able to take pictures, but the sensor data is not making it through the ISP data-path correctly. I know the problem is in the ISP data-path because I am configuring the sensor the exact same way as I have been on my working PXA system. I am expecting 4:2:2 packed YUV data, but all of the U and V data is no more than 2 bits where it should be 8. I know the ISP has a lot of capabilities, but all I want to use it for is grabbing 8-bit data from my sensor and putting it in a buffer untouched using the CCDC interface (and of course clocking and timing). What are the key steps to take to get this type of configuration? Other Questions: Is there any processing done on YUV data in the ISP driver by default that I am missing? Has any one else experienced similar problems while adding new sensor support? Any help here would be greatly appreciated. Thank you, Zach LeRoy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
bitsperlong.h missing in asm-arm?
Hi, I'm not at all familiar with the way the asm-* include directories are handled, but with the current linux-omap tree, I'm getting a user-space compilation error with the CodeSourcery 2009q1 release: In file included from /CodeSourcery/arm-gcc-2009q1/bin/../arm-none-linux-gnueabi/libc/usr/include/asm/types.h: linux-omap-2.6/include/asm-generic/int-ll64.h:11:29: error: asm/bitsperlong.h: No such file or directory It doesn't look like just a CodeSourcery issue, since the missing reference is actually in asm-generic/int-ll64.h. Am I doing something incorrect, or is something missing in include/asm-arm ? Thanks, Eddy Talvala Computer Graphics Lab Stanford University -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
