**** BEGIN LOGGING AT Mon Jun 24 02:59:57 2019 Jun 24 03:22:10 pratimugale: also, you can invoke assembly code, from inside the C code. Jun 24 04:01:17 zeekhuge: yes, using __asm and asm keywords, thanks Jun 24 06:58:26 pratimugale: not just that. Jun 24 06:58:40 You can actually create functions in assembly and invoke them Jun 24 06:58:47 see this example Jun 24 06:58:49 https://github.com/ZeekHuge/BeagleScope/tree/port_to_4.4.12-ti-r31%2B/examples/firmware_exmples/PRU_inline_asm_blinky Jun 24 06:59:07 The function is invoked from here : https://github.com/ZeekHuge/BeagleScope/tree/port_to_4.4.12-ti-r31%2B/examples/firmware_exmples/PRU_inline_asm_blinky Jun 24 06:59:24 and the function is defined in here : https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/examples/firmware_exmples/PRU_inline_asm_blinky/pru1-asm-blinky.asm#L24 Jun 24 07:19:47 pratimugale: Also, try to write better commits. Jun 24 07:20:33 The thought process is, you should be able to move forth and back on the commits and find the code is a state which makes sense. Jun 24 07:21:38 For example : look at this commit : https://github.com/pratimugale/PRUSS-Bindings/commit/e9de6131bc3f32a8ba3030eea68d4d0924efd395 Jun 24 07:22:47 This commit adds support in the APIs to be able to mem-read. But, till this commit, the daemon does not have any support (not even a mocked/temporary one) to mem-read. Jun 24 07:23:08 the support in the daemon comes just after this commit. Jun 24 07:23:34 Hence, the e9de6131bc3f32a8ba3030eea68d4d0924efd395 commit leaves the codebase in a kind of confusing state. Jun 24 07:24:15 Confusing non-testable state. Jun 24 07:24:47 zeekhuge: got it, I'll improve the commits Jun 24 07:26:06 Also, try to make better commit messages. The thought process with that is, when the codebase is big, and their is a bug, you should be able to find the commit which "might" contain the bug, through its commit message. Also, the commit message should tell "why you made these changes" Jun 24 07:26:55 The format most followed is : 1st line with a short description of what and where the changes are made. Leave a blank line. Then a details description. Jun 24 07:27:34 Short description is most useful with commands like `git log --oneline` and `git log --oneline --graph --decorate --all` (try these) Jun 24 07:28:43 @students : You guys may find these useful as well. Jun 24 07:33:17 zeekhuge: Thanks, will follow the description format and use the commands from now on Jun 24 07:35:26 pratimugale: On a different note, does the current daemon support multi-threading ? or will it keep waiting/hang when waiting for response ? for an RPMsg message from the PRU side for example ? Jun 24 07:42:18 thank you @ZeekHuge_:matrix.org will follow the format Jun 24 07:43:15 zeekhuge: The previous student (Muneeb) had worked on a multithreaded firmware example Jun 24 07:43:50 The daemon itself does not have multi-threading Jun 24 07:44:10 multi threaded firmware ? Jun 24 07:44:19 PRU is a single core. Jun 24 07:45:26 No he used multithreading in the userspace program Jun 24 07:45:27 https://github.com/pratimugale/PRUSS-Bindings/blob/master/examples/multi_threaded.cpp Jun 24 07:46:05 okay. so this is the client side. right ? Jun 24 07:46:10 the one that will use the APIs. Jun 24 07:46:14 right ? Jun 24 07:46:22 yes Jun 24 07:47:39 Yeah, but if the daemon is waiting for the PRU's reply, then the there is no point in making the client side multi-threaded. The daemon wont respond to any other calls, if its waiting for the message from the PRU. Jun 24 07:47:41 the directory name of the firmware example is "multi_threaded" Jun 24 07:47:56 I think this needs to be fixed. Jun 24 07:48:06 do add this in your TODO list. Jun 24 07:48:43 Okay, will work on this Jun 24 08:50:27 embden[m]: Sorry I had a sunday packed with diving training course. Jun 24 08:51:35 embden[m]: Some of the platform doesn't configure correctly CNTFREQ_EL0, that's why preinit_dt_xen_time() will check whether the frequency has been specified in the DT. Jun 24 08:55:23 I think this is a bit different for the X15. The frequency is derivated from the realtimer (see realtime_counter_init() in linux/arch/arm/mach-omap2.c). Jun 24 08:55:38 I don't know much of the hardware, but ds2 might be. Jun 24 08:56:18 We have similar code in xen (see omap5_init_time) except, AFAICT, cntfreq is not set. Jun 24 09:08:33 julieng: I am interested in where the timer is set up. I can't find the mapping from am5728 to what's happening in Linux kernel. But I am going to figure out what is happening Jun 24 09:09:49 julieng: I want to find where the timer is set up. Maybe it is easier to add frequency to DT if it is constant and not set up in the code Jun 24 09:10:04 via dividers or something Jun 24 09:11:59 embden[m]: Looking at the logic (realtime_counter_init), it depends on the current setup of the platform. I am also not sure whether the hardware requires CNTFREQ register to be valid. Jun 24 09:12:05 I also had problems with understanding on how to determine the frequency of the clock source but now I can see on the board 24 MHz oscillator Jun 24 09:12:21 If the hardware doesn't care, then the software (Linux and Xen) should be able to deal without it. Jun 24 09:49:37 julieng: so, I've added a parameter to the device tree and now it loads a bit further. Though, it counts down 3...2...1... like five times slower than it should be (should it be 1 second for each number to appear?) Jun 24 09:53:40 embden_[m]: Could you paste on pastebin the full log? Jun 24 09:56:46 julieng: https://pastebin.com/MskyW7ym Jun 24 10:26:51 julieng: yes, it seems that just providing the frequency in the node is not enough. Jun 24 10:37:22 embden[m]: Yes it is roughly 1s between each number (see warning_print). Jun 24 10:38:23 embden[m]: Wrong timing are often during the using a wrong frequency. I would recommend to look at the Linux code and see how they compute the frequency. Jun 24 10:38:38 yes, I do Jun 24 10:39:56 embden[m]: could it be it counts 3.9 times slower? The Linux sources mentions 6.144 MHz as the timer clock rate Jun 24 10:40:35 apritzel: it could Jun 24 10:41:39 I can see they mention values of numerators and denumerators so I am looking for them in RM Jun 24 10:42:07 embden[m]: yeah, but if you look further down in the code they *OR* in those numbers with some register values Jun 24 10:42:40 this whole routine is quite confusing, actually Jun 24 10:45:20 and they refer to some sys_clkin clock, I am not sure which one this is Jun 24 10:45:59 naively I would assume it's the usual 24 MHz clock source, but there is no 24MHz entry in that frequency table Jun 24 10:47:01 apritzel: I thougt they read it either from DT or from CNTRFREQ (not sure about the last one) Jun 24 10:47:33 CNTFREQ is a system register, purely meant for software Jun 24 10:48:06 the idea is that *firmware* sets this one up, to tell normal world what the frequency is Jun 24 10:48:15 it has no meaning to hardware at all Jun 24 10:48:43 problem is that you can only write it in *secure* state Jun 24 10:48:59 that's why you have this smc to set it up Jun 24 10:49:13 honestly the TI BootROM should do this, or at least U-Boot Jun 24 10:49:28 doing this is Linux (or Xen) is a hack Jun 24 10:49:50 also: putting the timer frequency is an equally bad hack Jun 24 10:50:14 it was added just to workaround those broken platforms where CNTFREQ is not set up properly Jun 24 10:50:33 s/putting the timer frequency/putting the timer frequency in DT/ Jun 24 10:51:23 so since the TI BootROM does not seem to program it, the cleanest solution would be to set it up in U-Boot Jun 24 10:51:38 next best thing is to do in Xen, similar to what we do in Linux Jun 24 10:52:40 embden[m]: which means you need to understand what this Linux routine really does, I suggest you add some debug output to better understand this Jun 24 10:53:40 for instance to learn what the rate of this sys_clkin clock is Jun 24 11:09:44 apritzel: I found the description of the sysclock registers in ref man but I still don't understand what 24 MHz oscillator is for Jun 24 11:10:57 it should go to prcm and probably after that prcm feeds new frequency to master timer Jun 24 11:11:11 embden[m]: The 24 MHz oscillator is typically one of two *actual* clock sources (crystal oscillator) for those kind of boards (the other being a 32768 Hz crystal) Jun 24 11:11:23 that's what you can actually see Jun 24 11:12:04 internally this reference clock is mangled heavily into a clock tree, sometimes increased (using a PLL), sometime decreased (using simple clock dividers) Jun 24 11:12:16 mostly both Jun 24 11:12:46 from a first glance this clock tree looks quite complex (which is quite common) Jun 24 19:52:27 jkridner ravikp7 cwicks: I have made a demonstration vide for the Techlab Cape Click Support examples here: https://youtu.be/f8NztEJGuHE , the audio is a bit noisy, sorry for that. Jun 24 19:54:21 jkridner: I did try out obs studio for screen recording, I couldn't find a nice way to record a particular portion of the screen other than cropping (alt+drag) which makes it difficult to read the console text , that's why I proceeded with the old software Jun 24 19:56:19 Unfortunately my weather click is also having the same issue as ravikp7 faced, the i2cdetect output shows no devices and support through corresponding dt overlay is also not working, I believe it's a hardware issue as I also tried it with an Arduino and it wasn't working Jun 24 20:34:18 I have written the evaluation **** ENDING LOGGING AT Tue Jun 25 03:00:38 2019