**** BEGIN LOGGING AT Tue Sep 28 02:59:56 2021 Sep 28 05:01:02 I finally figured out the vortex of what is the Isosceles Trapezoid of mounting holes on the BBBlue! Sep 28 05:01:26 It took a deep breath and some software but there. Done. Sep 28 05:01:48 Thank you. Sep 28 05:03:55 At first, I had the offset instead of the straight line from A to B from mounting hole A to mounting hole B. This was not configurable for me for some reason. Sep 28 05:04:17 3.18 mm was the offset. Sep 28 09:38:41 hey Sep 28 10:07:22 anyone who can help me enable earlyprintk? I have enable the debug_ll option and earlyprintk option in the kernel menuconfig Sep 28 10:08:21 and for the kernel low-level debugging port i have selected "Kernel low-level debugging message via AM33XX UART1" Sep 28 10:08:47 but once i start the kernel i add the option earlyprintk to the kernel options and it just hangs Sep 28 10:08:55 or atleast doesn't generate output Sep 28 10:09:46 i have tried earlyprintk=serial Sep 28 10:10:03 and i have tried earlyprintk=ttyO0,115200n8 Sep 28 10:55:26 the serial console is uart0, not uart1 Sep 28 11:09:14 oh never mind it's just mislabeled, it's actually using uart0 Sep 28 11:10:49 the earlyprintk kernel parameter does not take any argument on arm Sep 28 11:15:39 Daulity: I wouldn't be surprised if almost nobody uses earlyprintk on am33xx and it's just broken Sep 28 11:17:36 it's definitely been broken before: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg92515.html (but this is a very old patch and is definitely integrated) Sep 28 11:18:16 what kernel version are you using? Sep 28 11:19:15 btw the console tty is ttyS0, ttyO0 is just a backwards-compat symlink from back when the omap-serial driver was used instead of 8250-omap Sep 28 11:21:20 There is no option in the menuconfig that allows me to select UART0 Sep 28 11:21:28 only UART1 and up Sep 28 11:21:51 ah yea it's misslabled :) Sep 28 11:22:30 i have tried just earlyprintk and it hangs atleast no activity after u-boot says starting kernel Sep 28 11:22:49 without earlyprintk it boots Sep 28 11:23:24 kernel version: 4.19.94 Sep 28 11:25:54 there's also earlycon instead of earlyprintk, which appears to work totally differently Sep 28 11:26:30 I may give that a try Sep 28 11:28:26 it looks like that requires specifying something like console=uart8250,mmio32,0x44e09000,115200n8 Sep 28 11:28:40 or earlycon= ... the difference isn't quite clear to me Sep 28 11:29:35 got something working Sep 28 11:30:23 changed the bootparam to just earlyprintk and the console argument used ttyO0 and after changing that to ttyS0 i got output right away Sep 28 11:30:37 nice Sep 28 11:31:46 looks like earlycon actually doesn't require any parameters, it is able to get the console port from DT (/chosen/stdout-path) Sep 28 11:32:52 hmm, kernel docs say that's ARM64 rather than ARM, but the docs might be wrong of course Sep 28 11:35:59 yeah it totally looks like it should work fine on any platform that uses DT Sep 28 11:38:24 or... never mind Sep 28 11:46:01 no it does Sep 28 11:48:06 Daulity: so yeah you can also try earlycon (no parameters) instead of earlyprintk, it might have a cleaner transition to the normal serial console (since it's integrated into the serial driver instead being a completely separate hack) Sep 28 11:48:44 (this assumes you have CONFIG_SERIAL_EARLYCON enabled) Sep 28 11:48:56 oh never mind that gets automatically enabled Sep 28 12:20:15 Daulity: in case it's of interest, here's the outline of how earlyprintk and earlycon work (on am335x): https://pastebin.com/ESjHFDqa Sep 28 12:20:54 it's interesting how they have absolutely nothing whatsoever in common Sep 28 12:26:35 Daulity: I'm also deeply puzzled by your report that changing console from ttyO0 to ttyS0 affected earlyprintk for you, since I've seen absolutely nothing to suggest the console parameter would have any relevance to earlyprintk, it's a tiny piece of standalone code (mostly in assembly) that uses hardcoded addresses obtained from Kconfig Sep 28 13:00:13 zmatt: i can verify if it was the case that changing it worked Sep 28 13:00:22 i tried a few things hoping it would work :) Sep 28 13:01:39 earlycon looks to me like it would be more robust than earlyprintk Sep 28 13:02:31 like, earlyprintk hardcodes a kernel virtual address, that makes me a bit uncomfortable Sep 28 13:10:13 both ttyO0 and ttyS0 work now so I did change something and make it work :) Sep 28 13:10:19 something else* Sep 28 13:44:19 zmatt: thank you for all your help :) Sep 28 16:15:07 zmatt sorry I dissappeared yesterday, you were helping me with trying to fix my beaglebone's clock issues that are giving warnings when I try to make .dtbo overlays Sep 28 16:15:40 timedatectl timesync-status returns: Sep 28 16:15:45 try: timedatectl timesync-status Sep 28 16:15:50 also: 01:17 <@zmatt> the_person48: P8_31-46 should be NOPULL Sep 28 16:16:27 oh yeah I remember you saying that for P83-6 and P20-25, is it the same issue with 31-46? Sep 28 16:16:35 that they already have external pulldowns? Sep 28 16:16:57 and I'm having trouble installing timedatectl Sep 28 16:17:10 it's installed by default Sep 28 16:17:14 I think it might be my old version of debian (9.5), I'll try googling for analagous version Sep 28 16:17:17 oh right Sep 28 16:17:19 oh Sep 28 16:17:28 I don't know if systemd-timesyncd was even used back then Sep 28 16:17:35 oh actually I mistyped it sorry Sep 28 16:17:39 it worked this time Sep 28 16:17:54 oohh I see Sep 28 16:18:02 yeah itt's installed just doesn't have that command Sep 28 16:18:14 here's the output of timedatectl Sep 28 16:18:26 https://pastebin.com/DvrXcgma Sep 28 16:18:33 and P8.03-06 + P8.20-25 are the eMMC pins which have strong external pullups Sep 28 16:19:00 P8.31-46 are the boot config pins which have weak external pulls (up or down, varies per pin) Sep 28 16:19:20 gotcha Sep 28 16:19:27 ok I'll run that by my coworker Sep 28 16:19:36 I told him the bit about the strong ones before and he agreed Sep 28 16:20:02 creating a conflict between external pullup and internal pulldown or vice versa should be avoided Sep 28 16:20:16 yeah that makes sense Sep 28 16:20:48 since it may cause the voltage to float at an intermediate level (neither logic-high nor logic-low but some indeterminate level in between) Sep 28 16:20:56 ok, cool Sep 28 16:21:01 that actually does make sense to me Sep 28 16:21:04 will adjust Sep 28 16:21:44 and that paste is just timedatectl, not timedatectl timesync-status Sep 28 16:22:10 yeah it says "unknown option: timesync-status" Sep 28 16:22:15 when I try the full command Sep 28 16:22:16 oh Sep 28 16:22:25 ehh, what about timedatectl show-timesync Sep 28 16:22:51 also unknown operation Sep 28 16:23:05 *sigh* Sep 28 16:23:50 sorry Sep 28 16:24:08 I'm trying to find an old version of the command Sep 28 16:24:17 it's part of systemd Sep 28 16:24:37 your systemd is probably just too ancient Sep 28 16:24:55 how about: busctl get-property org.freedesktop.timesync1 /org/freedesktop/timesync1 org.freedesktop.timesync1.Manager ServerName Sep 28 16:27:54 The name org.freedesktop.timesync1 was not provided by any .service files Sep 28 16:28:56 try configuring a known-good NTP server (e.g. 0.debian.pool.ntp.org if you don't know a local one) into the "NTP" variable in /etc/systemd/timesyncd.conf Sep 28 16:29:14 and then sudo systemctl restart systemd-timesyncd Sep 28 16:29:24 ok Sep 28 16:29:25 will do Sep 28 16:29:50 and I know I asked this yesterday, but what happens if the clock is off? what problems exactly does it cause with make? Sep 28 16:30:04 cause I'm not sure we need it for anything else Sep 28 16:30:15 make uses file modification dates to figure out which files to rebuild Sep 28 16:31:16 so might I be able to work around it by just deleting the old output overlay .dtbo file? Sep 28 16:31:21 then recompiling the .dtsi with make? Sep 28 16:31:37 if one or more source files have correct dates and yoru system date is in the past, make will constantly think source files are newer than the generated outputs and keeps rebuilding them Sep 28 16:31:57 and it'll keep complaining Sep 28 16:32:19 ah I see Sep 28 16:32:32 so unnecessary rebuilding basically? Sep 28 16:32:52 yes Sep 28 16:33:18 ok, I will still try to figure out the NTP thing Sep 28 16:33:26 but if it doesn't work I'll probably just let it go then Sep 28 16:33:26 and of course it's also annoying when transferring files to/from your beaglebone, and it makes tools like rsync potentially hazardous Sep 28 16:33:28 doesn't sound too bad Sep 28 16:33:58 and in general you won't be able to determine which things have changed when Sep 28 16:34:07 which sounds obnoxious enough already to me Sep 28 16:34:39 yeah true Sep 28 17:08:06 So the console image has the same idle current as the TIDL image. In both cases they consume 4W at idle. Sep 28 17:09:14 really? curious Sep 28 17:12:24 I though tidl made a noticable difference, but it's been quite a while since I played with the BBAI so I might just misremember Sep 28 17:17:56 Are any of these modules (DSP, EVE) configurable via sysfs? Sep 28 17:20:23 pretty sure the DSPs have remoteproc devices yes, though I'd assume the console image doesn't include any firmware for them hence they will be idle. iirc the EVEs had no remoteproc devices and are instead managed by TIDL firmware running on the DSPs. I could be mistaken about that since I've never looked into how TIDL works really Sep 28 17:21:33 you can also check their state using "sudo omapconf show opp", for the DSPs, EVEs and IPUs, it should show their frequency in parentheses with the (1) note indicating module is disabled Sep 28 17:22:05 for some reason EVE3-4 are missing from that overview, though if all of the aforementioned are off there's no reason EVE3 or EVE4 would be on Sep 28 17:24:01 -bash: omapconf: command not found know what package it's in? Sep 28 17:26:21 oh yeah like I said before the console image is rather minimalistic and shouldn't be used unless you're prepared to manually install whatever you need Sep 28 17:26:27 pretty sure the package is called omapconf too Sep 28 17:26:52 E: Unable to locate package omapconf Sep 28 17:26:58 huh Sep 28 17:27:03 dpkg -S doesn't tell me anything either Sep 28 17:27:11 did you do "apt-get update" first to fetch the package lists? Sep 28 17:27:48 I've already installed a whackload of packages so yeah. But I'll run it again right now Sep 28 17:27:49 -S searches for files in installed packages so that's not really useful here Sep 28 17:27:53 hmm Sep 28 17:28:10 ah, package tiomapconf Sep 28 17:28:41 Thanks, that's working. How did you find out? Sep 28 17:32:11 dpkg -S, since I had it installed :P Sep 28 17:32:15 IT looks like EVE1 and EVE2 are disabled. DSP1 and DSP2 are 600MHz. IVA is 388MHz. IPU1 and UPU2 are on as well. Ass is DSS. I don't think I need any of those things. Sep 28 17:32:31 600MHz or (600MHz) ? Sep 28 17:32:46 with the parentheses, what does that mean? Sep 28 17:33:08 see note below the table Sep 28 17:34:09 Ah those are all part of the same module? So if they're off why is the device still drawing 4W? Sep 28 17:34:52 not sure what you mean, like I said earlier "it should show their frequency in parentheses with the (1) note indicating module is disabled" Sep 28 17:34:59 and I don't know what's drawing 4W on the BBAI Sep 28 17:35:19 my bbx15 (which uses the same SoC) barely gets warm to the touch, and it doesn't have a heatsink Sep 28 17:43:52 With a fan cape installed the temperature was 35C or so. I've unplugged the fan cape (it was drawing a little current) and temperatures are now over 50C. Sep 28 17:44:35 like, the internal temperatures reported by omapconf ? Sep 28 17:44:45 Yep. Is there a way to turn off the power into the EVE modules? Sep 28 17:44:54 via the regulators? Sep 28 17:45:50 50C is not hot Sep 28 17:46:09 max junction temperature is 90C Sep 28 17:47:23 like, 50C or 55C would not be reason to install a fan Sep 28 17:47:27 pushing 60C now. And 50C is not. Sep 28 17:47:42 50C is hot rather Sep 28 17:48:03 50C external temperature is hot to touch yes Sep 28 17:53:04 so my bbx15 with both cortex-a15 cores enabled at constant 1.5 GHz (cpu governor 'performance") but idle load shows around 55C stable, external temperature on the package is certainly warm but I can hold my finger pressed down on the package without hurting myself Sep 28 17:53:43 I don't think I have a way to measure its power consumption Sep 28 17:54:13 64C now. idle. Sep 28 17:54:27 yeah I know the bbai runs hot Sep 28 17:54:33 I'm just not sure why Sep 28 17:54:46 apparently the bbx15 is able to cool itself more through the larger pcb Sep 28 17:55:45 and none of the regulators are disabled? Sep 28 17:56:00 pretty sure disabling any of the supplies is forbidden Sep 28 17:57:06 they can be lowered for individual domains (shown as "Operating Point"), but mine are all at their maximum (NOM for VDD_CORE, HIGH for the others) Sep 28 17:58:57 (VDD_CORE has only a single operating point) Sep 28 17:59:15 are the dtbs for x15 and ai the same? Sep 28 17:59:26 no since they're completely different boards Sep 28 18:05:59 also uses am5728 whereas the ai uses am5729 Sep 28 18:06:05 they both use the am5729 Sep 28 18:06:54 iirc the am5729 didn't publicly exist at the time the bbx15 was released which is why it was spec'd as am5728 Sep 28 18:07:01 typo here then https://beagleboard.org/x15 Sep 28 18:07:35 jkridner: might be worth changing in the bbx15 spec? Sep 29 01:14:38 Hejho! Can I ask anybody here a question about pin assignment on beaglebone AI? Sep 29 01:15:55 I try to use the UART of the PRU's. This is how I tried to reconfigure the pins. Sep 29 01:16:20 This is part of my device tree overlay: Sep 29 01:16:21 &cape_pins_default { Sep 29 01:16:21 pinctrl-single,pins = < Sep 29 01:16:22 DRA7XX_CORE_IOPAD( 0x3614, PIN_OUTPUT | MUX_MODE10 ) // P8.31a PRU1 TX Sep 29 01:16:22 DRA7XX_CORE_IOPAD( 0x3610, PIN_INPUT | MUX_MODE10 ) // P8.33a PRU1 RX Sep 29 01:16:23 DRA7XX_CORE_IOPAD( 0x35E4, PIN_INPUT | MUX_MODE10 ) // P8.43 PRU0 UART RX Sep 29 01:16:23 DRA7XX_CORE_IOPAD( 0x35E8, PIN_OUTPUT | MUX_MODE10 ) // P8.44 PRU0 UART TX Sep 29 01:16:24 >; Sep 29 01:16:24 }; Sep 29 01:18:01 But the "show-pins" script after fiddling and rebooting for quite a while now still states MUX_MODE0 and some vout... function for these pin (I assume vout... is some HDMI thing, right?) Sep 29 01:18:01 P8.31a 133 C8 0 slow vout1_d14 Sep 29 01:18:02 P8.33a 132 C6 0 slow vout1_d1 Sep 29 01:18:02 P8.43 121 F10 0 slow vout1_d2 Sep 29 01:18:03 P8.44 122 G11 0 slow vout1_d3 Sep 29 01:19:30 I tried to disable HDMI like on the BBBlack in /boot/uEnv.txt like so: Sep 29 01:19:30 disable_uboot_overlay_video=1 Sep 29 01:19:31 disable_uboot_overlay_emmc=1 Sep 29 01:20:07 But I dont know if this works the same on the AI and couldn't find anything anywhere else about it **** ENDING LOGGING AT Wed Sep 29 02:59:56 2021