mu-b

Members
  • Content Count

    8
  • Joined

  • Last visited

About mu-b

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Im away at the moment and cannot pull the version number from the board. I suspect the dodgy board is the older revision as i have two of the newer and the capacitor is different (brand). - GlobalScale didn't reply, they know of the problem though and essential admit it. - Yes I recompiled a modified TIM/WTMI that changed the avs settings on boot and increased the voltage slightly in increments. I can supply these builds for you. I originally did this to get the latest versions of everything on the board as the armbian built versions caused random failures/lock-ups on TIM/WTMI, these versions have never caused this (suspect differences in compiler version)
  2. Yes it seems instability is still there, albeit it was stable for 4 days straight. I'm still asking GlobalScale for their explanation of the faulty part. With any luck they will respond. I can't see why they wouldn't since the device is a 'community board' and thus they rely on the community for support so it would be rather hypocritical to refuse to disclose knowledge relating to the hardware to the community.
  3. Yes I had a fan on the device and it would cause it to perform the reboot continuously and more frequently (often before the device had a chance to complete even TIM/WTMI/u-boot, which rules out the Linux kernel). Its not that difficult, if you have any experience with a soldering iron it'll take 10-15 minutes going slowly, the hardest part is desoldering the original component. In this case, youtube is your friend, plenty of tips on 'decapping'. On another note, the device completed 2 threads of memtester 400 128 alongside stress --cpu 2 and has now been up for 3 days without a hiccup.
  4. Thats the exact problem I was having. The capacitor only leaks under certain conditions, and by leak I don't mean leak the electrolytic fluid or bulge, but leak V through to GND when the temperature changes. Yes I noticed the same thing occurring to me, over time the problem would get worse, presumably as the capacitor degraded further. I would desolder the capacitor and replace with alike, I wouldn't mind betting that would fix your board. I've informed GlobalScale how I fixed it, no response from them confirming the defective component, I don't expect them to confirm it either.
  5. 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.
  6. 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.
  7. 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.