**** BEGIN LOGGING AT Sun Jun 21 02:59:58 2020 Jun 21 03:04:06 I guess I can perform the i2c instantiation w/ a Device Tree but what is the i2c bus number? I am lacking this idea. Off to read on github.com I guess. If you have any ideas, let me hear it! Jun 21 03:10:00 I see github.com/beagleboard/bb.org-overlays has a BBORG_SERVO-00A2.dts file. Should I load this file or will this .dts make the ServoCape work? Jun 21 03:41:33 Hello Team, I am using beaglebone black, kernel version 4.14. When any one of the pins P8.41, 43, 45 or 46 is high during boot, beaglebone does not boot. Can anyone please tel me what causes the issue? Jun 21 04:05:44 Are you using those pins when you boot? Jun 21 04:06:28 I know they are LCD Data pins that can be used as GPIO pins too. Jun 21 04:07:47 I think 45 and 46 is a PWM pin too. Hmm. did you try to figure out what mode those pins are in when you boot your BBB? Jun 21 04:09:17 Raj82: Try to update to the newest image. I think the image, or any older images, you are using may have no support. I am not completely sure. Maybe someone else will chime in soon. Jun 21 04:12:27 what is he trying to do Jun 21 04:13:32 Set_, Yes, I these pins are high during boot. I dont know what is the default mode during boot. Jun 21 04:14:01 Probably GPIO. Jun 21 04:14:09 Are you using them as GPIO? Jun 21 04:14:30 Oh. MattB0ne: Raj82 is having trouble at boot w/ specific pins. Jun 21 04:15:23 you should use zmatt overlay tool Jun 21 04:15:55 MattB0ne, There is some external input to these pins irrespective of the state of the BBB board. Jun 21 04:16:05 MattB0ne: The pins in question are P8.41, 43, 45, and 46 and when they are high at boot, the BBB does not boot. Jun 21 04:16:18 https://github.com/mvduin/overlay-utils Jun 21 04:16:20 Yes Jun 21 04:16:33 do you have any capes attached Jun 21 04:16:56 No cape Jun 21 04:17:17 Raj82: How do you boot if the pins are high and how can you change them back if the board cannot boot? Jun 21 04:18:24 I am using external board(not BBB) to power 3.3 V to these pins. Jun 21 04:18:33 Oh. Jun 21 04:19:30 How are you doing that exactly? I mean...how are you powering the BBB's pins w/ another board? Jun 21 04:20:19 Those pins are 3.3v tolerant and can be used as input and output but what method of input are you using? Jun 21 04:21:16 Like...a 3.3v input from a GPIO pin from another source? Jun 21 04:21:49 and then...you use the BBB outputs for whatever? Jun 21 04:22:46 Dang it. I was obviously not understanding. Jun 21 04:23:42 Raj82: Did I not understand? Jun 21 04:24:08 what are you trying to accomplish exactly Jun 21 04:24:16 Sorry I lost connection after this Jun 21 04:24:17 Raj82 09:48:24 Jun 21 04:24:40 Oh. Jun 21 04:24:52 Raj82: So, the BBB is not booting, right? Jun 21 04:25:01 Yes Jun 21 04:25:03 Did you try a serial connection? Jun 21 04:25:15 W/ a tty to usb dongle? Jun 21 04:25:25 No Jun 21 04:25:50 I am just trying to understand, is there any boot sequence causes this issue Jun 21 04:26:40 Oh. Jun 21 04:26:56 Not to my knowledge but I am not the uboot master. Jun 21 04:27:13 I think that would be better suited for another individual. Jun 21 04:27:56 Anyway, try a serial connection via tty to usb connect. You may be able to change your pins back from high to low. Jun 21 04:28:44 That way, you can boot and see specific parts of your file system. Jun 21 04:28:57 Yeah, yes if I left to low then it is working ok. Problem is only if those pins are high,I see only power LED on. All other LED are OFF. Jun 21 04:29:17 Right. Are you running source at boot when that happens? Jun 21 04:29:54 Sorry, what do you mean by source at boot? Jun 21 04:30:01 I know specific connections in specific modes will create a dysfunctional system. Jun 21 04:30:03 Oh. Jun 21 04:30:31 software or source. So, do you have a script running at boot when you turn on your board when the pins are high? Jun 21 04:31:38 Like a .py file or .c or .cpp file running when you boot the board w/ a .service file or another way? Jun 21 04:31:56 No, it is not getting into that state. Fails in kernel level. Jun 21 04:32:04 Oh. Jun 21 04:32:23 So, you need to debug your system as is and you do not want a new image? Jun 21 04:32:33 Also I see, the below update is https://cdn.sparkfun.com/datasheets/Dev/Beagle/e14%20BBB_SRM_rev%200.9.pdf These pins are also the SYSBOOT pins. DO NOT drive them before Jun 21 04:32:57 in 8.1.1 LCD Pins Jun 21 04:33:37 Oh. Okay. I guess it depends if they are being used, right. I have had some trouble before when running specific source w/ specific pins in use during boot. Jun 21 04:34:23 So, you drive the pins high somehow when they are in LCD mode? Jun 21 04:34:48 you need to get to your board. Use the serial connection and try. Jun 21 04:35:33 Those six pins near the header pins are the serial connect for debugging. Jun 21 04:35:41 It seems LCD is the default mode if it is not disabled in uEnv.txt. So I thought this may be also an issue. Jun 21 04:36:28 Oh. I know like MattB0ne said, @zmatt has had this script for seeing if the pins are in use, high, low, disabled, enabled, and so forth. Jun 21 04:36:39 Raj82: It is hard to tell. Jun 21 04:37:08 yes, I know that. I do not have FTDI converter so I have to buy one and try. Jun 21 04:37:14 If you do not have control of your board, I do not think it is possible to figure things out but please wait for someone. I am sure they will arrive. Jun 21 04:37:39 There are a couple of people who are experts w/ the BBB and debugging in general. Jun 21 04:38:06 Me, myself, and I <<< not so good w/out the booted board or even w/ the booted board. Ha. Jun 21 04:38:28 Raj82: Are you trying to keep your info. on your board? Jun 21 04:38:31 Thank you so much set_. ok I will wait for others input. Jun 21 04:38:40 No issue. Okay. Jun 21 04:40:15 * set_ Thinks something peculiar is going on. I hope you figure it out Raj82. Jun 21 15:48:57 zmatt: could I see the PWM with a multi-meter Jun 21 15:49:05 I do not have a oscilloscope Jun 21 15:49:14 I slowed down the frequency to 1 hz Jun 21 15:49:47 i was hoping to see it. I did try to run it through the jrk wasnt working and I want to trouble shoot seeing the pin voltage fluctuate Jun 21 15:50:05 I did add the print statement and I see the count change so the pru is working Jun 21 16:51:20 I'm having trouble enabling DCAN0. I know it conflicts wit I2C2 but I cannot find a way of either overriding or disabling I2C2. I've tried methods suggested in multiple places to no effect. config-pin P9.19 can always gets me the error message Pin is not modifyable: P9_19 i2c2_scl (spelling error in the original) Jun 21 16:52:37 More details on my attempts are here https://www.element14.com/community/message/293059/l/re-enabling-dcan0-disabling-i2c2#293059 Jun 21 17:00:34 Suggestions of items to look at or questions for more information about what I'm seeing are welcome. Either here or ot the question I linked. Jun 21 17:25:21 RobertClean: P9_19 should be reconfigurable unless you have an ancient system Jun 21 17:25:53 uname gives me Linux beaglebone 4.1.15-ti-rt-r43 #1 SMP PREEMPT RT Thu Jan 21 20:13:58 UTC 2016 armv7l GNU/Linux Jun 21 17:26:06 definitely ancient Jun 21 17:26:26 from the brief time they thought it was a good idea to ship rt kernels by default I guess Jun 21 17:26:53 you can find the image date in /etc/dogtag Jun 21 17:27:12 Well, that probably makes sense for the industrial version Jun 21 17:28:09 the industrial version is mostly silly, and doesn't run different software Jun 21 17:28:10 BeagleBoard.org Debian Image 2016-01-24 Jun 21 17:28:15 like I said, ancient Jun 21 17:28:18 :) Jun 21 17:29:48 Busy trying to get an up to date image Jun 21 17:32:28 The industrial version does have two important attributes though Jun 21 17:33:00 It's conformally coated and it has devices rated over the full temperature range Jun 21 17:34:33 well I think you're at max 85 degC anyway because of the ddr3 ram? Jun 21 17:34:40 which is also the limit for the commercial version of the SoC Jun 21 17:34:50 so I wonder which other components might have lower ratings Jun 21 17:34:55 The bigger issue is the low temperature range Jun 21 17:34:59 ah Jun 21 17:35:08 fair enough Jun 21 17:36:28 Truthfully, even most of the 0C rated devices could probably operate much lower. It's a risk management concern for those. Exception would be electrolytics. Jun 21 17:36:42 makes sense Jun 21 17:37:09 and this is mostly about starting up then I guess? since otherwise I'd expect it to keep itself wram Jun 21 17:37:12 *warm Jun 21 17:38:09 Yep, mostly startup. Could be soaking at low temperatures for weeks before startup. Once started the HVAC should slowly bring the ambient above 0 Jun 21 17:38:22 anyway, using an rt kernel is mostly useless unless you actually take advantage of its features (which requires somewhat specialized knowledge), and otherwise an rt kernel is overall just slower and often more prone to crash Jun 21 17:39:01 (because rt kernels tend to expose subtle locking bugs in drivers that would never cause a problem on a non-rt kernel) Jun 21 17:40:29 I'll keep that caution in mind. I mostly do RT but I'm not familiar with Linux based RT Jun 21 17:41:55 when using P9.19-20 for can, do keep in mind that while on newer systems the pins are runtime configurable, the pins would still be used for i2c probing during boot. you may want to explicitly disable that to avoid weird activity on the can bus and a drive conflict on the can rx pin (maybe also use a series resistor on that for protection to be safe) Jun 21 17:43:11 a linux-rt kernel improves worst-case latency by replacing most spinlocks (which on single-core systems are just non-preemptible "interrupts disabled" sections) by priority-inheritance mutexes and turning most interrupts into kernel threads Jun 21 17:43:31 I can easily enough add a blocking gate I've minor revisions to do in any case. I'm not really worried about bus disturbance on start. It won't affect traffic much. Still better to be clean. Jun 21 17:43:57 if you want really RT stuff on the BBB, its two PRU cores are very useful Jun 21 17:44:22 they can even generate custom signal waveforms with 5ns accuracy by bitbanging Jun 21 17:44:49 Yep, we are planning on using those. Also taking a look at the AI for future expansion. Haven't checked its IO yet though so it may not work. Jun 21 17:45:38 anyway, need to catch a train, back in an hour or so Jun 21 17:46:13 Thanks for the help. At least I've a thread to start pulling on Jun 21 18:14:37 hi zmatt . We talked about using OCMC RAM space for sharing data between PRU and ARM and you supplied me with some great piece of information. For my application i cannot use the UiO driver and even not the Remoteproc driver . What i am trying to do is write my own Loadable kernal module. So far what i have understood from the info you provided is that the base memory location is 40300000 and leaving aside the Jun 21 18:14:37 first 8KB i have 56KB left with me. I am thinking of using the ioremap function to get a virtual address and then manupulate the data. Jun 21 18:15:23 My question is regarding the compatibility tag in the device tree file do i need to write my drivers name there. Usually in case of other basic drivers i wrote i never required that Jun 21 18:15:46 but it is for the first time i am playing with the memory manupulation Jun 21 18:29:04 e Jun 21 18:50:44 deepankarmaithan: if you're writing a custom kernel driver then that changes everything Jun 21 18:53:37 deepankarmaithan: and for most kinds of driver you need some way for the kernel to know it needs to load your driver Jun 21 18:53:53 which, for platform devices declared in DT, is done using the compatible-tag Jun 21 18:54:27 (for usb devices it's done based on information from the device descriptor, PCI devices similarly embed identification, etc etc) Jun 21 18:58:26 normally for allocating physical memory for use with a hardware device (pru in this case) you'd use the dma memory allocation API, but that doesn't apply if you want to allocate it from ocmc Jun 21 18:59:24 ocmc is managed by the mmio-sram driver, which create a memory allocator (genpool) for it Jun 21 19:04:12 I'm not sure why, since it doesn't seem to expose any API for allocating memory from that pool Jun 21 19:05:44 which also explains why the two 4KB regions allocate from it for kernel use had to be declared in DT instead of just being dynamically allocated... since there's just no mechanism for dynamically allocating from it Jun 21 19:10:00 huh, or maybe there is Jun 21 19:12:34 of_gen_pool_get() Jun 21 19:12:47 the way it works is gross, but yeah there is an API Jun 21 19:14:38 okay I misread, the way it works is... okay I guess Jun 21 19:18:15 deepankarmaithan: so I think the proper way of allocating memory from ocmcram would be for your device to have a DT property that links to &ocmcram, then obtain its gen_pool using of_gen_pool_get(), and then allocate the memory you want from that Jun 21 19:18:55 using gen_pool_dma_alloc() Jun 21 22:01:10 zmatt Just a quick followup and thanks. Running an updated kernel fixed the issue. I've got both can channels showing up in candump Jun 21 22:07:27 \o/ **** ENDING LOGGING AT Mon Jun 22 02:59:57 2020