<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)
<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
<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>
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?
<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!