**** BEGIN LOGGING AT Sat Nov 02 02:59:57 2019 Nov 02 03:03:19 Okay. Nevermind. The Replicape has two PWR inputs and two GNDs. I can use those indead of making another piece of functional wiring. Nov 02 03:03:29 Yea boy! Nov 02 03:03:39 I just have to lengthen the wires by magic! Nov 02 04:06:59 rah: so... 34/1431 failures (2.4%) with no pull-up, 12/1189 failures (1.0%) with 1K pull-up, 5/1153 failures (0.4%) with 240Ω pull-up... I'm seeing a pattern here :P Nov 02 04:08:00 (when I say "no pull-up" I mean on external pull-up of course, the reset line has 10K pull-up on the BBB itself, and all of these tests also have the reset extender... I can't easily test without since it's been soldered on) Nov 02 04:13:16 so it would appear that the primary cause of the ethernet phy problem is related to the slow rise time of the reset signal (caused by the 2.2 uF capacitor) Nov 02 04:40:48 the cap does add min 5 typ 13 max 16 ms to the reset time (depending on threshold of the reset input of the phy) and 5 ms is exactly how much the reset needs to be extended to meet the phy's specs, so the RC value seems to have been tuned correctly for that (using smaller cap but larger pull-up would probably have led to too much uncertainty) Nov 02 04:49:04 but it would appear that either 1. the phy doesn't tolerate a slow-rising reset (though there's no constraint on this mentioned in the datasheet afaict nor is it in the errata) or 2. the am335x is being released from reset before the phy is (threshold for am335x is 0.8-2V, threshold for phy is 0.81-1.90V) and this somehow causes the problem Nov 02 06:20:22 okay, I've inserted 0.25s delay between bootrom and SPL. if the problem is somehow caused by the am335x being released from reset and SPL/u-boot being executed too early then this would have to fix it. (I've removed the pull-up) Nov 02 06:36:24 interesting :D Nov 02 06:36:42 is that PoR or all resets? Nov 02 06:38:48 POR since a soft-reset won't actually cause the reset line to go low (it's supposed to, the am335x tries, but the 2.2 uF cap is like "lol you want to drive this line low for a few microseconds with your puny driver?") Nov 02 06:40:27 assuming the length of the reset-out pulse isn't already configured to 0, as it should be since this can't be good for that poor output driver Nov 02 06:41:10 true :/ Nov 02 06:41:17 needs a FET :D Nov 02 06:41:36 but a 2u2F cap is pretty brutal Nov 02 06:41:40 oh not even a few microseconds... the default is 6 cycles (of the main osc), i.e. 0.25 us Nov 02 06:41:52 ouch lol Nov 02 06:41:58 yeah that ain't gonna do nuthin Nov 02 06:42:02 so it's trying to drive it low for 0.25 μs... let's just say it doesn't get very far in that time Nov 02 06:42:19 probably 99.98% ;D Nov 02 06:43:12 the maximum configurable value is 255 cycles, i.e. 64 us .. which still seems pretty short to me Nov 02 06:43:33 yeah reset pulses tend to be in the low ms no? Nov 02 06:43:44 (for cases where there isn't a big cap I mean, with the big cap it's probably a bad idea to even try) Nov 02 06:45:29 the PMIC keeps POR asserted for 20ms after all supplies are enabled, the reset extender (TLV803S) that's been attached to this BBB keeps reset asserted for 200ms after the 3.3v is stable Nov 02 06:46:20 was Gerald smokin somethign when he tied that pin to the 2u2F cap!? lol Nov 02 06:46:32 no, he was trying to extend reset by 5 ms Nov 02 06:46:50 ah heh :D Nov 02 06:47:45 my calculation is that based on the RC time and the minimum rising-edge threshold value specified in the phy datasheet, the 2.2 uF cap + 10K pull-up extends the reset to the phy by at least 5 ms Nov 02 06:48:05 ah at power-on yeah probably Nov 02 06:48:10 which is exactly the minimum amount needed to meet phy reset timing specs Nov 02 06:48:33 does the phy need reset on soft-reset? Nov 02 06:48:45 does it ever "hang"? Nov 02 06:48:53 at power-on yeah. the phy doesn't care about the width of the reset-pulse as such, but the reset deassertion needs to be >= 25 ms after the power supplies are stable Nov 02 06:49:10 yeah that sounds reasonable Nov 02 06:49:10 not sure what you mean Nov 02 06:49:21 does the phy need resetting whilst power is ON ever? Nov 02 06:49:38 eg. at CPU reboot Nov 02 06:49:45 or just at POWER on Nov 02 06:50:10 presumably PMIC and everything are in stable-ON mode .. so probably not .. Nov 02 06:50:34 (just getting a handle on what issue is being solved/questioned) Nov 02 06:50:34 I mean the phy will get soft-reset at reboot... twice... since both u-boot and the kernel perform a soft-reset as part of phy initialization (although I've patched the kernel to skip that if the phy seems to be in a reasonable state, since it had become a limiting factor for boot time) Nov 02 06:50:40 but a soft-reset is not a reset Nov 02 06:50:46 nope Nov 02 06:51:34 the problem is that is appears to mis-sample the strapping options (perhaps there's a race condition between sampling the strapping options and enabling the output drivers on those pins) Nov 02 06:51:34 so for a full hardware reset, we're talking a power-cycle, basically, yes? Nov 02 06:51:46 oh lovely :/ Nov 02 06:52:29 what action does the on-board push-button reset initiate? Nov 02 06:53:46 yes I have a setup that continuously power-cycles the BBB (more specifically it pulls the power-button pin low when the beaglebone is off, and I have a startup script that logs whether or not the phy failed and then powers off, after first checking the S2 button to have a way to break out of this loop) Nov 02 06:54:02 the reset button is directly between the reset line and ground Nov 02 06:54:13 ah Nov 02 06:55:57 so it's a single net that connects to: 1. cap and pull-up 2. open-drain driver controlled by POR signal (from pmic) 2. the am335x reset in/out 3. the reset button 4. pin P9.10 5. ethernet phy reset input 6. the SRST pin of the jtag header Nov 02 06:56:18 ehh, numbering fail Nov 02 06:56:37 ah I get the 'drift' Nov 02 07:08:36 or maybe the power rise time is too slow for the PHY Nov 02 07:09:10 never understood why they tied it with the POR... a GPIO made sense and that's what I did on my board Nov 02 07:10:01 power rise is essentially instant, and the phy doesn't relaly care as long as the power-up doesn't take more than 50 ms Nov 02 07:10:18 a gpio would definitely have been better yeah Nov 02 07:10:51 I suppose a GPIO would break boot from ethernet Nov 02 07:11:04 oh, true! Nov 02 07:11:08 I hadn't thought of that Nov 02 07:11:59 also the phy doesn't spec a maximum rise time on reset as far as I can tell, as long as it's monotonic Nov 02 07:12:16 but how many people use that Nov 02 07:12:19 (and it has schmitt-trigger to cope with some noise) Nov 02 07:14:43 the phy datasheet actually suggests using an rc circuit for generating the reset, in an application diagram Nov 02 07:15:20 (with unspecified R/C values) Nov 02 07:16:27 so that probably explains where the idea came from Nov 02 07:16:42 btw, anyone noticed the BBAI (current) kernel doesn't allow changing CPU freq Nov 02 07:19:33 ok, 0.25 ms delay between bootrom and SPL did absolutely nothing... I didn't expect it to, but it was worth trying just in case (since it would have meant it'd be software-fixable) Nov 02 07:22:32 so, I think I've kinda excluded any possibility other than: phy can't actually deal with slowly rising reset, even though an application diagram suggests using an RC-circuit for reset timing. I should probably try to contact Microchip with my findings and see if they reply Nov 02 07:26:29 didn't I just suggest that? :D Nov 02 07:55:58 ? Nov 02 07:56:57 uhh, no? Nov 02 07:58:25 regardless it wasn't something that needed suggesting, I fully planned to contact them once I had done sufficient analysis and excluded interaction with the am335x as cause Nov 02 07:58:59 or maybe the power rise time is too slow for the PHY Nov 02 08:06:18 :p Nov 02 08:07:14 ds2: ehm, and like I said power rise time is instant and not the problem, it's about reset Nov 02 08:11:33 (and I established unambiguously that failure probability depends directly on reset rise time many hours ago) Nov 02 18:04:13 Hi, so I need to run Android as an OS on my beaglebone Black Wireless, is there any os image for that? how can I manage to make wifi work? Any help appreciated. **** ENDING LOGGING AT Sun Nov 03 02:59:59 2019