**** BEGIN LOGGING AT Wed Oct 24 03:00:00 2018
Oct 24 03:04:47 <suprothunderbolt> If I mod probe it, will it be finding the things I set in the device tree? I.e. the gpio it should use?
Oct 24 03:05:48 <zmatt> sure, how the kernel module gets loaded doesn't affect those things
Oct 24 03:05:57 <zmatt> it's still really weird it doesn't get loaded though
Oct 24 03:06:21 <zmatt> have you tried without initramfs?
Oct 24 03:06:24 <suprothunderbolt> I'm sure i've made an embarrasing typo somewhere else :)
Oct 24 03:07:19 <zmatt> that doesn't explain anything... if the compatible-property doesn't match the driver's advertised ids then it won't get used at all (like before), if it does match then it should get automatically loaded
Oct 24 03:08:18 <suprothunderbolt> ahh so modprobe wouldn't print anything without the DTS?
Oct 24 03:08:58 <zmatt> modprobe merely makes the driver available in the kernel, just like it would be if compiled-in.  that doesn't mean it'll get used for anything
Oct 24 03:09:31 <zmatt> hmm, there *was* something weird about i2c drivers and DT matching though, I just remembered
Oct 24 03:09:43 <suprothunderbolt> okay so the himax_ts_probe function is called when it see its' matched in the DT
Oct 24 03:12:04 <suprothunderbolt> as a possible issue, not sure if I'm doing this right, but i'm specifying these overlays by: uboot_overlay_addr5=/lib/firmware/BB-I2C1-00A0.dtbo
Oct 24 03:13:37 <zmatt> the only thing wrong with it is that you've modified a standard overlay instead of making a copy under a different name :P
Oct 24 03:13:47 <suprothunderbolt> If I specify any overlays like that it seems to disable the universal overlay and I loose the ability to do config-pin
Oct 24 03:14:02 <suprothunderbolt> *cough* meant I didn't need to work out how the install script worked... ;)
Oct 24 03:14:13 <zmatt> also, if you want your overlay sources to be less painful to read and write, you might want to consider using my overlay-utils https://github.com/mvduin/overlay-utils
Oct 24 03:14:25 <zmatt> see i2c1*.dtsi in there
Oct 24 03:14:42 <zmatt> (you could just concatenate those two sources to create a single overlay that does both)
Oct 24 03:15:19 <zmatt> it uses a perl script to convert the source code into the mess with fragment@n { __overlay__ { etc
Oct 24 03:16:39 <zmatt> traditionally the universal overlay got implicitly disabled yes, but I'm pretty sure that either has changed recently or will soon change
Oct 24 03:17:04 <suprothunderbolt> looks neat! Though I think I'm already close to getting it all working... *cough*...
Oct 24 03:17:07 <suprothunderbolt> maybe.. ;)
Oct 24 03:17:07 <zmatt> since overlays have been changed to explicitly disable conflicting parts of the universal overlay
Oct 24 03:17:41 <suprothunderbolt> yeah, it'd be handy just so I don't have to find a eqep example.
Oct 24 03:17:49 <suprothunderbolt> :)
Oct 24 03:18:01 <suprothunderbolt> because it's very easy to get that working with config-pin
Oct 24 03:18:10 <zmatt> grep eqep in the bb.org-overlays ?
Oct 24 03:18:25 <suprothunderbolt> yeah... :)
Oct 24 03:18:26 <zmatt> actually, see bone_eqep0-00A0.dts ?
Oct 24 03:18:57 <zmatt> iirc the eqep driver is quite limited though
Oct 24 03:19:03 <Vikas> Hello
Oct 24 03:19:18 <suprothunderbolt> I don't need anything very exotic, setup by config-pin seems to work well
Oct 24 03:19:22 <Vikas> I would like to know wireless board with high RAM configuration
Oct 24 03:19:32 <Vikas> Does anyone has idea
Oct 24 03:19:32 <suprothunderbolt> tracks fast and it's easy to control from python
Oct 24 03:20:01 <suprothunderbolt> how much RAM?
Oct 24 03:20:38 <suprothunderbolt> ...
Oct 24 03:20:40 <suprothunderbolt> :)
Oct 24 03:21:05 <zmatt> suprothunderbolt: fair enough :)  if you ever find yourself in need of more of eQEP's features, or more precise control over its configuration, I also have a python example that configures the peripheral directly from userspace via uio: https://github.com/mvduin/py-uio/blob/master/other-examples/eqep-test.py
Oct 24 03:21:30 <suprothunderbolt> oh nice
Oct 24 03:21:53 <zmatt> it should still work, though haven't tested it recently
Oct 24 03:27:10 <suprothunderbolt> so good news! it does something different when I mod probe...
Oct 24 03:27:21 <suprothunderbolt> bad news... it seg faults
Oct 24 03:27:26 <zmatt> lol
Oct 24 03:28:00 <zmatt> oh btw what's the modalias attribute (in sysfs) of the device?
Oct 24 03:28:24 <zmatt> that's the thing being matched against the aliases declared by the module
Oct 24 03:28:59 <suprothunderbolt> i2c:himax_ts
Oct 24 03:29:15 <zmatt> well that explains why it doesn't get loaded
Oct 24 03:29:21 <suprothunderbolt> that's not in the modinfo...
Oct 24 03:29:24 <zmatt> so there *is* something weird about i2c device matching
Oct 24 03:29:42 <zmatt> how the hell did it pick that modalias
Oct 24 03:29:51 <suprothunderbolt> so do i change change the compatible name in the dts?
Oct 24 03:30:33 <zmatt> or add himax_ts to the i2c_device_id list in the driver
Oct 24 03:31:07 <suprothunderbolt> true. Though if both work I'll go for the one that doesn't require a kernel compile
Oct 24 03:31:59 <suprothunderbolt> I'm an idiot so I'm using a windows desktop running the linux subsystem, which works really well... apart from make -j > 1 fails...  j1 works fine
Oct 24 03:32:13 <zmatt> lol
Oct 24 03:32:40 <zmatt> well I think the lack of himax_ts in that list also explains the Requested model not found error
Oct 24 03:33:33 <suprothunderbolt> though I don't really know if this driver works with a current linux version at all / properly
Oct 24 03:33:36 <zmatt> and/or segfault
Oct 24 03:33:46 <zmatt> the struct i2c_device_id * is passed to the i2c probe function
Oct 24 03:33:56 <zmatt> so, if none of those match...
Oct 24 03:34:01 <suprothunderbolt> ahh
Oct 24 03:34:41 <zmatt> ah first you got Unsupported device model, which means it never reached that test
Oct 24 03:34:54 <suprothunderbolt> i think i've fixed that
Oct 24 03:35:06 <zmatt> so now you have a NULL dereference when it does reach this test: https://github.com/utilite-computer/linux-kernel/blob/utilite/devel/drivers/input/touchscreen/himax_ts.c#L354
Oct 24 03:35:12 <zmatt> since idp is NULL
Oct 24 03:35:48 <suprothunderbolt> i noticed this earlier: Found device ID: 0x852803
Oct 24 03:35:57 <zmatt> yeah that's printed a few lines earlier
Oct 24 03:36:01 <suprothunderbolt> so it's looking for model 0x8528
Oct 24 03:36:21 <zmatt> yes
Oct 24 03:36:24 <suprothunderbolt> but the driver doesn't have that as a supported one. An older driver I found did
Oct 24 03:36:39 <suprothunderbolt> in their code it uses all the same init stuff for both
Oct 24 03:37:01 <suprothunderbolt> so I added it and recompiled and that's why it now segfaults instead of that
Oct 24 03:37:10 <zmatt> added what?
Oct 24 03:37:13 <suprothunderbolt> though the segfault might be as you say by the missing match still
Oct 24 03:37:15 <zmatt> ah, you added it one place
Oct 24 03:37:38 <suprothunderbolt> in himax_ts_props
Oct 24 03:37:41 <zmatt> also, presumably there's also a better device model to use than "himax_ts", which is just the name of the driver
Oct 24 03:38:26 <zmatt> although the internet isn't being helpful... no matches on himax_ts 0x8528
Oct 24 03:38:39 <zmatt> you're the first with that model I guess... congrats? :P
Oct 24 03:39:05 <suprothunderbolt> hah, attempting to use it with beaglebone / mainline. It's in the nanopi kernel
Oct 24 03:39:12 <suprothunderbolt> it's a nanopi supported screen
Oct 24 03:39:22 <suprothunderbolt> but there stuff doesn't use the device tree stuff
Oct 24 03:39:31 <suprothunderbolt> or at least doesn't look like it does
Oct 24 03:39:45 <zmatt> it was a really ancient kernel wasn't it?
Oct 24 03:39:52 <suprothunderbolt> oh yes
Oct 24 03:39:59 <suprothunderbolt> 3.4
Oct 24 03:40:11 <zmatt> yeah
Oct 24 03:40:30 <suprothunderbolt> though i've heard it was mostly some weird port of an older one to 3.4
Oct 24 03:42:40 <zmatt> https://i2c.wiki.kernel.org/index.php/OF_Modalias
Oct 24 03:43:08 <zmatt> so basically "yeah it sucks, but too much relies on the current wrong behaviour to fix it any time soon" :P
Oct 24 03:43:55 <suprothunderbolt> oh!
Oct 24 03:45:32 <suprothunderbolt> okay, so changing the dts doesn't change that alias
Oct 24 03:46:14 <zmatt> dts does determine the modalias, where else would it get it from? :)  I think it just strips the vendor prefix from the first compatible-string, but I'm still checking to confirm
Oct 24 03:46:59 <suprothunderbolt> my dts now looks like:
Oct 24 03:47:01 <zmatt> or maybe the node name
Oct 24 03:47:08 <suprothunderbolt> compatible = "himax,hx8528-a";
Oct 24 03:47:28 <suprothunderbolt> node name is
Oct 24 03:47:35 <suprothunderbolt> himax-hx8526@4a
Oct 24 03:47:45 <zmatt> okay, and what's the resulting modalias in sysfs ?
Oct 24 03:48:11 <suprothunderbolt> cat /sys/bus/i2c/devices/1-004a/modalias i2c:himax_ts
Oct 24 03:48:16 <zmatt> also, is the difference between the two intentional?
Oct 24 03:48:21 <zmatt> wait, it still says himax_ts ?
Oct 24 03:48:30 <suprothunderbolt> nope, i just haven't updated the node...
Oct 24 03:48:41 <suprothunderbolt> not sure what the node name actually does...
Oct 24 03:49:06 <zmatt> nothing.  the official convention is to use something generic like "rtc"
Oct 24 03:49:09 <zmatt> iirc
Oct 24 03:49:10 <suprothunderbolt> still says himax_ts
Oct 24 03:49:22 <zmatt> but.. where the hell is it getting that from
Oct 24 03:49:27 <suprothunderbolt> ahh okay so ts is fine
Oct 24 03:49:49 <suprothunderbolt> my confusion exatly
Oct 24 03:49:59 <zmatt> the dts is all it has based on which to create the device
Oct 24 03:50:31 <zmatt> you're sure you're not accidently using an old dts?  cat /sys/bus/i2c/devices/1-004a/of_node/compatible
Oct 24 03:51:57 <suprothunderbolt> oh!
Oct 24 03:51:58 <suprothunderbolt> cat /sys/bus/i2c/devices/1-004a/of_node/compatible himax,himax_ts
Oct 24 03:52:03 <zmatt> there we go
Oct 24 03:52:07 <suprothunderbolt> i am!
Oct 24 03:52:33 <suprothunderbolt> sorry about that
Oct 24 03:54:30 <suprothunderbolt> @cat /sys/bus/i2c/devices/1-004a/modalias i2c:hx8528-a
Oct 24 03:55:07 <suprothunderbolt> so modprobe doesn't segfault
Oct 24 03:55:46 <zmatt> modprobe still needed?
Oct 24 03:56:16 <suprothunderbolt> ls /sys/bus/i2c/devices/1-004a/ modalias  name  of_node  power  subsystem  uevent
Oct 24 03:57:05 <zmatt> does modalias match one of the aliases from modinfo?
Oct 24 03:57:52 <zmatt> okay just confirmed, modalias is indeed created by taking the first compatible-string, stripping off the vendor prefix (the part up to and including the first comma), and sticking "i2c:" in front of it
Oct 24 03:57:59 <suprothunderbolt> yes
Oct 24 03:58:27 <suprothunderbolt> and it's now matching
Oct 24 03:58:37 <zmatt> but the probe fails?
Oct 24 03:58:50 <zmatt> if it's matching, manual modprobe should now no longer be needed?
Oct 24 03:59:05 <zmatt> (after depmod and reboot to be sure)
Oct 24 03:59:37 <suprothunderbolt> it's no longer needed :)
Oct 24 04:00:04 <zmatt> but probe still fails? since you showed the driver didn't actually attach (no driver-symlink in sysfs)
Oct 24 04:00:19 <suprothunderbolt> Oct 24 03:58:58 beaglebone kernel: [   20.656940] himax_ts 1-004a: Unable to request touchscreen IRQ.
Oct 24 04:00:23 <zmatt> ah
Oct 24 04:01:11 <suprothunderbolt> request_threaded_irq(priv->irq is the section before that
Oct 24 04:01:26 <zmatt> your interrupt section in dts looks weird
Oct 24 04:01:33 <zmatt> you have the correct declaration commented out
Oct 24 04:01:35 <suprothunderbolt> i'm not specifying an IRQ in the DTS, the example I found didn't
Oct 24 04:02:02 <zmatt> dunno what "gpio_intr" is but it's not a standard thing nor used in the driver you linked to
Oct 24 04:02:04 <suprothunderbolt> yeah, the example i found of this being using (not with a BB)
Oct 24 04:03:49 <suprothunderbolt> is there a way to see what paramaters the driver can accept?
Oct 24 04:04:02 <zmatt> yeah you'd use something like  interrupt-parent = <&gpio1>; interrupts = <28 IRQ_TYPE_EDGE_FALLING>;
Oct 24 04:04:53 <zmatt> (non-ancient kernels also support packing them together as    interrupts-extended = <&gpio1 28 IRQ_TYPE_EDGE_FALLING>;   but the official advice is to only use it if you need to declare multiple interrupts with different parents)
Oct 24 04:05:11 <zmatt> no, not really
Oct 24 04:05:46 <suprothunderbolt> okay, the driver example I found used the gpio_irq so I thought something else wacky was going on
Oct 24 04:06:35 <zmatt> the irq type constants can be found in <dt-bindings/interrupt-controller/irq.h> btw
Oct 24 04:08:27 <suprothunderbolt> ls /sys/bus/i2c/devices/1-004a/ driver  input  modalias  name  of_node  power  subsystem  uevent
Oct 24 04:08:43 <zmatt> hurray \o/
Oct 24 04:09:32 <suprothunderbolt> as a side issue... it actually works!
Oct 24 04:09:35 <suprothunderbolt> it's ALIVE!
Oct 24 04:09:38 <suprothunderbolt> :D
Oct 24 04:10:07 <suprothunderbolt> zmatt: thanks for the giant pile of very patient help. Even when I'd made stupid mistakes
Oct 24 04:10:22 <suprothunderbolt> I know understand a bit more about how the magic DT thing works...
Oct 24 04:10:36 <zmatt> you're welcome :)
Oct 24 04:11:04 <zmatt> yeah the quirky modalias weirdness for i2c devices definitely didn't help
Oct 24 04:11:06 <zmatt> and isn't DT's fault
Oct 24 04:13:25 <suprothunderbolt> 5 different and correlated issues
Oct 24 04:13:37 <suprothunderbolt> looking into sys helped a lot to work out what was going on
Oct 24 04:20:56 <suprothunderbolt> now to get it rotated correctly :) But first delicious lebanese food... Thanks again :)
Oct 24 04:21:22 <zmatt> rotation? as in 90 degrees?
Oct 24 04:21:48 <zmatt> hope you have a convenient way of simply creating a sideways UI since doing rotation in software is obviously... not fast
Oct 24 04:21:59 <zmatt> and bon apetit!
Oct 24 04:22:36 <suprothunderbolt> I've just got Option          "Rotate" "CCW" in my xorg.conf
Oct 24 04:23:12 <suprothunderbolt> in fbdev... I was assuming that it'd do that in hardware pretty quickly... I might have been spoilt by proper gl drivers...
Oct 24 04:23:15 <suprothunderbolt> acceleration
Oct 24 04:23:32 <zmatt> decent display drivers can do rotation in hardware
Oct 24 04:23:45 <zmatt> like omapdss found on the beagleboard-x15
Oct 24 04:23:53 <zmatt> *display controllers I mean
Oct 24 04:23:54 <suprothunderbolt> ahh :(
Oct 24 04:24:03 <suprothunderbolt> so not the one we have on the bbb?
Oct 24 04:24:06 <zmatt> the am335x has a really really _really_ basic display controller
Oct 24 04:24:20 <zmatt> it doesn't even have support for a hardware cursor
Oct 24 04:25:11 <zmatt> it just reads bytes from memory contiguously and clocks them out onto pins
Oct 24 04:25:15 <zmatt> that's it
Oct 24 04:25:22 <suprothunderbolt> oh i thought the SGX stuff actually did GL decently.
Oct 24 04:25:29 <zmatt> sure, but you said you were using x11
Oct 24 04:25:36 <suprothunderbolt> and that that the GL context would just be roated
Oct 24 04:25:38 <suprothunderbolt> rotated
Oct 24 04:25:46 <suprothunderbolt> oh and wayland etc isn't a GLX context?
Oct 24 04:25:53 <zmatt> SGX doesn't support opengl, it supports opengl ES (1 and 2)
Oct 24 04:26:00 <zmatt> it's also not compatible with x11
Oct 24 04:26:20 <suprothunderbolt> oh?
Oct 24 04:26:22 <zmatt> wayland should work but I've never experimented with it
Oct 24 04:26:44 <suprothunderbolt> I guess I'll see how I go with this and the improve
Oct 24 04:26:50 <zmatt> note also that sgx is not something that works out of the box with the default images, it requires effort
Oct 24 04:26:59 <suprothunderbolt> I'm hoping to run QML stuff on it
Oct 24 04:27:28 <zmatt> you can try using these packages I've created quite a while ago => https://liktaanjeneus.nl/sgx/
Oct 24 04:27:39 <zmatt> along with the kernel driver you'll have to compile
Oct 24 04:28:03 <suprothunderbolt> and then you ran QT on that?
Oct 24 04:28:12 <suprothunderbolt> or something else?
Oct 24 04:28:20 <suprothunderbolt> though brb. hungry!
Oct 24 04:28:26 <zmatt> yeah we use qt5 with the eglfs backend, though no qml
Oct 24 04:28:48 <zmatt> the perl script in that directory actually patches the qt5 libs to use a 16-bit framebuffer
Oct 24 04:29:09 <zmatt> so you can skip that if you actually want a 24-bit framebuffer
Oct 24 12:04:18 <kremlin> m
Oct 24 14:31:44 <ayjay_t> good morning kremlin
Oct 24 16:57:17 <dreamhiker> Hello! I got beagleboard-x15. I am totally new to the board and my Linux may require some refreshment. I have a few basic questions to ask:
Oct 24 16:58:21 <dreamhiker> 1. Which Linux flavor is more recommended to use? I need to implement a quite involved system controlling multiple devices.
Oct 24 16:58:45 <zmatt> debian is the default distro used on beaglebone and beagleboard devices, and what most people use
Oct 24 17:01:07 <dreamhiker> 2. How to I install/update my Linux OS. Preferably, if possible, without the MicroSD card. I do have an usb stick and the internet connection.
Oct 24 17:03:36 <zmatt> hmm
Oct 24 17:04:31 <zmatt> I'm not sure what boot devices u-boot supports... it might support booting from usb stick, in which case you can then use that to safely reflash eMMC
Oct 24 17:04:54 <zmatt> I'd need to try it when I'm home
Oct 24 17:05:40 <zmatt> is it really that much trouble to get a microsd card?
Oct 24 17:07:41 <Snert_> yea, best to go through the initial install/flash process and be better prepared for when things go south.
Oct 24 17:11:14 <zmatt> if things go south (i.e. you'd manage to bork the bootloader on eMMC) then a microsd card is pretty much required for recovery
Oct 24 17:13:07 <dreamhiker> OK, I will go and by the card. Just in case for me not to screw up the board, could you please send me an url for the install/flash procedure?
Oct 24 17:13:40 <Snert_> I bet that bbx15 already has an OS flashed on it.
Oct 24 17:13:50 <Snert_> out of the box.
Oct 24 17:14:19 <Snert_> and no, you can google up the flash procedure and everything you need in 2.53 seconds.
Oct 24 17:15:05 <zmatt> yeah it'll ship with an image
Oct 24 17:15:11 <zmatt> dunno how recent an image, but it'll have something
Oct 24 17:16:43 <dreamhiker> Linux BeagleBoard-X15 4.9.35-ti-r44 #1 SMP PREEMPT Sat Jul 1 00:54:33 UTC 2017 armv7l GNU/Linux
Oct 24 17:16:58 <zmatt> okay not very recent, ehhe
Oct 24 17:19:50 <zmatt> you can find the latest images at https://beagleboard.org/latest-images (you'll want the Debian 9.5 2018-10-07 4GB SD LXQT image for BeagleBoard-X15) and that page also has a paragraph on how to actually reflash eMMC rather than merely booting from sd card
Oct 24 17:23:10 <CoffeeBreakfast> I want a X15 for Christmas
Oct 24 18:28:02 <Snert_> digikey has a great little fan kit for the bbx15.
Oct 24 18:28:31 <Snert_> the microconnector on the fan where it plugs into the board is the difficult part.
Oct 24 18:28:59 <Snert_> after you get The Blessed Fan With Connector from digikey.....
Oct 24 18:29:47 <Snert_> if the fan goes bad, you can splice the wires for a new fan....which is several dollars cheaper when you buy it seperately.
Oct 24 18:30:15 <Snert_> because it is supplied with no connector.
Oct 24 18:32:11 <Snert_> https://www.digikey.com/product-detail/en/digi-key-electronics/X15FANKIT/X15FANKIT-ND/5822502
Oct 24 18:33:36 <Snert_> it doesmn't say so on the web, but mine came with a heatsink. Black alu....wish it were solid copper.
Oct 24 18:35:24 <Snert_> I take that back....here's a link to the heatsink
Oct 24 18:35:29 <Snert_> https://www.digikey.com/product-detail/en/cts-thermal-management-products/BDN10-3CB-A01/294-1098-ND/272736
Oct 24 18:37:01 <Snert_> the heatsink fins need to be spaced just right for the fan screws cuz the screws just simply thread into the space between the fins.
Oct 24 18:37:53 <Snert_> granted, all this can be sourced on Ali most likely for less than 1/2 the cost
Oct 24 21:07:54 <zmatt-> today I learned: it is really important in C++ to mark move-constructors as "noexcept" (whenever this is true of course)
Oct 24 21:15:50 <Snert_> what happens if you don't?
Oct 24 21:19:15 <zmatt-> for example if you have std::vector<Foo> where Foo is both copy- and move-constructible, but its move-constructors are not "noexcept", then whenever the std::vector needs to reallocate its storage, it will *copy* the elements over to the new storage rather than moving them
Oct 24 21:21:00 <zmatt-> the reason is exception-safety: if an exception occurs during all this, it needs to leave the object in the original state
Oct 24 21:21:14 <zmatt-> but if you've moved over half the elements, you've got a problem
Oct 24 21:23:01 <zmatt> therefore it either want a guarantee that elements can be moved without any risk of exceptions being thrown, or otherwise it'll just fall back to copying the elements in which case it can simply discard the half-copied array if anything goes wrong
Oct 25 01:24:11 <set_> reverse!
Oct 25 01:29:51 <set_> rev-right and rev-left, too!
Oct 25 01:30:12 <set_> Five point turn...here I come!
Oct 25 02:53:07 <set_> What GPIO pin is Motor Four on the MotorCape?
Oct 25 02:53:21 <set_> Oh!
Oct 25 02:53:29 <set_> I do not know. Forget it.
Oct 25 02:53:45 <zmatt> https://pastebin.com/ypQ3hpVb
Oct 25 02:53:52 <zmatt> the list of pins is in there
Oct 25 02:55:11 <set_> Okay. zmatt: You handed out some software not too long ago. I kept it. I just used it to see the pin configuration.
Oct 25 02:55:29 <set_> Memory!
Oct 25 02:55:59 <set_> I was off base anyway. I changed the GPIO pin but left the PWM pin the same. Oops!
Oct 25 02:57:19 <set_> That was the exact same software. Thank you, again.
**** ENDING LOGGING AT Thu Oct 25 03:00:00 2018