Which problem do you have? *IIRC* QNX may still use uboot or equivalent QNX can kill and restart a driver. Would require something to determine the Ethernet was not working and restart it.
It seems like there are/were two problems: 1. Random RX characters on console/debug UART interrupting normal boot 2. Ethernet chip not resetting, because the reset pulse is too short There are several routes to boot or reboot which clouds the issues. *UART Problem* The solutions and theory are... Connecting a FTDI USB to UART cable by holding the RX line at idle (3.3V), stopped the random characters which triggered the uboot command line. The original hardware fix was to pull the RX line low through a resistor, but this did not fix all boards. This holds the RX active which may cause a "break" interrupt in the UART. Alternate hardware fix was to pull the RX to 3.3V through a resistor (like using a FTDI cable). This may also allow the chip to be powered by its data line. The software fix is by changing uboot to only enter command line, by a specific sequence of characters, not just any random character. *Ethernet Chip Reset Problem* The hardware fixes were: to increase the length of the reset pulse by increasing C24 to add gate to pull down SYS_RESETn when "power good" signal is not On Wednesday, 2 June 2021 at 10:43:08 UTC+1 Geetha wrote: > We have a few Industrial Beaglebone Black from Element 14. Rev C(PCB > revision is B6). > The Ethernet not coming up on every boot is faced in this version too. > The OS used is QNX & hence the Software fix provided in Linux Kernel could > not be used. > Is there a solution? > -Geetha > > On Wednesday, November 27, 2013 at 3:52:42 AM UTC+5:30 AndrewTaneGlen > wrote: > >> Hello, >> >> I have noticed very rare cases (~1/50) of the ethernet phy on the >> Beaglebone Black not being detected on boot, and requiring a hard reset (as >> opposed to calling 'reset' from the command line) to get it to work/be >> detected again. >> >> This problem has been mentioned in a couple of other threads (below) >> concerning different topics (i.e. problems getting the BBB to boot, and the >> ethernet phy 'dying' some time after initially working fine), with no >> solution/workaround for this specific problem being suggested - so I >> thought I'd start a thread specifically for it. >> https://groups.google.com/forum/#!msg/beagleboard/Vp4pxwHm8BU/Iaw3p5xm0MoJ >> https://groups.google.com/forum/#!topic/beagleboard/aXv6An1xfqI >> >> In the first thread mlc/Mike discussed his response to the problem as >> follows: >> >> >> >> >> >> >> >> >> >> >> >> >> *"I had issues with the network not coming up on boot, and it was >> traced down to problems with the SYS_RESETn line. I had a level translator >> connected to SYS_RESETn, to drive a 5V chip. It was powered by a 5V rail. >> If the 5V rail powered up "differently" than the 3.3V rail (not sure of the >> exact relationship), I guess it pulled the SYS_RESETn line to weird levels >> that affected the network chip but not the main processor. I'm now using a >> GPIO to drive the external 5V chip now, instead of the SYS_RESETn >> line. Anyway, the moral is be very, very careful with SYS_RESETn, because >> it can cause hard-to-trace problems with networking.*" >> >> I see that the A6 Revision of the Beaglebone Black has some changes to >> the SYS_RESETn line: >> >> "*Based on notification from TI, in random instances there could be a >> glitch in the SYS_RESETn signal from the processor where the SYS_RESETn >> signal was taken high for a momentary amount of time before it was supposed >> to. To prevent this, the signal was ORed with the PORZn (Power On reset).* >> " ( >> http://elinux.org/Beagleboard:BeagleBoneBlack#Revision_A6_.28Production_Version.29 >> ) >> >> Is it likely that this modification will improve/resolve the issue I am >> seeing with the ethernt phy not resetting/powering-up correctly?, seeing as >> the SYS_RESETn signal also feeds into the nRST pin on the ethernet phy (The >> SYS_RESETn line is left untouched in my application). >> >> >> Some additional observations from dmesg concerning this use: >> >> On a good phy boot I see the following: >> [ 2.810749] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6 >> [ 2.817206] davinci_mdio 4a101000.mdio: detected phy mask fffffffe >> [ 2.833517] libphy: 4a101000.mdio: probed >> [ 2.837871] davinci_mdio 4a101000.mdio: phy[0]: device >> 4a101000.mdio:00, driver unknown >> >> Followed later by: >> [ 21.286920] net eth0: initializing cpsw version 1.12 (0) >> [ 21.301166] net eth0: phy found : id is : 0x7c0f1 >> >> On a 'bad phy' boot I see the following (differences highlighted): >> [ 2.806763] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6 >> [ 2.813213] davinci_mdio 4a101000.mdio: detected phy mask *fffffffb* >> [ 2.829512] libphy: 4a101000.mdio: probed >> [ 2.833875] davinci_mdio 4a101000.mdio: phy[2]: device >> 4a101000.mdio:02, driver unknown >> >> Followed later by: >> [ 21.346861] net eth0: initializing cpsw version 1.12 (0) >> [ 21.354379] *libphy: PHY 4a101000.mdio:00 not found* >> [ 21.359469] *net eth0: phy 4a101000.mdio:00 not found on slave 0* >> >> >> So it looks like the 'davinci_mdio_reset' function see the phy in both >> instances, but reports differently on the bad boot. I am not sure what to >> make of this. >> >> I am using the Debian 7.2 Rootfs and the 'RobertCNelson' kernel >> '3.12.0-bone8'. >> >> >> >> Regards, >> Andrew. >> >> >> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/f08f871f-8670-4f6b-a2b7-a34922f5ac62n%40googlegroups.com.
