**** BEGIN LOGGING AT Sun May 03 02:59:57 2020 May 03 09:39:15 I must not understand you, but on windows 7, isn’t it enough to open putty and enter "ssh debian@192.168.7.2"? May 03 09:51:21 I could not solve my main problem, so I again have to ask for your help. Whatever example I try to load into the PRU and no matter how I configure the GPIO, the value on the pins does not change. In this case, the program in the PRU runs 100%, I see it through shared memory May 03 09:59:10 I tried to compile on BBB and on windows, disconnected hdim, audio and emmc, updated the distribution package, transferred it from sd to eMMC, but nothing changed. Only once I managed to turn on the blink on P9_30, but I can not repeat it. I did not understand why this worked then. I am tracking the gpio value with an oscilloscope. May 03 10:00:02 what else can I try, what parameters to check? May 03 10:02:23 Debian 10.3 Buster IoT Image 2020-04-27, BigleBone Black May 03 12:06:37 hi every one , i try to connect the BBB with Microcontroller via SPI protocol , May 03 12:08:07 i have a proplem ,when i use the spidev Mdoul , SPI test code , i get the output [0,0,0,0] if i try to send [1,2,3,5] May 03 12:08:54 can you help me ? May 03 12:20:56 try to start loopback May 03 12:21:04 https://gist.github.com/pdp7/33a8ad95efcbcc0fadc3f96a70d4b159 May 03 12:23:55 connect P9_18 and P9_21 (MOSI and MISO), then compile the program and execute it with the “-verbose" parameter May 03 12:27:58 P9_18 should be connec to P9_21 ? May 03 12:28:51 yes, MOSI to MISO May 03 12:28:53 maybe you are using the wrong SPI channel to which you are connected or the module driver is not working correctly May 03 12:31:41 p9_17 & P9_22 shoudl be free ? , how can execute it with the “-verbose" parameter ? May 03 12:33:11 oh yes, only for test P9_18 -- P9_21 May 03 12:33:54 it worked fine May 03 12:34:02 yes, p9_17 and p9_22 free for loopback May 03 12:34:06 the output is right May 03 12:34:48 input == output? May 03 12:34:52 but just Run without execute it with the “-verbose" parameter May 03 12:35:03 yes input == output May 03 12:43:28 Module connected p9_18 - MISO, p9_21 - MOSI and p9_22 - clk? May 03 12:45:09 now i connect just P9_18 with P9_21 May 03 12:47:58 yes, and it showed that spi bbb is able to work normally. You can also use this code if you have to write a device driver. but how was the module connected? May 03 12:49:58 p9_18 - MISO, p9_21 - MOSI and p9_22 - clk May 03 12:50:32 i did so May 03 12:54:44 then it looks like the problem is in the code that works with the module. most likely you did not pass initialization and therefore the module does not respond. see the documentation of your Module May 03 12:57:19 i have the same problem if i use the Spidev module or Adafruit_BBIO.SPI May 03 13:09:03 https://pastebin.com/nS6FELGH May 03 13:09:44 luna: this outlines a test I've performed that confirms spi working on the latest (2020) image May 03 13:11:19 modules on spi have a different protocol, the program from adafruit will not work with anything else. Although it seems like I misunderstood something about Spidev May 03 13:13:14 luna: perform a loopback test first (i.e. with P9.21 connected to P9.18). once that works you know spi itself is working and you can then focus on communication with your device May 03 13:13:32 kiba: what do you mean? May 03 13:15:18 zmatt : it works if i connect P9_18 to P9_21 , the output == input May 03 13:15:50 Yes, loopback test has already worked May 03 13:15:57 luna: ok, so you don't have any problem with spi itself May 03 13:16:27 beyond that the details of how to communicate with your device depend on the details of the device and what sort of transfers it is expecting May 03 13:16:49 (also be sure to select the correct spi mode (0-3) for your device) May 03 13:17:37 I'm just not familiar with Spidev and Adafruit May 03 13:18:20 they're just two different (but functionally equivalent) wrappers around the linux spidev interface May 03 13:19:23 which itself just lets you perform raw spi transfers May 03 13:19:56 so as long as you understand how spi itself works there's not much more to know about it May 03 13:20:08 zmatt : how can i select spi mode(0-3) ? May 03 13:20:12 (and spi itself is barely a protocol, there's not much to understand) May 03 13:20:23 luna: look at my examples, they set the mode to 3 May 03 13:20:31 "spi.mode = 3" May 03 13:21:25 zmatt : I'm just trying to check the communication between the BBB and a logic analyzer, if i send a backeg from BBB the logic analyzer has to get what BBB sent, May 03 13:22:26 yep, and since you've confirmed a loopback test works that means that if your logic analyzer isn't showing the right data then that's just a problem with your setup May 03 13:22:32 with the measurement I mean May 03 13:23:40 zmatt : usually when I send something I should see in the output, May 03 13:25:03 if you run the looback program with the analyzer connected, you should just see the data there May 03 13:25:08 note that the default clock frequency is 16 MHz if I remember correctly. if that's too high you'll need to lower that (Spidev has a "max_speed_hz" for that, Adafruit_SPI abbreviates it to "msh") May 03 13:25:37 and obviously you'll also see the data without the loopback wire, provided you're looking at MOSI May 03 13:29:48 zmatt, Do you have any ideas how to solve my problem? I wrote 4 hours ago May 03 13:31:22 kiba: your problem description seems vague... if you configure P9_30 to pruout mode using config-pin then you should be able to control it by toggling bit 2 of R30 on pru core 0 May 03 13:33:07 you don't need to meddle with any configuration for that, using P9_30 for pru does even not conflict with hdmi May 03 13:35:22 if you want to double-check your pin configuration just in case, you may find my show-pins utility useful: https://github.com/mvduin/bbb-pin-utils/#show-pins May 03 13:40:45 did I understand correctly that this should work? https://pastebin.com/c3ncaSQV May 03 13:43:12 you're toggling bit 1, not bit 2 May 03 13:43:34 (also there's no reason to enable the OCP master port for this program) May 03 13:44:52 other than that I don't see anything obvious wrong with it (but I personally never use C to program pru) May 03 13:50:18 in this case, P9_30 is gpio0_02? I always used this http://cholla.mmto.arizona.edu/bbb/2013/pinout1-1024x585.png May 03 13:50:53 gpio numbers are only relevant for gpio mode, not for pru mode May 03 13:50:54 I don’t seem to understand how it works. May 03 13:51:08 gpio and pru are different mux modes May 03 13:51:31 https://pastebin.com/zK85mXex is a list of all pruin/pruout pins May 03 13:51:53 oh that's how May 03 13:52:31 So in PRU, in principle, gpio are not relevant? May 03 13:53:11 gpio mode connects the pin to one of 32 pins of one of the four gpio controllers, e.g. P9_30 connects to gpio 16 of gpio controller 3 May 03 13:53:45 pruout mode connects the pin to one of the bits of R30 of one of the two pru cores May 03 13:54:01 the two have nothing to do with each other May 03 13:55:35 (it *is* possible for pru to access the gpio controllers and thus be able to access arbitrary pins configured in gpios mode, but it's much slower, significantly more complicated, and will introduce timing jitter) May 03 13:56:32 if you want a more detailed overview of all functions on the P9/P8 headers of the BBB, check out the "P9" and "P8" tabs of my spreadsheet: https://goo.gl/Jkcg0w May 03 13:57:02 what does the last column of numbers in the list of all pruin / pruout pins show? May 03 13:57:45 which bit of R30 (for pru out) / R31 (for pru in) it uses May 03 13:59:37 note that pru outputs and pru inputs are actually completely separate, so e.g. you can use P8.15 for pru 0 in 15 and simultaneously use P8.11 for pru 0 out 15 May 03 14:01:18 thank you very much, now it’s clear! May 03 14:03:55 Now I don’t fully understand just how r30 and r31 differ May 03 14:04:38 r30 is just a normal register you can read and modify, but its bits will also drive any configured pruout pins for that pru core May 03 14:05:42 r31 is not really a register, and reading and writing perform different actions: reading it returns the pru inputs in bits 0-16 and outputs 0-1 of the pruss interrupt controller in bits 30-31 May 03 14:06:16 writing r31 is used to send an event to the interrupt controller (used e.g. to wake up the other core or to wake up software on the cortex-a8) May 03 14:09:19 then r30 works with legs and r31 with interruptions May 03 14:10:18 no? May 03 14:10:45 I don't think you can summarize it shorter than what I just said May 03 14:11:22 if you don't care about interrupts, then: R30 controls pru outputs, reading R31 reads pru inputs May 03 14:12:20 (but R31 is also used to receive interrupt signals from and send events to the interrupt controller) May 03 14:16:52 I'm understood, thank you. When I need interruptions I will need TRM anyway, so I still read about r31 May 03 14:19:36 however, if I need mcSPI in the PRU, do I need to do something with r30? or is it enough to use config-pin? May 03 14:20:35 McSPI is again a different mux mode, separate from and unrelated to gpio and pruout/pruin May 03 14:21:00 note that using McSPI from pru is significantly more hassle than just making PRU generate the SPI protocol itself May 03 14:22:40 it is possible to do. you'll however also need a DT overlay that disables the linux kernel driver for the McSPI instance you want to use (since otherwise pru and the linux kernel will fight over the peripheral) while ensuring that the linux kernel will keep the module enabled for you May 03 14:25:36 I understand. Can't I enable mcSPI via PRU? set the clock, go through the initialization May 03 14:26:09 you'll _also_ need to McSPI yes May 03 14:26:30 however you'll still need to ensure you're not stepping on the toes of the linux kernel May 03 14:27:31 in particular you should avoid messing with power/clock management registers, those are managed by the kernel and it will get upset if it notices that settings are not the way it left them May 03 14:28:45 you could gamble on it not noticing, but it's better to just have it do its job but tell it to keep the module enabled for you May 03 14:29:19 oh lol, "you'll _also_ need to McSPI yes" should have been "you'll _also_ need to initialize McSPI yes" May 03 14:29:33 that sentence no verb May 03 14:32:15 ok, thanks May 03 14:34:32 you have clarified a lot, many thanks May 03 15:13:00 so, did anyone manage to get bluetooth working on the AI? May 03 16:24:23 I wasn't aware it had problems with bluetooth, but I haven't tried it May 03 16:31:02 neither on mine nor the default image which I downloaded this morning has it working May 03 16:32:59 Apparently I'm not the only one with bluetooth problems https://groups.google.com/forum/#!msg/beagleboard/ZDi-qD7nEAM/YsggTIquAgAJ May 03 16:39:07 I should note that hcitool/hciconfig are deprecated tools May 03 16:39:44 (though that's unlikely to be an issue here) May 03 16:44:07 jkridner: has bluetooth on the bbai ever been tested? because this does sound like it's simply not functional out of the box May 03 16:48:04 humpelstilzchen[: can you pastebin: journalctl -k | grep -iP 'br?cm|bluetooth' May 03 16:48:53 journalctl souds like a systemd command.. May 03 16:49:16 uhh yes, journalctl -k dumps the kernel log May 03 16:50:49 why? May 03 16:51:04 I'm not running systemd May 03 16:51:21 I can boot the default image for that but this will take some time May 03 16:52:29 obviously what is most important is that it works on the default image... getting it working on your systemdless custom system is your problem then :) May 03 16:52:49 but if you want just kernel log I can execute dmesg May 03 16:53:13 like I said I tested it on the default image this morning, did work on it May 03 16:53:37 did work on it? May 03 16:53:55 you said it didn't May 03 16:54:05 sorry did not May 03 16:55:56 I understand, but I still want to know the output on the default image, which at least I know is supposed to have the appropriate driver and firmware files installed May 03 16:58:39 I'm not sure if I could be helpful here anyway though, since I have nearly zero experience with bluetooth May 03 17:10:09 zmatt : I released the pins and did the code run, the output is [0.0.0], May 03 17:18:16 zmatt: https://paste.debian.net/1144610/ May 03 17:20:37 luna: okay, well then that's what it read from spi during the transfer (i.e. miso was low during all 24 clock cycles) May 03 17:21:57 humpelstilzchen[: okay that looks like it's not even detecting the existence of the bluetooth device... so that's even less than what some people in the forum thread reported May 03 17:22:19 luna: what result were you expecting and why? May 03 17:25:53 zmatt : I expected to see input == input because I am May 03 17:26:46 because you are... ? May 03 17:27:06 (also saying you're expecting "input == input" is a meaningless tautology) May 03 17:27:45 if a test with a loopback wire succeeds, then if connected to the actual device I feel pretty confident that [0,0,0] _is_ the actual input data May 03 17:29:25 but it's really unclear what your setup is, what you're testing, what results you are expecting, and why they differ from the actual results May 03 17:30:39 however I feel fully confident in saying that the steps I gave in my pastebin result in a correctly configured and fully working SPI interface. any issues beyond that must be specific to your hardware setup or the spi device you're trying to communicate with, and you haven't given any real details about that May 03 17:33:43 it's not even clear if by "output is [0,0,0]" what you're referring to. do you mean the result of spi.xfer() ? do you mean data received by your microcontroller? data viewed on a logic analyzer? May 03 17:34:05 I'm trying without connecting the pins, May 03 17:34:26 so how are you viewing the output? a logic analyzer? May 03 17:36:25 and why does it take so long to get any sort of answer for such basic questions? May 03 17:36:39 this is making it really tedious to try to help you May 03 17:37:25 if i connect logic analyser i have not respone May 03 17:37:57 the internet connection is bad sorry May 03 17:38:11 "response" ? a logic analyzer analyzes your signal, it doesn't give any response May 03 17:38:57 it dont see the data May 03 17:39:01 and since we know the BBB gives correct output (otherwise a loopback test would have failed), if you're not seeing the data you were expecting on your logic analyzer, the only possible conclusion is that you either hooked it up wrong or misconfigured the logic analyzer May 03 17:40:52 i will try to connect it with another BBB and send data to the other one , May 03 17:41:05 that's pretty much impossible May 03 17:41:17 it's very difficult to use a BBB as SPI slave May 03 17:41:33 the linux driver most certainly does not support it, it would require PRU software May 03 17:42:37 ok i will try to send t to the Raspberry , it should receive the data May 03 17:42:53 it's even harder to use an rpi as SPI slave May 03 17:43:31 SPI slaves have very strict real-time requirements, since they have no control over data flow May 03 17:44:34 I think you still have some deep misunderstandings about how SPI works May 03 17:45:47 the goal that i should send data from BBB to tms Microcontroller , May 03 17:46:30 it's usually easier to implement an SPI slave on microcontrollers yes May 03 17:46:45 the BBB screen should be the Master , and give the Micro the instructions May 03 17:47:31 it will still require careful implementation on the microcontroller, combined with making sure the BBB uses sufficiently low spi clock frequency May 03 17:47:46 ok , perfect , i will try it with microcontrollers May 03 17:48:48 How can i make that the BBB uses sufficiently low spi clock frequency? May 03 17:48:55 I told you that earlier May 03 17:48:58 spi.max_speed_hz May 03 17:49:03 ? May 03 17:49:30 15:25 <@zmatt> note that the default clock frequency is 16 MHz if I remember correctly. if that's too high you'll need to lower that (Spidev has a "max_speed_hz" for that, Adafruit_SPI abbreviates it to "msh") May 03 17:50:25 yes , i will try it with microcontroller , i hope i will work , May 03 17:50:40 well it sounds like you should first try to debug why your logic analyzer isn't working May 03 17:50:45 sorry i am beginner , thamks for your help May 03 17:50:57 because it would probably be useful to have a working logic analyzer to debug spi communication issues with your microcontroller May 03 17:51:47 right , i try to check the connection , May 03 17:51:54 a simple loopback wire from mosi (P9.18) to miso (P9.21) can serve as a substitute for a device during debugging May 03 17:52:39 spi.xfer() should then return the same data you gave it, which confirms data is in fact being transmitted and received May 03 17:52:39 How ? May 03 17:52:59 "can serve as a substitute for a device during debugging" !! May 03 17:53:53 because it results in known data being on both MISO and MOSI? allowing you to confirm that data is in fact being transmitted and being received May 03 17:54:34 right May 03 17:54:40 perfect May 03 17:54:45 if you connect the loopback wire and see spi.xfer([12,34,56]) returning [12,34,56] then you know for sure that this data is being transmitted and received May 03 17:55:25 so if the logic analyzer still disagrees at that point, the fault is 100% certain with the logic analyzer (most likely in its configuration or the way you connected it) May 03 17:56:48 right .. i will try it now , May 03 18:10:39 hey everybody , I bought new BB when I connected it with my laptop, first my pc knows the BB, now no longer, I connected in another computer, it didn't see the BB, I changed the cable, it doesn't work, can someone help me further? May 03 19:09:43 Is there an easy way to make it difficult to bypass eMMC boot, other than removing the S2 button? May 03 19:20:39 outrageous: prevent physical access May 03 19:21:34 bypassing eMMC boot isn't very hard even without the S2 button May 03 19:21:39 if you have physical access May 03 19:28:11 zmatt: Not very difficult no, but perhaps slightly more difficult than pressing S2. Am looking into encrypting home dir, I suppose that's more effective while slightly more inconvenient or complex to keep the device in operation. May 03 19:30:30 filesystem encryption can protect the eMMC contents but creates the problem of how to boot it May 03 19:31:12 (a dynamic root of trust could have solved that problem if TI had implemented one, which wouldn't have been very hard, but they didn't and there's no way to create one if it's not already there) May 03 19:38:32 zmatt: Indeed. In this particular case, I think encrypting only a certain home directory would be sufficient and shouldn't prevent booting, but would prevent automatic start of scripts and access to configuration files. Or that is what I am thinking at least. May 03 19:40:07 I'm not sure I see the utility of that but perhaps it does in whatever your specific situation is May 03 19:42:57 I can however tell you that securing a device like a beaglebone against someone with physical access is extremely difficult May 03 19:43:23 and preventing physical access should be regarded as the principal solution May 03 19:43:33 zmatt: It's the configuration files stored within the home dir that I'm concerned about not being accessible by someone. The rest is mostly stock. May 03 19:44:09 okay, but presumably the beaglebone needs access to them, otherwise why have them on the beaglebone in the first place? May 03 19:45:07 also, if someone has access to the system, they can compromise whatever you're doing on it anyway (e.g. exfiltrate the encryption key of the homedir the moment you enter it) May 03 19:46:04 basically you can try to create some minor roadblocks to keep out unmotivated people, but I wouldn't really call that security May 03 19:48:06 zmatt: Yes. Which would make the device require my attention upon reboot...but should otherwise work? I wouldn't call it security either, but it would make it more difficult and require slightly more knowledge. I do not think that people would go that far to gain access for the device in question :) May 03 19:52:21 zmatt: In any case, home dir encryption makes gaining access to the data significantly more complicated than pressing S2 and booting from microSD/USB/serial and then having full access. Not that I expect the risk with the S2 method to be very high, but perhaps slightly higher than I feel comfortable with. May 03 19:53:52 zmatt: Having said that, I appreciate your input. Thank you! May 03 20:57:50 Can I get some help? May 03 21:05:28 I need some help please May 03 21:39:15 zmatt: bt on bbai question? May 03 21:39:31 popped up, but haven't found it in the scrollback yet. May 03 21:39:38 something about if it was ever tested. May 03 21:39:59 yes. kept it communicating with crc checks constantly during CE testing. May 03 21:40:56 tested, but not specifically enabled out-of-the-box. May 03 22:11:53 jkridner[m]: it seemed like people had the bluetooth device not even showing up on latest image May 03 22:11:59 haven't tested it myself yet May 03 22:12:39 software update? probably didn't test it on the latest release at all. May 03 22:12:52 but, production should still be testing it. May 03 22:13:04 guess I need to check. **** ENDING LOGGING AT Mon May 04 02:59:57 2020