**** BEGIN LOGGING AT Thu Apr 13 03:00:03 2017 Apr 13 06:53:27 gm Apr 13 07:18:23 zmatt: CM_PER_L4LS_CLKSTCTRL reads 0x101, so only the L4LS GCLK seems to be active, all other clocks in the domain are off already Apr 13 07:31:45 zmatt: never mind, got it Apr 13 08:33:03 zmatt: hmm, CPTS_RFT, what is that? Apr 13 08:43:18 zmatt: clock obviously goes into the ethernet controller, but how to shut it down? Apr 13 09:06:53 timestamping refclk Apr 13 12:31:03 zmatt: CPTS_CONTROL is shows that the CPTS module is disabled, so why is the reference clock enabled? Apr 13 13:09:03 that's just a config register of the CPTS module, prcm doesn't know about that Apr 13 13:10:29 zmatt: it's some clock output of the core dpll Apr 13 13:10:31 it's probably just viewed as a functional clock of the ethernet subsystem Apr 13 13:11:25 it's core-m5 (default) or core-m4 depending on mux in prcm Apr 13 13:11:36 offset 0x520 Apr 13 13:12:17 i.e. by default it's the 250 MHz ethernet clock, but it can be the 200 MHz L3 clock instead Apr 13 13:12:51 and both of those are needed by ethernet anyway :) Apr 13 13:23:31 zmatt: just not understanding why it's still active. ethernet is not used. but maybe u-boot didn't shut it down ... Apr 13 13:25:11 hmm, bit vague indeed, since the signal is not part of the ethernet clock domain (CLKSTCTRL register) but the L3 clock domain Apr 13 13:35:17 zmatt: ethernet main clock is also still active Apr 13 13:35:23 ahh Apr 13 13:35:40 zmatt: I guess ethernet module is left on by u-boot Apr 13 13:35:49 that sounds plausible Apr 13 13:35:56 isn't hard to disable though Apr 13 13:36:46 zmatt: hmm, cpgmac0 hwmod? Apr 13 13:37:34 maybe first kill it: use SOFT_RESET in CPSW_WR and then CPDMA_SOFT_RESET Apr 13 13:39:01 and finally the switch itself (CPSW_SS) Apr 13 13:39:45 and yeah there are two prcm registers, the module and the clock domain Apr 13 13:40:11 zmatt: didn't even map the module.. Apr 13 13:40:57 I don't think it'll enter standby mode if cpdma is still active Apr 13 13:41:15 so you'd at least need to do the first two steps Apr 13 14:26:40 zmatt: cpgmac0 clkctrl says module is disabled but the STBYST is not set Apr 13 14:26:56 zmatt: so, didn't enter standby state Apr 13 14:27:02 zmatt: soft resets didn't help Apr 13 14:33:28 zmatt: the cpgmac hwmod definition in the linux kernel is a bit weird. claims there is a standard sysstatus and sysconfig but that is obviously not the case Apr 13 14:40:12 thinkfat_: you've reset CPSW_WR and CPDMA ? (actually, now that I think of it the right order might be the other way around) ... what does CPSW_WR CONTROL say? Apr 13 14:44:50 zmatt: yup, soft reset of about everything that has it, but you need to explicitly force-idle/standby the WR Apr 13 14:45:02 zmatt: otherwise, module won't idle Apr 13 14:45:45 zmatt: now the per_cpsw clock domain is sleeping and the cpgmac0 hwmod says its disabled and in standby Apr 13 14:45:49 zmatt: all good Apr 13 14:47:36 zmatt: last obstacle is the L3 clock itself Apr 13 14:48:28 zmatt: looks like there are some other modules on the L3 that are not idle yet Apr 13 14:49:48 zmatt: EDMA, maybe Apr 13 15:04:47 zmatt: EDMA has the same pattern I think. I need to forcibly put it in standby mode, or it will keep requesting the L3 clock Apr 13 17:45:55 Hello :) Apr 13 17:47:28 I'd need some help regarding the usage of I2C by Beaglebone Black PRU. Is there anyone willing to help me? Apr 13 17:48:18 don't ask for a personal assistant, just ask your question and be patient, lots of knowledgable people here only occasionally pay attention to the chat (and may be in different timezones) Apr 13 17:48:31 I'm afk, bbl Apr 13 17:49:39 @zmatt, that's the first time I'm using IRC, so thanks for your patience too Apr 13 17:50:51 So I'm writing a program, that should be executed by PRU1 and it's purpose is to initalize acc and gyro and then read data from them Apr 13 17:51:21 For this I'm using I2C2 of BBB Apr 13 17:51:37 BBB is master, acc/gyro is a slave Apr 13 17:52:42 What is unclear to me is how I2C registers of AM3358 should be programmed to reach my goal Apr 13 17:54:44 For now all that works is when I write data to acc/gyro (initialize the device). When I try to read data back I always get 0x00, even though I know the value of given registers is different Apr 13 17:55:06 why are you doing this on the PRU? Apr 13 17:55:24 I2C is not exactly a realtime bus Apr 13 17:57:16 I wanted to: 1) Be sure that I read the data as soon as they're available 2) Do the preprocessing of these data on PRU and then deliver them to CPU Apr 13 18:01:22 I'm wondering whether CPU isn't messing something up while I'm accessing I2C through PRU Apr 13 18:01:46 then don't use the I2C HW if that is your goal Apr 13 18:01:59 I'm not doing anything with the I2C on purpose from the linux leve though Apr 13 18:02:40 yes but using non local peripherals doesn't make sense Apr 13 18:03:22 @ds2 because of read latency? Apr 13 18:03:36 pretty much Apr 13 18:03:50 besides, I2C is slow enough it doesn't matter if you do it on the A8 itself Apr 13 18:04:12 if you are worry about dropping samples, use the FIFO on the acc/gyr Apr 13 18:05:30 hmm... maybe I've really fixed myself on that HW I2C idea, but that solution seemed to be ready to use Apr 13 18:05:53 and I'm spending second week on it and nothing seems to be working as expected... Apr 13 18:06:40 is the PRU the final consumer of the gyr/acc data? Apr 13 18:07:44 if not, you are incurring latency doing I2C - PRU then PRU - ARM Apr 13 18:08:31 good point... Apr 13 18:08:57 thanks for the advices then ;) Apr 13 18:10:24 one thing yet Apr 13 18:10:39 these readings are crutial to my application Apr 13 18:11:20 and if I read them with linux and there comes a OS caused latency, I'll be screwed... Apr 13 18:11:43 that is another reason why I wanted PRU to do the JOB Apr 13 18:11:47 why? Apr 13 18:11:56 there is a latency due to I2C already Apr 13 18:12:20 I know, but only due to I2C Apr 13 18:12:22 and what sample rates are you looking at? Apr 13 18:12:35 not other things that non RT OS does Apr 13 18:12:45 1.66kHz Apr 13 18:12:59 how fast are you running the I2C at? Apr 13 18:13:17 100kHz Apr 13 18:13:54 let's do the math Apr 13 18:14:15 1600 * 2 * 6 * 8 =~ 160K alrady Apr 13 18:14:31 that assumes you don't have stop/stop conditions or clocking out of registers... Apr 13 18:14:49 1600 KHz, 2 bytes per sample, 6 axis, 8 bit per byte Apr 13 18:19:48 I'm not sure whether I understand you well - I'm not concerned about I2C speed. It's when I run these app that is collecting data from acc/gyro, can I be sure that it'll not ie miss any samples due to OS latencies? Apr 13 18:20:21 When it's running on non RT linux rather than RT PRU? Apr 13 18:29:54 and I am saying, the bus cannot handle the traffic so all else is moot Apr 13 19:30:34 @ds2 thanks for help, have to go Apr 13 20:17:50 Hi Apr 13 20:18:06 I have an issue sampling mic through analog pins Apr 13 20:18:23 If I know the ADC sampling rate is 200K Apr 13 22:00:22 zmatt: odd Apr 13 22:00:43 zmatt: every module in PER is now off, but the power domain still doesn't transition to OFF Apr 13 22:11:31 all clock domains in PER are in sw_sleep ? all their clocks off? Apr 13 22:52:52 ds2: to be fair, there isn't anything inherently contradictory to having real-time requirements on i2c... performance is not what makes real-time real-time of course Apr 13 22:55:13 if you're the only master and the slave has deterministic response time (e.g. it doesn't use clock stretching) then i2c itself is perfectly fine for real-time applications Apr 14 00:13:50 Hello. So, I have been having problems with updating the scripts on the Beaglebone Black and Beaglebone Blue. Whenever I do a Apr 14 00:14:03 sorry, hit enter on accident Apr 14 00:14:34 whenever I do a "git pull" in the /opt/scripts directory, it breaks the ssh server and I can't ssh into the Beaglebone anymore. Apr 14 00:17:01 I fixed this last time on the Beaglebone black by connecting to the shell's UART and reverting to a previous commit, but I am on the Beaglebone Blue right now and I don't have any JST-SH connectors to connect to the shell's UART (They are coming in the mail). Is there anyway to fix this? Apr 14 00:30:24 Ok, I figured it out. The Beaglebone Blue was showing up as /dev/ttyACM0 on my PC. So, I was able to use Putty to connect to the shell that way and revert back to an earlier scripts commit. **** ENDING LOGGING AT Fri Apr 14 03:00:01 2017