[deslatha]

Here pin out of other pci-e switch but not far from pex8603. PE_RST like and wl pci card, it may reset eeprom of pex8603.

[Malachi]

This is all above my head. Especially when I have a hard time understanding your English.
No offense meant.

[deslatha]

[Ja]

deslatha

Thanks for the info. Unfortunately, the disconnection of individual bands did not bring results

In the sense the router did not cover them anymore but it was restarting



I'll see what happens when I turn off the radio on a working router.


Which router do you have copies of nanad from?


Further, I think that this is a failure of the wifi / PEX system ultimately the CPU

No communication with wifi radios


I just do not know how to check with which of the three can't get a connect


There is access to errors on mtdblock 16


PCI_PROBE: bus 3, slot 0,vendor 14E4, device 4365(good PCI location).<4>[ 13.500000] dhdpcie_init: can't find adapter info for this chip

[routerhacker]

I had an extra hour or so and thought I would try to add the missing capacitor that so many of these boards are missing. The reference photos of this board on the FCC site shows the capacitor in place, but it is missing from the board I have and many others I gather. Bad or missing caps can lead to some pretty strange stuff... boot looping is a common one. Anyhow, I solder on the needee 330uf/25v cap next to the power plug and button and fired up the board. immediately, I noticed the LEDS were slightly "stronger" and more as I would have thought. Before, they were a little dim and kinda oscillated ever so faintly if you looked really close. Signs of something power related. Anyhow, the big moment... and same problem: rebooting after hitting and trying to initialize the wifi chips.

That got me thinking that perhaps all of this started for everyone with these issue withe power related issues (perhaps to missing caps) and that did something to the wifi chips and/or PEX pci bridge along the lines were Deslatha was heading.

So in looking at the Product Brief for the PEX8603 chip, I see the following:

[deslatha]

13.500000] PCI_PROBE: bus 3, slot 0,vendor 14E4, device 4365(good PCI location)
//Detect and assign 5 High ghz on bus 3 as 4365.

[ 14.750000] PCI_PROBE: bus 4, slot 0,vendor 14E4, device 4365(good PCI location).<4>
[ 14.750000] dhdpcie_init: can't find adapter info for this chip.
//Detect and assign 5 Low ghz on bus 4 as 4365 but no info???

Enabling device 0002:03:00.0 (0140 -> 0142).<4>
// setting device wl

[ 13.450000] DHD: dongle ram size is set to 1343488(orig 1343488) at 0x200000.
// reserver for digital HD

[ 13.460000] dhd_attach(): thread:dhd_watchdog_thread:2975 started.<4>
// watchdog start for monitor if not then disable or shut down

[ 13.460000] dhd_deferred_work_init: work queue initialized .<4>
//Start to fetch firmware of PEX 8603
[ 13.460000] dhd_bus_download_firmware: firmware path=, nvram path=.<4>
// down load FW from nvram path to bus

[ 13.460000] dhdpcie_ramsize_adj: Enter.<4>
[ 13.460000] select_fd_image: Dongle image not available for chipid = 0x4366 chiprev = 4 chippkg = 4.<4>
// then no image ??? there are and should be in first original OEM fw.

[ 13.460000] select_fd_image: Dongle image not available for chipid = 0x4366 chiprev = 4 chippkg = 4.<4>
//Dongle image=image+token for each router . these key "get married" with router mac id.
As you see, router finds no dongle key then it down load a FW support to be to genarate new key but not available.

traceback to github if dts of firmware. since load third party fw is out of warranty.
If router has same trouble if it is running OEM then complain to consumer protection office. As on digital key or mouser these chipset is obsolete.

[routerhacker]

The dhd.ko module contains the firmware image for the 4366 chip. They changed version revs of the chip along the way and the 4366c0 rev4 chip firmware in the dhd.ko module did not appear until delivered firmware version 1.0.2... As I recall. You can run strings on the dhd.ko module and see the included firmware like below:

strings dhd.ko | grep -i 4366

You'll see the names/versions of supported chip firmware embedded in the dhd.ko module.

[spectral]

Hi friends.
Anyone can share R8300(R8500) NAND dump binary with me? Have empty nand and unable to find bootloader code anywhere. Please.

[ComProf]

thanks guys,you are awesome
i repaired my r8500 (boot loop)
but temps are scaring me
may be someone can say what pads be on stock?

[Malachi]

Those temps are fine.

[PITABoy]

I just fixed my router too!!! Thanks to everyone on these forums... I am posting what I did to do it.

How I fixed the r8500
Note: I had a full brick bought on ebay.

Boot to CFE and stop with Ctrl-C

[ComProf]

[vital2k]

Thank you for your posts.

I managed to debrick R8300 router with Koolshare_Merlin_Legacy_380/Netgear/R8500 firmware.

Original Netgear always ends up with an error - not loading all interfaces, going into reboot. Koolshare loaded router but only with two WiFi frequencies 2.4 and 5 MH. One frequency is missing, only one 5 MH working, but it is fine. The router up and running again.

[phoenix127]

Hi all,

I know this is an old thread, but providing a bit more info ready for the next guy.

