**** BEGIN LOGGING AT Tue Jul 09 03:00:00 2013 Jul 09 03:20:55 just remembered how to use uboot. Jul 09 03:21:13 booted back into the beagle Jul 09 03:23:12 Also, the fdt uboot command that puzzled me months ago, is no longer a myster, now that i've been introduced the the concept device tree Jul 09 03:38:32 excellent Jul 09 03:48:33 ka6sox: Any idea why unloading the 'Bone-Black-HDMI' cape fails catastrophically? (http://pastebin.com/6vBN86Xt) Jul 09 03:49:53 sound code has a bug it appears Jul 09 03:50:02 it fails to unregister runtime PM in the module deinit Jul 09 03:55:06 hm Jul 09 03:55:59 jj2baile, what you need to do is load the PRU one and ignore unloading Jul 09 03:56:08 because unloading doesn't work yet Jul 09 03:57:01 bonus points for fixing this one Jul 09 03:57:09 looks like a 2-3 line fix Jul 09 03:57:18 could even be a 1 line fix Jul 09 04:37:25 Alright, preventing the hdmi thing from loading lets the test dtb from hours ago work. Jul 09 04:37:43 ds2: where would the code that is broken with hdmi thingy live? Jul 09 04:38:30 look for the mcasp stuff Jul 09 04:38:37 guessing it might be in sound/soc somewhere Jul 09 04:46:45 no, its worse Jul 09 04:46:49 its part of the HDMI code Jul 09 04:49:31 [ 59.861225] [] (davinci_mcasp_remove+0x1b/0x26) from [] (platform_drv_remove+0xd/0xe) Jul 09 04:49:42 davinci_mcasp_remove is part of the HDMI code? Jul 09 04:49:47 how did they F'd that up? Jul 09 05:51:12 it seems to me the table at: http://www.elinux.org/Ti_AM33XX_PRUSSv2#Beaglebone_PRU_connections_and_modes is wrong in a few places Jul 09 08:50:28 jj2baile, since I made that table...please tell me what I did wrong :) Jul 09 08:52:25 and I will fix it Jul 09 14:41:58 ka6sox-away: GPIO1_13 is actually called gpmc_ad13 i believe? (and has offset reg 834h) Jul 09 14:58:36 ka6sox-away: and as for the table headings: isn't R30 for output, and R31 for input. (or are you saying the R30 register takes an input, which I suppose is a valid way of looking at it) Jul 09 14:59:31 but regardless, P8_12, and P8_11 use Mode 6 for output not input. and thus shoulld be by the R30 side Jul 09 15:03:15 jj2baile, for mappings see https://github.com/bradfa/beaglebone_pinmux_tables Jul 09 15:03:36 and if you see any issues, pull requests welcomed :) Jul 09 15:05:07 jj2baile, looking Jul 09 15:07:19 jj2baile, bradfa since I added the PRU stuff to both tables, it should be wrong in both. Jul 09 15:08:24 ka6sox: there might have been other things as well, but upon just awaking those are the only things I can remember. Jul 09 15:08:35 same here Jul 09 15:08:52 okay lets carefully look at this so we get this DTC right Jul 09 15:09:27 I show the doco in the tables as being on 12 and 13 not 11 and 12 Jul 09 15:09:53 ka6sox, ha, ok :) Jul 09 15:10:15 send me a pull req, please Jul 09 15:11:37 bradfa, once I sort it a bit more I'll send a request including the alternative pinmux addys for P9_41 and P9_42 Jul 09 15:12:11 ok, cool Jul 09 15:12:52 the original document came from mranostay and I verified with the TRM his information Jul 09 15:12:54 anybody knows where kessj has disappeared ? haven't seen him here lately. Jul 09 15:12:55 and it is correct Jul 09 15:30:20 good catches jj2baile Jul 09 15:31:53 oh, let's blame mranostay! :) Jul 09 15:33:41 ugh...I now have to fix this in the JavaScript too. Jul 09 16:15:19 jj2baile, I fixed the table Jul 09 16:15:31 now to fix bradfa's tables Jul 09 16:23:42 ka6sox: as well, I think for GPIO3_19, and GPIO3_21, mode 5 is output(R30), mode 6 is input(R31) Jul 09 16:24:02 I think at least. Based on the signal names, and the fact that mode 5 was what worked for output for me Jul 09 16:24:15 This might be the case for similar pins, but had not looked into those Jul 09 16:25:10 can you look at the table again? Jul 09 16:41:49 yeah, I did. And according to the datasheet for at least GPIO3_{19,21} its mode 5 for out, mode 6 for in Jul 09 16:42:51 (it is flipped in the table) Jul 09 16:44:07 (the datasheet i am looking at is found here: http://www.ti.com/lit/ds/sprs717f/sprs717f.pdf) Jul 09 16:47:38 hopefully this is the correct one, but according to it, the first 8 pins should have the two pinmux tables swapped. Jul 09 16:49:32 but i digress. Jul 09 16:55:10 thats not a digression Jul 09 16:55:37 jj2baile, is this on both pru0 and pru1? Jul 09 16:58:18 i hadn't checked PRU1 yet. i think i've hit all PRU0 though. Ill go check pRU1 now Jul 09 17:02:33 seems to be the case as well. swap pin mode table for PRU1 in the range 0-13 Jul 09 17:03:10 * ka6sox must have been on bad drugs.... Jul 09 17:03:29 you are using spruh73"C" not F right? Jul 09 17:03:36 as they don't talk about the PRU in F Jul 09 17:03:53 that reference doesnt actually have the pinmodes as far as I found Jul 09 17:04:02 to find the modes themselves im using the datasheet Jul 09 17:04:10 http://www.ti.com/lit/ds/sprs717f/sprs717f.pdf Jul 09 17:09:42 er, by pinmux/mode table, i meant columns. Jul 09 17:10:15 right Jul 09 17:10:20 yes, that works Jul 09 17:11:59 look now please? Jul 09 17:12:14 if this table is fixed then I can set about to fixing the others Jul 09 17:12:58 I see no other issues. Jul 09 17:14:35 now I gotta fix up bradfa's tables...but that will be later as I'm needing a break Jul 09 17:23:14 so there is one thing im not sure i understand about the pinmux values. a value of 0x25: is mode 5 + input enable bit is set. Jul 09 17:23:28 if mode 5 is for output, why do we also set the input enable bit? Jul 09 17:23:44 you don't have to Jul 09 17:26:38 Does it do anything in particular though? Jul 09 17:26:52 just enables the receiver Jul 09 17:26:57 on a GPO that doesnt' make sense Jul 09 17:28:19 I think the mode bit take precedence Jul 09 17:28:23 but I don't know the details Jul 09 17:29:09 good morning panto Jul 09 17:29:20 hi jj2baile Jul 09 17:30:49 jj2baile, so we need pru0_pru_r30_[0:7] as outputs right? Jul 09 17:32:21 btw, there's a trick where you can access the other PRU's GPI/GPOs (but with a penalty) Jul 09 17:33:13 how many cycles? Jul 09 17:33:26 you don't go through the OCP host port Jul 09 17:33:33 panto, we are discussing: http://www.elinux.org/Ti_AM33XX_PRUSSv2#Beaglebone_PRU_connections_and_modes Jul 09 17:33:34 it's local accesses Jul 09 17:33:48 so maybe 20-30 Jul 09 17:33:53 kk Jul 09 17:34:50 ka6sox: outputs for what? Jul 09 17:35:01 pru0 Jul 09 17:35:05 the 8 bits Jul 09 17:35:10 do you mean to communicate with CPLD? Jul 09 17:35:14 yes Jul 09 17:35:25 Ah. yeah. Seems fine. Jul 09 17:35:49 and iirc pru1_pru_r31_[0:8] are inputs Jul 09 17:36:27 lets talk about pru0_pru_r[30,31]_[14,15] Jul 09 17:37:14 I was going to use those to signal the app to give more data (one pin as input) and flush (output) Jul 09 17:37:56 or alternatively we can use r31_16 Jul 09 17:38:00 (which is input only) Jul 09 17:38:55 the PISO (and FIFOs if we use them) need to signal when they want more data Jul 09 17:41:36 in reality we need start(O), flush(O) and EMPTY(I) Jul 09 17:41:53 EMPTY(I)? Jul 09 17:42:37 the PISO/FIFO needs to tell the PRU it wants more data Jul 09 17:42:57 oh alright Jul 09 17:43:36 16 is input only Jul 09 17:43:42 so that means empty is on 16 Jul 09 17:44:13 and that makes 14,15 outputs (start,flush) Jul 09 17:44:26 or we can call them start/stop Jul 09 17:44:32 your call Jul 09 17:45:43 start/flush is fine. Jul 09 17:47:06 okay for now: Jul 09 17:47:38 pru0_pru_r30_[0:7,14,15] set as outputs (for the DTC) Jul 09 17:47:50 pru0_pru_r31_16 set as input Jul 09 17:48:23 are bits 4 and 6 affected by the note on your table? Or is it only relevant if setting them to input mode Jul 09 17:48:45 actually they are significantly affected by this Jul 09 17:48:51 so now is the time to reconsider Jul 09 17:49:22 the problem is that the designer of the BB* doubled up on pins Jul 09 17:49:34 So what the note is saying is, if we want to use these pins for anything GPIO0_7 and GPIO0_20 must be set to input Jul 09 17:49:38 so that means we need to be cautious Jul 09 17:49:45 right Jul 09 17:50:11 doesnt' matter if the cape drives it or the PRU Jul 09 17:50:17 s/it/them Jul 09 17:52:48 panto, is that going to be a problem? Jul 09 17:52:59 no Jul 09 17:53:25 are GPIO0_{7,20} used by the board for anything? Jul 09 17:54:06 I'd have to see if cclk_out2 is used by anthing else Jul 09 17:54:11 I don't think so Jul 09 17:54:21 it is used for the camera cape Jul 09 17:54:24 Alright. But this means that for the DTB you create you need to also specify these pins right? Jul 09 17:54:33 and maybe gpmc peripherals Jul 09 17:54:35 specify the mode* Jul 09 17:54:47 panto, this cape will be pretty exclusive Jul 09 17:55:01 I don't expect GPMC to be used (at least I hope not!) Jul 09 17:55:20 ka6sox, just saying :) Jul 09 17:55:26 got it. Jul 09 17:55:28 Good to know at least. Jul 09 17:55:44 well this crashes with both emmc and hdmi onboard a BBB Jul 09 17:56:10 I have use for a 555 here I think Jul 09 17:56:41 Which pins are the emmc using again\/ Jul 09 17:57:30 jj2baile, see schematic, it's mmc1 7..0 plus clock and cmd Jul 09 17:59:32 panto, so eMMC will work with this cape? Jul 09 17:59:53 doubtful Jul 09 18:00:02 too many conflicts on the PRU pins Jul 09 18:00:09 we can try at least Jul 09 18:00:17 thats what I thought Jul 09 18:01:02 the CPLD will immediately configure...unless I add something to hold it off (the eMMC pins are on the bus and when Sys_rst comes OFF everything configures) Jul 09 18:02:12 the other option is to use the sysconfig lines to change the boot order and make the eMMC disappear Jul 09 18:05:24 panto, can you read the sysboot config and know when to disable eMMC? Jul 09 18:06:29 no Jul 09 18:06:44 so a hardware mod is necessary Jul 09 18:07:02 if you boot over mmc Jul 09 18:07:17 and the cape you use hogs any emmc pin, the emmc will be disabled Jul 09 18:07:44 however this all depends if you don't have any loading issues with another device on the bus (even when input) Jul 09 18:16:34 the issue is that even in that mode...*some* pins are being driven Jul 09 18:16:47 (related to the eMMC) Jul 09 18:17:04 so that causes a problem Jul 09 18:17:08 and a conflict Jul 09 18:17:50 yeah Jul 09 18:17:52 blame gerald Jul 09 18:18:48 we can swap I guess Jul 09 18:18:56 (pru0 for pru1) Jul 09 18:19:17 but i'd like to suss this out now in case I need to add something to make this not an issue Jul 09 18:29:49 jj2baile, panto thats going to be an issue for us too Jul 09 18:30:02 we will be driving those pins almost immediately Jul 09 18:30:36 P8_12, P8_13, P8_10 Jul 09 18:31:18 jj2baile, this means we should swap and use PRU1 as output and PRU0 as input Jul 09 18:31:18 hm Jul 09 18:31:26 Alrighty Jul 09 18:32:04 now we should see if anything else is broken with the eMMC before I drive a Stake thru its heart. Jul 09 18:42:41 it seems to me the emmc only uses GPMC_AD[0,7], PRU1_PRU_R31_[12,13] Jul 09 18:42:52 None of which are used by PRU0? Jul 09 18:43:58 (and the last two, used by PRU1 Jul 09 18:44:00 ) Jul 09 18:47:30 also LCDdata is configured as output for the HDMI as well. Jul 09 18:47:46 so that will crash PRU1_PRU_r30_0 Jul 09 18:47:55 (and the other ones too) Jul 09 18:48:13 the BBB is a poor choice for use with capes Jul 09 18:48:25 You can prevent the hdmi stuff from loading with a simple addition to uEnv.txt thankfull Jul 09 18:48:40 Thats what i ended up doing to get around the conflicts with my stuff from last night Jul 09 18:48:54 can you please blog about thigns like this? Jul 09 18:49:09 this information needs to be captured Jul 09 18:49:10 I think I did. Jul 09 18:49:13 kk Jul 09 18:49:36 But the post likely needs to be refined. Jul 09 18:49:46 i just quickly summarized the harrows of last night before i headed to bed Jul 09 18:49:56 kk Jul 09 18:50:10 (the line I added is there as well) Jul 09 18:51:35 So am I correct in the pins emmc is using? Because if so it doesnt seem like it interferes with PRU0 afterall Jul 09 18:52:15 TDA19988 the HDMi framer, correct/ Jul 09 18:52:16 ? Jul 09 18:52:20 yes Jul 09 18:56:39 And it is probably mostly safe to just, disregard the hdmi? Jul 09 18:58:29 iirc it is all outputs from the SoC to the framer Jul 09 18:59:17 jj2baile, how about using PRU1_PRU_r[30,31]_[10,11] instead of [12,13]? Jul 09 18:59:50 for in or out? Jul 09 18:59:54 that way your uEnv.txt fix will make the conflicts go away Jul 09 18:59:59 Are we still doing PRU1 for out instead of PRU0 Jul 09 19:00:01 we can define them later. Jul 09 19:00:23 I'm just trying to deconflict the BoneTag with the onboard stuff Jul 09 19:00:41 we don't have to use 12,13 we can use 10,11 just as easily Jul 09 19:00:44 But yeah, It seems to me like emmc is fine as long as we don't touch those 10 pins. which should be easy. Jul 09 19:00:58 Im kind of searching aroud for any other possible conflicts though Jul 09 19:01:12 okay so by not using gpmc_csn[1,2] we deconflict the eMMC? Jul 09 19:01:16 Im not sure how much my fix actually makes the problem go away. but at the very least, it prevents the HDMI virtual cape that is hogging all the pins from loading Jul 09 19:01:32 According to the BeagleBoneBlack schematics, i would say yes. Jul 09 19:01:50 those are MMC1_DAT[0,7] , MMC1_CMD, MMC1_CLK Jul 09 19:02:03 And I see no other none-power signals coming from that chip Jul 09 19:02:14 okay let me fix this Jul 09 19:03:44 so we are talking about using P8_28 and P8_30 right? Jul 09 19:03:48 (well there is also the emmc rst, but that is GPIO1_20 and thus not relevant to the discusion Jul 09 19:04:04 P8_28 and 30 for what? Jul 09 19:04:06 oh Jul 09 19:04:08 using, missed that word Jul 09 19:04:20 Yes. that seems fine Jul 09 19:04:48 Ok. So at present. we are talking about using PRU1 for output still, and PRU0 for input? Jul 09 19:07:41 if we have deconflicted the pins that the eMMC uses and we can use your uENV trick then we can go either way Jul 09 19:08:20 I've fixed the BoneTag to not use the pins we discussed Jul 09 19:08:30 (as being a conflict) Jul 09 19:10:36 we won't be using PRU1_PRU_r[30,31]_[12,13] on BoneTag Jul 09 19:11:39 okay I need to head out for a bit... Jul 09 19:11:43 good progress today Jul 09 19:12:03 if you see panto let him know of the change Jul 09 19:12:45 for RX you need a buffer full(I), Clock(I), and Start/Stop(O) Jul 09 19:16:06 k Jul 09 19:16:49 okay laters Jul 09 19:18:18 panto: Do you see any conflicts with the emmc based on what was said above? Jul 09 19:20:42 jj2baile, sorry was at dinner Jul 09 19:20:49 what is that all about? Jul 09 19:22:06 It seems to me that the emmc does not actually conflict with any pins the PRU may use, with the exception of PRU1 bits 12 and 13 Jul 09 19:22:17 i recall you saying above that it would be conflicting a lot Jul 09 19:23:57 jj2baile, ok, let me look Jul 09 19:24:18 basically "it seems to me the emmc only uses GPMC_AD[0,7], PRU1_PRU_R31_[12,13] Jul 09 19:24:21 " Jul 09 19:24:51 P8.21 P8.20 are the ones that conflict Jul 09 19:25:15 Yes that is consistent with my thoughts Jul 09 19:25:27 Alright, thanks Jul 09 19:25:36 right, 2/10 pins of the emmc Jul 09 19:26:18 and the hdmi can be taken out of the picture with a uEnv addition. (I am pretty sure). Jul 09 19:26:28 That was basically the gist of the discussion Jul 09 19:27:06 so if we can avoid using those two pins we're OK? Jul 09 19:27:21 I don't know how many pins we'll need Jul 09 19:27:49 But assuming we need at most n-2, things should be ok. Jul 09 19:28:33 famous last words :) Jul 09 19:28:44 haha. Jul 09 19:29:43 have you taken a look at the last pru stuff I pushed? Jul 09 19:29:54 panto, is the adc-read bug fixed now? Jul 09 19:29:56 Ah, I have it open somewhere but I hadn't read through the entire thing Jul 09 19:30:00 hatguy, it should Jul 09 19:30:19 where can I find information about the new instructions with pasm_2 by the way? I recall ka6sox instructing me to check out "loop" Jul 09 19:30:24 panto, which version should i go for? Jul 09 19:30:37 the last 3.8 kernel should have it Jul 09 19:30:45 3.11rc is a mess right now Jul 09 19:30:49 doesn't even boot Jul 09 19:31:08 panto, ahh... ok i have 3.8.13... I guess i need to update now Jul 09 19:31:15 jj2baile, git://github.com/beagleboard/am335x_pru_package.git Jul 09 19:31:48 I would say it's best to ask jkrinder so that we use the toolchain Jul 09 19:32:01 stuff like vrings are just too painful in assembly Jul 09 19:32:16 the way I did the pwm example was by having two PRUs in use Jul 09 19:32:26 the first one is the frontend, mostly programmed in C Jul 09 19:32:31 while the second one is hard RT Jul 09 22:45:50 mmm, It may be the case for input, to work properly it needs to be set to 0x26, not just 0x06 Jul 09 22:46:33 (bit 5 is the input enable, I think i tested with just 0x06 last night and it didnt work, but 0x26 seems to be just fine) Jul 09 22:46:50 I guess to make sure i'll test with 0x06 again Jul 09 22:55:46 It seems to be the case at least. ka6sox, If the input mode column of your table is supposed to be what value it needs to be set for input to work, you may want to verify **** ENDING LOGGING AT Wed Jul 10 02:59:59 2013