Search the Community

Showing results for tags 'research'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Announcements & first aid
    • Announcements
    • Board doesn't start
  • Community forums
    • Common issues
    • Peer to peer technical support
    • Feature Requests
    • TV boxes
    • General chit chat
  • Bug tracker
    • Allwinner A20
    • Allwinner H2 & H3
    • Allwinner H5 & A64
    • Armada A388, A3700
    • Amlogic S905(x)
    • NXP (Freescale)
    • Rockchip 3288 & 3328
    • Other supported boards
  • Development
    • Allwinner H6
    • Rockchip 3399
    • Development

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 89 results

  1. Hello, following the recent thread on LibreElec forum about an unofficial image for rk3229 devices, I would like to make public the work made by me and @fabiobassa about bringing rk322x support to armbian. For those which are interested, at the moment it is available on github -> here <- It is still a work in progress status, but all the fundamentals are in place. Stability, performance and features have already reached an almost mature status. Most of the love has been poured into supporting and bringing up the legacy rockchip 4.4 kernel, but in the near future the goal is to fully support the mainline kernel. What works: Three tested rk322x tv box boards: MXQ-4K - target: xt-mx4vr-v01 Schishion V88 - target: xt-mx4vr-v01 MXQ-4K Pro target: r329q Should work flawlessy on boards with RK3228a, RK3228b and RK3229, with either DDR2 and DDR3 memories. RK3228a boards may have some issues on mainline kernel although. Mainline u-boot OPTEE provided as Trusted Execution Environment All 4 cores are working Ethernet Serial UART (configured at 115200 bps, not 1.5Mbps!) Thermals and frequency scaling OTG USB 2.0 port (also as boot device!) EHCI/OHCI USB 2.0 ports MMC subsystem (including eMMC, SD and sdio devices) Hardware video acceleration (fully supported via RKMPP on legacy kernel, partial support via hantro kernel driver on mainline) NAND is available only on legacy (but not as boot device due to mailine u-boot missing the rockchip NAND driver) SSV6051 wifi over SDIO only on legacy (crappy driver, it is blacklisted and requires to be removed from blacklist from /etc/modprobe.d/blacklist.conf) Full GPU acceleration on legacy kernel, mainline kernel has lima driver compiled in but X11 does not work with (you are still free to compile and install mali kernel driver on mainline yourself, until lima matures) U-boot boot order priority: first the sdcard, then the USB OTG port and eventually the internal eMMC; you can install u-boot (and the whole system) in the internal eMMC and u-boot will always check for images on external sdcard/USB first. Building: You can build your own image follow the common steps to build armbian for other tv boxes devices (ie: when you are in the moment to choose the target board, switch to CSC/TVB/EOL boards and select "r329q" or "xt-mx4vr-v01" from the list). In case your board is not listed here, I suggest you to try with xt-mx4vr-v01 board, which has more chances to boot. Prebuilt images: If you don't want to build Armbian yourself, there are some prebuilt images already available: Armbian 20.05.0 Ubuntu Focal Desktop 20.04 - kernel 4.4.194 - xt-mx4vr-v01 board Armbian 20.05.0 Ubuntu Focal Desktop 20.04 - kernel 4.4.194 - r329q board Armbian 20.05.0 Debian Buster Minimal - kernel 5.4.21 - xt-mx4vr-v01 board (only RK3228b and RK3229) Armbian 20.05.0 Debian Buster Minimal - kernel 5.4.21 - r329q board (only RK3228b and RK3229) Quick installation instructions: If you already erased the internal eMMC, the board will boot from SD card. If you didn't, follow the instructions below to backup and/or erase the internal eMMC. As as alternative, there is a procedure using the libreelec bootloader described by @hexdump in a post below that does not require erasing the internal memory. flash the image on the sdcard, plug it in and plug the power cord. In alternative, you can burn the image directly to the eMMC (instructions below) Wait some seconds, the led should start blinking soon. HDMI output during u-boot is not available yet, so just wait for the kernel log and login prompt; the first time the boot process will take a couple of minutes or more because the filesystem is going to be resized. As usual, armbian default credentials are user: root password: 1234 Backup the existing firmware: You may want to first backup your existing firmware. You may do so using rkdeveloptool and maskrom/rockusb mode: Obtain a copy of rkdeveloptool: a compiled binary is available in the official rockchip-linux rkbin github repository. If you prefer, you can compile it yourself from the sources available at official rockchip repository Unplug the power cord from the tv box Plug an end of an USB Male-to-male cable into the OTG port (normally it is the lone USB port on the same side of the Ethernet, HDMI, analog AV connectors) Plug the other end of the USB Male-to-male cable into an USB port of your computer If everyting went well, using lsusb you should see a device with ID 2207:320b change directory and move into rkbin/tools directory, run ./rkdeveloptool rfi then take note of the FLASH SIZE megabytes (my eMMC is 8Gb, rkdeveloptool reports 7393 megabytes) run ./rkdeveloptool rl 0x0 $((FLASH_SIZE * 2048)) backup.data (change FLASH_SIZE with the value you obtained the step before) once done, the internal eMMC is backed up to backup.data file Restore the firmware: First we have to restore the original bootloader, then restore the original firmware. Running rkdeveloptool with these switches will accomplish both the jobs: ./rkdeveloptool db ../rk32/rk322x_loader_v1.04.232.bin Downloading bootloader succeeded. ./rkdeveloptool ul ../rk32/rk322x_loader_v1.04.232.bin Upgrading loader succeeded. ./rkdeveloptool wl 0x0 backup.data Write LBA from file (100%) Erase the eMMC and boot from SD: To let the boards boot from SD, we need to erase the internal eMMC/NAND. The SoC will first look for a bootloader in internal memory, it won't find anything and so will go further looking into external SD. Clearly you need to erase the internal eMMC/NAND just once. Obtain a copy of rkdeveloptool: a compiled binary is available in the official rockchip-linux rkbin github repository. If you prefer, you can compile it yourself from the sources available at official rockchip repository Unplug the power cord from the board Plug an end of an USB Male-to-male cable into the OTG port (normally it is the lone USB port on the same side of the Ethernet, HDMI, analog AV connectors) Plug the other end of the USB Male-to-male cable into an USB port of your computer If everyting went well, using lsusb you should see a device with ID 2207:320b run ./rkdeveloptool -ef and wait a few seconds once done, the internal eMMC is erased and the device will boot from the sdcard from now on Boot from the internal eMMC: You can burn the image directly to the internal eMMC so the device will boot without the extra SD card. You can do this step later using the included armbian-config utility which transfers the whole running system on the internal eMMC, so I suggest to first try booting from the sdcard using the other method. Most of the procedure is similar to the above: Obtain a copy of rkdeveloptool: a compiled binary is available in the official rockchip-linux rkbin github repository. If you prefer, you can compile it yourself from the sources available at official rockchip repository Unplug the power cord from the board Plug an end of an USB Male-to-male cable into the OTG port (normally it is the lone USB port on the same side of the Ethernet, HDMI, analog AV connectors) Plug the other end of the USB Male-to-male cable into an USB port of your computer If everyting went well, using lsusb you should see a device with ID 2207:320b Decompress the Armbian image you downloaded run ./rkdeveloptool wl 0x0 <armbian-image.img> once done unplug the USB cord and then plug back the power cord Note: rockchip devices cannot be bricked. If the internal flash does not contain a bootable system, they will always boot from the sdcard. If, for a reason, the bootable system on the internal flash is corrupted or is unable to boot correctly, you can always force the maskrom mode shorting the eMMC clock pin on the PCB. Just google around if you get stuck on a faulty bootloader, the technique is pretty simple and requires a simple screwdriver. I will continue to work on this project and refine both the legacy and mainline kernel and when the support will be in the same ballpark as other targets I will ask @Igor if it is a good idea to merge it into the main armbian repository. Critics, suggestions and contributions are welcome! Credits: @fabiobassa for his ideas, inspiration, great generosity in giving the boards for development and testing. The project of bringing rk322x into armbian would not have begun without his support! Justin Swartz, for his work and research to bring mainline linux on rk3229 (repository here) @knaerzche for his great contribution to libreelec support and mainline patches
  2. Hi, A small discussion started here, but I would like to lift it to here. The question and tests should be. Are there alternatives to Etcher? A must was - standard writing verification. IIRC this was back in the days an option you had to set a 'tick' on Win32 DiskImager.. and so not an option. Before we change anything - proper testing and writing down the steps to achieve a great result is a must. Multiplatform, would be nice, but we can as well recommend 2 or 3 SDcard writing programs. Can you please help to write a table of available programs (you can do a table in the forum, but consider quantity of lines & rows first). And whether or not the software is an equivalent replacement for armbian? Please help us to collect here your knowledge and expericence Of course your recommendation should support the minimum mentioned above - otherwise it is not a recommendation but Spam Thank you in advance for your participation on this challenge
  3. Found an old (2015) Ugoos UT3+ / UT3 Plus with an rk3288 - the neat thing about this board is it has HDMI-IN ! Also has PIP Specs: I'm was eventually able to successfully screen capture @ 1920 x 1080 ~29 fps using the Android 5.1.1 firmware V3.0.7 for UT3+ https://mega.nz/#!cQpl0ICS!8EgHddI3_PXQsSe-TSrkHfxdHCmkbckNWBYuLhfuA7w The firmware crashes frequently and the painful part is the IR remote is required to start recording.. so I'll be porting gentoo / armbian to this device to turn this paper weight into a linux friendly screen capture device. It maybe also worthwhile to document the process and create an armbian porting guide. Aside, for those interested, its worth to mention the LKV373A HDMI / ethernet sender is a potential $30 HDMI screen capture alternate.
  4. As we know, the PCIe on H6 is buggy, which doesn't offer linear address, and Linux cannot support such kind of configuration. However, the Cortex-A53 cores used by H6 supports virtualization, which can be used to change the order of the address space. Recently, I tried to make use of virtualization to provide linear mapping of PCIe, and I succeed in making an Intel 6205 wireless card working. The hypervisor code is at https://github.com/Icenowy/aw-el2-barebone . It's intended to start before U-Boot, and located at 0x40010000. A U-Boot fork that is patched to load the hypervisor is at https://github.com/Icenowy/u-boot/tree/h6-load-hyp , and a kernel that utilizes the wrapped PCIe (and patched to reserve memory for the hypervisor) is at https://github.com/Icenowy/linux/tree/h6-pcie-wrapped . In order to let the hypervisor start before U-Boot, BL31 needs to be built with `PRELOADED_BL33_BASE=0x40010000` in make parameter -- this will change the EL2 entrypoint to the hypervisor. Mainline ATF from ARM works. Contributions to the hypervisor is welcomed. (In addition, abusing virtualization in such way will prevent us from using KVM. But I think more people will want PCIe instead of KVM, right?)
  5. Since I've seen some really weird disk/IO benchmarks made on SBCs the last days and both a new SBC and a new SSD arrived in the meantime I thought let's give it a try with a slightly better test setup. I tested with 4 different SoC/SBC: NanoPi M3 with an octa-core S5P6818 Samsung/Nexell SoC, ODROID-C2 featuring a quad-core Amlogic S905, Orange Pi PC with a quad-core Allwinner H3 and an old Banana Pi Pro with a dual-core A20. The device considered the slowest (dual-core A20 with just 960 MHz clockspeed) is the fastest in reality when it's about disk IO. Since most if not all storage 'benchmarks' for SBC moronically focus on sequential transfer speeds only and completely forget that random IO is way more important on any SBC (it's not a digital camera or video recorder!) I tested this also. Since it's also somewhat moronically when you want to test the storage implementation of a computer to choose a disk that is limited the main test device is a brand new Samsung SSD 750 EVO 120GB I tested first on a PC whether the SSD is ok and to get a baseline what to expect. Since NanoPi M3, ODROID-C2 and Orange Pi PC only feature USB 2.0 I tested with 2 different USB enclosures that are known to be USB Attached SCSI (UAS) capable. The nice thing with UAS is that while it's an optional USB feature that came together with USB 3.0 we can use it with more recent sunxi SoCs also when running mainline kernel (A20, H3, A64 -- all only USB 2.0 capable). When clicking on the link you can also see how different USB enclosures (to be more precise: the included USB-to-SATA bridges used) perform. Keep that in mind when you see 'disk performance' numbers somewhere and people write SBC A would be 2MB/s faster than SBC B -- for the variation in numbers not only the SBC might be responsible but this is for sure also influenced by both the disk used and enclosure / USB-SATA bridge inside! The same applies to the kernel the SBC is running. So never trust in any numbers you find on the internet that are the results of tests at different times, with different disks or different enclosures. The numbers presented are just BS. The two enclosures I tested with are equipped with JMicron JMS567 and ASMedia ASM1153. With sunxi SBCs running mainline kernel UAS will be used, with other SoCs/SBC or running legacy kernels it will be USB Mass Storage instead. Banana Pi Pro is an exception since its SoC features true SATA (with limited sequential write speeds) which will outperform every USB implementation. And I also used a rather fast SD card and also a normal HDD with this device connected to USB with a non UASP capable disk enclosure to show how badly this affects the important performance factors (again: random IO!) I used iozone with 3 different runs: 1 MB test size with 1k, 2k and 4k record sizes 100 MB test size with 4k, 16k, 512k, 1024k and 16384k (16 MB) record sizes 4 GB test size with 4k and 1024k record sizes The variation in results is interesting. If 4K results between 1 and 100 MB test size differ you know that your benchmark is not testing disk througput but instead the (pretty small) disk cache. Using 4GB for sequential transfer speeds ensures that the whole amount of data exceeds DRAM size. The results: NanoPi M3 @ 1400 MHz / 3.4.39-s5p6818 / jessie / USB Mass Storage: Sequential transfer speeds with USB: 30MB/s with 1MB record size and just 7.5MB/s at 4K/100MB, lowest random IO numbers of all. All USB ports are behind an USB hub and it's already known that performance on the USB OTG port is higher. Unfortunately my SSD with both enclosures prevented negotiating an USB connection on the OTG port since each time I connected the SSD the following happened: WARN::dwc_otg_hcd_hub_control:2544: Overcurrent change detected ) ODROID-C2 @ 1536 MHz / 3.14.74-odroidc2 / xenial / USB Mass Storage: Sequential transfer speeds with USB: ~39MB/s with 1MB record size and ~10.5MB/s at 4K/100MB. All USB ports are behind an USB hub and the performance numbers look like there's always some buffering involved (not true disk test but kernel's caches involved partially) Orange Pi PC @ 1296 MHz / 4.7.2-sun8i / xenial / UAS: Sequential transfer speeds with USB: ~40MB/s with 1MB record size and ~9MB/s at 4K/100MB, best random IO with very small files. All USB ports are independant (just like on Orange Pi Plus 2E where identical results will be achieved since same SoC and same settings when running Armbian) Banana Pi Pro @ 960 MHz / 4.6.3-sunxi / xenial / SATA-SSD vs. USB-HDD: This test setup is totally different since the SSD will be connected through SATA and I use a normal HDD in an UAS incapable disk enclosure to show how huge the performance differences are. SATA sequential transfer speeds are unbalanced for still unknown reasons: write/read ~40/170MB/s with 1MB record size, 16/44MB/s with 4K/100MB (that's huge compared to all the USB numbers above!). Best random IO numbers (magnitudes faster since no USB-to-SATA bottleneck as with every USB disk is present). The HDD test shows the worst numbers: Just 29MB/s sequential speeds at 1MB record size and only ~5MB/s with 4K/100MB. Also the huge difference between the tests with 1MB vs. 100MB data size with 4K record size shows clearly that with 1MB test size only the HDD's internal DRAM cache has been tested (no disk involved): this was not a disk test but a disk cache test only. Lessons to learn? HDDs are slow. Even that slow that they are the bottleneck and invalidate every performance test when you want to test the performance of the host (the SBC in question) With HDDs data size matters since you get different results depending on whether the benchmark runs inside the HDD's internal caches or not. SSDs behave here differently since they do not contain ultra-slow rotating platters but their different types of internal storage (DRAM cache and flash) do not perform that different When you have both USB and SATA not using the latter is almost all the time simply stupid (even if sequential write performance looks identical. Sequential read speeds are way higher, random IO will always be superiour and this is more important) It always depends on the use case in question. Imagine you want to set up a lightweight web server dealing with static contents on any SBC that features only USB. Most of the accessed files are rather small especially when you configure your web server to deliver all content already pre-compressed. So if you compare random reads with 4k and 16k record size and 100MB data size you'll notice that a good SD card will perform magnitudes faster! For small files (4k) it's ~110 IOPS (447 KB/s) vs. 1950 IOPS (7812 KB/s) so SD card is ~18 times faster, for 16k size it's ~110 IOPS (1716 KB/s) vs. 830 IOPS (13329 KB/s) so SD card is still 7.5 times faster than USB disk. File size has to reach 512K to let USB disk perform as good as the SD card! Please note that I used a Samsung Pro 64GB for this test. The cheaper EVO/EVO+ with 32 and 64GB show identical sequential transfer speeds while being a lot faster when it's about random IO with small files. So you save money and get better performance by choosing the cards that look worse by specs! Record size always matters. Most fs accesses on an SBC are not large data that will be streamed but small chunks of randomly read/written data. Therefore check random IO results with small record sizes since this is important and have a look at the comparison of 1MB vs. 100 MB data size to get the idea when you're only testing your disk's caches and when your disk in reality. If you compare random IO numbers from crap SD cards (Kingston, noname, Verbatim, noname, PNY, noname, Intenso, noname and so on) with the results above then even the slow HDD connected through USB can shine. But better SD cards exist and some pretty fast eMMC implementations on some boards (ODROID-C2 being the best performer here). By comparing with the SSD results you get the idea how to improve performance when your workload depends on that (desktop Linux, web server, database server). Even a simple 'apt-get upgrade' when done after months without upgrades heavily depends on fast random IO (especially writes). So by relying on the usual bullshit benchmarks only showing sequential transfer speeds a HDD (30 MB/s) and a SD card (23 MB/s) seem to perform nearly identical while in reality the way more important random IO performance might differ a lot. And this solely depends on the SD card you bought and not on the SBC you use! For many server use cases when small file accesses happen good SD cards or eMMC will be magnitudes faster than HDDs (again, it's mostly about random IO and not sequential transfer speeds). I personally used/tested SD cards that show only 37 KB/s when running the 16K random write test (some cheap Intenso crap). Compared to the same test when combining A20 with a SATA SSD this is 'just' over 800 times slower (31000 KB/s). Compared to the best performer we currently know (EVO/EVO+ with 32/64GB) this is still 325 times slower (12000 KB/s). And this speed difference (again: random IO) will be responsible for an 'apt-get upgrade' with 200 packages on the Intenso card taking hours while finishing in less than a minute on the SATA disk and in 2 minutes with the good Samsung cards given your Internet connection is fast enough.
  6. Hi there, I am about to use an OrangePi Zero to handle the temperature and display some information on a custom contraption related to network. The problem I have is that this contraption will be powered on and powered off at will, without notice. So... I guess that after some time, the Zero running Armbian won't be that happy about being shut off brutally. I have seen some setups with supercapacitors for Raspberry Pis, but has anyone in here tried something similar with the OrangePi Zero? Or anything else that would delay the power loss, so that the board can shutdown properly? I made searches about supercapacitors with Armbian, but only found some information related to RTC (which would be nice to have too...). Thanks!
  7. Recently, a new SBC, the Rock Pi S by Radxa, was launched. Here's it's wiki page: https://wiki.radxa.com/RockpiS It's a 4 core A35 design. I'm debating getting one, but I can't find any information anywhere as to whether or not it's supported on Linux, or Armbian. Of course, if it's not listed in the download section it's not supported, but there's a difference between, "I need to add 100 lines of code and it will work." to "Geez, I need to redesign most of the Linux kernel after pulling my hair out." I did search the sunxi wiki and the local armbian wiki without success. Anyone know anything? Thanks!
  8. Hi, Armbian gurus, I'm trying to make the build system to build image with LibreELEC kernel tree for PineH64 I heard the kernel is patched for being better at hardware decoding Here are what I have done in order: 1. Retrieve patched kernel tree from LibreELEC build system. Upload the patched kernel tree to my gitlab account. 2. Modify config/sources/families/include/sunxi64_common.inc to make KERNEL_SOURCE = my previous repo; KERNELBRACH = master. To make it fetchable during bilding. 3. Modify lib/compilation-prepare.sh: skip aufs patch. 4. Modify lib/compilation.sh: skip advanced_patch in compile_kernel() After all these hassle, I can use compile.sh to build an Armbian 64 bit image with the 5.5.6 patched. BUT unfortunately, I flash the image and found it cannot boot properly. So here are my question: 1. How do you typically debug boot problem for PineH64. 2. Do you think anything could go wrong in those procedure? 3. Do I need to upgrade u-boot as well? It's using v2019.10 as far as I can tell. Thank you.
  9. Just got this error at the very end of a build. [ o.k. ] Checking git sources [ linux-firmware-git master ] fatal: unable to access 'https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/': The requested URL returned error: 504 [ .... ] Fetching updates fatal: unable to access 'https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/': The requested URL returned error: 504 [ .... ] Checking out error: pathspec 'FETCH_HEAD' did not match any file(s) known to git. I checked a very few minutes later and the URL https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ did eventually respond with a reasonable page, though with a huge delay. Presume that git.kernel.org had a problem, and returned the 504 error, not that the build system timed out waiting, but maybe wiser heads than me can check. If it was just lag, we may see a lot more of this sort of error, given the load on the internet at the moment.... Harry
  10. I have a supported build host running, and successfully building and testing kernels for a few targets that I have examples of. I'm looking to extend my repertoire to building complete armbian images. I think I also want to use EXTERNAL and/or EXTERNAL_NEW to configure additional packages into the image. This has led me to this stanza: BUILD_MINIMAL (yes|no): set to “yes” to build bare CLI image suitable for application deployment. This option is not compatible with BUILD_DESKTOP=”yes” and BUILD_EXTERNAL=”yes” I can find no BUILD_EXTERNAL referenced elsewhere, should this be simply EXTERNAL ? or have I missed something. Is there documentation on how EXTERNAL and EXTERNAL_NEW parameters are invoked? Harry
  11. Hello together, I need help to build a new ARMBIAN - Image based on DEBIAN fort this board: https://www.tq-group.com/de/produkte/tq-embedded/arm-architektur/stka8mx/ Can anyone help me with building, etc. for this board? Best regards Matthias
  12. Finally I got my lcd (some of them) to work with armbian on mainline kernel (5.4) using device tree overlay. It should be working on 4.19 kernel too. I test mine on orange pi zero. The one I am able to get working is ili9341 and st7735 based lcd. I'll add more detail later but for now I'd like to get this out. edit 1 : Adding ssd1306 and nokia 5110 overlay to the repo device tree overlay
  13. Dear Armbian community, we are looking for a low-power SBC with (deep sleep) / poweroff features for IoT applications. Arduino or any other MCU board are not suitable for doing our use cases, so we are investigating the use of an low-power SBC. i.MX6ULL (https://www.seeedstudio.com/NPi-i-MX6ULL-Dev-Board-Industrial-Grade-Linux-SBC-eMMC-Version-p-4221.html) has an integrated PMU with a lot of different low-power modes. Like SNVS mode, where only the power for the SNVS domain remain on. In this mode, only the RTC and tamper detection logic is still active This board is quietly new is there any possibility that this board can be supported by the Armbian community. Thankyou in advance. IMX6ULLIEC.pdf
  14. In my browsing I have just stumbled across this... https://tibbo.com/store/plus1.html Basic rundown Here are the key characteristics of the SP7021, the first member of the new PLUS1 line: Easy-to-use LQFP package. Quad-core 1GHz Cortex-A7 CPU, plus A926 and 8051 cores. Single 3.3V power*. Integrated 128MB or 512MB DDR3 DRAM. Eight 8-bit 5V-tolerant IO ports, plus one high-current port. Flexible Peripheral Multiplexing (PinMux). Dual PinMuxable Ethernet MACs. Four PinMuxable Enhanced UARTs, plus one console UART. Industrial operating temperature range: -40C ~ +85C. Low EMI simplifies certification. Modern, Yocto-based Linux distribution. Might do a bring up on a couple of boards and see how it goes... Just thought it was cool and others might find it that way too EDIT1: More detailed info can be found here https://sunplus-tibbo.atlassian.net/wiki/spaces/doc/overview
  15. Using systemd-networkd for network management on a small cluster of orangepi r1's and an orangepi zero. All are connected to a single TP-Link 8 port gigabit switch. Version of systemd-networkd is what is shipping in the current armbian buster image networkctl --version systemd 241 (241) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid All four devices are configured to emit lldp and to monitor lldp. All devices are emitting lldp, seen here from one of the four devices. netadmin@probe1:~$ tshark ether proto 0x88cc Capturing on 'eth0' 1 0.000000000 02:42:63:e3:6a:8f → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe2 2 13.009395698 02:42:45:92:9d:96 → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe3 3 13.999563625 02:42:1c:e9:eb:be → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe1 4 15.953929402 02:42:8e:41:09:de → LLDP_Multicast LLDP 103 TTL = 120 System Name = ups-monitor 5 30.255577659 02:42:63:e3:6a:8f → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe2 6 43.011986058 02:42:45:92:9d:96 → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe3 7 44.249476615 02:42:1c:e9:eb:be → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe1 8 45.954353503 02:42:8e:41:09:de → LLDP_Multicast LLDP 103 TTL = 120 System Name = ups-monitor 9 60.259316364 02:42:63:e3:6a:8f → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe2 10 73.014544815 02:42:45:92:9d:96 → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe3 11 74.249343777 02:42:1c:e9:eb:be → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe1 12 75.955214745 02:42:8e:41:09:de → LLDP_Multicast LLDP 103 TTL = 120 System Name = ups-monitor ^C12 packets captured netadmin@probe1:~$ However networkctl only ever shows two neighbors at the orangepi R1s and only one at the Orangepi zero (ups-monitor) netadmin@probe1:~$ networkctl lldp -a LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe3 .......a... eth0 \"probe3 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: o - Other; p - Repeater; b - Bridge; w - WLAN Access Point; r - Router; t - Telephone; d - DOCSIS cable device; a - Station; c - Customer VLAN s - Service VLAN; m - Two-port MAC Relay (TPMR) 2 neighbors listed. netadmin@probe1:~$ From an r1: netadmin@probe1:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe2 .......a... eth0 \"probe2 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: a - Station 2 neighbors listed. netadmin@probe1:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe3 .......a... eth0 \"probe3 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: a - Station 2 neighbors listed. netadmin@probe1:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe3 .......a... eth0 \"probe3 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: a - Station 2 neighbors listed. netadmin@probe1:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe3 .......a... eth0 \"probe3 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: a - Station 2 neighbors listed. netadmin@probe1:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe2 .......a... eth0 \"probe2 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: a - Station 2 neighbors listed. From the zero: netadmin@ups-monitor:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe1 .......a... eth0 \"probe1 uplink… Capability Flags: a - Station 1 neighbors listed. netadmin@ups-monitor:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe2 .......a... eth0 \"probe2 uplink… Capability Flags: a - Station 1 neighbors listed. netadmin@ups-monitor:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe2 .......a... eth0 \"probe2 uplink… Capability Flags: a - Station 1 neighbors listed. netadmin@ups-monitor:~$ tshark ether proto 0x88cc Capturing on 'eth0' 1 0.000000000 02:42:45:92:9d:96 → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe3 2 1.440290330 02:42:1c:e9:eb:be → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe1 3 4.231811986 02:42:8e:41:09:de → LLDP_Multicast LLDP 103 TTL = 120 System Name = ups-monitor 4 19.653023845 02:42:63:e3:6a:8f → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe2 5 30.282432096 02:42:45:92:9d:96 → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe3 6 31.720208055 02:42:1c:e9:eb:be → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe1 7 34.481361824 02:42:8e:41:09:de → LLDP_Multicast LLDP 103 TTL = 120 System Name = ups-monitor 8 49.931488643 02:42:63:e3:6a:8f → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe2 9 60.550552316 02:42:45:92:9d:96 → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe3 10 61.986085939 02:42:1c:e9:eb:be → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe1 ^C 11 64.480995938 02:42:8e:41:09:de → LLDP_Multicast LLDP 103 TTL = 120 System Name = ups-monitor 11 packets captured netadmin@ups-monitor:~$ It's as the neighbor table has one, and only one "neighbor" slot for each interface. Which seems crazy, but i'm not familiar enough with the code to check... Harry
  16. This "motd" fragment has a bug/inconsistency. # any changes will be lost on board support package update THIS_SCRIPT="armbian-config" MOTD_DISABLE="" /etc/defaults/armbian-motd has : # add space-separated list of MOTD script names (without number) to exclude them from MOTD # Example: # MOTD_DISABLE="header tips updates" This works correctly for the other "motd" fragments which contain, for instance : THIS_SCRIPT="sysinfo" MOTD_DISABLE="" but fails to disable 41-armbian-config unless the MOTD_DISABLE string includes armbian-config. I've verified that nothing untoward happens if you change 41-armbian-config to THIS_SCRIPT="config" MOTD_DISABLE="" and suppression then occurs correctly with /etc/defaults/armbian-motd set to: # add space-separated list of MOTD script names (without number) to exclude them from MOTD # Example: # MOTD_DISABLE="header tips updates" MOTD_DISABLE=" header tips updates config" ONE_WIRE="" # yes = show 1-wire temperature sensor if attached On a separate, but related note, I do use the 30-armbian-sysinfo script. However my version has a minimally modified output. My modified version first. System load: 0.02 0.01 0.00 Up time: 1:18 hour Memory usage: 29 % of 238MB Zram usage: 16 % of 119Mb IP: eth0: 192.168.1.5 CPU temp: 43°C Usage of /: 5% of 29G System load: 0.02 0.01 0.00 Up time: 1:18 hour Memory usage: 29 % of 238MB Zram usage: 16 % of 119Mb IP: 192.168.1.5 CPU temp: 44°C Usage of /: 5% of 29G Note the IP information starting on a new line, and the interface information included. netadmin@probe3:~$ diff ~/motd/30-armbian-sysinfo /etc/update-motd.d/30-armbian-sysinfo 141c141 < [[ -n $tmp ]] && ips+=("$intf: $tmp") --- > #[[ -n $tmp ]] && ips+=("$intf: $tmp") 143c143 < #[[ -n $tmp ]] && ips+=("$tmp") --- > [[ -n $tmp ]] && ips+=("$tmp") 199c199 < printf "\nIP: " --- > printf "IP: " I prefer my version. I'm very much a newbie on this board, I have no idea where to post the suggestion. Cheers Harry
  17. I've installed a wireless alarm system, but I want to use all my old wired stuff from my original alarm system. I started down the road of using an ESP8266, but GPIO.INT was flaky and GPIO pins limited, so I ordered a MCP23017 and figured Why not just do everything with one NanoPi Duo? I have a few of them and they are made for breadboard prototyping. Plus with the built in Ethernet I can have wired primary and wireless backup networking. I even rolled my own Ethernet adapter since the breakout adapters cost $5+. If you have already done this and have any wisdom to share I'd like to hear it. No turning back now!
  18. Hi, i own a Libre Computer Le Potato (AML-S905X-CC) board and i would like to compile my own customized kernel to try patches for bug fixing and experimenting unstable "features", like lima driver. The problem is that i currently use this board as daily driver and i would like the possibility to have a backup kernel (a stable one) in case something goes wrong. So the question is: it is possible to have multiple installed kernel and decide which one boot (like GRUB behaviour) using the uboot bootloader? If it is impossible, i'm sorry for the stupid question. I don't know how exactly the boot sequence works, from a low level point of view. Thanks a lot for the attention and the dedicated time.
  19. Good morning all, maybe someone could enlight me I own this box who internal board is a Q+ h6 version 3.0 . Despite of what is claimed ( 4 giga ram ) really the board is 2 giga ram. But the biggest problem is that the board is stick on Q logo and doesn't go further I have access to uart and when I try to flash new firmware, DOESN'T MATTER if I use phoenixsuite or the sd I have got this message: [18.838]nand not support! channel 0 chip 0: 2c 84 64 3c a9 04 00 00 [18.843]nand not support! channel 0 chip 1: 00 00 00 00 00 00 00 00 [18.849]nand not support! channel 0 chip 2: 00 00 00 00 00 00 00 00 [18.855]nand not support! channel 0 chip 3: 00 00 00 00 00 00 00 00 [18.861] no nand found ! [18.863]nand_physic_init nand_build_nsi error [18.867]nand_physic_init error -1 [18.870]NB1 : nand phy init fail [18.873]NB1 : enter phy Exit [18.876]nand_physic_exit [18.878]NAND_UbootProbe end: 0xffffffff [18.881]try nand fail [18.883]try spinor fail [18.885]flash init end initcall sequence 5ee50300 failed at call 4a00f9dc ### ERROR ### Please RESET the board ### well is clear that programming doesn't occur due failure on nand . But i would try to understand if I own the wrong firmware or effectively the internal nand is damaged So I flashed a SD with latest armbian Armbian_20.02.0-rc1.035_Aw-h6-tv_bionic_current_5.5.0-rc6_desktop_20200204.img and the board boots and run PERFECTLY. But I don't see the internal nand yet may be this armbian version doesn't support nand Please could you point me to right armbian version, if exist that can support internal NAND ? At least id I recognize the internal storage could have some e2fsck or doing other analysis ty in advance
  20. Tanix TX6 is H6 based Android TV Box and it can boot from SD cards prepared with PhoenixCard. It should be possible to make it work with Armbian too, right? I tried a recent Lite2 image, it didn't work, but it also didn't boot main Android, which means SD boot takes priority. I don't think it's a normal behavior for other Android TV boxes, but maybe it is for those with H6 boards.
  21. Where are the Odroid C1 images? This page is empty: https://dl.armbian.com/odroidc1/archive/ What is/was the latest stable Debian? I don't need Desktop but sound should work over HDMI. Its to bad the C1 has no support anymore. Seems to be the only board that does up to 384kHz Audio.
  22. I'm currently on the hunt for the cheapest decently reliable board to use for building a glusterfs cluster. Requirements are simple: GbE, SATA port, arm64, preferably low power. While helios64 is obviously the way to go for a NAS when it lands, it's totally overkill for a setup like this and I just realized that ODROID HC2 won't fly due to being 32-bit only. Most other 64-bit boards require expansion boards for SATA, which drags up the total cost. Finally I realized that the PC Engines APU boards fit all criteria, and come with what I understand to be performant GX-412TC CPUs. This one, for example, for 86EUR (maybe a bit on the pricey side, but I haven't found better actually): https://www.pcengines.ch/apu2d0.htm These boards are generally only used as router boards, and I am actually already using one as a router (which prevents me from doing tests myself right now unfortunately :P) Does anyone have any idea of if this is a Bad Idea or worth a shot? Looking at the specs I don't see an obvious reason why this wouldn't work. EDIT: While I guess an interesting topic to use these boards for other purposes, I realized now that the Espressobin looks more suitable at smaller size and lower cost at ~60EUR + shipping, so I think that's the best bet for now. EDIT2: Seems like GlusterFS has higher requirements than I thought and performs poorly with Gluster; this user got a measly 35Mbps (albeit with 5 disks): https://www.reddit.com/r/DataHoarder/comments/92zwct/espressobin_5drive_glusterfs_build_follow_up/. Redhat recommends 16GB minimum but surely it could be reasonable for home use with less... https://access.redhat.com/articles/66206 The APU has 2 instead of 4 cores and comes with in a 4GB version over the Espressobin's 2GB, so maybe it's the better alternative after all.
  23. I noticed that on the Duo I can select 5.5.0-rc6-sunxi in dev. Is there any idea when 5.5.0 will be the default release? Also, I noticed that there's no matching 5.5.x kernel source. I'm playing with linux-headers-dev-sunxi to see if I can compile libgpiod master which requires 5.5.0.
  24. Hi, I am testing mesa panfrost on RK3399 and I am facing an odd problem. When joint the chroot as root I get mesa working but if I join as pi, the user, I cant get it working and I've receive just a soft render (llvmpipe) How this could be fixed?? any experience??
  25. For the last few years I have been working on some hardware projects based on ARM SBCs. Every board I work with seems to have different kernel/overlay/GPIO/etc issues. So my question is - Which SBC, or chipset, has most complete and stable Armbian support? In other words if you had to pick a board to go into battle to run Armbian, without knowing any specific requirements, which SBC would it be?