**** BEGIN LOGGING AT Thu Sep 22 02:59:57 2022 Sep 22 07:52:02 NishanthMenon: hmm not sure I get you. This means that there is an upstream kernel+dtb suitable for the ai64, but not in the ti kernel? which in turn means, there is no recipe for it yet? Sep 22 11:50:16 LetoThe2nd: https://lore.kernel.org/linux-arm-kernel/20220921021300.4111283-1-robertcnelson@gmail.com/ we haven't pulled it back to TI kernel(rev 3 is recent). Correct, there will not be a support for it. When it does get done, it will be MACHINE=j721e-evm Sep 22 11:52:31 LetoThe2nd: I will try and see if I can backport the patches to TI tree and get some basic support in meta-ti Sep 22 12:15:32 NishanthMenon: well redirecting to a mainline kernel, I think I can manage that. Sep 22 12:16:36 LetoThe2nd: I think the new rev is so new, I don't think it has been merged upstream yet. Sep 22 12:16:52 NishanthMenon: ok understood Sep 22 14:35:33 zmatt: hi! About the mini usb configured as host, it worked, but sometimes it doesn't, it seems spurious. You mentioned the vbus of the port, is there something I should configure in the device tree for that? I don't understand why it'd work sometimes, sometimes not. Sep 22 14:38:12 if vbus isn't present then it will not "work sometimes", it will just not work Sep 22 14:38:21 at all Sep 22 14:38:47 if you're having problems, I suggest you check kernel log Sep 22 14:41:01 there is nothing else to configure in DT, any remaining issues will most likely be hardware-related Sep 22 14:44:23 in some sense it's surprising it works at all, given that this usb controller is designed as an OTG controller and normally uses the ID pin to determine the port mode and normally expects to be able to switch vbus power itself (with close monitoring of the vbus voltage)... I'm not sure how the kernel driver manages to bully the usb controller into working in host mode (in contradiction to the ID pin) ... Sep 22 14:44:29 ...with a fixed non-switchable vbus Sep 22 16:39:09 Good evening Sep 22 16:40:40 There's a blog article about ethernet Phy not being able to be addrssable on power up, i never seem to experience this issue, is this actual or addressed, has someone got hit with it ? Sep 22 16:40:42 https://wp.josh.com/2018/06/04/a-software-only-solution-to-the-vexing-beagle-bone-black-phy-issue/#comment-32267 Sep 22 16:42:01 jfsimon1981: so, there are various issues the phy can have. sometimes it's merely on the wrong phy address, that part has been fixed (or worked around rather) in software a long time ago Sep 22 16:42:55 the phy can also be completely non-operational, that part can't be fixed in software (the workaround in that blog port is hazardous and should not be used) Sep 22 16:43:33 we occasionally hit it and implemented an external workaround to reduce the probability Sep 22 16:43:39 really that's lucky i don't rely on it Sep 22 16:43:54 Not very good though Sep 22 16:44:12 yes i see. Sep 22 16:45:20 bbb rev c3 also includes a reset line to the phy which means a complete fix could be implemented in u-boot now Sep 22 16:45:30 I don't know if such a fix has been implemented yet Sep 22 16:45:30 ok Sep 22 16:45:39 i'll check it Sep 22 16:45:40 (I don't think it has) Sep 22 16:48:26 you mean tied to to the main sys reset Sep 22 16:48:43 so the chip resets itselfs to get the phy to reset too. Sep 22 16:48:57 no, there's a gpio to the ethernet phy reset Sep 22 16:49:06 ah Sep 22 16:49:18 the phy reset tied to the chip reset is what's been causing the problem Sep 22 16:49:44 (apparently due to the slow rise time of the chip reset as a result of the ridiculously large capacitance on it) Sep 22 16:51:02 ok 0.1u, like a bypass cap Sep 22 16:51:16 no there's a much larger cap Sep 22 16:51:50 unless that got removed in C3 Sep 22 16:52:07 i'll get( latest schematic Sep 22 16:52:15 I'm on c rev now Sep 22 16:52:54 they did change it! Sep 22 16:53:02 "Changed C24 from 2.2uF to DNI" Sep 22 16:53:24 I didn't realize that Sep 22 16:54:35 ok Sep 22 16:54:55 That's a great news Sep 22 16:55:11 rcn-ee: has an ethernet phy reset on rev C3 (using the gpio) been implemented in u-boot? with C24 gone, the reset pulse at power on is technically too short for the phy (shorter than that's mandated by the datasheet) Sep 22 16:56:05 *what's mandated Sep 22 16:56:22 they worked this out it looks Sep 22 16:56:58 GPIO 1_8 Sep 22 16:57:04 and system reset Sep 22 16:59:20 i only see a 100n on sys_resetn (C30) therefore 0.1u Sep 22 16:59:56 ideally phy reset would not have been connected to sys_resetn at all, but I guess they wanted to keep that for backwards compatibility Sep 22 17:01:00 Though i don't quite get it, the software is supposed to reset the ethernet PHY is unresponsive ? Sep 22 17:02:28 technically with the new C3 design u-boot ought to reset the phy at least once. I don't know if the phy problem can still occur with this new design, but in case it does happen u-boot could reset the phy again until it *does* respond Sep 22 17:03:44 Basically the and gate is a shlmitt trigger Sep 22 17:03:51 means the output has fast rising edge Sep 22 17:03:56 yeah indeed Sep 22 17:04:12 that may have taken care of it so Sep 22 17:04:20 which is why it's a bit weird they also removed C24 ... I would have kept C24 in this case Sep 22 17:05:04 since the AND gate already cleans up the edge, and C24 would make sure the power-on reset time meets the phy specification Sep 22 17:05:11 perhaps why i never noticed it, i run the project since november 2021, they revised it april 2021 Sep 22 17:05:54 I see DNI stands for do not install Sep 22 17:06:00 correct Sep 22 17:08:07 C24 was there to prevent spurious reset i think Sep 22 17:08:19 2.2 micro is very high i guess Sep 22 17:08:20 no, it was to extend the reset timing to meet the phy spec Sep 22 17:08:40 the reset pulse duration from the pmic is technically insufficient Sep 22 17:08:57 ok Sep 22 17:09:45 there's a C147 there Sep 22 17:09:48 4.7 uF Sep 22 17:10:32 which should absolutely not be there Sep 22 17:11:10 I don't understand why it is there Sep 22 17:11:25 It's an open drain gate Sep 22 17:11:29 they should have used a nand gate with push-pull output Sep 22 17:11:41 When open it charges theough r33 Sep 22 17:12:07 I guess that does extend the reset time again Sep 22 17:12:37 but it also again exposes the phy reset to a slow rising signal, which appears to have been the cause of the original issue Sep 22 17:13:20 indeed with an open drain the ground time is a fast edge, rise time is an RC constant Sep 22 17:13:35 I dunno, the root cause of the phy issue has never been understood, maybe this different reset circuit happens to fix the problem Sep 22 17:13:51 It was 0.1u not it is 4.7uF Sep 22 17:14:00 C24 was 2.2uF Sep 22 17:14:21 or what do you mean? Sep 22 17:14:39 2.2u yes Sep 22 17:14:52 yeah so now it's an even slower rise time Sep 22 17:15:43 in the testing I've done with a beaglebone that prominently suffered from this problem I found a clear correlation between reset rise time and probability of phy failure: the slower the rise time, the higher the probability of failure Sep 22 17:16:51 Is reset high or low active ? Sep 22 17:16:55 active low Sep 22 17:17:05 see also my comment on that page you linked earlier: https://wp.josh.com/2018/06/04/a-software-only-solution-to-the-vexing-beagle-bone-black-phy-issue/#comment-31992 Sep 22 17:19:09 yes Sep 22 17:20:12 So the RC time constant owed to be at sys_resetn input of the gate somehow Sep 22 17:20:34 if i understand right the concern about pulse duration. Sep 22 17:20:35 ehh I can't parse that sentence Sep 22 17:20:56 To extend properly the reset at ethernet phy and get fast edges Sep 22 17:21:12 (note that the NAND gate is new in rev C3, and this comment was written before then) Sep 22 17:21:26 not using an open drain, instead have rc at the input B for example Sep 22 17:21:39 that would extend the pulse and give it fastt edge. Sep 22 17:21:46 yes in rev c3 Sep 22 17:21:52 I'm lost at what you're saying Sep 22 17:23:12 you mention the phy ethernet needs a fast reset pulse with a certain duration Sep 22 17:23:31 which is why they used c24 and now c174 Sep 22 17:24:16 if rc is on input side of the gate, with a shitt trigger there's fast edge Sep 22 17:24:52 c174 ought to be on input of the gate, if i understand the issue. Sep 22 17:25:17 they could have left C24 and just used a push-pull NAND gate Sep 22 17:25:26 yes the same Sep 22 17:25:38 except you couldn't reset the phy Sep 22 17:25:43 ? Sep 22 17:25:49 yes you could, via the NAND gate? Sep 22 17:25:53 GPIO1_8 now allows it Sep 22 17:25:57 that's the whole purpose of the NAND gate Sep 22 17:26:10 yes sorry Sep 22 17:26:26 I mean just an inverter would be fine, no need for a GPIO Sep 22 17:26:32 ?? Sep 22 17:26:56 ehh, AND gate Sep 22 17:27:01 it's an AND gate, not a NAND obviously Sep 22 17:27:07 I'm not sure the gpio reset is required Sep 22 17:27:17 if that's just for that bug Sep 22 17:27:21 the purpose of the gpio reset is to be able to reset the phy if the issue happens again Sep 22 17:27:43 with the gpio reset you at least know that should there be any further problems, they can be worked around in software Sep 22 17:28:18 yes, though it's multiplexed Sep 22 17:28:26 ? Sep 22 17:28:43 GPIO1_8 is used for something is it not Sep 22 17:28:48 no Sep 22 17:29:42 it was not-connected on previous BBB revisions Sep 22 17:29:46 indeed Sep 22 17:30:01 It was NC my mistake Sep 22 17:31:55 there must be something else Sep 22 17:32:06 "The Pin19 nRST (ETH_RESETn) of PHY Sep 22 17:32:06 LAN8710A is Schmitt trigger input type." Sep 22 17:32:20 yeah it makes no sense Sep 22 17:32:25 Means there shouldn't be any issue with slow rise at the pin input Sep 22 17:32:36 and yet, that is what I observed in actual testing Sep 22 17:32:51 Ok Sep 22 17:33:01 ¯\_(ツ)_/¯ Sep 22 17:33:43 You mean they made it worse, but i have never had any issue, or maybe didn't notice it Sep 22 17:34:03 I don't think I've observed it with the new setup either, which makes things all the more mysterious Sep 22 17:34:08 but I've also not been looking for it Sep 22 17:34:13 At least it can be reset too, that's something good Sep 22 17:34:24 yep Sep 22 17:34:39 I *think* our devices collect statistics on it, I'll need to ask the other devs about this tomorrow Sep 22 17:35:17 ok Sep 22 17:35:55 it's interesting if you can share this info Sep 22 17:36:08 if that's at all possible of course Sep 22 17:38:32 i'm not too confident with all this, Sep 22 17:39:28 i had an issue with PRU driver of some sort, a quadrature encoder to mess with the PWM so that you helped me disable it, it was doing random kernel panic Sep 22 17:39:56 yeah the buggy out-of-tree eqep driver Sep 22 17:40:01 the ethernet issue which went for a couple years eventually Sep 22 17:40:27 every product has bugs, every chip has bugs Sep 22 17:40:36 it's just the way it is Sep 22 17:41:02 yes i can run tests for a particular setup to make sure it works well but you can't always test all conditions Sep 22 17:42:23 i'm relying of it to be working free of bugs for years, though i think it's doing good enough, probably the emmc was the biggest potential risk Sep 22 17:43:20 i was intending to run openbsd on it, this os is quite sane and simple, but it might have other issues, with lack of support Sep 22 17:43:56 i intend to check it, except it might be less resilient to halt by simple power than linux is Sep 22 17:44:38 if you want a stable low-risk system, I certainly wouldn't run something as poorly supported as openbsd on it Sep 22 17:44:50 openbsd is supported, though a handful of drivers are available Sep 22 17:44:56 "supported" Sep 22 17:45:07 indeed linux ecosystem for it seems mature Sep 22 17:45:46 i've had so few issues with openbsd, i understand it much better, it's quite clean Sep 22 17:47:01 at the moment i say i have no luck to make it run with it, but i can check deeper, if there a chance for it that would be what i'd opt for Sep 22 17:48:39 maybe netbsd Sep 22 17:51:32 lol Sep 22 17:52:11 makes you laugh Sep 22 17:53:22 or develop thourough test platform and deal with them Sep 22 17:54:27 just go baremetal development :) Sep 22 17:54:57 that's what i prefer you're right Sep 22 17:55:11 except i can't do the whole things in a lifetime Sep 22 17:55:26 TI has sort of an SDK for that on the am335x, called StarterWare, but it's a steaming pile of pig manure Sep 22 17:56:14 i just need i2c, a serial com with RTS for RS485, usb host, a storage location, and self updating capability Sep 22 17:56:16 yep Sep 22 17:56:22 like, it was written by devs who clearly do not understand interrupts or race conditions and who have no business touching driver code with a ten foot pole Sep 22 17:56:33 the client opted for Arduino but that didn't fit for all those need Sep 22 17:56:47 their uart driver caused random corruption, and their uart echo example would compile into a deadloop if you enabled any optimization Sep 22 17:56:56 :D Sep 22 17:57:51 i might run projects with the graphic accelerator later, that's not needed for this present project at all Sep 22 17:59:13 yes i see Sep 22 17:59:19 the baremetal sdk Sep 22 18:54:00 hello Sep 22 18:59:36 I have a pocket beagle with the seeed grove cape. I used the adafruit library to add gpis controls to control a relay. My concern is whether this presents a conflict with the Grove drivers which were probably set up by default. Sep 22 19:00:28 there's no such thing as "grove drivers" Sep 22 19:01:11 no special drivers loaded for the grove cape? Sep 22 19:01:53 can you recommend an example of code to control an I2C relay board? Sep 22 19:02:23 that depends on what's on the relay board Sep 22 19:04:01 it's the seeed relay board 103020133 grove-4channel spot relay Sep 22 19:04:24 spdt Sep 22 19:06:43 they're not using any sort of standard i2c chip to drive the relays, for some reason they chose to use a microcontroller Sep 22 19:07:44 and neither the product page nor the wiki page appears to document their custom protocol Sep 22 19:08:24 so typicaly I'd avoid this sort of mess Sep 22 19:08:51 I've created a scenario where I send an email from my iPhone containing commands like "Relay 1 On" to my email address. An Applescript parses this and places the body in a file which is picked up by a python program and uses ssh to start a python program on the beagle to enable the relay. I use a 2 channel port relay which works, but I want to get Sep 22 19:08:51 the 4 channel working too. Sep 22 19:09:49 thanks Sep 22 19:10:29 it looks like it's a two-byte write: 0x10, value where bits 0..3 of the value are the four relays Sep 22 19:10:42 i2c slave address is programmable but 0x11 by default Sep 22 19:11:56 I really don't understand why they didn't just use one of the ubiquitous i2c gpio controllers Sep 22 19:16:56 is there an example of the code used to send an I2C command? Sep 22 19:18:00 the examples with the grove kit for other I2C controls use compiled python code Sep 22 19:21:11 assuming it's on i2c bus 2, something like https://pastebin.com/edB99p2e I guess Sep 22 19:21:28 where 0b0000 is the four-bit value controlling the four relays Sep 22 19:22:54 (you can of course use smbus2 instead of smbus, but it seems smbus is preinstalled on beagleboard.org IoT images) Sep 22 19:23:38 thanks for your help, I have to leave for an appointment now **** ENDING LOGGING AT Fri Sep 23 02:59:56 2022