**** BEGIN LOGGING AT Sat Mar 03 02:59:59 2012 Mar 03 03:00:10 http://www.cyberciti.biz/tips/linux-disable-screen-blanking-screen-going-blank.html Mar 03 03:00:25 There's another setting Mar 03 03:00:27 in /sys/ Mar 03 03:00:31 having a hard time finding it Mar 03 03:00:36 then fix the app :D Mar 03 03:01:19 Thks!:) Mar 03 03:02:06 cp: cannot stat `/angstrom/setup-scripts/sources/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.2/beaglebone/./configs/*': No such file or directory Mar 03 03:02:27 robinswan: also look in /sys/class/graphics/fb0 Mar 03 03:03:28 anlan_o: thank you ! I will try. Mar 03 03:03:38 ERROR: Function failed: Unpack failure for URL: 'file://configs/*'. Mar 03 03:14:01 I know angstrom has the setup-scripts directory, and the ~/.oe directory, is there anything else? Mar 03 03:16:32 I my know, there are no anything else. Mar 03 03:17:22 i recommend you follow openembedded quick start guide. Mar 03 03:33:33 my kernel command line reads "buddy=${buddy} buddy2=${buddy2} camera=${camera} vram=${vram}" what could be the reason those aren't being filled in properly? Mar 03 03:34:06 the serial console does show "buddy=trainer" while it's booting through Mar 03 03:35:06 err, not while it's booting, if i break into the manual boot i can see it in printenv Mar 03 04:45:05 hi Mar 03 04:45:09 beagleboard xm McSpi2 how to configure mux Mar 03 04:45:11 thanks Mar 03 04:45:53 I see // NOTE: Clock pins need to be in input mode Mar 03 04:46:38 But CPU as Master, should be configured to OUPUT Mar 03 05:37:54 does the trainer board come with an arduino bootloader or not? there wiki/tin can tools site seem to say both yes and no Mar 03 05:38:17 i can't seem to get avrdude to talk to it Mar 03 06:58:22 My beaglebone i2c hardware bus 2 is returning busy even though there are no capes on my board. Has anybody else experienced this problem? Mar 03 06:58:25 root@beaglebone:~# i2cget -y 3 0x54 Mar 03 06:58:25 Error: Could not set address to 0x54: Device or resource busy Mar 03 06:59:35 i imagine this is why my beaglebone cannot detect my cape bucause that address should be reserve for a cape but the beaglebone seems to be having problems with it Mar 03 07:01:02 I checked the schematic and it says that here is nothing connected to I2C2_SCL (i2c-3) Mar 03 07:02:09 also if I do a i2cdetect -r 3 Mar 03 07:02:24 i get 50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- -- Mar 03 07:03:02 those UU are in 0x54, 0x55, 0x56, 0x57. UU = busy Mar 03 07:05:59 I am running Linux beaglebone 3.2.5+ #1 Mon Feb 13 19:22:44 CET 2012 armv7l GNU/Linux Mar 03 07:08:13 OrlandoT: from the boot output on my board, " Mar 03 07:08:17 [ 0.231006] at24 3-0054: 32768 byte 24c256 EEPROM, writable, 64 bytes/write Mar 03 07:08:18 [ 0.231039] at24 3-0055: 32768 byte 24c256 EEPROM, writable, 64 bytes/write Mar 03 07:08:18 [ 0.231071] at24 3-0056: 32768 byte 24c256 EEPROM, writable, 64 bytes/write Mar 03 07:08:18 [ 0.231101] at24 3-0057: 32768 byte 24c256 EEPROM, writable, 64 bytes/write Mar 03 07:09:19 so what that means? you have a cape board connected to your beaglebone? Mar 03 07:09:26 so even though there's no device, the driver was loaded to probe for eeproms at those addresses? haven't looked to see how that works Mar 03 07:09:36 no, no capes installed Mar 03 07:10:01 yes, true it will scan for them at those addresses but it shouldn't find them Mar 03 07:10:58 can you do a i2cdetect -l for me? Mar 03 07:11:42 I get the same thing you do, and this one is running 3.1.0 Mar 03 07:11:46 actually I meant i2cdetect -r 3 Mar 03 07:12:22 …running… Mar 03 07:13:06 I don't think we get the same Mar 03 07:13:11 when I do a dmesg | grep -i cape Mar 03 07:13:12 i get Mar 03 07:13:24 [ 0.346969] BeagleBone cape EEPROM: could not read eeprom at address 0x54 Mar 03 07:13:24 [ 0.426968] BeagleBone cape EEPROM: could not read eeprom at address 0x55 Mar 03 07:13:24 [ 0.506967] BeagleBone cape EEPROM: could not read eeprom at address 0x56 Mar 03 07:13:24 [ 0.586967] BeagleBone cape EEPROM: could not read eeprom at address 0x57 Mar 03 07:13:24 [ 0.586985] BeagleBone cape: exporting ADC pins to sysfs Mar 03 07:13:35 50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- -- Mar 03 07:14:22 hmm... that means those locations are busy Mar 03 07:14:44 try to read 0x54 Mar 03 07:14:46 i2cget -y 3 0x54 Mar 03 07:15:18 I did, get the same thing you do Mar 03 07:15:29 this is so strange, how can those location be busy if there is no device connected to that i2c port? Mar 03 07:16:50 my schematic is A5 which match the version of my board Mar 03 07:17:23 I don't think there needs to be a device there for it to come back busy Mar 03 07:17:24 perhaps the i2c device driver is treating those addresses as busy because there is sure no device connected there Mar 03 07:17:41 it's a driver thing yeah Mar 03 07:18:06 there has to be a device there to come up busy either that or the driver is doing it Mar 03 07:18:31 i wonder why would the driver do that Mar 03 07:19:11 I install my cape board and the beaglebone does not even try to read the cape's eeprom. I have a scope on that scl line and see no activity Mar 03 07:21:13 ls /sys/bus/i2c/devices Mar 03 07:22:06 there are drivers installed for those devices so to i2cxxx they are busy Mar 03 07:23:49 ah? Mar 03 07:24:02 that does not make sense Mar 03 07:24:25 of course there needs to be a driver installed and running otherwise we could not use i2c Mar 03 07:24:59 plus you can use i2c-3 with any other address and it works. I can see the sda and scl on the scope Mar 03 07:25:34 for example, if you do i2cget -y 3 0x50 Mar 03 07:25:43 it will return Error: Read failed Mar 03 07:26:20 but you will see the i2c transaction trying to read in the sda and scl lines on the oscilloscope Mar 03 07:26:54 yes but at least on 3.1.0 there is an eeprom driver. the eeprom driver sits on top of the i2c framework, and once that driver has that address it's not available except through that driver. that's my understanding anyway Mar 03 07:27:41 it seems like the driver is reserving addresses 0x54,0x55,0x56 and 0x57. perhaps it needs to detect that a cape board has been inserted first and then the driver will allow reading from those addresses Mar 03 07:28:10 or maybe the driver will only let access to those addresses from kernel and not user space? Mar 03 07:28:43 an eeprom driver on top of the i2c Mar 03 07:28:51 now that makes sense Mar 03 07:29:29 so the eeprom driver has reserved those addresses for itself Mar 03 07:29:35 yes Mar 03 07:29:41 do you know the module name for this eeprom driver? Mar 03 07:30:19 lsmod Mar 03 07:30:19 Module Size Used by Mar 03 07:30:19 g_mass_storage 24010 0 Mar 03 07:30:19 ipv6 210434 20 Mar 03 07:30:27 it's compiled into the kernel I have so doesn't show up in lsmod. Mar 03 07:30:35 perhaps it's not a module :-( Mar 03 07:30:43 i see Mar 03 07:30:57 you should be able to read your eeprom via the eeprom driver though Mar 03 07:31:02 that's what it's there for after all Mar 03 07:31:21 ok Mar 03 07:31:29 how can i do that? Mar 03 07:33:04 you just treat it like a file… cat /sys/bus/i2c/devices/3-0054 should dump it to the console for example Mar 03 07:33:58 (tested with 1-0050) Mar 03 07:37:05 do you mean? cat /sys/bus/i2c/devices/i2c-3/3-0054/eeprom Mar 03 07:37:18 yeah sorry Mar 03 07:37:29 np Mar 03 07:37:37 I tried it with 1-0050 because I know there's an eeprom there Mar 03 07:39:13 ok let me give it a try Mar 03 07:40:32 hmm... i see nothing on the scope Mar 03 07:40:44 i get this on the console Mar 03 07:40:56 cat: /sys/bus/i2c/devices/i2c-3/3-0054/eeprom: Connection timed out Mar 03 07:41:21 hi Mar 03 07:42:13 Spi CLK PIN configuration for the INPUT, isn't that CPU for master Mar 03 07:42:21 thanks Mar 03 07:42:47 Sgarr: 1-0050 does work though Mar 03 07:43:08 hmm Mar 03 07:44:18 and still no activity on scope? Mar 03 07:44:52 well, i did not hook the scope to that channel but i have no doubt there is activity on that channel Mar 03 07:45:34 I have seen activity on i2c-3 as well if i use other addresses so i know the port works Mar 03 07:46:21 the strange thing is that the eeprom driver should scan 0x54 at bootup so that it can automatically detect my cape board Mar 03 07:46:42 the dmesg says that it is scanning that address but no activity on scope Mar 03 07:53:20 cat /sys/bus/i2c/devices/3-0054/eeprom Mar 03 07:53:26 cat: /sys/bus/i2c/devices/3-0054/eeprom: Connection timed out Mar 03 07:53:41 oh well, it's late so I am going to bed Mar 03 07:53:51 thank you Sgarr for your help Mar 03 07:54:09 sure sorry no real answers yet Mar 03 07:54:35 no problem thank you for trying Mar 03 07:54:53 you don't have a cape so i could not ask for more Mar 03 07:56:04 when I'm home (just have ssh to it right now, still on this blasted work trip) I might breadboard in an eeprom. There will surely be an answer before then though. have a good one Mar 03 07:57:38 oh don't go through all that trouble. Yes, i should have an answer before then and I'll let you know Mar 03 07:57:42 gnight Mar 03 09:46:14 mranostay: GMT+1 here :) Mar 03 09:50:44 <_av500_> UGT here Mar 03 12:09:56 OrlandoT: the driver will bind to the addresses even if there are no eeproms Mar 03 12:10:31 if you use a recent uImage there will be no timeout and the detection process works nicely. Mar 03 14:38:19 somebody must make a little plastic enclosure with the prongs on it to plug it into an AC outlet Mar 03 14:38:29 yet find one cannot I Mar 03 14:43:12 * SilicaGel12 tires phrasing his query in english Mar 03 14:48:29 ooooh polycase, here we go Mar 03 15:06:01 <_av500_> SilicaGel12: yes, they exist Mar 03 15:07:30 use paperclips Mar 03 15:08:01 pretty much equivalent to a US power plug Mar 03 15:09:16 <_av500_> paperclip is more useful Mar 03 15:09:40 that's why I didn't say exactly equivalent Mar 03 15:34:24 ok so i need major help now Mar 03 15:36:59 let me upload my boot up Mar 03 15:41:12 *** Warning - bad CRC, using default environment Mar 03 15:50:48 ignore that Mar 03 16:02:39 "OMAP totally fucked" -- is it full moon again? Mar 03 16:04:23 I'm guessing that retailers just have got another batch of beagles Mar 03 16:06:27 hmm Mar 03 16:06:48 been trying to get ubuntu netinstall to work for me but so far no green lights Mar 03 16:07:04 angstrom buildt last night works but now goes to black screen uplon log in Mar 03 16:09:32 yay finally boots up now Mar 03 16:18:50 baah i was so wrong about the twl4030 issue.. Mar 03 16:19:16 what omap3 based board uses a microphone input ? Mar 03 16:20:01 whats the uEnv.txt setting for a 1400x900 display? Mar 03 16:21:25 IRanNaked: check the kernel but im unsure if you find anything above 1280x720 in the wS range.. (at least for a beagle) Mar 03 16:22:18 i think it works... Mar 03 16:22:34 just changed it and my monitor isn't displaying wrong resolution OSD Mar 03 16:25:23 :) Mar 03 17:55:02 i want to run mp3 player in very low power mode, are there any experimental omap3 dsp mp3 players? Mar 03 17:56:04 http://wiki.davincidsp.com/index.php/C674x/OMAPL1x_Introductory_Information Mar 03 18:07:19 hmm anyway to make a ubuntu netinstall bootable? Mar 03 18:13:44 what makes a good insulator for running an boone in the box? Mar 03 18:13:51 well tin Mar 03 18:14:53 dwery: how recent the uImage has to be? I am using Linux beaglebone 3.2.5+ #1 Mon Feb 13 19:22:44 CET 2012 armv7l GNU/Linux Mar 03 18:15:18 dwery: I believe that is the latest of the latest or not? Mar 03 18:38:04 Crofton|work: sheet of plastic? Mar 03 18:47:12 I lack good plastic Mar 03 18:47:31 mru, what is the latest thinking on timing execution for testing NEON hacking? Mar 03 18:47:37 anti static bags? Mar 03 18:47:44 you had a patch to access he counters once upon a time Mar 03 18:47:58 Crofton|work: that patch still works Mar 03 18:48:01 yeah, thinking about an a-s bag, or old fashioned cardbaord Mar 03 18:48:01 jannau: not so good, seeing as they are slightly conductive Mar 03 18:48:15 how conductive Mar 03 18:48:18 let me measure Mar 03 18:48:19 yeah, thick paper would do too Mar 03 18:48:26 ask your trusty ohm meter Mar 03 18:48:59 can you be more specific about timing? Mar 03 18:49:23 sections of code Mar 03 18:49:43 duh Mar 03 18:50:35 btw, my vom reports more meg ohms than it can measure for a-s bag Mar 03 18:50:39 yeah duh Mar 03 18:52:33 "With playbin2 I play videos where audio and video is Mar 03 18:52:34 decoded by the dsp. The dsp is multitask" Mar 03 18:52:37 aha Mar 03 18:53:26 http://groups.google.com/group/gst-dsp/browse_thread/thread/39f7ad5c9630afd6 Mar 03 18:57:54 Crofton|work: the pink foam seems to work as well Mar 03 19:02:29 Crofton|work: and please tell me gary is trolling with his latest mail on angstrom devel Mar 03 19:11:04 use cardboardbox it came in :) Mar 03 19:11:49 * mranostay waves Mar 03 19:14:02 hey mranostay Mar 03 19:14:21 I've found a new demo to implement on the beaglebone: http://www.hackengineer.com/3dcam/ Mar 03 19:14:44 * koen is annoyed at having to patch the kernel to get 640x480 Mar 03 19:14:57 ew Mar 03 19:16:22 koen: git cherry-pick or some weird patch file somewhere? Mar 03 19:16:34 mranostay: to make it worse: the resolution and timings are set in drivers/video/davincifb, but the pixclock in the boardfile Mar 03 19:17:15 * koen waits for people to say "devicetree will fix that" Mar 03 19:18:19 device tree is the future! Mar 03 19:20:38 koen: kernel people need to follow --> http://boingboing.net/images/flowchart-2007.png Mar 03 19:20:41 I deleted the email already Mar 03 19:21:03 btw, thanks for working on cleaning up meta-ti Mar 03 19:27:58 ~welcome to the beagledrome~ Mar 03 19:28:52 can you well me what the ultra-low power solution for playing back mp3-ogg would be? Mar 03 19:29:05 is it the same with cpu or dsp? Mar 03 19:29:10 cortex-m4? Mar 03 19:29:47 copy 1-4mb chunks of frames to dsp and let it work and generate output straight to kernel alsa device, my thought Mar 03 19:30:07 i see this gst-dsp but little mention of the mp3 Mar 03 19:30:19 and no discussion of whether there is a power win to be had Mar 03 19:38:35 I have connected my beaglebone to a cape but it does not read the cape's eeprom at boot. Does anybody know why something like this might happen? Mar 03 19:38:43 my dmesg says Mar 03 19:38:48 [ 0.346987] BeagleBone cape EEPROM: could not read eeprom at address 0x54 Mar 03 19:38:48 [ 0.426984] BeagleBone cape EEPROM: could not read eeprom at address 0x55 Mar 03 19:38:48 [ 0.506984] BeagleBone cape EEPROM: could not read eeprom at address 0x56 Mar 03 19:38:48 [ 0.586984] BeagleBone cape EEPROM: could not read eeprom at address 0x57 Mar 03 19:38:48 [ 0.587002] BeagleBone cape: exporting ADC pins to sysfs Mar 03 19:39:01 http://stackoverflow.com/questions/3247373/how-to-measure-program-execution-time-in-arm-cortex-a8-processor Mar 03 19:39:19 I wouldn't trust stackoverflow in such matters Mar 03 19:39:44 the funny thing is that when i hook a scope of the sda/scl line i see no traffic Mar 03 19:39:48 at bootup Mar 03 19:39:53 or at anytime Mar 03 19:40:02 yeah, buit one of the answers seems to do what I want to try :) Mar 03 19:40:25 does the angstrom kernel have my patch to allow userspace perf counter access? Mar 03 19:40:33 however if i do echo a > /dev/i2c-3 then is see the i2c traffic on the scope Mar 03 19:40:34 not sure Mar 03 19:40:38 need to check Mar 03 19:40:46 koen rule #3... Mar 03 19:43:35 the cat likes to chew on the pink foam Mar 03 19:44:10 bother, it look like the bone has no Mar 03 19:44:21 patch enabling access to perf counters Mar 03 19:51:57 another detail is that I have done cat /sys/bus/i2c/devices/3-0054/eeprom because i know the i2c address is 0x54 for the cape's eerpom and i get Mar 03 19:52:04 cat: /sys/bus/i2c/devices/3-0054/eeprom: Connection timed out Mar 03 19:52:22 I am using Linux beaglebone 3.2.5+ #1 Mon Feb 13 19:22:44 CET 2012 armv7l GNU/Linux Mar 03 19:52:32 maybe it's just broken? Mar 03 19:52:48 what's broken? Mar 03 19:53:02 the eeprom Mar 03 19:53:31 well, there is no i2c traffic so it is not the eeprom's fault Mar 03 19:54:00 oh. i thought you said you did see traffic Mar 03 19:54:08 i also know the i2c port is fine because when i do echo a > /dev/i2c-3 then i see traffic on that i2c port Mar 03 19:54:53 not when it has to read the eeprom using the eeprom driver Mar 03 19:55:46 I can read/write i2c to i2c-3 as long as i do not use address 0x54,0x55,0x56 or 0x57 because the eeprom driver has reserved those addresses Mar 03 19:56:40 i guess there is a module that sits on top of the eeprom driver telling the eeprom driver to reserve those addresses Mar 03 19:56:57 probably it is reserved for only cape discovery Mar 03 19:57:26 so i need to find out which program is responsible for beaglebone cape discovery Mar 03 19:57:37 does anybody know? Mar 03 19:59:31 i wish there was a document explaining how the beagleboard detects cape boards. Mar 03 20:00:06 SRM? Mar 03 20:01:52 what's SRM? Mar 03 20:02:26 http://beagleboard.org/static/beaglebone/latest/README.htm Mar 03 20:02:29 oh system ref manual Mar 03 20:04:34 lol i had forgotten about the most important doc Mar 03 20:18:51 Crofton|work: ok i read the cape's section but it is more for hardware guys who want to design the cape but there is no information about which linux program reads the cape's EEProm Mar 03 20:21:18 I bet it is u-boot Mar 03 20:21:21 but I am not sure Mar 03 20:21:42 but maybe not Mar 03 20:23:44 probably not since the logs are dmesg and those are linux only Mar 03 20:26:19 Crofton|work: could you do a ps -A on your board for me? I would like to see if there is a program that you are running that I am not. perhaps it will be the program that does cape discovery Mar 03 20:26:58 just to check because most likely the discovery is not done by an app but some kernel driver that talks to the eeprom driver Mar 03 20:27:12 i'm totally guessing Mar 03 20:28:14 you can use http://pastebin.com/ for the results Mar 03 20:29:20 http://pastebin.com/chAqqXNf Mar 03 20:29:32 thank you Mar 03 20:30:33 you know what i just realized? I am thinking the structure is like this capeDiscoModule --> EEPromDriver --> I2CBusDriver --> Cape's EEProm Hw Mar 03 20:31:04 I know the I2CBusDriver works because I did echo a > /dev/i2c-3 and i saw the i2c traffic Mar 03 20:31:30 however if I do cat /sys/bus/i2c/devices/3-0054/eeprom Mar 03 20:31:41 i get cat: /sys/bus/i2c/devices/3-0054/eeprom: Connection timed out Mar 03 20:31:58 so I can conclude that the EEProm driver is the one acting up? Mar 03 20:32:22 the capeDiscoModule would get the same error I get when talking to the EEProm driver Mar 03 20:33:36 the bad thing is that this EEProm driver is not a module instead is compiled into the kernel and I am running Linux beaglebone 3.2.5+ Mar 03 20:33:50 I do not see 3.2.5+ at angstrom website Mar 03 20:34:39 Can anybody with Linux beaglebone 3.2.5+ access a cape? Mar 03 20:35:18 * mranostay checks closet Mar 03 20:35:26 sorry no capes in there Mar 03 20:37:25 small closet? lol Mar 03 20:38:29 no really i have my "lab" in there :) Mar 03 20:43:04 oh lol Mar 03 20:44:51 OrlandoT: it's not a program, it's the kernel that detects it Mar 03 20:45:27 ok thanks i should have known since they are dmesg i see Mar 03 20:45:43 so how do i troubleshoot this problem? Mar 03 20:46:36 I would like to take a look at the eeprom driver port for the beaglebone on kernel 3.2.5+ to see if i find the problem there Mar 03 20:47:04 because i get this error cat: /sys/bus/i2c/devices/3-0054/eeprom: Connection timed out Mar 03 20:47:40 i would understand if i get that error because there was no ack on the i2c bus but there was no i2c traffic generated at all Mar 03 20:48:12 koen: do you know where i can find the source code for this driver? Mar 03 20:49:58 OrlandoT: er check koen's tree? Mar 03 20:51:22 koen's tree? Mar 03 20:51:43 * mranostay smells potato pancakes Mar 03 20:53:38 mranostay: where is that located? i see a tree for a weather station project Mar 03 20:53:39 there's a git tree for lazy people here: https://github.com/koenkooi/linux/commits/linux-ti33x-psp-3.2-r5a+gitr09e9651bcf2ee8d86685f2a8075bc6557b1d3b91 Mar 03 20:54:05 the docs on the bone itself show you how to rebuild it Mar 03 20:54:25 oh cool Mar 03 20:55:03 i don't understand how this works. So angstrom distro is based on yor sources koen? Mar 03 20:55:40 koen is mr angstrom :) Mar 03 20:56:13 OrlandoT: no Mar 03 20:56:35 OrlandoT: follow the angstrom instructions and see what it uses to build things Mar 03 20:57:09 koen: anyone ever call it "an storm"? :) Mar 03 20:57:27 that git tree on github is only there for people either too lazy to too stupid to rebuild it properly Mar 03 20:57:54 mranostay: it's a dig at zaurus people calling everything a 'ROM', even sd cards Mar 03 20:58:03 mranostay: angst ROM Mar 03 20:58:32 lol Mar 03 20:58:50 heh Mar 03 20:59:29 koen: Zaurus has been dead for like 5 years right? Mar 03 20:59:35 pretty much Mar 03 20:59:38 or as I put it Mar 03 20:59:45 "at least it smells that way" Mar 03 20:59:50 of course who needs a pda anymore? Mar 03 21:00:30 we still have them, but we call them phones now Mar 03 21:00:41 yes Mar 03 21:01:16 it's actually phones we don't have any more Mar 03 21:01:26 when was the last time you made an actual phone call? Mar 03 21:01:41 compared to last time you used your 'phone' for something else Mar 03 21:02:17 mru: looks like 2 weeks ago :) Mar 03 21:03:31 see Mar 03 21:04:51 ah Windows developers... Mar 03 21:05:23 * mranostay breaks out good old find . -name *.c -exec dos2unix {} \; Mar 03 21:05:43 can't find the eeprom driver code :-( just realized how complicated this is. They have an MTD subsystem and they use JDEC to detect flash/eeproms Mar 03 21:06:05 my little brain is not likely to fix this issue Mar 03 21:06:41 so use your big brain Mar 03 21:06:57 that one is always thinking about sex Mar 03 21:07:04 oops did I say that out loud? lol Mar 03 21:07:26 it is ok we don't work for the same company so we can't call HR :P Mar 03 21:07:33 OrlandoT: https://github.com/koenkooi/linux/blob/linux-ti33x-psp-3.2-r5a+gitr09e9651bcf2ee8d86685f2a8075bc6557b1d3b91/arch/arm/mach-omap2/board-am335xevm.c#L1839 Mar 03 21:08:01 * mranostay pictures someday haven't a job interview and having IRC chat logs coming back to haunt him :) Mar 03 21:08:03 lol good one Mar 03 21:09:00 koen: us famous irc guys have to worry right? :) Mar 03 21:09:13 * mru does not worry Mar 03 21:09:19 does that mean I'm not famous enough? Mar 03 21:10:02 * mranostay needs to do something with his new debugger this weekend Mar 03 21:10:11 mru: did kridner label you as "famous IRC people" in a youtube movie? Mar 03 21:10:27 no idea Mar 03 21:10:33 mranostay: FS2? Mar 03 21:11:04 actually i should say logic probe Mar 03 21:11:54 so i'm told someone fixed the OpenOCD for the bone Mar 03 21:11:59 heh Mar 03 21:12:16 I heard I threw someone under the bus for that :) Mar 03 21:12:36 koen: ? Mar 03 21:12:41 koen: thank you. I am assumming this is your way of telling me that the error could be in the config for the EEprom not the eeprom driver itself. Cool all the platform specific stuff seems to be in that file Mar 03 21:13:35 mranostay: the other matt received emails after I pointed him out during my talk :) Mar 03 21:13:46 mranostay: http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=summary shows a few commits for a bone cfg Mar 03 21:14:35 * mranostay notes he needs less techy hobbies :) Mar 03 21:17:30 koen: so the icepick is interfaces directly the FTDI chip? Mar 03 21:17:55 mranostay: I think it is Mar 03 21:17:55 *interfaced Mar 03 21:17:59 <- jtag n00b Mar 03 21:18:16 ok that makes two of us :) Mar 03 21:18:40 all i know is how to hack BDI config files :) Mar 03 21:19:24 and usually then it 95% done for you minus the NOR/NAND mapping Mar 03 21:23:22 OrlandoT: there's a prebuilt image here: http://www.angstrom-distribution.org/demo/beaglebone/ . it should work nicely. Mar 03 21:23:54 (img.xz) Mar 03 21:27:23 can anybody help with compiling u-boot with angstrom? I get link errors with the current recipe Mar 03 21:27:38 ggreen: stop doing it wrong :P Mar 03 21:27:48 yes that would be good Mar 03 21:28:11 dwery: this prebuild image has kernel 2.3.5+? Mar 03 21:29:26 when i did a google search i found this on pastebin, so someone else had the same problem, but no other hits anywhere: http://pastebin.com/FQASuKkg Mar 03 21:31:48 OrlandoT: I don;t know Mar 03 21:31:56 haven't checked it Mar 03 21:32:20 dwery: i think you have a point that i should just upgrade because somebody has probably already fixed my problem. Mar 03 21:32:36 yeah I will simply update Mar 03 21:32:49 you might just extract the kernel Mar 03 21:33:29 i2c bus timeout is usually due to missing pullup resistors, which were not activated in some kernel versions. Mar 03 21:33:38 I'm not sure if you have a fixed one or not Mar 03 21:33:53 you can add a cape and see if it works Mar 03 21:33:56 or add an eeprom Mar 03 21:35:32 i can tell that the uImage is 3.1 by the file name :-( Mar 03 21:35:42 I am currently running 3.2.5+ Mar 03 21:36:02 where did you got it ? Mar 03 21:36:10 hi all! I can't install my new beaglebone's xds100 driver on vista. (access denied) have anybody seen something like this? Mar 03 21:36:17 the cape that I have comes with pullup resistor (hardware) already in the sda/scl lines Mar 03 21:36:37 uhm.. which cape? Mar 03 21:36:47 dwery: it came with that version when i bought it Mar 03 21:36:50 a week ago Mar 03 21:36:57 well, it should work just fine then Mar 03 21:36:59 I have xds100 driver from ccs (so it's trusted) Mar 03 21:37:12 dwery: it's the dvi cape Mar 03 21:38:10 and you get i2c timeouts, right? Mar 03 21:38:18 dwery: no Mar 03 21:38:29 oh Mar 03 21:38:58 dwery: there is no traffic at all on the i2c-3 bus when the dmesg shows saying that it could not read eeprom at 0x54-0x57 Mar 03 21:39:09 uhm... Mar 03 21:39:32 got a fast scope? Mar 03 21:39:34 if i use the i2c-3 bus myself then i can see traffic Mar 03 21:39:55 a regular 100Mhz scope Mar 03 21:40:09 the bus only runs at 100K Mar 03 21:40:11 any chance you might be missing the traffic on bootup? it is probably quite fast Mar 03 21:40:16 triggers? Mar 03 21:40:19 no way Mar 03 21:40:21 ok. Mar 03 21:40:26 i trigger on the clocks Mar 03 21:40:33 it's not on auto-trigger Mar 03 21:40:38 I'd try with another i2c chip before declaring a faulty bus Mar 03 21:42:07 i can do echo a > /dev/i2c-3 and i see traffic right away Mar 03 21:42:24 so it's not a faulty i2c bus Mar 03 21:42:32 and I guess you see traffic with i2cdetect? Mar 03 21:42:46 yes, i do Mar 03 21:42:52 faulty eeprom? Mar 03 21:43:11 well, if there is no traffic there is no chance for the eeprom to respond Mar 03 21:43:20 try to unbind the driver Mar 03 21:43:41 find /sys | grep eeprom | grep unbind should get you the right file Mar 03 21:43:52 (or grep at24, can't remember) Mar 03 21:44:03 ok another data point is that if i do cat: /sys/bus/i2c/devices/3-0054/eeprom Mar 03 21:44:05 that's when i get Mar 03 21:44:07 cat: /sys/bus/i2c/devices/3-0054/eeprom: Connection timed out Mar 03 21:45:09 nope i tried the find command but nothing Mar 03 21:45:30 there's the unbind node somewhere Mar 03 21:45:48 I'm pretty sure, I just can't remember where Mar 03 21:48:08 why do you want to unbind the eeprom driver? Mar 03 21:48:23 so you can use the i2c* commands to try to talk to the chip Mar 03 21:50:07 oh ok makes sense Mar 03 21:50:32 but if I am successful at talking directly with the chip then what? Mar 03 21:51:49 dwery: koen showed me the source for board-am335xevm.c and in there they do omap_register_i2c_bus(3, 100, cape_i2c_boardinfo, ARRAY_SIZE(cape_i2c_boardinfo)); Mar 03 21:52:09 which i believe reserves the addresses 0x54-0x57 so that nobody else can use it Mar 03 21:52:41 the function name is i2c2_init Mar 03 21:52:52 https://github.com/koenkooi/linux/blob/linux-ti33x-psp-3.2-r5a+gitr09e9651bcf2ee8d86685f2a8075bc6557b1d3b91/arch/arm/mach-omap2/board-am335xevm.c#L1839 Mar 03 21:53:16 that is kernel 3.2.5+ Mar 03 21:53:24 yes, that's correct. unbinding the driver will free the addresses Mar 03 21:53:37 if you talk correctly, the there's a bug in the kernel code Mar 03 21:56:24 Hi, I'm new to embedded Linux but am interested in getting into the Beaglebone. Does the preinstalled Angstrom have low latency kernel patches? I'm hoping to use the Beaglebone for audio processing Mar 03 21:58:15 Damianos: I'd say not. Mar 03 21:58:36 <_av500_> Damianos: and you are sure you need that for audio? Mar 03 21:59:27 I was going to use libPD (Puredata) to process six audio signals at once Mar 03 21:59:37 so I'm assuming the answer is yes Mar 03 21:59:44 <_av500_> why? Mar 03 21:59:52