**** BEGIN LOGGING AT Tue Oct 23 02:59:59 2018 Oct 23 03:11:48 Hi Oct 23 03:18:32 thinkfat_: slowest reply ever, but I expected 18 bit to have a lot more colours than 16 :) Currently the colour gradient in the beaglebone logo is really bad looking. Oct 23 03:28:23 On our BBBs, how can I check which Process is Process: 2187 & 2183? Oct 23 03:29:35 top? Oct 23 03:30:33 ps aux | grep 2187 Oct 23 03:30:45 Aw! Oct 23 03:30:49 Thank you. Oct 23 03:31:42 now back to working out why the kernel module I've ported / written for the touch screen isn't working... :) Oct 23 03:31:51 lcd screen works now, but no touch Oct 23 03:32:10 Cool! Oct 23 03:52:22 How can I work around, arducopter.service: Failed with result 'resources', if I am not using any resources except a .service file which I am trying to start on my BBBlue? Oct 23 04:00:01 forget I asksed. systemd.exec is vast. Yikes! Oct 23 04:12:10 it means that a configured resource limit was exceeded Oct 23 04:15:02 Oh. Oct 23 04:16:37 PID: 5183 can be found where? I have tried looking up on debian w/ top and ps. I have come up empty. Oct 23 04:17:01 Does that seem odd that a process does not exist that is exceeded? Oct 23 04:18:22 I will go and search the web some more but I may make reference to some debian user groups too. Oct 23 04:18:32 suprothunderbolt: you can do ps u -p 2187 ... more elegant than grepping :P Oct 23 04:18:46 set_: ehm, what do you mean? Oct 23 04:18:51 I used -A w/ ps. Oct 23 04:18:55 why do you think a process with that pid (still) exists? Oct 23 04:19:00 what exactly is being logged? Oct 23 04:19:03 use pastebin Oct 23 04:19:06 Okay. Oct 23 04:19:08 also, pastebin your service file Oct 23 04:19:18 journalctl -xe? Oct 23 04:19:32 Okay about the .service file. Oct 23 04:19:41 to get the last 100 lines related to your service you can use journalctl -n 100 -u arducopter.service Oct 23 04:19:48 Okay. Oct 23 04:20:26 I am starting up the BBBlue again. Oct 23 04:20:32 new image! Oct 23 04:20:45 ?? Oct 23 04:21:02 I turned it off a second ago. Oct 23 04:21:11 why? weren't you trying to debug something? Oct 23 04:21:19 and/or locate a process Oct 23 04:21:36 Yes...but I kept failing and my back started to hurt. Oct 23 04:22:47 hmm, I don't think service files have ever managed to hurt my back Oct 23 04:23:33 I know. This is something new I am going through. Odd days. Oct 23 04:24:33 https://pastebin.com/nXG9ALYk is the journalctl cmd. Oct 23 04:25:05 okay, so it's simply crashing Oct 23 04:25:50 Yes. Oct 23 04:25:51 probably because they're trying to rudely access the pru via /dev/mem, but it hasn't actually been enabled by the kernel Oct 23 04:25:58 Oh! Oct 23 04:26:14 I don't see the resource error you asked about earlier though Oct 23 04:26:24 I know. I was trying something else then. Oct 23 04:26:31 This is my updated version. Oct 23 04:27:14 https://pastebin.com/cVqGxhKR is the .service file. Oct 23 04:27:28 seems fine Oct 23 04:28:50 I don't know how the robotics stuff is supposed to work exactly, but my understanding is that it expects pru to already be initialized by the kernel in advance, which means remoteproc-pru must be enabled and suitable firmware needs to be in the right place Oct 23 04:29:08 hey zmatt: How do I attempt to erase a file w/ the auto function? Oct 23 04:29:09 and they don't actually check whether this happened, hence the bus error Oct 23 04:29:18 I have an odd file now from journalctl. Oct 23 04:29:20 I have no clue what you mean by that Oct 23 04:29:47 I thought Linux could guess what was next w/ a certain cmd on the terminal. Oct 23 04:30:12 "what was next" = what I would type out Oct 23 04:31:39 I am trying to rm a file but I did not put the file there. Oct 23 04:32:28 auto type or whatever... Oct 23 04:32:50 it finishes what I would type if I was to type out the entire file name. Oct 23 04:33:25 you seem to be talking about tab completion, but I still don't get what your question is Oct 23 04:34:19 tab completion. Thank you. Oct 23 04:34:41 How can I use tab completion to erase a file on my terminal that I did not start or place there? Oct 23 04:35:02 ??? Oct 23 04:35:11 it states on my terminal now: ystemd[1]: and so on. Oct 23 04:35:26 Like something was left behind from the journalctl cmd. Oct 23 04:35:52 sounds like something is wrong maybe with terminfo Oct 23 04:36:20 but I understand now you don't want to erase any file whatsoever, you just want to clear the screen :P Oct 23 04:36:24 try the "clear" command Oct 23 04:36:29 Oh. Oct 23 04:36:30 Okay. Oct 23 04:36:36 pressing control-L may work too Oct 23 04:36:51 what are you using to ssh to the beaglebone Oct 23 04:36:55 nope. Still there after I type ls. Oct 23 04:36:59 PuTTY. Oct 23 04:37:01 ! Oct 23 04:37:13 I am on my Win 'puter now. Oct 23 04:37:30 oh you somehow managed to actually create a file with a garbage name? Oct 23 04:37:39 did you accidently copy-paste some stuff into the terminal? Oct 23 04:37:46 Yes. Oct 23 04:37:47 ! Oct 23 04:38:00 I had to copy the info. I put into pastebin.com. Oct 23 04:38:24 I used right click. Oct 23 04:39:08 anyway, if it unintentionally created some files, just remove them Oct 23 04:39:35 zmatt: true :) But only 1 of the 2 I remember :) Oct 23 04:39:40 I tried but it is not allowing me. I need the auto complete. Oct 23 04:39:52 if the filename has special characters, you can either escape them with backslash or put the name in quotes Oct 23 04:39:57 sorry. tab complete. Oct 23 04:39:59 tab completion may indeed help too Oct 23 04:40:02 okay, so use it? Oct 23 04:40:12 Okay. Oct 23 04:40:13 How? Oct 23 04:40:25 Off to look it up! Oct 23 04:40:32 type "rm" followed by the first few letters of the filename and then press tab Oct 23 04:40:44 Auntie! Oct 23 04:41:12 oh yea! Oct 23 04:41:21 I forget more than I learn at times, I think. Oct 23 04:50:05 Does it seem like this idea, /bin/echo pruecapin_pu >/sys/devices/platform/ocp/ocp:P8_15_pinmux/state, would work if put in a dir in /usr/bin/xxxx w/ the file name aphw w/ that .service file? Oct 23 04:50:06 ... Oct 23 04:50:52 Aw! Oct 23 05:09:14 Is there a way to get any debugging info from the device tree loading process? Spefically I've modified a touch screen driver to look like device tree supported thing but I'm not sure if it's being found / initialised and not working or just not found Oct 23 05:57:49 any debugging hints for a custom touch screen driver? I'm not sure if it's getting loaded at all. The original driver didn't have any of the compatible device tree sections so I added them. Oct 23 08:41:54 is there any logging from the loading of the device tree / overlays? I'm really not sure if my driver is being loaded or not which is making debugging a bit harder Oct 23 10:26:23 lsmod? Oct 23 12:30:12 yeah lsmod Oct 23 12:30:25 there's soemthing in /sys too i think Oct 23 12:30:30 you can probably `watch` something Oct 23 14:36:51 m Oct 23 14:36:57 Hello, I need a datasheet for the IMU used in Beaglebone blue. How can I get it? Oct 23 14:42:27 viraj: have you tried feeding the part number to the search engine of your least distrust? Oct 23 14:55:00 good morning kremlin Oct 23 14:55:06 tbr: lol Oct 23 15:12:52 i noticed in the memory map for the PRUs there is this CREGISTER keyword I'd never seen before Oct 23 15:13:11 I have trouble find docs on linker files tbh so I'd love either some docs on them or an explanation for that keyword Oct 23 15:14:07 the prus are going to be a whole universe i think Oct 23 15:14:12 i mean, a totally custom toolchain? Oct 23 18:13:43 ayjay_t: there's its own compiler and such. It's not gcc AFAIU. Oct 23 18:29:53 yeah its exciting, there's a lot Oct 23 19:52:23 it indeed has nothing to do with gcc, it's based on TI's C6x compiler Oct 23 19:54:20 ayjay_t: cregister is presumably something related to explaining the compiler what addresses are in the constant registers hence usable as base address for loads/stores without having to load the base address into a register first, but other than that I don't know any details about it (I prefer pasm over clpru) Oct 23 19:56:13 yeah we're just getting into it Oct 23 19:56:32 we have a ton of code written i feel like're gonna have to go through it, document it, and opensource it Oct 23 19:56:51 CoffeeBreakfast1: that doesn't provide info about the loading of overlays per se though... the only way to determine that is by checking the serial console output from u-boot or inspecting /proc/device-tree to look for evidence of the nodes and properties of the overlay Oct 23 19:58:32 ayjay_t: I've only played a little bit with clpru to evaluate the quality of the code it produces (crappy, even at the highest optimization level) and to make py-uio capable of loading executables produced by clpru Oct 23 19:59:14 hmm Oct 23 19:59:27 i did want to look @ it too Oct 23 19:59:35 i'd also like to NOT use stdlib Oct 23 19:59:45 or w/e they're using Oct 23 20:14:27 any thoughts on rpmsg zmatt Oct 23 20:23:13 overcomplicated? inefficient? iirc the implementation looks like it might break if the optimizer actually did its job well Oct 23 20:24:01 or maybe it contained an outright race condition... not sure, I'd need to look at it again Oct 23 20:26:19 hmm Oct 23 20:26:48 it's obviously also pretty bad that both send and receive memcpy() the data instead of allowing zero-copy access to the buffers Oct 23 20:27:10 also it uses fixed-size buffers regardless of message size, hence large messages are not supported and small messages waste space Oct 23 20:28:12 (in theory this has the benefit of allowing you to hold on to individual messages and release them later, but this is not going to be of benefit to many applications and the API does not support it Oct 23 20:28:16 ) Oct 23 20:30:06 huh? Oct 23 20:30:12 fixed size allows you to "hold onto" messages? Oct 23 20:30:24 so we have py uio as an alternative eh Oct 23 20:30:31 sorry I didn't formulate that sentence well Oct 23 20:31:37 hmm well Oct 23 20:31:39 the reason the messages are fixed size is because you're not writing messages directly into a ringbuffer, you write each message into a buffer pulled from a pool of fixed-size buffers and then add the { buffer pointer, message length } pair to a ringbuffer Oct 23 20:31:51 oh i see Oct 23 20:32:27 i suppose you could use a pool of memory and dynamically sized buffers of the same structure? Oct 23 20:32:32 it would end up being a bit filesystemy Oct 23 20:33:33 same structure = ringbuffer with pointer/length pairs Oct 23 20:33:46 oh I guess you could... for some reason I was thinking you'd have a big problem with shared access, but actually the message recipient doesn't touch the buffer allocation data structures at all, it just posts the buffer back to the sender (via another ringbuffer) when it's done Oct 23 20:34:09 so the sender could use any memory-management technique it wants, e.g. a malloc pool Oct 23 20:34:32 is that a userspace or kernal space change? Oct 23 20:34:35 however on the pru side you want something simple and efficient Oct 23 20:34:38 you're saying malloc so Oct 23 20:34:40 yeah Oct 23 20:34:40 for sure Oct 23 20:34:47 and deterministic preferably Oct 23 20:35:14 in practice that might be difficult if you're not just holding a pool of fixed-size buffers like pru is right now Oct 23 20:35:38 in contrast, if you post messages directly into a ring buffer, they can be variable-size basically "for free" Oct 23 20:36:16 that's _true_ i'm curious about the actual physical structure of these memory spaces Oct 23 20:36:26 you'd just need a way to deal with wraparound, which is still not hard Oct 23 20:36:50 yeah i mean, its a bit of a framework no matter what Oct 23 20:37:18 e-mail. lets just give the pru's an e-mail address Oct 23 20:37:26 everyone knows how to use email Oct 23 20:37:31 _for the noobs_ Oct 23 20:45:32 ayjay_t: here's a header I wrote to document the data structures for myself: https://pastebin.com/LPJduJKS Oct 23 20:49:58 there, replaced u32 by uint32_t etc to get better syntax highlighting in pastebin :P Oct 23 20:50:38 pastebin still doesn't highlight constexpr? jeez Oct 23 20:50:51 nor static_assert, or alignas Oct 23 20:50:57 is that c++ stuff Oct 23 20:51:00 sounds like heresy Oct 23 20:51:28 I wrote this header in c++ yes Oct 23 20:51:33 okay howabout a text editor with syntax highlighting that also allows you to view the docs for the syntax in the document Oct 23 20:52:05 because our tech stack is now like 5 languages and i am not nearly as good at most of them as i need to be to make meaningful changes without having to literally sound out function chains Oct 23 20:52:36 given that these are parameterized data structures, there's no good way to write them in C anyway Oct 23 20:53:23 you can only make structures for the fixed-size fragments thereof Oct 23 20:54:13 this C++ header wouldn't be great in practice either since the ring size is fixed at compile-time... but like I said, the main purpose was to document the datastructure Oct 23 20:55:35 any specific part of it you're having trouble understanding? I don't feel like I'm doing anything complicated or use advanced C++ anywhere in this paste Oct 23 20:58:22 oh yeah TI's implementation of this for pru definitely contains a race condition Oct 23 20:59:30 no no no Oct 23 20:59:32 its fine Oct 23 20:59:38 its in my "list of tabs" at the moment Oct 23 20:59:54 i'm literally drowning in code to read :-p Oct 23 21:00:17 used_elem = &used->ring[used->idx++ & (num - 1)]; Oct 23 21:00:17 used_elem->id = head; Oct 23 21:00:17 used_elem->len = len; Oct 23 21:01:02 they're writing the { descriptor index, message length } *after* incrementing used->idx Oct 23 21:04:03 not going to go wrong in practice, but still semantically wrong Oct 23 21:04:25 since incrementing used->idx is what declares that you've written the message Oct 24 01:00:41 arg... dropped out and can't see if I missed anything in the log. Anyone got any ideas about how to see if a module is being loaded and failing somehow or not being found Oct 24 01:01:01 if the device tree is finding the module. Oct 24 01:01:32 what sort of device did you declare in your overlay? Oct 24 01:01:46 it's an I2C device Oct 24 01:01:55 a touch screen Oct 24 01:02:09 you can confirm the overlay itself has been applied by checking u-boot's log output on the serial console or inspecting /proc/device-tree to confirm the nodes/properties you declared are there Oct 24 01:02:20 i2c, okay, does it show up in /sys/bus/i2c/devices ? Oct 24 01:02:27 The driver isn't the the mainline kernel, but I found one referenced in another embedded kernel and pulled it out, compiled okay Oct 24 01:03:02 did you run "depmod" after installing the module ? Oct 24 01:03:04 oh nice. Didn't realise u-boot would be logging to the serial console. Oct 24 01:03:27 no? I complied the whole kernel and installed them as debs Oct 24 01:03:33 ah okay Oct 24 01:03:39 will I still have to run depmod? Oct 24 01:03:47 is the driver compiled as module or compiled into the kernel itself? Oct 24 01:03:51 module Oct 24 01:04:10 himax_ts Oct 24 01:04:15 if all is well you shouldn't *need* to run depmod, but it doesn't hurt to run it anyway in case all is not well Oct 24 01:05:01 depmod is responsible for generating the index files used to automatically load the right kernel module(s) needed for a particular device Oct 24 01:07:07 cat /sys/bus/i2c/devices/1-004a/name himax_ts Oct 24 01:07:32 is there a /sys/bus/i2c/devices/1-004a/driver symlink ? Oct 24 01:07:38 did the kernel module load? (lsmod) Oct 24 01:08:07 ls /sys/bus/i2c/devices/1-004a/ modalias name of_node power subsystem uevent Oct 24 01:08:51 not in lsmod nad no driver symlink Oct 24 01:08:57 so the kernel has no idea what to do with this device. what happens if you manually load the module (modprobe himax_ts) ? does it recognize the device then? Oct 24 01:09:27 lsmod Module Size Used by himax_ts 16384 0 Oct 24 01:09:57 is there are 'driver' symlink now? Oct 24 01:10:02 no Oct 24 01:10:18 so the kernel doesn't think this driver is for this device Oct 24 01:10:26 can I see your DT declaration? Oct 24 01:11:58 zmatt: https://paste.debian.net/1048711/ Oct 24 01:15:14 does the driver declare "himax,himax_ts" as an of_device_id it matches on? Oct 24 01:15:34 { .compatible = "himax,himax_ts", }, Oct 24 01:15:49 have a link to the source code? Oct 24 01:17:23 https://github.com/utilite-computer/linux-kernel/blob/utilite/devel/drivers/input/touchscreen/himax_ts.c Oct 24 01:17:55 also: modinfo himax_ts | grep alias Oct 24 01:18:26 I haven't rebooted since i ran depmod in case that changes anything Oct 24 01:18:49 modinfo himax_ts | grep alias alias: i2c:hx8528-a alias: i2c:hx8526-a alias: i2c:hx8520-c alias: of:N*T*Chimax,hx8528C* alias: of:N*T*Chimax,hx8528 alias: of:N*T*Chimax,hx8526C* alias: of:N*T*Chimax,hx8526 alias: of:N*T*Chimax,hx8520C* alias: of:N*T*Chimax,hx8520 Oct 24 01:19:17 depmod just determines auto-loading of the module at boot. it may be interesting to reboot to see if it gets automatically loaded Oct 24 01:19:29 don't paste multiline output into chat Oct 24 01:19:36 sorry about that Oct 24 01:19:44 longer than planned Oct 24 01:20:07 maybe there's two separate issues: maybe it didn't get loaded because the module index wasn't okay for some reason, and maybe subsequently the probe fails Oct 24 01:20:20 if the latter happens I kinda expect some complaints in the kernel log though Oct 24 01:20:24 https://paste.debian.net/1048713/ Oct 24 01:20:46 yeah, I'm not seeing anything in /var/log/syslog Oct 24 01:20:48 eh, this doesn't match what you linked to Oct 24 01:21:07 not remotely Oct 24 01:21:10 https://paste.debian.net/1048713/ Oct 24 01:21:15 ? oh... Oct 24 01:21:21 https://github.com/utilite-computer/linux-kernel/blob/utilite/devel/drivers/input/touchscreen/himax_ts.c#L463-L477 Oct 24 01:22:13 your module has hx8528-a as extra alias but no himax_ts Oct 24 01:22:38 oh! um... interesting! Oct 24 01:23:09 therefore it doesn't get used for your device Oct 24 01:23:11 also no hx8528 in the code... Oct 24 01:23:25 yes your kernel module is simply not this thing you linked to on github Oct 24 01:23:38 so you'll need to dig a bit to see how you managed to get confused Oct 24 01:23:58 mmm... that's the code I've got open... maybe I'll do a make clean. Oct 24 01:25:49 I had a previous himax_ts that I attempted to modify to get it closer to working with device tree stuff, it was from a much older kernel that I found but then I hunted down this one Oct 24 01:25:58 anyway, now you know why it didn't work: the himax_ts module you have installed does not actually declare itself as being compatible with himax,himax_ts Oct 24 01:26:11 thanks! Oct 24 01:26:41 in the mod info should alias lines have himax,himax_ts in them? Oct 24 01:26:55 or is the N*T*C part correct as well? Oct 24 01:26:58 also, if you ever manually installed a module (rather than being part of the deb), be sure to manually remove them Oct 24 01:27:11 it should have of:N*T*Chimax,himax_ts Oct 24 01:27:19 cool Oct 24 01:27:44 (and of:N*T*Chimax,himax_tsC*) Oct 24 01:29:23 I'll rebuild the module and reinstall and hopefully that'll be problem solved :) Thanks for the help! Oct 24 01:29:37 Then it's on to understanding the Alsa SOC subsystem... :) Oct 24 01:29:48 oh dear Oct 24 01:29:55 asoc /o\ Oct 24 01:29:59 hah, fun times? Oct 24 01:30:42 I think I had an easier time grasping the drm subsystem than asoc Oct 24 01:30:55 oh... Oct 24 01:31:30 well, I'm not sure I've mastered the LCD bit yet... my screen still appears to be 16 bit colour despite sending info on the other 2 pins for 18... Oct 24 01:31:47 actually, that sentence implies I now grasp asoc... I don't Oct 24 01:31:48 either that or the LCD is really bad at gradients... Oct 24 01:32:17 If I work it out I'm happy to attempt to write it up :) Oct 24 01:32:48 I'm using it with an analog devices part so it looks pretty well supported Oct 24 01:33:10 unlike the totally lack of docs that is this LCD and touchscreen controller. Oct 24 01:33:40 which red-and-blue-writing are you using? (or whatever that property is called) Oct 24 01:34:17 because one will cause most clients to use 16-bit color and the other will cause most clients to use 24-bit color (although technically both wirings support both 16- and 24-bit color) Oct 24 01:34:25 blue-and-red-wiring = "crossed"; Oct 24 01:34:52 I think I did that to get the colours right when I was testing with 16 bit colour Oct 24 01:36:15 yes, only one of the two will get the colors right for a particular physical wiring of the lcd to the am335x Oct 24 01:36:45 which also means how you connect the lcd determines whether 16-bit or 24-bit color is used by most clients Oct 24 01:36:51 ahh Oct 24 01:37:10 so if I switch it I might get 24 bit colour but my colours will be around the wrong way? Oct 24 01:38:40 yes Oct 24 01:39:34 "crossed" supports DRM_FORMAT_BGR565, DRM_FORMAT_RGB888, and DRM_FORMAT_XRGB8888 Oct 24 01:39:49 "straight" supports DRM_FORMAT_RGB565, DRM_FORMAT_BGR888, and DRM_FORMAT_XBGR8888 Oct 24 01:40:07 most clients (e.g. Qt) only support DRM_FORMAT_RGB565, DRM_FORMAT_RGB888, and DRM_FORMAT_XRGB8888 Oct 24 01:40:55 oh okay, but I'm running crossed so I'm getting the more supported formats option... Oct 24 01:41:15 i.e Oct 24 01:41:23 oops, DRM_FORMAT_RGB888 Oct 24 01:41:41 though I'm actually send RG666 to the screen Oct 24 01:41:54 though I'm actually sending RGG666 to the screen Oct 24 01:41:58 arg :) Oct 24 01:42:06 RGB :) Oct 24 01:42:33 these are in-memory formats Oct 24 01:43:14 yep, I'm running at 24 but the less significant bits aren't connected Oct 24 01:43:49 bpp = <24> Oct 24 01:43:52 once you go above 16 bits per pixel, it would be kind of pointless to less than 8 bits per channel since it makes working with the pixel data pointlessly hard while not saving any memory Oct 24 01:44:01 *to use less than... Oct 24 01:44:20 yeah Oct 24 01:44:50 whether the lcd choses to ignore some of those bits doesn't really matter Oct 24 01:45:24 but yeah, if you want to use 18-bit color then you'll probably want to swap red and blue in your physical wiring Oct 24 01:45:35 might want to evaluate whether it's worth it though (using swapped colors) Oct 24 01:46:06 I do already have that though right? Because the colours look correct when running with crossed, which is the correct option for 24? Oct 24 01:46:08 24-bit color does require more memory bandwidth than 16-bit Oct 24 01:46:26 I'm pretty keen on maximum prettiness Oct 24 01:46:27 oh right! Oct 24 01:47:35 I kinda assumed you weren't because you said it appeared to be 16-bit Oct 24 01:48:30 of course merely adding a single bit of resolution each to the red and blue channels only might not make the hugest visual difference Oct 24 01:48:56 this gradient looks identical at 16 and 18 and I'm pretty sure it shouldn't Oct 24 01:49:07 specifically the beagelbone logo Oct 24 01:50:35 also interesting food for thought: conceivably some clients might use dithering when the framebuffer is 16-bit, hence using 24-bit color but discarding 6 of those bits could conceivably look worse. I have no idea whether any clients actually do this though Oct 24 01:50:44 how are you testing this? Oct 24 01:50:53 I'm just running x Oct 24 01:51:24 but how are you comparing with 16-bit? disconnecting the two lines? Oct 24 01:51:46 only thing I think might be weird is that most of the the 24 bit examples driving 18 bit panels actually have all the 24 RGB pins in the DTS, where as I need those pins for other stuff Oct 24 01:51:57 no that won't matter Oct 24 01:52:14 okay, that's the only weird thing I think I'm doing Oct 24 01:52:32 neither the lcdc peripheral nor the driver has no idea what the pinmux is Oct 24 01:52:41 *has any idea Oct 24 01:54:18 ahh okay. Wasn't sure if there was magic when it saw less than 24 pins or something Oct 24 01:55:33 I'm comparing with 16 bit just by changing the DTS, no physical change Oct 24 01:55:37 oh and xorg Oct 24 01:55:46 took photos of both Oct 24 01:56:33 maybe it's something else in my LCD setup that is making the logo look really wrong Oct 24 01:58:44 ah you mean you disable the pinmux? Oct 24 01:58:54 that should work too yes Oct 24 02:01:10 just switch out the DTS for one with only the 16 pins defined and bpp set to 16 Oct 24 02:04:01 https://drive.google.com/file/d/1u5hMQG3zlS-4Al8JKvczWqdIwp2RMmIX/view?usp=sharing Oct 24 02:04:08 that's what the screen looks like Oct 24 02:04:39 It's and 480x800 panel and looks good in videos I've seen of other people using it Oct 24 02:08:44 that does look like something is wrong, and I don't think it has anything to do with limited color depth Oct 24 02:09:29 maybe try some actual test images to confirm all pins are working right (e.g. colored bands with each only one bit set in the pixel value) Oct 24 02:09:55 yeah, I might have miss solderered the tiny pins Oct 24 02:10:42 also I have no idea what the panel timing should be so I just guessed values until It worked this well Oct 24 02:11:00 so I might have the pixel clock / sync wrong Oct 24 02:11:01 timing isn't likely to mess up colors though Oct 24 02:11:08 (I think0 Oct 24 02:11:09 ) Oct 24 02:11:13 :) Oct 24 02:13:50 so the good news: alias: of:N*T*Chimax,himax_tsC* Oct 24 02:14:13 the bad news: ls /sys/bus/i2c/devices/1-004a/ modalias name of_node power subsystem uevent Oct 24 02:18:16 did the module get loaded automatically? (lsmod) Oct 24 02:18:21 nope Oct 24 02:18:28 that's odd Oct 24 02:18:49 try depmod (although I think modinfo gets its stuff from the same database, but I might be wrong about that) Oct 24 02:23:23 ran depmod and restarted, no change Oct 24 02:23:50 it still doesn't load? that's really weird Oct 24 02:23:55 oh! Oct 24 02:24:10 oh? Oct 24 02:24:39 I've got something in the log now! Oct 24 02:24:58 beaglebone kernel: [ 351.685710] himax_ts 1-004a: Unsupported device model Oct 24 02:25:23 oh and before that it says: Oct 24 02:18:45 beaglebone kernel: [ 351.685696] himax_ts 1-004a: Found device ID: 0x852803 Oct 24 02:25:34 okay so now it automatically loads, but the probe fails Oct 24 02:25:38 progress! Oct 24 02:25:52 still doesn't explain why manual depmod was needed, but oh well Oct 24 02:26:01 oh nice so that's logging from the kernel Oct 24 02:26:06 i mean from the driver Oct 24 02:26:14 yep Oct 24 02:28:00 progress! Oct 24 02:28:21 that logging was from when it restarted this time after depmod I think Oct 24 02:31:10 ahh nope Oct 24 02:31:48 only happens when i modprobe Oct 24 02:33:13 if I do i2cdetect I can see it Oct 24 02:37:23 so it stil doesn't load the module automatically? that's so weird Oct 24 02:38:26 oh! you're probably using an initramfs? try rebuilding it (or just delete it. it's not needed and just slows down boot) Oct 24 02:41:58 zmatt: ? when I run the install dts scripts it generates one, is that not recommended? Oct 24 02:42:29 oh so you're already regenerated it since the depmod? Oct 24 02:42:56 the install dts scripts generates one? ehh, what? Oct 24 02:43:05 what do the dts and the initramfs have to do with each other? Oct 24 02:43:18 not sure of the ordering there... will do! Though I think I might have discovered an issue in the actual kernel module code... Oct 24 02:43:39 I'm using the bb overlays github repo Oct 24 02:43:43 yeah the probe issue is separate, this is just for figuring out why the driver doesn't get automatically loaded Oct 24 02:44:01 and running the install script there Oct 24 02:44:11 oh I guess it rebuilds the initramfs in case you're not using u-boot overlays, in which case the overlays would be loaded during early boot I guess Oct 24 02:44:21 ahh okay Oct 24 02:44:52 update-initramfs: Generating /boot/initrd.img-4.14.71+ Oct 24 02:45:03 so I'm using an initramfs but could live without? Oct 24 02:45:12 if you use u-boot overlays, compiling the overlay and copying it to the appropriate path (as specified in /boot/uEnv.txt for manual overlays, or /lib/firmware for cape overlays) suffices Oct 24 02:45:26 yes I have no idea why the beaglebone images use initramfs by default Oct 24 02:45:38 in fact I think rcn's kernel package might even have a dependency on initramfs-tools Oct 24 02:45:52 but if you remove the initrd file you'll find it boots just fine Oct 24 02:46:07 and faster? Oct 24 02:46:30 at least, I never use an initramfs on beaglebones and never had any problem Oct 24 02:46:46 iirc it is faster. should be easy enough to confirm or deny Oct 24 02:47:21 yeah, as long as it still boots then easy to regenerate Oct 24 02:47:54 fair enough, I guess you might want to delay the test if you don't have a bootable sd card at hand ;) Oct 24 02:48:12 or a serial cable (if you move the initrd file rather than deleting it) Oct 24 02:48:43 but like I said, I personally have never seen any ill effect from a lack of initramfs Oct 24 02:50:31 i've got both those so should be okay :) Oct 24 02:54:26 so restarted after depmod / install script nothing in the log from it attempting to load the module Oct 24 02:55:17 weird **** ENDING LOGGING AT Wed Oct 24 03:00:00 2018