**** BEGIN LOGGING AT Tue Jun 09 02:59:57 2020 Jun 09 03:00:23 GenTooMan: you used Code Composer Jun 09 04:08:39 I've used CCS when I failed to avoid it Jun 09 04:27:47 got my BBB up to date all dandy, there is something odd (for me at least) why are there 2 usb NIC on the BBB and when I connect it to my PC via USB it creates 2 network connections via the same USB Jun 09 04:27:57 192.168.7.2 and 192.168.6.2 Jun 09 04:28:51 Janos: blame microsoft. one is CDC-ECM (the usb standard for ethernet networking), one is RNDIS (microsoft's proprietary equivalent). Mac only supports CDC-ECM, Windows only supports RNDIS, Linux supports both Jun 09 04:29:29 weird, using mac atm Jun 09 04:29:53 maybe you've installed a third-party RNDIS driver? Jun 09 04:30:03 yup that sounds about right Jun 09 04:30:27 use it for usb tethering with my android phone Jun 09 04:30:32 but I think people were having trouble with it on more recent versions of MacOS, iirc, maybe that's been fixed Jun 09 04:31:13 anyway, so that's why there are two... to cope with microsoft's refusal to implement standards Jun 09 04:31:26 typical Jun 09 04:31:39 thanks for the clarification Jun 09 04:38:25 mm I wonder which package(s) do I need to be able to run the Cloud9 IDE, the smaller images does not seem to have it on by default Jun 09 04:39:17 I'd venture to guess the one with cloud9 in the name :P and a webserver (typ nginx) if it doesn't install one as a dependency Jun 09 04:39:56 I should note that cloud9 is kinda very dead and unmaintained and I know they're looking to replace it Jun 09 04:41:50 c9-core-installer looks promising from your prev listing and nginx seems to be the web server of choice Jun 09 04:43:01 yeah I know that C9 is not the best, but I will be gifting this BBB and I want it to be plug and play, and currently all the available docs point to c9 and connect to the BBB via USB with the web server Jun 09 04:43:51 might it not be better to just wipe eMMC and boot the latest IoT image from sd card? Jun 09 04:44:41 or get BeagleLogic running and gift it as a 12-channel 100 Msps logic analyzer ;-) Jun 09 04:49:22 well it does have a 8G sd card, so I guess it makes sense to just leave the eMMC bare bones and boot the IoT from the sd card Jun 09 04:49:30 * Janos checks on BeagleLogic Jun 09 04:50:26 yeah I do recommend wiping eMMC (sudo blkdiscard /dev/mmcblk1) when booting from sd card, to avoid any future trouble caused by version mismatch between u-boot on eMMC and the image on sd card Jun 09 04:51:55 mm I would have never guessed that could be a problem Jun 09 04:53:14 it's a very common problem, especially since the flasher image isn't at the top of the page and in fact used to be not on the page at all, so instead of reflashing eMMC people would end up running from sd card with some crusty old u-boot on eMMC that doesn't understand the configuration variables in /boot/uEnv.txt on newer images Jun 09 04:56:37 but when you press S2 switch to force boot from the sd card, do you still use the eMMC at all ? Jun 09 04:57:42 powering on while holding the S2 button will cause u-boot on eMMC to be bypassed, which is fine if you need it working properly only once but obviously you don't want to have to do that every time you use the beaglebone if you're going to be booting from sd card by default Jun 09 04:58:17 yeah Jun 09 04:58:21 makes sense Jun 09 04:58:30 and the trouble is that with an old u-boot on eMMC, it would typically _seem_ to boot from sd card just fine with the S2 button, except its lack of understanding the config vars in /boot/uEnv.txt causes all sorts of strange problems Jun 09 04:58:39 without the S2 button Jun 09 04:58:41 sorry Jun 09 05:01:02 honestly the meanest thing you can do these days is to require boost as a dependency Jun 09 05:01:10 just throwing that out there Jun 09 07:00:15 *cough* *kicad* Jun 09 07:06:56 hi Jun 09 07:07:55 actually i have updated my beagle bone black with following update Jun 09 07:07:58 AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher Jun 09 07:08:30 but now it is not showing graphical desktop. Jun 09 07:08:51 So what can i do to obtain grapical desktop Jun 09 07:16:22 zmatt: do you know if there's still a separate mailing list for submitting kernel patches specific to "omap" devices? Or does one need to enter the lkml cesspool? Jun 09 07:16:43 thinkfat: linux-omap Jun 09 07:17:35 @vger.kernel.org Jun 09 07:17:46 good ol' vger... Jun 09 07:17:55 Hi Jun 09 07:18:09 http://vger.kernel.org/vger-lists.html#linux-omap Jun 09 07:19:03 after updating my beagle bone black with following image, i am not getting graphical desktop Jun 09 07:19:15 AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher Jun 09 07:20:23 ?? Jun 09 07:20:43 Ganesh: yeah the default images haven't included a graphical desktop for quite a while now, since few people care about it and it just runs poorly on the am335x (and takes up a lot of space, making it difficult to fit on eMMC) Jun 09 07:21:30 So what can i do to get graphical desktop Jun 09 07:23:02 ?? Jun 09 07:23:24 ehh, if you really insist on having one, install one I guess? or I think there are still lxqt images somewhere... though I don't think they fit on eMMC anymore so you'd have to run from sd card instead, lemme check Jun 09 07:23:34 and stop being so fucking impatient and saying "??", it's really annoying Jun 09 07:24:12 this is a volunteer-run channel, it can take a moment to get a response Jun 09 07:24:29 sorry. Jun 09 07:25:33 there is an lxqt image here, and actually even a flasher, though I don't know how much free space that will leave but you can try it: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Buster_LXQt_Snapshot Jun 09 07:28:59 actually i have required an image with python 3.6 or above Jun 09 07:30:24 this image includes python 3.7 Jun 09 07:30:42 debian stretch has python 3.5, debian buster has python 3.7 Jun 09 07:31:38 ok thanks Jun 09 07:32:18 so first i have to use target media as Micro SD card. Jun 09 07:32:44 yeah the only easy way to reflash a beaglebone is by writing an "eMMC flasher" image to SD card and then booting the beaglebone from that Jun 09 07:34:03 ok if it works from SD card than i can use image for target media eMMC flasher Jun 09 07:34:09 to whoever at TI wrote the TI dmtimer framework: **PALM** Jun 09 07:35:23 Ganesh: the "eMMC flasher" images will immediately reflash eMMC if you boot from them. if you want to boot normally from an SD card you need a "microSD" image Jun 09 07:35:47 thinkfat: just write the registers directly :) Jun 09 07:38:37 there's a method to request a timer by device_node. however, getting a pointer to the timer_ops that contains a pointer to the request function means you need the platform_device of the timer, which requires OF magic to obtain. Jun 09 07:39:14 this is just convoluted shit Jun 09 07:40:27 omap_dm_timer_request_by_node Jun 09 07:40:47 not talking about the fact that the whole "set_source" method to set the fclk doesn't work at all. Jun 09 07:40:53 and nobody noticed Jun 09 07:40:56 for years Jun 09 07:41:28 omap_dm_timer_request_by_node is not an exported function Jun 09 07:41:37 well it is, but it's only in timer_ops Jun 09 07:42:24 ? there are drivers just using it though: https://elixir.bootlin.com/linux/v4.5/source/drivers/media/rc/ir-rx51.c#L181 Jun 09 07:42:24 but you need to jump through a couple of hoops to get the timer_ops pointer Jun 09 07:43:11 4.5 - old kernel Jun 09 07:43:41 oh lol it grabbed that from my url history, wasn't paying attention Jun 09 07:44:00 someone "refactored" it in 4.14 I think and made a complete mess of it Jun 09 07:44:09 oh god what did they do Jun 09 07:44:45 all the previously public symbols are now inside a timer_ops struct that requires to get the platform data of at least one timer pdev... Jun 09 07:44:47 wait, the fuck Jun 09 07:45:03 how on earth are you now supposed to find any timer? wtf Jun 09 07:45:12 what idiot did this Jun 09 07:45:12 yep, I know Jun 09 07:45:45 it's just completely broken Jun 09 07:47:17 the most common task is to request an omap_dm_timer* from an OF phandle, right? Jun 09 07:47:20 so that should be easy Jun 09 07:48:23 lol, and that one driver that used it has been rewritten to do software-based bitbanging instead of generating pulses with hardware timing... yeah that's a great improvement guys, well done Jun 09 07:49:20 there should be a pwm driver that uses it Jun 09 07:49:25 the API before this moronification is what you want Jun 09 07:50:38 or just say fuck you to the whole dmtimer framework and just make yourself the driver for the timer Jun 09 07:51:29 and then if you submit the driver and people complain, "well, you made the dmtimer API inaccessible so what did you expect?" Jun 09 07:52:34 https://elixir.bootlin.com/linux/v4.19.94/source/drivers/pwm/pwm-omap-dmtimer.c#L242 Jun 09 07:53:02 apparently this is how you now do it. Jun 09 07:53:54 I guess that's not too awful... except it will crash horrifically if the device node is pointing to the wrong thing Jun 09 07:54:11 since you're using the platform data without any way to check whether the correct driver is attached to it Jun 09 07:54:20 you first obtain the timer pdev from its phandle, then get the platform_data and from that the timer_ops, and then you need to request it by its phandle to get an omap_dm_timer * Jun 09 07:54:30 it will also fail horribly if the timer's driver is not yet loaded Jun 09 07:54:58 well, yes, then the timer_ops in empty Jun 09 07:55:08 no, then timer_pdata is NULL Jun 09 07:55:15 oh, ok Jun 09 07:55:17 oh wait Jun 09 07:55:18 never mind Jun 09 07:55:28 of_find_device_by_node would fail Jun 09 07:55:30 I'm an idiot Jun 09 07:55:47 but if it's the wrong driver then it'll crash and burn Jun 09 07:56:38 I don't understand why anyone would do this Jun 09 07:56:42 it's an API specific to one driver Jun 09 07:56:51 and it still is... this is pointless abstraction Jun 09 07:57:01 an abstract interface that only has, and only ever will have, a single implementation Jun 09 08:05:05 yep Jun 09 08:05:28 the only "advantage" is that it creates less symbols Jun 09 08:05:37 and that's about it Jun 09 08:05:47 hm Jun 09 08:05:58 maybe it makes module stacking easier? Jun 09 08:06:05 no.. Jun 09 08:06:18 symbol dependencies are resolved by depmod Jun 09 08:07:43 no, it just hides the module dependency Jun 09 08:23:09 unfortunately the git history doesn't reveal anything about the motivation Jun 09 08:23:58 I don't intend to dig through the linux-omap archive, I'm not a psychologist Jun 09 09:07:18 omap drivers are full of half-baked abstractions Jun 09 09:20:59 adding insult to injury, it lacks a function to setup event capture :-(((( Jun 09 09:21:20 where's my fail button Jun 09 09:44:52 thinkfat: like I said, just make yourself the driver for the timer itself Jun 09 09:45:05 access the registers directly Jun 09 09:45:42 :-) Jun 09 09:46:43 evil!1!1! Jun 09 09:46:56 that would be, like, buying an ebike and then leaving the battery at home because it's too heavy Jun 09 09:47:07 <_troll_> it's good to be evil Jun 09 09:47:15 more like connecting the wires to the motor by hand while driving Jun 09 09:47:19 says a _troll_ Jun 09 09:47:22 directly from the battery Jun 09 09:48:12 thinkfat: what does the dmtimer abstraction give you really, other than frustration and lack of compatibility between kernel versions? Jun 09 09:48:32 iirc setting up a dmtimer directly is maybe a few lines of code Jun 09 09:48:51 possibly less than what's needed to find the dmtimer API :P Jun 09 09:48:53 grab the code from starterware Jun 09 09:49:00 does that still exist? Jun 09 09:49:07 starterwhat? Jun 09 09:49:13 the TI non-OS libs Jun 09 09:49:17 I mean, it hasn't disappeared, no matter how hard I wish Jun 09 09:49:19 yes, they do Jun 09 09:49:20 for omapish CPOOOs Jun 09 09:49:37 am335x starterware is atrocious Jun 09 09:50:11 like, written by people who should never be allowed to write drivers and instead maybe consider gardening or something Jun 09 09:50:15 I tried using that code when I did some barebone bone hacking (porting to a diffent OS). Jun 09 09:50:22 oh, so its like STM32 HAL :) Jun 09 09:50:32 In the end I had to ask zmatt how to do the stuff correctly Jun 09 09:51:16 like, the uart driver has many functions that will corrupt data (including enable/disable interrupts) and the uartEcho example compiles to a deadloop if any optimization is enabled Jun 09 09:51:28 :) Jun 09 09:51:34 ok HAL is not that bad :) Jun 09 09:51:59 am335x starterware, at least the parts I've looked at, is really really bad Jun 09 09:52:00 if you run starterware in a container, does it become tupperware? Jun 09 09:52:18 or selfaware` Jun 09 09:52:19 or selfaware? Jun 09 09:52:29 I never used it but I had a look, and my eyes AreStillBleedingFromTheCamelCaseBullShit Jun 09 09:53:28 ...PWM signal generation as well as Capture mode of DMTimer is not supported in StarterWare... Jun 09 09:55:54 setting up a timer (as a periodic counter, with or without capture) is like... writel_relaxed to 3 registers Jun 09 09:56:05 plus one to enable interrupts Jun 09 09:57:32 sans integration into the whole dynamic power management stuff Jun 09 09:57:40 nope, that's done for you Jun 09 09:58:17 not if I bang the registers, right? Jun 09 09:58:45 is the AM335x so starved of address space that they had to triple re-use registers in the UART? Jun 09 09:58:48 depends on what you mean... you'll need to add some code for suspend/resume if you want to support deepsleep Jun 09 09:59:11 pm_runtime stuff Jun 09 09:59:12 av500: no, it's the awful legacy compatibility with ancient uarts Jun 09 09:59:20 they had that? Jun 09 09:59:42 thinkfat: does runtime pm apply to you? don't you need the timer running continuously? Jun 09 09:59:51 no, doesn't.. Jun 09 10:00:01 then no need to worry about it Jun 09 10:00:10 so I could just call it one time to activate the timer and be done with it Jun 09 10:00:16 0 calls to it Jun 09 10:00:35 the timer will be enabled for you before probe() and if you don't enable runtime pm then the kernel will assume you don't want power management Jun 09 10:00:46 ah, right Jun 09 10:01:19 but then I'd have to completely disable the kernel dmtimer support, because that's what is going to grab the timer and it will of course enable runtime pm Jun 09 10:01:39 no, you change the compatible= of the relevant timer in DT to match your driver Jun 09 10:01:54 so the normal dmtimer won't attach to it Jun 09 10:02:09 your driver will take its place, but just for that timer Jun 09 10:02:14 or status="disable" Jun 09 10:02:24 no, because you need that node Jun 09 10:02:29 ah, right Jun 09 10:02:29 but with your own driver Jun 09 10:02:43 that sounds dirty.... Jun 09 10:02:49 not at all Jun 09 10:04:08 for example I've used this to attach the uio_pdrv_genirq driver to a dmtimer and use it from userspace: https://pastebin.com/raw/KW5z0AWB Jun 09 10:05:39 and my ecap clocksource driver is an alternative to the normal ecap pwm driver Jun 09 10:06:12 it's important to use the existing DT node since there's power management stuff attached to it Jun 09 10:07:03 (managed by platform infrastructure, independent of what driver is used) Jun 09 10:10:14 ah well... Jun 09 10:11:22 now, on the question of synchronizing the counters of two timers, my idea would be to start them, then read the counter register of one of them until it changes, then write to the trigger register of both to force a reload Jun 09 10:11:25 how does that sound? Jun 09 10:12:29 thinkfat: both run on the same clock and have the same period? I'd enable posted mode in both of them and then just start or reset them with two back-to-back writel_relaxed Jun 09 10:12:41 (one per timer) Jun 09 10:12:52 both run on the same clock, but not the same period Jun 09 10:13:09 integer ratio? Jun 09 10:13:18 same procedure anyhow Jun 09 10:14:30 you can either set the counter while stopped and then start, or use trigger to set the counter... and you can make that choice independently for each timer Jun 09 10:14:55 two immediately consecutive writes should end up right after each other on the interconnect Jun 09 10:16:12 you could be extra sure of that if you first do a full memory barrier (to drain any buffered writes in the cortex-a8 and local interconnect) and some read from the one of the counters (to drain the path from mpu subsystem to target l4 interconnect) Jun 09 10:16:33 like, a "dmb sy" Jun 09 10:16:48 yep Jun 09 10:17:06 though tbh that's probably overkill Jun 09 10:17:29 reading from one or both timers is probably good enough Jun 09 10:17:39 especially since the cortex-a8 is very in-order Jun 09 10:17:52 it's still important for me that both timers start counting on the same fclk edge Jun 09 10:18:01 how fast is fclk? Jun 09 10:18:10 well, 10MHz, so I have a 100ns window Jun 09 10:18:40 then reading the timers is pointless, the read would probably take more than an fclk cycle Jun 09 10:18:41 or, could be 24MHz, too Jun 09 10:18:51 back-to-back writes is the best you can do Jun 09 10:19:11 no external event they can by both synced to? Jun 09 10:19:14 be* Jun 09 10:19:20 av500: not with dmtimer no Jun 09 10:20:42 I'd expect back-to-back writes (with the path cleared in advance by a read) to sync the timers to within 1 cycle, with high probability of perfect sync Jun 09 10:20:48 zmatt: when I TRG a PWM timer, will that count as a overflow and toggle the PWM output? Jun 09 10:21:10 that's a great question Jun 09 10:22:01 no idea :) Jun 09 10:22:09 hah Jun 09 10:22:20 I finally found something you didn't already try :-) Jun 09 10:22:57 you could figure it out with a scope and a timer configured to sub-1Hz PWM Jun 09 10:23:10 or a led even :P Jun 09 10:23:26 yeah, I'll know soon enough Jun 09 10:23:41 if my PPS pulse comes out with the wrong polarity it doesn't Jun 09 10:24:14 I'm 99% sure it can't get the wrong polarity Jun 09 10:24:42 would a match event toggle the PWM even without prior overflow event? Jun 09 10:25:39 I seem to recall it doesn't really toggle.. as in, configuring the match to be below the reload value won't suddenly cause it to toggle on overflow alone Jun 09 10:26:00 but maybe I misremember Jun 09 10:26:52 yeah Jun 09 10:26:55 I tested it Jun 09 10:28:15 setting match below the reload value results in constant level, not a toggle on each overflow Jun 09 10:28:31 https://pastebin.com/raw/DjbKDp09 Jun 09 10:28:54 (ignore the tildes, long story) Jun 09 10:29:56 (well not a very long story, this is from baremetal forth code where I used the tilde-prefix for fields/methods) Jun 09 10:31:11 so once you start the timer, it's fixed whether overflow will set the output and match will clear it or vice versa Jun 09 10:32:18 alright, according to the TRM, the first match is ignore if no overflow has happened before Jun 09 10:32:58 in other words, the level you configure is the level used after match (and overflow sets the opposite) Jun 09 11:54:35 I think I'd appreciate a patch that validates a clocksource' registration data instead of a kernel panic due to a division-by-zero Jun 09 11:54:46 lol Jun 09 11:55:23 now I need a recue plan... Jun 09 11:55:39 just boot from the previous kernel? Jun 09 11:55:50 (or from sd card) Jun 09 11:55:55 or with the normal DT Jun 09 11:55:56 and that would prevent the module being loaded, right... Jun 09 11:56:12 because the kernel version wouldn't match Jun 09 11:56:21 because modules are installed in a per-kernel dir Jun 09 11:56:28 indeed Jun 09 11:56:49 and using a DT that doesn't include your driver should also prevent it from being loaded Jun 09 12:03:29 heh Jun 09 12:03:50 saved by the missing tclkin when I removed the gpsdo cape ;) Jun 09 12:04:07 that caused an async abort during module load but the kernel keeps running Jun 09 12:26:03 hm, also, a clocksource doesn't take it lightly to have its counter resetted. Jun 09 12:26:58 lol Jun 09 12:27:11 that should not be a surprise Jun 09 12:27:35 just start the timers in sync to begin with Jun 09 12:30:51 yes, that's what I'm doing initially, only I had a really bright idea to restart the timers on the first captured pps pulse, but that is of course not workable Jun 09 12:30:58 not like this, at least Jun 09 12:51:38 it won't be well-synchronzied to it anyway Jun 09 12:51:52 interrupt latency and all that Jun 09 12:51:52 now, why do I have an I2C line stuck low all of a sudden? Jun 09 12:52:09 a device got confused? Jun 09 12:52:27 could be, yes, I've seen that before with eeproms Jun 09 12:52:34 but it should cure after a power cycle, no? Jun 09 12:53:09 if you power cycle well enough and don't leave enough residual voltage on the 3.3v supply to keep the eeprom's logic alive Jun 09 12:53:31 well, there's not an eeprom, but I suspect the temperature sensor might ... Jun 09 12:53:40 or whatever i2c device Jun 09 12:55:39 is there a way to run the i2c recovery procedure without configuring the pins as gpio first? Jun 09 12:55:57 the driver should automatically attempt i2c recovery I think Jun 09 12:56:24 the i2c controller lets you select a test mode where you can manually manipulate sda and scl Jun 09 12:56:28 which is used for recovery Jun 09 13:49:49 no, just one of the bodgewires came loose. Jun 09 13:50:00 I really need to get the next pcb revision launched Jun 09 13:50:07 lol Jun 09 13:51:12 I thought it was stuck on, but it was really ony the flux residue that glued it into place Jun 09 14:10:10 hmmmm Jun 09 14:10:24 the clocksource framework usually autoselects the sources based on a rating, no? Jun 09 14:10:48 so, maybe there's a way to set a very bad rating initially so that it selects a different timesource at boot... Jun 09 14:21:36 yes, "struct clocksource" has a "rating" field for that purpose Jun 09 14:21:59 (to be set before registering) Jun 09 14:29:08 yes, if I set that to 1 it's likely not going to get selected. Jun 09 14:29:21 now, how can I change that rating... Jun 09 14:29:43 by setting the rating field before registering the clocksource :P Jun 09 14:29:55 no, there's a "clocksource_change_rating" call actually Jun 09 14:29:55 https://github.com/dutchanddutch/bb-kernel/blob/am33x-v4.14/patches/local/0015-clocksource-add-timer-ti-ecap-driver.patch#L107 Jun 09 14:30:04 that's for changing after registering I assume Jun 09 14:30:24 yeah Jun 09 14:30:53 before registering you just set cs->rating Jun 09 14:31:41 ok, but I cannot call that from an interrupt service... I need to queue some work, I guess Jun 09 14:31:56 what? interrupt service? Jun 09 14:32:10 ??? Jun 09 14:32:38 oh you mean to change the rating later on? Jun 09 14:32:48 you can also change the clocksource manually from userspace I think Jun 09 14:33:48 you could also defer registering your clocksource until you have it working properly Jun 09 14:35:08 yes, but it all boils down to the capture interrupt that will know when the timepulses start arriving Jun 09 14:35:30 yeah that would need to trigger deferred work Jun 09 14:35:43 i.e. workqueue Jun 09 15:46:33 almost ... Jun 09 15:50:20 m Jun 09 16:01:57 m 2 u Jun 09 17:40:04 alright, it works. Jun 09 17:40:22 the pps output of the timer and gps timepulse stay in lock Jun 09 17:40:46 now I need to work out where the absolute offset comes from Jun 09 17:43:12 how are you starting/syncing them now? Jun 09 17:44:22 https://pastebin.com/gzahNcEf Jun 09 17:44:30 no bells and whistles Jun 09 17:45:25 yeah that should be pretty tight... like I said, you may want to do a read (of any register) from at least one of the two timers Jun 09 17:45:28 before doing the two writes Jun 09 17:45:41 it probably doesn't matter, but just in case Jun 09 17:46:31 are the timers configured in posted mode? Jun 09 17:46:57 or is 10 MHz too fast for that? I can't remember the constraints Jun 09 17:49:00 okay posted mode requires that the timer clock is slower than interface clock / 4, which is 25 MHz Jun 09 17:54:21 as far as I understand the framework stuff, the timers are in posted mode Jun 09 17:58:34 also, _OMAP_TIMER_TRIGGER_OFFSET is wrong Jun 09 17:58:46 (and has zero references in the kernel) Jun 09 17:58:56 heh, which kernel ;) Jun 09 17:58:59 4.9 Jun 09 17:59:08 ancient Jun 09 17:59:16 4.19.94 is the current baseline Jun 09 17:59:18 4.19 I mean Jun 09 17:59:24 sorry Jun 09 17:59:41 https://elixir.bootlin.com/linux/v4.19.127/C/ident/_OMAP_TIMER_TRIGGER_OFFSET Jun 09 18:00:20 it's referenced through OMAP_TIMER_TRIGGER_REG Jun 09 18:01:06 but that define contains the also the corresponding wait register offset, which I don't need here Jun 09 18:03:16 thing is, unless func_base has a really weird value, the trigger register is not at that offset Jun 09 18:06:31 peripheral base for (timer2-7) is at 4804x000 (x depends on timer), the block of registers common to all timers (starting with CTRL) is at 4804x0038, trigger register is at 4804x0044 Jun 09 18:07:09 so offset 0x44 from the start of the peripheral, or offset 0x0c from the start of the common block Jun 09 18:11:01 timer1 and watchdog timers have a 0x24-byte omap2-style wrapper before the common block, timer 0 and timers 2-7 have a 0x38-byte omap4-style wrapper Jun 09 18:11:49 offset 0x30 for the trigger register is 0x24 + 0x0c, i.e. it's the correct offset (from start of peripheral) for timers with an omap2 register layout Jun 09 18:17:28 oh GROSS Jun 09 18:17:52 they set func_base to timer + 0x14 for new timers /o\ Jun 09 18:17:54 yep ;) Jun 09 18:17:57 that's fucking disgusting Jun 09 18:18:53 why would you do that, instead of setting func_base to the actual start of functional registers, being io_base+0x24 for old timers and io_base+0x38 for new timers Jun 09 18:20:13 with the kernel's definition of "func_base", everything below offset 0x24 is stlil totally different between the two timer versions Jun 09 18:21:21 anyway, timer->posted will be true if the timer is posted Jun 09 18:21:47 hmm, wait Jun 09 18:22:06 https://elixir.bootlin.com/linux/v4.19.127/source/include/clocksource/timer-ti-dm.h#L66 Jun 09 18:22:12 lemme check which errata those are Jun 09 18:22:39 (saying "omap3/4/5 devices including AM33xx" is also garbage, AM33xx is not an omap3/4/5 device) Jun 09 18:25:06 you mean, the timers are actually not posted because of some obscure errata work-around? Jun 09 18:25:31 yeah, that's what I remembered.. the only timer erratum is that in posted mode, the counter and capture values won't be uptodate right after taking the interface clock out of idle (since they require a few cycles to synchronize) Jun 09 18:26:08 but you're never halting the interface clock anyway Jun 09 18:27:42 you could use __omap_dm_timer_override_errata and then __omap_dm_timer_enable_posted Jun 09 18:32:54 I'm pretty sure this erratum is completely irrelevant on am335x. I can see this erratum being a problem on omaps where the interface clock may be dynamically gated, but on the am335x you need to manually enable the clock and poll a register before you can access the timer, by which time you're many interface clock cycles later and the registers will have synchronized Jun 09 19:15:49 well, it definitely made a difference of 100ns Jun 09 19:17:19 cmt Jun 09 19:18:05 i.e. one cycle? Jun 09 19:18:25 yes Jun 09 19:18:31 one timer fclk cycle Jun 09 19:20:28 are they still out of sync? (the second timer lagging more than 1 fclk cycle behind the first) Jun 09 19:20:55 yes, about 200ns Jun 09 19:21:05 weird Jun 09 19:21:14 but that might be due to something else, I have another measurement to make Jun 09 19:21:32 sometimes it really help to have a scope with more than 2 channels ;) Jun 09 19:21:50 like a beaglebone with BeagleLogic on it? Jun 09 19:22:15 no, more like pretty recent Siglent gear Jun 09 19:22:52 like, you're limited to 3.3V but 12-channel 100 Msps is not bad Jun 09 19:23:24 I like the 4 analog + 16 digital channels on my scope Jun 09 21:24:19 zmatt the PRU operates off what clock on the BBB? Jun 09 22:09:34 zmatt: is there a way to get notified of a reboot? Jun 09 22:10:22 it seems that there's a problem if the timer clock comes from tclkin, reboot will fail. It seems to get through u-boot but then the kernel hangs somewhere Jun 09 22:10:33 zmatt: in a driver, that is Jun 09 22:47:03 zmatt: you have a C++ baremetal application? Jun 09 23:59:11 Hey peoples Jun 09 23:59:38 what overlay do I need to use to enable my PRU Jun 10 00:05:16 I dont want to do the config pin stuff everytime Jun 10 01:17:47 is there an overlay for enabling the PRU pins **** ENDING LOGGING AT Wed Jun 10 02:59:57 2020