Jump to content

AnythingIsFine

Members
  • Posts

    9
  • Joined

  • Last visited

Posts posted by AnythingIsFine

  1. Hello,

     

    I am still facing the

    E: The repository 'http://apt.armbian.com bionic Release, is no longer signed.

     

     error message when attempting a

    apt update

     

    So far, I have tried:

     

    1. Waiting

    2. Re-adding the repository key as suggested by user "favorit800" in this thread.

    3. Setting the repository as "trusted" as suggested by "Jerry Jyrer" in this thread.

     

    None of the above have worked, I am running:
     

    ~$ cat /etc/armbian-release
    # PLEASE DO NOT EDIT THIS FILE
    BOARD=rock64
    BOARD_NAME="Rock 64"
    BOARDFAMILY=rockchip64
    BUILD_REPOSITORY_URL=https://github.com/armbian/build
    BUILD_REPOSITORY_COMMIT=baaefaf69-dirty
    DISTRIBUTION_CODENAME=bionic
    DISTRIBUTION_STATUS=csc
    VERSION=21.05.4
    LINUXFAMILY=rockchip64
    ARCH=arm64
    IMAGE_TYPE=user-built
    BOARD_TYPE=csc
    INITRD_ARCH=arm64
    KERNEL_IMAGE_TYPE=Image
    BRANCH=current
    
    
    
    ~$ uname -a
    Linux rock64 5.10.43-rockchip64 #21.05.4 SMP PREEMPT Wed Jun 16 08:02:12 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

     

    Any ETA regarding the repository signing ?

     

    Regards!

  2. I have just updated to the Armbian Buster legacy kernel 4.4.213-rockchip64  from kernel 4.4.192-rockchip64 using 'armbian-config' and noticed that the "/etc/default/cpufrequtils" is no longer present.

     

    From what I saw, the "/etc/init.d/cpufrequtils" script which is still enabled at boot up is still configured to source the above mentioned file (line 58), otherwise the variables "GOVERNOR" is set o "ondemand" and "MIN_SPEED" and "MAX_SPEED" are set to 0 which translates to 408MHz and !.51GHz respectively.

    From the script:

     

     24 # Which governor to use. Must be one of the governors listed in:
     25 #   cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
     26 #
     27 # and which limits to set. Both MIN_SPEED and MAX_SPEED must be values
     28 # listed in:
     29 #   cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
     30 # a value of 0 for any of the two variables will disabling the use of 
     31 # that limit variable.
    
     [...]
    
     57 if [ -f /etc/default/cpufrequtils ] ; then
     58     . /etc/default/cpufrequtils
     59 fi

     

    Shouldn't the "/etc/default/cpufrequtils" be created automatically post kernel update?

     

    P.S.

     

    The documentation on the download page states using 'sed' to changed values which implies an existing file.

     

     

     

  3. Hello,

     

    I've followed the steps on the Rock64 Armbian download page to enable overclock on my Rock64 running Armbian Xenial 5.60 (rock64 4.4.124-rk3328), yet I can't seem to increase the CPU clock frequency.

    I've also checked the Documentation-> Fine Tuning page where the same steps are listed.

     

    Steps:
     

    sed -i "s/MAX_SPEED=.*/MAX_SPEED=1510000/" /etc/default/cpufrequtils
    
    systemctl restart cpufrequtils

     

    I've checked the CPU frequency now and it looks like it's stuck at the default value.

     

    Shouldn't the new CPU frequency now be listed as 1.51GHz by the below commands ?

     

    rock64:~$ cpufreq-info -c 0
    cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
    Report errors and bugs to cpufreq@vger.kernel.org, please.
    analyzing CPU 0:
      driver: cpufreq-dt
      CPUs which run at the same hardware frequency: 0 1 2 3
      CPUs which need to have their frequency coordinated by software: 0 1 2 3
      maximum transition latency: 68.0 us.
      hardware limits: 408 MHz - 1.30 GHz
      available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.30 GHz
      available cpufreq governors: conservative, ondemand, userspace, powersave, interactive, performance
      current policy: frequency should be within 600 MHz and 1.30 GHz.
                      The governor "ondemand" may decide which speed to use
                      within this range.
      current CPU frequency is 600 MHz.
      cpufreq stats: 408 MHz:0.00%, 600 MHz:94.66%, 816 MHz:0.00%, 1.01 GHz:0.00%, 1.20 GHz:0.00%, 1.30 GHz:5.34%  (285924)


     

    pi@rock64:~$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
    408000 600000 816000 1008000 1200000 1296000
    pi@rock64:~$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    600000
    pi@rock64:~$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    1296000
    pi@rock64:~$

     

     

    I've found this post on the forum related to overclocking the Rock64, alas it does not specify the steps to increase the CPU frequency.

     

    *** I am aware of the issues that CPU overclocking might bring, yet I am willing to test stability and share the results and I already have a heat sink and 5V fan in place.

    *** I am using the official Rock64 PSU (5V DC at 3A).

     

  4. Hi,

     

    Just wanted to chime in here as I had a similar issue with a wifi adapter bought from Pine64.

    My issue began with the fact that the aforementioned adapter would just randomly lose connection to my wifi router and at that point I could not even see the device in the USB tree using the 'lsusb -t' command.

    In my case, I believe there was a hardware issue with the adapter I received so I decided on buying a new one, which used the same Realtek RTL8188EU chipset, namely a COMFAST CF-WU810N which works out of the box with the Rock64 in case anyone needs a compatible wifi adapter not sold by Pine64.

     

    More to the point of this thread, the configuration of the wireless interface on Armbian Xenial can also be done without the use of the "NetworkManager" service.

     

    •  Optional Step:

     

    I did not want to keep the horrid predictable/unique wireless interface name generated based on the device's MAC address so I added the below line in this file to assign it the name "wlan0".

    * Please note, you need to change the 'ATTR(address)' field with your device's MAC address and REBOOT your machine so the kernel assigns the new interface name.

    This change is reboot persistent and may be taken out by removing the "70-persistent-net.rules" file.

     

    $ cat /etc/udev/rules.d/70-persistent-net.rules
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="40:a4:3f:98:a1:xt", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="wlan0"
    $

     

    •  Mandatory Steps:

     

    Configure the wireless interface with a static IP address as below:

     

    $ cat /etc/network/interfaces.d/wlan0
    
    auto wlan0
    allow-hotplug wlan0
    iface wlan0 inet static
        address 192.168.1.10
        netmask 255.255.255.0
        #gateway 192.168.1.1
        dns-nameservers 192.168.1.1
        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
    $

     

    Next, you need to create the "wpa_supplicant.conf" file, where the details of your SSID (wIreless network name) are stored like below.

    * Please note, you must change the 2 letter "country" code to your specific country, and the "ssid" & "psk" parameters to your network's name and password.


     

    $ sudo cat /etc/wpa_supplicant/wpa_supplicant.conf
    
    ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
    update_config=1
    country=<YourCountryCode>
    
    network={
        ssid="YourWirelessNetworkName"
        key_mgmt=WPA-PSK
        psk="YourSecretPassword"
    }
    $

     

    The last step implies performing a link down/up of the interface.

     

    ip link set interface_name down && ip link set interface_name up

     

     

  5. @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.

     

    Quote

    I don't know what's happening on your side with the verification, since at least version 0.9 Etcher has done a verify/validate on a write after the write phase on both Linux and Windows, but it was very subtle... the progress bar would just run through a second time but would state it was verifying instead of writing. In a update (1.4.2 or 1.4.4?) that was pushed a couple weeks ago, the verify progress bar is a different colour now, making it more visible.

     

    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.

     

    Quote

    Side-note: Can you link to a image that does this 'led' flashing... I've been using the Xenial images (initially the minimal images, but now container ones) of ayufan's images since he started producing them and hadn't noticed any of them flash the either of the LEDs OOTB, other than ones that flash the SPI Flash memory chip. I seem to remember the Android ones doing that though. 

     

    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.

     

    Quote

    Check the ACT LED to determine if the Pi is booting
    The ACT LED is essential in determining if the Pi can actually read from the card. It indicates that it can read from the card by blinking, If the ACT LED doesn't blink quickly in an irregular pattern for at least twenty seconds, this indicates that the Pi cannot read from the SD card, and that booting is not taking place.

     

    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!
     

  6. @pfeerick

     

    Quote

    When you did the dd, did you do a sync afterwards to ensure the image had completely finished writing to the sd card?

     

    No, I did not issue a 'sync' after the 'dd' command was executed, but I waited a while before un-mounting the USB to eMMC adapter as I browsed the files that were flashed to it (certainly more than 3 minutes)

    I also waited after flashing the image with Etcher...

     

     

    Quote

    Armbian does not need a separate /boot partition, as the version of uboot it ships with supports ext4, hence they were able to get rid of that extra partition.

     

    I was not aware of this... Nevertheless, once I inserted the eMMC into my Rock64, it would not boot up, the white and red LEDs were constantly on as opposed to when booting Ubuntu Xenial/Artful when the red led was rapidly blinking indicating it found a bootable storage device and once it finished booting only the white LED would remain on...

     

     

    Quote

    Why does running Fedora Workstation mean that Etcher skips the verification/validation after writing? Are you running an older version, or have it turned off in the options?

     

    When I flashed images to microSD cards using on a Windows 7 machine, it also ran a "Verifying" step post flashing, this does not happen on Linux in my experience...

     

     

    Quote

    Etcher can read a xz compressed image (e.g. xenial-containers-rock64-0.6.27-196-arm64.img.xz) natively, without any need to extract the image from it. It cannot do the same for yet, although it has been discussed on their issue tracker as a possibility.

     

    I agree, but the Armbian image in question is compressed using '7zip' and as such you won't be able to flash it using Etcher unless you uncompress it beforehand. This is why I stated it would have been impossible for me to flash the compressed image to eMMC using Etcher.

  7. Firsly, thanks for your interest in my issue!

     

    @Igor

     

    I am afraid that's not possible, as I did not save the logs...

    In any case, no error was reported.

     

    @pfeerick

     

    I tried to flash the latest image of Armbian for Rock64, the very same one you pointed out.

    Here are the steps I undertook:

     

    1) Downloaded the latest Rock64 Armbian build.

    2) unzipped the image

    3)

    a. Attempted to flash the image using 'dd if=/path/to/armbian_rock64.img of=/dev/sdb bs=1M'

       The image was flashed on the eMMC card, but only the 1.1GB root partition, no '/boot' partition was created. It looked as if the image was simply copied as opposed to flashed...

     

    b. Formatted the eMMC card, this time I used Etcher (the Pine64 version from Github), and had the same result.

     

    To test if I was actually doing something wrong, I used Etcher to flash ayufan's Ubuntu Xenial to eMMC, it worked and it created the /boot partition along with the root partition as expected, tried again with ayufan's Ubuntu Artful image, worked as well...

     

    4) Etcher did not verify my image as I am running Fedora27 Workstation...

     

     

    Quote

    It's possible what was tripping you up is that ayufan's images are xz compressed, and Etcher can read then natively. It can't read the 7z archives natively, so you have to help it and extract the disk image from the archive before writing it.

     I unzipped the downloaded archive, albeit I used Fedora's native zip tool, not  '7zip'...but the image was uncompressed with no error reported.

     

    Also, the Etcher GUI will only list images (probabily by looking for the '.img' extension on the end of files) so unless you uncompress the downloaded file you won't be able to see it in Etcher, let alone flash it...

     

    I will try to flash with Etcher once more from a Windows7 machine on Monday, although I am sceptical to say the least...

    If all else fails I will use the "nand-sata-install" script to flash the image to eMMC and create an image out of that to share with others...

  8. Hello,

     

    I want to try out Armbian OS as opposed to Ubuntu Artful 17.10 on my Rock64, mainly to see how it compares(I am aware Armbian minimal for Rock64 is derived from Ubuntu Xenial, but I understand it's optimized for ARM CPUs)

     

    Long story short, I have a 32GB eMMC and a eMMC to USB adapter from Pine64 and would like to run Rock64 Armbian off it, but I was unable to simply flash Armbian to it using 'dd' or Etcher as with ayufan's Ubuntu images.

     

    I am aware it's possible to boot from an microSD card and use the "nand-sata-install" bash script to achieve this as described in the Armbian documentation, so I am inquiring if I can bypass using the microSD card.

     

    * I want to know if it's possible to flash Ubuntu Xenial 16.04 on my eMMC, mount it in my Rock64 and attempt to an build Armbian image, which I can later copy to a separate storage media and flash to my eMMC card.

    If this is indeed achievable, I will share the Armbian eMMC rock64 image for all to enjoy.

     

    Regards,

     

     

     

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines