brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Ping timeout: 240 seconds]
rob_w has joined #beagle
Shadyman has quit [Quit: Leaving.]
Archana has joined #beagle
set_ has quit [Ping timeout: 268 seconds]
otisolsen70 has joined #beagle
otisolsen70 has quit [Quit: Leaving]
ft has quit [Quit: leaving]
florian has joined #beagle
otisolsen70 has joined #beagle
Stat_headcrabed has joined #beagle
Stat_headcrabed has quit [Client Quit]
rob_w has quit [Quit: Leaving]
xet7 has joined #beagle
xet7 has quit [Remote host closed the connection]
buzzmarshall has joined #beagle
xet7 has joined #beagle
brook has joined #beagle
florian has quit [Quit: Ex-Chat]
ft has joined #beagle
outrageous has quit [Remote host closed the connection]
Parduz has joined #beagle
<Parduz>
Why the RTC module is /dev/rtc1 in my Debian 11 image instead of /dev/rtc0 as in the Debian 10 image?
<Parduz>
what causes a different enumeration?
<zmatt>
what hardware?
<Parduz>
BBB
<zmatt>
do you also have a /dev/rtc0 or just rtc1 ?
<Parduz>
both. The rtc0 is the one on the board
<zmatt>
oh by "RTC module" you mean an external RTC ?
<Parduz>
rtc1 is the i2c and timedatectl show that's the one that works
<Parduz>
yup
<zmatt>
what DT overlay are you using for the rtc?
<Parduz>
lib/firmware/BB-I2C2-PCF8523-00A0.dtbo
ikarso has quit [Quit: Connection closed for inactivity]
<zmatt>
what kernel version?
<Parduz>
i was mostly "copying" my settings from the debian 10 image
<Parduz>
let me look
<zmatt>
btw, you'll want to specify overlays just by filename (instead of the full path) in /boot/uEnv.txt since some overlays are now kernel version dependent
<Parduz>
Linux BeagleBone 5.10.162-ti-r58 #1bullseye SMP PREEMPT Sat Feb 25 19:31:31 UTC 2023 armv7l GNU/Linux
<zmatt>
if you just give a name instead of a path it'll first look in /boot/dtbs/$version/overlays/ and if it's not there fall back to /lib/firmware/
<Parduz>
ok, i'll change that. did'nt know it.
<zmatt>
not important for this overlay, but worth mentioning
<Parduz>
yup, thanks
<zmatt>
hmm the overlay *ought* to make the external rtc /dev/rtc0
<Parduz>
mh ... not booting anymore after changing the udev.txt ...
<zmatt>
uhh
<zmatt>
it really sucks that u-boot (and rcn's boot script in u-boot) is so ungraceful about configuration mistakes
<zmatt>
it's not too hard to recover from, but it's still annoying
<Parduz>
i think i've just removed /lib/firmware from the 3 overlays ... i'm checking the microSD with a debian PC (waiting it to boot)
<zmatt>
since you're booting from sd card, just to check.. has eMMC (or at least the bootloader on eMMC) been wiped?
<Parduz>
nope, in the emmc there's the debian 10 image
<zmatt>
bootloader on eMMC takes precedence over the one on SD card, so you're using the debian 10 bootloader to boot your debian 11 system
<zmatt>
the older bootloader doesn't understand what you just did to your /boot/uEnv.txt
<zmatt>
hence it fails to boot
<Parduz>
oh...ok
<zmatt>
if you hold the boot (S2) button during power-on then the bootloader on eMMC will be ignored (until next time the bbb is power-cycled)
<zmatt>
that should allow it to boot with your modified /boot/uEnv.txt
<Parduz>
restored as it was, anyway
<Parduz>
so now it boots.
<zmatt>
anyway, back to the rtc numbering
<Parduz>
yup
<zmatt>
can you check: ( cd /proc/device-tree/aliases && perl -0777 -pe 's/(.*?)\x00/$ARGV:$1\n/sg' rtc* )
<zmatt>
(that perl command dumps string(-array) DT properties in a nice way)
<Parduz>
rtc0:/fragment@4/__overlay__/pcf8523@68
<Parduz>
rtc1:/ocp/rtc@44e3e000
<Parduz>
i don't get it
<zmatt>
ohhh that's not right
<zmatt>
it should point to the resolved path, not a fragment path in the overlay
<zmatt>
wait do overlays even support string-fixups
<Parduz>
i don't know what your asking :-|
<zmatt>
they absolutely don't
<zmatt>
lol
<zmatt>
okay so the question isn't "why is this no longer working?" ... the real question is "how on earth did this ever work?"
<zmatt>
Parduz: so, here's the syntactically cleaned up version of the overlay source: https://pastebin.com/T5kCz22q
<zmatt>
(still the same overlay, just easier to read)
<Parduz>
so i need to build it?
<zmatt>
I've also marked the problem
<zmatt>
no I was just going to explain the issue
<zmatt>
but the old-style overlay syntax is like getting stabbed in the eye, so I first did a quick syntax cleanup
<Parduz>
lol ok
<zmatt>
so, it's trying to set rtc0 = &extrtc;
<zmatt>
note how that node reference is not inside <> like they normally are
<Parduz>
ok
<zmatt>
e.g. further down you see pinctrl-0 = <&bb_i2c2_pins>;
<Parduz>
so should i enclose it in <> ?
<zmatt>
typically DT nodes are references using their "phandles" which are unique 32-bit ids
<zmatt>
the dts syntax <&foo> means you're asking the compiler to find the node labeled "foo" and insert its phandle (encoded into 4 bytes)
<zmatt>
however, for historical reasons /aliases does not use phandles
<zmatt>
they use full node paths
<zmatt>
which is what the syntax &foo (as property value, outside <>) means
<Parduz>
...ok. i think i'm following you.
<zmatt>
so far so good, so what's the problem? overlays are the problem
<zmatt>
originally node references were resolved by the DT compiler and not part of the resulting .dtb
ikarso has joined #beagle
<zmatt>
overlays changed everything, since they're used to patch the DT at runtime (in u-boot) which requires references to be fixed up after that
<zmatt>
e.g. <&bb_i2c2_pins> needs to be the 32-bit phandle of the &bb_i2c2_pins node, but when compiling the overlay the compiler obviously has no idea what that phandle will be (even though it's defined in the overlay, its phandle will get renumbered when it gets patched into the main DT)
<zmatt>
so what the compiler does, it sticks a table of "fixups" into the overlay, which gives instructions (to u-boot) on how to fix all these references when applying the overlay to the main DT
<Parduz>
ok
<zmatt>
and here's the issue: these fixups only support phandle references
<zmatt>
the compiled overlay contains no fixup for the /aliases/rtc0 property
<zmatt>
so what we see in the final DT is the path this node had in the overlay, not the path it has in the actual DT
<zmatt>
which of course makes no sense to the kernel
<zmatt>
btw, if you're curious how to examine those fixups, you see them if you decompile the compiled overlay: dtc -I dtb -O dts src/arm/BB-I2C2-PCF8523-00A0.dtbo
<zmatt>
anyway, the fix would be to just specify the path manually, like they did for /aliases/rtc1
<zmatt>
the part that makes this annoying is that it depends on the path of &i2c2, which is kernel version dependent
<Parduz>
here i am, the boss wanted to know how it was going
<Parduz>
so, in my specific case, what would be the fix?
<zmatt>
you can determine the path of &i2c2 for the currently running kernel using: perl -0777 -pe 's/\x00/\n/g' /proc/device-tree/__symbols__/i2c2
<zmatt>
for example on kernel 4.19 I get: /ocp/i2c@4819c000
<zmatt>
the &extrtc node is defined in the overlay, it's the pcf8523@68 node in &i2c2
<zmatt>
so for me it would be rtc0 = "/ocp/i2c@4819c000/pcf8523@68";
<zmatt>
for you rtc0 = "/ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/pcf8523@68";
<Parduz>
ok, so that the whole string plus /pcf8523@68 has to be put in place of &extrtc
<Parduz>
oh, yes. thanks
<Parduz>
i just wonder (like you) how could it work before?
<zmatt>
also I just noticed... why the fuck is this overlay setting up the i2c2 bus and pins... that's the cape i2c bus and is already configured by default
<zmatt>
it has no business touching that config
<Parduz>
maybe should we look at how the rts was at the time of the Debian10 image? to get what happened?
<Parduz>
do you mean the &am33xx_pinmux section?
<zmatt>
I think I can guess why it worked: since the built-in rtc got renumbered to rtc1, maybe the old kernel simply used the first unused number for the external rtc
<zmatt>
while the new kernel either 1. notices rtc0 has an aliases (even if it doesn't understand the reference) and therefore shouldn't be used for any discovered rtcs that have no alias
<zmatt>
or 2. wants all dynamic rtcs (those which have no alias defined) to have numbers that are higher than the highest rtc with an alias
<Parduz>
do you think i can compile it on debian 10? 'cause being the debian11 a minimal image, i'd need to install gcc etc to compile the dts
<Parduz>
or the "cleaner" syntax does not work on older debian?
<zmatt>
not sure which dtc version is required for that
<Parduz>
ok, i'll install gcc and make then. I tired of "trying" :)
<zmatt>
but, none of the #includes aren't actually needed for this overlay (I forgot to remove them), which means you can also compile this with my overlay-utils if you remove the first bits
<Parduz>
meanwhile, i have a more trivial question:
<Parduz>
how to silent the boot after the kernel? it keeps showing the default username/password, the copyright and the "NO-WARRANTY" messages, the all the xorg output, until Openbox starts.
<Parduz>
then*
<zmatt>
also, debian 10 dtc understands the new syntax
<zmatt>
you mean on the serial console?
<Parduz>
yup
<zmatt>
the kernel's own verbosity is configured via kernel parameters (e.g. the "quiet" option)
<Parduz>
the kernel is absolutly silent. no penguin logo, nothing, just the blinking cursor
<zmatt>
the default username/password is probably in /etc/issue ? but that wouldn't show up unless you have a getty on the serial console
<Parduz>
after it, there's the message that once i've seen only after the first boot, but now they're always shown
<zmatt>
but you probably want to make /etc/issue and /etc/issue.net empty or very minimal
<zmatt>
the rest depends a bit on how you're starting X now
<Parduz>
OK. never looked there, i'll check them after. Now i'll try to compile the new rts.
<Parduz>
lot of error like this: Warning (reg_format): /fragment@2/__overlay__/pcf8523@68:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
<Parduz>
(using the make command, not your tools
<zmatt>
yeah dtc gives wrong errors
<zmatt>
overlay-utils passes some flags to suppress those
<zmatt>
the problem is that it's trying to perform sanity-checks that it can't actually perform because it doesn't have access to the base DT that this overlay will be applied to
<Parduz>
ok, then ill install your tools
<Parduz>
uh ... no apt package?
<zmatt>
overlay-utils is 1. a perl script that preprocesses device tree snippets into overlay dts (with the hideous original syntax) 2. a Makefile 3. headers with macros/definitions 4. examples
<zmatt>
part (1) has become mostly irrelevant with the new dtc, although what overlay-utils accepts is still nicer
Guest94 has joined #beagle
<Guest94>
What are the camera supported by Beagleplay
vagrantc has joined #beagle
Guest94 has quit [Ping timeout: 245 seconds]
<Parduz>
nope, compiled but still rtc1
<Parduz>
but now i have to go (7pm here)
<zmatt>
Parduz: then the kernel just broke rtc numbering via DT
<Parduz>
thanks zmatt, will look at it again monday
Parduz has quit [Quit: Leaving]
Guest94 has joined #beagle
Guest94 has quit [Client Quit]
jsolano has quit [Remote host closed the connection]
vvn has quit [Quit: WeeChat 3.8]
vvn has joined #beagle
otisolsen70 has quit [Quit: Leaving]
brook has quit [Ping timeout: 256 seconds]
ikarso has quit [Quit: Connection closed for inactivity]