**** BEGIN LOGGING AT Mon Mar 10 02:59:58 2014 Mar 10 04:08:22 ds2, could I talk to you regarding the documentation project? Mar 10 06:28:59 wiznerd: Hi... I am about to hit the sack...catch me tomorrow and we can talk Mar 10 12:41:52 hi Mar 10 12:42:05 morning Mar 10 12:42:25 _av500_: mdp back? Mar 10 12:42:49 i wanted to ask somethings about the bonescript webpages project, i have been speaking to jkridner about it, are you there jkridner? Mar 10 12:43:03 not yet Mar 10 12:47:47 Apart from mdp, who among the mentors were at the conf in Macao? Mar 10 12:48:17 just mdp Mar 10 13:36:09 t27 left? Mar 10 13:37:00 hi jkridner Mar 10 13:38:15 hi Mar 10 14:59:38 hi Mar 10 15:14:28 mdp : Hello! Mar 10 15:31:30 mdp: piiing Mar 10 15:31:35 mdp : hello! Mar 10 15:39:00 karki: it seems a lot of people want to talk with mdp about the gsoc Mar 10 15:39:13 what are you insterested in ? Mar 10 15:41:30 mines not the PRU loader, but related to the PRU. Its basically developing a firmware for the PRU so that high level languages can talk to the PRU Mar 10 15:42:09 using RPC/shared memory/some-other-method : not sure as yet Mar 10 15:42:52 karki, pong Mar 10 15:42:54 chocko, pong Mar 10 15:43:01 PRU time? Mar 10 15:43:06 oh yes Mar 10 15:44:08 glad to meet you, i hope you enjoyed your conf and the fligths Mar 10 15:44:26 chocko, conf was pretty good...but all work..less fun ;) Mar 10 15:44:51 so, first, so I get these straight... Mar 10 15:45:35 basically, i am interested in the firmware loader project as described in the wiki. I will file a proper application on the ml, but at first i have a few questions Mar 10 15:45:52 karki, I read your email..about the f/w to support high-level languages...but which Alexander did you talk to? Mar 10 15:46:20 mdp : Alexander Hiam, I'm working with him for PyBBIO Mar 10 15:46:48 ahh, ok..I've heard of that project but didn't know of alexander Mar 10 15:47:26 chocko, ok, one thing I need to understand is how far panto got with his PRU remoteproc work. Mar 10 15:48:34 afaik panto had a working pru remoteproc loader...if so, I'm unclear of the state and what work this project would be Mar 10 15:49:14 why is it needed to have the firmware to be loaded with a request_firmware seeing that it already possible to dit it with mmap ? Mar 10 15:49:52 because it would be cleaner, faster ? Mar 10 15:49:54 it's about using standard kernel interfaces Mar 10 15:50:01 ok cleaner Mar 10 15:50:25 it then allows you to make use of the virtio framework for abstraction if desired Mar 10 15:50:54 because it should still have to be loaded from userspace (sort of) after a UEVENT is sent Mar 10 15:50:59 and that's something panto was working on last year in conjunction with the failed GSoC project for the JTAG PRU implementation Mar 10 15:51:36 The idea is to support basic communication between ARM and PRU via a high level language. Then there will a custom protocol exchanged between the language library and the PRU firmware. Mar 10 15:51:48 well, you can request the load itself via a sysfs exposed "trigger" Mar 10 15:52:23 I did a simple implementation of this for the 6502 remoteproc project..but didn't upstream for unrelated reasons Mar 10 15:53:19 Based on what values the ARM processor sends to the PRU, the firmware will branch to a particular function and execute what is requested to it. Mar 10 15:53:28 karki, so are going to focus on just PyBBIO support to start? or are you planning to also implement that javascript front-end to it? Mar 10 15:54:07 in the end, is this project still available ? did someone file an application for it last year ? Mar 10 15:54:46 There has to be a front-end library to access the firmware, and I'm comfortable with PyBBIO as of now (I'm already a contributor there) Mar 10 15:54:53 chocko, well, here's the thing..we're going to have to do some digging on this. I'm trying to get responses from panto and ka6sox that had some involvement with that student last year. Mar 10 15:55:17 Jason told he will be developing a Node.js based test bench Mar 10 15:55:22 chocko, I'd hate to see you recreate some out-of-tree stuff...but, I can say that nothing like this was completed and made it upstream in the kernel. Mar 10 15:56:01 karki, ok, so jkridner will handle the bonescript side, alexander mentoring on pybbio side, and you need somebody to help mentor on the PRU end, right? Mar 10 15:56:22 ok i understand. should I do something OR only wait for an update of the project on the wiki ? Mar 10 15:56:53 mdp: yes, that's the status as of now. Mar 10 15:57:25 chocko, hang on a sec Mar 10 15:57:28 hey Mar 10 15:57:28 ahh, here he is ;) Mar 10 15:57:34 thanks for joining , panto Mar 10 15:57:45 I aim to please... Mar 10 15:57:48 Mar 10 15:57:58 or shall we say Mar 10 15:58:00

