AnythingIsFine

Members
  • Content Count

    8
  • Joined

  • Last visited


Reputation Activity

  1. Like
    AnythingIsFine reacted to Igor in Rock64 CPU Overclock using cpufrequtils   
    Possible, it might work, but it is not recommended.
  2. Like
    AnythingIsFine reacted to Igor in Rock64 CPU Overclock using cpufrequtils   
    You need to have most recent kernel. 
  3. Like
    AnythingIsFine reacted to pfeerick in Rock64 - Armbian eMMC image   
    @AnythingIsFine Ouch! That sounds like me with the raspberry pi... when the recent 'disabled by default' behavior of the SSH... scratching my head to work out why the SSH wasn't working, and I'd firstly forgotten to make the enable file, then made a typo in the filename...
     
    At least it's working now!
     
    Hm. so the artful images... interesting... will have to poke around and see why it changed. Be handy to port that back to other images. If the artful images are using the kernel that supports it, it could be signifying disk activity...
     
     
  4. Like
    AnythingIsFine got a reaction from pfeerick in Rock64 - Armbian eMMC image   
    @pfeerick
     
    Thank you for your time! On the other hand, I do apologize for wasting it.
     
    I managed to boot up Armbian on my Rock64 and figured out that the issue was between the keyboard and chair, namely me.
     
    I am running only headless boot on my SBCs and I just configure a static IP after flashing the respective image, which I later use SSH into post boot.
     
    On ayufan's Ubuntu Xenial/Artful I just edited the '/etc/network/interfaces.d/eth0' file to achieve this, but when browsing the files after flashing the Armbian image, I noticed the "armbian_first_run.txt.template" file and decided to use this option instead... I edited it to boot 'eth0' to a static IP which I would use to SSH into it, just to test it out (nice feature by the way, very Raspbian-e)
     
    Of course, I edited the file accordingly, but simply forgot to rename it to 'armbian_first_run.txt' so it may be found and read and as such the IP I set in it was not configured, hence I could not ping the IP I set up.
     
    This mistake, coupled with the fact that the red LED was constantly on as opposed to flashing quickly during boot and then being turned off, lead me to *mistakenly* believe the Armbian image would not boot of my eMMC.
     
     
    I think this is default behavior on Etcher on Windows/Linux.
     
    When flashing an image using Etcher on my Fedora 27 Workstation computer there is no validation happening post flash process, or at least its very subtle as you point out...
    When flashing an image using Etcher on my Windows 7 Enterprise SP1 computer, a validation step occurs post flash process, which roughly takes as much as the flash process itself.
     
     
    As can be seen in the below link, the Ubuntu Artful image does cause the red LED to blink during boot up and turn off once the boot process is finished.
     
    Artful-minimal-rock64-0.5.15-136-arm64 - Boot up LEDs
     
    The Armbian image on the other hand, does not have the same behavior and the red LED just remains on the whole time, which is expected behavior according to this post (your response)
     
    Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124 - Boot up LEDs
     
    I wrongfully assumed that the red LED on the Rock64 had the same behaviour as the green one on the the Raspberry Pi 3B as described below.
     
    Source.
     
     
    P.S.
     
    I noticed the Rock64 Armbian image is still in its testing phase...
    If there are certain tasks/test cases the good folks at Armbian would need extra help to test/implement, please let me know where I can sign up to help!