Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

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

  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. Is it possible to update from Armbian Xenial to Bionic (kernel 4.4.162) or should I just re-flash the eMMC with Bionic ?
  4. 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).
  5. 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 netmask #gateway dns-nameservers 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
  6. @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!
  7. @pfeerick 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... 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... 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... 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.
  8. 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... 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...
  9. 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...