**** BEGIN LOGGING AT Wed Jul 20 02:59:58 2016 Jul 20 03:02:23 so has anybody looked at changing the pinconfig from the PRUs? I have some lines that are used for both input and output Jul 20 04:31:10 you mean from pru code? Jul 20 05:37:18 nerdboy: yeah. I guess I could include a whole new set of synchronization between PRU/ARM for it but I'd rather not Jul 20 05:39:13 which pins? Jul 20 05:40:03 you need to change pin config repeatedly? Jul 20 05:40:15 that doesn't sound right... Jul 20 05:40:34 what pin modes? Jul 20 05:42:20 Wormo, nerdboy: the D0-D11 pins. need em pruout for config (occurs during each axis change) and pruin for reading results Jul 20 05:42:20 https://e2e.ti.com/support/arm/sitara_arm/f/791/t/445028 Jul 20 05:42:45 "The PRU does not have privileges to edit the pinmux or pad config settings in the device-level Control Module. However, the PRU can read these registers. Jul 20 05:42:48 " Jul 20 05:43:27 bleh. alright Jul 20 05:43:42 still doesn't sound right Jul 20 05:43:51 what do you mean doesn't sound right? Jul 20 05:44:21 how often/fast are you changing the mode? Jul 20 05:44:50 pretty often... the config stuff is used to do things like select the channel Jul 20 05:45:15 My suggestion was to read both channels and throw away the unused one Jul 20 05:45:19 is your drawing still accurate/current? Jul 20 05:45:34 if you read both channels you cut your sample rate in half Jul 20 05:45:47 yes, is that too low? Jul 20 05:47:55 nerdboy: not if I need to go to the ARM to do pinmux changes. but that's the only thing that'd be off Jul 20 05:49:07 Wormo: in practice hard to say... not sure where the lowest accuracy step of this is going be. let me see what the theoretical limit for 3MSS/s is Jul 20 05:49:15 Ok Jul 20 05:59:36 Wormo: well, I guess that might be right on the edge - at least if we're keeping up nerdboys early hopes of 0.1 m/s acurracy. a 0.1 m/s difference would show up one cycle different (assuming I Haven't stuffed up the math) Jul 20 05:59:53 (on the edge in a perfect world, I mean) Jul 20 06:00:18 Ok well I think it's the sanest approach for the current iteration Jul 20 06:00:30 can't go for perfect with weeks to go after all Jul 20 06:01:18 well, still need some synchronization with the ARM even with reading both channels at once. it just means doing it once rather than repeatedly Jul 20 06:01:50 Assuming there is a configuration bit that is mandatory to change Jul 20 06:02:58 reset is mandatory, but the evm appeared to allow doing that with a separate output-only pin Jul 20 06:04:01 looking to see what the default channel select is... Jul 20 06:05:28 wormo: kinda looks to me like it comes up in a non-functional config Jul 20 06:05:44 too bad Jul 20 06:06:33 or at least one they didn't bother to include in their table of input descriptions (that's half reserved anyway) Jul 20 06:06:59 docs do talk about using it without a config step after the reset though. but hey, TI... Jul 20 06:07:08 looks like a differential channel Jul 20 06:07:21 not two channels Jul 20 06:07:21 oh, they flipped the order of two things Jul 20 06:07:49 00100 Jul 20 06:08:05 why wouldn't you have your docs say DIFF0, DIFF1 in one place and DIFF1, DIFF0 the next page... Jul 20 06:08:23 so what you said applies, can't get around changing the config at least once Jul 20 08:06:03 Abhishek_: Wormo : Hi ! Jul 20 08:06:17 ...... Jul 20 08:08:29 Hi ds2 Jul 20 08:16:22 nice web posts Jul 20 08:16:30 ZeekHuge ^^ Jul 20 08:23:22 hi ZeekHuge Jul 20 08:23:45 Hey ! ah .. hows you ? read the report ? Jul 20 08:23:56 like I said good posts, want to talk about the organization of the next one? sometimes it helps to talk it out Jul 20 08:24:38 Yup was reading it when you logged in Jul 20 08:25:27 Yeah sure. we can talk on the next post. Jul 20 08:25:48 whats about the work ? Jul 20 08:25:51 *what Jul 20 08:26:02 sorry? Jul 20 08:26:10 what work? Jul 20 08:26:30 I mean .. I didn't actually do anything na .. Jul 20 08:26:33 :( Jul 20 08:26:44 Its okay sometimes I guess ? Jul 20 08:26:48 docs isn't nothing, it's not bad you didn't put it all off to the last week Jul 20 08:27:10 Okay. Jul 20 08:27:35 So the next post I was thinking was about the inline_pru example Jul 20 08:27:35 it's often underappreciated part of community building in fact Jul 20 08:27:47 Ok that sounds good Jul 20 08:28:08 But .. that basically involves explaining the compiler options Jul 20 08:28:20 but will that be useful ? Jul 20 08:28:29 yes Jul 20 08:28:59 I am thinking to skip this and make work on post to communication. Jul 20 08:29:00 if it's not obvious and you took time to get it right, it's worthy of explaining for future PRU projects Jul 20 08:29:04 *for communication Jul 20 08:29:12 okay. Jul 20 08:29:13 rpmsg stuff? Jul 20 08:29:17 yes Jul 20 08:29:48 rpmsg is a great topic, but maybe the other won't take too long Jul 20 08:30:25 having an accompanying blog post does make the example more useful Jul 20 08:31:16 you'll want to put links into your README so that ppl trying to use the examples realize that there is some specific relevant tips over in the blog area Jul 20 08:31:18 yes. that is true. And the questions asked there on the mailing list makes it more interesting .. Jul 20 08:31:30 okay. Jul 20 08:32:04 links to further discussions on mailing list are helpful too Jul 20 08:32:08 just one offtopic question... we can do nesting in git repos. isnt it ? Jul 20 08:33:01 in *theory*, but I'm still not so comfortable with git subprojects Jul 20 08:33:47 they don't behave like I wish, you need to find some aliases to make it at all manageable Jul 20 08:34:18 nerdboy has some useful aliases for git submodules, if you do want them he or I can dig them up Jul 20 08:35:17 another option for multiple repos with a relationship together is the 'repo' command Jul 20 08:35:47 okay. Jul 20 08:36:00 I know, named so uniquely to help in searches :) Jul 20 08:36:45 So alias in the sense ? its another utility ? Jul 20 08:37:21 git has aliasing capability, you can write 'git aliases' for submodules Jul 20 08:37:36 'repo' is a different utility altogether, goes on top of git Jul 20 08:38:02 google uses it for android sdk, they may have invented it Jul 20 08:38:17 first place I saw it anyways Jul 20 08:38:28 yes.. I just saw that . Jul 20 08:39:10 okay, I will look into it. Jul 20 08:39:22 and i have been using vim a lot Jul 20 08:39:23 lets you check out multiple git repos at versions that are known to work together Jul 20 08:39:37 and I have mapped a lot of commands Jul 20 08:39:49 *lot of shortcut keys Jul 20 08:40:03 I think you are a power user by now, after only a few months :D Jul 20 08:40:43 and a few commands like, when i write :commit, it starts spell check , a border at column =80 and so on Jul 20 08:41:30 but, is there a way I can just go into some directory and vim automatically pics up some configuration info Jul 20 08:41:36 ? Jul 20 08:41:51 based on the directory ? Jul 20 08:42:09 I recall there is, but would have to look it up, I usually use the one .vimrc Jul 20 08:43:14 there it is, see :help vimrc Jul 20 08:43:45 "If the 'exrc' option is on (which is not the default), the current directory is searched for three files." Jul 20 08:45:02 What is Amiga ? never heard of it .. Jul 20 08:45:52 Hm! Classic computer Jul 20 08:46:27 made by Commodore who did the "Commodore 64" very widespread home computer here in the US Jul 20 08:47:25 Okay. Jul 20 08:49:00 I'm not really sure if I believe the latest vim releases still run on OS/2 and Amiga :-) Jul 20 08:50:18 Visaoni: https://www.zeekhuge.me/post/ptp_docs_commands_and_tools/ Jul 20 08:50:46 check out the PRU debug section Jul 20 08:53:20 singlestep stuff looks like it could be nice Jul 20 08:53:48 indeed Jul 20 08:55:23 yeah .. it took lot of time to figure out the stuff... combination of reading pru reference material + pru_rproc source + testing it myself Jul 20 08:55:42 and same with the 'regs' entry Jul 20 08:56:08 good stuff Jul 20 08:57:05 I don't doubt it Jul 20 09:02:08 The page is still not completely secure ... it shows an exclamatory mark :/ .. there is no content being fetched from other place or on an in-secured network. Jul 20 09:04:15 ZeekHuge: Jul 20 09:04:29 See the http:// Jul 20 09:04:58 oh ! okay .. firefox was blocking it ... therefore it wasnt showing in my console. Jul 20 09:05:06 Thank you :) Jul 20 09:05:12 your welcome Jul 20 09:05:21 er you're Jul 20 09:11:57 ZeekHuge: By this Friday I hope to see a plan from you on what you plan to complete by your next weekly report. Consider it your mid-weekly report just for this week as you haven't described your next steps in detail. Jul 20 09:12:30 I may not be there in Wednesday's meeting but will go through the logs later. Jul 20 09:13:36 Abhishek_: Okay. Will do. Jul 20 09:35:02 website is secured now. Jul 20 09:35:07 completely Jul 20 13:56:56 howdy... I have a meeting at our meeting time today. :) Jul 20 13:57:00 er, :-( Jul 20 13:57:09 _av500_: ^^^ Jul 20 13:59:47 <_av500_> jkridner-web: and I am at a conf :( Jul 20 14:00:02 <_av500_> i hope alex or nerdboy can fill in Jul 20 14:00:51 _av500_: jkridner-web, mdp: I may not be able to make the meeting today, I have an unexpected doctor's visit (not for the baby) Jul 20 14:01:53 nerdboy: you might be our only hope! Jul 20 14:22:20 * nerdboy has a dentist appt @ 0800 Jul 20 14:22:46 supposed to be m_w and alex-in-the-car Jul 20 14:39:44 <_av500_> nerdboy: ok Jul 20 15:00:26 [alexanderhiam] t-1hr? Jul 20 15:02:38 <_av500_> gcl-bot: yes Jul 20 15:31:02 so I will be running the meeting today Jul 20 15:36:45 <_av500_> thx :) Jul 20 15:46:33 howdy m_w, we leading the meeting today? Jul 20 15:46:52 yeah I said I would take it Jul 20 15:47:28 checking the reports now, and working up the bullet points Jul 20 15:48:01 cool. I'm driving across indiana atm, not sure how my service will hold up Jul 20 15:48:33 you got any topics that need to come up today? Jul 20 15:48:42 is it the last meeting?? Jul 20 15:49:09 I don't think so Jul 20 15:49:21 what would make you believe that? Jul 20 15:49:26 k. _av500_'s email had me worried Jul 20 15:50:28 he wanted to bring that up early so people make sure their URLs are ready for the final Jul 20 15:51:21 makes sense Jul 20 15:52:19 chanakya_vc: did you submit a weekly report? Jul 20 15:52:28 yup m_w Jul 20 15:52:38 sent it yesterday only Jul 20 15:52:52 didn't appear on the ml? Jul 20 15:53:26 I see it there Jul 20 15:54:02 okay good Jul 20 15:54:09 https://groups.google.com/forum/#!topic/beagleboard-gsoc/yeWytc2SmvI Jul 20 15:57:22 hello everyone Jul 20 15:58:22 greetings pmezydlo Jul 20 16:00:37 coffee time before meeting :) Jul 20 16:00:54 okay lets do this Jul 20 16:01:12 0) WELCOME Jul 20 16:01:22 roll call Jul 20 16:01:25 hi Jul 20 16:01:29 hi Jul 20 16:01:35 hello ! Jul 20 16:01:52 namastey everyone Jul 20 16:03:05 only 4 today? Jul 20 16:03:44 kiran4399, kiran4399_: ping? Jul 20 16:03:53 Visaoni? Jul 20 16:04:13 Sorry.. Jul 20 16:04:19 I am here.. Jul 20 16:04:25 5 Jul 20 16:05:49 hey Jul 20 16:05:52 hi Jul 20 16:05:56 6 Jul 20 16:06:47 amragaey? Jul 20 16:07:11 looks like he is absent Jul 20 16:07:20 lets move on Jul 20 16:07:35 1) final eval URLs Jul 20 16:08:06 av500 want to make sure that everyone had an early heads up Jul 20 16:08:10 wanted Jul 20 16:08:43 there is a new requirement this year for the final deliverables Jul 20 16:08:55 m_w: what is it? Jul 20 16:08:59 " Jul 20 16:09:02 In previous years, students were required to upload their work to the program website (as a zip or tar file). This year, as part of their final evaluations, students will provide a single URL to the code they produced. Then, as part of their final evaluation of the student, mentors will validate the target of the URL (provided in the evaluation), making sure it points to the GSoC 2016 work product and mee Jul 20 16:09:09 ts the other requirements. Jul 20 16:09:11 " Jul 20 16:09:33 for most of you this should be your github repository Jul 20 16:10:25 and if you can't consolidate everything into one, perhaps make a separate repo with an intro and links to the everything Jul 20 16:10:33 Ok.. that sounds cool. Jul 20 16:11:01 makes a lot more sense than the archive Jul 20 16:11:08 just make sure that all of your work is accessible from the URL that you provide Jul 20 16:11:28 with ample documentation Jul 20 16:11:37 #exactsteps Jul 20 16:11:52 2) general issues Jul 20 16:12:30 anyone stuck? Jul 20 16:12:56 yeah, I still have kernel crashs due to dsp firmware... Jul 20 16:13:49 henrix_: okay we can try to take a look after the standup reports Jul 20 16:14:01 ok Jul 20 16:14:10 anyone else? Jul 20 16:14:40 Hi all Jul 20 16:15:01 hi Jul 20 16:15:04 hey rma_ Jul 20 16:15:13 rma_: anything to report? Jul 20 16:15:24 all good here Jul 20 16:15:38 okay lets move on again Jul 20 16:16:08 3) standup reports Jul 20 16:16:20 who is up today? Jul 20 16:16:57 I guess its me. Jul 20 16:17:11 okay you have the floor Jul 20 16:17:42 alright.. so.. Jul 20 16:17:57 you all must've gone through the weekly report.. Jul 20 16:18:24 so what I've done for the last 10-15 days is writing the kernel driver and servo firmware for the pru Jul 20 16:18:37 the kernel driver will provide 8 sysfs entries for the servo Jul 20 16:18:40 just like pwm Jul 20 16:18:57 8 sysfs entries for 8 different channels.. Jul 20 16:19:11 currently for each channel directory.. Jul 20 16:19:20 there is only 1 file.. in_servo Jul 20 16:19:37 kiran4399_work_: a quick overview of the motor outputs and why soft-PWM PRU firmware is needed would be good Jul 20 16:19:39 which takes in the duty cycle of the 50 hz pulse you want to put on the channel Jul 20 16:20:49 well, you all know that servo outputs should be a series of high frequency pulses.. Jul 20 16:21:06 so using hard pwm at this frequency would'nt be good.. Jul 20 16:22:02 and even then, it would be much better if we allow this pulse generating module to work independently of the main arm core.. so this is how pwm comes to the picture Jul 20 16:22:13 well, the PWMSS works fine for servos.. I just mean that the PWMSS outputs are in use for the DC motor drivers Jul 20 16:22:28 ok.. Jul 20 16:22:32 alexhiam: :-P Jul 20 16:22:35 sorry.. Jul 20 16:22:39 yeah.. alexhiam is right. Jul 20 16:22:50 since ehrpwm module is busy serving the dc motors.. Jul 20 16:22:59 we use softpwm in pru for servo.. Jul 20 16:23:08 * amragaey is saying hi, apologizing for being late Jul 20 16:23:10 that sounds better ;) Jul 20 16:23:18 so this is how the pulses work.. Jul 20 16:23:45 great Jul 20 16:23:53 https://github.com/kiran4399/bbb_pru_firmware/blob/master/servo_pru.c Jul 20 16:23:58 as you can see.. Jul 20 16:24:21 there is an outer loop which goes through all the 8 ports.. Jul 20 16:24:46 and sets the corresponding bit for the port high or low depending on the duty cycle.. Jul 20 16:25:09 so basically.. we choose a dt interval.. Jul 20 16:25:20 in our case 1/200 Jul 20 16:25:49 and the period as 1/50. Jul 20 16:25:58 because the frequency of the pulse is 50 hz.. Jul 20 16:26:28 so this is not a general purpose PWM? Jul 20 16:26:39 alexhiam: btw.. should the dt be 1/200000000? Jul 20 16:26:52 because the frequency of pru is 200 Mhz Jul 20 16:26:52 ? Jul 20 16:27:00 rc servo ctrl? Jul 20 16:27:09 ds2: yeah.. Jul 20 16:27:24 no need to be that fast Jul 20 16:27:45 what's the max resolution you would need? 0.5%? Jul 20 16:27:52 alexhiam: yeah.. Jul 20 16:28:38 so dt = 1/10000 Jul 20 16:29:17 ok so you convert the user given duty cycle to real pulse time.. Jul 20 16:29:37 and you decrement the time and set the corresponding mask to 1 for the pin.. Jul 20 16:30:01 btw.. the pulse time for each pin gets decrement by the dt.. Jul 20 16:30:16 as the pulse time for a pin comes to 0. Jul 20 16:31:24 you clear the corresponding bit for a servo port to 0 until it reaches a point after which you will reset the pulse time to the original time.. Jul 20 16:31:37 this is the story for firmware.. Jul 20 16:32:24 I see a bug in the firmware Jul 20 16:32:34 looping from 1? Jul 20 16:32:47 for the kernel driver.. It creates the sysfs entries and boots up the pru elf firmware(bin is not supported by remoteproc) and takes the user given value to the shared memory. Jul 20 16:32:51 "for(pin=1;pin<=SERVO_NUM_PIN;pin++)" Jul 20 16:32:56 should be Jul 20 16:33:03 "for(pin=0;pin you are indexing past the end of the array Jul 20 16:33:22 m_w: ok.. sorry.. I'll fix it.. Jul 20 16:33:37 m_w: I thought using the original pin values.. from 1 to 8.. Jul 20 16:33:37 so.. Jul 20 16:33:42 anyway.. I'll change it.. Jul 20 16:34:28 so as I was saying.. Jul 20 16:34:29 if you do use it that way you will need pulse_width[SERVO_NUM_PIN+1] Jul 20 16:34:34 go ahead Jul 20 16:34:40 yeah.. Jul 20 16:36:09 so once the duty cycle is given by the user it writes to the kernel memory space which is mapped to 0x4a310000 in the shared mem by ioremap Jul 20 16:36:18 the firmware then takes the value.. Jul 20 16:37:29 lastly, for taking the dutycycle as inputs.. servo_api is written which simply opens the sysfs and puts the value there.. Jul 20 16:37:40 any questions anyone? Jul 20 16:38:21 it appears not Jul 20 16:38:43 okay then who is up next? Jul 20 16:40:27 ???????????? Jul 20 16:40:51 who hasn't done a 3rd(?) update? Jul 20 16:40:56 or is this #2? Jul 20 16:41:06 2 nd I guess alexhiam Jul 20 16:41:29 I think only one person reported last time Jul 20 16:41:55 amragaey_: have you done a second report? Jul 20 16:42:06 * Visaoni can't remember if he has done a 2nd or not Jul 20 16:42:22 go ahead then Visaoni Jul 20 16:42:24 m_w, I sent my report today Jul 20 16:42:27 no need to remember.... could just volunteer ;) Jul 20 16:42:59 alright Jul 20 16:43:22 I will tally up the number for each student Jul 20 16:43:47 but go ahead Visaoni Jul 20 16:44:01 so, I finally finished wading through a bunch of junk with rpmsg Jul 20 16:44:20 m_w, Am i missing something ? Jul 20 16:44:56 amragaey: I was referring to the standup reports Jul 20 16:45:10 I found some uh, interesting things along the way. such as some auxilary functions I wrote to allow me to clear/set individual bits in __R30 apparently ran into some compiler bug Jul 20 16:45:32 I was able to clear pins but not set them. fixed by turning them all into macros Jul 20 16:45:37 so uh, watch out? Jul 20 16:45:38 m_w, aha I didn't do a second one, I did the first one with chanakya_vc Jul 20 16:46:20 amragaey: go first next week Jul 20 16:46:36 m_w, ok Jul 20 16:46:50 Visaoni: which compiler? Jul 20 16:47:00 ti Jul 20 16:47:13 pru stuff Jul 20 16:47:27 * Visaoni should have mentioned that Jul 20 16:47:54 okay send a bug report Jul 20 16:48:57 don't suppose you know where it should go? save me some poking around Jul 20 16:49:22 bye, i have to go. i'll be back in an hour Jul 20 16:49:49 ellaborate on the ML and I will will see if I can find a channel for the report Jul 20 16:50:02 pmezydlo: okay Jul 20 16:50:28 alright. I didn't investigate too much, but I can take another look Jul 20 16:50:44 anyway, other than that, the main issue seemed to be basic stack smashing with some temporary buffers. they caused different symptoms in the real code and some tests I threw together which was a real pain Jul 20 16:51:08 with that and a few minor things cleared up, the rpmsg stuff seems to be in fine order Jul 20 16:51:38 good Jul 20 16:51:40 I was also having some problems being unable to read my IMU Jul 20 16:51:45 turns out it was a bad IMU Jul 20 16:52:01 so that's cleared up as well Jul 20 16:52:38 anything else? Jul 20 16:52:57 nothing I didn't touch on my status update Jul 20 16:53:10 *in Jul 20 16:53:59 anyone else have any closing questions or remarks? Jul 20 16:55:13 how many more work weeks? Jul 20 16:55:37 good question lets see Jul 20 16:56:33 finals week is august 15th-23rd Jul 20 16:57:04 4 weeks and a few days Jul 20 16:57:15 does that include that 1 week for docs/cleanup? Jul 20 16:57:25 So m_w Just one question, we won't be able to submit any work in the final eval week? Jul 20 16:57:41 Like everything has to be done by 15? Jul 20 16:57:55 "Final week: Students tidy code, write tests, improve documentation and submit their code sample. Students also submit their final mentor evaluation." Jul 20 16:58:17 15 August - 23 August 19:00 UTC Jul 20 16:58:41 I would try your best to have the code ready by the 15th Jul 20 16:59:17 Okay m_w Jul 20 16:59:19 leaving ample time for documentation and evaluation Jul 20 17:00:38 so that wraps it up for this week's meeting Jul 20 17:00:38 * nerdboy is back, clean but gritty Jul 20 17:01:43 time for technical issues? Jul 20 17:01:49 henrix_: you want to discuss the memory issue you are having and see if we can shed some light? Jul 20 17:01:52 yes Jul 20 17:02:19 ok, so I checked the reserved memory area in ti opencl doc Jul 20 17:02:28 http://downloads.ti.com/mctools/esd/docs/opencl/memory/ddr-partition.html#am57 Jul 20 17:02:51 when cmemk module is loaded i can verify the memory in /proc/iommu Jul 20 17:02:58 80000000-9fffffff : System RAM Jul 20 17:02:58 80008000-80a876ab : Kernel code Jul 20 17:02:58 80b0e000-80ce9b9f : Kernel data Jul 20 17:02:58 a0000000-a9ffffff : CMEM Jul 20 17:02:58 aa000000-ffcfffff : System RAM Jul 20 17:03:00 fff00000-ffffefff : System RAM Jul 20 17:03:12 the memory area of cmem is identical with ti doc Jul 20 17:03:16 so, this should be fine Jul 20 17:03:23 but still kernel crashs Jul 20 17:03:42 for testing i used the asoc simple-card module to use our audio card Jul 20 17:03:45 same problem Jul 20 17:03:56 strange Jul 20 17:04:18 so the bug should be in cmem or iommu module or something like that Jul 20 17:04:54 but i have no more ideas how to find the origin of the bug Jul 20 17:05:03 hi jkridner-web Jul 20 17:05:06 tested several kernel versions as well Jul 20 17:05:34 weather opencl is not working (so dsp can't be used) or kernel crash when triggering audio card Jul 20 17:06:13 i had the idea to test a kernel directly from ti Jul 20 17:06:21 :D Jul 20 17:06:38 but no defconfig:-P Jul 20 17:06:56 so thats my problem Jul 20 17:07:38 you have a link to your latest devicetree? Jul 20 17:08:16 moment Jul 20 17:08:18 will push Jul 20 17:11:29 http://pastebin.com/YfudUe7g Jul 20 17:16:52 do you need the dma bindings for that? Jul 20 17:17:13 seems a little thin for all that stuff... Jul 20 17:19:27 or clock bindings maybe Jul 20 17:20:03 * nerdboy hacking device trees into tiny bits yesterday Jul 20 17:20:14 no, I created / modified only sound2, mcasp2_pins_default, mcspi3_pins_default, mcspi3 and mcasp2 node. Jul 20 17:20:50 you have cmem and other stuff too Jul 20 17:21:15 yes, but this is from default device tree from bbx15 Jul 20 17:22:57 what about dt-bindings/clk/ti-dra7-atl.h ? Jul 20 17:24:37 it's not included in any parents Jul 20 17:25:05 * nerdboy has no idea about bbx15/draXX just asking... Jul 20 17:27:39 clocks are configured in dra7xx-clocks.dtsi Jul 20 17:30:09 neither of which is included in any parent of your dt Jul 20 17:33:38 henrix_: do you have a pastebin of the error that occurs? Jul 20 17:34:26 yes, moment Jul 20 17:35:25 http://pastebin.com/LiheUmFK Jul 20 17:36:18 error 0x00000002 is TRANSLATIONFAULT according to am5728 TRM Jul 20 17:38:52 http://pastebin.com/2iW9t5Gd Jul 20 17:39:12 and this is the error when kernel crashs Jul 20 17:40:55 it's strange that snd_soc_ad193x_spi (codec module for our soundcard) and snd_soc_simple_card (onboard audio) are linked to cmemk module Jul 20 17:47:43 sorry my internet is really flakey today Jul 20 17:49:13 did you get the last 2 pastebin urls? Jul 20 17:49:31 yes Jul 20 17:49:46 I can look them up in the logs Jul 20 17:49:55 henrix_: crash is in rproc_trigger_recover function, perhaps you should build a kernel with extra debug where the crash is detected, before kernel attempts the reset which is apparently buggy Jul 20 17:50:04 learning more about the translation faults Jul 20 17:50:25 ok Jul 20 17:50:34 I mean extra debug where the *rproc crash* is detected, before the attempt to recover from that problem leads into an oops Jul 20 17:50:57 ok Jul 20 17:51:11 cascade of problems triggered by the original rproc problem -- recovery paths are often not so well tested Jul 20 17:51:25 will look for some kernel config parameters Jul 20 17:51:32 for more debug output Jul 20 17:51:53 I would do that and also probably instrument the function that calls rproc_trigger_recovery Jul 20 17:53:09 another possibility is to turn on a kernel debugger to try going back up the stack and looking at local variables in the caller of rproc_trigger_recovery Jul 20 17:53:31 stack doesn't look particularly corrupt at that point Jul 20 17:54:06 ok Jul 20 17:55:10 hm looks like the recovery got started as a separate background task from where error was detected Jul 20 17:56:26 so finding in the code where this happens is a good idea, can put custom printfs or even a breakpoint there if using the debugger option Jul 20 17:57:02 by printfs I mean printks of course, debugging by printfs kernel-style Jul 20 17:57:39 ok Jul 20 17:58:22 I take it the initial oops message (before cascading into secondary errors) is quite consistent? Jul 20 17:59:30 the part where it fails unregistering a virtio device to attempt rproc recovery Jul 20 18:04:05