**** BEGIN LOGGING AT Tue Jul 05 02:59:59 2016 Jul 05 04:14:26 ds2: Abhishek_ m_w : there ? Jul 05 04:15:10 or nerdboy ? Jul 05 04:15:28 what's up? Jul 05 04:16:37 nerdboy: hi ! have a doubt here https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/firmware/main_pru1_def.asm#L222 Jul 05 04:17:16 So you see .. to take a sample, I have toggled the clk pin, so it will be HIGH Jul 05 04:17:29 and then toggled it back, so that it will be low Jul 05 04:18:05 the clock will have the least duty cycle, that we need Jul 05 04:18:17 the question is, will it work ? Jul 05 04:18:36 I mean, is it enough time to take a sample ? Jul 05 04:19:13 try it and see Jul 05 04:19:22 * nerdboy not asm guy Jul 05 04:20:31 ZeekHuge: can you measure the duty cycle with a scope? Jul 05 04:20:43 yeah. Jul 05 04:21:24 ZeekHuge: what does it look like? frequency , duty cycle? Jul 05 04:21:43 .. ? Jul 05 04:21:52 on the scope Jul 05 04:22:08 I haven't measured it yet, but I can do. Jul 05 04:22:10 okay Jul 05 04:22:47 what is the maximum frequency clock that you can produce? Jul 05 04:24:47 so the scope just shows up the pulses on its screen and I can precisely measure the distances in that screen ... so can calculate duty cycle Jul 05 04:25:01 measure distances like this : https://postimg.org/image/6eysheu9j/ Jul 05 04:25:46 that looks close to 50% duty cycle Jul 05 04:26:06 no ! that is not the signal I am talking about Jul 05 04:26:24 do you really need the second CLK_TOGGLE in take sample? Jul 05 04:26:51 er, do you really need 2 Jul 05 04:26:59 m_w: the signal that this code generates : https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/firmware/main_pru1_def.asm#L222 Jul 05 04:27:30 ahh .. yeah . one to send a HIGH and then to make it LOW Jul 05 04:28:10 There needs to be a clock signal to get the data out of ADC Jul 05 04:28:14 isnt it ? Jul 05 04:28:19 nerdboy: ^ Jul 05 04:28:49 CLK_TOGGLE just toggles the state of CLK_PIN and it take only one cycle Jul 05 04:29:27 this code would produce a 2/3 duty cycle Jul 05 04:30:03 or 1/3 depend on the state of the line before the marco is called Jul 05 04:30:21 ahh ... no actually . The Time period is configurable Jul 05 04:30:44 https://github.com/ZeekHuge/BeagleScope#firmware Jul 05 04:30:54 okay, let me please put the question again. Jul 05 04:31:23 The current state of the firmware allow to have a configurable sampling frequency Jul 05 04:31:36 just looking at it and wondering if you shouldn't reset/toggle the clock pin elsewhere and set it high after each SAMPLE_8 Jul 05 04:31:48 more or less Jul 05 04:31:58 So ofc the time period will be configurable. Jul 05 04:32:02 * nerdboy not really sure how that stuff is normally done Jul 05 04:32:42 maybe SAMPLE_CYCLE_8 should have more "clock" control Jul 05 04:32:56 though the time period is changing the time for which the clock signal remains HIGH is only 10 nsec Jul 05 04:33:29 if you don't put a dummy instruction after the second CLK_TOGGLE the clock will never be 50% duty cycle Jul 05 04:34:29 * nerdboy would probably make a diagram Jul 05 04:35:03 you need to delay half of the half of the period after each clock toggle Jul 05 04:35:12 but that's an exercise left for the student... Jul 05 04:35:31 maybe a timing doagram? Jul 05 04:35:32 minus the instruction delay on the first toggle Jul 05 04:35:37 *diagram even Jul 05 04:38:45 this code is going to have tiny pulses for each sample Jul 05 04:38:58 yeah .. that is .. Jul 05 04:39:11 that is what i am asking will work Jul 05 04:39:34 that depends on ADC and the length of the pulse Jul 05 04:40:31 looks like 2 system clocks Jul 05 04:40:53 what is the time per instruction? Jul 05 04:41:01 5nSec Jul 05 04:41:09 2 system clocks ? Jul 05 04:41:23 10ns then Jul 05 04:41:55 yes , so for this code the clk is HIGH for 10ns Jul 05 04:42:02 okay Jul 05 04:42:20 what is the part number of the ADC? Jul 05 04:42:31 and in that 10ns, we have a 5ns window where the sample is taken Jul 05 04:42:33 okay Jul 05 04:42:37 just a minute Jul 05 04:43:14 http://cds.linear.com/docs/en/demo-board-manual/dc782A.pdf Jul 05 04:43:21 782A-P Jul 05 04:43:30 and this http://cds.linear.com/docs/en/datasheet/223876fa.pdf Jul 05 04:43:44 which adc is on yours? Jul 05 04:44:37 http://cds.linear.com/docs/en/datasheet/22510fa.pdf Jul 05 04:44:51 LTC2236 Jul 05 04:45:17 http://cds.linear.com/docs/en/datasheet/223876fa.pdf Jul 05 04:45:41 look at the TIMING CHARACTERISTICS table Jul 05 04:45:53 yeah Jul 05 04:46:54 with the duty cyle stabilizer off the minimum CLK low time is 18.9ns Jul 05 04:47:44 with the duty cyle stabilizer on the minimum CLK low time is 5ns Jul 05 04:49:01 so there is your answer, no and yes. Jul 05 04:49:03 :) Jul 05 04:49:04 okay .. that was what i looking for. I will go through the table and be back with more question. Jul 05 04:49:04 one more question Jul 05 04:49:19 it is said that each instruction take 5ns on PRU Jul 05 04:49:26 okay Jul 05 04:49:49 so our assumption that clk will be HIGH for 10ns is correct ? Jul 05 04:49:56 according to the code there ? Jul 05 04:51:50 is the clock low before the macro starts? Jul 05 04:52:02 but, since this timing of the clk pin depends on the ADC or part we are using, it should be configurable as well. Jul 05 04:52:24 yes it is https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/firmware/main_pru1_def.asm#L31 Jul 05 04:53:17 then it should be high for 10ns pulse no matter the frequency Jul 05 04:53:32 which may be a problem for other ADCs Jul 05 04:53:58 yeah. So we need to make timings configurable as well. Jul 05 04:54:01 okay. Jul 05 04:54:30 the best way to do it is to make the delay be split Jul 05 04:54:59 so that the duty cycle is closer to 50% Jul 05 04:55:49 hmm okay. So it will cover most of the ADCs that way. Jul 05 04:55:53 right ? Jul 05 04:55:54 just remember to subtract the one cycle for the mov on the first half Jul 05 04:56:04 yeah. Jul 05 04:56:08 yeah most all convertors Jul 05 04:56:30 of this type Jul 05 04:56:38 there already are subtractions - https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/firmware/main_pru1_def.asm#L122 Jul 05 04:56:44 okay. Jul 05 04:57:58 that will have to be adjusted of course Jul 05 04:58:30 since it is split in half Jul 05 04:59:36 yeah. Jul 05 04:59:56 btw, hows the code ? and commit messages ? Jul 05 05:01:05 the asm is okay Jul 05 05:01:24 is the loop unrolled to save a cycle? Jul 05 05:01:54 i SAMPLE_CYCLE_8 Jul 05 05:01:56 in Jul 05 05:03:14 yes Jul 05 05:04:42 your comments are quite detailed Jul 05 05:05:54 commits are getting better Jul 05 05:07:17 started working on the Linux side yet? Jul 05 05:07:51 started reading about is Jul 05 05:10:30 okay Jul 05 05:11:00 let me know when you have the firmware code updated and I can take another look Jul 05 05:12:00 send an email if I am not on here Jul 05 05:12:39 I am going to bed now Jul 05 06:58:51 p Jul 05 16:34:32 Hey bradfa, there? Jul 05 16:35:13 mdp ^^ Jul 05 16:43:26 chanakya_vc: do you need some help? Jul 05 16:44:39 yes m_w .I do. I am having dinner. Please give me 5 minutes. Jul 05 16:44:50 I will be back Jul 05 16:54:43 enjoy your dinner Jul 05 16:55:18 m_w: I have started working on driver and as this commit message says https://github.com/ZeekHuge/BeagleScope/commit/66d8750ddef8d3c6bf34c3ae9d2340bc2b0e3cbd Jul 05 16:55:42 this driver will be straight from iio to pru Jul 05 16:56:04 so that means , it will have the adc-device-driver code in it too. Jul 05 16:56:35 So to develop that, I was trying to find if there is already a linux driver for my adc part. Jul 05 16:56:49 ZeekHuge: awesome I will take a look Jul 05 16:57:09 ZeekHuge: it is unlikely that you will find a driver for it already Jul 05 16:57:40 okay. Just wanted to confirm that. But why is it so ? linux has SO MANY drivers Jul 05 16:57:47 ZeekHuge: okay you have a skeleton Jul 05 16:58:03 ZeekHuge: because parallel ADCs are not easily supported Jul 05 16:58:20 I am back m_w . Dinner took longer than expected :P Jul 05 16:58:27 m_w: hmm okay. thanks . back to work Jul 05 16:58:36 Are you free m_w ? Jul 05 16:58:40 ZeekHuge: let me know if you get stuck Jul 05 16:58:47 chanakya_vc: sure Jul 05 16:58:56 m_w: sure :) Jul 05 16:59:48 I have removed all the errors that were there in the char driver that I was writing . However, on compiling it I am getting this:http://pastebin.com/ANSbakyZ Jul 05 17:00:05 m_w: and about that firmware clock timings, I have raised it as an issue and will resolve that soon ... It wont take much time i guess . Jul 05 17:00:43 chanakya_vc: hi, sorry, been swamped over the holiday weekend and today Jul 05 17:00:44 sorry :( Jul 05 17:00:55 chanakya_vc: I saw you sent an email but haven't read it yet, sorry Jul 05 17:01:06 http://unix.stackexchange.com/questions/169806/no-build-scripts-available-when-compiling-module-outside-of-linux-source-tree Jul 05 17:01:22 https://vishnulinux.wordpress.com/2012/04/30/binsh-scriptsmodmodpost-not-found/ Jul 05 17:01:29 No problem bradfa , I am almost through.Just stuck on a simple issue. Jul 05 17:01:58 And just wanted to wish you a very happy fouth of July bradfa ,m_w ! Jul 05 17:02:55 brexit 1776 Jul 05 17:03:29 Haha bradfa :P Jul 05 17:03:36 *m_w Jul 05 17:03:38 Oops Jul 05 17:04:38 so try modules_prepare Jul 05 17:05:37 Doing that m_w Jul 05 17:07:42 I am getting an error m_w :http://pastebin.com/FYdbZSev Jul 05 17:09:12 there is an omap config in arch/arm/configs/omap2plus_defconfig Jul 05 17:10:04 make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- omap2plus_defconfig Jul 05 17:11:05 make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules_prepare Jul 05 17:12:14 Okay doing it m_w Jul 05 17:13:23 This has to be run in the directory you have written above right? Jul 05 17:13:25 m_w, ^^ Jul 05 17:13:56 in the kernel directory Jul 05 17:14:06 /home/vc/Desktop/beagle-gsoc/kernel_BBB/bb-kernel/KERNEL Jul 05 17:17:30 Okay m_w Now when I am doing modules_prepare Jul 05 17:18:15 I think it is asking me kernel configuration Jul 05 17:18:30 So I am not really sure with many of these settings Jul 05 17:18:39 okay Jul 05 17:18:50 run menuconfig and save Jul 05 17:18:58 make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig Jul 05 17:19:10 just grab it from a running system, /proc/config.gz Jul 05 17:19:19 or that Jul 05 17:19:43 that might be better actually Jul 05 17:20:06 rcn config is preferrable to omap_defconfig Jul 05 17:20:15 m_w, It opened up a window with kernel configuration Jul 05 17:20:29 exit and save Jul 05 17:20:43 Okay did that Jul 05 17:21:11 run modules_prepare again Jul 05 17:21:29 Done Jul 05 17:21:53 now try you module make again Jul 05 17:22:10 your Jul 05 17:32:23 chanakya_vc ??? Jul 05 17:32:41 m_w, It is still exiting. I am trying to paste the log in pastebin. Jul 05 17:32:52 But pastebin doesn't seem to be working Jul 05 17:32:54 Wait m_w Jul 05 17:33:25 Although I do see a .o file in my folder Jul 05 17:34:18 what is the error? Jul 05 17:34:27 http://pastebin.com/nyyuB19g Jul 05 17:34:38 It is throwing up some warnings Jul 05 17:34:43 But no error m_w . Jul 05 17:35:31 do you get a .ko file? Jul 05 17:35:48 Yup got it in my folder Jul 05 17:35:50 m_w, Jul 05 17:36:07 Okay so it has compiled correctly Jul 05 17:36:30 okay then try putting that on the target and running insmod on it Jul 05 17:36:40 Okay give me a minute Jul 05 17:40:01 m_w, Got it scp it here right? /lib/modules/4.4.9/kernel/drivers/ Jul 05 17:40:53 doesn't matter if you use insmod Jul 05 17:41:13 but that is where the modules go yes Jul 05 17:49:17 you can stick it under kernel/extra/my_fancy_driver Jul 05 18:01:18 okay m_w when I am doing insmod pru-spi.ko Jul 05 18:01:31 It says:insmod: ERROR: could not insert module pru-spi.ko: Invalid module format Jul 05 18:01:53 oh boy Jul 05 18:02:18 modinfo pru-spi.ko Jul 05 18:04:46 http://pastebin.com/1FzhvKkx Jul 05 18:04:47 m_w, Jul 05 18:05:32 it is likely the vermagic Jul 05 18:05:41 Yes it is 4.4.14 Jul 05 18:07:43 what is the version of the target? Jul 05 18:07:47 uname -a Jul 05 18:08:25 Linux beaglebone 4.4.9-ti-r25 #1 SMP Thu May 5 23:08:13 UTC 2016 armv7l GNU/Linux Jul 05 18:08:28 m_w, Jul 05 18:08:34 So 4.4.9 Jul 05 18:08:53 the kernel versions must match Jul 05 18:09:02 So what do I do now. Jul 05 18:09:22 you can either update the kernel or compile against the target's kernel Jul 05 18:09:41 choose your fate Jul 05 18:09:57 Recompile the kernel on my computer?But I remember that on my host I had 4.4.9. How did 4.4.14 come Jul 05 18:10:00 hmmnn Jul 05 18:10:30 --force--vermagic option is still available Jul 05 18:10:32 m_w, Jul 05 18:10:54 you can give that a try too Jul 05 18:11:29 Okay let me take a look m_w Jul 05 18:11:39 And get back to you. Jul 05 19:21:23 hmmm Jul 05 19:22:35 m_w: the module get compiled but on ismod-ing it, dmesg says : Unknown symbol devm_iio_device_alloc (err 0) Jul 05 19:22:52 and Unknown symbol devm_iio_device_register Jul 05 19:23:05 they are being used in some drivers too .. Jul 05 19:23:34 it sounds like you need use modprobe Jul 05 19:23:46 ohh ! Jul 05 19:23:48 yes Jul 05 19:24:03 so dependencies are not getting loaded Jul 05 19:24:05 okay Jul 05 19:24:13 yup Jul 05 19:25:02 did you install the module correctly and run depmod? Jul 05 19:25:06 besure you did the depmod -a Jul 05 19:25:19 ^^^ Jul 05 19:25:20 insmod should be fine as long as you manually load the right pieces Jul 05 19:25:55 taking shortcuts only works for independent modules Jul 05 19:26:10 what are you calling a shortcut? Jul 05 19:26:13 yeah .. so what other drivers will I need ? Jul 05 19:26:26 itsounds like you are missing hte IIO subsystem Jul 05 19:26:38 hacks like chanakya_vc was talking about earlier Jul 05 19:27:13 that is a different problem Jul 05 19:27:18 yeah Jul 05 19:27:32 it isn't a short as much as trying to intentionally mismatch structures Jul 05 19:27:36 short cut Jul 05 19:27:54 yeah Jul 05 19:28:11 <--- running non-RT and the USB card reader is monopolizing the CPU/interactivity Jul 05 19:29:25 ds2 .. i got the fw ready ! Jul 05 19:29:27 :) Jul 05 19:29:51 ZeekHuge: cool... do you know if the emitter follower works for the clock? Jul 05 19:30:16 ZeekHuge: sorry about not being around more... got buried by new HW bring up Jul 05 19:30:27 Haven't tested it yet. Focusing on the software part. Jul 05 19:30:39 'k Jul 05 19:30:45 we can get a fake data from the pru for now Jul 05 19:31:11 truely fake or sort of fake (i.e. can you read back patterns set by having pull up/down resistors on the PRU pins) Jul 05 19:31:14 ds2: No problem :) https://github.com/ZeekHuge/BeagleScope#firmware Jul 05 19:32:00 and me and m_w discussed about the clock too... so it comes out that we will need to solve this https://github.com/ZeekHuge/BeagleScope/issues/1 Jul 05 19:32:31 *I, with m_w that is * Jul 05 19:34:44 excellent... was about to ask about the clock duty cycle :D Jul 05 19:35:23 yeah we went over this yesterday Jul 05 19:36:17 should be pretty simple to get 50% duty cycle with appropriate delays before each toggle Jul 05 19:37:02 I am still wondering if a loop could be used in the main sampling instead of all of the repeated macro use Jul 05 19:37:25 or is a jump indeterminate? Jul 05 19:37:43 I donno about simple Jul 05 19:37:56 macro is fine Jul 05 19:38:08 problem is scheduling the toggling with the sampling and other work Jul 05 19:38:56 well the sampling consumes one instruction cycle so just remove that from the delay Jul 05 19:39:33 at 20MHz clock, you need to toggle ever 5th instructon unless you got long instructions (i.e. mem read or run into an xout/xin stall) Jul 05 19:40:39 it isn't really a delay issue. if it was a delay, that'd would be simple Jul 05 19:43:31 m_w: loop ? to remove that those three calls to SAMPLE_CYCLE_8 ? Jul 05 19:44:29 I was think of all of the macros inside SAMPLE_CYCLE_8 Jul 05 19:45:08 loop is a good instruction to use if you are short on cycles Jul 05 19:45:18 loop can save you 1 clock Jul 05 19:45:40 is there a list of the number of cycle used on each instruction somewhere? Jul 05 19:45:49 yes Jul 05 19:46:24 short summary - everything except for mem access is 1 cycle; register swaps SHOULD be 1 cycle but may take more if there is a collision (this is controlable by design) Jul 05 19:46:43 mem access is 1 + n*(32bit words) Jul 05 19:46:47 http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit#Load_.2F_Store_Instructions Jul 05 19:46:49 m_w: ^ Jul 05 19:46:53 okay Jul 05 19:47:03 mem access outside of the PRUSS is 1 + n*(32bit words) + whatever external penalties Jul 05 19:47:16 certainly Jul 05 19:47:26 ds2: loop is an instruction ? Jul 05 19:47:28 chanakya_vc: don't forget to send status report today Jul 05 19:47:43 yes Jul 05 19:47:57 let me rephase, there is a loop instruction Jul 05 19:48:00 donno if you are using it Jul 05 19:48:07 chanakya_vc: hopefully I can help you more tomorrow Jul 05 19:48:20 bradfa, I will. Jul 05 19:48:39 the quick branch instructions Jul 05 19:48:52 I am stuck on this issue. But I can report that I atleast removed all the errors. Jul 05 19:48:54 loop is more then that Jul 05 19:49:00 loop also does the decrement Jul 05 19:49:06 so you save the cycle used for decrement Jul 05 19:49:20 i dont see a loop instruction there : http://processors.wiki.ti.com/index.php/PRU_Assembly_Instructions Jul 05 19:49:22 very useful if you are extremely tight on timing Jul 05 19:49:29 And bradfa I have also been working on the driver using the spi-subsytem Jul 05 19:50:36 look under PRU Core Revision Comparism Jul 05 19:50:38 neither was i able to see it in the manual Jul 05 19:50:42 it is a V3 instruction Jul 05 19:50:48 which the AM335x PRUSS implements Jul 05 19:51:21 it is buried in the PDF manuals Jul 05 19:51:51 ah Jul 05 19:53:23 you probally need to give the assembler a flag for that to be recognized Jul 05 19:53:34 pasm definitely needs it, no idea if the new one does Jul 05 19:54:06 for initial purposes, you could try slowing things down for testing then fix it toward the end so at least you know you have working pieces Jul 05 19:55:35 okay i see it there : https://github.com/beagleboard/am335x_pru_package/blob/master/am335xPruReferenceGuide.pdf Jul 05 19:55:49 section 5.3.4.3.18 Jul 05 19:56:22 yep. Thats the idea. Jul 05 19:56:54 Also, there are some limitations too, and we will have to work around them. Jul 05 19:57:21 I will add details about them in the report. Jul 05 19:58:10 if you get a chance, test reading patterns on the PRU pins (use 1K pull ups/downs Jul 05 19:58:25 okay. Jul 05 19:58:25 that will let you verify the pinmux configuration Jul 05 19:59:24 ds2, m_w : Can I keep the new driver in kernel/testing/ ? will depmod and modprobe work fine with that ? Jul 05 19:59:25 that 1K isn't critical... if you got something a little bigger or lower, it'll be fine... also keep in mind if you are testing it on the LCD pins, they can impact boot Jul 05 19:59:57 ZeekHuge: kernel/testing?? why not drivers/testing or drivers/misc? Jul 05 20:00:09 generally drivers go into the driver branch of the tree Jul 05 20:00:10 :D Jul 05 20:00:33 pinmux config ? isnt that easy with config-pin utility ? Jul 05 20:00:51 put it in the device tree Jul 05 20:01:09 ds2: ahh ... the idea was , will it work anywhere it the kernel/ dir ? Jul 05 20:01:27 it should...depmod should find it Jul 05 20:01:37 it searches /lib/modules/`uname -r`/..... Jul 05 20:32:52 * nerdboy is apparently much to subtle with "make a diagram..." stuff Jul 05 20:59:30 m_w: hi, I won't be able to do tests today, I'm still working on user api and thorough reconstruction of the driver. Jul 05 21:00:08 pmezydlo1: okay Jul 05 21:00:31 how is the reconstruction coming along? Jul 05 21:07:40 s/to/too/ Jul 05 21:13:09 m_w:With some minor problems. It's too much at once and I'm a bit lost. Jul 05 21:14:19 try to break it down into manageable steps Jul 05 21:16:30 at the beginning: git reset HEAD --hard :) Jul 05 21:20:47 that is one way to do it Jul 05 21:23:05 m_w: This reconstruction brings me closer to the final appearance of user api and the very way of how the driver works. Jul 05 21:23:27 m_w: I'll describe everything on tomorrow's meeting, during my stand up. Jul 05 21:23:51 pmezydlo1: okay good Jul 05 22:08:17 m_w: there ? Jul 05 22:08:22 I am getting this error Jul 05 22:08:47 so .. here : http://lxr.free-electrons.com/source/drivers/staging/iio/iio_simple_dummy.c?v=3.14#L456 Jul 05 22:09:12 it says that we need to specify the name ... and the bus for me is rpmsg. Jul 05 22:09:14 so .. Jul 05 22:09:32 http://lxr.free-electrons.com/source/include/linux/mod_devicetable.h#L416 Jul 05 22:09:59 and as in this file ^ Jul 05 22:10:35 i2c and rpmsg_device_id have same data type of the name Jul 05 22:10:49 but why is that warning there then ? Jul 05 22:11:30 lemme see Jul 05 22:11:32 id = &rpmsg_dev->id; indio_dev->name = &id->name; Jul 05 22:11:43 this is that specific part in the code ^ Jul 05 22:12:28 *specific part in my code Jul 05 22:14:02 I need to say the whole code Jul 05 22:15:50 hmmm Jul 05 22:16:00 indio_dev->name is a **? Jul 05 22:16:33 just a minute ... I will have to commit and push it up. Jul 05 22:16:57 I have a feeling you have too many & Jul 05 22:17:21 usually indio_dev->name = id->name (assuming id has global/static scope) Jul 05 22:24:57 m_w, ds2 : this is what i am talking about Jul 05 22:25:01 https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/driver/beaglescope_driver.c#L51 Jul 05 22:26:12 are you sure you need the '&' on there? Jul 05 22:27:28 oops .. Jul 05 22:29:15 probally should find out if that rpmsg structure is presistant (or at least the name) Jul 05 22:29:26 not sure if teh register does a strdup() (or equiv) Jul 05 22:30:52 http://lxr.free-electrons.com/source/include/linux/rpmsg.h#L110 Jul 05 22:33:57 ds2: ^ Jul 05 22:38:15 i suspect it is ok Jul 05 22:55:15 but what if he creates a tiny blackhole? Jul 05 22:56:43 if it is stable... Jul 05 22:59:05 it would eat the beaglebone... Jul 05 23:01:10 good thing the small ones don't live very long Jul 05 23:02:29 good excuse for not finishing ;) Jul 05 23:43:35 ahh .. shit ! I just made a blackhole big enough to eat my laptop too !!! Jul 05 23:43:36 :P Jul 05 23:44:02 I need help here : https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/driver/beaglescope_driver.c Jul 05 23:44:16 Do you notice any mistake there ? Jul 05 23:44:29 Its working sometime .. Jul 05 23:44:55 but not always Jul 05 23:45:21 not even the messages in __init are getting printed in dmesg Jul 05 23:45:30 ds2, m_w, nerdboy ^^ Jul 05 23:47:13 and when getting printed, that kern_debug message is getting printed twice ... dont know why .... Jul 05 23:47:21 i rebooted bbb twice. Jul 05 23:48:00 use pr_info for line 104 Jul 05 23:48:28 tried ... same ... getting printed twice. Jul 05 23:49:15 what does your dt look like? Jul 05 23:49:21 which message is coming out twice? Jul 05 23:49:34 infact .. i commented out everything but that message ... it was still printing those messages twice Jul 05 23:49:47 !??!?! Jul 05 23:50:14 ds2: this message https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/driver/beaglescope_driver.c#L104 Jul 05 23:50:44 do you have latest v5 and matching kernel? Jul 05 23:50:59 or v4 and (older) kernel Jul 05 23:51:07 m_w: yes .. thats all happening for last 2 hours and ... Jul 05 23:51:16 nerdboy: yes .. Jul 05 23:51:55 this is a module or compiled in? Jul 05 23:53:19 the Makefile seems to point towards it being a module Jul 05 23:53:28 i just tested v5 and 4.4.12-ti-r32 rpmsg today and it worked fine Jul 05 23:53:52 are you sure udev isn't loading your module twice for some reason? Jul 05 23:53:52 ds2: m_w : yes .. module Jul 05 23:54:16 does lsmod look sane? Jul 05 23:54:23 nerdboy: its not about the rpmsg for now. Jul 05 23:54:27 fx doesn't load on boot, but loads fine after with a remove/modprobe of pru_rproc module Jul 05 23:54:28 can you account for everything there to make sure you don't have 2 instance? Jul 05 23:54:32 actually .. no .. Jul 05 23:54:35 *tw even Jul 05 23:54:40 arg Jul 05 23:54:47