I've had an R8500 for about 5 years now that's been working fairly well since the initial efforts to get these units understood better. I even stumbled across a number of the old threads discussing hardware variants and WIFI issues back then ..
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=286232&postdays=0&postorder=asc&start=150. Its good to see some of the old handles are still active, although sadly not Kong.

Well, it seems that my unit is also afflicted with the same problem now. I got complaints that WIFI was not good around the house, so I boosted that with a HH5A running OpenWRT at the other end of the house and and things have been OK except for bad power bricks on those units, but that's another story. I had noticed that some radios were disappearing and changing order in the UI in the R8500, with config parameters moving between them. I noticed this as I have different SSID's for each radio. For example, the 5G radio was broadcasting the 2.4G SSID. My thinking was that at boot the detection wasn't always getting them in the same order, so possibly firmware or something. Once I couldn't get WIFI in my office where the unit lives and had to deploy another HH5A for coverage there, I knew I had to deal with the problem.

Starting with the easiest things first, I ordered a replacement AC adapter and have tested both old and new on an active load and both are delivering good clean power up to their rated specification, so the problem is not the DC power into the units. When I can get a suitably sized DC connector, I will try a good lab grade power supply on a short cable into the router and see what it shows.

I was also far behind on builds, since my config is fairly complex. I took the plunge and updated a lot (9 months worth of updates) with a few stumbles through intermediate builds to stop the unit failing with presumably changes in NVRAM in between and the obvious change to swconfig for ethernet config. My hope was that a firmware change may have improved things. Either way, I'm now running the latest build with a migrated, not clean config. The serial console was connected during this to help out and I noticed the errors that indicated that certain hardware could not be seen - presumably the radios as there are lots of wl[x] related messages and invalid zero responses from things, etc. Its a shame that lspci is not in the standard build.

I was thinking start simple and check DC power rails. I decided to have a look and check for aged hardware - failing capacitors for example and I removed the 330uf cap next to the DC input, this looked OK (not bulged) and tested OK on an ESR meter, it was also a bit of a pain to get out as its obviously connected into ground and power planes on the PCB, so getting enough heat into it to get it out took a minute with a bigger (hotter) tip on the iron.

The cap tested OK and due to the lack of new similar shaped caps, the old one went back in. I could have put a larger one laying down across another chip but that could cause heat dissipation issues for that chip so I didn't do it. I'll order some spares anyhow next time I'm ordering components. I stumbled across a similarly thinking thread this evening, so good to see I'm not the first to think about this https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=309602&sid=7ebf9d0eee95444091b3e8592f13d71a. I can't see any other bulk capacitors on the board, at least not without a lot of stripping down, so I looked at the FCC ID pictures of the unit at https://fccid.io/PY315200309/Internal-Photos/Internal-Photos-pdf-2709621.pdf, I can't see anything else obvious in terms of bulk capacitance and haven't had the time to look for other regulators on the board.

I have also noticed that the wall that the unit is mounted on, which I decorated only 2 years ago, is showing a discolouration patch the size of the unit, hence showing that the unit is pushing out a fair amount of heat into the wall. I have also noticed that the radios seem to be temperature sensitive, for example, after reassembly, I saw three radios for a short time, before one disappeared again. Only the 2.4GHz one seems to be reliably appearing and even that now stops broadcasting its SSID sometimes.

I support the thinking of the PCI multiplexer being the likely cause as its in the right place, but I remain open on why its not happy - hardware failure, temperature, power stability, etc.

I've got a second hand R8000 coming my way at the moment so that I can swap out the R8500 and take a more leisurely look at it without the family complaining about Internet problems.

What is interesting is that if you erase the nvram and reboot, you do get the 3 radios showing up for a bit in the UI, but none of the 5GHz SSID's are broadcasting - as validated with InSSIDer, so again this would support some form of power related issue as the chip is being detected sometimes, but not working. This implies that the multiplexer is there and something else is wrong.

My plan is that once the R8000 appears and gets the config rebuilt onto it, I'll swap units and see what I can find with no time pressure and as insurance against the R8500 failing completely into boot loop mode, which seems to be the next step. I'm thinking this could indicate a power issue, or the PCI chip dying and crippling the bus for the CPU or perhaps a thermal issue such as the conductive paste drying out under the heat sink, so I'll check that and get the freezer spray out too and see what happens.

The only thing that doesn't sit right with me is that there are too many related problems for it to be one chip causing all the problems.

On related thinking, I've realised that the port mapping on the R8500 is not logical across the back panel, GUI and swconfig, so I think I've figured out how its all wired together, I'll post that in a separate thread in case anyone is interested and still has a working R8500 . What may be relevant to this discussion though is that there are three ethernet adapters - eth1, eth2 and eth3 which correspond to the wl0, wl1, wl2 adapters, when a device disappears, then the related eth[x] adapter also disappears from the OS

The other thing I realised is that if the unit is dying, then there is not a logical next router to move to, nothing seems to have a similar / better spec than the R8500 and the Asus porcupine AC5300 looks to be an R8500 in a new box and from a different vendor, just with a far inflated price tag and all the existing 12 aerials separated out to make it look fancy. Does anyone have any info on if these are better / suffer the same problems. Can we learn anything from the internals of that unit ?