<set_>
I finally figured out the vortex of what is the Isosceles Trapezoid of mounting holes on the BBBlue!
<set_>
It took a deep breath and some software but there. Done.
<set_>
Thank you.
<set_>
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.
<set_>
3.18 mm was the offset.
charlie5 has quit [Ping timeout: 245 seconds]
charlie5 has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
the_person48 has quit [Quit: Client closed]
giort has joined #beagle
otisolsen70 has joined #beagle
rob_w has joined #beagle
vd has quit [Ping timeout: 256 seconds]
florian has joined #beagle
Daulity has joined #beagle
<Daulity>
hey
Shadyman has quit [Remote host closed the connection]
<zmatt>
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
<Daulity>
There is no option in the menuconfig that allows me to select UART0
<Daulity>
only UART1 and up
<Daulity>
ah yea it's misslabled :)
<Daulity>
i have tried just earlyprintk and it hangs atleast no activity after u-boot says starting kernel
<Daulity>
without earlyprintk it boots
<Daulity>
kernel version: 4.19.94
<zmatt>
there's also earlycon instead of earlyprintk, which appears to work totally differently
<Daulity>
I may give that a try
starblue1 has joined #beagle
<zmatt>
it looks like that requires specifying something like console=uart8250,mmio32,0x44e09000,115200n8
<zmatt>
or earlycon= ... the difference isn't quite clear to me
<Daulity>
got something working
<Daulity>
changed the bootparam to just earlyprintk and the console argument used ttyO0 and after changing that to ttyS0 i got output right away
<zmatt>
nice
<zmatt>
looks like earlycon actually doesn't require any parameters, it is able to get the console port from DT (/chosen/stdout-path)
<zmatt>
hmm, kernel docs say that's ARM64 rather than ARM, but the docs might be wrong of course
<zmatt>
yeah it totally looks like it should work fine on any platform that uses DT
<zmatt>
or... never mind
<zmatt>
no it does
<zmatt>
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)
<zmatt>
(this assumes you have CONFIG_SERIAL_EARLYCON enabled)
<zmatt>
oh never mind that gets automatically enabled
<zmatt>
Daulity: in case it's of interest, here's the outline of how earlyprintk and earlycon work (on am335x): https://pastebin.com/ESjHFDqa
<zmatt>
it's interesting how they have absolutely nothing whatsoever in common
<zmatt>
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
<Daulity>
zmatt: i can verify if it was the case that changing it worked
<Daulity>
i tried a few things hoping it would work :)
<zmatt>
earlycon looks to me like it would be more robust than earlyprintk
<zmatt>
like, earlyprintk hardcodes a kernel virtual address, that makes me a bit uncomfortable
Guest15 has quit [Quit: Client closed]
<Daulity>
both ttyO0 and ttyS0 work now so I did change something and make it work :)
<Daulity>
something else*
<Daulity>
zmatt: thank you for all your help :)
buzzmarshall has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
buzzmarshall has quit [Client Quit]
GenTooMan has quit [Ping timeout: 250 seconds]
buzzmarshall has joined #beagle
GenTooMan has joined #beagle
starblue1 has quit [Ping timeout: 245 seconds]
otisolsen70_ has joined #beagle
otisolsen70 has quit [Ping timeout: 252 seconds]
otisolsen70_ has quit [Ping timeout: 264 seconds]
vagrantc has joined #beagle
rob_w has quit [Quit: Leaving]
starblue1 has joined #beagle
vd has joined #beagle
the_person48 has joined #beagle
<the_person48>
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
<zmatt>
and P8.03-06 + P8.20-25 are the eMMC pins which have strong external pullups
<zmatt>
P8.31-46 are the boot config pins which have weak external pulls (up or down, varies per pin)
<the_person48>
gotcha
<the_person48>
ok I'll run that by my coworker
<the_person48>
I told him the bit about the strong ones before and he agreed
<zmatt>
creating a conflict between external pullup and internal pulldown or vice versa should be avoided
<the_person48>
yeah that makes sense
<zmatt>
since it may cause the voltage to float at an intermediate level (neither logic-high nor logic-low but some indeterminate level in between)
<the_person48>
ok, cool
<the_person48>
that actually does make sense to me
<the_person48>
will adjust
<zmatt>
and that paste is just timedatectl, not timedatectl timesync-status
<the_person48>
yeah it says "unknown option: timesync-status"
<the_person48>
when I try the full command
<zmatt>
oh
<zmatt>
ehh, what about timedatectl show-timesync
<the_person48>
also unknown operation
<zmatt>
*sigh*
<the_person48>
sorry
waldo323 has quit [Remote host closed the connection]
<the_person48>
I'm trying to find an old version of the command
waldo323 has joined #beagle
<zmatt>
it's part of systemd
<zmatt>
your systemd is probably just too ancient
<zmatt>
how about: busctl get-property org.freedesktop.timesync1 /org/freedesktop/timesync1 org.freedesktop.timesync1.Manager ServerName
<the_person48>
The name org.freedesktop.timesync1 was not provided by any .service files
<zmatt>
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
<zmatt>
and then sudo systemctl restart systemd-timesyncd
<the_person48>
ok
<the_person48>
will do
<the_person48>
and I know I asked this yesterday, but what happens if the clock is off? what problems exactly does it cause with make?
<the_person48>
cause I'm not sure we need it for anything else
<zmatt>
make uses file modification dates to figure out which files to rebuild
<the_person48>
so might I be able to work around it by just deleting the old output overlay .dtbo file?
<the_person48>
then recompiling the .dtsi with make?
<zmatt>
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
<zmatt>
and it'll keep complaining
<the_person48>
ah I see
<the_person48>
so unnecessary rebuilding basically?
<zmatt>
yes
<the_person48>
ok, I will still try to figure out the NTP thing
<the_person48>
but if it doesn't work I'll probably just let it go then
<zmatt>
and of course it's also annoying when transferring files to/from your beaglebone, and it makes tools like rsync potentially hazardous
<the_person48>
doesn't sound too bad
<zmatt>
and in general you won't be able to determine which things have changed when
<zmatt>
which sounds obnoxious enough already to me
<the_person48>
yeah true
lucascastro has joined #beagle
giort has joined #beagle
mag has quit [Remote host closed the connection]
mag has joined #beagle
waldo323_ has joined #beagle
waldo323 has quit [Ping timeout: 246 seconds]
Guest15 has joined #beagle
<Guest15>
So the console image has the same idle current as the TIDL image. In both cases they consume 4W at idle.
<zmatt>
really? curious
<zmatt>
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
vagrantc has quit [Quit: leaving]
<Guest15>
Are any of these modules (DSP, EVE) configurable via sysfs?
vagrantc has joined #beagle
<zmatt>
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
<zmatt>
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
<zmatt>
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
<Guest15>
-bash: omapconf: command not found know what package it's in?
Guest30 has joined #beagle
<zmatt>
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
<zmatt>
pretty sure the package is called omapconf too
the_person48 has quit [Quit: Client closed]
<Guest15>
E: Unable to locate package omapconf
Guest30 has quit [Client Quit]
<zmatt>
huh
<Guest15>
dpkg -S doesn't tell me anything either
<zmatt>
did you do "apt-get update" first to fetch the package lists?
<Guest15>
I've already installed a whackload of packages so yeah. But I'll run it again right now
<zmatt>
-S searches for files in installed packages so that's not really useful here
<zmatt>
hmm
<zmatt>
ah, package tiomapconf
<Guest15>
Thanks, that's working. How did you find out?
<zmatt>
dpkg -S, since I had it installed :P
<Guest15>
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.
<zmatt>
600MHz or (600MHz) ?
<Guest15>
with the parentheses, what does that mean?
<zmatt>
see note below the table
Konsgn has joined #beagle
<Guest15>
Ah those are all part of the same module? So if they're off why is the device still drawing 4W?
<zmatt>
not sure what you mean, like I said earlier "it should show their frequency in parentheses with the (1) note indicating module is disabled"
<zmatt>
and I don't know what's drawing 4W on the BBAI
<zmatt>
my bbx15 (which uses the same SoC) barely gets warm to the touch, and it doesn't have a heatsink
akaWolf has quit [Ping timeout: 252 seconds]
charlie5 has quit [Ping timeout: 252 seconds]
<Guest15>
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.
<zmatt>
like, the internal temperatures reported by omapconf ?
<Guest15>
Yep. Is there a way to turn off the power into the EVE modules?
<Guest15>
via the regulators?
<zmatt>
50C is not hot
<zmatt>
max junction temperature is 90C
<zmatt>
like, 50C or 55C would not be reason to install a fan
<Guest15>
pushing 60C now. And 50C is not.
<Guest15>
50C is hot rather
<zmatt>
50C external temperature is hot to touch yes
<zmatt>
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
<zmatt>
I don't think I have a way to measure its power consumption
<Guest15>
64C now. idle.
<zmatt>
yeah I know the bbai runs hot
<zmatt>
I'm just not sure why
<zmatt>
apparently the bbx15 is able to cool itself more through the larger pcb
<Guest15>
and none of the regulators are disabled?
<zmatt>
pretty sure disabling any of the supplies is forbidden
florian has quit [Quit: Ex-Chat]
<zmatt>
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)
charlie5 has joined #beagle
<zmatt>
(VDD_CORE has only a single operating point)
<Guest15>
are the dtbs for x15 and ai the same?
<zmatt>
no since they're completely different boards
akaWolf has joined #beagle
<Guest15>
also uses am5728 whereas the ai uses am5729
<zmatt>
they both use the am5729
<zmatt>
iirc the am5729 didn't publicly exist at the time the bbx15 was released which is why it was spec'd as am5728