**** BEGIN LOGGING AT Thu Aug 16 03:00:01 2018 Aug 16 07:22:56 zmatt: i would think that it would show up when i scan the bus? even if i haven't got a driver for it ? (also the driver point, is a good point, it can very wel be that the person before me made a custom driver! :) ) Aug 16 07:23:42 it's on the i2c bus so my assumption is/was that it would show up when i scan i2c bus :) Aug 16 08:01:32 I am confused when does something show up in /sys/bus/i2c/devices ? when it has a driver ? Aug 16 08:15:27 oke so that only show devices with a loaded driver :) Aug 16 08:18:27 but the device address is 0x1b, it shows up when using i2cdetect in my old kernel but not in my new kernel. Aug 16 08:56:42 Duality: are you sure i2cdetect wasn't simply marking it as "in use by a kernel driver" ? Aug 16 08:56:50 in general, i2c is *not* a discoverable bus Aug 16 08:58:13 I'd actually expect it to show up in /sys/bus/i2c/devices in your case though, since you declared the existence of the device. afaik the ability to probe a driver for it should not be necessary Aug 16 08:58:53 I'm not 100% sure that's true for i2c devices in linux though Aug 16 09:07:09 ok good point :) Aug 16 09:08:08 old kernel marked it in use, but in deed i2c is not a discoverable bus. Aug 16 09:08:49 i found some driver code though, and trying to port it. but i see that a lot has changed since 3.13 :P Aug 16 09:11:02 only i see this is not going to be easy :S Aug 16 09:12:39 they modified existing tas5727 code to make it work. it is not documented what they changed, because that would be super helpfull :D Aug 16 09:17:11 might it not be easier to adapt the existing tas57xx drivers, or are the differences too substantial? Aug 16 09:18:11 the fact that the tas571x driver supports four devices (5711, 5717, 5719, 5721) suggests a fair degree of commonality within the family Aug 16 09:40:40 indeed Aug 16 09:41:29 but i don't know what i am doing, and working with. (no experience) so my idea was to start out with what i had. it is based on the 5727 code (while the chip is actually 5708) Aug 16 09:41:56 oh you don't even have a 5727 ? Aug 16 09:42:09 no did inot mention that :) ? Aug 16 09:42:21 nope Aug 16 09:42:33 sorry Aug 16 09:43:15 i always forget to mention crucial information -.- Aug 16 09:43:16 anyway, I suspect using one of the existing two drivers in 4.14 is going to be a lot easier than trying to get some patched non-mainline 3.8 driver working in 4.14 Aug 16 09:44:56 maybe i'll have too look into how it works anyway, so one of those might indeed be a good starting point :) Aug 16 09:47:37 comparing the register map summaries, they all look extremely similar Aug 16 09:50:28 the 5708 is just simpler, it's a subset Aug 16 09:55:52 i see Aug 16 09:56:36 I actually got the code from the older kernel to compile it wasn't as bad as it at first seemed :D I only had to change 4 lines of code. to make it compile. Aug 16 09:58:46 it compiles but dmesg says that it doesn't show up yet. maybe i am missing something in the build chain. Aug 16 09:59:51 maybe it's a good idea if i make a propper driver for it. instead of hacking on the source that they hacked together from the 5727 :) Aug 16 10:00:45 at the very least it would probably be worth inspecting the existing tas571x driver to see if it looks like it would be easy to add the 5708 to the list Aug 16 10:04:58 oh i see in dmesg: tas5727 probe failed with error -121 Aug 16 10:10:17 specifically: tas5727: probe of 1-002a failed with error -121 Aug 16 10:10:51 i am wondering what 1-002a meens Aug 16 10:16:15 in the old kernel i see something like tas5708 1-001b Aug 16 10:41:27 Duality: that's bus 1, address 2a Aug 16 10:41:44 the 2a comes from the "reg" property in the device tree Aug 16 10:43:41 based on the datasheet it should indeed be 1b, so your DT is wrong Aug 16 10:44:20 (lines 358 and 360 of https://pastebin.com/vrDdnwMh ) Aug 16 11:14:34 alright but that is the address used in the old kernel's dt Aug 16 11:15:40 i'll edit it :) Aug 16 11:20:01 well that makes no sense, especially since you said it appeared as 1b rather than 2a in sysfs Aug 16 11:20:20 yes Aug 16 11:20:25 it doesn't make sense :S Aug 16 11:20:39 but i edited the address and now get a failed to identify codec :) Aug 16 11:20:53 so it finds it ! Aug 16 12:44:50 I am actually questioning how it could have worked on the old system, it clearly passes the wrong address with the DeviceTree, but then in the dmesg log it shows the correct one. Aug 16 12:46:44 hello Aug 16 12:48:44 why does beaglebone black only have 512MB ram? why not 1 or 2GB im fairly new to beaglebone but im kinda scared any fairly sophisticated program will quickly go past that Aug 16 12:50:17 like 70$ is alot for ex BBE with 1GB ram Aug 16 14:32:38 * zmatt wonders what bobbert_ is doing that would require such a huge amount of ram Aug 16 15:22:51 someone taking their nodejs-foo-bla-buzz stack "embedded" and discovering that there are hw constraints? Aug 16 15:39:06 our nodejs application is pretty bulky and takes an annoying amount of time to start, but free -h still only indicates 109M used :p Aug 16 18:02:47 zmatt: yeah, did some proof of concept once for minimal system that could still run nodejs with nodered and something. Ended up with a quite small rootfs out of buildroot and a memory footprint of 96-105M for the whole OS. Aug 16 18:03:44 (one of the questions was can we get away with it if $hw has 96M RAM, the answer was no, there were occasional crashes, recommended 128M) Aug 16 18:37:41 with nodejs you probably want a decent amount of breathing room anyway Aug 16 22:06:54 what are the best docs on the prus? Aug 16 22:07:09 because i'm currently being all-capped by someone trying to program them Aug 17 00:01:28 dunno, probably also depends on which language and tools you want to use **** ENDING LOGGING AT Fri Aug 17 03:00:04 2018