**** BEGIN LOGGING AT Fri Mar 27 02:59:57 2020 Mar 27 03:16:28 jkridner: I've dug up the conversation I recently had with pdp7 about pinmux-helper, sysfs gpio, and other such topics... extracted the relevant bits and formatted it for readability, since I think there's actually a fair bit of good stuff in there to read: https://liktaanjeneus.nl/gpio-discussion.html Mar 27 07:34:56 Hi Mar 27 07:35:19 I'm doing a project for my degree Mar 27 07:35:28 University of the West Indies Mar 27 07:35:55 Is it possible to get a Manufacturer's profile of beaglebone AI ? Mar 27 10:58:01 Hello everyone, I just got my BeagleBone AI started. Do you know how to make it boot from the SD card instead of eMMC? I could not write the boot flag Mar 27 11:13:28 Hello everyone, do you know how to make the beaglebone ai boot from the SD card? I followed this guide but it does not work: https://dulirupanetti.com/?p=8337 Mar 27 13:04:32 duyliontran[m]: which image did you use? Mar 27 14:00:44 hey zmatt Mar 27 14:01:30 on the ARM Cortex A v7, there are coprocessors, e.g., CP15. but it seems that most of the time all these co"processor"s do is provide registers. Mar 27 14:01:49 do they ever "execute" code, e.g., like a real "co"processor? are they _real_ coprocessors? Mar 27 14:02:10 and if they do, does such execution have something to do with the MCRR instruction, as opposed to MCR instructions which seem to just setup coprocessor registers Mar 27 14:09:12 here is why i'm asking. here is the secure monitor interrupt handler: http://paste.ubuntu.com/p/xBvnkMrVHt/ Mar 27 14:09:24 but it doesn't seem like it DOES anything except set some cp registers Mar 27 14:13:11 and what are the NOPs for there? Mar 27 14:31:57 zmatt: any thoughts on how this SMCInterruptHandler does anything useful? Mar 27 15:41:54 zmatt: thanks for the log of gpio talk Mar 27 16:24:52 yates: on old ARM cores they used to be coprocessors in the sense of being attached to the core via a coprocessor interface. nowadays they're fully integrated into the core, so "move to/from coprocessor register" should just be interpreted as "move to/from special register" Mar 27 16:32:50 yates: and there's not just move to/from register, there's also "coprocessor data processing" (cdp and cdp2) to get the "coprocessor" to perform operations. for example this includes FPU instructions (coprocessor 10 and 11), although neon data processing instructions were allocated into a new (previously undefined) opcode range instead Mar 27 16:36:23 yates: I found this in some thumb2 opcode summary notes I once wrote: https://pastebin.com/raw/jspfkzqq Mar 27 16:40:11 I am looking for a mentor around my area, anybody here from New Delhi, India? I want someone who can guide me through GSoC during when my mentors are busy. Mar 27 16:40:45 lorforlinux: please ask questions like those in #beagle-gsoc, not here Mar 27 16:43:10 zmatt: i am just following the pointer given to me by jkridner. We don't have anyone my area in #beagle-gsoc. Mar 27 16:43:25 * anyone around Mar 27 16:44:32 btw, thanks for this nice discussion log https://liktaanjeneus.nl/gpio-discussion.html Mar 27 16:48:04 yates: note btw that all coprocessor instructions have the interesting property of being identical to their encoding in the legacy ARM instruction set except that on little-endian machines the two halves are swapped in memory, and the legacy ARM encoding may support conditional execution (if the top nibble is 0xE it's a condition code, if it's 0xF the instruction is always unconditional) Mar 27 16:48:53 I am learning PRU. Meanwhile I have a few questions: Mar 27 16:49:13 What is the best PASM reference guide? Mar 27 16:49:43 I do see https://processors.wiki.ti.com/index.php/PRU_Assembly_Reference_Guide Mar 27 16:50:15 But it mentions: "Content is no longer maintained and is being kept for reference only!" Mar 27 16:50:40 And whatever they refer to I do not see PASM (maybe did not find it) Mar 27 16:50:40 dreamhiker: section 5.3 of the pru reference guide and those webpages yes Mar 27 16:51:05 who cares if they're unmaintained, PRU and pasm won't suddenly change :) Mar 27 16:51:48 What would I do without you? Don't get under the bus and dont catch the virus :) Mar 27 16:51:59 I'll try Mar 27 16:53:23 5.3.2.1.4 Set Call/Return Register (.setcallreg) Command Mar 27 16:54:11 It says that default register of R30.w0 is used for CALL/RET, but R30 us used for gpio. Mar 27 16:56:06 which is why you should override that default, along with .origin: https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/common.h#L3-L8 Mar 27 16:57:53 Thanks! Still strange though why the default is such Mar 27 16:58:18 backwards compatibility, r30 wasn't used for gpio in pruss v1 Mar 27 16:59:03 of course if you don't use the pru gpio outputs then you can still use r30 as call register if you want to Mar 27 16:59:27 Makes sense (some) :) Mar 27 17:02:12 In the pru ref guide there is a statement: Mar 27 17:02:14 The hardware module(s) and the features described in this Reference Guide are not supported by Texas Instruments. "Community" support may be offered at BeagleBoard.org/discuss. Mar 27 17:04:30 yeah they had a weird policy about pru in the beginning... pru even disappeared from the public TRM for a bit, then this separate reference manual was released via unofficial route (beagleboard.org), and later they changed their position and returned PRU back to the TRM Mar 27 17:05:51 in case it's useful btw, here's an overview of all special uses of PRU registers: https://pastebin.com/raw/E6m8ztPm Mar 27 17:06:24 note that EABI only matters if you ever want to interoperate with C code, it doesn't matter for pasm code Mar 27 17:06:52 thanks for the thoughts, zmatt Mar 27 17:09:40 dreamhiker: and for R30/R31 the only modes supported on the beaglebone are "direct", "serial" and "parallel capture" Mar 27 17:09:48 with direct being almost always used Mar 27 17:12:55 zmatt: is there a conventional term for the bootloader code that resides on the chip and runs at the very beginning of power on? as opposed to what seems to be conventionally called "bootloader"(s) which run as part of the reset vector in outside memory? Mar 27 17:13:12 bootrom you mean? Mar 27 17:13:18 yeah, i guess Mar 27 17:13:27 or "rom bootloader" Mar 27 17:14:07 is bootrom constant across, say, all Cortex Av7 cores? Mar 27 17:14:16 absolutely not Mar 27 17:14:29 how about Cortex A9v7? Mar 27 17:14:43 absolutely not, it's SoC specific and usually SoC revision specific Mar 27 17:14:56 it's just some mask rom integrated into the SoC Mar 27 17:14:58 in other words, to SoC designers ... oh - you answered it Mar 27 17:15:52 so if you're a big enough player, you could have, e.g., Marvell spin you a totally custom SoC with your own bootrom code? Mar 27 17:16:05 absolutely Mar 27 17:16:16 if you're a big enough player Mar 27 17:16:44 ok, that's good to know Mar 27 17:18:21 though even the Nintendo Switch did not have a custom bootrom for the Tegra X1 SoC on it Mar 27 17:18:44 even though Nintendo is pretty big Mar 27 17:19:05 but maybe they could have and just didn't feel a need for it Mar 27 17:19:21 speaking convetionally/typically then, what does the bootrom code set up? e.g., does it typically set an initial configuration of the MMU, and thus the memory map? does it initialize DRAM? does it initialize a nand controller and load nand into memory? SRAM? DRAM? Mar 27 17:19:23 (unfortunately for them, that bootrom contained a critical security vunlerability) Mar 27 17:19:59 there's no "typical" there Mar 27 17:20:40 is the standard A9 rom bootloader code published somewhere? (haven't looked yet so sorry if it is obvious) Mar 27 17:20:48 cortex a9 core, that is Mar 27 17:20:53 no such thing exists Mar 27 17:21:09 since bootrom performs SoC-specific initialization Mar 27 17:21:33 is the AM335x bootrom code published? Mar 27 17:21:54 ok Mar 27 17:22:00 and loads the next bootloader stage according to a SoC specific rules from external memory or peripherals Mar 27 17:22:20 and perhaps performs authentication on it according to SoC specific security mechanisms Mar 27 17:22:42 right, like a AES or whatever check against the 1st-level bootloader code Mar 27 17:22:50 BCH/AES Mar 27 17:23:19 (where bootrom is the 0th level bootloader) Mar 27 17:23:44 and no, am335x bootrom isn't published, although you can dump "pubrom" (0x4002000 - 0x4002bfff) Mar 27 17:23:56 BCH is NAND error correction, not authentication Mar 27 17:24:32 ok my flub Mar 27 17:24:42 authentication most commonly uses public-key crypto, though symmetrical crypto could be used I guess Mar 27 17:25:32 the public key is stored somewhere on the SoC? possibly in the core rom? Mar 27 17:25:44 efuses typically Mar 27 17:26:02 (typically the hash of the public key since that is more compact than the public key itself) Mar 27 17:26:28 so ifyou could just work out a hash collision... Mar 27 17:26:55 then you've done the exact thing cyptographic hash functions are designed to make infeasible Mar 27 17:27:28 and you wouldn't need a mere collision but a "second pre-image" Mar 27 17:27:46 (i.e. invert the hash function) Mar 27 17:28:18 the hash function isn't invertible, theoretically, right? Mar 27 17:28:25 except also do so in a way that would allow you to have a private key for that public key Mar 27 17:28:41 inverse mappings exist iff (onto and 1-1) Mar 27 17:28:50 so basically you'd just have to generate keypairs until your public key happens to hash to the right value Mar 27 17:29:09 which for an n-bit hash will happen on average after generating 2^(n-1) keypairs Mar 27 17:29:29 other than that you don'[t know a thing about it? :) Mar 27 17:30:14 that's supposed to be a joke... ^^^ Mar 27 17:30:28 ok. Mar 27 17:32:03 to back up, so theoretically it would be possible for a vendor to put the secure monitor setup code in bootrom? Mar 27 17:32:25 that's not "theoretically", that's typical Mar 27 17:32:46 really? like setting up the MVBAR? Mar 27 17:32:46 actually I don't know if it's typical Mar 27 17:32:53 but it's what TI does Mar 27 17:33:01 ok Mar 27 17:34:23 I know the broadcom SoC on the rpi doesn't (but technically the ARM processor there isn't the boot processor. it boots initially on the VC processor (the "GPU"), so that would be the place where boot security is implemented) Mar 27 17:40:40 if TrustZone setup stuff is done in bootrom, doesn't that preclude utilizing open TEE implementations such as OP-TEE? Mar 27 17:43:05 yes Mar 27 17:43:25 trustzone is not usable on TI SoCs Mar 27 17:43:32 (unfortunately) Mar 27 17:43:45 you mean not implemented? Mar 27 17:43:54 no I mean not usable Mar 27 17:44:07 other than as part of their security architecture for High Security devices Mar 27 17:44:47 but us plebs who have General Purpose parts (like the beaglebone) cannot use trustzone in any way Mar 27 17:45:02 if it's present on the core, why couldn't you use it? Mar 27 17:45:57 ...why couldn't it be used.. Mar 27 17:46:02 on GP devices secrom just sets up a tiny secure monitor that implements a handful of secure monitor calls (to allow configuration of certain special machine registers that can only be written by secure privileged mode), and then it switches to public mode for te remaining bootloading Mar 27 17:46:10 you have no way to execute code in secure mode Mar 27 17:46:37 secrom? Mar 27 17:46:48 the secure part of bootrom Mar 27 17:47:37 you mean it switches to "normal world" for the remaining bootloading? Mar 27 17:47:55 public world, normal world, non-secure state, whatever you want to call it Mar 27 17:48:17 right. Mar 27 17:48:48 so that's an example of the very thing we've been discussing Mar 27 17:49:45 TI calls it public rom, and I actually like "public" vs "secure" because the ARM standard terminology "non-secure" is just awful and for the reason at the top in comments here: https://liktaanjeneus.nl/firewall.h.html Mar 27 17:50:57 it conveniently allows for single-letter abbreviations, which can be useful for certain types of dumps :) Mar 27 21:18:02 @zmatt: I think I may have gotten the mraa/upm libraries to work w/ the BBB due to some instructions on github. Mar 27 21:18:17 I am compiling upm now but mraa compiled. I will keep you updated. Mar 27 21:18:48 If that is interesting at all, please let me know. Either way, more testing will ensue. Mar 27 21:19:28 I saw a lot of Adafruit modules are listed on the upm compilation. Mar 27 21:33:58 well, there are errors but one shall figure this out! Mar 27 21:38:46 set_ morning. Mar 27 21:42:53 Hello GenTooMan. Mar 27 21:43:26 What are you up to these days? Mar 27 21:44:13 upm had some issues on 4% and 5% during the compilation but now, it is as smooth as ice. Mar 27 21:44:25 Build! Mar 27 21:48:46 mostly, the 2.7.13 python building in compilation is giving issues. Mar 27 21:59:06 is it okay to update c++ on the BBBW for use? I think I am receiving errors in upm during compilation b/c of my c++ 6. Mar 27 21:59:48 Forget what I typed. I will see what happens. Mar 27 22:51:56 anyone use qt creator Mar 27 22:56:04 Not me. Mar 27 22:59:33 MattB0ne wxglade here :D Mar 27 22:59:54 Today people in my office were talking about some time-critical ~1ms analog signal processing. Basically: analyze the signal and trigger a pin when something is found. Do we know what is the best to do it on BB? I realize that the question is very generic. Mar 27 23:01:08 1ms is a lot of time Mar 27 23:02:23 just a normal linux process probably suffices, especially if you give it real-time scheduling Mar 27 23:02:57 optionally you could use an RT kernel to ensure there are less things in the kernel that could block a real-time process from executing Mar 27 23:03:21 as usual, if you need a strict guarantee, use pru Mar 27 23:03:40 set_: python 2 is dead Mar 27 23:04:10 set_: (but it's still packaged for debian so there's absolutely no need to compile it) Mar 27 23:04:17 I thought that last time you said that the user program can be interrupted by the kernel and be out of control for a good number of milliseconds Mar 27 23:04:17 Okay. Mar 27 23:04:34 I will figure out how to cancel the comp. for python2.7.x now. Mar 27 23:04:58 set_ why are you building python 2.7. Mar 27 23:05:23 I do not know. I used cmake to compile and it was compiling the 2.7.x python examples too. Mar 27 23:05:56 Dreamhiker: I'm pretty sure I didn't specify a concrete amount of time Mar 27 23:07:29 Dreamhiker: you know, forget I said a normal linux process should be fine for 1ms latency... I don't actually know. I know last time I tested it a linux process could respond within a few dozen microseconds, but I don't actually know how long various interrupts take Mar 27 23:08:21 (though an RT kernel would allow scheduling a process at a higher priority than most interrupts) Mar 27 23:09:29 zmat: Sorry, my internet today is dead and I may have missed something. You did not provide the timing: as the best my recollection you said that you are surprised that the kernel rescheduling takes that many cycles. And I do not remember if you have mentioned 15us or 15ms Mar 27 23:09:51 neither Mar 27 23:10:07 or just talked about a huge amount of cpu cycles Mar 27 23:11:06 So what do you think the maximum hickup can be? Mar 27 23:11:08 *shrug* the linux kernel does sometimes seem to spend mind-boggling amounts of cpu cycles on things Mar 27 23:11:14 I have no idea Mar 27 23:11:22 OK Mar 27 23:11:24 that will depend a lot on system use and drivers Mar 27 23:11:44 and RT kernel: you have meant not to use linux? Mar 27 23:12:57 no I mean a linux kernel build with PREEMPT_RT (i.e. the linux kernel packages with -rt suffix) Mar 27 23:13:45 OK, won't bug you with this - will try to understand this Mar 27 23:14:37 What do you think is the best way to provide analog signal to PRU? Mar 27 23:15:21 basically what it does is change most interrupt handlers into kernel threads and most spinlocks (which on uniprocessor systems normally disable interrupts and prevent preemption) into priority-inheritance mutexes Mar 27 23:15:54 there is no "best way" with such a vague specification Mar 27 23:16:30 @zmatt: Whenever you get a couple of minutes to look over this idea, https://pastebin.com/Hqt2VrtD, please let me know what you think from the library that was put together for the ServoCape. Mar 27 23:16:48 I know right now is not the best time. I will wait. Mar 27 23:18:28 Looked at PREEMPT_RT - do not think it will help. It would mean that I need to keep the analyzer thread all the time on the high priority. Mar 27 23:19:01 dreamhiker27: I assume it's idle most of the time and just periodically samples the adc ? Mar 27 23:19:14 so why is it a problem to be at high priority? Mar 27 23:19:44 Because nothing else will run. Correct? Mar 27 23:20:09 only when the analyzer thread is runnable, not while it's blocked obviously Mar 27 23:21:33 if has high priority and uses a timer to periodically wake up then whenever that timer expires linux will switch to that thread (since it has real-time priority) and when it blocks (e.g. when it's done its thing and goes back to waiting on the timer) it will reschedule back to whatever Mar 27 23:21:57 otherwise high-priority tasks would be useless Mar 27 23:22:32 Can I say periodically wakeup every 100us? Mar 27 23:23:01 didn't you say 1ms earlier? Mar 27 23:23:21 waking up every 100us might not leave much cpu time for other stuff Mar 27 23:23:51 (but maybe I'm overly pessimistic) Mar 27 23:24:15 So what is the realistic time that it allows everything else to work at 90%: will not quote you :) Mar 27 23:24:30 no idea, test and find out Mar 27 23:25:09 a ball-park (for a person who reads the kernel)? Mar 27 23:25:43 sorry it doesn't work like that Mar 27 23:25:50 I'd need to test if I wanted to know Mar 27 23:25:59 I don't have a need to know, you do, so test Mar 27 23:26:42 it's easy enough to just make a tiny program that calls usleep(100) in a loop and run it with real-time priority Mar 27 23:26:46 Thanks! Mar 27 23:27:04 cannot open you pastebin. Could you please resend? Mar 27 23:27:10 (though you may want to check what the timer slack value is and change it if necessary) Mar 27 23:27:13 which? Mar 27 23:27:29 https://pastebin.com/Hqt2VrtD, Mar 27 23:27:49 that's not my pastebin, it's set_'s Mar 27 23:28:14 and dunno why you can't open it, it seems fine here Mar 27 23:29:25 not for me. But that's ok. Will ask him. Mar 27 23:30:05 as far as usleep(100us), don't I need first to build the real-time kernel? Mar 27 23:30:26 dreamhiker27: why would you care? it looks like he has some problem with some snippet of untested python code I scribbled I while back Mar 27 23:31:43 I am talking about "it's easy enough to just make a tiny program that calls usleep(100) in a loop and run it with real-time priority". DO I need to build a rel-time kernel? Mar 27 23:31:52 dreamhiker27: you can test it on a normal kernel first, if it seems okay there you could apt-get install the rt version of the kernel you're using to see if performance (which will be worse on rt) is still okay there Mar 27 23:32:58 dreamhiker27: that question suggests you either haven't read or haven't understood the things I've said about real-time scheduling nor rt kernels Mar 27 23:33:35 On a normal kernel, can I set the priorities (which are honored)? Mar 27 23:35:49 pthread_setschedparam() can be used to do it in software, although I'm not sure if you can do that as regular user (that depends a bit on system configuration details). there's also a utility you can use to change the scheduling policy of a running process/thread, lemme see if I can find what it's called Mar 27 23:36:14 schedtool Mar 27 23:36:38 (which you can install with apt) Mar 27 23:38:42 Very interesting information! Thanks! I was under the impression that all those priorities never work. I am glad I am wrong. I will definitely try those Mar 27 23:39:51 I explained what an rt kernel does, it only has to do with kernel code, it does not change how scheduling works or what scheduling options are available for userspace threads Mar 27 23:41:02 its purpose is to minimize the amount of time the kernel is preventing preemption Mar 27 23:41:30 which can make a big difference with time critical code. Mar 27 23:41:53 Maximize (not minimize)? Mar 27 23:42:10 (but as a side effect it will reduce overall system performance and it has a tendency to make the kernel buggier and crashier, though this tends to be as a result of exposing preexisting bugs in driver code) Mar 27 23:42:11 RT allows my thread not being preempted Mar 27 23:42:14 minimize Mar 27 23:42:25 minimize the amount of time the kernel itself is running non-preemptible code Mar 27 23:42:36 it's not about your threads Mar 27 23:42:44 I just said an RT kernel has no impact on those Mar 27 23:44:26 it's about when the kernel can be preempted (e.g. to switch to a high-priority userspace task that just became runnable) Mar 27 23:46:14 OK, will get to it. Mar 27 23:47:05 once upon a time kernel code was never preemptible, then the concept of "voluntary preemption" was introduced, i.e. specific points in the kernel code where preemption was allowed (e.g. in chunks of kernel code that were known to take a lot of time and could be safely preempted), later the kernel was more and more made preemptible, allowing preemption anywhere except in small pieces of code explicitly ... Mar 27 23:47:12 ...marked as non-preemptible Mar 27 23:47:25 but interrupt handlers are still non-preemptible in a normal kernel Mar 27 23:48:36 an rt kernel adds a fourth level of preemptibility: preempt_rt, which tries to further eliminate non-preemptible kernel code by making interrupt handlers and spinlock-protected critical sections preemptible (by making interrupt handlers into kernel threads and spinlocks into mutexes) Mar 27 23:52:38 From what you are saying, an rt kernel can provide a better reaction within a sub-microsecond, which I do not need Mar 27 23:54:26 I haven't said anything about how much time the kernel could spend inside an interrupt handlers or spinlock-protected section, but I think assuming it's less than a microsecond on a BBB seems absurdly optimistic Mar 27 23:54:45 however, I do not know Mar 27 23:55:13 it'll also depend entirely on what stuff the kernel is doing, hence in particular which drivers are being used Mar 27 23:55:33 (and presumably on kernel version and kernel configuration) Mar 28 02:06:51 Are people using Processing .js or .py for visual effects? Mar 28 02:18:54 I set it up on the dev. machine. I might try it w/ a motor or something on the BBBW. Mar 28 02:19:24 It has I/O and real time capabilities. Mar 28 02:28:45 ???? Mar 28 02:30:05 it's a library for graphics and animation Mar 28 02:31:06 ("targeted towards artists and designers") Mar 28 02:31:40 "Processing started as an open source programming language based on Java to help the electronic arts and visual design communities learn the basics of computer programming in a visual context" Mar 28 02:32:03 (with Processing.js and Processing.py being javascript and python ports of it) Mar 28 02:39:16 Right. But, I found that it has i/o w/ p5.js. Mar 28 02:39:18 Right? Mar 28 02:39:26 ?? Mar 28 02:39:40 I thought they worked together. Mar 28 02:40:01 I know ml5 works w/ p5. Mar 28 02:40:14 That is nice, at least. Mar 28 02:40:59 ah, Processing.js isn't a port, it's an interpreter apparently, whereas p5.js is a port Mar 28 02:41:17 I still have no idea what you mean by "has i/o" Mar 28 02:41:25 Let me show you. Mar 28 02:41:27 Please hold. Mar 28 02:41:30 I will get the link. Mar 28 02:42:28 processing.org/reference/libraries/io/index.html Mar 28 02:42:45 I found that somehow while searching for something unknown to me. Mar 28 02:43:12 They say pi but they also say other linux machines. Mar 28 02:43:15 cute, although obviously you don't have those in p5.js or processing.js since those run in your web browser Mar 28 02:43:23 Oh. Mar 28 02:43:37 Double dang. Mar 28 02:44:18 Still, I have done all sorts of nice things so far w/ p5, ml5, and processing. Well, not a lot but some things. Mar 28 02:44:43 ml5 has neural networks and teaching. Mar 28 02:45:19 @zmatt: I got the upm/mraa libraries installed on the BBBW. Mar 28 02:45:29 The one w/ the ServoCape on it. Mar 28 02:45:45 Talk about some fun times ahead. Mar 28 02:51:33 Are people still talking about putting tensorflow on the AI? Mar 28 02:58:06 Exec format error means it was compiled with the wrong arch? **** ENDING LOGGING AT Sat Mar 28 02:59:59 2020