**** BEGIN LOGGING AT Tue Apr 18 03:00:01 2017 Apr 18 03:18:03 zmatt: k Apr 18 05:04:14 ehh? Apr 18 09:10:37 zmatt: do you know of any clock comains in L4LS that need to explicitly make a wake/sleep transition before the L4LS clock domain can sleep? Apr 18 09:10:57 zmatt: no, that came out wrong Apr 18 09:12:26 zmatt: that should read: any modules in the L4LS clock domain that need to make a on -> idle transition Apr 18 09:13:18 zmatt: I now have the strange state that everything seems to be off, according to the prcm, only L4LS_GCLK is on and the L4LS clock domain is stuck in a sleep transition Apr 18 09:14:11 zmatt: also the L4LS hwmod doesn't want to idle Apr 18 09:15:03 zmatt: https://ghostbin.com/paste/ko9tm Apr 18 09:18:03 zmatt: I've marked the differences between a bad vs good transitions. I think the reason why the L4LS clock domain doesn't want to sleep is that the L4LS interconnect hwmod doesn't want to idle Apr 18 10:24:38 zmatt: oh, allright Apr 18 10:30:21 someone has experiences with customize an Beagle Board? Apr 18 10:30:33 i need to customize hardware Apr 18 10:30:42 depauperate Beagle Board Black Apr 18 10:40:07 zmatt: works now, GFX_L4LS needs to be woken up and put to sleep again or it will prevent L4LS sleep Apr 18 11:17:50 that's pretty weird Apr 18 11:18:58 especially since the gfx_l4ls doesn't exist afaik Apr 18 11:23:08 or, I guess it does actually, since the "ghost" modules on the am335x do have their interconnect stuff intact usually.... Apr 18 11:45:08 I still wonder what the story behind the am335x and its ghost peripherals/subsystems is... I've not seen anything like it on other TI SoCs Apr 18 11:56:26 zmatt: well there's a GFX power domain that contains two clock domains and 3 hwmods. Apr 18 11:56:35 zmatt: so, "something" seems to be there :) Apr 18 11:58:39 thinkfat: but the integration chapter the TRM doesn't at all mention any L4LS connectivity Apr 18 11:58:53 * thinkfat must stop talking to himself... Apr 18 12:00:19 Hello! Did anyone encounter low reading speed from DDR allocated for pru by uio_pruss driver? Apr 18 12:06:09 thinkfat: my prcm.h shows the "l4ls_gfx" is just for the configuration port of the system mmu (ghost) Apr 18 12:06:40 zmatt: but there is no system mmu... Apr 18 12:06:48 correct Apr 18 12:07:00 zmatt: ah, but I think the SGX has one. Apr 18 12:07:12 sgx has an integrated mmu, so no point in having a system mmu for it Apr 18 12:07:20 it might be for the bitblt (ghost) Apr 18 12:13:52 Hi Apr 18 12:15:30 I just want to use CAN bus in beaglebone. tried this link, http://www.thomas-wedemeyer.de/beaglebone-canbus-python.html. But not able to see the sent data Apr 18 12:15:37 do you have any useful link? Apr 18 12:20:24 I don't have much experience with CAN, though I've seen the bus work Apr 18 12:20:47 I just used some simple testing with can-utils Apr 18 12:23:38 a word of caution: if there is an electrical problem with the bus, the CAN controller go into fault mode right away or after transmitting the first packet, after which it stays mute until the interface is reinitialized... Apr 18 12:24:34 you'd think such an event would cause a loud notice in the kernel log, but if I remember correctly I actually had to enable dynamic debug messages to notice this was happening Apr 18 12:26:40 I'd also expect the bus to recover automatically, it didn't :/ Apr 18 12:26:59 of course it's entirely possible that I was simply doing something stupid due to my inexperience with CAN Apr 18 12:30:58 thinkfat: hm, bitblt also has an integrated mmu... then I don't understand it Apr 18 12:32:45 thinkfat: it would have been useful to put lcdc behind an mmu to cope with its extremely limited dma controller, except lcdc is located in pd_per, not pd_gfx... Apr 18 12:35:35 i checked in log, nothing there Apr 18 12:39:14 note that the link you just gave seems to contain quite old information Apr 18 12:40:34 be sure to double-check pinmux is setup right (use e.g. my show-pins utility from https://github.com/mvduin/bbb-pin-utils ) Apr 18 12:43:34 you can enable debug messages for can with: Apr 18 12:44:51 echo 'file net/can/* +p' | sudo tee /sys/kernel/debug/dynamic_debug/control Apr 18 12:45:14 (use -p instead of +p to disable them again) Apr 18 12:47:08 modules need to be loaded first before this works Apr 18 12:49:54 for more information about "dynamic debug", see https://www.kernel.org/doc/html/latest/admin-guide/dynamic-debug-howto.html (note that this documentation writes to mean the debugfs mountpoint, which is /sys/kernel/debug ) Apr 18 12:55:46 drivers/bluetooth/hci_qca.c:261 [hci_uart]qca_wq_awake_rx =_ "hu %p wq awake rx\012" drivers/bluetooth/hci_qca.c:391 [hci_uart]qca_open =_ "hu %p qca_open\012" drivers/bluetooth/hci_qca.c:452 [hci_uart]qca_open =_ "HCI_UART_QCA open, tx_idle_delay=%u, wake_retrans=%u\012" net/netfilter/xt_tcpudp.c:145 [xt_tcpudp]udp_mt =_ "Dropping evil UDP tinygram.\012" net/netfilter/xt_tcpudp.c:79 [xt_tcpudp]tcp_mt =_ "Dropping evil TCP offset=1 fra Apr 18 12:56:14 I am seeing the same output even after sending can messages Apr 18 12:57:51 I dont think I am getting some log related to CAN Apr 18 12:58:32 As you said there might be an issue with electrical connection Apr 18 12:58:40 I am checking the pinmux now Apr 18 13:06:12 p9.24 and p9.26 are used for CAN Tx and Rx. Pin configurations are correct. Apr 18 13:08:05 One clue is, when I transmit data it sends for the first time, no response there after. Apr 18 13:08:06 ehh, that output you're showing is when you read from /sys/kernel/debug/dynamic_debug/control ... that just gives you a list of all possible debug messages in the kernel that can be dynamically enabled Apr 18 13:09:07 logging simply goes to the kernel log (dmesg) Apr 18 13:09:43 and I've seen that too (message sent once), it means it ran into trouble while sending the first message Apr 18 13:09:50 but, I gotto run, afk Apr 18 13:13:29 checked dmesg in /var/log. No information found related to CAN. there was all related to wlan0 Apr 18 13:21:03 we are using the can bus SN65HVD230 Apr 18 13:21:47 it uses 3.3v but our CAN bus adapter uses 5V. is it cause any prob? Apr 18 13:40:42 I'm pretty sure it's impossible to find "no information related to CAN" if you enable dynamic debug messages for can Apr 18 13:41:08 be sure to enable dynamic debug after loading the relevant kernel modules but before sending the first packet Apr 18 13:42:24 I don't know what you mean by "CAN bus adapter", SN65HVD230 uses 3.3V signalling to the beaglebone, which is what is required Apr 18 13:42:50 the CAN bus itself is differential so it shouldn't be very sensitive to the voltage used Apr 18 13:42:58 afk again Apr 18 14:03:16 we received this log only once Apr 18 14:03:17 Apr 18 14:01:19 beaglebone kernel: can: controller area network core (rev 20120528 abi 9) Apr 18 14:01:19 beaglebone kernel: NET: Registered protocol family 29 Apr 18 14:01:19 beaglebone kernel: can: raw protocol (rev 20120528) Apr 18 16:22:14 Dear, team Apr 18 20:26:18 :/ Apr 18 22:51:26 oh argh, Raj_ wasn't looking at dmesg but at /var/log/dmesg ... Apr 18 23:23:45 how big is the delta generally? some installs don't have one/other Apr 18 23:27:04 afaik /var/log/dmesg just contains a snapshot of dmesg captured somewhere late in the boot process? Apr 18 23:27:18 you can't not-have dmesg Apr 18 23:27:36 well, in insane configurations the utility might not be installed I guess, but then you just install it :P Apr 18 23:31:31 yea I think its a kernel function? as opposed to syslog or some dumping function :) Apr 18 23:31:42 it happens in /dev/log iirc .. or somewhere like that Apr 18 23:33:04 I don't have /var/log/dmesg at all on the beaglebones here, but that's because I've made a reasonably succesful attempt at getting rid of logging to /var/log/ .. https://pastebin.com/raw/Sq2jm7EH Apr 18 23:33:24 it's some sort of kernel interface, never bothered looking into it Apr 18 23:33:47 /dev/log is the syslogd socket Apr 18 23:34:11 lrwxrwxrwx 1 root root 28 Apr 14 12:15 /dev/log -> /run/systemd/journal/dev-log= Apr 18 23:52:12 gotcha Apr 18 23:52:32 I assume you don't ever have problems that require logging to investigate any more ... ;) Apr 19 00:03:13 ? Apr 19 00:03:27 journal Apr 19 00:05:25 or if you just need the kernel log, use dmesg :P (I noticed it now has an option to "tail" the kernel log, dmesg -w .. pretty sure that's semi-newish anyawy) **** ENDING LOGGING AT Wed Apr 19 03:00:03 2017