Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
(114) |
Apr
(35) |
May
(60) |
Jun
(52) |
Jul
(121) |
Aug
(170) |
Sep
(343) |
Oct
(147) |
Nov
(185) |
Dec
(172) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(319) |
Feb
(505) |
Mar
(614) |
Apr
(358) |
May
(344) |
Jun
(306) |
Jul
(558) |
Aug
(506) |
Sep
(639) |
Oct
(863) |
Nov
(705) |
Dec
(562) |
2006 |
Jan
(828) |
Feb
(1229) |
Mar
(1099) |
Apr
(856) |
May
(1099) |
Jun
(943) |
Jul
(1109) |
Aug
(975) |
Sep
(928) |
Oct
(1174) |
Nov
(1120) |
Dec
(948) |
2007 |
Jan
(858) |
Feb
(1095) |
Mar
(1143) |
Apr
(1178) |
May
(1255) |
Jun
(1092) |
Jul
(1373) |
Aug
(904) |
Sep
(848) |
Oct
(1552) |
Nov
(823) |
Dec
(973) |
2008 |
Jan
(1303) |
Feb
(1093) |
Mar
(1173) |
Apr
(1258) |
May
(664) |
Jun
(461) |
Jul
(613) |
Aug
(452) |
Sep
(387) |
Oct
(411) |
Nov
(466) |
Dec
(608) |
2009 |
Jan
(529) |
Feb
(452) |
Mar
(482) |
Apr
(679) |
May
(545) |
Jun
(588) |
Jul
(519) |
Aug
(675) |
Sep
(441) |
Oct
(556) |
Nov
(472) |
Dec
(471) |
2010 |
Jan
(799) |
Feb
(622) |
Mar
(659) |
Apr
(479) |
May
(631) |
Jun
(698) |
Jul
(802) |
Aug
(666) |
Sep
(533) |
Oct
(797) |
Nov
(459) |
Dec
(486) |
2011 |
Jan
(792) |
Feb
(526) |
Mar
(748) |
Apr
(506) |
May
(477) |
Jun
(528) |
Jul
(642) |
Aug
(418) |
Sep
(494) |
Oct
(374) |
Nov
(355) |
Dec
(424) |
2012 |
Jan
(476) |
Feb
(491) |
Mar
(606) |
Apr
(462) |
May
(275) |
Jun
(278) |
Jul
(241) |
Aug
(205) |
Sep
(215) |
Oct
(296) |
Nov
(317) |
Dec
(108) |
2013 |
Jan
(317) |
Feb
(228) |
Mar
(157) |
Apr
(108) |
May
(120) |
Jun
(123) |
Jul
(136) |
Aug
(204) |
Sep
(169) |
Oct
(152) |
Nov
(103) |
Dec
(164) |
2014 |
Jan
(153) |
Feb
(190) |
Mar
(147) |
Apr
(51) |
May
(131) |
Jun
(70) |
Jul
(99) |
Aug
(49) |
Sep
(28) |
Oct
(37) |
Nov
(43) |
Dec
(50) |
2015 |
Jan
(53) |
Feb
(48) |
Mar
(49) |
Apr
(83) |
May
(44) |
Jun
(163) |
Jul
(58) |
Aug
(39) |
Sep
(105) |
Oct
(73) |
Nov
(57) |
Dec
(82) |
2016 |
Jan
(64) |
Feb
(60) |
Mar
(37) |
Apr
(42) |
May
(113) |
Jun
(51) |
Jul
(56) |
Aug
(37) |
Sep
(26) |
Oct
(40) |
Nov
(28) |
Dec
(19) |
2017 |
Jan
(27) |
Feb
(28) |
Mar
(27) |
Apr
(31) |
May
(8) |
Jun
(10) |
Jul
(23) |
Aug
(5) |
Sep
(7) |
Oct
(31) |
Nov
(3) |
Dec
(1) |
2018 |
Jan
(1) |
Feb
(9) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
1
(9) |
2
(22) |
3
(20) |
4
(12) |
5
(21) |
6
(14) |
7
(2) |
8
(4) |
9
(9) |
10
(36) |
11
(48) |
12
(43) |
13
(17) |
14
(9) |
15
(5) |
16
(32) |
17
(24) |
18
(21) |
19
(48) |
20
(19) |
21
(11) |
22
(10) |
23
(27) |
24
(21) |
25
(19) |
26
(33) |
27
(39) |
28
(19) |
29
(23) |
30
(27) |
31
(22) |
|
|
|
|
From: Erik Rodriguez <erodriguez@gr...> - 2010-08-27 23:40:35
|
From: J. L. <vwyodapink@gm...> - 2010-08-27 23:31:47
|
From: Erik Rodriguez <erodriguez@gr...> - 2010-08-27 22:35:31
|
From: RussellMorin <russmorin@gm...> - 2010-08-27 22:13:12
|
Hello, I am having trouble gettin i2c-io working with my Robostix. I'm using the precompiled bootloader .hex from Dave Hylands' website because the one which built with my "bitbake robostix" gives the following error: root@...:/$ i2c-load --reset 0x0b write i2c-io.hex ERROR: BootLoader device is too new; Host is (1-1) Device is (255-255) Here's the error I encounter with the precompiled bootloader: root@...:/$ uisp --erase --upload if=i2c-Boot-m128-16MHz.hex Atmel AVR ATmega128 is found. Erasing device ... Reinitializing device Atmel AVR ATmega128 is found. Uploading: flash root@...:/$ i2c-load --reset 0x0b write i2c-io.hex Detected ATMega128 Write: ## Verify: ## Verify sucessful Write sucessful, rebooting... root@...:/$ i2c-io 0x0b info i2c: error: exhausted retries i2c: msg_num: 0 msg_idx: -2000 msg_ptr: 0 i2c: ICR: 000007e0 ISR: 00000002 i2c: log: [00000446:000007e0] ERROR: I2cTransfer: ioctl failed: Remote I/O error (121) ERROR: I2cReadBlock failed ERROR: Unable to retrieve information from i2c address 0x0b Any ideas? Thanks, -Russell Morin Dave Hylands wrote: > > Hi Rob, > >> I am having trouble with i2c between the gumstix connex400xm and robostix >> I have a sandwich of three boards - gumstix, robostix, and netMMC. > >> However when I load i2c-io on robostix I garbage out (as if wrong baud >> rate - I'm still using 38400), and no LED activity except power LED. > > Did you load the i2c-bootloader? Currently, i2c-io expects to use some > of the code found in the bootloader. > > The correct procedure would be to load the bootloader using uisp, and > then use i2c-load to download i2c-io.hex. > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > gumstix-users mailing list > gumstix-users@... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/i2c-io-errors-tp11653076p29557247.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Kai Howells <kai@au...> - 2010-08-27 21:52:58
|
Setting the correct CHS values is absolutely critical when you're booting from the ROM on the overo - ie, you don't have a working MLO in nand. If you do, then it's a bit more forgiving. Set the CHS values, as calculated in the howto, but when entering the partition size, make it, say, 40MB: Last cylinder or +size or +sizeM or +sizeK (1-247, default 15): +40M That should sort you out. I'm not sure why the new kernel is so large however, the stock MLO is 20k, the u-boot.bin is 189k and the uImage is 3.1M (3160128 bytes) Are you sure you're reading the figures correctly - that the sizes are in kB not in bytes... If so, the "out of space" error is something else. On 28/08/2010, at 3:39 AM, Hugo Grimmett wrote: > Hi there, > > I've just rebaked a new kernel image, which I was hoping to use to > replace the existing uImage.bin file on the SD card. Unfortunately when > I try and copy it across, I get a "device has run out of space" error. > The sizes are as such: > uImage-old.bin - 3154816kB > uImage-new.bin - 3160076kB > > It seems that I just need to make the FAT32 partition on the SD card > slighly larger in order to accommodate the new uImage file, but the > number of cylinders/heads/sectors were so carefully calculated that I'm > afraid I'll break something if I just try and make it 1MB bigger... Can > someone tell me what numbers I should change by using fdisk with respect > to this page? > http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html > > Many thanks, > > Hugo > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > gumstix-users mailing list > gumstix-users@... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Søren Steen Christensen <lists@ss...> - 2010-08-27 21:11:44
|
> thanks soren :) Would you also know the correct way to change the > i2c_bus? I see everyone says to to i2c_bus=3,100 but when I run that > in uboot it doesnt seem to work as it still runs at 400? Doesn't it work adding this to bootargs? It has been a while since I last time tried, but at that time I think it worked... - I do unfortunately not have a setup just in front of me right now, so I can't give it a try :-(... Remember that dependent on you U-boot version/setup bootargs might be changed dependent on mmc- or nand-boot. The actual string passed to the Linux kernel can be checked by "cat /proc/cmdline" in the Linux console Best regards - Good luck Søren --- SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk |
From: J. L. <vwyodapink@gm...> - 2010-08-27 21:00:39
|
From: J. L. <vwyodapink@gm...> - 2010-08-27 20:59:15
|
thanks soren :) Would you also know the correct way to change the i2c_bus? I see everyone says to to i2c_bus=3,100 but when I run that in uboot it doesnt seem to work as it still runs at 400? On Fri, Aug 27, 2010 at 1:52 PM, Søren Steen Christensen <lists@...> wrote: > Just add "mpurate=720" to your bootargs variable... > > Alternatively you can use the cpufreq tools in Linux > Søren > > --- > SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > gumstix-users mailing list > gumstix-users@... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Søren Steen Christensen <lists@ss...> - 2010-08-27 20:52:39
|
Just add "mpurate=720" to your bootargs variable... Alternatively you can use the cpufreq tools in Linux Søren --- SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk |
From: Erik Rodriguez <erodriguez@gr...> - 2010-08-27 20:49:01
|
From: AJ ONeal <coolaj86@gm...> - 2010-08-27 20:45:36
|
Could you give more info or a resource as to how to set the DSP and ARM clock rate in u-boot please? AJ ONeal |
From: Søren Steen Christensen <lists@ss...> - 2010-08-27 20:43:41
|
> so taking it to the 600 or 720 its suppose to handle would shorten the > life of the overo? Is that correct? YES > I read a thread that Don Anderson > wrote a reply that says they are shipped 600 but why would mine show > 500 regardless? I don't recall this thread - As indicated in my previous post I think you can easily fix this by setting mpurate in U-boot > Frustrating trying to sort out one problem and come across 50 more > each time, wish things were more clearly documented by gumstix on > things like this and others. :P Thanks for the info though OMAP and OMAP-linux is still pretty new to the public and a lot of stuff have to be fixed/cleaned up. It's however getting better and better day after day I think Søren :-) --- SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk |
From: J. L. <vwyodapink@gm...> - 2010-08-27 20:38:37
|
From: Erik Rodriguez <erodriguez@gr...> - 2010-08-27 20:34:37
|
From: AJ ONeal <coolaj86@gm...> - 2010-08-27 20:32:00
|
I'd like to create a rootfs which is read only (with some data written to SD and some written to tmpfs). Is there any documentation for this? AJ ONeal |
From: Søren Steen Christensen <lists@ss...> - 2010-08-27 20:21:06
|
Whoops - A bit too fast - Fire and Water are actually shipped with the 720MHz OMAP3 version - Sorry I didn't catch this prior to now. All chips are however currently just configured for 500MHz and the user need to change it if wanted (i.e. by setting mpurate to 720 in the U-boot environment)... The same story about overdrive is however still valid... From the latest datasheet (OPP5 and 6 are now considered overdrive modes - It's unfortunately not 100% clear to me if OPP5 is considered an overdrive mode for the 720MHz version - or only for the 600MHz version ... :-) ------------------------------------------------------------------------- To avoid significant device degradation for commercial temperature OMAP3530/OMAP3525 devices (0°C < Tj < 90°C), the device power-on hours (POH) must be limited to one of the following: * 100K total POH when operating across all OPPs and keeping the time spent at OPP5-OPP6 to less than 23K POH. * 50K total POH when operating at OPP5 - OPP6. * 44K total POH with no restrictions to the proportion of these POH at operating points OPP1 - OPP6. To avoid significant device degradation for extended temperature OMAP3530A/OMAP3525A devices ------------------------------------------------------------------------- Best regards Søren --- SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk |
From: J. L. <vwyodapink@gm...> - 2010-08-27 20:20:10
|
so taking it to the 600 or 720 its suppose to handle would shorten the life of the overo? Is that correct? I read a thread that Don Anderson wrote a reply that says they are shipped 600 but why would mine show 500 regardless? Frustrating trying to sort out one problem and come across 50 more each time, wish things were more clearly documented by gumstix on things like this and others. :P Thanks for the info though On Fri, Aug 27, 2010 at 1:06 PM, Søren Steen Christensen <lists@...> wrote: > Overo's are pr default shipped with the 600Mhz OMAP3 version. BeagleBoards > are shipped with the 720MHz (or 1GHz for Beagle XM :-) > The 600MHz mode is however considered an overdrive mode, which might shorten > the devices lifetime (see the datasheet - omap3530.pdf) > > Taken from the datasheet (OPP5 = 600MHz overdrive mode): > -------------------------------------------------------- > To avoid significant device degradation for commercial temperature > OMAP3530/OMAP3525 devices > (0°C < Tj < 90°C), the device power-on hours (POH) must be limited to one of > the following: > * 100K total POH when operating across all OPPs and keeping the time spent > at OPP5 to less than 23K POH. > * 50K total POH when operating exclusively at OPP5. > * 44K total POH with no restrictions to the proportion of these POH at > operating points OPP1 - OPP5. > -------------------------------------------------------- > > I hope this clarified why it's pr. Default configured to 500MHz? - Best > regards > Søren > > --- > SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk > > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > gumstix-users mailing list > gumstix-users@... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Søren Steen Christensen <lists@ss...> - 2010-08-27 20:06:52
|
Overo's are pr default shipped with the 600Mhz OMAP3 version. BeagleBoards are shipped with the 720MHz (or 1GHz for Beagle XM :-) The 600MHz mode is however considered an overdrive mode, which might shorten the devices lifetime (see the datasheet - omap3530.pdf) Taken from the datasheet (OPP5 = 600MHz overdrive mode): -------------------------------------------------------- To avoid significant device degradation for commercial temperature OMAP3530/OMAP3525 devices (0°C < Tj < 90°C), the device power-on hours (POH) must be limited to one of the following: * 100K total POH when operating across all OPPs and keeping the time spent at OPP5 to less than 23K POH. * 50K total POH when operating exclusively at OPP5. * 44K total POH with no restrictions to the proportion of these POH at operating points OPP1 - OPP5. -------------------------------------------------------- I hope this clarified why it's pr. Default configured to 500MHz? - Best regards Søren --- SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk |
From: J. L. <vwyodapink@gm...> - 2010-08-27 19:48:55
|
I thought the overo fire was suppose to have 700mhz? doing a cat /proc/cpuinfo shows me having a BogoMIPS of 499.92? I have changed nothing relating to this why does mine show its running at 500mHz? Is there a way to clock it to the 700? or ? Kinda lost on the info on this one. The only reason I came across this was because I was trying to find out what was eating my memory and decided to see what that would give me. Thanks for any info on this one. |
From: vwyodapink <vwyodapink@gm...> - 2010-08-27 19:17:52
|
The error says its looking on the host machine and I have been trying to use devshell and learn it at the same time to fix this and I am not having any luck with the minimal directions around to mess with the devshell. I think I am close to where I need to be to find the mess up in the compile but not sure. Is there anyone else having this issue and if so if you can give some pointers in how to make it build properly I would happily continue trying so I can learn the patch proccess better but I can not continue on with my build until this is configured and building properly. Thanks for any help. Also I have tried cleaning and rebuilding and re pulling the source files again and still nothing for apr-util always fails the same way. I also re did apr as well incase that was part of the cause and it builds fine. Error is below: NOTE: Running task 816 of 833 (ID: 24, /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb, do_fetch) NOTE: fetch http://archive.apache.org/dist/apr/apr-util-1.3.4.tar.gz --2010-08-27 12:00:02-- http://archive.apache.org/dist/apr/apr-util-1.3.4.tar.gz Resolving archive.apache.org... 140.211.11.131 Connecting to archive.apache.org|140.211.11.131|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 778902 (761K) [application/x-tar] Saving to: `/home/vdubhack/overo-oe/sources/apr-util-1.3.4.tar.gz' 100%[======================================>] 778,902 161K/s in 4.9s 2010-08-27 12:00:10 (156 KB/s) - `/home/vdubhack/overo-oe/sources/apr-util-1.3.4.tar.gz' saved [778902/778902] NOTE: Running task 817 of 833 (ID: 19, /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb, do_unpack) NOTE: Unpacking sources/apr-util-1.3.4.tar.gz to tmp/work/armv7a-angstrom-linux-gnueabi/apr-util-1.3.4-r5/ NOTE: Running task 818 of 833 (ID: 20, /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb, do_patch) NOTE: Applying patch 'configfix.patch' (org.openembedded.dev/recipes/apr/apr-util/configfix.patch) NOTE: Applying patch 'configure_fixes.patch' (org.openembedded.dev/recipes/apr/apr-util/configure_fixes.patch) NOTE: Running task 819 of 833 (ID: 27, /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb, do_configure) NOTE: Running task 820 of 833 (ID: 28, /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb, do_qa_configure) ERROR: This autoconf log indicates errors, it looked at host includes. Rerun configure task after fixing this. The path was '/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/apr-util-1.3.4-r5/apr-util-1.3.4' ERROR: Error in executing: /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb ERROR: Exception:<type 'exceptions.SystemExit'> Message:1 ERROR: Printing the environment of the function ERROR: Build of /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb do_qa_configure failed ERROR: Task 28 (/home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb, do_qa_configure) failed NOTE: Tasks Summary: Attempted 819 tasks of which 795 didn't need to be rerun and 1 failed. ERROR: '/home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb' failed ----- Just a beginner trying to learn his way around. -- View this message in context: http://old.nabble.com/apr-util-fails-to-build%2C-lost-trying-to-fix-tp29555960p29555960.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Søren Steen Christensen <lists@ss...> - 2010-08-27 18:03:55
|
Hi Hugo, Just change the "+32M" in the creation of the FAT32 partition to whatever fits you need (needs to me in the 32MB-4GB range though :-) Keep the other parameters as is... BTW: Are you sure the numbers you gave are correct? uImage-new.bin - 3160076kB would be a kernel with a size of 3160MB? Normally the kernel is around 1-3MB? Hope you can clarify on this? Best regards and thanks - Good luck Søren --- SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk |
From: Cliff Brake <cliff.brake@gm...> - 2010-08-27 18:01:28
|
On Fri, Aug 27, 2010 at 1:39 PM, Hugo Grimmett <hugo@...> wrote: > Hi there, > > I've just rebaked a new kernel image, which I was hoping to use to > replace the existing uImage.bin file on the SD card. Unfortunately when > I try and copy it across, I get a "device has run out of space" error. > The sizes are as such: > uImage-old.bin - 3154816kB > uImage-new.bin - 3160076kB > > It seems that I just need to make the FAT32 partition on the SD card > slighly larger in order to accommodate the new uImage file, but the > number of cylinders/heads/sectors were so carefully calculated that I'm > afraid I'll break something if I just try and make it 1MB bigger... Can > someone tell me what numbers I should change by using fdisk with respect > to this page? > http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html I don't know offhand the answer to your question, but here is a script I typically use: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/contrib/angstrom/omap3-mkcard.sh It might set up partitions in a way that is better for you. Cliff -- ================= http://bec-systems.com |
From: Hugo Grimmett <hugo@ro...> - 2010-08-27 17:39:10
|
Hi there, I've just rebaked a new kernel image, which I was hoping to use to replace the existing uImage.bin file on the SD card. Unfortunately when I try and copy it across, I get a "device has run out of space" error. The sizes are as such: uImage-old.bin - 3154816kB uImage-new.bin - 3160076kB It seems that I just need to make the FAT32 partition on the SD card slighly larger in order to accommodate the new uImage file, but the number of cylinders/heads/sectors were so carefully calculated that I'm afraid I'll break something if I just try and make it 1MB bigger... Can someone tell me what numbers I should change by using fdisk with respect to this page? http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html Many thanks, Hugo |
From: AJ ONeal <coolaj86@gm...> - 2010-08-27 16:08:45
|
I've been working on porting an application from the DM6446 to the OMAP3530 (Overo Fire). On the DaVinci the CCDC was used for for general data acquisition - a straight passthrough of RAW16 (8-data lines with par_bridge, of which we use only 12-bits) which is then acquired in the application space as a v4l2 buffer. However, with the ISP on the OMAP this has been *much* more difficult than originally expected. I've traced up and down through `isp.c`, `ispccdc.c`, `omap34xxcam.c`, `board-omap3beagle-camera.c`, `v4l2_int_device.h`, `videodev2.h`, and others trying my best to create a configuration that simply lets the data through the ISP. My driver is a stripped down version of the `mt9t111` renamed as `fsr172x`, but I keep getting hung up on `isp_wait` and `Ouch!` errors. The deadline for this part of the project is coming up in just a few short days and I would really appreciate the help. Current Patches: http://github.com/fastr/fsr172x/tree/master/patches/ Simple Capture Application: http://github.com/fastr/fidcap Development Blogpost: http://fastr.github.com/articles/dummy-isp-ccdc-driver.html Specifications: - RAW 12-bit capture - 128x16000 resolution (4mb) - 1 fps - Vendor-specific extensions for V4L2 params - format, colorspace, etc - VD/HD can be either master or slave (we can turn signal generation on or off on our sensor) - As little latency as possible The resolution and frame-rate above are convenient, but we can hack some byte mapping if we can get it to work reliably at another resolution / fps. In addition to benefiting our project, the final documentation would be very beneficial for any of the Gumstix Community who wants to tweak the ISP/CCDC with vendor specific extensions. AJ ONeal |
From: Hugo Grimmett <hugo@ro...> - 2010-08-27 16:02:12
|
I have fixed this problem, which originated from my using a terminal-only tty1 which didn't allow menuconfig to open the required window. Hugo On 27/08/2010 15:57, Hugo Grimmett wrote: > Hi J.L., > > None of the commands on that page work for me. > 1. There is no org.openembedded/conf/machine/ folder, > 2. The 2nd command does not reveal a bitbake version > 3. The "bitbake linux-omap3-2.6.34" command returns: > > NOTE: Handling BitBake files: - (8358/8358) [100 %] > NOTE: Parsing finished. 7554 cached, 479 parsed, 325 skipped, 1 masked. > NOTE: Resolving any missing task queue dependencies > NOTE: Preparing runqueue > NOTE: Executing runqueue > NOTE: Running task 359 of 359 (ID: 5, > /home/mrg/code/Gumstix//org.openembedded.dev/recipes/linux/linux-omap3_2.6.34.bb, > do_menuconfig) > ERROR: function do_menuconfig failed > ERROR: log data follows > (/home/mrg/code/Gumstix//tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.34-r88/temp/log.do_menuconfig.31233) > | > /home/mrg/code/Gumstix//tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.34-r88/temp/run.do_menuconfig.31233: > line 1238: gnome-terminal: command not found > NOTE: Task failed: > /home/mrg/code/Gumstix//tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.34-r88/temp/log.do_menuconfig.31233 > ERROR: TaskFailed event exception, aborting > ERROR: Build of > /home/mrg/code/Gumstix//org.openembedded.dev/recipes/linux/linux-omap3_2.6.34.bb > do_menuconfig failed > ERROR: Task 5 > (/home/mrg/code/Gumstix//org.openembedded.dev/recipes/linux/linux-omap3_2.6.34.bb, > do_menuconfig) failed > NOTE: Tasks Summary: Attempted 358 tasks of which 358 didn't need to be > rerun and 1 failed. > ERROR: > '/home/mrg/code/Gumstix//org.openembedded.dev/recipes/linux/linux-omap3_2.6.34.bb' > failed > > So I guess I will just try editing it directly, as you say you have done > (successfully) ? > > Thanks, > > Hugo > > > On 26/08/2010 21:53, J. L. wrote: >> Here is a howto for you to be able to change your kernel. >> >> http://www.gumstix.net/wiki/index.php?title=Kernel_Reconfiguration >> >> Hope that helps, it will give you the new defconfig, though I have >> just edited the file directly before and had it work but I am sure >> that is not a good way to do it. >> >> >> >> On Thu, Aug 26, 2010 at 9:26 AM, Hugo Grimmett<hugo@...> wrote: >>> Dear Thierry, >>> >>> Thanks for your help, I do have a couple of questions: >>> >>> In the defconfig file it says "Automatically generated make config: >>> don't edit". How then do I make sure the touchscreen is disabled? >>> >>> Also, can I just run the patch for the 2.6.32 kernel even though the >>> most up-to-date version is 2.6.34, or does it need to be in the >>> linux/linux-omap3-2.6.34 folder and some values changed? At the moment I >>> have just put it into the linux/linux-omap3-2.6.32 folder as per the >>> instructions in your linked post. >>> >>> Many thanks, >>> >>> Hugo >>> >>> >>> >>> On 24/08/2010 19:22, Thierry Genovese wrote: >>>> Hi Hugo, >>>> >>>> Don't bother with the patch for BeagleBoard. Most of it has been >>>> merged already. To enable spidev: >>>> * it must be enabled in the kernel config: the defconfig file. I >>>> think it is already enabled in the Gumstix defconfig, so nothing to do >>>> here. >>>> * u-boot must be configured with the proper muxing for the SPI pins: >>>> that is already done in the Gumstix u-boot, nothing to do here either >>>> * you need to declare the properties of the SPI link you want: bus, >>>> cs, freq, etc... This is done in a kernel source file called >>>> board-overo.c. I do not think it is done in the latest kernels, so you >>>> will have to create a patch for this file and add it to the kernel >>>> bitbake recipe to patch the file when the kernel is built. >>>> >>>> For example, this post: >>>> http://old.nabble.com/spidev-tp27230456p27241022.html contains a patch >>>> for the 2.6.32 kernel and the modifications to the 2.6.32 kernel >>>> bitbake recipe. I haven't updated to 2.6.33 and 2.6.34 so I do not >>>> have a patch ready to share. The patch for 2.6.32 will likely not >>>> apply to newer kernels, but all it does is add an entry in the spi >>>> info array. There are already entries in the array for the >>>> touchscreens, so it should be easy to find. >>>> >>>> Gotcha: the SPI busses are used by the touchscreen controllers on the >>>> expansion boards that support them, so if you don"t use touchscreens, >>>> I recommend you disable them in the defconfig, to avoid conflicts (in >>>> the 2.6.32 kernel the touchscreens entries were conditionally added to >>>> the spi info array based on the defconfig values, so I just disabled >>>> them). >>>> >>>> Hope this helps. Don't hesitate to ask if you are stuck. >>>> >>>> Regards >>>> >>>> Thierry >>>> >>>> On Tue, Aug 24, 2010 at 1:24 PM, Hugo Grimmett<hugo@...> wrote: >>>>> Dear Ned and Thierry, >>>>> Thanks to the both of you for your replies! >>>>> >>>>> Ned: my situation is exactly that which you describe, whereby I require >>>>> 1-direction data transfer between the ATMEGA (master) and gumstix (slave), >>>>> at a regular 100Hz. However, due to my inexperience in dealing with drivers >>>>> I will try to make do with using the Gumstix as the master. >>>>> >>>>> Thierry: I am trying to follow your instructions in the final post of this >>>>> thread >>>>> (http://old.nabble.com/SPI,-spidev,-et.-al-to24588398.html#a24594755). It >>>>> seems that before the >>>>> "git diff diff --git a/recipes/linux/linux-omap3-2.6.30/overo/defconfig >>>>> b/recipes/linux/linux-omap3-2.6.30/overo/defconfig" >>>>> command, a patch needs to be run. Is that the same one as from the >>>>> beagleboard site you mention? The title of that patch implies it should >>>>> configure the SPI3 bus, not the SPI1 bus I need. Please could I trouble you >>>>> for a brief guide on how to apply the patch? >>>>> Sadly I'm feeling a little lost in the dark here, so any help would be much >>>>> appreciated! >>>>> >>>>> Best regards, >>>>> Hugo >>>>> >>>>> >>>>> On 23/08/2010 17:24, Ned Forrester wrote: >>>>> >>>>> On 08/23/2010 10:55 AM, Hugo Grimmett wrote: >>>>> >>>>> Hi there, >>>>> >>>>> I'm a new gumstix user trying to configure the SPI protocol. The only >>>>> gumstix documentation I can find is the sample code on this page >>>>> (http://docwiki.gumstix.org/Sample_code/C/SPI) which doesn't seem to be >>>>> quite what I need. >>>>> A couple of questions: >>>>> 1. I'm using the 40-pin header on the Tobi expansion board, which has 6 >>>>> GPIO pins prefixed with _SPI1_, to which I have wired an ATMEGA328P. The >>>>> sample code is configured for use of the NSSP pins, of which I can find >>>>> no mention elsewhere. How do I adapt the code to work on the >>>>> SPI-tailored GPIO170-175 pins? >>>>> >>>>> Others will be able to help with the hardware. I only use the PXA >>>>> processors. >>>>> >>>>> 2. I really need to run the Gumstix as the SPI slave, with the >>>>> ATMEGA328P chip as host and initiating data transfers. What do I need to >>>>> change to make this possible? >>>>> >>>>> There is no SPI slave implementation for Linux, and likely never can be, >>>>> for the reasons periodically discussed on the mailing list: >>>>> >>>>> spi-devel-general@... >>>>> >>>>> You can search the list for references to "slave" to read the discussion >>>>> at its home page: >>>>> https://lists.sourceforge.net/lists/listinfo/spi-devel-general >>>>> >>>>> but it is not very searchable. So... >>>>> >>>>> Search Google for this pair of phrases: >>>>> "spi-devel-general" "spi slave" >>>>> >>>>> The basic problem is that an SPI slave device is often required to >>>>> respond to a request within one SPI clock cycle (the master sends the >>>>> register address, and immediately expects to clock out the register >>>>> contents). Linux (and likely every other operating system) is incapable >>>>> of that response time. >>>>> >>>>> However, slave operation is possible in certain circumstances, either >>>>> when the devices involved don't require an immediate response, or when >>>>> the next transfer on the bus can be predicted in advance. An example of >>>>> the latter case is where there is only one master and one slave on the >>>>> bus, and the master always sends data to the slave; thus the slave can >>>>> predict that the next transfer on the bus will require it to receive >>>>> data, and it can always have a buffer ready to be filled. >>>>> >>>>> I have an application that works just that way: a device continuously >>>>> streams data at 11Mbit/s and Linux receives that data. The driver (a >>>>> heavily modified version of pxa2xx_spi.c) maintains a queue of empty >>>>> buffers, and uses DMA descriptors to chain DMA transfers to those >>>>> buffers. Interrupt service is required to maintain the queue of >>>>> buffers/DMA-descriptors, but no interrupts are required put data in a >>>>> buffer nor to shift to the next buffer (all handled by DMA). >>>>> >>>>> In any case, even if your application can use Linux as a slave, you will >>>>> likely have to write a device driver, or modify an existing one, to get >>>>> the specialized functions that you need. >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program >>>>> Be part of this innovative community and reach millions of netbook users >>>>> worldwide. Take advantage of special opportunities to increase revenue and >>>>> speed time-to-market. Join now, and jumpstart your future. >>>>> http://p.sf.net/sfu/intel-atom-d2d >>>>> _______________________________________________ >>>>> gumstix-users mailing list >>>>> gumstix-users@... >>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>> >>>>> >>> ------------------------------------------------------------------------------ >>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program >>> Be part of this innovative community and reach millions of netbook users >>> worldwide. Take advantage of special opportunities to increase revenue and >>> speed time-to-market. Join now, and jumpstart your future. >>> http://p.sf.net/sfu/intel-atom-d2d >>> _______________________________________________ >>> gumstix-users mailing list >>> gumstix-users@... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > gumstix-users mailing list > gumstix-users@... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |