Heisath

Members
  • Content Count

    105
  • Joined

  • Last visited


Reputation Activity

  1. Like
    Heisath got a reaction from lanefu in Espressonbin 2.5Gbps, anyone?   
    The information you linked indicating there is 2.5Gbps mode is always only for the chip (Armada 3700) used on the espressobin. This Marvell chip does have the 2.5Gbps interface. That is also the reason it is explained on Marvell github.
     
    The espressobin itself has all 3 ethernet ports wired through one switch with only RGMII going in. As can be seen here: http://wiki.espressobin.net/tiki-index.php?page=Block+diagram
    As only one RGMII is feeding all 3 ports I dont think 2.5Gbps will be possible on any of them.
  2. Like
    Heisath got a reaction from Tido in Boot time - Anything similar to "Boot without waiting for network connection"?   
    Anyway, next steps to save time are:
    - completely remove NetworkManager (you need to do your network config the classic way then). 
    - remove armbian zram and ramlog (which can be done via apt remove or just disable the services) 
    - make sure your device does not run a fsck on every boot 
    - remove u-boot 'prompt timeout' (the time the bootloader waits for user input before booting the system, I guess thats 3s default on armbian) 
     
    Btw. no guarantee that your system works perfectly after above steps - there's a reason for every service running. 
     
     
  3. Like
    Heisath reacted to guidol in Date synchronization   
    All these messages show us, that you network isnt working or isnt working correct.
     
    How did you configure your network? Network-Manager? /etc/network/interfaces? armbian-config?
     
    Can you ping 8.8.8.8?
    Can you ping armbian.com?
    What says ifconfig for eth0 or wlan0?
    whats the IP of your gateway/DNS?
    what is the content of /etc/resolv.conf (when not using network-manager)
     
  4. Like
    Heisath got a reaction from lanefu in Espressobin - Only 1 GB RAM detected on a 2 GB board   
    If this works consider to contribute (https://docs.armbian.com/Process_Contribute/) and maybe add a PR with your changes to the Github https://github.com/armbian/build
    We are always looking for helping hands, especially espressobin since this has currently no real maintainer (that I'm aware of).
     
     
  5. Like
    Heisath got a reaction from Werner in Need your help - what else beside Etcher   
    I meant create an issue for displaying a general warning before writing. Like "WARNING: This will erase all existing data on drive X".
     
    The detection can probably not be made entirely perfect & foolproof
     
  6. Like
    Heisath got a reaction from Tido in Need your help - what else beside Etcher   
    Yeah it seems to protect only your system drive in Windows.
    A general warning before writing would also be nice. Maybe someone add an issue on gitlab?
  7. Like
    Heisath got a reaction from gounthar in Is it possible to shutdown properly an OrangePi Zero in case of power loss?   
    Yeah that might work.
     
    Keep in mind though that this module will still output 3.3V if the input is lower than 5V. Checking the datasheet http://www.advanced-monolithic.com/pdf/ds1117.pdf it seems like this regulator has a dropout voltage of about 1.2V. So 4.5V input would still allow this module to output 3.3V signaling to your SBC that everything is OK while at 4.5V input to your SBC it will probably fail.
     
    This is obviously not ideal!
     
    EDIT: Easiest way to do it would be to instead of the converter just use a potentiometer (10k or something like that). Connect the ends to 5V and GND, and adjust it until the slider is at about 3V (measure with multimeter). Then attach the slider pin to some GPIO and check GPIO state. Keep turning down the voltage just until the GPIO reads as LOW. Turn back up a bit until it is HIGH. Then once the input drops below 5V the poti output will also drop slightly causing the GPIO to go LOW -> use this as shutdown. 
     
    This is also not perfect, beware: never turn the poti to high (watch out for anything >3.3V on your GPIO) also you might have to experiment 'till you have a good setting. Minor power fluctuations should not cause a shutdown. 
  8. Like
    Heisath reacted to Werner in Rename Supporter to Donator   
    38 views and one like. So at the moment the majority of people is for this change
  9. Like
    Heisath got a reaction from lanefu in Armbian 20.02 (Chiru) Release Thread   
    Is this not easily possible by using LIBTAG parameter? Or does it not work anymore? 
     
    Apart from the final release confusion  I'd also totally agree with JMCC this release process was way better than older ones. 
  10. Like
    Heisath reacted to lanefu in Armbian 20.02 (Chiru) Release Thread   
    Yes. We definitely need to figure out when to cut a release, when to increment, what a RC version number means, etc.    -rc1 was really a rolling release branch this time.  AR-176
     
     
    I really see that as 2 parts.  
    * Make building alternate armbian build branches easier.
    * Make upstream dependencies consistent.
     
    Both are important, I think the first is a higher priority.    AR-176
     
     
    I partially agree with this.   All features in an RC should exist in master--first.   Bug fixes no.  If a bug fix obviously will improve master, then yes it can be cherry-picked,  But the primary purpose of bugfix is to assure the stability of the release.   Simple Example.. we add a patch to a release on 5.4 kernel...  master has moves to 5.5... may not make sense.

    In practice---during this release we ended up cherry-picking most fixes from master and into the RC branch.
  11. Like
    Heisath got a reaction from lanefu in Armbian 20.02 (Chiru) Release Thread   
    Suggestion for future releases: On the release date / once it's released make a topic in Announcements telling people of the new release. Or is Twitter now the main way to communicate such things? 
     
  12. Like
    Heisath got a reaction from guidol in Armbian 20.02 (Chiru) Release Thread   
    Suggestion for future releases: On the release date / once it's released make a topic in Announcements telling people of the new release. Or is Twitter now the main way to communicate such things? 
     
  13. Like
    Heisath reacted to Werner in Rename Supporter to Donator   
    Since - in my eyes - at least - there is a likelihood of confusion regarding the "Supporter" tag of members that actually (recurring) donating to the project. People could think "Supporter" means staff member that actually support people with their issues. The real staff rank, Moderator and Administrator to say, is "hidden" in their individual profiles. Since I like the idea of flat hierarchy I do not suggest to make the actual staff visible in forum postings but simply rename the Supporter to something like "Donator" to make it clear that these people donated to the project but are not necessarly involved into it.
     
    Tell me what you think,
  14. Like
    Heisath got a reaction from gounthar in Is it possible to shutdown properly an OrangePi Zero in case of power loss?   
    You could just add some larger capacitor in parallel to the power bank. If chosen right it should surpress the voltage spike and buffer enough so it does not drop. Might even use more than one to get a better frequency response. Or put a 5.2 volt zener / tvs diode across the board to protect it from the spike. 
     
    I can edit this with some wiring later if needed. 
     
    EDIT: Some wiring idea:
     

     
    Use some resistor voltage divider on the powerbank input (eg. 10k to 10k which gives you 0.5) to get some measurement to your sbc. With the given voltages this would be: 5V in -> 5V * (10k / (10k + 10k)) = 5V * 0.5 = 2.5V .
    If you feed this to some GPIO you can either use some analog pin to measure it directly (and initiate shutdown if it goes to low) or you can hook it up to some digital one if you only want to know wether it is high or low. Might need to change the resistor ratio then. Do not exceed your max gpio voltage!
     
    On the Powerbank output add either D1 or D2  (zener or transient voltage surpressor diodes) rated for slightly above 5V. These will get rid of nasty voltage spikes for you. Additionally use some small capacitor (to remove high frequency ripple) and some larger one in parallel (to reduce low frequency ripple / voltage drops) to buffer over the voltage drop when powerbank is switching on / off.
     
     
     
    Cheers, 
    count-doku
  15. Like
    Heisath got a reaction from Werner in Is it possible to shutdown properly an OrangePi Zero in case of power loss?   
    I was not expecting you to put more time into it. It was more directed at the original poster, to address the issues pointed out by you. And to give him an idea what he could do to make it work with a powerbank...
  16. Like
    Heisath got a reaction from TRS-80 in Which SBC, or chipset, has most complete and stable Armbian support   
    I agree with the previous posters. Any supported / recommended board will run stable with most features working if you use good PSU (not micro-usb), sd card (or even better root on emmc or sata) and is sufficiently cooled. I'd suggest you go for boards with good mainline linux support (ie. 4.19 or 5.4) because more hardware is supported & if something breaks there are possibly more people fixing it versus boards which only have some old vendor kernel.
     
    Apart from that unfortunately it is like you said, not every feature works on every board. In my experience this is mainly due to hardware producers advertising (hardware) functions although there is no real software support for it. Or randomly changing hardware (see espressobin) which breaks existing software... I suggest thinking about stuff you really need and picking a board afterwards. (You probably don't need an "Eierlegendewollmilchsau").
     
    Personal experience: I'm running a Router/NAS based on ClearfogPro with M.2 SSD for OS, 2x HDD for storage (with mPCIe-SATA bridge) for about  3 years now with no problems (apart from stuff which I broke be installing dev kernels and so on). 
     
    So, I am sending in the Clearfog Army!
     
  17. Like
    Heisath got a reaction from aprayoga in Helios4 Support   
    Hi Xavier,
     
    Kernel 5.5 is currently not supported by us. Our current kernel 4.19 has complete hardware support, dev kernel (5.4; which you need to compile yourself with https://github.com/armbian/build) should also have working PWM. 

    If you need to use Kernel 5.5 you are on your own, you can try to use the patches from 5.4 (https://github.com/armbian/build) to get PWM working...
     
    Cheers,
    count-doku
  18. Like
    Heisath got a reaction from gprovost in Helios4 Support   
    Hi Xavier,
     
    Kernel 5.5 is currently not supported by us. Our current kernel 4.19 has complete hardware support, dev kernel (5.4; which you need to compile yourself with https://github.com/armbian/build) should also have working PWM. 

    If you need to use Kernel 5.5 you are on your own, you can try to use the patches from 5.4 (https://github.com/armbian/build) to get PWM working...
     
    Cheers,
    count-doku
  19. Like
    Heisath reacted to lanefu in Armbian 20.02 (Chiru) Release Thread   
    Release Candidate Code Freeze Date: 2020-01-25
    Release Date: 2020-02-??  (will update thread)
    Current Release Candidate Branch Link: v20.02-rc1
    Release Changelog: (will update)
    Release Coordinator: @lanefu
    Testing Tracking Sheet: https://bit.ly/2TGaeZN  (google sheets)
     
    The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release.  Once the release is complete, this thread should be locked and unpinned.  Our Hotfix process for completed releases is TBD.
     
    First of all I'm sorry I'm kicking this off so late.  I should have started a few weeks ago.  I'll continue to update this post with more information.  I will also update release process documentation as we progress.
     
    I am going to go ahead and cut a release branch to learn and further document the process, but the official release branch won't be cut until the Release Candidate Code Freeze Date.
     
    Tagging a few devs here from memory.. please tag others....  @Igor @gprovost @martinayotte @chwe @TonyMac32 @count-doku @balbes150 @Tido
     
     
  20. Like
    Heisath reacted to Igor in Armbian 20.02 (Chiru) Release Thread   
    My two cents.
     
    - once we made a fork from a master branch, version must be adjusted accordingly (also on master)
    - master remains the place for new contribution and we merge them into 
    - when we are satisfied with the state of the build, RCx -> .1
    - hot-fix releases. For now IMO, using master branch and just going up with the number. Unless we have resources which will stay behind and tinkle old releases, send fix to master, merge back, bump version and tell me what to build
     
    I do plan to create a Jenkins server for this one day, that you will be able to push things up without me in the loop.
  21. Like
    Heisath reacted to lanefu in Armbian 20.02 (Chiru) Release Thread   
    I've added some more detail here on merge policy and release process.  Keep an eye on it. I'll be updating it as we go through this process https://github.com/armbian/documentation/blob/master/docs/Process_Release-Model.md#release-coordinating
     
    and to clarify.. I have cut an rc0 branch, but it's just to test the process.   rc1 will be the first official rc branch and will happen on our freeze date.
     
  22. Like
    Heisath reacted to gprovost in Armbian 20.02 (Chiru) Release Thread   
    Adding @aprayoga
  23. Like
    Heisath got a reaction from aprayoga in Armbian 20.02 (Chiru) Release Thread   
    Looks good, I like the definitive freeze / release dates. 
     
    I will do remaining work (mostly testing recent mvebu changes on Helios4) today.
     
    Another dev: @aprayoga
     
    EDIT:
    Not worth the extra post, I completed testing on Helios4 and Clearfog looks good:
    mvebu-legacy
        Helios4 lk 4.14.y u-boot 2018.11-armbian
       http://ix.io/27Ou
     
        Clearfog (Pro) lk 4.14.y u-boot 2018.01-armbian
        * SFP working but only up to 1Gbps    
       http://ix.io/27OL
     
    mvebu-current
        Helios4 lk 4.19.y u-boot 2019.04-armbian
       http://ix.io/27Ox  
     
        Clearfog (Pro) lk 4.19.y u-boot 2018.01-armbian
        * SFP working but only up to 1Gbps
       http://ix.io/27OM
  24. Like
    Heisath got a reaction from gounthar in GPIO and Armbian for OrangePi Zero.   
    Hi,
     
    these PIN Names are possibly considered "general knowledge" once you worked with some microprocessors or similiar. Most are just abbreviations. And the different functions on a pin.
     
    I'll try to explain some of them based on the linked OrangePi Extension header table (from their wiki):

    3.3V -> obviously 3.3V output
    TWI0_SDA / PA12 / GPIO12:
    TWI0_SDA -> Two Wire Interface also known as I²C | SDA -> Serial Data
    PA12 -> Pin from internal pin register a, number 12
    GPIO -> General Purpose Input/Output Pin Number 12
    the last two are essentially the same with the first one based on the internal registers and the other one just numerated over all pins.
     
    TWI0_SCK / PA11 / GPIO11:
    TWI0_SCK -> Two Wire Interface (i2c) | SCK -> Serial Clock
     
    GND -> ground, minus, (-), return or whatever you're gonna call it.
     
    UART2_RX -> Universial Asynchronous Receiver and Transmitter 2 -> also known as Serial Port (RS232 like) | RX -> Receiving or Receiver. This pin is read by software.
    UART2_TX -> see above, TX -> Transmitter. This pin gets set by software (and sends the data)
    UART2_CTS -> see above, CTS -> Clear to Send. Used for flow control, to tell the partner you are ready to receive. (or they are cleared to send) 
    (Googling for UART, USART or RS232 will probably give good explanations on this)
     
    SPI1_MOSI:
    SPI -> Serial Peripheral Interface -> Another kind of serial port. -> google.
    MOSI -> Master Out / Slave In -> this is the transmitting port for a master perspective
    SPI1_MISO -> Master In / Slave Out -> receiving port
    SPI1_CLK -> the clock signal. 
    Just search for spi for more info.
     
    SIM_CLK / PA_EINT7:
    SIM_CLK -> can probably attach a SIM Card here (then this will be the clock line). I don't know stuff about sim cards though.
    PA_EINT7 -> Internal Port Register A, External Interrupt 7. Read about Hardware Interrupts for microprocessors for more info. Essentially a software component can be instantly triggered on some predefined signal on this pin.
     
    The rest has the same prefixes, so you can probably deduce the meaning by using the internet. If something remains unclear, just ask.
     
    Kind regards,
    count-doku
  25. Like
    Heisath got a reaction from gprovost in Helios64 Annoucement   
    Looks good! Congrats to the Kobol team for designing another interesting NAS board.
     
    Is the 12V 10A power supply neccessary though? I mean thats 120W, with that much power one can easily run a real x86... 
    How much does the board itself consume?