**** BEGIN LOGGING AT Mon Jul 01 02:59:58 2013 Jul 01 06:18:03 av500: ping Jul 01 06:20:21 time for beddy bye Jul 01 06:20:44 gn! Jul 01 07:00:38 vvu: pong Jul 01 09:25:25 av500: got the spl on board now, next logical step what would it be? Jul 01 09:45:45 vvu: but spl with patched kernel, right? Jul 01 09:49:43 av500: patched kernel and patched u-boot Jul 01 09:58:01 I needed to trick uboot to think that the connection is already established Jul 01 10:02:28 thats ok Jul 01 10:02:40 uboot we can patch Jul 01 10:02:45 Okok Jul 01 10:02:50 its the patched kernel that is not so nice Jul 01 10:03:05 but well Jul 01 10:03:13 With the stock one dunno what is happening there Jul 01 10:03:14 so, I would propose you get the whole chain running Jul 01 10:03:22 SPL, uboot, kernel Jul 01 10:03:25 initrd Jul 01 10:03:30 Ok no problem Jul 01 10:03:34 up to a point where you have a shell on the BBB Jul 01 10:03:45 Same thingie in like 2 days we have them runnin Jul 01 10:04:14 I will need some help in getting a good kernel +initrd! This combination Jul 01 10:04:30 But a bit later Jul 01 10:04:34 right Jul 01 10:04:42 test that first via linux Jul 01 10:04:45 and usb boot Jul 01 10:04:49 easier Jul 01 10:04:52 I'd guess Jul 01 10:04:54 Yep Jul 01 10:07:04 But in the end kernel patched is not nice, any proposal here? Or stick with the patch? Jul 01 14:14:18 keesj: testing the 2nd i2c bus (i2c1) on the BBB went fine (write and read back from an eeprom). I moved the 2 wires from my test circuit from pins P9-17 and P9-18 to P9-19 and P9-20 to test the 3rd bus (i2c2) and it isn't finding the chip. Jul 01 14:15:01 I checked the padconf stuff 3 times and don't see any obvious errors. https://github.com/tcort/minix-i2c/commit/9fa021adce4a70897d0723efe8484221cbc54427#L7R413 Jul 01 14:15:29 the padconf and clock setup works for the other buses Jul 01 14:15:45 is there anything obvious that I'm missing or suggestions for what to check? Jul 01 14:18:10 I'm using the VDD_3V3B and GND pins on P9 to supply power to the eeprom chip Jul 01 14:19:48 I've got the suggested 5.6k pull-up resistors on SCL and SDA Jul 01 14:37:15 morning jj2baile Jul 01 14:45:11 i2c1 and i2c2 are in the same power domain and clock domain Jul 01 14:45:59 unfortunately, u-boot and starterware don't touch the 3rd i2c bus and NetBSD doesn't support i2c on the am335x so I can't look at how they setup i2c2. Jul 01 14:58:06 tcort: I looked at the schematics and glanced and the AM335X TRM and I don't see a reason why it should not worked (I cheked the interrupt) Jul 01 15:00:09 tcort: you could boot into linux and check pinmux there Jul 01 15:00:11 and compare Jul 01 15:05:19 tcort I will give your code a run tomorrow! Jul 01 15:07:00 av500: I'm using the default angstrom that came with the BBB (rev A5A with no updates) and there are only 2 i2c buses showing /dev/i2c-{1,2} and /sys/bus/i2c/devices/i2c-{0,1} Jul 01 15:07:08 yes Jul 01 15:07:16 the others are not set up Jul 01 15:07:23 you need a DT fragment for that Jul 01 15:09:26 there's one already Jul 01 15:10:21 for i2c3? Jul 01 15:10:38 there was one in the audio patches Jul 01 15:11:00 yes (hw i2c2 is i2c-3 in software). Jul 01 15:11:04 I'll look into the DT stuff Jul 01 15:11:09 err, no Jul 01 15:11:13 not for i2c3 Jul 01 15:11:31 are you sure it's getting to the expansion headers? Jul 01 15:11:41 i2c0, i2c1, i2c2 go to the headers Jul 01 15:11:49 err, scratch i2c0 Jul 01 15:11:52 it's on the base board Jul 01 15:12:01 i2c1 goes to the headers but it's not enabled Jul 01 15:12:17 i2c2 got to the headers and is enabled since the eeproms of the capes are on that bus Jul 01 15:12:54 okay, so i2c2 (the 3rd i2c bus for cape eeproms) is mapped to /dev/i2c-2 in Linux? Jul 01 15:13:10 no Jul 01 15:13:24 the order is determined by the initialization order Jul 01 15:13:33 so i2c0 = i2c-0, i2c2 = i2c-1 Jul 01 15:13:58 I will try to address this on 3.10+, but it's no something you can rely on Jul 01 15:15:44 r/i2c-*/device :/sys/class/i2c-adapter/i2c-0/device# ls -l /sys/class/i2c-adapter Jul 01 15:15:44 lrwxrwxrwx 1 root root 0 Jan 1 01:12 /sys/class/i2c-adapter/i2c-0/device -> ../../44e0b000.i2c Jul 01 15:15:44 lrwxrwxrwx 1 root root 0 Jan 1 01:13 /sys/class/i2c-adapter/i2c-1/device -> ../../4819c000.i2c Jul 01 15:16:04 parse that link to make sure about the hardware interface for now Jul 01 15:18:19 0x4819c000 is for the 3rd bus and `i2cdetect -y -r 1` is giving me the address of the eeprom I have on the breadboard. Jul 01 15:19:44 right Jul 01 15:33:07 alright, with `i2cdump -y 1 0x50 c` I can read what I had previously written to the eeprom. So it looks like the hardware is all fine. I'll continue looking at the software to see if there is anything I'm missing. Jul 01 15:33:29 thanks for the help panto. Jul 01 15:35:57 np Jul 01 15:36:26 make sure you keep a log of the things that was too cryptic to figure out Jul 01 18:06:24 question - are you guys planning to use the PRUs only to connect to the target JTAG directly? Or via CPLD? Jul 01 18:07:48 ka6sox-away, ^^^^ Jul 01 18:07:56 jj2baile, ^^^^ Jul 01 18:08:41 mluckham, I believe the goal is to use the CPLD as somewhat of a buffer Jul 01 18:09:17 makes sense - and the EEPROM to hold the CPLD program? Jul 01 18:09:59 mluckham, cpld's need eeproms? Jul 01 18:10:17 I was thinking they are like fpga's Jul 01 18:10:20 I think the eeprom is cause it's a cape Jul 01 18:10:31 cpld usually don't need external program memory for loading the logic Jul 01 18:10:39 https://en.wikipedia.org/wiki/Complex_programmable_logic_device Jul 01 18:10:48 ok-thanks:) Jul 01 19:06:42 mluckham: At the moment it seems the intent is to try with just the PRU only, and depending on performance, we may leverage CPLD Jul 01 19:07:08 ka6sox-away: g'morn Jul 01 19:07:19 today is canada day, so I may be somewhat absent... Jul 01 19:19:15 jj2baile: thanks, is there a schematic to look at? Jul 01 19:32:36 mluckham: Yeah sure: https://github.com/ka6sox/BoneTag Jul 01 19:32:57 This is the possible JTAG shield that ka6sox is designing Jul 01 19:33:03 err, Cape, not sheild Jul 01 19:59:55 Cape :) Jul 01 20:10:40 jj2baile: thanks again, very helpful! Jul 01 20:19:58 looks like the CPLD itself will be programmed/debugged by the BBB (GPIO pins to the CPLD JTAG) - nice! Jul 01 20:23:14 CPLD supports various JTAG target protocols and busses Jul 01 21:15:13 any thoughts on using this Cape for Embedded Trace Buffer? Jul 01 23:12:17 mluckham, yes Jul 02 01:22:28 ka6sox, good! Jul 02 01:27:20 anyone know him? **** ENDING LOGGING AT Tue Jul 02 02:59:58 2013