Hello all, I’m going to try and keep this fairly short while remaining informative.
It’s been fairly self evident for some time now that the E610-XAT2 package was not the issue, it is important to understand the origin of a fault and where it surfaces aren’t necessarily the same, any software engineer that’s had to deal with issues caused by uninitialized data reads and out of bounds buffer writes knows this all too well, the fault can often surface a significant distance from the origin, and sometimes in completely unrelated functionality.
The E610 package is quite complex and requires no less than 7 external SVRs (3.3v, 1.8v, 0.75v, 0.895v, 2.3v, 0.85v and 0.65v), these rails must become stable within specified timings and obviously remain stable thereafter, stability issues when the package initially receives power and enters its boot sequence, at least for my unit, likely corrupts the E610 shadow RAM, this invalid/undefined state leads to NIC instability and eventual failure.
The workaround I suggested, that works on my system, is to warm up the GTR9 by running it hot for a few minutes with the NICs disabled, then completely remove power for a few seconds and re-enable the NICs, the E610 will then go through a full power on sequence and re-initializes its shadow RAM. Warming up circuits has a number of effects, one of which is stabilization, especially for passive components. Unfortunately despite correcting them, Beelink continue to instruct not to remove power, thus completely defeating the purpose of the workaround. (Note that some systems are designed to only operate correctly at low temperatures but that doesn’t apply here).
I’m neither an expert or an authority regarding this issue, especially as I’ve neither the time or inclination to put it on the bench and analyse it myself, so don’t take what I say as gospel.
What you do is of course up to you, but if you want to exchange your unit for one free of this defect I suggest you wait until Beelink stops giving mixed messages, issue a statement confirming the issue they have discovered, and that it’s been corrected both in manufacturing and the supply chain. That is the least customers deserve and the very least Beelink owes this community.
There’s a lot more I could say and a little more I’d like to say if I’ve time a bit later in week, hopefully it’s of interest to the community.
