**** BEGIN LOGGING AT Sun Jul 13 02:59:59 2014 Jul 13 04:03:35 alexanderhiam : my compiler works! ^_^ Finished encoding all possible instructions. Also came up with a neat data flow within the userspace libraries :) Jul 13 04:23:27 karki_: awesome! Jul 13 04:23:52 alexanderhiam : I've pushed the code, check it out when you are free :) Jul 13 04:30:02 the code works fine, but isn't exactly clean :p I'll fix that soon enough. Jul 13 04:37:38 karki_: the user will have to stick to the variable names defined in bs_parse.py or can define his own variables as well? Jul 13 04:38:23 he can, I have handled it for variables. Though still thinking of how to do it for arrays...... Jul 13 04:43:56 karki_: you could just have array indexes compilled to start_addr+offset Jul 13 04:45:06 e.g. if the first variable you create is an array called my_array it would be at address 0x00, and my_arr[3] would be 0x00+0x03 Jul 13 04:46:46 if you create an array of size 10 then "SET array[11]" could simply overwrite the next slot Jul 13 04:47:05 i.e. keep it simple! Jul 13 04:47:41 alexanderhiam : that is how it works in my current implementation! :p Jul 13 04:47:44 but Jul 13 04:48:11 I was thinking about how I would define an array in the first place! Jul 13 04:48:40 e.g. In case of a normal variable Jul 13 04:48:51 there's not really a need to since you're compiling, just always use the effective address Jul 13 04:49:32 the compiler could keep track of tyes and get mad if you try to index an integer Jul 13 04:49:38 types* Jul 13 04:50:38 I would "SET var, 5"; if var is not defined, it'll create a loc for it, it it is already defined, it will use the pre existing loc. Jul 13 04:50:50 right Jul 13 04:51:17 but if it were an array, how would I tell that I need say 10 mem loc for the array variable? Jul 13 04:52:17 they're explicitely created with a size, as defined by botspeak: "SET array_SIZE,10" Jul 13 04:52:36 (though that looks a little funny...) Jul 13 04:52:45 that's from here: http://botspeak.org/?page_id=101 Jul 13 04:53:41 alexanderhiam : thanks :p I read that a long time ago and couldn't find it in the last two days............... Jul 13 04:53:57 yeah _SIZE doesn't seem that nice Jul 13 04:54:27 it almost seems like a typo to me Jul 13 04:54:42 might be worth asking Chris Jul 13 04:55:51 yeah, and even if I were to implement something like that, my code would look really ugly! Jul 13 04:56:15 * karki_ will be back in a few min..... Jul 13 05:17:53 karki_: I'm finally getting around to trying out pruspeak; I grabbed the A8 PRU compiler from http://software-dl.ti.com/codegen/non-esd/downloads/beta.htm and it's failing to build the pruspeak firmware: https://gist.github.com/alexanderhiam/ab243320d3c64e1d8de6 Jul 13 05:19:42 hmm... weird, I don't seem to get any error! Jul 13 05:20:07 oh, nevermind, I don't have the ti libraries in my include path! Jul 13 05:20:37 :p Jul 13 05:24:08 ok, compiled! Jul 13 05:24:56 alexanderhiam : you would want to try the legacy code on the userspace side. the new userspace compiler is still under development! Jul 13 05:25:06 ok Jul 13 05:29:59 karki_: are the DIO the PRU GPIO pins? Jul 13 05:31:59 i.e. DIO[4] = pr1_pru0_pru_r30_4 = P9_42? Jul 13 05:40:54 DIO[1] is the one controlled by pru0_r30_1 Jul 13 05:40:57 x Jul 13 05:41:12 ^ ignore Jul 13 05:41:24 I suppose I need to do some pinmuxing as well... Jul 13 05:41:54 yeah, try the DTC folder Jul 13 05:42:06 it has all the reqd pin mux stuff Jul 13 05:44:20 should I be using the universal cape? Jul 13 05:45:24 wait..... one sec Jul 13 05:47:21 alexanderhiam : I haven't used the universal cape! Jason added that, never tried it out. I had a .dto of my overlay, I continued to used that even after jason replaced it! Jul 13 05:47:55 oh ok, well it's about time I gave the universal cape a try anyway Jul 13 05:52:38 karki_: cape-universal and BB-PRUSPEAK overlays don't get along; loading both in either order causes kernel panic Jul 13 05:53:50 because of this perhaps? https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universal-00A0.dts#L1723 Jul 13 05:53:51 I don't know the cape-universal stuff as of now :/ I'll look into it and fix it........ Jul 13 05:54:29 it seems like it's going to become a standard part of the beaglebone Jul 13 05:55:17 mind adding your pinmux overlay to the repo for now? Jul 13 05:55:38 yes, possibly. I'll look into it. but first I'll have to complete the encoding doc before jason gets mad at me. Jul 13 05:55:44 ok :) I'll add it Jul 13 05:56:05 * Abhishek_ is yet to try the universal cape, knows it would bring some skeletons out of the cupboard :P Jul 13 05:57:25 who ever figures out this universal cape stuff please give me a flash lecture ;) Jul 13 05:57:43 * Abhishek_ takes out his flashlight Jul 13 05:58:55 karki_: have you used the bone-pinmux-helper? Jul 13 06:00:24 nope....... Jul 13 06:00:35 karki_: it's the basis of the universal cape; it's also how I do pinmux in PyBBIO: https://github.com/alexanderhiam/PyBBIO/blob/master/tools/overlays/gpio-template.txt Jul 13 06:01:06 Abhishek_: ^ one of my skeletons it will bring out :P Jul 13 06:01:07 Will look into it :) thanks Jul 13 06:02:09 oh! yeah I remember seeing this when I first encountered pyBBIO Jul 13 06:07:15 afaik the bone-pinmux-helper is a kernel module? Jul 13 06:10:15 yeah, from panto I think Jul 13 06:12:40 alexanderhiam : here is the DTS you need right now : https://github.com/deepakkarki/pruspeak/blob/fc4a25225245c4b3c194b245d79df7026673c445/src/dts/BB-BONE-PRU-07-00A0.dts Jul 13 06:13:44 ok thanks Jul 13 06:23:02 karki_: I'm not sure it's working for me, I don't see any change on the pin when I run client.py Jul 13 06:23:18 here's my dmesg: https://gist.github.com/alexanderhiam/5143fadebb25adee50b6 Jul 13 06:23:22 thats odd.... Jul 13 06:23:44 can you paste the kernel log? Jul 13 06:23:51 okay :) Jul 13 06:24:00 * alexanderhiam is up way too late and is probably just doing something dumb Jul 13 06:25:23 alexanderhiam : I'll check it up, it happened to me once too, I did something and then it got fixed. I'll see if I can recall! Jul 13 06:26:32 I suppose this is a firmware issue Jul 13 06:27:24 yeah it is Jul 13 06:27:45 reloading the firmware once or twice could help Jul 13 06:28:17 something like echo 0:pru-botspeak > /sys/devices/....rproc/load Jul 13 06:29:42 Abhishek_ : the firmware has not been loaded correctly, so what you say might work. or it's probably something else all together :/ Jul 13 06:30:32 karki_: I updated that gist with my whole log, and I'll get back to this tomorrow Jul 13 06:30:32 it has less to do with reloading the fw and more with resetting the PRU :/ Jul 13 06:30:52 alexanderhiam : sure :) Jul 13 06:30:55 * alexanderhiam can't put off sleeping any longer Jul 13 06:33:19 alexanderhiam : this is the problem "remoteproc0: failed to load pru_firmware" Jul 13 06:33:44 alexanderhiam : https://gist.github.com/alexanderhiam/5143fadebb25adee50b6#file-pruspeak-dmesg-L432 Jul 13 06:34:59 you have to place the firmware as "pru_firmware" in "/lib/firmware"; looks like you have given the elf file a wrong name while coping it to /lib/firmware Jul 13 06:35:08 * Abhishek_ finds magic bytes loaded into the PRU RAM by the firmware and fails load of BeagleLogic module if firmware is not loaded correctly Jul 13 11:19:37 vvu : thanks :) Jul 13 12:20:03 praveendath92: ping Jul 13 12:48:39 vvu: pong Jul 13 12:54:39 what is happening now with the fb ? Jul 13 12:54:57 so if you remove all the compression functions it is not working anymore ? Jul 13 12:55:00 Saw my mail? Jul 13 12:55:21 It's giving errors. Jul 13 12:55:30 yep Jul 13 12:55:34 Saw the image? Jul 13 12:55:48 yes Jul 13 12:55:56 so how did u get the image ? Jul 13 12:55:58 usb transfer ? Jul 13 12:56:11 Nope. I couldn't remove the compression. Jul 13 12:56:22 I took a dump of raw data from fb. Jul 13 12:56:43 Transferred it to device and parsed it as a bitmap. Jul 13 12:56:57 mhmh Jul 13 12:57:11 but why does it give errors if you remove those ? Jul 13 12:57:41 It's a bit confusing. Jul 13 12:58:04 It shouldn't from what I expect. Jul 13 12:58:46 I went through the udlfb documentation this morning. Jul 13 12:59:24 The /dev/fbx sysfile has an attribute which specifies the bytes transferred. Jul 13 13:00:18 try and see from where you get the error Jul 13 13:00:28 can you use gdb to debug the module ? Jul 13 13:00:35 and see at which line it fails Jul 13 13:00:36 and why Jul 13 13:01:24 I was meaning to ask you about a debugger. Jul 13 13:01:36 gdb if so Jul 13 13:01:43 use eclipse with gdb think so Jul 13 13:01:52 i was using eclipse with gdb and openocd to debug some arm chipset Jul 13 13:02:03 https://www.kernel.org/doc/Documentation/fb/udlfb.txt Jul 13 13:02:16 The Sysfs Attributes section. Jul 13 13:03:06 and you get 0 for transferred ? Jul 13 13:04:13 Nope. I was just searching for how to read those attributes. Jul 13 13:04:27 You know? Jul 13 13:04:28 just as from a file i assume Jul 13 13:06:11 Let me check. Need to restart. Jul 13 13:06:34 oki Jul 13 13:07:17 I'm in windows :/ Jul 13 13:08:10 I press ALT+CTRL+ as a habbit to switch workspace and my screen rotates :| Jul 13 13:08:27 :)) Jul 13 13:45:11 vvu: ping Jul 13 13:50:47 They are created as file. I just have to read them. Jul 13 13:56:11 good Jul 13 13:59:37 I'm getting some random kernel paging errors :( Jul 13 14:00:07 I mean they occur on a few times of usage. Jul 13 14:05:22 paging errors ? Jul 13 14:05:25 that is awkward Jul 13 14:08:20 Hmm. Jul 13 14:08:57 this is kinda out of my league Jul 13 14:10:48 That is like once in a while. Thought I will look into later. Jul 13 14:11:00 May be some memory allotment issue. Jul 13 14:11:57 what happens if u try and send the buffer with the data directly when it is available in the kernel driver ? Jul 13 14:12:08 before computing what changed Jul 13 14:12:38 Yes. That is what I was trying to do. Jul 13 14:13:01 just a sec. Jul 13 14:13:22 ok Jul 13 14:13:50 https://github.com/praveendath92/udlfb/blob/master/udlfb.c#L620 Jul 13 14:13:59 I commented the compression functions. Jul 13 14:14:19 Also in L637 Jul 13 14:15:15 From what I figured, they are taking pointer to buffer data and storing a shorter version of it. Still this isn't working. Jul 13 14:15:33 mhmh maybe now it is trying to access memory that is not available to you Jul 13 14:15:36 that is why u get those errors Jul 13 14:16:17 Hmm. But it's not a kernel paging error. Jul 13 14:16:30 BTW, I got this. https://github.com/praveendath92/udlfb/blob/master/info.txt Jul 13 14:17:06 I will get you the log of it. In a moment. Jul 13 14:17:43 so something really got sent Jul 13 14:20:48 Yes. Jul 13 14:21:15 I also received fairly good amounts of data on Android. Jul 13 14:21:48 so try and reverse the compression algo Jul 13 14:21:55 is it complicated ? Jul 13 14:23:18 I will go through that in detail. Jul 13 14:23:36 May I will find out. Jul 13 14:25:25 vvu: https://gist.github.com/praveendath92/a9f8b8a0fd5f35ac8f96 Jul 13 14:25:46 Kernel log when I comment the compress functions. Jul 13 14:34:34 something does not click Jul 13 14:34:43 u get a soft lockup which means interrupts are turned off Jul 13 14:35:06 those compression functions do nothing regarding anything than processing data Jul 13 14:37:07 I got that everytime w/o those functions. Jul 13 14:37:23 mhmh Jul 13 14:37:45 I used to get it in the probe function itself. Jul 13 14:38:14 This time while starting the xserver. Jul 13 14:38:38 praveendath92: https://github.com/praveendath92/udlfb/blob/master/udlfb.c#L448 Jul 13 14:38:48 think that does the magic Jul 13 14:39:28 What does that do? Jul 13 14:39:49 But the function is commented right? You mean it is required? Jul 13 14:39:55 think so Jul 13 14:43:17 I will look at what prefetch does. Jul 13 14:43:44 I'm hungry. Will be back after dinner. Jul 13 14:44:05 k Jul 13 14:44:14 i think that does something that prevents the soft lockup Jul 13 17:42:07 alexanderhiam_ : you around? Jul 13 18:36:38 karki: hey Jul 13 18:45:47 karki, karki_: https://gist.github.com/alexanderhiam/5143fadebb25adee50b6#file-loading-pruspeak Jul 13 18:47:57 okay...... this is weird. I don't know why it should be failing :/ Jul 13 18:51:42 * karki digs into the kernel driver. Jul 13 18:59:11 alexanderhiam : the problem seems to be here..... : https://github.com/deepakkarki/pruspeak/blob/master/src/driver/pru_speak.c#L694 Jul 13 18:59:18 I donno why though! Jul 13 19:05:19 karki: who calls rproc_fw_sanity_check? Jul 13 19:07:42 alexanderhiam : not sure. Abhishek_ dabled with it quite a bit though. Jul 13 19:08:45 http://lxr.free-electrons.com/source/drivers/remoteproc/remoteproc_core.c#L801 Jul 13 19:09:09 alexanderhiam : check my latest push. I compiled the pru firmware on my machine and put it in the /bin of the rep (pru0_firmware). check if it works with my image Jul 13 19:11:08 it seems like request_firmware isn't working right: http://lxr.free-electrons.com/source/drivers/remoteproc/remoteproc_core.c#L1079 Jul 13 19:11:24 firmware_p seems to be a null pointer after that call Jul 13 19:12:28 karki: should I change the overlay to request pru0_firmware? Jul 13 19:12:52 nah, just copy it in the /lib/firmware as pru_firmware Jul 13 19:15:09 karki: looks like that one worked worked Jul 13 19:15:38 so the problem is with the ..... ? Jul 13 19:15:45 compiler? Jul 13 19:16:14 alexanderhiam : I also started documenting the encoding stuff. Jul 13 19:16:46 here is what I finished today : https://gist.github.com/deepakkarki/c2cccf889b91da660bc9 Jul 13 19:17:24 alexanderhiam : feel free to fork and edit if there are any obvious mistakes! (I was kinda sleepy) Jul 13 19:18:10 karki: so the stuff in legacy_code only has SET implemented? Jul 13 19:18:52 yeah, only DIO, GOTO and wait! Jul 13 19:19:35 DIO is working for me now :D Jul 13 19:21:45 :) and don't forget to check out my encoding doc :p Jul 13 19:22:16 alexanderhiam : Put a whole day into it more or less : https://gist.github.com/deepakkarki/c2cccf889b91da660bc9 Jul 13 19:22:28 karki: I feel like it would more 'expandable' if it was always the same bit that indicated an instruction was 64 bits Jul 13 19:22:44 (looking at the doc now) Jul 13 19:24:08 alexanderhiam :true, but I didn't find the point reserving 128 instructions for 64 bit instructions, cause there won't be nearly as many 64 bit inst as there are 32 bit....... (just a thought) Jul 13 19:26:14 alexanderhiam : I'll be going to sleep now. leave some comments on the gist if you find necessary :) Jul 13 19:27:15 I'm just thinking it would simplify the interpreter logic a bit; i.e. 'if bit 7 of the OPCODE byte is 1 then grab the next 4 bytes as well', whereas now it's 'if the OPCODE is 0x12 or 0x20 or 0x21 or...or 0x2F grab the next 4 bytes as well' Jul 13 19:28:05 karki: ok, will do. The doc looks great btw Jul 13 19:28:14 thanks :D **** ENDING LOGGING AT Mon Jul 14 02:59:59 2014