• Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    barish reacted to mu-b in Espressobin support development efforts   
    Well I've fixed my instability issue. The root cause was the same as, 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.
  2. Like
    barish reacted to mu-b in How to make ESPRESSObin v7 stable?   
    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 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 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.
  3. Like
    barish reacted to JDL in How to make ESPRESSObin v7 stable?   
    Not sure if this is related, but the Netgate team is seeing an unusually high instability failure percentage on the SG1100, which is a branded Espressobin.  They say this is related to the power system on the board I think, and caused by a supplier component problem. I imagine it is possible the same supply chain issue has impacted the Espressobin. 

  4. Like
    barish reacted to mu-b in Espressobin support development efforts   
    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 ( 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.
  5. Like
    barish reacted to guidol in Failing to Rescue EspressoBin   
    link doenst work, so please try this git command:
    git clone -b A3700_utils-armada-17.10  
  6. Like
    barish got a reaction from Bernie_O in A20 SATA write speed improvement   
    To sum up my not too excessive tests of the new kernel on the Lime2 - I did not encounter any read/write errors up to now. Right from the start I switched to nightly builds and still had a reasonably stable system. What I found dissapointing were the speeds over network (SMB): I did never exceed 44MB/s in any condition (reading, writing, HDD, SSD, SD card, SATA, USB, always GBit-Ethernet).
    If there's any procedure of testing read/write over SATA excessively - please let me know. Does a benchmark apply?
    OT: So this board might be a good update to my first generation Raspberry Pi (which makes 6MB/s ;-) ) but compared to the EspressoBin V5, which I obtained a couple of days ago and which is stable (other than the V7 I had to send back), it is about half as fast. And I am running the EspressoBin at a conservative 800MHz.
  7. Like
    barish got a reaction from Bernie_O in A20 SATA write speed improvement   
    Thanks @Tido for this link, I hadn't seen it and it gives quite a good explanation to why it took so long and why it's so difficult to have a decent SATA speed on Allwinner boards. :-)  So I think testing should include all different kinds of transfer block sizes, verifying the write result on the fly, just to be sure that one trial-and-error-finding is as good as the previous trial-and-error-finding, which has already been tested since 2014.
  8. Like
    barish reacted to martinayotte in I2C busses changed with update?   
    If you do a "i2cdetect -l", you will probably see that i2c-0 is dedicated to "sun4i_hdmi_i2c adapter", which maybe wasn't present before ...
  9. Like
    barish reacted to Igor in I2C busses changed with update?   
    Most likely settings were changed upstream since I don't recall seeing anyone around Armbian fiddling around this.
  10. Like
    barish reacted to lagerschaden in [RfC] Make Armbian more IoT friendly?   
    It would be GREAT if rootless access to gpio was integrated in armbian (just like in raspbian).
    I made a little test on my Orangepi-One:
    created a group gpio and added the user to the group gpio, then created the file /etc/udev/rules/99-gpio.rules, this makes the access rootless
    # /etc/udev/rules/99-gpio.rules SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\ chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\ chown -R root:gpio /sys/devices/platform/sunxi-pinctrl/gpio && chmod -R 770 /sys/devices/platform/sunxi-pinctrl/gpio;\ '" Edit (02/09/2018): for later versions of armbian the file must change (tested with 4.14.18 and 4.14.65):
    # /etc/udev/rules.d/97-gpio.rules SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\ chown -R root:gpio /sys/class/gpio && chmod -R 0770 /sys/class/gpio &&\ chown -R root:gpio /sys/devices/platform/soc && chmod -R 0770 /sys/devices/platform/soc'"  
    Now you can use the access on the bash for the PIN PA12 (calculation see
    echo 12 > /sys/class/gpio/export # enable access to PA12 sleep 0.1 # wait some time to become gpio12 active echo out > /sys/class/gpio/gpio12/direction # PA12 is output echo 0 > /sys/class/gpio/gpio12/value # PA12 is low echo 1 > /sys/class/gpio/gpio12/value # PA12 is high echo 12 > /sys/class/gpio/unexport # disable access to PA12 My skills in programming are not good enough  to transform this to C, C+, Python etc, but you don't need any root privileges.
  11. Like
    barish reacted to tkaiser in safe GPIO access (no root)   
    Did you read through this already? 
  12. Like
    barish got a reaction from Igor in What happens when booting with SATA drive connected?   
    Sorry for not testing for so much time, it was quite a bad situation with the Olinuxino at work all the time.
    But I have good news: I just downloaded the latest Jessie-image, and the problem seems to be solved, I can boot with attached SATA drive without any issues.
    Thanks a lot for the ongoing development!
  13. Like
    barish reacted to zador.blood.stained in GPIO in Olinuxino Micro A20   
    Look at GPIO numbering scheme in mainline kernel here:
    It is tied to SoC pin bank (port) numbers, so GPIO 1 would be pin PA01, and this pin (for A10/A20 CPUs) is probably used by network driver, so no wonder kernel crashed here.
    You will need to calculate GPIO numbers for pins manually by their names (i.e. PG0 -> GPIO 192 if I'm not mistaken).