<set_> I am little man on the todem pole in the udev dept. for now.
<set_> I need to learn more.
<zmatt> metaGross128: ugh, inconsistent indenting
<zmatt> also, you seem to be missing a closing }; at the end
<set_> THere are actually three SPI devices?
<set_> For the am335x and the BBBW?
<set_> News to me.
<zmatt> metaGross128: also why do you still have the hex values for spi0_pins instead of using the macros I provided?
<set_> for hexdump and serial decoding?
<zmatt> set_: hush
<set_> Fine. I just like to learn too.
<metaGross128> i'm testing
<metaGross128> :p
<zmatt> it's probably also more readable to keep the pinmux declarations near the corresponding device (it's fine to have multiple &am335x_pinmux { .. }; blocks)
<metaGross128> works like magic
<metaGross128> ls /dev/*sp*
<metaGross128> (/dev/spidev0.0)
<metaGross128> as result
<metaGross128> awesome :D
<metaGross128> Thanks
<zmatt> metaGross128: https://pastebin.com/9WB12L3L same for spi1
<zmatt> ugh, these ugly verbose mainline pinmux macros are such an eyesore
<metaGross128> any idea how to run autotest on SPI0 ?
<metaGross128> i installed spidev_test util already
<zmatt> and I despise the practice of naming pins after one of the functions
<metaGross128> spidev_test -D /dev/spidev0.0
<zmatt> what do you even mean by "autotest"
<zmatt> spi requires that you configure the bus exactly right for the slave device and perform transfers which the slave device understands
<set_> Use a device!
<set_> Dang it. Sorry.
<metaGross128> i don't have any external sensors for now
<zmatt> you mean a loopback test?
<metaGross128> yes
<metaGross128> that it
troth has quit [Ping timeout: 260 seconds]
<metaGross128> found it !
<zmatt> spidev_test doesn't really seem to have a loopback test... also, it's kind of annoying since it unconditionally overrides the configuration you declare in DT
<zmatt> if you want to use python, probably just use the spidev python library instead of Adafruit
troth has joined #beagle
<zmatt> there's an example for that at the bottom of this doc of mine: https://pastebin.com/nS6FELGH
<zmatt> don't forget to connect the two data pins (miso and mosi) with a wire if you want to do a loopback test ;)
<zmatt> on a random note, this is a really awesome-looking x-ray photo of a microSD card: https://twitter.com/mikelectricstuf/status/553659167580618753
<metaGross128> that's cool
<metaGross128> thanks
vagrantc has joined #beagle
mturquette has quit [Ping timeout: 240 seconds]
jkridner has quit [Ping timeout: 240 seconds]
mturquette has joined #beagle
jkridner has joined #beagle
drewfustini has quit [Ping timeout: 245 seconds]
paulbarker_ has quit [Ping timeout: 245 seconds]
drewfustini has joined #beagle
paulbarker_ has joined #beagle
metaGross128 has quit [Ping timeout: 256 seconds]
<set_> Yay! PCBs!
<set_> It is like candy but better. You can reuse them!
troth has quit [Ping timeout: 245 seconds]
troth has joined #beagle
nparafe has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nparafe has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
Shadyman has joined #beagle
Shadyman has quit [Ping timeout: 245 seconds]
starblue has quit [Ping timeout: 245 seconds]
starblue has joined #beagle
thinkfat_ has quit [Ping timeout: 250 seconds]
thinkfat_ has joined #beagle
Shadyman has joined #beagle
Shadyman has quit [Ping timeout: 245 seconds]
Shadyman has joined #beagle
troth has quit [Ping timeout: 240 seconds]
troth has joined #beagle
vagrantc has quit [Quit: leaving]
buzzmarshall has quit [Quit: Konversation terminated!]
Shadyman1 has joined #beagle
Shadyman has quit [Read error: Connection reset by peer]
jfsimon1981 has quit [Remote host closed the connection]
Shadyman1 has quit [Remote host closed the connection]
ikarso has joined #beagle
johanhenselmans has quit [Ping timeout: 268 seconds]
johanhenselmans has joined #beagle
vd has quit [Ping timeout: 256 seconds]
troth has quit [Ping timeout: 240 seconds]
troth has joined #beagle
florian has joined #beagle
vigneshr has quit [Quit: Connection closed for inactivity]
troth has quit [Ping timeout: 260 seconds]
set_ has quit [Remote host closed the connection]
troth has joined #beagle
troth has quit [Ping timeout: 256 seconds]
set_ has joined #beagle
troth has joined #beagle
metaGross128 has joined #beagle
jfsimon1981 has joined #beagle
jfsimon1981 has quit [Client Quit]
jfsimon1981 has joined #beagle
set_ has quit [Ping timeout: 268 seconds]
metaGross128 has quit [Ping timeout: 256 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
florian has quit [Quit: Ex-Chat]
<GenTooMan> don't eat the PCB's
<GenTooMan> or at least try too...
set_ has joined #beagle
set_ has quit [Ping timeout: 260 seconds]
set_ has joined #beagle
renrelkha has quit [Quit: bye]
renrelkha has joined #beagle
vd has joined #beagle
vd has quit [Ping timeout: 256 seconds]
ikarso has joined #beagle
metaGross128 has joined #beagle
<metaGross128> hello does any body know how to bind the ublox 6m driver in linux on serial UART1 ?
<set_> Can I try?
<set_> I used UART2 before and maybe UART4.
<set_> I never once tried UART3 for some reason.
<metaGross128> uart 3 is not usable
<set_> Oh.
<set_> Boo.
<set_> B/c of WiFi?
<metaGross128> yes i think
<metaGross128> is successed to activate uart 1
<metaGross128> njow i have /dev/ttyS1 device working
<set_> Okay. So, we need @zmatt b/c you want to use your own image right?
<set_> Oh!
<set_> He knows what you are up to.
<metaGross128> and i can see the gnss data in console
<set_> Nice.
<metaGross128> yes i use my own image
<metaGross128> now i want to bind the ubx 6 m driver
<set_> I would have to do too much catch up work. Maybe another person can help.
<set_> I can look though.
<set_> Yea boy!
<metaGross128> here is the source of the driver i want to use
<set_> ubx.c?
<set_> That is a bunch of files. I am new. Let me look around.
<metaGross128> yes
<metaGross128> https://pastebin.com/4Xdy5H5u here is my dts
<set_> So, are you trying to just use UART1 instead of their lengthy source?
<set_> spacey dudes.
vd has joined #beagle
<metaGross128> yes
<set_> Oh. Let me get this right here. So, I do not make errors.
<metaGross128> uart1 is functionning correctly now using serialdev driver
<set_> Right.
<metaGross128> now i want to bind ublox-neo-m6 driver to uart 1
<metaGross128> i don't know how
<set_> Oh. Me neither. Maybe typing up a random set of source can prevent you from giving up. For instance, that source is going back, back, back...
<set_> Anyway, you get the picture. It is like they have so many files. There is no way to know them all.
<set_> Do you have a year?
<set_> I mean it. For me to help, it will take every breathe you have currently and a year from now into the future.
<set_> So, I am out for now unless you can offer time in place of help. I know. Lengthy.
<set_> metaGross128: May I please share something with you?
<metaGross128> yes
<set_> You have a year or I can share?
<metaGross128> yes share
<set_> Oh. Okay. Here goes it. I checked the BeagleBoard-DeviceTrees github page and received a 505. That was a source of ideas for the am335x for me.
<set_> Now, I must know things outside of the .dtsi files. Do you have the .dtsi files still?
<metaGross128> everything is provided in the kernel sources
<set_> Yes!
<set_> Okay.
<metaGross128> i'm patching this dts
<set_> Oh. Okay.
<set_> I thought you were using the BBBW?
<metaGross128> yes
<set_> Use the am335x-boneblack-wireless.dts?
<set_> I am still missing things here. The online repo is gone but the kernel now has the mainlined .dtsi files?
<set_> I will look.
vd has quit [Ping timeout: 256 seconds]
<set_> Is it not available yet or something?
<set_> I am at a loss here b/c I cannot find the .dtsi files.
<set_> Here: https://elixir.bootlin.com/linux/v5.10.23/source/arch/arm/boot/dts/am335x-bone-common.dtsi it is in the /am335x-bonegreen-wireless.dts so far from what I see and hyperlinked.
<set_> This is neat.
<set_> But...where is the other .dtsi files? Maybe they are not ready yet?
<set_> Or...maybe they will never be ready?
<set_> Just for reference here, I am some average Joe if you cannot tell already.
<set_> This makes things extra interesting if the am335x is mainlined w/out the BBBW .dtsi files.
<set_> Whoosh!
<set_> I got you now.
<set_> The bone-common does not have uart1 listed in its current state.
<set_> So, we need to make it. Off to the TRM.
<set_> I think they want people to put in work. This is neat.
<set_> So, they have the BBBW .dtsi.
<set_> Why are you using the bonegreen-wireless .dtsi?
<set_> They are different boards w/ different features.
<set_> UART1?
mattb00ne has quit [Ping timeout: 256 seconds]
<metaGross128> yes i already made it available
<metaGross128> it is bonegreen-wireless .dts and not an inclueded DTSI
<set_> I need to stop steering you incorrectly. BBBW and BBGW are two separate boards. At least...this is what I thought.
<set_> They have the same am335x and form factor.
<set_> Maybe it is me that does not understand. Hmm.
<set_> I thought .dtsi files were the main files needed for to conclude on the .dts files turned into .dtb files one would use.
<set_> for one to
<metaGross128> yes the same SOC (processor) but not the same headers mapping
<metaGross128> nor the devices on the board
<metaGross128> zmatt
<set_> I am still at a loss here b/c you are using a BeagleBone Black Wireless and using the BoneGreen-Wireless file for use.
<metaGross128> any solutions ?
<set_> Yep. I think he can help more.
<metaGross128> yes my board is BBBW
<set_> metaGross128: Use the BBBW .dtsi files.
<set_> Let me get the link.
<set_> @zmatt has answers but I have an elongated way of describing the necessary steps to produce w/ trial and error involved. That is all.
vd has joined #beagle
vd has quit [Ping timeout: 256 seconds]
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
<zmatt> metaGross128: hmm, what's the question?
<set_> Excuse me but this is exhilerating. You guys?
<set_> I cannot wait!
* set_ sits in idle mode.
ikarso has quit [Quit: Connection closed for inactivity]
<zmatt> metaGross128: when you first came into the channel you said "beaglebone black", then later you showed your work which said it was a beaglebone black wireless, and now you're saying you're using am335x-bonegreen-wireless.dts ? what device do you _actually_ have? :P
<zmatt> btw, don't patch a standard .dts, just make a new .dts and #include the .dts of the board you're using (and add your custom stuff below that)
<zmatt> that's much better for maintainability
xet7 has quit [Quit: Leaving]
<metaGross128> hi zmatt
xet7 has joined #beagle
<metaGross128> i shared the issue here
<metaGross128> if you can take a look
<zmatt> again a blob of hex values? where are you even getting these?
<zmatt> you can easily find source code examples for the pinmux in the linux kernel tree: grep -I -A6 'uart1_pins:' arch/arm/boot/dts/am33*
<metaGross128> okay
<metaGross128> you think the problem comes from the declaration of the uart1_pins ?
<zmatt> no idea, I'd need to manually look up what these values mean and I really can't be bothered
<zmatt> also vcc-supply = <0>; is nonsense
<zmatt> and according to the gnss binding documentation ( https://www.kernel.org/doc/Documentation/devicetree/bindings/gnss/gnss.txt ) the node needs to be named "gnss", not "gps@0"
vd has joined #beagle
<metaGross128> okay !
<metaGross128> testing
<zmatt> and you didn't answer my question
<zmatt> what device do you actually have?
<zmatt> you're saying "beaglebone black" in several places, have showed a dts based on the black *wireless*, and now you're saying you're using *green* wireless
<zmatt> these are all different devices, please try to be accurate in saying what it is you're using
<metaGross128> i have a BBB- wireless
<zmatt> then why are you saying you're using am335x-bonegreen-wireless.dts ?
<metaGross128> no it is not green
<metaGross128> typo
<set_> I am on a spaceship. Sorry. I am driving.
<set_> Not fair!
<metaGross128> i tested by renaming the node to gnss
<metaGross128> doesn't work
<zmatt> and fixed the vcc-supply? is the driver enabled in your kernel config? have you checked kernel log for error messaged?
otisolsen70 has quit [Quit: Leaving]
<metaGross128> yes i enabled it
<metaGross128> [    3.522605] gnss: GNSS driver registered with major 247
<metaGross128> also vcc-supply = <0>; is nonsense --> change to what ? i provide supply from 3.3V of the BBB
<zmatt> then vcc-supply should reference the node that is representing that supply
<zmatt> (or in practice, since it's a fixed non-switchable supply, referencing any fixed 3.3v supply will work)
<metaGross128> do you have the name of the node
<metaGross128> ?
<zmatt> <&vmmcsd_fixed> will work
<zmatt> so, have you checked kernel log for error messages?
<metaGross128> about gnss there is only this => [    3.522605] gnss: GNSS driver registered with major 247
<zmatt> is that driver compiled as module (CONFIG_GNSS=m) or built-in (CONFIG_GNSS=y) ?
<metaGross128> y
<metaGross128> built in
<metaGross128> *
<zmatt> then you'll get that message unconditionally, so it means literally nothing
<zmatt> it's just saying the driver loaded, but the driver is compiled into the kernel so it will always load
<metaGross128> i make m
<metaGross128> add try with modprobe ?
<zmatt> unless your system is broken you don't need to modprobe modules for drivers
<zmatt> they get loaded automatically
<zmatt> what does your device tree snippet for this look like now?
<metaGross128> tested this
<metaGross128> doesn't work
<zmatt> also, do you have CONFIG_GNSS_UBX_SERIAL enabled? (=m or =y)
<metaGross128> both on y
<metaGross128> for info
<metaGross128> when i do:  find / -name *gnss*
<metaGross128> i get
<metaGross128> (/sys/bus/serial/drivers/gnss-ubx) and (/sys/class/gnss)
<zmatt> also, unrelated, that master@0 block at lines 166-170 in your pastebin is nonsense, remove that
<metaGross128> and (sys/firmware/devicetree/base/ocp/interconnect@48000000/segment@0/target-module@22000/serial@0/gnss)
<set_> chrdev -> dev
<set_> Nevermind. Sorry. You guys are doing it right now!
* set_ back to my corner.
<zmatt> metaGross128: if your device is detected it will show up as a symlink in /sys/bus/serial/drivers/gnss-ubx/ as well as in /sys/class/gnss/
<metaGross128> no devices in /dev ?
<zmatt> no idea, I'm unfamiliar with gnss
<zmatt> I'd expect it has some device in /dev yes
<metaGross128> i read a little bit the driver
<metaGross128> normally there is something like /dev/gnss0
<metaGross128> in devfs
<metaGross128> see core.c in /drivers/gnss/core.c
<zmatt> that aside, does anything show up in /sys/class/gnss/ ?
<metaGross128> there is bind unbind and event
<zmatt> or /sys/bus/serial/drivers/gnss-ubx/ ?
<metaGross128> files
<zmatt> yeah ignore those
<metaGross128> the other is empty
<zmatt> devices will be directories or symlinks to directories
<metaGross128> i will test the driver as LKM
<zmatt> did you check kernel log for errors, or any messages related to gnss or uart1 ?
<zmatt> (other than that one message saying that gnss loaded)
<zmatt> lkm?
<metaGross128> module
<metaGross128> try to load from user space
<zmatt> oh as kernel module... I mean, there's no reason to do that, if it works as module it will definitely also work when compiled-in
<metaGross128> to see if it fails
<zmatt> if there's an actual failure then you can find that in your kernel log
<metaGross128> i dunno maybe there is a problem due to initialisation
<set_> For reference, I am reading this info.
<zmatt> metaGross128: can't gpsd use this thing directly from userspace without this gnss kernel driver?
<metaGross128> you have to pass serial port device to gpsd
<zmatt> yes, that would be /dev/ttyS1
<metaGross128> i know
<metaGross128> i just wanted to test the driver
<zmatt> sure, it sounds like it ought to work
<metaGross128> or else i will write my own
<zmatt> except evidently it's... not
<metaGross128> :p
<zmatt> AH
<zmatt> found the problem
<zmatt> your compatible-string is wrong
<metaGross128> okay
<zmatt> you wrote "blox,neo-6m"
<metaGross128> okay
<zmatt> but it should be "u-blox,neo-6m"
<metaGross128> oh !
<metaGross128> right
<metaGross128> fuuuuuuuuuuuuuuuuuuuuuu
<metaGross128> thanks
<set_> Ha!
<zmatt> devicetree is rather intolerant of typos ;)
<set_> The ole u-blox in the corner tree!
<zmatt> it would be nice if there were some tool to perform thorough sanity-checking on the dt... e.g. a software tool could easily have detected that you had a node with a compatible-string that didn't match any driver
<metaGross128> dtc compiler is tolerent to this type of errors ?
<metaGross128> dts sementic compiler maybe ?
<metaGross128> parser *
<set_> When you all go on break, let me know.
<set_> I want to read something else.
<zmatt> dtc will catch syntactic errors
<zmatt> but to dtc, the value of the compatible-property is a just a string
<zmatt> it doesn't know anything about its semantics, and it certainly has no way of knowing what all valid compatible-strings are, which will depend on your kernel version and config
<zmatt> actually, does udev not log something if it can't find a driver to load?
<metaGross128> now i see /dev/gnss0
<zmatt> since if the kernel can't find a driver it will poke userspace to load the appropriate kernel module
<zmatt> which would typically be udev
<zmatt> doing that
<metaGross128> yes
<zmatt> of course you won't find that in kernel log but in syslog (or journal when using systemd)
<zmatt> at least I'd *hope* udev logs a warning if it's asked to load a driver for a device but it can't find any matching module
<metaGross128> okay i will see yhis
<metaGross128> i don't know enough about udev xD
<set_> break time?
<set_> I just made a transpose and a random.randn !
<set_> Learnin' slowly over CHE!
<set_> Sorry. HERE!
<set_> Hey. Quickster here, does it seem natural to get a complete assembly for four boards and just pay $26.xx extra for 100 boards?
<set_> Literally, something is wrong w/ these people. Outie!
<set_> Sorry. I am leaving now.
<set_> bg
buzzmarshall has joined #beagle
buzzm has joined #beagle
buzzmarshall has quit [Ping timeout: 256 seconds]