Mar 10 15:58:01 panto, chocko here was interested in the project for a loader for the pru that uses request_firmware() Mar 10 15:58:11 that's essentially part of the project from last year Mar 10 15:58:14 that's already done Mar 10 15:58:17 absolutely Mar 10 15:58:18 yeah Mar 10 15:58:27 on 3.8 Mar 10 15:58:37 things have changed/b0rked for 3.13 Mar 10 15:58:41 panto: that kernel will never die Mar 10 15:58:44 so there is work to do Mar 10 15:58:47 to be done Mar 10 15:58:47 yes Mar 10 15:58:53 yes, ok, cool Mar 10 15:58:54 good :) Mar 10 15:58:57 also the PRU compiler isn't open :) Mar 10 15:59:00 I wasn't sure how much worked or didn't work Mar 10 15:59:08 mranostay, why do you need the PRU compiler? Mar 10 15:59:10 and the new versions broke my code Mar 10 15:59:24 ELF binaries? Mar 10 15:59:25 cause it's so much easier doing stuff with it Mar 10 15:59:32 pasm doesn't do that Mar 10 15:59:39 mranostay, um, ELF binaries are not needed for remoteproc Mar 10 15:59:41 you can still use assembly for the time critical parts Mar 10 16:00:07 well, I'm not going to help with a closed compiler, that's for sure Mar 10 16:00:13 ;) Mar 10 16:00:35 so, there's a few things I'm aware of Mar 10 16:00:46 hehe Mar 10 16:00:47 1) I believe PRU still doesn't work upstream due to the hwmod reset issue Mar 10 16:00:58 and other issues Mar 10 16:01:12 lots of changes in rproc Mar 10 16:01:18 2) PRU remoteproc exists for 3.8 but not anything later...and depends on the closed C compiler due to using ELF binary loading(?) Mar 10 16:01:29 mdp, no Mar 10 16:01:37 you can use a blob just fine Mar 10 16:01:42 great Mar 10 16:01:50 however I have an idea Mar 10 16:01:53 a cunning plan Mar 10 16:02:04 panto: nonsense! Mar 10 16:02:14 the PRU is stupid simple as an instruction set Mar 10 16:02:19 yes Mar 10 16:02:20 we have a free assembler Mar 10 16:02:23 yes Mar 10 16:02:49 why don't we put someone to enable it in a modern compiler Mar 10 16:02:58 mdp: The functionalities I mentioned is the most simplistic ones, there is also certain scripting functionalities we plan to introduce where the high level language shoots a few lines code (similar to bot speak - chris rodgers) to the firmware and it interprets it. Mar 10 16:03:00 it is 32 bit Mar 10 16:03:20 llvm for instance Mar 10 16:03:32 so there is no work needed for the request_firmware ? Mar 10 16:03:33 (not gcc since the internals are way too weird for someone to grok them fast) Mar 10 16:03:36 chocko, no Mar 10 16:03:43 MDP: welcome back. mranostay: hi Mar 10 16:03:52 hi Abhishek_ Mar 10 16:04:05 is there still work needed for the PRU or the kernel ? Mar 10 16:04:23 yes Mar 10 16:04:37 someone has to port it to mainline Mar 10 16:04:44 panto, is there something concrete we could help chocko define as a useful project? Mar 10 16:04:45 and then push the patches Mar 10 16:04:51 ahh, mainline, baby! Mar 10 16:05:16 there is also this heterogenous stuff I did a long long time ago Mar 10 16:05:19 panto, so, the basic remoteproc, fix the hwmod issue, add the sysfs load interface Mar 10 16:05:19 mdp remembers Mar 10 16:05:40 those pieces seems to be the absolute minimum to me Mar 10 16:05:45 ok Mar 10 16:05:51 unified ARM userspace+PRU Mar 10 16:05:53 panto, would you agree? Mar 10 16:05:58 yes Mar 10 16:06:04 I know there's the whole communication part after that Mar 10 16:06:27 but the sysfs load interface is nothing without the whole pinmux reconfiguration required Mar 10 16:06:47 if you're changing pinmux that is Mar 10 16:07:01 well, for mainline, you are stuck with having to modify and boot with the appropriate dts Mar 10 16:07:14 I've been there before...suboptimal...but mainline Mar 10 16:07:24 my DT overlay patches will be posted this week Mar 10 16:07:35 work fine on x86 too :) Mar 10 16:07:49 panto: feel dirty? Mar 10 16:08:14 oh they might fire you if they think you're helping me out :) Mar 10 16:08:24 panto, finally another round...it's been so long I figured they were dead again :-/ Mar 10 16:09:05 meh Mar 10 16:09:14 panto: btw CC me on the patchsets Mar 10 16:09:21 not my intel address of course :) Mar 10 16:09:29 coward Mar 10 16:10:30 reminds me to ping jic21 on the iio patches Mar 10 16:10:35 mranostay: Please let. me know your thoughts on the logic analyser idea. Mar 10 16:10:49 karki, so back to yours..yes, that's sane. basically you are talking about a run to completion type firmware per command. one thing that will need to be considered is if some commands are non-blocking and notify on completion. the real question is what is the goal of offloading thing to the PRU? Mar 10 16:11:08 Abhishek_: totally doable just how complex and what mhz we can really run at Mar 10 16:11:30 also the inputs Mar 10 16:11:35 karki, if it's to leverage the low-latency i/o and determinism, then that needs to be considered in designing the RPC mechanism Mar 10 16:11:38 mdp, I had some high priority interrupts Mar 10 16:12:03 there's already an RPC mechanism Mar 10 16:12:13 in the zombie 3.8 kernel Mar 10 16:12:32 blocking ARM -> PRU call Mar 10 16:13:55 I would like to run at max MHz possible. Also requesting MDP for sup port in writing. PRU code Mar 10 16:14:31 mdp : and another problem is that all the logic is to be done in PRU assembly, it'll be awfully big and hard to maintain! Mar 10 16:14:34 Abhishek_, we've got several people with PRU experience here so not a problem Mar 10 16:14:59 mdp: can i put PRU assembly on the resume? :P Mar 10 16:15:11 sure Mar 10 16:15:25 panto, yeah, I was thinking that a non-blocking call with a notifier interrupt on completion would be preferred for certain cases. Mar 10 16:15:41 for the core. How can libsigrox help us? Mar 10 16:15:48 panto, but could be worked around Mar 10 16:16:15 Abhishek_, I saw some discussion about UIs etc. on scrollback..you should use sigrok and not reinvent things that exist there Mar 10 16:16:23 mdp, non-blocking requires buffering Mar 10 16:16:30 panto, yes Mar 10 16:16:32 and makes things more complex Mar 10 16:16:38 yes Mar 10 16:16:54 let's just say we KISS and do blocking RPCs Mar 10 16:17:05 in that case we have that already Mar 10 16:17:07 now, let's say you are calling to the PRU from javascript/python.. Mar 10 16:17:10 but it's kernel mode only Mar 10 16:17:13 low level latency and ARM acting as the bottle neck was my doubt initially, but then I looked up chris's scripting technique for bot speak. So even if I have to repeat something, one write will do. Mar 10 16:17:14 yes Mar 10 16:17:21 what's the value of blinking an led via pru pins? Mar 10 16:17:40 mdp that's not the value Mar 10 16:17:40 faster blink Mar 10 16:17:46 hehe Mar 10 16:17:58 the value is making a call like generate_waveform() Mar 10 16:18:00 there's some truthiness under the snarkiness of that Mar 10 16:18:04 and having it go on it's way Mar 10 16:18:05 yes, that's true Mar 10 16:18:08 mdp: always Mar 10 16:18:27 #troll-gsoc at play? Mar 10 16:18:44 blink is a simple example. Mar 10 16:18:59 Abhishek_: yes use sigrok :) Mar 10 16:19:02 more like "bitbang this complex thing in real time" Mar 10 16:19:12 so i can kang your code for a ELC talk in the future :P Mar 10 16:19:29 there is a lot more you could do with such function calls. Mar 10 16:19:34 we know Mar 10 16:20:01 here's the thing..you get no serious gain by mapping arduino type calls on top of RPCs Mar 10 16:20:04 and you can easily use threads on the arm side Mar 10 16:20:05 and then trace this in real time :P Mar 10 16:20:16 mdp, +1 Mar 10 16:20:19 you get a gain by doing high level calls like panto suggests Mar 10 16:20:23 forget the arduino model Mar 10 16:20:27 it's BS Mar 10 16:20:36 arduino is a toy anyway Mar 10 16:20:42 like a pru.pwm() Mar 10 16:20:50 right Mar 10 16:20:57 have high-order interfaces Mar 10 16:21:07 for instance generate_sine() Mar 10 16:21:31 maybe a pru.serialWrite(val)? such kind of calls? Mar 10 16:21:35 not try to shoehorn lowlevel stuff like 'set_dac_value()' Mar 10 16:21:46 even higher level Mar 10 16:22:52 karki, for instance Mar 10 16:23:11 pru.setLEDpattern Mar 10 16:23:14 let's say that you have a PRU program that generates a uart stream Mar 10 16:23:24 okay..... Mar 10 16:23:26 by bitbanging Mar 10 16:23:37 for some 7.5bit UART Mar 10 16:23:40 there are various level of where you can put the interface to arm Mar 10 16:23:54 you could put it at set_tx_level() Mar 10 16:24:03 that's what arduino would do Mar 10 16:24:15 and have arm generate the UART character Mar 10 16:24:22 but that's a bad thing to do with linux Mar 10 16:24:35 why? Mar 10 16:24:46 timing Mar 10 16:24:48 because the timing requirements Mar 10 16:24:49 or the lack thereof Mar 10 16:25:00 you could have a middle layer interface Mar 10 16:25:09 like transmit_uart_char() Mar 10 16:25:17 this is better Mar 10 16:25:31 because you guarantee the bit timing via the PRU Mar 10 16:25:46 pru.minebitcoin() Mar 10 16:25:49 but it's far from optimal because you will leave lots of gaps between characters Mar 10 16:26:23 I see! Mar 10 16:26:28 now, a better interface would be Mar 10 16:26:35 transmit_uart_block() Mar 10 16:26:58 cause you will make sure that even the inter-char delay is handled by the PRU Mar 10 16:27:15 Ah! yes. Mar 10 16:27:33 you can go even higher level Mar 10 16:27:47 you can submit descriptors of blocks to transmit Mar 10 16:27:47 ftp Mar 10 16:27:55 making sure that there are no gaps in the stream Mar 10 16:28:02 never gap the streams! Mar 10 16:28:14 mind the stream gaps Mar 10 16:28:47 if you take a high level view Mar 10 16:28:55 this is your standard DMA capable peripheral Mar 10 16:30:01 Basically put most of the logic in the PRU so it minimizes the number of times the kernel has to write via RPC; implying lesser delay and the PRU can carry out doing it's thing happily! Mar 10 16:30:17 Yes, like a DMA. Mar 10 16:30:17 yes Mar 10 16:30:32 the PRU is then like a very intelligent DMA peripheral Mar 10 16:31:30 smartDMA(tm) Mar 10 16:31:37 * av500 runs off to patent office Mar 10 16:31:51 av500, I'm pretty sure it has been done before Mar 10 16:32:09 this was the idea at the high level - the scripting part I was talking about earlier; yes the same thing. The only thing different was that we thought we'd start from simple blink functions. Mar 10 16:32:11 all the old freescale designs with a communication processor are like this Mar 10 16:32:23 karki, nothing stops you from starting there Mar 10 16:32:33 The scripting ensured that there is minimal write from the kernel side Mar 10 16:32:36 it's just not an efficient thing to do Mar 10 16:33:28 so once a command is issued; it could keep looping over to generate patterns. Mar 10 16:33:42 right Mar 10 16:33:44 or instance Mar 10 16:33:49 let's take the led example Mar 10 16:33:50 atleast this was what me and Alexander talked a while ago! Mar 10 16:34:19 like av500 said Mar 10 16:34:26 have something like pru.setLEDpattern() Mar 10 16:34:47 Yeah thats exactly the scripting part I had in mind :D Mar 10 16:34:50 which takes as an argument a series led pattern structs Mar 10 16:35:14 mranostay: I now divide the logic analyser into PRU capture, libsigrok based back end and a web based frontend. What do you think? Who would be able to assist us with the webapp side? Mar 10 16:35:14 Bot Speak does something similar. Mar 10 16:35:45 I am not familiar with that Mar 10 16:35:55 btw, do not do a python only interface Mar 10 16:36:06 me? Mar 10 16:36:12 anyone Mar 10 16:36:21 use something like libpru() Mar 10 16:36:34 a standard autotools based library Mar 10 16:36:37 written in C Mar 10 16:36:41 like libsoc does Mar 10 16:36:51 or even try to get your stuff in libsoc Mar 10 16:37:33 what is libpru? haven't looked at it as yet. Mar 10 16:38:03 there is none :) Mar 10 16:38:06 I wonder if jackmitchell would want pru stuff in libsoc Mar 10 16:38:08 maybe you should write it Mar 10 16:38:14 panto : how do you suggest I go about the client side? Mar 10 16:38:31 declare your RPC interfaces first Mar 10 16:38:44 and make thunk calls Mar 10 16:39:17 so the idea is that the ARM userspace program just calls a function in libpru with the same name as the function to execute at the PRU side Mar 10 16:40:41 but each one should be carefully considered as to how it can be optimally implemented on the pru side..to be better performing (in some way) than the equivalent running on the ARM Mar 10 16:40:51 otherwise it should not be offloaded to the PRU Mar 10 16:43:25 So the user space call gets translated to some value and internally is sent to the PRU, where the PRU reads the value, branches to the appropriate handler and starts execution! Mar 10 16:45:12 yes Mar 10 16:45:34 All the code on the PRU has to be handled using Assembly only? or is there a better option? Mar 10 16:46:02 assembly is the only "fully supported" option IMHO Mar 10 16:46:04 the drop in 3.8 angstrom has C Mar 10 16:46:42 yes, as we found out the compiler broke my code with the new updates Mar 10 16:48:04 Has anyone had a look at CorePy (http://corepy.org) ? Mar 10 16:48:32 It would be great if the PRU had some support like that ;) Mar 10 16:48:53 I would settle with a working free compiler Mar 10 16:49:05 generate assembly using higher level language code :) Mar 10 16:49:41 isn't that what a compiler does? Mar 10 16:49:52 It was my first idea when I thought about using PRU with a high level language. Mar 10 16:50:14 True, but this is much different, and easier to implement! Mar 10 16:50:34 panto, a free C compiler isn't a doable GSoC for most people Mar 10 16:51:36 CorePY is a python library which you can use to output assembly code! Mar 10 16:52:06 If only I had the skill to implement a complete C compiler in 3 month ;) Mar 10 16:53:33 it's not that hard really Mar 10 16:53:49 and the PRU is easy to write a compiler for Mar 10 16:54:05 all instructions are a single cycle Mar 10 16:54:38 I've worked a decent bit with compilers. but I don't know whether a full working C compiler is something I can do in three months! Mar 10 16:55:23 I've worked with parsers and code optimizers, but never built a full compiler :/ Mar 10 16:55:37 well, we're not talking about writting one from scrach Mar 10 16:55:39 *scratch Mar 10 16:56:57 but the chances of it being accepted as a GSoC project tends to nill! Most people will think it's too big. Mar 10 16:57:54 ok then :) Mar 10 17:00:46 Ok! coming back to the previous topic, is there any special way I can make use of the fact that I have 2 PRU's? With the firmware and RPC interface. Mar 10 17:02:34 panto? Mar 10 17:02:45 yes Mar 10 17:02:55 it's how I use it on the 3.8 kernel Mar 10 17:03:06 one PRU handles comms and soft-ish real-time stuff Mar 10 17:03:16 the other is doing the hard real-time loop Mar 10 17:03:34 https://github.com/pantoniou/testpru Mar 10 17:03:37 you seen this? Mar 10 17:03:47 and mranostay's led work? Mar 10 17:05:17 No, I hadn't. I'll have a look at it now. Mar 10 17:08:06 It looks like it'll be very helpful :) Thanks! which C compiler did you use? Mar 10 17:08:38 clpru? Mar 10 17:09:31 yes Mar 10 17:09:40 careful with the version Mar 10 17:09:45 sidbh can tell you all about it Mar 10 17:10:40 the newer versions are broken? is it a free software? Mar 10 17:11:09 no, it isn't Mar 10 17:11:14 they are not broken Mar 10 17:11:30 they modified the interface to the constant registers breaking my code Mar 10 17:12:49 I see. is it a free software? opensource? Mar 10 17:13:46 the compiler? Mar 10 17:13:55 or the testpru sources Mar 10 17:14:26 the compiler Mar 10 17:15:13 it's not open source Mar 10 17:15:15 it's TIs stuff Mar 10 17:16:18 So I can't use it for the GSoC? Mar 10 17:16:56 I don't know Mar 10 17:17:05 you should ask jkridner Mar 10 17:17:09 mdp seemed to not like the fact that a non open source tool was being used for GSoC Mar 10 17:17:10 but I don't see why not? Mar 10 17:17:31 jkridner : what do you say? Mar 10 17:18:37 I don't see a problem as far as the end work is open-source. Mar 10 17:18:49 well it isn't helpful if you can't build it :) Mar 10 17:19:55 I have no idea why TI is stalling on releasing it Mar 10 17:20:10 true. but it's free and also much simpler to maintain! Mar 10 17:20:19 perhaps they're waiting to have code composer working with it Mar 10 17:20:48 as in the firmware will be simpler to maintain. Mar 10 17:21:21 * sidbh thinks panto hit the mark :) Mar 10 17:21:40 stupid TI Mar 10 17:21:44 + once a opensource C compiler does come out, all the code can be ported with minimal effort. Mar 10 17:23:05 and if the firmware is written in PRU assembly, it will become redundant after a CC comes out. No one will want to maintain a assembly project when there is a C compiler staring at you :p Mar 10 17:23:20 not really Mar 10 17:23:33 you need to use assembly in parts Mar 10 17:24:15 but thats minimal as compared to having the whole project in PRU assembly! Mar 10 17:24:23 It's going to be huge! Mar 10 17:26:21 mranostay: i don't see any reason to use assembly if you can access all the requisite registers using C Mar 10 17:27:27 sometimes you need to be assured how many clock cycles you are using Mar 10 17:27:39 mranostay, +1 Mar 10 17:27:44 not depend on the C compiler version Mar 10 17:27:46 please be aware of this Mar 10 17:27:54 you can do loops with C Mar 10 17:28:04 but you can't be as accurate as with assembly Mar 10 17:28:09 however Mar 10 17:28:17 you can be pretty damn accurate even with C Mar 10 17:28:35 for reference https://github.com/mranostay/ws28xx-lighting-pru Mar 10 17:28:36 the pwm example is accurate to the microsecond with 10 pwm software channels Mar 10 17:28:55 if you need higher accuracy you have to use assembly Mar 10 17:30:16 for the WS281x LEDs you have to use assembly Mar 10 17:33:30 jkridner: accept my gsoc connection Mar 10 17:33:41 i wonder what if we control the ecap connected to main core with PRU to generate PWM Mar 10 17:35:14 obviously we have to disconnect the peripheral totally from the linux interference to do that Mar 10 17:36:35 sidbh: check the datasheet.. not sure if that is correct offhand Mar 10 17:37:55 panto : I found a lot of documentation of TI that shows ARM and PRU interactions using UIO; have they any updated documentation with remoteProc put up? Mar 10 17:38:13 not as far as I know Mar 10 17:39:13 which libraries do you suggest I use for the project? to handle interaction between the PRU and linux? Mar 10 17:39:42 mranostay: we can access the peripheral external to it i guess, all the peripherals are mapped to its memory, just don't know how much latency will be induced Mar 10 17:43:20 panto : should I go for UIO or remoteProc ? Mar 10 17:44:45 karki: remotedproc! Mar 10 17:45:38 remoteproc Mar 10 17:46:04 UIO is not going to be nice when you find out you have to handle the cache coherency by yourself Mar 10 17:47:36 what exactly is remoteProc. I don't know much about it, couldn't find the right documentation! Mar 10 17:49:18 https://www.kernel.org/doc/Documentation/remoteproc.txt Mar 10 17:58:12 thanks! Mar 10 17:59:17 does firmware loading work reliably on ARM? Mar 10 18:00:23 ? Mar 10 18:00:37 ds2: why wouldn't it? Mar 10 18:00:44 maybe I have a broken userland Mar 10 18:00:48 it rarely works for me Mar 10 18:01:07 ds2, there's a trick/bug Mar 10 18:01:13 panto: eh? Mar 10 18:01:14 the firmware is cached Mar 10 18:01:36 I see requests but can't seem to consistantly see udev or the older equiv being called reliably Mar 10 18:01:36 so if you try to load a firmware file Mar 10 18:01:48 udev firmware loading is deprecated Mar 10 18:02:04 the kernel now directly loads from the fs Mar 10 18:02:04 what's the firmware loading method dejour? Mar 10 18:02:20 direct load from filesystem Mar 10 18:02:24 oh.. so it would need the real absolute path? Mar 10 18:02:30 panto: also the annoying BBB needing it builtin Mar 10 18:02:35 in /lib/firmware/`uname -r`, /lib/firmware Mar 10 18:02:37 i.e. it would fall flat if it is dealing with chroot? Mar 10 18:02:43 yes Mar 10 18:02:50 that explains that Mar 10 18:02:54 cause the kernel is outside the chroot jail Mar 10 18:03:13 yes, I understand that and the kernel has no way of knowing which chroot it should use anyways Mar 10 18:03:38 I miss the days of nice simple .h files being compiled in Mar 10 18:03:46 you can still do that Mar 10 18:03:52 BUILTIN_FIRMWARE Mar 10 18:03:57 panto : I read up the link you gave, understood the basic remoteproc framework! are there any concrete examples for the PRU specifically? Mar 10 18:04:07 3.8 kernel sources are your friend Mar 10 18:04:08 I know about BUILTIN_FIRMWARE...that's my work around Mar 10 18:04:09