**** BEGIN LOGGING AT Tue Jan 15 02:59:58 2019 Jan 15 04:31:55 hey guys, I've been looking at the TRM for the beaglebone black. I'm trying to find out what addresses are reserved for peripherals. Would anyone know where I can find that info? Jan 15 04:32:36 The TRM for the chipset has info for the cache but not the RAM. I'm specifically looking for the addresses for the UART pins and where the end of the reserved memory Jan 15 04:32:40 Would appreciate any help :) Jan 15 04:33:53 For Rasperry Pi they have info for their BCM2837 board stating 0x3F to 0x3FF... are reserved for peripherals, sort of looking for that same info Jan 15 05:21:52 if anyone is around :) Jan 15 05:45:47 chaos_: I guess the question is which i2c bus Jan 15 05:47:10 For i2c it is chapter 7.11.1 I guess Jan 15 05:49:12 *i2c2 Jan 15 05:53:27 Humpelstilzchen: Sorry in what manual? The TRM for the AM335x doesn't have a 7.11.1 Jan 15 05:54:31 Asking as I am working on a custom kernel and need to know after what memory address I can load my code, and what address the UART registers are if that helps clarify anything Jan 15 05:57:58 chaos_: aah sorry I just did i2c stuff and was automatically on i2c adresses not memory adresses Jan 15 05:58:36 ah, no worries. Any idea where I could find the info I'm looking for? Jan 15 05:59:33 chaos_: no idea other then the dtc files Jan 15 06:00:48 dts Jan 15 06:05:41 I'm taking a look at the dts file that linux uses for the black, what would I be looking for to find the address after which the kernel is loaded? Jan 15 06:07:45 chaos_: thats u-boot configuration Jan 15 06:08:57 chaos_: btw you have seen the chapter memory map in the AM3358 TRM? Jan 15 06:09:46 Yea I wasn't sure what I was looking at (I'm not usually too close to the hardware, hence why I was asking for help). That looked like all CPU cache addresses so i wasn't sure if it related directly to the physical RAM addressing Jan 15 06:10:28 and I'm aware that it's u-boot configuration but it should specify where u-boot will load the kernel code right? I found the dts for the chip here if you know what I would be looking for: https://github.com/torvalds/linux/blob/v4.14/arch/arm/boot/dts/am33xx.dtsi Jan 15 06:13:20 chaos_: do you run your custom kernel on a custom board or the vanilla BBB? Jan 15 06:14:07 vanilla Jan 15 06:14:33 chaos_: then why not just use am335x-boneblack.dts Jan 15 06:15:53 That's fine but I still need to set a base address for the kernel that is outside the reserved memory zone Jan 15 06:16:06 Just trying to find that out in the dts or tech sheets Jan 15 06:16:21 I had found it pretty easily with the RPi3 but having a hard time finding it for the BBB Jan 15 06:19:42 the regular bone board seems to be defined as starting its addressing at 0x80000000 according to it's dts Jan 15 06:22:26 thats the starting addr of the sdram afaik Jan 15 06:24:58 https://github.com/torvalds/linux/blob/v4.14/arch/arm/boot/dts/am335x-bone-common.dtsi#L18 Jan 15 06:25:04 seems to be classed as memory Jan 15 06:25:14 but the BBB dts doesn't have a def like that from what i can tell that shows its 512mb Jan 15 06:33:41 chaos_: good question, am335x-som-common.dtsi has the 256 MB for the bb white, but I don't see the 512 of the black Jan 15 06:35:53 I give up for now haha. I guess I'll try taking a look again tomorrow Jan 15 06:35:57 Thanks for the help though Jan 15 08:09:29 what a confusing question Jan 15 09:38:21 Hallo,Is it possible to use other gpio pins of beaglebone black as PWM pins rather then that 14 PWM pin? Jan 15 10:21:42 Hallo,Is it possible to use other gpio pins of beaglebone black as PWM pins rather then that 14 PWM pin? Jan 15 11:02:51 Hello, has anyone experienced a connection getting detached from the board (beaglebone blue)? If so, how did you attach it back? Thanks! Jan 15 11:03:29 the UART UT0 plug got detached from the board by pulling the cable out Jan 15 11:03:53 Dj_: you'd have to re-solder it Jan 15 11:05:04 Thanks for your answer, kremlin :) but it looks like the solder won't work because the surface of the board where it got detached isn't shiny nor grey Jan 15 11:05:44 I wonder if it'd be ok to use the board anyways by using the UART UT1 instead of the UT0, in the long-term ... Jan 15 11:06:04 leaving the UT0 connection "broken" Jan 15 11:07:08 zmatt: check out my 'cape': https://ce.gl/a1.jpg https://ce.gl/a2.jpg Jan 15 11:07:13 Dj_: you lifted the solderpad? Jan 15 11:08:11 Yes, the 6 solderpads holding the UT0 connection got detached :/ Jan 15 11:08:34 uh oh Jan 15 11:08:42 uh oh .... is it that bad ? Jan 15 11:08:44 that's no good Jan 15 11:08:47 yeah, that's like Jan 15 11:08:50 new board bad Jan 15 11:09:10 So i shouldn't us the board at all? Jan 15 11:09:12 use* Jan 15 11:09:19 you can try Jan 15 11:09:24 if it boots you're probably OK Jan 15 11:09:45 it does, but I'm scared of long-term use of the BBB Jan 15 11:10:30 my guess is that it'll be fine if it boots Jan 15 11:10:42 so long as you've cleared away debris around the pads/etc Jan 15 11:10:52 thank you Krem :) Jan 15 11:10:58 npnp Jan 15 11:11:17 some metal "cable" from the board broke off a little Jan 15 11:11:34 my project partner used too much strength Jan 15 11:11:42 ;-; Jan 15 11:11:43 always fun Jan 15 11:11:57 have a nice day from Paris! Jan 15 11:12:48 you as well, from texas ;) Jan 15 11:18:26 Hallo,Is it possible to use other gpio pins of beaglebone black as PWM pins rather then that 14 PWM pin? Jan 15 11:18:53 Alex_: sure but you have to do all the bit-banging yourself Jan 15 11:19:04 there's no other PWMs besides what the docs list Jan 15 11:24:12 Hey, I'm back with another naive question: would it be a bad idea to glue the component with crazy glue where the board isn't supposed to have solder pads? Jan 15 11:24:37 not a great idea Jan 15 11:24:49 Mmmh, I thought so Jan 15 11:25:20 Thank you again :) Jan 15 11:25:26 npnp Jan 15 11:25:40 Dj_: if you really want to revive UART0, then find someone who knows how to rework a board Jan 15 11:26:06 I don't have one at hand to check how hard it would be to get to TX/RX (the only pins you really need) Jan 15 11:27:10 Hey tbr, thanks :) I will try to find someone who's good with boards if the UART1 gets ripped off by my partner haha Jan 15 11:27:31 It is quite fragile... Jan 15 11:28:19 step 1) don't let that person handle boards Jan 15 11:28:41 step 2) if he insists, see step 1) Jan 15 11:28:53 you're getting it! +1 Jan 15 11:29:08 Hahahaha Jan 15 11:29:15 Have a nice day too, tbr :) Jan 15 11:29:22 thanks you too Jan 15 11:29:30 thanks! Jan 15 11:58:56 hello, does anyone know where to get the TI pinmux tool files corresponding to the default configuration of the BeagleBoard x15? Jan 15 12:05:18 Erik__: https://docs.google.com/spreadsheets/d/1mSqEpV_BAUHfeNApytxHcGhgTZwypy564GyOr66Nphs/edit?usp=sharing Jan 15 12:07:50 Erik__: http://www.ti.com/tool/PINMUXTOOL not sure if that works with the X15 though Jan 15 12:08:00 thanks @wmat, I had seen that before but I didn't know how to use them in TI pinmux tool Jan 15 13:01:56 kremlin: it looks very retro :) Jan 15 13:02:21 kremlin: didn't end up going with topor I see ;) Jan 15 13:04:42 or is this still the old autorouted one? Jan 15 15:51:50 W/ the BBB, since it produces 3.3v logic out of the headers, would it be possible to add something to make the 3.3v logic at around 5.0v? Jan 15 15:52:06 level shifters Jan 15 15:52:12 level shifters! Jan 15 15:52:32 zmatt: You are a life saver. I am on the look-out for level shifters now. Jan 15 15:53:11 I got these items for machinekit, some drivers for the stepper motors. Jan 15 15:53:26 I wanted some extra oomph w/ my motors. Jan 15 15:55:00 I just went to DigiKey to look around, "Tariff Eligible." Jan 15 15:55:02 Ha! Jan 15 15:55:52 Are the BBBs having any trouble due to the Tariff stuff? Jan 15 15:56:14 parts comes to mind. Jan 15 16:10:01 what is the input signal on the BBB? Jan 15 16:10:55 CMOS? Jan 15 16:25:35 probably yes set_ Jan 15 16:25:57 probably schmitt triggers using cmos technology Jan 15 16:27:00 oh Jan 15 16:27:11 the bbb shows up as an usb ether_cdc gadget Jan 15 16:27:23 that can clear up my desk Jan 15 16:27:34 full of ethernet cables and usb-ttl adapters and power supplies Jan 15 16:30:21 m Jan 15 16:30:34 zmatt: yes :-) i am a sucker for PTH components Jan 15 16:30:40 and yeah i used a crappy autorouter for this Jan 15 16:30:42 FreeRouters Jan 15 16:31:11 a part of the LayoutEditor software suite (but i used kicad, only used the former for routing Jan 15 16:31:13 ) Jan 15 16:44:55 The SRM for the BBB does not show that CMOS tech. is around in the BBB except for the EEPROM register for Capes. Jan 15 16:48:38 Forget it. I just realized what that fellow wanted. Jan 15 17:29:23 hey guys Jan 15 17:30:06 with Debian 9 my mac don't match with the sticker on the beaglebone Jan 15 17:30:55 any of you have this issue too? Jan 15 17:38:23 you can set the mac to whatver you want otrab Jan 15 17:38:29 if you want to set it back to the sticker mac you can do it Jan 15 17:41:45 in debian 8 the mac is the same Jan 15 17:42:14 this is for production so I need to identify the beablebones by MAC Jan 15 17:45:20 I don't undertand why this script in Debian 8 set the MAC in the sticker but in Debian 9 set another MAC Jan 15 17:45:21 https://github.com/rcn-ee/repos/blob/master/bb-wl18xx-firmware/suite/stretch/debian/bb-wl18xx-wlan0 Jan 15 19:24:09 otrab: try to run the script manually (bash -x) and see where it fails. Jan 15 20:23:38 I am curious if anyone knows what is the future for BBB? It was launched in 2013 and now it is ~6 years old. At the same time, X15, launched in Nov 2015 is a different beast. Jan 15 20:24:26 So, will it be any BBB-2? Jan 15 20:57:41 there's a BBBlue - no onboard ethernet port but has wireless. Jan 15 20:58:21 but no update to the BBBlack as far as I know. Jan 15 20:59:22 the X15 costs $250.00 Jan 15 20:59:33 so me doubts it was meant to replace the BBB Jan 15 20:59:56 it's such a little horsepower board no wonder it costs beaucoup. Jan 15 21:00:05 dreamhiker: there is no official announcement on any Beagle forum about the future of BBB but the platform seems to track veeeeery closely with Texas Instruments "Sitara" processors. Whenever a new Sitara launches it seems like a new Beagle follows shortly thereafter Jan 15 21:00:24 i say this as a total Beagle n00b btw. Jan 15 21:01:38 sounds pretty on target actually. Jan 15 21:01:54 https://en.wikipedia.org/wiki/Sitara_ARM_Processor Jan 15 21:06:31 what is n00b ? Jan 15 21:06:39 newbie Jan 15 21:07:17 I only just got into Beagles this past October after 4+ years on Raspberry Pi for my various hobby projects Jan 15 21:14:35 Remember that BBB was shrunk into PocketBeagle a little over a year ago, so it stands to reason that, when some new silicon comes out, something like the X15 could be shrunk to the size of a BBB. I'm no mindreader but I'm sure the Beagle overlords have given that a good deal of thought Jan 15 23:20:03 mawk: Thank you for your reply. I was looking in the SRM instead of the TRM for the am335x chip. Jan 15 23:20:08 I was off base by a long shot. Jan 15 23:26:22 This was regarding the CMOS input from the BBB to another device. Jan 15 23:31:59 why do you say cmos input set_ ? Jan 15 23:32:07 cmos is just a technology for digital components Jan 15 23:32:10 it's not just for input Jan 15 23:32:27 the cmos technology is just a method of making the logic gates and drivers on silicon Jan 15 23:33:05 you also have logic using bipolar transistors, etc Jan 15 23:33:22 maybe you're talking about the usual voltage levels associated with CMOS ? Jan 15 23:33:34 0V to 3.3V or soemthing Jan 15 23:33:42 as opposed to 0V to 5V for TTL Jan 15 23:42:58 I had to buy a dc-dc converter or level shifter. Jan 15 23:43:48 For a specific type of level shifter, this fellow asked about what tech. the board had as input signals. Jan 15 23:45:04 I was messing around on the instant chat w/ DigiKey and the fellow behind the 'puter wanted the input signal. At the time, I was stumped. Jan 15 23:45:49 I saw that some level shifters have cmos tech. and there are other techs. for the level shifters. Jan 16 00:00:06 is linux-rt mandatory for bbb ? Jan 16 00:00:14 no Jan 16 00:00:18 right Jan 16 00:00:26 and can it be the source of issues with a device driver ? Jan 16 00:00:32 yes Jan 16 00:00:36 eg if it's not very popular so not much feedback Jan 16 00:00:36 ah Jan 16 00:00:43 I got my perfect culprit then Jan 16 00:00:46 realtime makes me think of the PRU Jan 16 00:00:53 which can be safely handled from a non-RTOS Jan 16 00:01:23 I'm trying to bisect my 6LoWPAN fragmentation issue Jan 16 00:01:33 let's try with a non-rt kernel first Jan 16 00:01:40 an rt kernel can easily expose flaws in device driver code, especially locking issuews Jan 16 00:02:04 yes Jan 16 00:02:10 the irqs can be preempted Jan 16 00:02:37 yup, in an rt kernel, your irq handler is actually a kernel thread Jan 16 00:03:17 and a "spinlock" is actually a priority-inheritance mutex Jan 16 00:08:39 I installed the non-rt version, let's see Jan 16 00:11:46 no still same thing Jan 16 00:12:10 on the BBB I have 4.14.91-ti-r90, on the RPi I have 4.14.79-v7+ Jan 16 00:12:41 let's debug the kernel module then Jan 16 00:12:49 I need to locate the bug Jan 16 00:12:57 either in 6LoWPAN, either in 802.15.4 Jan 16 01:09:46 howdy all Jan 16 01:09:50 anyone around? Jan 16 01:11:04 Me, I am here. Jan 16 01:11:11 What are you doing w/ your BBB? Jan 16 01:11:51 I am trying to get the PRU's up and running, but i have been hitting a bunch of hurdles and feel _really_ stuck Jan 16 01:12:15 Me too. I am sorry. There are other people here that can help more than I can in that dept. Jan 16 01:12:51 Are you using clpru or another form of compiler? Jan 16 01:14:03 yeah, clpru. I can compile the examples without issue, but I can't seem to get the PRU's themselves to boot Jan 16 01:14:30 Oh. Yea. Stick around. People know about PRU stuff here. It may take a while but they will come around. Jan 16 01:14:53 meawoppl: Sorry. I thought it was an easier question. Jan 16 01:15:20 I've never used the PRUs myself but just from reading thru docs I got the impression you need to mess around with device tree overlays to "turn them on" Jan 16 01:15:57 but I might be totally wrong on that. Jan 16 01:16:04 In all my reading, it suggets that `/sys/class/remoteproc/` should have 3 devices if successful Jan 16 01:16:29 @schibes I have tried a bunch of permutations, but there are lots of mixed/old/misleading docs around Jan 16 01:17:14 If you are running 4.14.x, you have to make sure your correct files are uncommented in /boot/uEnv.txt. Jan 16 01:17:49 I found that sometimes the 4.9.x kernel has the pru stuff in uEnv.txt commented out. Jan 16 01:18:06 comment = # Jan 16 01:18:44 Yeah, I have mucked through that game w/o success Jan 16 01:19:03 my assumption was to enable the rproc line that matched my `uname -a` kernel version Jan 16 01:19:06 http://processors.wiki.ti.com/index.php/PRU_Assembly_Instructions got updated in 2018. Jan 16 01:19:12 Right. Jan 16 01:20:07 So, if rproc_4.14.x and uname -r = 4.14.x, uncomment it. slash the # out. Jan 16 01:20:08 Right. Jan 16 01:20:47 My current state of that file is here: http://paste.debian.net/1060776/ Jan 16 01:20:53 I have some more links if they can help but I am a struggling PRU learner right now. Most of that Wiki or all it is now read only. Jan 16 01:21:20 TI.com did something recently w/ their wiki. Jan 16 01:22:16 do I need to set the dtb= to something? Jan 16 01:23:02 I am w/out knowledge in that dept. I thought once the software was typed up and able to be deployed, the correct compiler did the rest. Jan 16 01:23:20 https://markayoder.github.io/PRUCookbook/03details/details.html#_compiling_and_running is some ideas on this subject. Jan 16 01:29:47 Hmmm, this is helpful... I think Jan 16 01:30:15 when I chase into `/sys/devices/platform/ocp/` I don't have the expected file structure Jan 16 01:37:31 I know. I think they changed some files and dir. Jan 16 01:38:38 There are about 3 generations of changes that have happened here: uio -> rproc, 4.4.x -> 4.14.y, and then some changes in rproc itself? Jan 16 01:41:51 *confused* Jan 16 01:42:04 set_: What kernel version/image are you working with? Jan 16 01:42:21 4.14.x! Jan 16 01:43:02 Ditto Jan 16 01:43:10 I gave this version a run: http://paste.debian.net/1060778/ Jan 16 01:43:19 Does not seem to have worked :/ Jan 16 01:43:23 bbb.io/latest-images has an easy as pie rendition of IoT. Jan 16 01:43:33 Okay. Let me look at it. Jan 16 01:45:57 That is how my system looks for now. Jan 16 01:46:32 I would ask for a particular clpru command but that seems nosey to me. Jan 16 01:46:33 I am using the latest image from there too Jan 16 01:46:41 Okay. Me too. Jan 16 01:47:03 I can get the compiler to work ok, maybe I can at least help you with that bit Jan 16 01:47:06 Hold on. Let me look at what changed. Jan 16 01:47:32 I remember that you said the file structure was different. Jan 16 01:49:20 Hey meawoppl: Where have you been working from, i.e. what site or what info? Jan 16 01:49:24 yeah, the examples I can find suggest two different shapes of the filesystem, neither of which come true for me Jan 16 01:49:51 I looked at /sys/class/remoteproc. I have three lite blue files in there. Jan 16 01:50:04 I always thought I could write to these files. Nope. Jan 16 01:50:11 I don't Jan 16 01:50:16 special! Jan 16 01:50:19 they should be weird symlinked directories Jan 16 01:50:25 Oh. Jan 16 01:50:41 `remoteproc0`, `remoteproc1`, `remoteproc2` Jan 16 01:50:57 can you share what you did to get that far? Jan 16 01:51:04 cd /sys/class Jan 16 01:51:06 ls Jan 16 01:51:19 You can view them. they have other dir. and files in them. Jan 16 01:51:58 Is it normal for my PRU to be running right now? Jan 16 01:52:08 so those folders existed for you by default? Jan 16 01:52:17 Yep. Jan 16 01:52:28 I think I may have done a good job and not known about it. Jan 16 01:52:54 1 second, I have a fresh sd card I haven't futzed with yet Jan 16 01:52:57 let me check that one Jan 16 01:53:24 Okay. Jan 16 01:54:15 Why would async be disabled w/ PRU stuff from rproc? Jan 16 01:55:32 confirmed, on a fresh flash I don't have those devices Jan 16 01:55:41 womp womp Jan 16 01:55:54 must be busted on the wireless version Jan 16 01:56:46 I have wireless. Jan 16 01:56:51 https://elinux.org/Ti_AM33XX_PRUSSv2. Jan 16 01:57:46 Man, I hope TI comes back w/ some good wiki stuff. Jan 16 01:59:00 huh, I am having the same issue on the bbpocket I have here too Jan 16 02:00:31 set_: what are you saying about async? Jan 16 02:00:48 did you run any commands/enable any capes to get those directories to showup? Jan 16 02:01:27 It is disabled on my board for some reason. Jan 16 02:01:34 I do not think so. Jan 16 02:01:43 I did run some commands via clpru. Jan 16 02:01:50 Let me get the link. Jan 16 02:02:32 http://www.ti.com/lit/ug/spruhv7c/spruhv7c.pdf Jan 16 02:03:57 brb Jan 16 02:07:53 hermph Jan 16 02:08:10 set_: are you using the microsd image for IoT? Jan 16 02:08:53 Yes. Jan 16 02:08:53 words of wisdom from anyone with PRU experience would be helpful here Jan 16 02:09:02 interesting Jan 16 02:09:31 Hey meawoppl: Did you update your image on your eMMC yet? Jan 16 02:09:42 no, what does that entail? Jan 16 02:09:56 There is a way around it but you can update your eMMC to get the latest bootloader. Jan 16 02:10:12 S2 does it and so does erasing your eMMC. Jan 16 02:10:30 The bootloader is a big deal. Updates! Jan 16 02:10:47 I think my pru has been running this entire time. Jan 16 02:10:50 S2? Jan 16 02:10:55 I need to know how to stop it. Jan 16 02:10:55 the emcc is the onboard flash right? Jan 16 02:10:59 Yep. Jan 16 02:11:11 what is s2? Jan 16 02:11:30 S2 is the button for making the SD Card work out of the box. There is a better description but I am lacking in that dept. right now. Jan 16 02:11:41 I have been up to my neck in cross compiling. Jan 16 02:12:03 I will look it up. Jan 16 02:12:05 Please hold. Jan 16 02:12:53 Chip select. Jan 16 02:13:47 So, for instance, pushing the S2 button on the BBB will allow you to add the SD Card w/out any complaints from the eMMC, e.g. old bootloaders and other issues. Jan 16 02:14:54 Also, meawoppl: You may need specific headers to make your PRU realities come to light. Jan 16 02:15:05 set_: I have had a very easy time using the compiler _on_ the beaglebone, its already the right arch and configured Jan 16 02:15:15 Oh. Jan 16 02:15:43 (cross arch is always possible, but I have found it troublesome) Jan 16 02:15:47 So, the compiler compiles and whatever you want to happen, happens? Jan 16 02:15:56 yeah Jan 16 02:15:59 Cool! Jan 16 02:16:09 So, what are you trying to do w/ the BBB? Jan 16 02:16:24 I managed to get some pretty big libraries to compile on chip, including `numpy` and `ffi` Jan 16 02:16:33 Make motors move (very quickly) or communicate in a particular manner? Jan 16 02:16:37 Wozzers. Jan 16 02:17:01 I am making a wireless oscilloscope that sends the data in a pub-sub Jan 16 02:17:08 Oh. Jan 16 02:17:11 so I can use my cell or a laptop as an interface Jan 16 02:17:23 That sounds very complicated. Jan 16 02:17:47 its not too bad, I have the send/receive logic running cleanly which I thought would be the hard part Jan 16 02:17:48 Do you have your pub-sub already typed up? Jan 16 02:17:54 Oh. Jan 16 02:17:57 I got you. Jan 16 02:18:24 I am just trying to get a high-speed spi adc going based on strong example code Jan 16 02:18:26 which Jan 16 02:18:32 I wouldn't have thought was the hard part Jan 16 02:18:54 I shouldn't have used the "bone17" kernel, it would panic each time Jan 16 02:18:56 flashing the emcc now, does the tree overlay only take effect if you flash? Jan 16 02:19:04 (I think this was my source of misunderstanding) Jan 16 02:19:06 and I spent way too much time in the uboot console trying to boot the other kernel Jan 16 02:19:10 that thing is soooo lame Jan 16 02:19:24 grub it's a nice TUI with nice key bindings nicely explained that allows you to select the kernel Jan 16 02:19:55 and uboot it's a bunch of macros on top of macros running in an infinite-rows tty where you can't force line-wrapping so you can't edit anything larger than your screen Jan 16 02:20:11 grub! u-boot! Jan 16 02:20:28 That makes it way easier. Jan 16 02:20:33 less traffic. Jan 16 02:20:50 :( Jan 16 02:21:25 is there something in the -ti version kernel that could mess up a kernel module ? eg patches Jan 16 02:21:49 meawoppl: Hey. So, let me get this correct here. You typed up your software, typed up your clpru commands on the cmd line, and then ran the cmd. Then, everything worked out? Jan 16 02:22:41 Why are you looking for help if you have everything you want working? Additions or subtractions? Jan 16 02:23:08 you don't have to flash the emmc to apply overlays no meawoppl Jan 16 02:24:04 Overlays! Jan 16 02:24:25 no Jan 16 02:24:29 Oh and there is a PRU support software package. Jan 16 02:26:21 How can I get my PRU to stop running? Jan 16 02:27:01 w/ a command or do I need to type up "stop" software? Jan 16 02:30:01 so, I just my device to come up Jan 16 02:30:09 yay, I have the devices now Jan 16 02:30:34 let me see which of these structures matches the instruction I have been poking through Jan 16 02:31:03 Okay. Jan 16 02:33:37 alright, so there are a set of device interfaces in `/sys/class/remoteproc/` Jan 16 02:33:47 `remoteproc1` is one pru Jan 16 02:33:47 Right. Jan 16 02:33:53 `remoteproc2` is the other Jan 16 02:34:02 0 and 1, I thought. Jan 16 02:35:04 hmmm Jan 16 02:35:44 Let me reread the info. Hold please. Jan 16 02:37:24 I have no clue what pru2 would be besides them working together, reading/writing. Jan 16 02:37:39 B/c the core is 0 and 1. Jan 16 02:37:55 I am most likely wrong. Jan 16 02:38:04 I was thinking of cores. Jan 16 02:39:18 https://elinux.org/PRUSSv2_Memory_Map was something to view. I was thinking of cores and not rproc. Jan 16 02:40:02 I am not sure how to confirm that Jan 16 02:40:11 Hmm is right. Good question. Jan 16 02:40:23 I have been looking at examples from the discoverBB book (chapter 15) and this site: github.com/MarkAYoder/PRUCookbook Jan 16 02:40:30 How would we confirm that pru0 is related to rproc0. Jan 16 02:40:38 Okay. Jan 16 02:40:50 I have those resources. I can look through them. Jan 16 02:41:07 Ch. 15 is a place I have not visited yet. Jan 16 02:41:19 I usually work in books from start to finish. Jan 16 02:41:42 Some ideas fail. This is the case w/ books. Some ideas work and others do not. Jan 16 02:43:54 That is slave stuff. I am highly unfamiliar w/ slave address stuff. Jan 16 02:44:51 Ch. 15 goes into allowing us to know about remoteproc address stuff. But! It lets me know about how to stop the PRU! Jan 16 02:45:00 meawoppl: Thank you. Jan 16 02:45:10 https://github.com/derekmolloy/exploringBB/blob/version2/chp15/pru/blinkLED/Makefile Jan 16 02:45:15 is pretty helpful Jan 16 02:45:25 Oh. Okay. Thank you. Jan 16 02:45:30 The makefile shows how signaling and code upload work Jan 16 02:45:35 pru-led-blink Jan 16 02:46:18 Yea, in his managed file, pru0 = remoteproc1. Jan 16 02:46:52 Does it blink onboard LEDs or a RGB? Jan 16 02:48:07 So, we would not put in a file, like .c or .asm, to run the compiler and linker? Jan 16 02:48:17 Is that right/ Jan 16 02:48:18 ? Jan 16 02:48:55 yeah, in this example the compiled code is a `.c` file `blinkLED.c` Jan 16 02:49:10 Oh. Jan 16 02:49:27 So, on the command line, how would I go about proving this file true? Jan 16 02:50:04 so, in that directory I can just type make and the binaries endup in a folder called `gen` Jan 16 02:50:46 clpru blah.c -v options? Jan 16 02:50:48 Oh. Jan 16 02:51:25 So, he already did all the command line stuff in the file, i.e. like it is linked. Jan 16 02:51:48 You need a _ton_ of innane lib/import foolishness to make that part work, which is rolled up in the `Makefile` Jan 16 02:52:20 I haven't looked at the actual commands it is calling on the complier yet, as they seem to work ;p Jan 16 02:52:28 So, CFLAGS is the listed compiler? Jan 16 02:52:34 I have a lot of research to do. Jan 16 02:53:07 Yea. He has the compiler options and linker options but no file name. Jan 16 02:53:11 Odd. Jan 16 02:54:37 I found the file. So, w/out calling the file, somehow, there is a way to have them relate. Like you said, make. Jan 16 02:54:51 That is a big book by itself. Jan 16 02:56:25 Learning all things must take eternity. BBB! Jan 16 02:59:02 heh Jan 16 02:59:38 So looking at that and other examples **** ENDING LOGGING AT Wed Jan 16 02:59:56 2019