**** BEGIN LOGGING AT Mon Jun 29 02:59:57 2020 Jun 29 03:12:45 zmatt: the last digit in the structure from pruss.uart.io Jun 29 03:12:50 what does that signify Jun 29 03:13:00 in the loop back I was getting zero all the time Jun 29 03:13:14 I am hooked up to the digitizer and I am gettin ga non zero value Jun 29 03:13:22 zero = no errors Jun 29 03:13:35 what does 24 mean Jun 29 03:14:08 is there a table to look up error codes Jun 29 03:14:13 is this like a standard thing Jun 29 03:14:20 https://github.com/mvduin/py-uio/blob/master/src/uio/ti/icss/uart.py#L28-L31 Jun 29 03:16:17 24 == LSR_RX_FRAMING | LSR_RX_BREAK ... so it's saying it received a break, which either means a connection problem (that's what the word "break" comes from: it indicates a broken connection), or it might happen if the wrong baudrate is being used Jun 29 03:17:06 (I think a break will always cause a framing error as side-effect) Jun 29 03:21:04 is there a way to test the baudrate of a device Jun 29 03:21:18 like a universal "hey what speed are you runnint at" Jun 29 03:21:25 running* Jun 29 03:21:28 no Jun 29 03:23:20 many have tried to solve that problem before (baud rate detection). Jun 29 03:23:38 you can analyze the response (assuming you manage to get one, since worng baudrate also means whatever you send to the device is received as garbage) with a scope or logic analyzer, or a small pru program Jun 29 03:24:13 but there's no method that works under all circumstances Jun 29 03:25:15 but if the device ends each transmission in a CRLF then that could definitely be used to determine the baudrate (again assuming you can get it to send anything) Jun 29 03:25:47 but, haven't you already communicated with this thing? Jun 29 03:25:47 well I am getting x\00 Jun 29 03:25:50 so that is something Jun 29 03:25:51 I have Jun 29 03:25:56 the baudrate isn't going to magically be different Jun 29 03:26:02 i know Jun 29 03:26:23 which is weird but it does change from time to time when I plug into my windows computer Jun 29 03:26:39 i just plugged it in and it is at 19200 Jun 29 03:26:55 and yes a break will always manifest itself as b'\x00' with LSR_RX_FRAMING | LSR_RX_BREAK Jun 29 03:26:59 uhh how do you know? Jun 29 03:27:13 when I connect with its windows tool Jun 29 03:27:17 it gives a speed Jun 29 03:27:36 granted this is windows and through its usb cable Jun 29 03:27:44 could it be the timing settings Jun 29 03:27:58 I need to set the data bits and stop bit and stuff Jun 29 03:28:04 i know you have defaults Jun 29 03:28:14 I forgot to check if they what I had usually Jun 29 03:28:35 we're talking about your load cell right? Jun 29 03:28:55 it has no settings for data bits or stop bits, it uses 8n1 like basically everything Jun 29 03:29:44 and its baudrate should definitely not change randomly Jun 29 03:29:49 your right Jun 29 03:30:07 though the speed thing is at 19200 Jun 29 03:30:14 what "speed thing" ? Jun 29 03:30:15 let me force it to 9600 with the tool Jun 29 03:30:33 the FDC1 software Jun 29 03:30:44 it detects the device and speed Jun 29 03:31:07 do you yhink i could get confused since I have both the USB and serial coms plugged in? Jun 29 03:31:27 how should I know what will or won't confuse you? :P Jun 29 03:32:02 lol Jun 29 03:33:10 anyway, wrong baudrate will usually just give garbage and framing errors, it will normally not cause a break Jun 29 03:33:30 especially not _just_ a break, it would be a break and garbage, or a whole bunch of breaks Jun 29 03:33:47 should I try reading in a bunch of bytes Jun 29 03:33:53 was only asking for 1 back Jun 29 03:34:07 it always returns everything in the fifo, at a minimum Jun 29 03:35:21 the recv_bytes parameter is just used to decide whether or not it will wait for more data, but it will always return all data available Jun 29 03:35:33 ok Jun 29 03:36:10 so regardless of what the tool says if you ask for the speed with its terminal it returns 9600 Jun 29 03:37:43 are you sure you're not configuring the current connection speed or something? (which is meaningless when using usb) Jun 29 03:38:29 anyway, if you know the baudrate is 9600 then you don't have anything more to fiddle with on that front Jun 29 03:38:45 well I checked that it was 9600 for the serial port with the BR command Jun 29 03:38:53 I unplugged the usb Jun 29 03:38:55 so it's 9600. Jun 29 03:38:59 yes Jun 29 03:39:09 not sure what that connections screen is saying Jun 29 03:39:11 but for serial Jun 29 03:39:15 it is 9600 Jun 29 03:39:41 okay, so move on. like I said, receiving a break (especially if a single break is all you receive) typically means a connection problem Jun 29 03:40:06 it's detecting RxD as being low Jun 29 03:40:22 yeah all I get is a single \x00 Jun 29 03:40:39 that's just broken connection Jun 29 03:41:19 like my headers and stuff are not in correctly Jun 29 03:42:33 it's detecting RxD as being low. there are a variety of reasons Jun 29 03:43:03 if you use config-pin to change the rxd pin to gpio mode, you should be able to confirm that it's low Jun 29 03:43:26 while it should be high if it's connected correctly Jun 29 03:49:38 so why won't config-pin p9.26 gpio work Jun 29 03:49:42 (after that you could also configure the two pins to normal uart mode to confirm they're working like you've had them working before, and only then try using the pru uart instead) Jun 29 03:50:03 sounds like a plan Jun 29 03:50:08 let me do that first actually Jun 29 03:50:14 no Jun 29 03:50:18 since ok Jun 29 03:50:45 that's completely pointless as long as the connection is broken, which is most easily checked in gpio mode Jun 29 03:51:04 and nobody can possibly answer why config-pin won't work for you without more information, like an error Jun 29 03:51:33 did you use an overlay to configure the pru uart pins? (if so, why?) Jun 29 03:52:13 https://pastebin.com/TB1jDDWt Jun 29 03:52:37 I used your tool to make my overlay to set all the pins Jun 29 03:52:39 yeah that sounds like you used an overlay to configure those pins, making them unreconfigurable at runtime Jun 29 03:52:42 why? Jun 29 03:52:47 why not just use config-pin ? Jun 29 03:52:59 well once this is set up I am never gonna change it Jun 29 03:53:06 I will just get a new board Jun 29 03:53:18 so I will comment out that overlay and reboot Jun 29 03:53:25 that's nice, but that's optimization Jun 29 03:53:56 ok Jun 29 03:54:03 since you have basically nothing working yet and are basically just doing little experiments, being able to use config-pin is way more useful Jun 29 03:54:12 so I should just config-pin everything Jun 29 03:54:13 ok Jun 29 03:54:18 let me remove that overlay Jun 29 03:56:00 in general if config-pin is saying "No such file or directory", then either you made a typo in the pin number or the pin just isn't reconfigurable (e.g. because some overlay configured it) Jun 29 03:57:09 so I have it set to GPIO and I should set it to low and take my multi-meter and check that I am getting 0 for V and then set to high and ensure I am getting 3.3V right? Jun 29 03:57:15 NO Jun 29 03:57:25 ok Jun 29 03:57:31 how on earth did you come to that conclusion? Jun 29 03:57:48 to confirm that it is low Jun 29 03:57:54 you said to do that Jun 29 03:58:17 yes, confirm that it is indeed currently low, as in by reading the gpio value or using show-pins Jun 29 03:58:37 rxd is an input Jun 29 03:58:38 not an output Jun 29 03:59:10 changing it to an output might damage the beaglebone and/or your load cell Jun 29 03:59:14 yes it is low Jun 29 03:59:22 P9.24 is up though Jun 29 03:59:30 but it is an output Jun 29 03:59:34 so that is ok right? Jun 29 03:59:35 what? Jun 29 03:59:36 no? Jun 29 03:59:39 how? why? Jun 29 03:59:56 P9.24 is up and hi Jun 29 04:00:04 P9,26 is low Jun 29 04:00:14 24 is the txd pin, not the rxd pin Jun 29 04:00:35 if they're configured to pull-up then I'd expect them to be high if nothing is connected Jun 29 04:00:50 so if it's low then it's not merely a broken connection, it's actually shorted to ground somehow Jun 29 04:00:55 so I set both to GPIO mode Jun 29 04:01:22 I never said anything about the txd pin but you do you Jun 29 04:02:14 P9,24 is not up or down but it is set to hi Jun 29 04:02:26 p0.26 is neither up or down and set to lo Jun 29 04:02:35 they're not "set to" lo/hi Jun 29 04:02:53 and it's really bad for them to not have pull-up or -down Jun 29 04:03:07 I forgot that mode "gpio" idiotically means "no pull-up/down" for config-pin Jun 29 04:03:10 use mode default instead Jun 29 04:04:13 now both are pull ups Jun 29 04:04:40 not having anything in there means the value floats which is super bad Jun 29 04:04:53 so always should pull the value up or down right ? Jun 29 04:05:03 well not "super bad" but just not a good thing, and certainly not useful for diagnostic purposes here Jun 29 04:05:40 so now I can move on to the UART test? Jun 29 04:05:52 no? Jun 29 04:05:58 did you fix the problem? Jun 29 04:06:18 well I confirmed that it is lo Jun 29 04:06:20 the rxd pin should measure high (i.e. "<< hi") regardless of pull-up/down Jun 29 04:06:28 yeah so you confirmed that there's something wrong Jun 29 04:06:45 05:43 <@zmatt> while it should be high if it's connected correctly Jun 29 04:07:22 and like I just said, if it's "<< lo" even if pull-up is enabled, that means it's not merely disconnected but actually shorted to ground Jun 29 04:07:25 ok so there is something wrong if I fix it it should flip to hi Jun 29 04:07:49 well with pull-up enabled it'll even flip to high if you merely disconnect it Jun 29 04:08:02 but that's at least an improvement to being shorted to ground :P Jun 29 04:09:02 it could also be that you're connected correctly to the max3232 but it's not powered up or there's a problem with the connection from max3232 to the load cell Jun 29 04:09:59 (though if it weren't powered then I think the TxD pin would also be low, probably) Jun 29 04:10:49 anyway, your setup is fucked, even though you had it working before, so... go debug it Jun 29 04:10:52 enough hand-holding Jun 29 04:18:12 will do Jun 29 04:18:16 thanks for the tips Jun 29 04:18:21 I think I know whats up Jun 29 04:18:28 good night I will rpeort in the morning Jun 29 04:18:33 my findings Jun 29 04:18:41 over and our Jun 29 04:18:46 out* Jun 29 04:35:18 ok got it working Jun 29 04:43:48 ok got it working **** BEGIN LOGGING AT Mon Jun 29 10:19:15 2020 Jun 29 14:11:19 Hi, does Bare Metal BeagleBone Black boot from USB0? If so, what is the indicator of booting from USB0? Jun 29 14:14:30 david30: bootrom can perform bootp/tftp boot over rndis on usb0 (the mini-usb port), if that's what you're asking Jun 29 14:15:15 (this is similar to ethernet boot, except performed via usb0 by acting like an rndis usb-networking device) Jun 29 14:15:51 not sure what the word "bare metal" is doing in your question.... bootrom doesn't know or care what it's loading Jun 29 14:15:52 Yes. But I got 'CCCCC...', which is bootrom code for booting from UART. I couldn't get into USB0 booting mode. Jun 29 14:16:42 the default boot order is { eMMC, μSD, uart, usb } so it will show CCC before attempting to perform usb boot Jun 29 14:17:33 So, I have to disconnect UART, in order to be booted from USB0? Jun 29 14:18:00 Or change the order through GPIO pins? Jun 29 14:18:06 no, it just attempts to boot from uart and then continues with usb boot Jun 29 14:18:39 so it merely delays usb boot while it's trying to perform uart boot (which takes 3 seconds or so I think?) Jun 29 14:19:48 if you hold the S2 button during power-up (you can let go once the power led turns on) then the boot order becomes { spi, μSD, usb, uart } Jun 29 14:19:54 I have seen CCCCC, it stops for a while, then 'CCCCC..' again. Does that indicates UART/USB0 alternative? Jun 29 14:20:36 it'll probably do that if it's not even being enumerated by the usb host Jun 29 14:20:57 I *think* once it's enumerated it stops cycling, even if it's failing to usb-boot successfully Jun 29 14:21:40 Ok, let me try. But I don't seen anything indicating is the bootrom code booting from USB0 Jun 29 14:23:22 The microUSB (USB0) is connected to Windows PC. If Debian is booted from SD card, it have usb-Ethernet initiated on the PC (192.168.7.1). Jun 29 14:24:20 But bootrom for USB0, it never initidated usb-EThernet. The UART console, keeps displaying 'CCCCC..' Jun 29 14:25:32 I've just done a quick test, I can confirm that once it's been enumerated as usb device it should stop CCCing Jun 29 14:26:02 Can you share the steps you did? Jun 29 14:27:20 I saw some information on OCTVAO web site, it seems need to use STARTERWARE to download some code into RAM using JTag, then start USB0 booting. SO I am confused Jun 29 14:27:28 held down the S2 button (to bypass eMMC) and connected it to my laptop's usb port... it immediately showed up as usb device and I did not see any CCC on the uart (while I did see periodic CCC when I connected it to a usb power supply instead of my computer) Jun 29 14:27:50 that sounds like nonsense, link? Jun 29 14:28:58 however I have no idea if the usb gadget exposed by bootrom is understood by Windows... the usb stack of Windows is terrible and it's an eternal struggle to get it to recognize devices Jun 29 14:29:23 but on linux it Just Works Jun 29 14:30:08 The normal B'bone Black usb gadget is reconized. Jun 29 14:30:21 Ragnorok: that's completely unrelated though Jun 29 14:30:27 Okey doke. Sorry. Jun 29 14:30:52 and even that one periodically breaks when microsoft randomly changes something again Jun 29 14:30:54 But I couldn't duplicate yours. I unplugged UART and USB0. No Power to BBB. Then Press and Hold S2. Then Plug in USB0. The power LED lit. No usb0 is initiated on my PC Jun 29 14:31:15 david30: that's probably due to Windows then Jun 29 14:31:36 or rather, something about the bootrom rndis gadget that Windows doesn't understand or doesn't like Jun 29 14:31:39 Are you using Linux? Jun 29 14:31:42 yes Jun 29 14:31:52 Let me try Linux Jun 29 14:33:21 My Linux doesn't show 192.168.7.1 (2) Jun 29 14:33:52 I am using Ubuntu 16.04 Jun 29 14:33:52 nor would that be expected Jun 29 14:34:12 bootrom is not a dhcp server, it's a bootp client Jun 29 14:36:11 Sorry, I lost a bit. BBB is bootp client, Linux as DHCP server. I can ping 192.168.7.2 from Linux, if Linux has 192.168.7.1 as local IP? Jun 29 14:36:27 ? Jun 29 14:36:50 I have no idea what you mean Jun 29 14:37:06 How to access BBB's usb0 ethernet? Jun 29 14:37:22 what do you mean by "access" Jun 29 14:37:46 How to communicate with BBB through usb0? Jun 29 14:39:07 what do you mean by "communicate"? if the bbb is connected via usb and bootrom attempts usb0 boot then it should show up as a networking interface on your computer. your computer has to have a static IP assigned to that interface and it needs to run a bootp server (to give bootrom an IP and the information it needs for TFTP boot) and TFTP server (to serve the file that needs to run on it) Jun 29 14:40:31 (dnsmasq can perform both of those tasks at the same time) Jun 29 14:40:36 Sorry. I didn't see any networking interface on my Linux or Windows PC. I use ifconfig to check all networking interfaces on my Linux PC Jun 29 14:41:06 well I don't know what to say, I've never had trouble with it on any computer here, so I don't know what you're doing wrong Jun 29 14:42:57 https://pastebin.com/raw/QdtkSXci Jun 29 14:48:13 hmm, the "not running at top speed; connect to a high speed hub" is odd though Jun 29 14:49:14 I wonder if bootrom intended to be a full-speed device and just mistakenly has a high-speed qualifier, or if the highspeed communication is somehow failing and it's falling back to fullspeed Jun 29 14:50:19 easy enough to check with a scope if it's trying to negotiate high-speed Jun 29 14:57:23 that sounds like way more effort than I'm willing to invest into satisfying my curiosity Jun 29 14:57:35 full speed is fine for this application Jun 29 15:07:56 mru: I did find an e2e thread where a TI guy mentions bootrom is a full-speed device, so I guess it's just mistakenly claiming to be high-speed Jun 29 15:08:09 I'm having trouble matching up show-pins output with what's in the DTS. DTS uses the PADCONF macro & and names like "AM335X_PIN_UART0_CTSN", where show-pins doesn't. Jun 29 15:08:29 Ragnorok: oh yeah those macros are terrible Jun 29 15:08:50 naming a pin after one of the functions (not necessarily the one used) is really not great Jun 29 15:08:52 They sure don't see to have made more understandable. Jun 29 15:09:05 Wow. Missed some words there. Jun 29 15:11:10 Ragnorok: https://pastebin.com/raw/033KwkeP Jun 29 15:11:36 oh UART0, you're looking at non-expansion-header pins? Jun 29 15:11:44 So it looks like it just subtracts 0x800 from the pin #define value & ORs the last two parms. Jun 29 15:12:05 I'm looking at the DTS to get the sample "pin" listed above. Jun 29 15:12:26 I don't know if it's just the expansion header b/c the naming gives no clues. Jun 29 15:12:46 zmatt: getting _you_ to pull out the scope is reasonable effort for satisfying _my_ curiosity Jun 29 15:12:51 my spreadsheet (https://goo.gl/Jkcg0w) includes a column for names Jun 29 15:12:55 mru: lol Jun 29 15:13:08 I'll look. Thanks! Jun 29 15:13:33 and https://pastebin.com/raw/033KwkeP is what I extracted from that, restricted to just BBB expansion header pins Jun 29 15:14:45 Roit. Jun 29 15:15:16 Ragnorok: and 0x800 is the location of the pinconfig register-array within the AM335x control module Jun 29 15:16:26 so the register for pin 3 would be at offset 3*4=12 (0x00c) from the start of the pin config array, or offset 0x80c from the start of the control module, or physical address 0x44e1080c Jun 29 15:17:36 Also despite doing -vv I don't see any mcasp1 pin assignment, but I know it's done. Jun 29 15:18:09 uhh, -vv is just to show non-expansion-header pins Jun 29 15:18:12 like ethernet Jun 29 15:18:22 and the sd card slot Jun 29 15:18:26 Pin 3 would be the first row of the spreadsheet, just to verify. Jun 29 15:18:41 first row would be pin 0 Jun 29 15:18:49 Column. Sorry. Jun 29 15:19:03 Words are my friends today. Jun 29 15:19:07 with "pin" I mean the number in the first column yeah.. the one labeled "Pin" Jun 29 15:19:14 Cool. Thanks for verifying. Jun 29 15:19:26 How would I see where mcasp1 is configured? Jun 29 15:20:46 the only place where mcasp1 could be configured is on P9.42 (clk), P9.27 (fs), P9.41 (data 0), P9.25 (data 1) Jun 29 15:21:13 see also https://pastebin.com/raw/37Vr51Wr for notes on mcasp connections on the BBB Jun 29 15:21:14 Ok. Jun 29 15:21:25 Thanks! Jun 29 15:24:46 I should probably mention in that doc that the mcasp linux driver doesn't currently support asynchronous rx and tx (although I have a hacky patch for it) Jun 29 15:26:22 Pretty sure we don't need the Linux driver, we just need it to sit in the background and shuffle bytes around. One of the PRUs manages the data from there. Jun 29 15:26:22 Ragnorok: anyway, for pinmux blocks for expansion headers in your dts you should use the macros from Jun 29 15:26:46 Roit toe. Jun 29 15:27:30 ah you're using PRU as DMA controller for McASP instead of using ALSA ? I actually was also planning to do that but haven't gotten around to it yet Jun 29 15:28:13 That's for 1. 0 is a normal ALSA device. Jun 29 15:28:33 ok, yeah we only use one mcasp Jun 29 15:29:58 It's not really a DMA controller afaik. The mcasp1 is receiving a TDM frame from hardware codecs and fires an interrupt on frame receipt. The PRU services that and pulls in the frame for processing so the mcasp may continue to free-run. Jun 29 15:31:21 if "processing" is more than storing it somewhere then yeah, it's not really a DMA controller :) Jun 29 15:32:31 It is more. Both PRU are currently used, though one could do the job. I was ultra-conservative in my estimation of what a PRU could do b/c I'd never seen one before. Jun 29 15:34:06 audio processing on PRU seems like a bit of a chore though... Jun 29 15:34:24 Nah it wasn't hard. Jun 29 15:34:40 with its lack of signed arithmetic and somewhat awkward to use multiplier Jun 29 15:35:33 nothing insurmountable, but still Jun 29 15:36:05 it's something the cortex-a8 is definitely better at Jun 29 15:37:49 if you don't need the high part of the result, there's no difference between signed and unsigned multiplication Jun 29 15:38:12 true, but you almost certainly do want the high part Jun 29 15:38:53 depends on what you're doing Jun 29 15:39:41 but any proper audio processing would likely benefit from signed arithmetic at some point Jun 29 15:40:15 The hard part was figuring out how to do all this w/o a working mcasp while the other (now gone) dude noodled that. lol Jun 29 15:41:06 getting mcasp running isn't that hard Jun 29 15:43:15 For you I'm sure it's not. (wink) Jun 29 15:57:12 don't forget to stick ti,no-idle; onto &mcasp1; to ensure linux will keep mcasp1 enabled for you Jun 29 15:57:48 (it's generally a bad idea to have pru mess with prcm registers behind the kernel's back) Jun 29 16:25:10 zmatt: how would I know if FIFO overrun is causing a problem Jun 29 16:25:31 i wont get a hard crash of anything just lost data right Jun 29 16:26:15 lost data and the LSR_RX_OVERRUN error will be indicates Jun 29 16:26:18 *indicated Jun 29 16:27:45 ok Jun 29 17:02:05 In show-pins, the column output from $mux in the code is the mode? Jun 29 17:04:06 The readme says it's the "mux option", but in the DTS that would be the second entry in pinctrl-single.pins, which prior dude often comments as "MODE N". Jun 29 17:04:44 So if that second options is 0 in the DTS, show-pins should have a zero in that column. Jun 29 17:04:57 the second entry in pinctrl-single,pins is the entire pin config, bits 0-2 of which is the mux Jun 29 17:05:48 0 is PIN_OUTPUT_PULLDOWN | MUX_MODE0 Jun 29 17:05:50 Right. But if that's zero, the mux column should be zero. I'm not seeing that, which makes me wonder if I have the right dtb in. Jun 29 17:06:43 check /proc/device-tree/chosen/base_dtb Jun 29 17:07:09 pinmux can also be missing if the device that the pinmux is attached to failed to probe, or if the pinmux could not be selected due to conflict Jun 29 17:07:24 the latter would result in an error in your kernel log though Jun 29 17:07:31 the former usually too, depends a bit Jun 29 17:07:32 I'm sure it's the right name, it just may not be the one that corresponds to the DTS I'm looking at. I'm going to recompile and stick it back in. Jun 29 17:07:45 check /proc/device-tree/chosen/base_dtb_timestamp Jun 29 17:07:46 :) Jun 29 17:08:07 or you can also just find the actual pinmux node in /proc/device-tree/ Jun 29 17:08:42 Time stamp is way off. Good to know. lol Jun 29 17:11:02 Odd. When I look at the dtb on the device, it's not what the dtb timestamp says. It has the right date. Jun 29 17:11:34 did you accidently install your dtb into /boot/dtbs/$uname_r instead of /boot/dtbs ? the former takes precedence over the latter Jun 29 17:12:00 Ah. I have a backup of a dtb in there. D'oh. Jun 29 17:12:47 Never would have expected that behaviour, but knowing it makes a measure of sense. It also explains why things haven't been working like I expected. lol Jun 29 17:14:04 it definitely does make sense Jun 29 17:14:47 The thing that doesn't make sense is the chosen/base_dtb points to the one in uname -r, not the one it's using. Jun 29 17:15:37 what do you mean? Jun 29 17:16:29 if a dtb (with the name configured in /boot/uEnv.txt) is present in /boot/dtbs/$uname_r/ then that is the one that will be used Jun 29 17:16:37 otherwise it will look in /boot/dtbs/ Jun 29 17:16:50 I mean uEnv is pointing to the dtb in dtbs/, but b/c I had a dtb in dtbs directly, it loaded that other dtb. So it was using backup.dtb where base_dtb listed theNew.dtb. Jun 29 17:17:19 uhh what Jun 29 17:17:25 you're not making sense Jun 29 17:17:39 however do note that chosen/ just contains whatever is defined in the dtb that was loaded Jun 29 17:17:43 u-boot does not stick the filename there Jun 29 17:17:52 it comes from your source code Jun 29 17:18:02 I never said it did. I said chosen doesn't match the dtb it's running. Jun 29 17:18:10 that is not possible Jun 29 17:18:19 I disagree. Jun 29 17:18:29 Because I see it, right now, live. Jun 29 17:19:00 disagree all you want, it's literally impossible since /proc/device-tree is a view into the dtb that your kernel using Jun 29 17:19:17 and chosen/base_dtb comes from the dtb file itself Jun 29 17:19:27 What if the dtb doesn't have a chosen? Jun 29 17:19:36 then the property is absent Jun 29 17:20:24 Whatever. You don't have to believe what I see, and I don't care. What I do care is that I'm clearly not using the dtb I thought, I'm fixing it. Jun 29 17:20:26 it's not a property that has any meaning to u-boot or the kernel, it's just something rcn started putting into dts files to be able to more easily identify which is active Jun 29 17:20:55 And I appreciate you leading me to that conclusion. (grin) Jun 29 17:21:28 u-boot simply loads /boot/dtbs/$uname_r/$dtb or, if that is missing, /boot/dtbs/$dtb Jun 29 17:21:57 whatever was in the first of those two locations when you booted, that's your active dtb Jun 29 17:22:26 whatever was the chosen/base_dtb{,_timestamp} defined in that file when u-boot loaded it, that's what you will find in /proc/device-tree/chosen/ Jun 29 17:23:27 if that mismatches your mental model of what was where at what time, then your mental model of what was where at what time is at fault Jun 29 17:27:16 zmatt: is one of the issue you have with gpiod uAPI is that a line does not stay set after process exits? Jun 29 17:27:35 pdp7: that's definitely one of its problems yes Jun 29 17:29:02 there was just a GPIO talk at ELC from Bart, one of the maintainers Jun 29 17:29:05 pdp7: I commented on that near the bottom of https://liktaanjeneus.nl/gpio-discussion.html Jun 29 17:30:35 he suggested running a daemon Jun 29 17:30:40 pdp7: like, perhaps it can be useful for some applications if a gpio reverts to a specific default state (defined in DT) if the process using it dies, but it should be optional Jun 29 17:30:46 but i guess that would be a problem for the speaker scenerio Jun 29 17:30:50 if the daemon died Jun 29 17:30:55 and the lines reset Jun 29 17:31:03 the kernel just shouldn't mess with signals without being asked Jun 29 17:32:20 like I said, if I want some specific cleanup action I'll add an ExecStopPost to my systemd service Jun 29 17:33:35 but of all of gpiod's problem this is probably one of the less serious ones, it can be worked around (though I shouldn't have to) Jun 29 17:35:10 fortunately I don't have to anyway since the sysfs interface does exactly what I want, so I don't really have to care what the gpiod API I don't use looks like Jun 29 17:36:11 (I should say, the sysfs interface + gpio-of-helper) Jun 29 17:42:42 zmatt: the gpio co-maintainer Bartosz says he does not have a solution yet to your use case but that he will think about it. Someone from automotive said they have similar concerns to you Jun 29 17:42:47 thanks Jun 29 17:43:14 https://ossna2020.sched.com/event/c3TK Jun 29 17:43:19 if you're interseted Jun 29 17:43:26 pdp7: what do you mean by "my use case" exactly? Jun 29 17:43:31 slides https://static.sched.com/hosted_files/ossna2020/67/Linux%20GPIO-Evolution%20and%20Current%20State%20of%20the%20User%20API.pdf Jun 29 17:43:48 that lines resetting to defaults on fd close is not desired Jun 29 17:43:51 like I said, the gpio resetting thing is an annoyance but far from gpiod's greatest flaw Jun 29 17:43:55 and could cause a problem Jun 29 17:45:29 what I currently have (with sysfs-gpio + gpio-of-helper) is the ability to declare individual named gpios in DT and configure them (direction, initial output value if output, whether it's active-low or -high) Jun 29 17:45:53 and per-gpio access control through filesystem permissions Jun 29 17:46:21 userspace is not allowed to mess with any gpio unless explicitly declared in DT, and they're not allowed to change inputs into outputs Jun 29 17:46:40 (and they don't have to care about gpio numbers since they access them by name) Jun 29 17:50:58 Bartosz Golaszewski 9 minutes ago Jun 29 17:50:58 > @Drew Fustini (pdp7) sysfs probably won't go away if people are using it so we need to figure out some way for such use cases Jun 29 17:51:58 any thoughts about mainline solution for gpio-of-helper? Jun 29 17:52:13 it seems like a useful thing Jun 29 17:52:23 why was gpio-of-helper or something like it never accepted? I think people have tried Jun 29 17:52:43 like, iirc it could use some cleanup Jun 29 17:53:10 but probably people were already like "we're designing something better!" ... except the result isn't remotely better Jun 29 17:53:38 like, how gpio-of-helper works is inherently incompatible with how gpiod works Jun 29 17:54:05 since gpiod turns an entire gpio controller into a device, which is a silly thing to expose to userspace Jun 29 17:54:21 userspace cares about (specific) gpios, not about gpio controllers Jun 29 18:13:19 I have a case where I (sort of) care about a gpio controller Jun 29 18:13:47 yeah I should have inserted "typically" into that sentence Jun 29 18:14:16 it's a usb device with an i2c bus and a few gpios connected to an adc chip Jun 29 18:14:22 zmatt: i am having trouble finding one of your nice dts snippets where you define a name for a gpio line (like "rest"). I'm trying to show some people the benefit of that style Jun 29 18:14:40 pdp7: https://liktaanjeneus.nl/gpio-discussion.html in the second block there are links Jun 29 18:15:14 beware that that dts snippet uses my pinmux macros instead of those of mainline linux Jun 29 18:15:21 but that's easily adapter or ignored Jun 29 18:15:29 pinmux isn't the part that matters there anyway Jun 29 18:27:23 zmatt: have you seen gpio aggregator? it is new Jun 29 18:27:24 https://www.kernel.org/doc/html/latest/admin-guide/gpio/gpio-aggregator.html Jun 29 18:28:28 maybe this can do some of what you were talking about Jun 29 18:28:30 Example: If “door” is a GPIO-operated device described in DT, using its own compatible value: Jun 29 18:28:30 door { Jun 29 18:28:30 compatible = "myvendor,mydoor"; Jun 29 18:28:31 gpios = <&gpio2 19 GPIO_ACTIVE_HIGH>, Jun 29 18:28:31 <&gpio2 20 GPIO_ACTIVE_LOW>; Jun 29 18:28:32 gpio-line-names = "open", "lock"; Jun 29 18:28:32 }; Jun 29 18:29:07 on a side note, gpio-line-names is pretty messed up Jun 29 18:29:22 gpio-line-names = "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "foo"; Jun 29 18:29:22 that should just be gpio-names; Jun 29 18:29:30 in this case Jun 29 18:29:31 did I get the right number of ""? Jun 29 18:30:56 pdp7: like, either it should be gpio-lines and gpio-line-names or gpios and gpio-names Jun 29 18:32:32 pdp7: anyway, this seems to have some of the functionality, but still lacks critical parts Jun 29 18:32:54 pdp7: not having a standard compatible is already a fail Jun 29 18:33:44 pdp7: and it still can't configure the gpios Jun 29 18:34:27 especially being able to restrict direction is essential... without that any process with access to such a device basically has the CAP_DAMAGE_HARDWARE posix capability :P Jun 29 18:39:21 pdp7: at a minimum you need to be able to configure per gpio 1. whether its initial state is input, output-low, or output-high, and whether or not its direction may be changed. if you want to be fancy you might generalize the latter to a bitmap of which of the three states are allowed (so an open-drain pin would allow "input" and "output-low" but not "output-high") Jun 29 18:41:01 lol, I started making a numbered list and turned it into a single sentence. fail. Jun 29 18:49:30 pdp7: of course even if all this were done, question would still remain: what motivation is there to switch from something that works and is really simple to use by userspace applications in any programming language to something that does the same (if all shortcomings were fixed) but has a way more complicated API ? Jun 29 18:50:03 (requiring either complicated ioctls or the use of a library) Jun 29 18:50:55 i guess mainly it is that Linus W. thought sysfs was bad way to do it Jun 29 18:56:36 a chardev is nicer yeah, if it had been just as simple. a device for a single gpio (which is really what I want) could have been something like: after open() read 2 chars to get current output state ('0', '1', or '-') and line level ('0' or '1'), device becomes readable again if line level changes, change output state by writing '0'/'1'/'-' Jun 29 18:56:53 or something Jun 29 18:58:06 dunno Jun 29 18:59:57 like, the whole thing with cramming multiple gpios into a device and having to query their names and search through those to find the one you need is just ugh, userspace "requesting" a gpio (instead of DT doing so) is ugh Jun 29 19:01:44 the whole goal of a gpio userspace interface is basically to make a connection between a physical electrical signal and a piece of software. the declaration of this connection belongs in DT. userspace just needs a simple way to attach to it by name Jun 29 19:04:51 the gpio chardev is just not a good abstraction Jun 29 19:05:03 imho Jun 29 19:23:00 pdp7: actually, now that I've thought about it a bit, I really don't think a chardev would be any improvement over the sysfs interface Jun 29 19:25:15 like, having a few named attributes per gpio is just quite convenient and self-descriptive Jun 29 19:25:38 (although I'll admit the sysfs gpio interface is definitely not perfect) Jun 29 20:20:19 i2cdetect should show a device at an address regardless if a driver is loaded to use it, right? Jun 29 20:21:25 man i2cdetect see "INTERPRETING THE OUTPUT" Jun 29 20:21:35 also the WARNING above it Jun 29 20:21:49 i2cdetect also cannot always detect a device Jun 29 20:21:49 Silly me. Jun 29 20:22:06 in general, i2c is not a discoverable bus Jun 29 20:22:43 how to safely probe a device depends on the device, which i2cdetect obviously doesn't know Jun 29 20:24:36 so for each address it just guesses which of its two strategies to use and it hopes for the best Jun 29 20:25:09 I have two units with the same hardware, one running kernel 4.1 and one running 4.19. The old one gives different results for i2cdetect. Could that be a kernel thing? Jun 29 20:25:43 well the presence or absence of UU entries in the results will be dependent on your DT Jun 29 20:26:24 other than that one would expect the same results regardless of kernel version Jun 29 20:26:27 show-pins -vv is the same between them, but that mean enough. Jun 29 20:26:40 *may not mean enough. Jun 29 20:26:45 what kind of difference are you seeing? Jun 29 20:26:57 there's really no need to use -vv Jun 29 20:27:11 (shrug) I do anyway. Can't hurt right? Jun 29 20:27:20 phone Jun 29 20:27:23 irrelevant output doesn't benefit you Jun 29 20:27:53 the additional pins with -v are for signals that are internal to the BBB and not things you'd configure Jun 29 20:28:07 and the additional output from -vv is entirely pointless Jun 29 21:01:13 the v itself is pointy Jun 29 21:01:18 I can see what you're saying, but I simply compared the outputs, so the excess wasn't visible. When I got them to compare identical I moved on to i2c. Jun 29 21:01:43 okay, but anything added by -vv is simply not your concern Jun 29 21:01:58 that's for am335x-boneblack.dts to deal with Jun 29 21:02:22 I understand. Since they compare same I probably won't be using show-pins any longer, but if I do I'll be sure to avoid -vv. Jun 29 21:04:35 i2c0 is roughly the same for devices. One shows UU and one shows 34, but that just means the 34 doesn't have a driver. Jun 29 21:05:28 i2c1 shows four devices on the 4.1 kernel unit and no devices on 4.19 kernel unit. That seems bad to me. Jun 29 21:06:12 i2c2 shows 8 devices on the 4.1 kernel and four on the 4.19. The four are at least a subset of the 8. lol Jun 29 21:07:13 34 ? on i2c0 ? Jun 29 21:07:40 Yeah. Jun 29 21:07:57 -r 0 is i2c0, right? Jun 29 21:07:59 on a beaglebone black? Jun 29 21:08:14 Yup. Jun 29 21:08:49 The 4.1 kernel has a UU at position 34. I'm looking to see what drivers may not have loaded. Jun 29 21:08:59 the bbb has i2c0 devices at 0x24 (pmic), 0x50 (eeprom), and 0x70 (hdmi framer) Jun 29 21:09:03 nothing else Jun 29 21:09:13 so that makes no sense Jun 29 21:09:24 (shrug) Dunno. Want me to pastebin the output? Jun 29 21:09:44 also why are you using -r ? Jun 29 21:09:58 I thought that was how one determined the bus. Jun 29 21:10:11 no Jun 29 21:11:02 that's... weird.. Jun 29 21:11:07 If I don't use -r it says it can't do quick write on this bus. Jun 29 21:11:47 oh that's weird and broken... you can do arbitrary i2c transfers, including any type of smbus transfer Jun 29 21:12:18 Afiak it's always done that, where always is "since I've been working with it". Jun 29 21:12:54 interestingly it's not detecting the hdmi framer Jun 29 21:13:10 at the address it's declared to exist at Jun 29 21:13:27 It is. I see UU & 0x70. Jun 29 21:13:49 There are four devices, three at the addresses you indicated, and one at 0x34. Jun 29 21:14:04 hdmi framer isn't showing up here Jun 29 21:14:20 (I don't have hdmi enabled, but I'd still expect it to show up obviously) Jun 29 21:14:26 Roit. I see. Jun 29 21:14:56 okay 0x34 is a second address of the hdmi framer, used for the CEC core Jun 29 21:18:22 \o/ i2c 1's controller timed out. That's why it's blank, but i2c 2 doesn't have anything in dmesg. Jun 29 21:18:43 "i2c 1's controller timed out. That's why it's blank" what do you mean? Jun 29 21:19:19 a timeout just means 1 transfer failed Jun 29 21:19:27 not that the bus is now unusable or something Jun 29 21:19:29 i2cdetect is blank for i2c 1. It has the UU at 0x70 like they all do, but the four other devices that should be there aren't. Jun 29 21:19:33 Oh. Ok. Jun 29 21:19:58 "It has the UU at 0x70 like they all do" uhhhhhh what? Jun 29 21:20:11 Well 2 doesn't the 0x70 entry. 0 & 1 have always shown a UU there. Jun 29 21:21:19 the bbb itself has no devices on any bus other than i2c0, so anything on i2c1 and i2c2 will be things you declared Jun 29 21:22:28 Ok. If it's my device it's still at 0x70. I haven't gone through all the hardware to see what its addresses it. I'm thinking having the older unit for comparison is sort of doing that. Jun 29 21:22:38 well, and am335x-boneblack.dts declares devices 0x54-0x57 on i2c2 for the cape eeproms Jun 29 21:23:41 That's what's missing on i2c 2; 55-7. Huh. We aren't using those, afaik. Jun 29 21:24:20 okay, and if I enable hdmi and reboot, 0x70 shows up as UU, if I then disable it and reboot it shows up as 70 (since the kernel's initialization apparently makes it responsive to quick-reads, and a reboot won't reset the hdmi framer since it has no reset input) Jun 29 21:24:34 no, those are for cape autodetection Jun 29 21:24:46 Oh. And 0x73 is on the old 4.1 kernel but missing on the new 4.19. Jun 29 21:25:17 you could just disable those with &cape_eeprom0 { status = "disabled"; }; and ditto for &cape_eeprom1..3 Jun 29 21:26:01 (or just leave them, they shouldn't matter) Jun 29 21:26:12 I have no idea why the hdmi framer is active but the 4.1 kernel has it. Then again it has the cape things too. (shrug) I guess I should go through all the hardware datasheets and see what addresses belong to my bits, and why. Jun 29 21:26:41 well you said you weren't using the pins that conflict with hdmi video, so maybe your old dtb didn't bother disabling it? Jun 29 21:26:58 That's what I'm thinking. Jun 29 21:27:14 and if you're switching back and forth between a dtb that has the hdmi framer and one that doesn't, you'll see 0x70 in i2cdetect Jun 29 21:27:20 I'm going to keep it active and when all is said and done I'll disable it and if it breaks. Jun 29 21:27:44 though if you then power-cycle, it'll be gone, since apparently when the hdmi framer is in its reset state it's undetectable by i2cdetect Jun 29 21:27:46 I'm not; I see UU there in both. Jun 29 21:28:01 which is a good reminder that i2cdetect does not always work Jun 29 21:28:19 I mean, if you're not using hdmi you should disable it Jun 29 21:28:27 at the bare minimum you _need_ to disable hdmi audio Jun 29 21:28:38 since you're using mcasp0 for other purposes Jun 29 21:29:30 If hdmi audio is disabled will that change the output of show-pins? Jun 29 21:29:36 yes Jun 29 21:29:40 I mean Jun 29 21:29:49 those pins should be claimed by whatever _you_ are doing with audio Jun 29 21:29:53 which will conflict with hdmi audio Jun 29 21:30:22 the pins might show up similarly configured in show-pins (depending on how you need it to be configured) Jun 29 21:30:40 I understand, but right now the output of show-pins matches between the 4.1 & 4.19 kernels. I'm taking that to mean it's "ok", and perhaps what I said before is inaccurate. Jun 29 21:31:14 that's really not an adequate criterium for "ok" Jun 29 21:31:48 you're not using hdmi, so if those pins are used by hdmi audio then your audio stuff is broken, regardless of whether the pins are muxed right or not Jun 29 21:32:52 Afaik that's the audio playback section. If it's broken I'll find out when I get far enough to try to play out the audio jack. Jun 29 21:34:13 it is broken as long as you have hdmi audio enabled, since it's using the hdmi framer as codec Jun 29 21:34:18 instead of your actual codec Jun 29 21:35:29 Ok. Since I don't even have a sound device defined yet it's not likely to matter. I'm trying to get all the i2c bits functioning first. 95% of the system runs over i2c. Jun 29 21:36:17 again, you're using using the hdmi port, so you should disable hdmi to avoid confusion. lines 14-19 of https://pastebin.com/b60VG5Ys should accomplish that Jun 29 21:37:53 to get audio working then you need to replace the &mcasp0 { status = "disabled"; }; by a block that configures it right for your application, you need your codec declared on the appropriate i2c bus (assuming it's an i2c device), and you need to create a new /sound node (after having deleted the old one) to glue things together Jun 29 21:38:31 (i.e. something along the lines of https://pastebin.com/CN6UPm1P ) Jun 29 21:39:45 The old dts doesn't explicitly declare the codecs, but they're on a mux that's on i2c 1. That mux shows the extra busses but does not appear in the i2c 1 device list. Jun 29 21:40:25 I mean, it needs to, otherwise how would alsa know to configure them? Jun 29 21:40:42 an i2c mux doesn't really change anything afaik, it just creates a bigger bus Jun 29 21:40:44 I've been wondering that myself, truthfully. Jun 29 21:41:04 the codec is also explicitly referenced from your /sound node Jun 29 21:41:11 it needs to exist as device Jun 29 21:42:08 Right. But that can't work, even if its in the dts, if the mux doesn't show up on the i2c bus, can it? Jun 29 21:42:19 nope. what kind of mux is it? Jun 29 21:42:29 Let me find the datasheet. Jun 29 21:42:41 like, what compatible-string Jun 29 21:42:46 what part number Jun 29 21:43:00 nxp,pca9544 Jun 29 21:47:42 https://elixir.bootlin.com/linux/v4.19.130/source/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt Jun 29 21:47:57 seems straightforward enough Jun 29 21:48:18 That's a lot more than the old or new dts has. Jun 29 21:48:31 well it's just giving an example Jun 29 21:49:04 though... a _lot_ more? like, this example seems pretty minimal apart from the interrupt declaration being optional Jun 29 21:49:13 I'm thinking the children are devices on the mux bus. Jun 29 21:49:31 yes, i2c@2 and i2c@4 in that example are the two child-buses Jun 29 21:49:38 and the eeprom and rtc are example devices on those buses Jun 29 21:50:05 Ok. I don't have those. Could be why no devices. lol I'll see if I can find any ref to what might have to go there. Jun 29 21:50:22 Still I would expect the mux itself to be there and it's not. Jun 29 21:50:25 that should be in your old dt Jun 29 21:50:35 have you checked the kernel log for errors? Jun 29 21:50:39 or maybe you just misdeclared it Jun 29 21:51:19 I looked in the journal. I haven't checked kern.log directly. Jun 29 21:51:28 journalctl -k yes Jun 29 21:51:32 that's the kernel log Jun 29 21:52:01 if you have /var/log/kern.log that just means you forgot to apt-get remove rsyslog, or you have some old logfiles still in /var/log/ :P Jun 29 21:52:03 I did -b thinking that gives everything since this boot. Jun 29 21:52:08 it does Jun 29 21:52:18 Ok. Only that timeout then. Jun 29 21:52:28 what's the actual error? Jun 29 21:52:45 Let me find it again. Jun 29 21:53:38 kernel: omap_i2c 4802a000.i2c: controller timed out Jun 29 21:54:08 weird error, lemme see what exactly that means Jun 29 21:54:23 Ah. I think that's from my i2cdetect. It's in the log after I've logged in. Jun 29 21:55:42 okay so i2cdetect possibly broke your bus? Jun 29 21:56:35 No other i2c errors of any kind. Dunno. I'm learning about i2c as I go along. I could reboot and probe the mux address to see if it responds. Jun 29 21:56:36 or the bus was already broken and i2cdetect noticed that (but if it's the first to notice then that would mean the kernel hasn't tried to probe any device on that bus) Jun 29 21:57:17 rebooting is very unlikely to unwedge wedged i2c devices Jun 29 21:57:29 Clearly it knows the mux is there b/c it addes the busses. Jun 29 21:57:54 so why did you say the "mux doesn't show up on the i2c bus" Jun 29 21:57:57 I mean power cycle reboot. I almost never just reboot. Jun 29 21:58:25 it won't add the child buses unless it has been able to talk to the mux Jun 29 21:59:30 Roit. I said the mux doesn't show up b/c it should be at 0x20 on i2c 1, and I have nothing at that slot. Jun 29 22:00:05 0x20 ? datasheet disagrees Jun 29 22:00:13 Ok. What does it say? Jun 29 22:00:40 I looked and couldn't find addressing data. I have it open right here. Jun 29 22:00:42 between 0x70 and 0x77 depending on the A0-A2 lines Jun 29 22:01:20 What page is that on? I want to know how I missed it. Jun 29 22:01:47 https://www.nxp.com/docs/en/data-sheet/PCA9544A.pdf section 6.1 on page 6 Jun 29 22:02:29 I hope this is the right device, plain PCA9544 without the A doesn't really seem to exist anymore Jun 29 22:03:39 I detest how things ignore where I told them to download put them in some pre-defined place. Jun 29 22:04:19 That is exactly the datasheet I have. I still don't see it. I must be blind. Jun 29 22:04:41 Oh. I see it. I am blind. Jesus. Jun 29 22:04:45 lol Jun 29 22:04:57 literally the first thing in the functional description Jun 29 22:05:00 with a nice diagram Jun 29 22:05:28 Yeah. So that's where the other 0x70 comes from and it is there. I probably just need to put the children in and it'll be betterer. Jun 29 22:06:04 and if you have the reset line and/or irq line hooked up in your schematic, you should declare those too probably Jun 29 22:06:27 I'll check and see. Jun 29 22:07:17 and if you have more than one mux on the same i2c bus you'll want to add the i2c-mux-idle-disconnect; property Jun 29 22:07:28 There's just the one. Jun 29 22:07:35 then you don't need to Jun 29 22:12:06 The dcomp of the 4.1 kernel dts doesn't have children under i2c1, it has entries for the add'l busses the mux adds. Jun 29 22:12:14 dts -> dtb Jun 29 22:14:09 When I search what I think are the dts for the 4.1 kernel, no such configuration exists anywhere. I've not trusted this is the actual dts for some time, do to so many discrepancies between dcomp'd dtb & this "source". Jun 29 22:15:32 "doesn't have children under i2c1, it has entries for the add'l busses the mux adds" ... ehh but those busses are children of the mux, which is a child of i2c1, so that sentence makes no sense to me Jun 29 22:17:12 Ok. It's not i2c@addr { child { } }. It's i2c@addr { } i2c@otheraddr { what would be child is here } Jun 29 22:19:09 sorry, that's not helping Jun 29 22:20:17 but, if you're in doubt about the reality of the situation, maybe just try to focus on the schematic as primary guideline rather than the suspected-not-the-actual-dts Jun 29 22:20:42 Ok. https://pastebin.com/nUn49bNf Jun 29 22:21:21 i2c3 is a bus on the mux. Jun 29 22:22:42 nah that's just i2c2 with inexplicably off-by-one numbering Jun 29 22:23:02 i2c@4802a000 is &i2c1, i2c@4819c000 is &i2c2 Jun 29 22:23:26 Huh. Ok. Jun 29 22:23:30 the mux as declared has no child devices and is pointless Jun 29 22:24:12 unless maybe the child busses implicitly show up in userspace (without being declared in DT) and all devices on each bus are just accessed from userspace without a specific kernel driver Jun 29 22:24:44 That may be what's going on b/c the old kernel has numbers, not UU. Jun 29 22:25:26 The new kernel has nothing, though. Jun 29 22:25:47 do the child buses show up or also not? Jun 29 22:26:08 They do in /dev, but detect empty. Jun 29 22:26:22 curious Jun 29 22:26:34 I think it's timing out on access. There's a pause before it shows empty. Jun 29 22:29:17 does sudo i2cget -f -y 1 0x70 work? Jun 29 22:29:44 Read failed. Jun 29 22:29:55 well that's not good Jun 29 22:31:02 if you do a power-cycle and then try that command? Jun 29 22:31:55 Equally curious, the old 4.1 kernel has no module loaded, but the 4.19 kernel does. Jun 29 22:32:14 might be compiled-in on the old kernel? Jun 29 22:32:57 grep CONFIG_I2C_MUX_PCA954x /boot/config-* Jun 29 22:33:03 I'll see if I can find out. Would it load the same code on a module? Maybe that's different? Jun 29 22:34:13 Yup. Has y on old and m on new. Jun 29 22:34:27 so, nothing unusual there Jun 29 22:34:59 It should be the same code though, right? Just one is dynamic and one isn't. Jun 29 22:35:02 I'm assuming the i2cget works after power cycle? it sounds to me like the bus is locking up as a result of scanning (or possibly merely switching to) one of the child buses Jun 29 22:35:07 yes that won't matter Jun 29 22:35:11 Sorry. Let me do that. Jun 29 22:36:38 maybe your new dts is still lacking something that some device on one of the child buses needs to not lock up the bus, something like that Jun 29 22:36:41 Yup. Jun 29 22:36:57 ok hold on Jun 29 22:37:19 since we can also try switching to each child-bus individually... are they all in use? Jun 29 22:37:32 Only the first two afaik. Jun 29 22:37:43 That should be 3 & 4. Jun 29 22:38:07 why 3 and 4 ? o.O Jun 29 22:38:17 I should see devices at 18, 1d, 20, & 21. Jun 29 22:38:57 Dunno. The mux adds i2c3 through i2c6. Stuff appears on i2c3 & i2c4, on the unit with the old 4.1 kernel. Jun 29 22:39:09 oh, those bus numbers are arbitrary Jun 29 22:39:22 unless you use /aliases to fix them Jun 29 22:39:42 but right now the linux bus numbers don't matter, the hardware ones do Jun 29 22:39:54 so eh, lemme think how to do that i2c transfer Jun 29 22:40:48 Are /aliases in the dts? Jun 29 22:40:57 sudo i2cset -f -y 1 0x70 0x04 selects bus 0 Jun 29 22:41:10 (then do the i2cget again to check if it still works) Jun 29 22:41:29 and then 0x05 selects bus 1 Jun 29 22:41:37 Yup. 0xf4 now instead of 0xf0. Jun 29 22:41:57 5 is write fail. Jun 29 22:42:07 and finally 0x00 to deselect again Jun 29 22:42:12 Which makes 4 write fail. Jun 29 22:42:31 i2cset -f -y 1 0x70 0x05 fails? Jun 29 22:42:35 He's dead, Jim. Jun 29 22:42:44 That line killed it. Jun 29 22:42:54 With a write fail, yes. Jun 29 22:43:15 interesting that even the write itself fails.. I'd have assumed any bus lockup would be _after_ the write Jun 29 22:43:21 i2cset -f -y 1 0x70 0x05 Jun 29 22:43:21 \nError: Write failed Jun 29 22:44:20 ohh it's like, actually an analog mux... the child-bus is electrically connected to i2c1 Jun 29 22:44:49 so if the child-bus is fucked at that time, you lose i2c1 as well and now you can't reach the mux anymore either Jun 29 22:45:00 Lucky me. Jun 29 22:45:13 so... was the mux's reset line wired up? ;) Jun 29 22:45:19 Let me look. Jun 29 22:45:50 let me check if there's an easy way to check in what state the bus is stuck Jun 29 22:46:35 Doesn't look like it, sadly. Jun 29 22:50:50 okay maybe the quickest way to check the lines (other than grabbing a multimeter) is by using https://liktaanjeneus.nl/pinmux.tar.gz to forcibly set the i2c1 pins to gpio mode Jun 29 22:51:01 (and then export them and show-pins will show their state) Jun 29 22:51:53 I have a DMM, an o'scope, and logic analyzer. I can hook things up. Jun 29 22:52:07 whichever you prefer Jun 29 22:53:11 e.g. my pinmux util can be used as sudo ./pinmux --mode 7 P9.24 P9.26 or whichever pins you use for i2c1 Jun 29 22:53:19 (it also accepts pin numbers) Jun 29 22:54:00 If it's hosed it won't change, right? Jun 29 22:54:05 (and shows help if run without arguments... though not if run with --help, I should probably fix that) Jun 29 22:54:15 what do you mean? Jun 29 22:54:33 if it's hosed there's probably no way to fix it, otherwise the kernel would already have succeeded in doing so Jun 29 22:54:53 but using gpio mode lets you see whether scl is stuck low or sda Jun 29 22:54:55 If I hook up a tool (dmm, etc) it'll show steady-state voltage? Jun 29 22:55:14 if you're not doing any (attempted) transfer, yep Jun 29 22:56:07 I'm attempting to discern how the tool will tell me if the bus is stuck. Jun 29 22:56:20 well normally sda and scl will both be high when idle Jun 29 22:56:33 Ok. So one will be low. Jun 29 22:56:52 yep, which you can either measure with a multimeter or using gpio mode Jun 29 22:57:25 Okey doke. Jun 29 22:58:56 so the big question remains why this isn't happening on your old kernel... and the answer will no doubt lie in whatever devices are on that child bus and how the beaglebone might be affecting those in a way that makes things go wrong Jun 29 22:59:23 Roit. Jun 29 22:59:24 e.g. a power supply disabled by a gpio, a clock that's not provided, a reset line kept asserted, stuff like that Jun 29 23:00:30 Could be clock. The hardware codecs are mux'd. I know there was some issue w/ clocks to get it all working initially. Jun 29 23:01:18 oh, that can be easily tested Jun 29 23:01:36 hold on Jun 29 23:02:20 So I tried pinmux b/c I didn't want to hunt down where P9.24 is. Sure it's easy, but typing is even easier. lol Both 24 & 26 show "up". Jun 29 23:02:31 that's the pull Jun 29 23:02:40 to show the gpio state you also need to export the gpios Jun 29 23:03:25 so ehh... echo 14 >/sys/class/gpio/export Jun 29 23:03:27 and ditto 15 Jun 29 23:03:50 now show-pins should show their level (as << hi or << lo after the gpio) Jun 29 23:04:16 Both hi. Jun 29 23:04:21 huh Jun 29 23:04:46 Read 0x70 still fails. Jun 29 23:04:51 yet the mux is unreachable? that's going on on that bus Jun 29 23:05:33 just checking, you _are_ using those pins for i2c1 right, and not P9.17/18 ? ;) Jun 29 23:06:21 let's see if we can test the audio clock hypothesis Jun 29 23:06:26 does echo $((1*32+27)) > /sys/class/gpio/export work? Jun 29 23:07:18 Sorry. It is 17 & 18. So do all that w/ P9_17 & 18 then. Jun 29 23:07:43 lol Jun 29 23:08:06 What export numbers do I use? Jun 29 23:08:48 show-pin should show the gpio numbers Jun 29 23:09:06 4 and 5 Jun 29 23:09:25 Ah. That's what that is. Thanks. Jun 29 23:10:01 Both "lo". Jun 29 23:10:06 oof Jun 29 23:10:46 so, can you export gpio 59 ? (==1*32+27 for gpio 1.27) Jun 29 23:11:07 and assuming success, echo high >/sys/class/gpio/gpio59/direction Jun 29 23:13:11 Direction was out, after high still says out. Jun 29 23:13:46 ok yeah, writing "high" to direction sets it to output high level Jun 29 23:13:54 a bit counterintuitive Jun 29 23:14:39 normally you'd read/write the value instead of the direction, but I just wanted to ensure direction was set to output Jun 29 23:14:57 anyway, now the audio osc is enabled, maybe that unwedges i2c1 ? Jun 29 23:15:36 if at least one of the two lines has gone high you can try configuring the pins back to --mode 2 and see if the bus works again Jun 29 23:15:36 Nope. I've been at this over 11 hrs. I think I may hook up the logic analyzer tomorrow morning and go from there. As always, your time is greatly appreciated! Jun 29 23:15:56 bummer Jun 29 23:16:17 Mode 2 had no effect. Jun 29 23:16:31 But I'm off. Have a great part of day! Jun 29 23:16:50 instead of logic analyzer (which probably isn't useful) I'd suggest examining the schematic Jun 29 23:16:51 Ragnorok: keep pounding Jun 29 23:16:56 and good night! Jun 29 23:22:42 i saw an article on arm going into apple computers Jun 29 23:22:46 if you are going to learn a chip Jun 29 23:22:50 is ARM the best one Jun 29 23:22:54 or the most dominant Jun 29 23:22:58 in the market Jun 30 00:10:15 i feel like the answer to that depends a lot on your goals, but arm is successful, trendy, and has a fair amount of inertia at the moment. Jun 30 00:13:12 the "embedded" space remains hot, if the number of recruiters reaching out is an indication Jun 30 00:34:34 for jobs Jun 30 00:34:36 ? Jun 30 00:34:48 that is neat Jun 30 01:00:10 are there a lot of recruiters Jun 30 01:00:13 i wish ppl appreciated me Jun 30 01:00:19 it's that drop out stigma Jun 30 01:09:01 you dropped out Jun 30 01:09:05 ? Jun 30 01:18:31 I dropped out Jun 30 01:21:36 really Jun 30 01:21:41 of what Jun 30 01:21:44 from what Jun 30 01:21:54 university, math & cs Jun 30 01:22:05 never would of guessed Jun 30 02:17:21 How can I set up UART5 on my BBBW? Jun 30 02:17:33 I am trying to help some stranger that is having trouble. Jun 30 02:18:27 I tried config-pin, make in /opt/source/bb.org-overlays/src/arm/, and using the u-boot overlays section for Capes. Jun 30 02:19:57 It seems that I am receiving a file error. Jun 30 02:22:12 Never mind me. I got it. Jun 30 02:22:13 Sheesh. Jun 30 02:33:02 there's no need for overlays, just use config-pin (after disabling video in /boot/uEnv.txt) Jun 30 02:40:50 Okay. Got it. Jun 30 02:40:54 That is what I figured out. Jun 30 02:41:01 disable video! Jun 30 02:41:15 I told the fellow. Hopefully, the fellow can use it. Jun 30 02:42:25 The person thought that disabling/uncommenting audio should do it. I told him/her that it had to be video. Jun 30 02:43:02 I even tested both to make sure. I tested all three avenues. Jun 30 02:43:14 P8.27-46 are used by video if enabled Jun 30 02:43:23 which are also the pins where uart 5 lives Jun 30 02:48:05 Right. Jun 30 02:48:28 So, if this person needs to use video for some reason, there is not a way to use UART5. Jun 30 02:48:46 one or the other. GOt it. Jun 30 02:50:54 I noticed the fellows /boot/uEnv.txt file is different compared to mine. he has capemgr for some reason. Is that a "bringin' it back" thing these days? Jun 30 02:55:43 no Jun 30 02:55:55 that probably means he's running an ancient system Jun 30 02:56:26 He is using the updated image from he stated. Jun 30 02:56:32 Let me show you the link. Jun 30 02:56:57 https://stackoverflow.com/questions/62645009/beaglebone-black-no-slots-while-enable-uart/62649347#62649347 is what this fellow is saying. Jun 30 02:57:49 I noticed something on google groups that made me think that capemgr is back for those who would like to try it. Jun 30 02:57:53 Let me see if I can find it. **** ENDING LOGGING AT Tue Jun 30 02:59:57 2020