Foxconn have no intention to fix tis issue, but instead killed Netgear R8500
Same story with D7000 and D7000v2
/*foxconn Han edited start, 10/01/2015
*when R8500 didn't recognize all 3 interface, then do the software reboot*/
int isDhdReady()
{
char ifname[32] = "eth1";
int flags;
unsigned long addr, netmask;
int i = 1;
int ret = 0;
int max = 3;
int flag = 0;
char *max_pt = NULL;
Well.. not sure what to think about the "no driver" statement. The PCI chip(s) / bus certainly need to be properly setup and devices (i.e. wireless chips) sitting on a given bus need to be properly setup and initialized. And that is what seems to be the issue at hand. The wifi chips are not properly being setup/initialized/recognized.
I have read elsewhere that the PEX 8603 used in the these units due to it nature has some trouble when wifi goes offline reestablishing proper communications due to a bug in the broadcom drivers (I can't personally verify that however).
It does seen that in reading much about this that Netgear never made proper changes to the bcm5301x_pcie.c "switch" code and instead just declared the router end-of-life to avoid as much replacement obligations/cost as possible. Seems the Openwrt guys found a bit of the issue but have not yet focused on the R8500 units at length but did sort out in EA9500 Linksys units. Cest-la-vie.
Well.. not sure what to think about the "no driver" statement. . Cest-la-vie.
I think you support to know what BroadComm legacy about magic bits.
For instant you need whole sentence to command amazon Echo&Alex;It required alot data in term of communication. more data then more slower in time. more bugs and working.
How about if you only send 1 byte that interpret into 8 bits which have 16 combinations. that is called magic number. intead you send up thousand byte x 16 times to do same task.
It is true meaning of computer that cutting Time not slow time in same procedure. However there should some space between 0 and 1 magic bit to turn into debug model but i have not see.
Back to topic, BCM has put all thing into rom of PEX chipset that why router does not need a driver. Or may be called pre-set driver. just a few byte like mtd cal-pcie partition sending then PEX 8603 switch on to wl modules.
True. But for most anyhow, the mtd calibration data is intact and viewable. It just is either a) not properly being sent or b) not properly being recognized or c) both or d) missing something else.
Perhaps some interactive manual initialization steps would be possible?
Way too late here and not thinking clearly More this weekend.
Which pcb version did you replace the flash on? Was is from a same exact variant board? You said it did not search for wifi devices... did you watch the logs under a serial connection? That is almost always where the bootloop issue occurs. The router tries to init the wifi chip and they are not responding in time due to either misconfiguration, failure, or something like that.
Now it well might be possible that failing (or missing) caps on the board lead to the wifi chips (and related coprocessors) not getting proper voltages and in turn the wifi chips not consistently or properly initializing and resulting in the reboots.
It is probably worth a very close inspection or maybe even complete replacement of caps on the board with new caps and see if that makes a difference fi that is something you can try.
This is not a factory defect. Routers started to fall after some time or uploading a newer software
It is not the fault of software for sure. Unfortunately, I do not have parts to solder. Maybe I will order, but shipping from China will last. And do not want to spoil efficient routers.
Yeah, my soldering equipment here is on it's last leg and doesn't heat well now. I need to find a replacement. I will see if I can locate some replacement/fresh caps and give that a go here when I get a little time and see what happens.
Failing after a little time (not immediately from factory) does tend to sound like caps, especially if they have a super sensitive board design.
It would be nice if Netgear would just come clean about the issue so anyone choosing to do so might have a change to fix, even if they still don't replace or make good on their warranties for folks.
If you are thinking about replacing 4366 chips one option might be to get another broken router and salvage one working 4366 chip from it and replace it on your router.
I was not thinking of replacing 4366 chip however. I was talking about bad or failing capacitors. It is not uncommon for capacitors to go bad or start to not provide proper voltage/power levels to components. In this case, as their are multiple wifi chips with coprocessors and an extra PEX bridge involved, the power requirements are much different than other routers of the past. It may just be that the problems are related to one or more sketchy capacitors. After all, you have even seen that between board revisions MP1 and MP2 that Netgear added a capacitor which is indication they recognized something was not quite right in the original design. I suspect the problem may just be in capacitors due to heat and power drain. That would be a cheap and easier thing to determine than replacing 4366 chips.
No change for me. Still only have the upper band 5ghz working on this koolshare fw as I do on dd-wrt.
The 2.4ghz sometimes shows up some times doesn’t, on either firmware.
Won’t boot at all on Netgear firmware.
This is on an r8300. I threw away the other r8500’s I had two weeks ago.
You can made a short cut 3 stream from cpu to direct 2.4ghz or 5ghz_low; but router is no more tri-band but only 2 of 5ghz or like normal router.
Here how to do with expert on micro soldering. Or like any other pci-e switch that has PE_RST and debug TP; hold to groud for reset and active.
here a example pinout on other pci-e switch.
C1436&C1435=stream in 1 from cpu
C1004&C1003=stream in 2 from cpu
C1430 &C1431=stream out to 2.4ghz
C1438 & C1439=stream out to 2.4ghz