mu-b

Well I've fixed my instability issue. The root cause was the same as https://forum.netgate.com/topic/144636/sg-1100-intermittent-reboots, and it was power related. The fix was to replace the 470uf/16V capacitor (component EC1 on the schematic) sat immediately behind the 12V DC jack which under testing leaked under certain temperature conditions (variations). As such the board is now stable and has been running OpenWRT 18.06.2 for 24 hours with memtester and stress running continuous during that entire time.
 
I'll leave it a few more days, after that I'm going to assume that its fixed and that is what NetGate were referring too when they mention 'a power related component'.
 
And GlobalScape will not tell you, they know of the problem, in a reply from Kevin Liu he says 'Yes, I do have knowledge regards the power related component issue.' when I asked which component it was so i could attempt to replace myself.

Well I've fixed my instability issue. The root cause was the same as https://forum.netgate.com/topic/144636/sg-1100-intermittent-reboots, and it was power related. The fix was to replace the 470uf/16V capacitor (component EC1 on the schematic) sat immediately behind the 12V DC jack which under testing leaked under certain temperature conditions (variations). As such the board is now stable and has been running OpenWRT 18.06.2 for 24 hours with memtester and stress running continuous during that entire time.
 
I'll leave it a few more days, after that I'm going to assume that its fixed and that is what NetGate were referring too when they mention 'a power related component'.
 
And GlobalScape will not tell you, they know of the problem, in a reply from Kevin Liu he says 'Yes, I do have knowledge regards the power related component issue.' when I asked which component it was so i could attempt to replace myself.

Well I've fixed my instability issue. The root cause was the same as https://forum.netgate.com/topic/144636/sg-1100-intermittent-reboots, and it was power related. The fix was to replace the 470uf/16V capacitor (component EC1 on the schematic) sat immediately behind the 12V DC jack which under testing leaked under certain temperature conditions (variations). As such the board is now stable and has been running OpenWRT 18.06.2 for 24 hours with memtester and stress running continuous during that entire time.
 
I'll leave it a few more days, after that I'm going to assume that its fixed and that is what NetGate were referring too when they mention 'a power related component'.
 
And GlobalScape will not tell you, they know of the problem, in a reply from Kevin Liu he says 'Yes, I do have knowledge regards the power related component issue.' when I asked which component it was so i could attempt to replace myself.

I've been looking at something relating to this, recompiling and modifying atf/A3700-marvell-utils to build a viable u-boot. From what I've figure out already, it seems the voltage (VDD) applied by marvell is too low by default.
 
Does anyone have any visibility on where the modification to ddr4-*cs-/*g.txt from http://wiki.espressobin.net/tiki-download_file.php?fileId=216 came from? namely the following line:
+;Step9: DDRPHY Driver/Receiver & DQS internal Pullup/Pulldown settings
+;WRITE: 0xC0001004 0xD0133449
+WRITE: 0xC0001004 0xD0677449
 
That is the only difference between the Espressobin provided ddr init and the mainline Marvell A3700 ddr init code.
At the moment I'm running an Espressobin v7 1000/800 using WTMI-devel-18.12.1-e6bb176 / 2018.03-devel-18.12.3-gc9aa92ce70 with a modification to bump the AVS voltage from 1.032V to 1.155V by default. This is looking to be more stable currently..
 
If anyone wants the resulting builds let me know. I cannot use the latest https://dl.armbian.com/espressobin/u-boot/ provided versions of WTMI-devel-18.12.1-e6bb176 since it randomly fails to boot. I rebuilt and enabled debugging and so far no stalls.
 

Even with the latest build, I'm still experiencing random hard-resets (that is, no panic, just a complete reboot to TIM/WTMI). I'm now pretty sure that Netgate are correct (https://forum.netgate.com/topic/144636/sg-1100-intermittent-reboots) and there are component issues on some espressobin v7 boards. 
 
I'm asking GlobalScape if they know the root cause, that is the component that is not functioning correctly, wonder if I will receive of a response, Netgate don't seem to want to say.

I've been looking at something relating to this, recompiling and modifying atf/A3700-marvell-utils to build a viable u-boot. From what I've figure out already, it seems the voltage (VDD) applied by marvell is too low by default.
 
Does anyone have any visibility on where the modification to ddr4-*cs-/*g.txt from http://wiki.espressobin.net/tiki-download_file.php?fileId=216 came from? namely the following line:
+;Step9: DDRPHY Driver/Receiver & DQS internal Pullup/Pulldown settings
+;WRITE: 0xC0001004 0xD0133449
+WRITE: 0xC0001004 0xD0677449
 
That is the only difference between the Espressobin provided ddr init and the mainline Marvell A3700 ddr init code.
At the moment I'm running an Espressobin v7 1000/800 using WTMI-devel-18.12.1-e6bb176 / 2018.03-devel-18.12.3-gc9aa92ce70 with a modification to bump the AVS voltage from 1.032V to 1.155V by default. This is looking to be more stable currently..
 
If anyone wants the resulting builds let me know. I cannot use the latest https://dl.armbian.com/espressobin/u-boot/ provided versions of WTMI-devel-18.12.1-e6bb176 since it randomly fails to boot. I rebuilt and enabled debugging and so far no stalls.