**** BEGIN LOGGING AT Fri Mar 16 03:00:02 2018 Mar 16 04:44:32 Hi all - do you know if any of the Beaglebone boards are made in USA? Mar 16 04:51:00 pocket Beagle...I am pretty sure. Mar 16 04:52:19 I was on this chat one day and this fellow came on. he stated that the PocketBeagle was produced in the states. Mar 16 04:52:39 ... Mar 16 04:52:54 Now...I have not ventured to their mfg. plant but I will take his word for it. Mar 16 04:54:51 digikey sells them. I am looking now to see if they state it. Mar 16 04:57:08 GHI... Mar 16 04:58:15 Mouser states that GHI is the mfg. or something like that... Mar 16 04:58:25 Yeah, I'm looking into GHI. Mar 16 04:58:30 Oh. Mar 16 04:58:38 You are a step ahead. Mar 16 04:58:58 I found nothing but a bunch of medical devices and insurance. Mar 16 04:59:09 I just checked an old Beaglebone Black box I had laying around - it says made in USA. I just don't know whether they're always that way, or if it's luck of the draw Mar 16 04:59:49 Good question. I am not 100% sure these days. I know that laws lack in that dept. at times (if you know the loopholes). Mar 16 05:00:00 ... Mar 16 05:00:42 I would keep looking but my browser keeps intergrating Medicare and medical devices. Mar 16 05:00:49 No! Mar 16 05:00:52 lol Mar 16 05:00:58 no worries, and thanks a lot for your help Mar 16 05:01:17 You are welcome. Mar 16 05:01:19 I have to speak to someone at GHI and find out just how much of it is made in the USA, or if they're just assembling components bought from China Mar 16 05:01:37 If I hear otherwise, i will send a note. Mar 16 05:01:44 sounds good. Thanks! Mar 16 05:01:48 Yep...sometimes it is just assembled in the USA. Mar 16 05:02:21 device mfg. is complicated. Luckily, I am not into law. Mar 16 08:08:33 I use a couple of pins of SYSBOOT for PWM and GPIO. As these are powered at the same time as the Beaglebone, the BBB (or BBW) will not bootup correct: only after disconnecting these pins the BB will boot. What is the way to use these pins and still have the BB booting from eMMC? Mar 16 08:09:08 (SYSBOOT pins are the LCD_DATA pins) Mar 16 08:09:53 See page 96/97 of the SRM. Mar 16 08:47:41 zmatt: sorry, had to leave yesterday. i read your answer about hdmi framer power consumption. Do you have an idea of the total power consumption of BBB when running with maximum system usage? Mar 16 09:20:35 good morning, I'm starting with a fresh BBG with latest debian 9.3 image. I've set dtb=am335x-bonegreen-overlay.dtb in uEnv.txt ... when I try to echo "cape-universala" > /sys/devices/platform/bone_capemgr/slots ......... I get: bash: echo: write error: File exists Mar 16 09:21:23 cat /sys/devices/platform/bone_capemgr/slots .... only shows 4 lines : "PF---- -1" Mar 16 09:21:47 any idea what I'm doing wrong ? Mar 16 09:22:12 dmesg shows ..... Mar 16 09:22:18 OF: changeset: add_property failed @/__symbols__/pruss Mar 16 09:22:25 OF: Error applying changeset (-17) Mar 16 10:14:41 deeLer: The userspace capemgr/slots thing is no longer enabled by default in the latest image Mar 16 10:15:06 deeLer: The new approach is to let uboot merge overlays and pass the result to the kernel Mar 16 10:15:33 deeLer: You can still make the old approach work by disabling uboot overlays, I think, but there might be some bitrot in there already Mar 16 10:16:14 deeLer: However, by default, uboot overlays and the universal cape are enabled (unless you have an actual cape installed, or an overlay loaded by uboot through uEnv.txt, then the universal overlay gets disabled). Mar 16 10:17:49 blathijs_: thank you for answering; i'm not so familiar with 'uboot overlays' ... is there a documentation you can point me out, how to do this the new way ? By the way, I have no real cape, I just want to use my BBG with 65 GPIO mode , direcly on the pins Mar 16 10:22:37 deeLer: I think docs are lacking, there is a wiki page, but it is not really helpful. But as I said, the default configuration should give you a working universal cape and config-pin. Mar 16 10:24:00 blathijs_: thank, i'll play around with the uEnv file then. is there also an universala (with the 'a') available using this method ??? because the standard universal cape still has the emmc pins instead of gpio Mar 16 10:27:33 deeLer: Ah, there is a disabe_emmc_overlay or something similar in uEnv Mar 16 10:27:49 blathijs_: cool, i'll give it a try Mar 16 11:17:11 blathijs_: I've don't have much luck with the overlays Mar 16 11:17:28 can you show me your uEnv file? Mar 16 11:31:05 deeLer: latest image has cape-universal enabled by default Mar 16 11:32:17 deeLer: and runtime overlays (hence bone_capemgr) are deprecated, they've been replaced by u-boot overlays Mar 16 11:32:32 oh wait blathijs_ already said that Mar 16 11:32:37 sorry, I'm not awake yet Mar 16 11:33:45 :-) Mar 16 11:34:04 deeLer: Mine is modified, and I don't have it at hand, sorry. Mar 16 11:34:23 johanhenselmans: you need to make sure these pins are pulled in the right direction during power-up. there are on-board 100K resistors for that, but external load can mess that up Mar 16 11:35:12 okay, this is what i have now ; https://pastebin.com/BSJZuL3m Mar 16 11:35:36 but when i'm trying 'config-pin -a p8-25 in+ ' says : P8_25 pinmux file not found! Pin has no cape: P8_25 Mar 16 11:35:39 johanhenselmans: pins 32, 33, 35, 39, 40, 45, and 46 of P8 must be low during power-up Mar 16 11:36:07 johanhenselmans: pins 31, 41, 43, and 44 must be high (pulled up to 3.3v) during power-up Mar 16 11:36:32 deeLer: are you booting from sd card or eMMC ? Mar 16 11:36:45 zmatt: SD Mar 16 11:37:56 oh right, that's an eMMC pin. 1. wipe eMMC to ensure it will load u-boot from SD card instead of loading an old one from eMMC 2. uncomment the disable_uboot_overlay_emmc=1 Mar 16 11:38:37 wiping woudl be then dd if=/dev/zero of=/dev/ ???? Mar 16 11:38:44 blkdiscard /dev/mmcblk1 Mar 16 11:39:22 zmatt: ok, running now Mar 16 11:39:48 i didn't realize it woudl still get it's uEnv from emmc .... Mar 16 11:40:15 ok, rebooting now Mar 16 11:40:44 also, if you intend to use both P8.20 and P8.21 for gpio, make sure to enable the reset pin of the eMMC (this is OTP config of the eMMC, use mmc-utils) and double-check that it's being held low once you use disable_uboot_overlay_emmc=1 Mar 16 11:42:12 (you can check that e.g. with my show-pins script; show-pins -v | grep 'eMMC reset' ) Mar 16 11:43:23 microdevel1: no, not really sure. there are some upper limits on current draw from various power supplies of the processor specified, but it's not realistic to be hitting those sustained Mar 16 11:43:29 okay ... learning again Mar 16 11:44:12 zmatt: config-pin works now ! had to clear emmc Mar 16 11:44:21 thank you Mar 16 11:44:24 microdevel1: but since there are so many different components that consume power, and there's aggressive clock-gating all over the place, it would be hard to figure out a worst-case system load Mar 16 11:45:17 zmatt: my maximum measurement input current @5V is approx. 470mA for the beaglebone black running hdmi kernel. is this what you would expect? Mar 16 11:45:19 deeLer: it doesn't load uEnv.txt from eMMC, just u-boot itself Mar 16 11:45:47 ok Mar 16 11:46:00 SRM says so but i was wondering if it could be any higher. have to check for dimensions of my power supply Mar 16 11:46:02 can I apt-get these mmc-utils? Mar 16 11:46:32 deeLer: yup Mar 16 11:46:53 cool Mar 16 11:47:33 microdevel1: is this while running something that causes both high cpu load as well as sustained ddr3 and eMMC activity? are you using the gpu? Mar 16 11:47:58 (where this high cpu load should also exercise the NEON unit of course) Mar 16 11:48:32 i was running 6 instances of glxgears and youtube in browser at the same time Mar 16 11:48:40 system was hardly responding =) Mar 16 11:48:47 ok so you're not using the gpu Mar 16 11:48:59 glxgears uses gpu? Mar 16 11:49:06 gpu drivers don't support x11 Mar 16 11:49:11 ohh Mar 16 11:49:21 you're doing software rendering Mar 16 11:49:48 so there's no driver that supports hardware rendering? Mar 16 11:50:33 there are, but not installed by default, and they only support openGL ES and ES 2, either without any windowing system (DRM or GBM backends) or using Wayland Mar 16 11:50:48 (never tried Wayland myself) Mar 16 11:51:25 zmatt: like this then ? mmc hwreset enable /dev/mmcblk1 ? Mar 16 11:52:39 sounds good Mar 16 11:53:36 oh, wasn't aware of that. there are guys that play 3d games on bbb - do they just use software rendering? Mar 16 11:53:57 root@beaglebone:~# mmc hwreset enable /dev/mmcblk1 open: No such file or directory Mar 16 11:54:13 microdevel1: anyway, it sounds like you definitely exercised the cpu, probably NEON assuming mesa and the video codec are decently optimized, and probably fair ddr3 access, some ethernet traffic. but no gpu and probably no eMMC writes Mar 16 11:54:26 microdevel1: playing 3d games on the bbb sounds very painful Mar 16 11:54:48 microdevel1: it's not a particularly powerful gpu. it's meant for shiny user interfaces, not gaming :) Mar 16 11:55:06 deeLer: you disabled eMMC access via uEnv.txt remember :) Mar 16 11:55:18 deeLer: you need to temporarily enable it to be able to use mmc-utils Mar 16 11:55:25 zmatt: right ! :) Mar 16 11:55:51 zmatt: they seem to run it on android https://www.youtube.com/watch?v=U4P_s-7dDRQ Mar 16 11:56:28 I think android may be the main reason to include a gpu in the first place Mar 16 11:57:19 oh that actually still looks like it performs surprisingly decent Mar 16 11:58:51 yeah i guess it does Mar 16 11:59:12 ok according to datasheet max eMMC power consumption is 200mA Mar 16 11:59:35 and everything on 3.3v is powered via LDO, so that just becomes 200 mA on 5V Mar 16 12:00:10 but what power will GPU need additionally? Mar 16 12:00:36 have you checked the am335x datasheet? I know it has some information about power consumption Mar 16 12:00:51 will do now Mar 16 12:01:04 tsk, should have been step 1 before asking Mar 16 12:03:05 is reducing power consumption a concern btw, or are you just trying to figure out the power budget to design the supply ? Mar 16 12:04:13 I guess the latter Mar 16 12:04:40 Hey zmatt! You helped me a few weeks ago with reading a "SPI esque" data bus on the AD7779 ADC. https://pasteboard.co/Hc9Z7Zb.png Mar 16 12:05:17 You helped me to the point I was able to read 1 data line out without running out of clock cycles. Now I'm trying to read all 4 data lines. Mar 16 12:05:51 you were using C instead of asm right, if I remember correctly? Mar 16 12:05:56 At first I tried just performing 4 reads of the __R31 register, but then I started running out of clock cycles. Mar 16 12:05:59 Correct! Mar 16 12:06:33 So my hack to get around this was to read the entire __R31 register with each clock pulse and store it in an array. Mar 16 12:07:05 why would you read it more than once per clock cycle? you actually want to sample all the data lines simultaneously, not sequentially Mar 16 12:07:12 zmatt: you're right. yes, just for dimensions of the power supply Mar 16 12:07:16 Even though I only need to read the 4 data lines. Mar 16 12:07:37 do you know what is meant by "Maximum current rating for the MPU domain; Nitro" Mar 16 12:07:39 I want to sample them simultaneousley you are correct. Mar 16 12:07:47 microdevel1: nitro = 1 GHz Mar 16 12:08:30 have no idea about clocking on BBB, will it run in 1GHz mode? Mar 16 12:09:05 microdevel1: yes. see cpufreq-info Mar 16 12:09:34 Guest41719: do you remember approximately when it was that we last spoke? Mar 16 12:09:39 ok so my supply must be a lot bigger. nitro requires 1A of current Mar 16 12:09:48 microdevel1: 1A on 1.35V Mar 16 12:09:56 this one is supplied by switching power supply Mar 16 12:10:01 Yes, one second Mar 16 12:10:18 microdevel1: so that becomes 270 mA @ 5V Mar 16 12:10:31 plus a little for overhead (but iirc the pmic's efficiency is pretty good) Mar 16 12:11:36 Fri, Feb 16 is when we talked Mar 16 12:12:09 zmatt: that permanent reset of the emmc, coudl that also have an effect on pin p8-25 (gpio32) . I'm havin a weird issue when suddenly that pin becomes active output 3.3V , even though it's set to input .... I haven't been able to figure out when that suddenly happens, but it's been pulling my hair out Mar 16 12:13:08 zmatt: unfortunately theres no info about consumption of GPU Mar 16 12:13:47 This is a link to my current code: https://pastebucket.com/565702 Mar 16 12:14:54 microdevel1: but there is a spec for vdd_core right? Mar 16 12:15:31 zmatt: found something interesting from ti: http://processors.wiki.ti.com/images/0/02/AM335x_PowerConsumptionSummary_20130515.zip Mar 16 12:15:44 let me dig into that Mar 16 12:16:01 Guest41719: ah, I remembered I played a bit with your code to see what seems to give decent output by clpru... I found this lying around in a directory: https://pastebin.com/UDHCXZmm Mar 16 12:17:22 Exactly, that's me! Mar 16 12:18:15 zmatt: this is pretty much the perfect answer http://processors.wiki.ti.com/index.php/Processor_SDK_Linux_Kernel_Performance_Guide#Power_Management Mar 16 12:19:11 So if I remember correctly, I tried that code snippet you just pasted and all of the left shifting and bitwise operations made me run out of clock cycles. It worked for 1 data line, but when I added the other 3 I started missing things. Mar 16 12:20:23 Guest41719: the compiler seems to give pretty decent output for it: https://pastebin.com/raw/xGJB10db Mar 16 12:20:30 zmatt: for me as an idiot :D if the power indication is in mW, do i have to care about switching and ldo? i was thinking that power stays the same? Mar 16 12:21:14 Let me run the code on my hardware, one sec Mar 16 12:21:22 Guest41719: I think this should work up to 10 MHz or so? Mar 16 12:22:15 microdevel1: for 1.8V and lower voltage (mpu, core, ddr) supplies, switching power supplies are used hence consumption in mW is relevant Mar 16 12:22:33 microdevel1: for 3.3V stuff, LDOs are used hence current in mA is relevant Mar 16 12:23:14 thanks Mar 16 12:40:56 Guest41719: your seconds are pretty long ;) Mar 16 12:41:02 I'm about to be afk Mar 16 12:46:24 Lol, Mar 16 12:46:34 I'm haivng more issues. Mar 16 12:47:42 I just noticed my code is missing an out_reg toggle Mar 16 12:48:17 I think? Mar 16 12:48:34 Ok, I don't think that's it. Mar 16 12:48:55 or is T0 only supposed to toggle once per clock cycle? Mar 16 12:49:18 Doesn't matter, it was just for debugging Mar 16 12:49:23 ah ok Mar 16 12:50:39 Why isn't the compiler ok with for (unsigned i=0; i<32; i++) // loop through first 32 bits (bits 0-31, CH0, bits 32-63 CH1) Mar 16 12:50:59 It want's me to declare i first outside of the for loop. Mar 16 12:51:08 I thought inside of the loop was fine. Mar 16 12:51:19 I mean at the beginning. Mar 16 12:52:15 ZMATT, what are the chances you will be on again later today? Mar 16 12:52:48 compiler settings probably Mar 16 12:52:57 Ok Mar 16 12:53:06 also, I use .cc sources rather than .c Mar 16 12:53:27 but I think you can make it less fussy for c code as well Mar 16 12:53:30 iirc Mar 16 12:53:41 and I'm probably around now and then Mar 16 12:55:49 Ok! Just curious, what is your story, how did you get so good at beaglebone? Mar 16 12:56:22 we use 'em at work Mar 16 12:56:41 Where do you work if you don't mind me asking? Mar 16 12:56:59 dutchdutch.com Mar 16 12:57:51 Cool! Mar 16 12:58:45 (and also some work for hamwells.com) Mar 16 13:00:35 Cool! Those are very different. :) Mar 16 13:01:55 yes, but we actually spawned from the same company... it's complicated ;) Mar 16 13:03:26 Could you email me at long.hw@gmail.com? I might have a few more questions and I will seriously send you $20 for your help. It's totally worth it because it takes me hours to figure out some of these things on my own. Just an offer, take it or leave it :) Mar 16 13:03:54 nah, just ask questions here and if you're lucky you get answers Mar 16 13:04:03 :) Mar 16 13:04:15 :) ok that sounds good to me. Mar 16 13:04:30 I hate hogging the channel though :) Mar 16 13:05:18 in what sense do you think you're "hogging" the channel? it's not like other people can't ask questions Mar 16 13:05:36 hi Mar 16 13:05:38 also, maybe consider picking a nickname that's not Guest41719 ... use /nick whatever Mar 16 13:06:08 anyway, I was heading afk Mar 16 13:06:11 Ok, I've never used IRC before Mar 16 13:06:16 is beagle board looking into alternate human-to-computer interfaces like voice or anything else? Mar 16 13:06:46 sorry, i am a bachelor student trying to get my proposal accepted for gsoc Mar 16 13:07:00 i forgot to introduce myself Mar 16 13:07:09 there's a channel for gsoc, #beagle-gsoc Mar 16 13:07:23 thanks Mar 16 13:52:32 /msg NickServ VERIFY REGISTER hunter235711 amkjjuzesytd Mar 16 13:54:23 So this code: https://pastebin.com/R36SdUty Mar 16 13:54:55 Produces this output: https://pasteboard.co/HcaIqts.png Mar 16 13:55:44 I'm using T0 and T1 on the logic analyzer for debugging. Mar 16 13:56:19 Each time that the code receives a bit it toggles T0, and this makes it evident that it is too slow. Mar 16 14:01:17 If I comment out lines so that I am only reading channel 0 and channel 1 it is fast enough and I get the following: https://pasteboard.co/HcaKLMr.png Mar 16 14:24:00 zmatt: interested in mentoring GSoC this year? Mar 16 14:35:30 hunter235711: that looks like it's waaaaay too slow, while Mar 16 14:36:09 hunter235711: disassemble the code using dispru or add the -k option to clpru to make it retain its assembly output Mar 16 14:36:21 I think it's doing something stupid Mar 16 14:37:22 e.g. poor optimization Mar 16 14:42:22 Ok, I've printed out the assembley. Mar 16 14:42:30 I'll add it here Mar 16 14:43:57 https://pastebin.com/JHJT1MkR <- the ASM Mar 16 14:44:37 I'm going through line through line, looking what each command does. Never done ASM before. Mar 16 14:44:52 it's doing stupid things Mar 16 14:45:01 you probably have optimization disabled or something Mar 16 14:45:59 Here's my makefile where you can see all of the compiler flags I use: https://pastebin.com/iCrnavAN Mar 16 14:46:20 CFLAGS=-v3 -O2 --endian=little --hardware_mac=on --keep_asm Mar 16 14:47:06 also you've changed my code by moving the left-shifts up Mar 16 14:47:13 that will reduce the max frequency it supports Mar 16 14:47:35 Yeah, I thought since it is waiting any way, might as well do some work before it waits. Mar 16 14:47:42 I was hoping for a speed up Mar 16 14:47:55 that's exactly why I placed my shifts in the spot I placed them Mar 16 14:48:34 I put part of the work (left-shift) during the clock-low period and part of the work (conditional-or) during the clock-high period Mar 16 14:49:39 that's not the core problem though Mar 16 14:49:52 here's the main loop of your version with spam removed: https://pastebin.com/raw/6Tk7XmJm Mar 16 14:49:57 Oh yeah, I had that backwards Mar 16 14:50:01 here's what I got as output: https://pastebin.com/raw/xGJB10db Mar 16 14:50:30 yours is loading each data[] element from memory before each operation and storing it back after each operation Mar 16 14:50:33 mine is keeping them in register Mar 16 14:51:10 so either you marked data[] as volatile, or there's a difference in compiler flags Mar 16 14:51:29 No, I have uint32_t data[8] = {0, 0, 0, 0, 0, 0, 0, 0}; Mar 16 14:52:28 Here is my most recent c code (I just put the shifts back where you had them): https://pastebin.com/Ycxa2EKf Mar 16 14:52:46 btw, this is why I would use assembly instead of C for something as timing-critical as this. there's nothing you can do in your source code to ensure a working program, since you critically depend on the quality of the code produced by the compiler Mar 16 14:53:11 Is -O2 the correct optimization level to use? Should I increase it (or decrease it)? Mar 16 14:53:16 using a different compiler version or different flags turns a working program into a broken one Mar 16 14:53:24 I'm pretty sure -O2 should be fine, so it must be something else Mar 16 14:54:04 Good point, I've just never used ASM before. Mar 16 14:54:43 it's not that different from what you're doing in C... mostly just more verbose syntax, and no types :) Mar 16 14:55:15 mov r0, r31 means r0 = r31; Mar 16 14:55:30 lsl r1, r1, 0x01 means r1 = r1 << 1; Mar 16 14:55:32 etc Mar 16 14:56:09 ok, thats not too bad Mar 16 14:57:04 qbbc label, r0, 2 means if( !( r0 & 1 << 2 ) ) goto label; (Branch if Bit is Clear) Mar 16 14:57:49 brb Mar 16 14:57:57 Although, after I get this data into the PRU I'm going to want to send it to the ARM so that people in Linux Userspace can use it. I was thinking of doing something similar to this: http://credentiality2.blogspot.com/2015/09/beaglebone-pru-ddr-memory-access.html Mar 16 14:59:19 Where the PRU writes to system DDR memory Mar 16 14:59:43 I was going to say that sounds too complicated for ASM, but I see that actually that is what is used in the post. Mar 16 15:03:28 Although is now obsolete (as far as the Linux side goes) Mar 16 15:06:53 Anyway, thats off topic. I think I can figure out the ASM commands, looks like when I make an ASM file I need to put .origin 0 .entrypoint TOP as the first two lines and end with HALT Mar 16 15:11:58 Hello ! Mar 16 15:21:41 analogWrite() does not seem to have an effect on PWM frequency. It is always 2khz. Why is that? Mar 16 15:24:02 badfrogg: When you first use it, how do you specify the frequency? Mar 16 15:24:11 badfrogg: what version of the BoneScript library are you using? 0.6.3 I hope. Mar 16 15:24:58 why would it have an effect on pwm frequency? it should adjust the duty cycle Mar 16 15:25:13 it is completely normal that the pwm frequency is fixed Mar 16 15:27:02 hunter235711: prussdrv is kinda ugly, I still kind of want to make a nicer C/C++ library for uio-pruss Mar 16 15:27:28 more like my python lib for uio-pruss Mar 16 15:28:05 interaction via shared memory is easier with uio-pruss than with remoteproc-pru, and it poses no complication whatsoever on the pru side Mar 16 15:28:05 Yeah, well isn't prussdrv not used any more since clpru came along? Mar 16 15:28:34 not everyone cares about clpru Mar 16 15:29:36 Yeah, it is confusing because the switch must have happened very recently. Almost all of the resources online use prussdrv and it isn't apparently what TI reccomends anymore. Mar 16 15:29:36 but yeah, clpru produces ELF executables for which prussdrv doesn't have a loader... it's not particularly hard to load ELF executables though so I'll probably write one eventually Mar 16 15:30:20 I don't like remoteproc-pru myself though... it seems to offer less functionality and require more complication Mar 16 15:30:47 it might be good if you want PRU code to cooperate with linux kernel code Mar 16 15:30:51 dunno Mar 16 15:31:05 I generally don't write kernel code unless I have to :) Mar 16 15:31:19 Lol, yeah. Mar 16 15:31:25 zmatt, what compiler flags did you use? Shouldn't we get the same ASM if we are both using the same flags? How did you generate your faster ASM where it keeps each data[] element in a register? Mar 16 15:31:45 Why is your ASM so much nicer? Mar 16 15:32:36 here's my makefile: https://pastebin.com/2puEgqqB Mar 16 15:34:48 What does CL += --gcc do? Is it using the gcc compiler? I thought CLPRU was a c compiler? Mar 16 15:35:55 no, it makes clpru accept some gcc syntax extensions to the C language Mar 16 15:36:09 The parameters for analogwrite() are pin,duty,freq,callback - but setting freq does not change anything Mar 16 15:36:56 Got it Mar 16 15:38:24 badfrogg: hm, looks indeed as if it ought to support it Mar 16 15:39:35 and you're not getting any errors? Mar 16 15:40:42 also beware that the a and b outputs of each ehrpwm instance share the same pwm frequency, so setting the frequency on one of these will fail if the other one is enabled Mar 16 15:40:42 I just got a big speedup. I changed where I declare data[] https://pastebin.com/je5zyHJn Mar 16 15:41:05 hunter235711: WHAT Mar 16 15:41:08 lol Mar 16 15:41:22 that's ... Mar 16 15:41:37 I haven't looked at ASM yet, but the logic analyzer showed it is now keeping up Mar 16 15:42:49 so, this is an excellent reminder of why I'm not hugely inclined to use clpru :P Mar 16 15:43:00 god it can do such dumb things Mar 16 15:43:52 like, being able to keep elements of a global array in register but failing to do the same for a local array is... fascinating Mar 16 15:45:26 https://pasteboard.co/Hcbre6Z.png <- proof's in the pudding Mar 16 15:48:54 I don't think I've ever found a proof in a pudding Mar 16 15:51:53 untill now Mar 16 15:52:47 So now that that is working, do you know of any easy ways to get this data into ram? Mar 16 15:54:11 I'm taking samples at 8khz, so the PRU has a lot of down time where it can move data into ram: https://pasteboard.co/HcbuS65.png Mar 16 15:54:53 in asm you'd just store it to ram Mar 16 15:55:39 like what was happening already in C, except only at the end of the transfer (and to a fixed location so you know where to find it) Mar 16 15:55:41 Is that the PRU shared ram? Mar 16 15:55:54 any of the pru local memories Mar 16 15:56:07 Can the pru write directly to the system RAM? Mar 16 15:56:08 probably just the pru core's own data ram since it requires the least effort Mar 16 15:56:21 yes but that's more effort for all parties involved, and much slower Mar 16 15:56:26 well, writes aren't slower I guess Mar 16 15:57:17 My problem is that at 8CH, 24bit/sample, 8k samples/second the 8k of PRU ram fills up really quick. Mar 16 15:57:25 I think the shared ram is 12k Mar 16 15:57:31 ah right you produce a stream of data Mar 16 15:57:50 although, that doesn't really matter since you're not sampling fast Mar 16 15:59:39 12KB / (8 words * 4 bytes * 8 kHz) = 48 ms Mar 16 16:00:55 exactly, and I don't want to drop any samples. Mar 16 16:00:56 if you're not careless, a userspace process shouldn't get randomly delayed by that much even on a non-RT kernel Mar 16 16:06:17 When you say it's hard to write to Linux RAM, how much harder? Conceptually it doesn't seem very different. Mar 16 16:07:00 It just seems nice to have a little more time than 48ms, like if the user wants to process the data a little bit. Mar 16 16:08:13 nah, it doesn't matter that much Mar 16 16:08:18 synchronization may be slightly trickier Mar 16 16:08:28 i.e. knowing when data has arrived in ram Mar 16 16:09:05 You mean that writing to PRU internal RAM should work fine Mar 16 16:09:08 although that should be solved if you also keep the buffer pointers in ram Mar 16 16:09:12 in the same ram I mean Mar 16 16:09:56 I actually have a python example that exchanges data via ddr memory -> https://github.com/mvduin/py-uio/blob/master/pruss-ddr-ping.py Mar 16 16:10:22 maybe I should extend it to send and receive values via two ringbuffers Mar 16 16:10:30 dunno Mar 16 16:11:05 Does DDR memory refer specifically to the Linux side, or is DDR also the shared PRU ram? Mar 16 16:11:56 ddr refers to the external ddr3 memory, specifically the chunk of it that has been allocated by the uio-pruss driver for use by pru Mar 16 16:12:28 "shared pru ram" generally is used to refer to one of the SRAMs embedded in the pru subsystem Mar 16 16:13:46 Ok, so you are saying that it won't be too hard to write to DDR3 and that it would mean I don't have to check the SRAM in the PRU every 48ms? Mar 16 16:14:13 correct Mar 16 16:14:20 Cool! Mar 16 16:16:18 for synchronization, have pru write the buffer pointer to somewhere in the same ram as the data (i.e. also in ddr when using ddr for the buffer) Mar 16 16:16:18 In your file you have: from ti.icss import Icss, is this a library that you wrote? I didn't know TI had any Python code. Mar 16 16:16:33 it's in the same repository Mar 16 16:16:49 Yeah, I saw that, but did you write it? Mar 16 16:17:20 the repository contains the uio.py library, modules for various TI peripherals/subsystems, and examples Mar 16 16:17:52 correct, I don't have any external contributors yet Mar 16 16:20:18 Early on I found this page: http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg Mar 16 16:20:54 I'm a little confused because it seems there are numerous ways of passing data from the PRU to the ARM. Mar 16 16:21:15 I guess that Remoteproc is just one framework that TI made, but not the only way to do things. Mar 16 16:21:40 yeah this is TI's vision... doing stuff in a complicated way with lots of overhead :D Mar 16 16:21:56 I mean it's not like the pru core only has 2048 instructions worth of code memory or anything Mar 16 16:22:17 Lol, so is your approach similar to this? Just with less overhead? Mar 16 16:22:40 pru: write data, write pointer Mar 16 16:22:44 arm: read pointer, read data Mar 16 16:23:06 I'm assuming you know what a ringbuffer is? Mar 16 16:23:33 Yes, I've never implemented one but I know of it. Mar 16 16:24:04 Two pointers, one for the head and one for the tail right> Mar 16 16:24:08 *? Mar 16 16:26:09 yeah, although the tail pointer is just kept by the arm code Mar 16 16:27:51 How are you loading the PRU binary? I load it as a part of my Makefile cp $(PRU0_ROOT)/am335x-pru0-fw /lib/firmware cp $(PRU1_ROOT)/am335x-pru1-fw /lib/firmware Mar 16 16:28:50 I see you have # load program with open('pruss-ping-fw.bin', 'rb') as f: core.iram.write( f.read() ) Mar 16 16:29:23 yep Mar 16 16:29:25 https://pastebin.com/Gw5nm6Ra Mar 16 16:30:27 with uio-pruss you just map the pru subsystem into userspace and directly load code into it Mar 16 16:34:54 Sorry, remind me what uio-pruss is again? Is it a TI library? Im trying to figure out what I need to change since I'm using clpru. Mar 16 16:35:32 the alternative to remoteproc-pru Mar 16 16:35:44 (kernel driver) Mar 16 16:36:56 and using it with clpru is currently not yet easy Mar 16 16:37:18 like I said, it would need an elf loader, or you need to manually extract the code and data sections and load them Mar 16 16:45:47 Ok Mar 16 16:46:52 hmm, it really is very easy to load ELF though... Mar 16 16:47:06 I'm having trouble keeping all of the acronyms straight. Mar 16 16:47:27 CLPRU is the compiler I'm using (What TI reccomends currently) Mar 16 16:47:40 CLPRU replaced PASM Mar 16 16:47:47 in TI's mind yes Mar 16 16:47:49 SANTA is the load Mar 16 16:47:57 But you still use PASM right? Mar 16 16:48:01 yup Mar 16 16:48:17 pasm still has superior functionality Mar 16 16:48:36 although it would be nice to extend it with support for ELF output and data sections Mar 16 16:48:43 Got it, and the newest version of Debian I installed comes with CLPRU and associated libraries but not PASM Mar 16 16:49:42 This confused me a lot, because I thought the way to go would be with the newest install. No more device tree overlays, no more PASM. But most of the tutorials still use DTOs and PASM. Mar 16 16:50:48 well, technically an overlay is still used to enable remoteproc-pru or uio-pruss (your choice, the selection is made in /boot/uEnv.txt) Mar 16 16:51:28 so, your pru code isn't going to be much more than what you've shown right? Mar 16 16:51:44 just read that data and ship it off to the arm core Mar 16 16:52:40 Yep, exactly Mar 16 16:52:49 since if so, I'd definitely recommend uio-pruss and pasm, way less headache Mar 16 16:53:23 Ok, they don't have c support though right? PASM is ASM only? Mar 16 16:54:41 correct, which is what you want. consider for a moment that right now you've been moving variable declarations around to see if you can convince the compiler to stop being an idiot and produce the right assembly Mar 16 16:55:02 that's not how you want to have to develop software Mar 16 16:55:49 Ok, valid point. PASM and CLPRU use slightly different assembly syntax too right? I remember that CLPRU didn't like code written for PASM. Mar 16 16:56:04 clpru's assembler is a bit obnoxious iirc yes Mar 16 16:56:07 pasm is pretty chill Mar 16 16:56:19 it's mostly compatible though Mar 16 16:56:43 So can I keep the latest version of Debian and just install PASM? Mar 16 16:57:09 I assume it's just a apt-get install PASM or something? Mar 16 16:57:39 I'm checking if there's a package Mar 16 16:57:46 I just compiled it from source: https://github.com/beagleboard/am335x_pru_package/tree/master/pru_sw/utils/pasm_source Mar 16 16:58:35 Ok, and what about uio-pruss? Nothing I need to install for that right? Mar 16 16:59:21 Except for your python code and associated libraries Mar 16 16:59:32 it's a kernel driver, you enable it via /boot/uEnv.txt Mar 16 17:00:17 although I think there were some issues with it not working in some kernel releases... I haven't fully checked out what the issue was Mar 16 17:01:16 I'm commenting out uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo Mar 16 17:01:22 and uncommenting #uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo Mar 16 17:01:55 from /boot/uEnv.txt Mar 16 17:01:58 yep Mar 16 17:02:27 They have wierd names, not clear to me which is which. Mar 16 17:02:31 then after reboot, verify it has loaded: lsmod | grep uio_pruss Mar 16 17:02:47 PRU-UIO = uio-pruss, PRU-RPROC = remoteproc-pru Mar 16 17:03:07 i’ve decided i’m converting http://credentiality2.blogspot.com/2015/09/beaglebone-pru-ddr-memory-access.html?m=1 to rproc because it keeps getting so much attention. Mar 16 17:03:08 (actually technically the module name is uio_pruss while the driver name is pruss_uio ... but whatever) Mar 16 17:03:19 give me a day. Mar 16 17:03:31 jkridner[m]: to py-uio ? ;-) Mar 16 17:04:37 really want rcn-ee to always make rproc on by default. thought we’d already agreed to do that, but the 3-5 images still don’t. Mar 16 17:05:00 zmatt: ugh. guess i can add a python example. Mar 16 17:05:16 I still consider uio superior to rproc for most purposes Mar 16 17:05:49 it just needs a better C/C++ library Mar 16 17:06:03 although probably python is fine for a lot of people Mar 16 17:06:19 for what reason? you can still mmap the processor with rproc. Mar 16 17:06:30 then what benefit is there to rproc? Mar 16 17:07:02 the existing C library for UIO can probably be adapted easily. Mar 16 17:07:10 loading process just needs to change. Mar 16 17:07:13 this is news to me btw, that you can mmap pruss Mar 16 17:07:21 well loading doesn't need to change if you can mmap pruss Mar 16 17:08:09 at least the pruss memory. control registers might be in conflict. Mar 16 17:08:39 but shared ram is fine to mmap. Mar 16 17:08:44 need to check the interrupt. Mar 16 17:08:50 like I said, rproc just reduces functionality and adds complication Mar 16 17:08:59 that's my impression anyway Mar 16 17:09:45 have you seen my py-uio examples for uio-pruss btw? :) Mar 16 17:10:31 (pruss-*.{py,pasm} in https://github.com/mvduin/py-uio/ ) Mar 16 17:18:27 Ok, so I went into the /root/am335x_pru_package/pru_sw/utils/pasm_source folder after I cloned it and typed ./linuxbuild. It that all I need to do? Mar 16 17:18:34 ls Mar 16 17:19:29 yeah, should result in a linux executable Mar 16 17:20:38 i’ll check them. Mar 16 17:20:38 Got it, it was one level up. Let me add it to my path of executables now (or however you say it) Mar 16 17:20:53 you can just copy it to /usr/local/bin Mar 16 17:22:39 That worked! Mar 16 17:23:47 Ok, I also changed uEnv.txt and am rebooting. Mar 16 17:26:16 root@beaglebone:~# lsmod | grep uio_pruss uio_pruss 4629 0 uio 11100 2 uio_pruss,uio_pdrv_genirq Mar 16 17:26:25 Looks like it worked! Mar 16 17:27:23 you can also try my py-uio examples then, see note in readme: https://github.com/mvduin/py-uio/#uio_pruss Mar 16 17:34:50 root@beaglebone:~/py-uio# python pruss-test.py Traceback (most recent call last): File "pruss-test.py", line 3, in from ti.icss import Icss ImportError: No module named ti.icss Mar 16 17:35:18 use ./pruss-test.py or python3 pruss-test.py Mar 16 17:35:39 it kinda sucks that 'python' is still the old python 2 in debian Mar 16 17:35:50 but backwards compatibility blah blah I guess Mar 16 17:35:53 Oh, gotcha Mar 16 17:36:26 root@beaglebone:~/py-uio# ./pruss-test.py waiting for core to halt r0 = 124 Mar 16 17:36:34 Looks good I think... Mar 16 17:36:59 yep, since the program for that test just adds 1 to r0 Mar 16 17:40:45 So to make the .bin file with PASM, do I just run pasm pruss-test-fw.pasm and out comes pruss-test-fw.bin? Mar 16 17:41:08 pasm -b pruss-test-fw.pasm Mar 16 17:41:14 Got it, Mar 16 17:41:49 Also, how were you helping me with C since you have PASM and not CLPRU? How did you get the assembly from my C code and why do you have a make file? Mar 16 17:42:10 of course I *have* clpru for testing purposes Mar 16 17:42:22 Oh, gotcha! Mar 16 17:42:44 I just don't *use* it other than to play a bit with it and conclude it often produces pretty meh code output ;) Mar 16 17:43:11 lol, yeah CLPRU is for when you need a good laugh Mar 16 17:43:30 plus the mismatch between C and PRU in general Mar 16 17:43:41 C very much encourages the use of signed integers Mar 16 17:43:57 PRU is unsigned all the way Mar 16 17:45:07 so e.g. a signed comparison is implemented by flipping the sign bit and then doing an unsigned comparison Mar 16 17:45:23 Whoa, never knew that. Mar 16 17:45:48 the PRU architecture was never designed to be targeted by a C compiler Mar 16 17:46:00 it was designed to be programmed directly by humans Mar 16 17:46:08 it has a pretty friendly instruction set Mar 16 17:46:12 I have CH4 of the AM335x and AMIC110 sitara processors technical reference manual printed out (which talks about the PRU-ICSS). What are other good ways to learn about the inner workings of the PRU? Mar 16 17:46:43 you can find an instruction list here: http://processors.wiki.ti.com/index.php/PRU_Assembly_Instructions Mar 16 17:47:26 the beagleboard/am335x_pru_package git repo also has am335xPruReferenceGuide.pdf Mar 16 17:47:47 you can also find comments on various stuff in ti/icss/*.py Mar 16 17:49:34 (in py-uio I mean) Mar 16 17:49:47 Cool! Thanks! Mar 16 17:54:34 Alright, now to rewrite my program in ASM and get it working with pruss-ddr-ping.py Mar 16 17:55:33 oh, and maybe now is a good time to point out the single biggest wtf in the pru instruction set: qbgt label, a, b does not mean "go to label if a > b" like you'd expect from the mnemonic but "if a < b" Mar 16 17:55:40 likewise qblt is "if a > b" Mar 16 17:55:47 Good to know! Mar 16 17:55:54 root@beaglebone:~/py-uio# ./pruss-ddr-ping.py Traceback (most recent call last): File "./pruss-ddr-ping.py", line 16, in shmem = pruss.ddr.map( c_uint32 * 2 ) AttributeError: 'NoneType' object has no attribute 'map' Mar 16 17:55:55 so I personally lean toward #define bgt qblt Mar 16 17:55:56 etc Mar 16 17:56:17 huh, it has no ddr memory? Mar 16 17:57:06 which kernel are you using? Mar 16 17:57:25 How do I check that from the command line? Mar 16 17:57:30 uname -r Mar 16 17:57:43 4.4.91-ti-r133 Mar 16 17:57:50 oh wow that's old Mar 16 17:58:09 Really? I thought I had the newest one! Mar 16 17:58:45 I downloaded it here https://beagleboard.org/latest-images Mar 16 17:58:54 which one did you download? Mar 16 17:59:19 the first can't have included such an old kernel Mar 16 17:59:23 *first link Mar 16 17:59:56 the default ddr pool size for that kernel is indeed 0 Mar 16 18:00:09 I thought I dowloaded the first link Stretch IoT (without graphical desktop) for BeagleBone and PocketBeagle via microSD card Mar 16 18:01:08 that should be fine, I don't understand how you can then have such an old kernel Mar 16 18:01:11 cat /etc/dogtag Mar 16 18:01:12 ? Mar 16 18:01:29 Yeah, I still have the image on my computer bone-debian-9.2-iot-armhf-2017-10-10-4gb.img Mar 16 18:02:10 Ok, so it's not the first link any more. Mar 16 18:02:22 But it was a few months ago Mar 16 18:02:45 BeagleBoard.org Debian Image 2017-10-10 <- /etc/dogtag Mar 16 18:02:56 that still had a 4.4 kernel? really? ... maybe I'm confused about when they switched to 4.9 Mar 16 18:03:01 I'm using 4.14 myself Mar 16 18:04:14 anyway, to allocate ddr memory, I think you can just create a .conf file in /etc/modprobe.d/ containing: Mar 16 18:04:37 options uio_pruss extram_pool_sz=65536 Mar 16 18:04:37 Honestly those kernel numbers mean nothing to me, I have no idea what's recent Mar 16 18:04:39 or whatever Mar 16 18:04:51 ok, I'll give it a shot Mar 16 18:05:02 although it should be nonzero by default Mar 16 18:05:06 maybe there's a different issue Mar 16 18:05:08 wait Mar 16 18:07:31 can you print pruss._regions Mar 16 18:07:37 I didn't do everything in your readme. I just coppied the uio-pruss.rules file Mar 16 18:07:52 that's sufficient Mar 16 18:08:13 you can ignore the stuff under the uio_pdrv_genirq heading Mar 16 18:08:29 ok Mar 16 18:09:41 echo 'from ti.icss import Icss; print(Icss("/dev/uio/pruss/module")._regions)' | python3 Mar 16 18:10:07 what do you get? specifically, which keys? Mar 16 18:10:32 I'd expect as keys: 0, 'pruss', 1, 'ddr' Mar 16 18:11:19 if it only has 0 and 1 then you do have ddr memory, but your old kernel doesn't label the memory regions Mar 16 18:11:24 root@beaglebone:~/py-uio# echo 'from ti.icss import Icss; print(Icss("/dev/uio/pruss/module")._regions)' | python3 {0: , 1: } Mar 16 18:11:49 output got truncated... please avoid pasting long or multiline output in irc Mar 16 18:12:03 {0: , 1: } Mar 16 18:12:06 but yeah it looks like your regions aren't named Mar 16 18:12:15 oh never mind the output didn't get truncated, I was blind Mar 16 18:13:20 so... normally I'd suggest upgrading to the latest 4.9-ti kernel, but iirc it had issues with uio-pruss. let me quickly check Mar 16 18:14:14 yup, it lacks it :( Mar 16 18:14:27 oh right, rcn said it was fixed again in 4.14-ti Mar 16 18:14:32 it also works in 4.9-bone Mar 16 18:14:41 How can it be my kernel it outdated, it is only 5 months old :( Mar 16 18:15:09 the kernel isn't 5 months old, they just kept using the 4.4 series for quite a while Mar 16 18:15:14 by default anyway Mar 16 18:15:27 I'd say give the latest 4.9-bone a try Mar 16 18:15:41 or 4.14-bone or 4.14-ti Mar 16 18:16:01 Is 4.9 the first on on this page? https://beagleboard.org/latest-images Mar 16 18:16:17 It says Debian 9.3 Mar 16 18:16:17 you don't need to reflash, just apt-get install a new kernel Mar 16 18:16:32 Didn't know that was possible. Mar 16 18:16:32 you may reflash of course Mar 16 18:17:08 reflashing would get you a more uptodate system overall... it's possible more stuff has been improved Mar 16 18:17:33 but you can also just sudo apt-get install linux-image- Mar 16 18:17:35 4.14.27-bone13 Mar 16 18:17:36 crap Mar 16 18:17:43 but you can also just sudo apt-get install linux-image-4.14.27-bone13 Mar 16 18:17:49 So does the first link on that page use the 4.9 kernel? Mar 16 18:17:52 Ok, thanks! Mar 16 18:18:04 yeah, some kernel in the 4.9-ti series Mar 16 18:18:13 How do you tell? Mar 16 18:18:23 I just know 4.9 is the default currently Mar 16 18:18:28 ok Mar 16 18:18:58 it's also mentioned here: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Stretch_Snapshot_iot Mar 16 18:19:19 brb Mar 16 18:28:55 It can't find that package Mar 16 18:34:55 did you do apt-get update first? Mar 16 18:35:52 yeah Mar 16 18:36:20 oh, maybe it's not up yet Mar 16 18:36:53 I got that version number from looking at https://github.com/RobertCNelson/linux-stable-rcn-ee/releases but it says "2 hours ago" .. so perhaps the binary packages aren't up yet Mar 16 18:37:20 I know there's also a script in /opt somewhere to install the latest kernel in a certain series Mar 16 18:37:51 4.14.26-bone13 then I guess? Mar 16 18:38:19 or 4.14.25-ti-r38, whichever you prefer Mar 16 18:38:35 thats working, Mar 16 18:38:46 what is the difference between bone13 and ti-r38 Mar 16 18:38:52 ? Mar 16 18:39:15 -ti kernels are based on the linux kernel tree from TI (+ patches) while -bone is mainline + patches Mar 16 18:39:42 and bone is more specifically configured for beaglebone while -ti is more general and also used e.g. for the x15 Mar 16 18:40:03 Ok, Mar 16 18:40:06 (which means that -bone may be slightly more efficient) Mar 16 18:40:44 some stuff from ti that hasn't hit mainline yet might only be in -ti and not in -bone, for example I think this still applies to remoteproc-pru (unless that's changed in 4.14) Mar 16 18:47:28 4.14.26-bone13 <- uname -r Mar 16 18:47:31 looks like it worked! Mar 16 18:48:47 However, maybe not Mar 16 18:48:47 root@beaglebone:~/py-uio# echo 'from ti.icss import Icss; print(Icss("/dev/uio/pruss/module")._regions)' | python3 {0: , 1: } Mar 16 18:48:54 huh Mar 16 18:48:57 what Mar 16 18:49:10 hold on a sec Mar 16 18:50:13 ohhh, maybe I never sent the patch to rcn to add names to the memory regions Mar 16 18:50:32 ok I'll fix py-uio to just use the number then I guess Mar 16 18:53:33 ok, git pull and try again :) Mar 16 18:55:48 Oh yeah!! root@beaglebone:~/py-uio# ./pruss-ddr-ping.py ping 1 okay ping 2 okay ping 3 okay Mar 16 18:57:42 \o/ Mar 16 19:01:37 I'm getting so close, I can almost taste the 24-bit adc samples flowing into the beagle bone Mar 16 19:03:01 lol Mar 16 19:03:41 Hi, I'm trying to load BB-SPIDEV0-00A0 overlay using kernel 4.14 and 4.4 from https://github.com/beagleboard/linux and I get this "bone_capemgr: loader: failed to load slot-4 BB-UART1-00A0:00A0" my board is beaglebone-black Mar 16 19:04:19 berton: if you're using a recent image then those overlays are not really needed anymore Mar 16 19:04:38 also, the error disagrees with you w.r.t. which overlay you were trying to load :P Mar 16 19:04:56 I can't understand why kernel can't creates slot-4 in /sys/devices/platform/bone_capemgr/ Mar 16 19:05:00 but regardless, both uart1 and spi0 are directly usable Mar 16 19:05:09 bone_capemgr is deprecated Mar 16 19:05:33 zmatt (IRC): Ok, but how I use spi, /dev/spidev* doesn' exist Mar 16 19:05:56 they should exist by default if you're using a recent image (and then you only need to configure pinmux using the config-pin utility) Mar 16 19:06:01 zarzar (IRC): and I enable SPIDEV on my defconfig Mar 16 19:06:13 zarzar (IRC): sorry, is zmatt (IRC) Mar 16 19:06:22 why are you writing (IRC) ? Mar 16 19:06:59 tab complete write this, I don't I'm using matrix Mar 16 19:07:29 then maybe find a setting to fix it or use a client that isn't broken, since it's annoying Mar 16 19:07:53 I'll look this config-pin tool Mar 16 19:08:27 if /dev/spidev* don't show up yet then that problem should be fixed first Mar 16 19:08:38 like I said, they exist by default if you use a recent image Mar 16 19:10:26 also, if you boot from sd card then consider wiping eMMC with sudo blkdiscard /dev/mmcblk1 (assuming you don't care about its contents). this ensures that the ROM bootloader will load u-boot from sd rather than from eMMC Mar 16 19:11:09 (that prevents accidently using an old u-boot still lying around on eMMC even when booting linux from sd, which can cause problems) Mar 16 20:48:56 Hi! Mar 16 21:28:32 Can anyone explain the naming system for PRUs in Linux for AM57xx? Mar 16 21:29:48 In particular, the the directors `am572x_1_1` and `am572x_2_0` `pru-software-support-package/include`? Mar 16 21:29:57 *directories Mar 16 21:34:27 Do the numbers represent _? If so, then why I dont I see `am572x_1_0` `am572x_2_1`? Mar 16 22:08:48 Nevermind. I think it's refering to silicon revision. That was maddening Mar 16 23:11:53 kickliter: ah, yeah it must be Mar 16 23:12:07 yes, definitely Mar 17 01:28:52 Hello! Mar 17 01:30:08 I rescued a Beaglebone Black. Can I feed power over the pinout? I'm tired of PSUs, I use a computer PSU these days to avoid having tons of them. I try to care about the power the computer (ATX) PSU can give, of course Mar 17 01:30:49 If there's a recommendation to avoid a disaster by using this crazy idea, any advice is welcomed :D Mar 17 01:35:22 I don't have access to easily a desktop web browser. I'm in rescue mode of flashing the "bios" of my laptop using SPI. I have other ARM device, but I still didn't learn how to configure the GUI stuff. Any ASCII art is welcomed :D Mar 17 01:37:17 timofonic: you can power it by applying 5V to P9.05+P9.06 (using e.g. P9.01+P9.02 as ground) Mar 17 01:38:00 (using two pins for ground and two for 5v is recommended, but using one for each probably works fine too) Mar 17 01:38:49 zmatt: Define P9.05+P9.06 and p9.02+p9.02. I don't understand that nomenclature and the bbb is in a case :D Mar 17 01:39:48 if you orient the BBB with the ethernet connector at the top and usb host connector at the bottom, then P9 is the big expansion header on the left side and P8 is the one on the right side Mar 17 01:40:27 also in this oriented, pin 1 of P9/P8 is topleft, pin 2 is topright, 3 and 4 are below that, etc Mar 17 01:40:31 *orientation Mar 17 01:41:28 alternatively you can power the system via the mini-USB connector Mar 17 01:41:53 please wait. this is connected to a cheap tv. the mute sign is fscking me :P Mar 17 01:42:03 i need to find the remote controller... Mar 17 01:42:08 ?? Mar 17 01:42:32 oh lol Mar 17 01:42:40 some people are poor and lack a real computer monitor :P Mar 17 01:44:16 the mute sign moves all around the screen. its a PITA Mar 17 01:45:01 why is it muted? Mar 17 01:45:36 I mean, typically the bbb won't be producing audio via hdmi, and you can disable it to be extra sure Mar 17 01:45:56 There was some tv program. I mostly see TV muted with subtitles. I know it, it's weird... Mar 17 01:46:03 I'm not deaf Mar 17 01:46:32 remote found Mar 17 01:47:29 Ok. Now I understand what P9 and P8 is. Thanks! Mar 17 01:48:36 now I need to find my "gay" duponts :) Mar 17 01:49:57 if you also want to know what the other pins on those headers are doing, you can get an overview of their current configuration with this script I made: https://raw.githubusercontent.com/mvduin/bbb-pin-utils/master/show-pins Mar 17 01:50:25 (pipe through sort to sort by expansion header pin number) Mar 17 01:50:42 that covers all digital I/O on those headers Mar 17 01:51:07 Oh, nice. shell script? Mar 17 01:52:33 perl script Mar 17 01:53:01 zmatt: you're a hardcore nerd :D Mar 17 01:53:21 because I write in perl? Mar 17 01:53:34 yes, perl is nerdy :D Mar 17 01:54:18 Nothing against nerdism, I appreciate and wish to become one.... Mar 17 01:55:43 jeez, if that already gets me hardcore nerd points, what do I get for having written my own Forth compiler, or a small baremetal program for the BBB (i.e. runs without OS) written entirely in assembly? ;) Mar 17 01:56:17 wow :D Mar 17 01:58:42 So as I'm afraid of making something too stupid... Mar 17 01:58:48 1 black 2 black Mar 17 01:58:52 3 red 4 red Mar 17 01:59:12 no Mar 17 01:59:16 5 red 6 red Mar 17 01:59:21 Right? Yes. 3yo explanation. 2AM here, but I want to power this Mar 17 01:59:48 Yes. I did it right but wrote it wrong lol Mar 17 01:59:51 Thanks Mar 17 02:01:44 Uhh. No more floppy connectors. I need to do some small hack :P Mar 17 02:01:57 floppy power connectors, perfect for dupont Mar 17 02:02:48 dmm to the rescuew... Mar 17 02:37:54 zmatt: I had to hand wire copper cables, the dupont males were not big enough. The process was a bit PITA, but the BBB leds are lighting. What to do now? Mar 17 02:38:10 I wish to have an HDMI splitter at least :P Mar 17 02:38:20 "What to do now?" ? Mar 17 02:39:03 zmatt: flash firmware? or what? Mar 17 02:39:18 uhh, flashing the latest image is generally a good idea Mar 17 02:39:20 zmatt: Also... what's the max speed a BBB can get from a microSD? Mar 17 02:39:40 half the max speed it can get from its eMMC Mar 17 02:39:58 zmatt: What do you mean? :P Mar 17 02:40:02 although for writes often the eMMC / uSD is the limiting factor Mar 17 02:40:17 ohhh Mar 17 02:40:29 the "firmware memory" is an eMMC Mar 17 02:41:07 yes it has 4 GB of eMMC (or 2 GB if you have an older beaglebone black) Mar 17 02:42:12 SanDisk Ultra 64gb and SanDisk Extreme PRO 128gb Mar 17 02:43:01 I have two uSD. Both can in theory get 100mb speed, I think. Mar 17 02:43:32 max for uSD is 20-22 MB/s or something like that Mar 17 02:43:49 (48 MHz * 4 bits minus protocol overhead) Mar 17 02:43:58 oh, I see. It seems faster than rpi3? :P Mar 17 02:44:05 zmatt: No 100mhz overclock? Mar 17 02:44:36 no support for UHS modes Mar 17 02:44:53 those don't merely require higher clock speeds, it also requires switching to 1.8V Mar 17 02:45:01 zmatt: It seems an evil in most ARm devices :( Mar 17 02:45:31 eMMC (sequential read): Mar 17 02:45:31 67108864 bytes (67 MB, 64 MiB) copied, 1.58518 s, 42.3 MB/s Mar 17 02:45:49 zmatt: Is it USB faster? Can it be used instead uSD? Mar 17 02:46:16 no idea, I wouldn't count on it since the usb controller is pretty mediocre Mar 17 02:46:20 it can't boot from usb anyway Mar 17 02:46:28 Damn :( Mar 17 02:46:46 (it can netboot from ethernet, but that's definitely not going to be faster ;) Mar 17 02:46:51 Does newer models offer better features? Mar 17 02:47:15 there are various beaglebone variants with slightly different feature sets Mar 17 02:47:26 "slightly" Mar 17 02:47:29 e.g. the beaglebone black wireless replaces ethernet by wifi + bluetooth Mar 17 02:48:07 Replaces? Why not everything? What about USB3.1? What about UHS stuff? What about SATA? Mar 17 02:48:27 all of those require a different SoC than the one used on the beaglebone family Mar 17 02:48:45 e.g. the beagleboard-x15 supports SATA, USB3, and UHS Mar 17 02:48:51 Ohh Mar 17 02:49:00 How does it cost? :D Mar 17 02:49:28 hello Mar 17 02:49:45 how can i join with this project? Mar 17 02:49:52 it's not cheap. if you're using these boards just as "arm board running linux" then you can probably find boards with better price/performance ratio Mar 17 02:49:57 jvalen92: what do you mean? Mar 17 02:50:03 zmatt: I see Mar 17 02:50:45 zmatt: I'm derailing. How to upgrade the firmware? My other system is a rpi3. A friend sent me as a gift. I'm a bit deceived, but it's ok Mar 17 02:51:25 I boot wiyh USB. So uSD slot is free to write an .img. If there's need to use other method, plz explain :D Mar 17 02:52:20 timofonic: people who use the beaglebone and beagleboard often have more specific interests, like the powerful i/o capabilities, the PRUs, the DSPs on the bbx15, and the fact that the hardware designs are open and you can actually obtain tha parts to be able to customize the boards... unlike the rpi family whose SoCs are simply not available for sale whatsoever Mar 17 02:52:26 I have no PC. My laptop has the "bios" broken. I'm gona fix it Mar 17 02:52:37 you already said that Mar 17 02:53:00 zmatt: Yes, I agree. What about GPU drivers? Mar 17 02:53:00 I'm guessing you want an image with gui ? Mar 17 02:53:35 zmatt: Not essential, but good for a first contact... :) Mar 17 02:54:10 the gpu on the beaglebone has open source kernel driver but closed source userspace libs. it supports opengl ES and ES2, either directly fullscreen (DRM or GBM backends) or using Wayland. no X11. Mar 17 02:54:21 zmatt: I would like to install archlinuxARM. I'm an archlinux addict :P Mar 17 02:55:00 zmatt: So the GPU situation is a bit similar than rpi3. Well, ARM world is that way... Mar 17 02:55:38 rpi has a really weird GPU situation since the GPU is the boot processor which then brings up the ARM core as aux Mar 17 02:57:36 if gui is not essential or you're comfortable selecting packages yourself then I wouldn't recommend the standard gui image, since it's generally not as well maintained as the gui-less ones. also, the gui image is nearly 4GB (hence nearly fills eMMC, if you intend to flash it instead of booting from sd) Mar 17 02:58:24 zmatt: Going to look ir archlinux arm is available.... :D Mar 17 02:58:30 I'm used to archlinux way Mar 17 02:59:55 keep in mind that going for a distro that's rarely used on a particular platform might come with the risk of having to do more troubleshooting by yourself ;) **** ENDING LOGGING AT Sat Mar 17 03:00:00 2018