All Activity

This stream auto-updates     

  1. Past hour
  2. Upgraded to #5.97.190916 an hour ago and noticed Thermal reading is back. Left the system complete idle for an hour. After hour, I noticed thermal reading of 58C while ambient is 26C. It has a good heatsink installed. I remember old days on the board when it was that hot or may be more in idle state.
  3. Today
  4. Indeed Try stock Solidrun builds? While Armbian_5.91_Cubox-i_Debian_buster_default_4.14.133 is more or less stock u-boot, stock kernel + few improvements.
  5. I don't know what you expect from that upgrade? Errors are kernel related and kernel will not be changed since Ubuntu does not provide it. Upstream user space upgrade scripts are outside our control. They can work or not. It's known bug but can't help in this area, not very familiar with imx6 and graphics drivers. I was looking for a solution some time ago, but ... not found, don't remember to what is this related to. Try around, if Librelec folks have done some progress with imx6 ... Perhaps its just a wrong kernel config. Or some parameter is needed ...
  6. So I did try a 5.3 kernel today, but the result does not look all to different from the 5.2 kernel available through apt already: http://ix.io/1Vr9 (is "etnaviv-gpu 130000.gpu: command buffer outside valid memory window" the cause of the Wayland failure?) All I did was checkout the repo, change 2 to 3 in the line KERNELBRANCH='branch:linux-5.2.y' in config/sources/cubox.conf, then run: ./compile.sh docker I had to answer a few questions about new kernel options, pretty much leaving all of them on default (usually N). Then I copied the debs from output/debs to the cubox (via scp), and installed them. So the build system is working nicely. Now I wonder what is the best way of updating to Ubuntu 19.04 (or 19.10 already)? I tried do-release-upgrade inside this Ubuntu 18.04 Armbian, but that lead to some errors:
  7. Hm, there are two ways to do that: You can try to chainload the u-boot binary from SD card with the help of the SPI u-boot. The SPL may check the presence of a SD card and try to load the u-boot binary from there instead of SPI flash. The first option requires some u-boot script hacking but should work with the existing firmware while the second option needs a modified SPL.
  8. Hello @balbes150 and Others, I'm able to boot my X96 (S905x) device from a SD card with linux builds (tried Armbian 5.91 and 5.96). However, when I tried to configure the device as Wifi Hotspot / Access Point (AP), facing issues with connecting or pairing to the AP. The device appears to be configured with SSID and a static IP. But, when I tried to pair another device to this SSID + Passcode, it fails - something like invalid passcode. Could you please help to resolve or provide leads to the solution? - Krish
  9. I recently had a similar issue with my Tinkerboard. I was still using the legacy 4.4 kernel. To solve it: 1, I booted another SD card with TinkerOS 2. Plugged in the SD with Armbian using a USB SD-card adapter 3. mounted /dev/sda1 the partition with Armbian 4. bind mounted /dev /run /proc and /sys on the Armbian filesystem 5. chrooted into Armbian 6. ran armbian-config 7. first switched to the 5.2 kernel, but that didn't boot either, then did above again, switched to 4.19 and Armbian was booting again!!
  10. I done some thing no bad on my 2 hotspot in routing mode with a script to manage IPTABLES rules The script firewall_rules.sh in /etc/init.d/ load pre-defined rules in /etc/firewall.d/ firewall_rules.sh
  11. I made several tests: 1. burn all the possible pairs of SPL / u-boot.img on the existing SDCard --> each time the same story: U-Boot 2018.01-armbian (Jul 07 2019 - 11:26:59 +0200) CPU: Freescale i.MX6Q rev1.2 1200 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 33C Reset cause: POR Board: MX6 Cubox-i Watchdog enabled DRAM: 2 GiB U-Boot SPL 2018.01-armbian (Jul 07 2019 - 11:26:59) Trying to boot from MMC1 2. take a new SDCard, dd the SPL.sdhc and u-boot.img.sdhc then use Etcher to burn "Armbian_5.91_Cubox-i_Debian_buster_default_4.14.133" on it, boot with no hard drive connected to the cubox-i: U-Boot 2018.01-armbian (Jul 15 2019 - 21:19:21 +0200) CPU: Freescale i.MX6Q rev1.2 1200 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 35C Reset cause: POR Board: MX6 Cubox-i Watchdog enabled DRAM: 2 GiB U-Boot SPL 2018.01-armbian (Jul 15 2019 - 21:19:21) U-Boot SPL 2018.01-armbian (Jul 15 2019 - 21:19:21) U-Boot SPL 2018.01-armbian (Jul 15 2019 - 21:19:21) U-Boot SPL 2018.01-armbian (Jul 15 2019 - 21:19:21) U-Boot SPL 2018.01-armbian (Jul 15 2019 - 21:19:21) U-Boot SPL 2018.01-armbian (Jul 15 2019 - 21:19:21) That is crazy! It seems no more possible to boot that cubox!??!
  12. I have tried on my OPi3 the latest 5.3 nightly Buster and Buster Minimal, trying with USB power and DC connector 3A PS. It crashed in all cases....
  13. Pihole Core update to 4.3.2 https://github.com/pi-hole/pi-hole/releases also fixed: - Fix for 404 error when browsing to http://pi.hole/ (without /admin) #2826
  14. I have two OPi1+ and both running fine on 5.3.0 and earlier ran fine on 5.2.x as well... Just updated one of those SBCs to the 5.3.0-sunxi64 kernel image I built earlier today (and is available to the public, see link below) and is booting fine.
  15. I know this doesn't exactly answer your question, but the only way (at least for me) to get a working image for OPiOnePlus is to either copy a dtb file from an older image (kernel 5.1.5 and older works for me) to the new erimages or edit the dtb file of newer images and copy over the cpu opp table values from an older image (5.1.5 and older) to the new image. Otherwise I'm just stuck with endless bootloops. Makes no difference if I built the image myself or downloaded a pre-built one.
  16. We used to have both, but maintaining both become too much when there is little help ... I would like to see both + some basic firewall config, but don't know when https://github.com/armbian/config/blob/master/debian-config-jobs#L513
  17. I usually keep the bridge mode for wifi spots with network connections must remain open during roanning The NAT mode is much easier to set up and the main limitation is that you can't open a network connection from network to the wifi I prefer the routing mode but and it's more complicated to set up
  18. For your interface naming there are new rules : https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/ch-consistent_network_device_naming Generally this new naming come with re-install and not update
  19. For hotspots, there are 3 modes : Bridge : Wifi IP address are in same range as your network and it's your DHCP deliver wifi IP address Routing : Wifi IP address are not in the same range as your network, wifi IP address are deliver per the hotspot ; your network must be "informed" the range IP of wifi ( routing table ) NAT : The wifi is full managed per the hotspot ; on your network you see only connection initiated per the hotspot Each mode have advantages and inconvenient, that depending your wifi using
  20. That's a pity, but good to know. So if I want my 16TB Volume to have checksums of file contents (against bit-rot), there's only ZFS left, with its own problems (not in kernel, eats a lot of Ram).
  21. Buy a new SD card and reinstall it with Armbian (the current version/origin or the new update) Restart your O-droid with the new SD card and do the basic config (name, network) With a SD/USB card reader, connect the old card to your O-dorid Retrieves what is still readable and makes the copies directly where is needed on the new SD card
  22. Wow, that table is a pain and a half to read! The image of the v7 and its description agree, but don't match the order of jumpers in the table. On the other hand, the image of the v5 and its jumpers disagree on which jumper is which, but one of them matches the table. Can you clarify which labeling you're using, and which direction of jumper you're calling "1" or "0"? This link would have me believe that the jumper next to the SATA connecter is toward the edge of the board, while the other two are toward the center - [J11, J3, J10] = [0, 1, 1] to boot from SATA if oriented with the printed labels, and [1, 1, 0] to boot from NOR. , And that "boot from SATA" link has the jumper settings in the 10, 3, 11 orientation, as opposed to the 11, 3, 10 orientation given in the big table of boot modes. How absolutely horrid! In Summary: The ports and interfaces page needs: - Reorganize the v7 table columns to match the order of the jumpers on the v7 board, either 10,11,3 or 3,11,10, but we don't know whether the columns are correct - Fix the callout on the v5 image to J10, J3, J11 - Reverse the labels on the v5 table columns so it's J10, J3, J11, but don't move the columns.
  23. Nice. New builds, including freshly released Linux 5.3.0, are ready.
  24. Now that Kernel 5.3 has seen the light I wonder where things stand if I'd build with these options " BOARD=orangepioneplus BRANCH=dev RELEASE=buster BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no " for OrangePiOneplus . I suppose a working image ( read: bootable ) can be build? Also can things rgd OPiOnePlus be moved to a matured status, or that needs to wait at least till a new LTS Kernel 5.4 will pop up somewhere in November ?
  25. @ManoftheSea Yes, as mentioned in my previous post, I came to the same conclusion. It seems that v5 cannot do it, but v7 can. I have already bought the v7 and now I am trying to get it to download the bootloader from from SD card. So far no luck. Also you are correct, my links are not applicable to the problem. However, I have no better links. I am unable to find any link with a description of how to download the bootoader from SD card, be it with espressobin v5 or with v7. The depictions and tables from the link you posted (http://wiki.espressobin.net/tiki-index.php?page=Ports+and+Interfaces#Boot_selection) also seems to be weird. If you look at the table for v7, all the boot modes (other than NOR) seem to have the same jumper setting. This cannot be correct. Also the order of jumpers for v7 is wrong in the table. The order on the real board is J3, J11, J10, which is quite irritating when using the table to check your settings. This goes further, the depictions and tables for the v5 are flat out wrong. The table says that "NOR boot" is J11=1, J3=0, J10=0, but to get it to boot from NOR flash I actually have to sett it to J11=0, J3=0, J10=1. This sucks and took some time to figure out. Long story short: I cannot find any source with a description of how to download the bootloader from SD card with espressobin v7. Maybe I should open a new thread for that.
  26. @Shirohige I see, you are correct the U-Boot can be loaded from alternate locations. I learned something. Your links, however, are describing loading Linux from U-Boot, and are not applicable to loading U-Boot itself. http://wiki.espressobin.net/tiki-index.php?page=Ports+and+Interfaces#Boot_selection This link tells me that a v5 board is unable to load U-Boot from SD card, while a v7 can. It appears neither version can do so from USB.
  27. Correct. https://docs.armbian.com/#what-is-armbian Usually longer than upstream. Kernel wise we are ahead. Kernel is always the best one - not tied to the particular build version (as this is the case with Debian or Ubuntu) and they are more polished. Support is defined this way https://docs.armbian.com/#what-is-supported For example, this board (since its very matured) is already stashed away. We don't deal specifically with it anymore. There will be nothing new, but changes for entire Allwinner (A20) family come to this board as well ... If you need something that is not at the download pages, you can easily build latest version on your own. Perhaps Debian Buster? Minimal, server or desktop? https://github.com/armbian/build
  1. Load more activity