**** BEGIN LOGGING AT Sat Nov 27 02:59:56 2021
Nov 27 16:20:34 <GenTooMan> don't eat the PCB's
Nov 27 16:20:47 <GenTooMan> or at least try too...
Nov 27 20:03:44 <metaGross128> hello does any body know how to bind the ublox 6m driver in linux on serial UART1 ?
Nov 27 20:26:26 <set_> Can I try?
Nov 27 20:28:03 <set_> I used UART2 before and maybe UART4.
Nov 27 20:28:17 <set_> I never once tried UART3 for some reason.
Nov 27 20:28:26 <metaGross128> uart 3 is not usable
Nov 27 20:28:31 <set_> Oh.
Nov 27 20:28:32 <set_> Boo.
Nov 27 20:28:41 <set_> B/c of WiFi?
Nov 27 20:28:52 <metaGross128> yes i think
Nov 27 20:29:18 <metaGross128> is successed to activate uart 1
Nov 27 20:29:33 <metaGross128> njow i have /dev/ttyS1 device working
Nov 27 20:29:42 <set_> Okay. So, we need @zmatt b/c you want to use your own image right?
Nov 27 20:29:43 <set_> Oh!
Nov 27 20:30:00 <set_> He knows what you are up to.
Nov 27 20:30:00 <metaGross128> and i can see the gnss data in console
Nov 27 20:30:05 <set_> Nice.
Nov 27 20:30:08 <metaGross128> yes i use my own image
Nov 27 20:30:26 <metaGross128> now i want to bind the ubx 6 m driver
Nov 27 20:30:34 <set_> I would have to do too much catch up work. Maybe another person can help.
Nov 27 20:30:39 <set_> I can look though.
Nov 27 20:30:49 <metaGross128> https://elixir.bootlin.com/linux/v5.10.23/source/drivers/gnss
Nov 27 20:30:54 <set_> Yea boy!
Nov 27 20:31:01 <metaGross128> here is the source of the driver i want to use
Nov 27 20:31:16 <set_> ubx.c?
Nov 27 20:31:46 <set_> That is a bunch of files. I am new. Let me look around.
Nov 27 20:32:59 <metaGross128> yes
Nov 27 20:33:16 <metaGross128> https://pastebin.com/4Xdy5H5u here is my dts
Nov 27 20:35:45 <set_> So, are you trying to just use UART1 instead of their lengthy source?
Nov 27 20:40:57 <set_> spacey dudes.
Nov 27 20:42:00 <metaGross128> yes
Nov 27 20:42:23 <set_> Oh. Let me get this right here. So, I do not make errors.
Nov 27 20:42:28 <metaGross128> uart1 is functionning correctly now using serialdev driver
Nov 27 20:42:35 <set_> Right.
Nov 27 20:42:54 <metaGross128> now i want to bind ublox-neo-m6 driver to uart 1
Nov 27 20:43:07 <metaGross128> i don't know how
Nov 27 20:44:02 <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...
Nov 27 20:44:20 <set_> Anyway, you get the picture. It is like they have so many files. There is no way to know them all.
Nov 27 20:44:29 <set_> Do you have a year?
Nov 27 20:45:36 <set_> I mean it. For me to help, it will take every breathe you have currently and a year from now into the future.
Nov 27 20:46:35 <set_> So, I am out for now unless you can offer time in place of help. I know. Lengthy.
Nov 27 20:47:11 <set_> metaGross128: May I please share something with you?
Nov 27 20:47:17 <metaGross128> yes
Nov 27 20:47:33 <set_> You have a year or I can share?
Nov 27 20:48:01 <metaGross128> yes share
Nov 27 20:48:50 <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.
Nov 27 20:49:23 <set_> Now, I must know things outside of the .dtsi files. Do you have the .dtsi files still?
Nov 27 20:49:55 <metaGross128> everything is provided in the kernel sources
Nov 27 20:50:05 <set_> Yes!
Nov 27 20:50:07 <set_> Okay.
Nov 27 20:50:34 <metaGross128> https://elixir.bootlin.com/linux/v5.10.23/source/arch/arm/boot/dts/am335x-bonegreen-wireless.dts
Nov 27 20:50:44 <metaGross128> i'm patching this dts
Nov 27 20:50:49 <set_> Oh. Okay.
Nov 27 20:50:58 <set_> I thought you were using the BBBW?
Nov 27 20:51:15 <metaGross128> yes
Nov 27 20:51:42 <set_> Use the am335x-boneblack-wireless.dts?
Nov 27 20:52:25 <set_> I am still missing things here. The online repo is gone but the kernel now has the mainlined .dtsi files?
Nov 27 20:52:40 <set_> I will look.
Nov 27 20:58:47 <set_> Is it not available yet or something?
Nov 27 20:59:07 <set_> I am at a loss here b/c I cannot find the .dtsi files.
Nov 27 21:00:16 <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.
Nov 27 21:00:18 <set_> This is neat.
Nov 27 21:00:48 <set_> But...where is the other .dtsi files? Maybe they are not ready yet?
Nov 27 21:01:11 <set_> Or...maybe they will never be ready?
Nov 27 21:01:31 <set_> Just for reference here, I am some average Joe if you cannot tell already.
Nov 27 21:02:16 <set_> This makes things extra interesting if the am335x is mainlined w/out the BBBW .dtsi files.
Nov 27 21:02:18 <set_> Whoosh!
Nov 27 21:03:52 <set_> I got you now.
Nov 27 21:04:15 <set_> The bone-common does not have uart1 listed in its current state.
Nov 27 21:05:02 <set_> So, we need to make it. Off to the TRM.
Nov 27 21:07:16 <set_> I think they want people to put in work. This is neat.
Nov 27 21:07:38 <set_> So, they have the BBBW .dtsi.
Nov 27 21:07:52 <set_> Why are you using the bonegreen-wireless .dtsi?
Nov 27 21:08:09 <set_> They are different boards w/ different features.
Nov 27 21:08:37 <set_> UART1?
Nov 27 21:13:05 <metaGross128> yes i already made it available
Nov 27 21:14:14 <metaGross128> it is bonegreen-wireless .dts and not an inclueded DTSI
Nov 27 21:16:17 <set_> I need to stop steering you incorrectly. BBBW and BBGW are two separate boards. At least...this is what I thought.
Nov 27 21:16:48 <set_> They have the same am335x and form factor.
Nov 27 21:17:16 <set_> Maybe it is me that does not understand. Hmm.
Nov 27 21:18:45 <set_> I thought .dtsi files were the main files needed for to conclude on the .dts files turned into .dtb files one would use.
Nov 27 21:18:56 <set_> for one to
Nov 27 21:26:13 <metaGross128> yes the same SOC (processor) but not the same headers mapping
Nov 27 21:26:21 <metaGross128> nor the devices on the board
Nov 27 21:26:52 <metaGross128> zmatt
Nov 27 21:27:20 <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.
Nov 27 21:27:23 <metaGross128> any solutions ?
Nov 27 21:27:28 <set_> Yep. I think he can help more.
Nov 27 21:27:52 <metaGross128> yes my board is BBBW
Nov 27 21:28:15 <set_> metaGross128: Use the BBBW .dtsi files.
Nov 27 21:28:30 <set_> Let me get the link.
Nov 27 21:28:58 <set_> This one handles the BBBW: https://elixir.bootlin.com/linux/v5.10.23/source/arch/arm/boot/dts/am335x-boneblack-wireless.dts
Nov 27 21:30:25 <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.
Nov 27 22:17:11 <zmatt> metaGross128: hmm, what's the question?
Nov 27 22:19:56 <set_> Excuse me but this is exhilerating. You guys?
Nov 27 22:20:08 <set_> I cannot wait!
Nov 27 22:20:15 * set_ sits in idle mode.
Nov 27 22:21:27 <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
Nov 27 22:22:21 <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)
Nov 27 22:22:54 <zmatt> that's much better for maintainability
Nov 27 22:26:40 <metaGross128> hi zmatt
Nov 27 22:27:07 <metaGross128> i shared the issue here
Nov 27 22:27:09 <metaGross128> https://unix.stackexchange.com/questions/679338/failed-when-binding-the-blox-neo-6m-driver-to-uart-1-on-beagleboneblack
Nov 27 22:27:15 <metaGross128> if you can take a look
Nov 27 22:30:17 <zmatt> again a blob of hex values? where are you even getting these?
Nov 27 22:31:21 <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*
Nov 27 22:32:35 <metaGross128> okay
Nov 27 22:33:06 <metaGross128> you think the problem comes from the declaration of the uart1_pins ?
Nov 27 22:33:42 <zmatt> no idea, I'd need to manually look up what these values mean and I really can't be bothered
Nov 27 22:33:48 <zmatt> also vcc-supply = <0>; is nonsense
Nov 27 22:34:55 <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"
Nov 27 22:37:30 <metaGross128> okay !
Nov 27 22:37:35 <metaGross128> testing
Nov 27 22:37:42 <zmatt> and you didn't answer my question
Nov 27 22:37:48 <zmatt> what device do you actually have?
Nov 27 22:39:07 <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
Nov 27 22:39:33 <zmatt> these are all different devices, please try to be accurate in saying what it is you're using
Nov 27 22:40:56 <metaGross128> i have a BBB- wireless
Nov 27 22:41:14 <zmatt> then why are you saying you're using am335x-bonegreen-wireless.dts ?
Nov 27 22:41:19 <metaGross128> no it is not green
Nov 27 22:41:36 <metaGross128> typo
Nov 27 22:42:24 <set_> I am on a spaceship. Sorry. I am driving.
Nov 27 22:42:40 <set_> Not fair!
Nov 27 22:43:18 <metaGross128> i tested by renaming the node to gnss
Nov 27 22:43:24 <metaGross128> doesn't work
Nov 27 22:44:16 <zmatt> and fixed the vcc-supply?  is the driver enabled in your kernel config?  have you checked kernel log for error messaged?
Nov 27 22:44:33 <metaGross128> yes i enabled it
Nov 27 22:44:57 <metaGross128> [    3.522605] gnss: GNSS driver registered with major 247
Nov 27 22:46:14 <metaGross128> also vcc-supply = <0>; is nonsense --> change to what ? i provide supply from 3.3V of the BBB
Nov 27 22:46:47 <zmatt> then vcc-supply should reference the node that is representing that supply
Nov 27 22:47:24 <zmatt> (or in practice, since it's a fixed non-switchable supply, referencing any fixed 3.3v supply will work)
Nov 27 22:47:34 <metaGross128> do you have the name of the node
Nov 27 22:47:38 <metaGross128> ?
Nov 27 22:48:45 <zmatt> <&vmmcsd_fixed> will work
Nov 27 22:49:59 <zmatt> so, have you checked kernel log for error messages?
Nov 27 22:51:16 <metaGross128> about gnss there is only this => [    3.522605] gnss: GNSS driver registered with major 247
Nov 27 22:51:42 <zmatt> is that driver compiled as module (CONFIG_GNSS=m) or built-in (CONFIG_GNSS=y) ?
Nov 27 22:51:50 <metaGross128> y
Nov 27 22:51:52 <metaGross128> built in
Nov 27 22:51:57 <metaGross128> *
Nov 27 22:52:03 <zmatt> then you'll get that message unconditionally, so it means literally nothing
Nov 27 22:52:26 <zmatt> it's just saying the driver loaded, but the driver is compiled into the kernel so it will always load
Nov 27 22:52:58 <metaGross128> i make m
Nov 27 22:53:06 <metaGross128> add try with modprobe ?
Nov 27 22:53:27 <zmatt> unless your system is broken you don't need to modprobe modules for drivers
Nov 27 22:53:31 <zmatt> they get loaded automatically
Nov 27 22:53:59 <zmatt> what does your device tree snippet for this look like now?
Nov 27 22:54:41 <metaGross128> https://pastebin.com/pRDx7WTx
Nov 27 22:54:45 <metaGross128> tested this
Nov 27 22:54:49 <metaGross128> doesn't work
Nov 27 22:55:00 <zmatt> also, do you have CONFIG_GNSS_UBX_SERIAL enabled? (=m or =y)
Nov 27 22:55:09 <metaGross128> both on y
Nov 27 22:55:21 <metaGross128> for info
Nov 27 22:55:34 <metaGross128> when i do:  find / -name *gnss*
Nov 27 22:55:40 <metaGross128> i get
Nov 27 22:56:09 <metaGross128> (/sys/bus/serial/drivers/gnss-ubx) and (/sys/class/gnss)
Nov 27 22:56:09 <zmatt> also, unrelated, that master@0 block at lines 166-170 in your pastebin is nonsense, remove that
Nov 27 22:56:29 <metaGross128> and (sys/firmware/devicetree/base/ocp/interconnect@48000000/segment@0/target-module@22000/serial@0/gnss)
Nov 27 22:57:07 <set_> chrdev -> dev
Nov 27 22:57:35 <set_> Nevermind. Sorry. You guys are doing it right now!
Nov 27 22:57:44 * set_ back to my corner.
Nov 27 22:58:05 <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/
Nov 27 22:58:32 <metaGross128> no devices in /dev ?
Nov 27 22:58:51 <zmatt> no idea, I'm unfamiliar with gnss
Nov 27 22:59:06 <zmatt> I'd expect it has some device in /dev yes
Nov 27 22:59:14 <metaGross128> i read a little bit the driver
Nov 27 22:59:35 <metaGross128> normally there is something like /dev/gnss0
Nov 27 22:59:43 <metaGross128> in devfs
Nov 27 22:59:59 <metaGross128> see core.c in /drivers/gnss/core.c
Nov 27 23:01:51 <zmatt> that aside, does anything show up in /sys/class/gnss/ ?
Nov 27 23:02:14 <metaGross128> there is bind unbind and event
Nov 27 23:02:14 <zmatt> or /sys/bus/serial/drivers/gnss-ubx/ ?
Nov 27 23:02:15 <metaGross128> files
Nov 27 23:02:20 <zmatt> yeah ignore those
Nov 27 23:02:28 <metaGross128> the other is empty
Nov 27 23:02:32 <zmatt> devices will be directories or symlinks to directories
Nov 27 23:03:14 <metaGross128> i will test the driver as LKM
Nov 27 23:03:16 <zmatt> did you check kernel log for errors, or any messages related to gnss or uart1 ?
Nov 27 23:03:29 <zmatt> (other than that one message saying that gnss loaded)
Nov 27 23:03:49 <zmatt> lkm?
Nov 27 23:04:01 <metaGross128> module
Nov 27 23:04:13 <metaGross128> try to load from user space
Nov 27 23:04:18 <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
Nov 27 23:04:19 <metaGross128> to see if it fails
Nov 27 23:04:47 <zmatt> if there's an actual failure then you can find that in your kernel log
Nov 27 23:04:48 <metaGross128> i dunno maybe there is a problem due to initialisation
Nov 27 23:05:08 <set_> For reference, I am reading this info.
Nov 27 23:06:54 <zmatt> metaGross128: can't gpsd use this thing directly from userspace without this gnss kernel driver?
Nov 27 23:07:34 <metaGross128> you have to pass serial port device to gpsd
Nov 27 23:07:47 <zmatt> yes, that would be /dev/ttyS1
Nov 27 23:07:55 <metaGross128> i know
Nov 27 23:08:06 <metaGross128> i just wanted to test the driver
Nov 27 23:08:17 <zmatt> sure, it sounds like it ought to work
Nov 27 23:08:23 <metaGross128> or else i will write my own
Nov 27 23:08:26 <zmatt> except evidently it's... not
Nov 27 23:08:27 <metaGross128> :p
Nov 27 23:08:50 <zmatt> AH
Nov 27 23:08:52 <zmatt> found the problem
Nov 27 23:08:56 <zmatt> your compatible-string is wrong
Nov 27 23:08:58 <metaGross128> okay
Nov 27 23:09:02 <zmatt> you wrote "blox,neo-6m"
Nov 27 23:09:10 <metaGross128> okay
Nov 27 23:09:14 <zmatt> but it should be "u-blox,neo-6m"
Nov 27 23:09:54 <metaGross128> oh !
Nov 27 23:09:58 <metaGross128> right
Nov 27 23:10:15 <metaGross128> fuuuuuuuuuuuuuuuuuuuuuu
Nov 27 23:10:19 <metaGross128> thanks
Nov 27 23:10:22 <set_> Ha!
Nov 27 23:10:30 <zmatt> devicetree is rather intolerant of typos ;)
Nov 27 23:10:52 <set_> The ole u-blox in the corner tree!
Nov 27 23:11:40 <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
Nov 27 23:11:50 <metaGross128> dtc compiler is tolerent to this type of errors ?
Nov 27 23:12:13 <metaGross128> dts sementic compiler maybe ?
Nov 27 23:12:29 <metaGross128> parser *
Nov 27 23:12:54 <set_> When you all go on break, let me know.
Nov 27 23:13:02 <set_> I want to read something else.
Nov 27 23:13:16 <zmatt> dtc will catch syntactic errors
Nov 27 23:13:29 <zmatt> but to dtc, the value of the compatible-property is a just a string
Nov 27 23:14:05 <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
Nov 27 23:14:41 <zmatt> actually, does udev not log something if it can't find a driver to load?
Nov 27 23:15:33 <metaGross128> now i see /dev/gnss0
Nov 27 23:15:35 <zmatt> since if the kernel can't find a driver it will poke userspace to load the appropriate kernel module
Nov 27 23:15:43 <zmatt> which would typically be udev
Nov 27 23:15:48 <zmatt> doing that
Nov 27 23:16:35 <metaGross128> yes
Nov 27 23:16:46 <zmatt> of course you won't find that in kernel log but in syslog (or journal when using systemd)
Nov 27 23:17:17 <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
Nov 27 23:21:45 <metaGross128> okay i will see yhis
Nov 27 23:22:08 <metaGross128> i don't know enough about udev xD
Nov 27 23:27:53 <set_> break time?
Nov 27 23:28:48 <set_> I just made a transpose and a random.randn !
Nov 27 23:29:07 <set_> Learnin' slowly over CHE!
Nov 27 23:29:16 <set_> Sorry. HERE!
Nov 27 23:31:48 <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?
Nov 27 23:32:12 <set_> Literally, something is wrong w/ these people. Outie!
Nov 27 23:32:34 <set_> Sorry. I am leaving now.
Nov 27 23:32:42 <set_> bg
Nov 28 00:23:24 <set_> Do it! Capes!
Nov 28 00:26:16 * set_ is back to bg
Nov 28 00:53:46 <set_> binary conversion. hex party!
Nov 28 00:56:25 <set_> I got partially how to do the c/c++ save-me-space equations now. Phew!
**** ENDING LOGGING AT Sun Nov 28 02:59:56 2021