You've already forked documentation
mirror of
https://github.com/armbian/documentation.git
synced 2026-01-06 10:13:36 -08:00
Initial restructuring and cleanup
- dropping all deprecated sections - fix small link issues in documentation
This commit is contained in:
Igor Pecovnik
@@ -1,40 +0,0 @@
|
||||
# Armbian Governance
|
||||
|
||||
## Armbian Board Maintainers
|
||||
|
||||
You can see the current list of supported boards and their maintainers <a href="https://docs.armbian.com/Release_Board-Maintainers/">here</a>
|
||||
|
||||
## Armbian Platform Maintainers
|
||||
|
||||
| Area | Lead Maintainers | Maintainers | Acronyms, Codenames | additional info |
|
||||
|-------------------------------|-----------------|-------------------------------|---------------------------------|--------------------------------------|
|
||||
| Build Scripts | @Igorpecovnik | @The-going @iav @Miouyouyou @rpardini @150balbes | `/lib/*.sh` | code responsible for building images |
|
||||
| Armbian-Tools | @Igorpecovnik | @Miouyouyou @sgjava @TheLinuxBug | armbian-config, armbian-monitor | userland tools provided by Armbian |
|
||||
| Armbian-Tools: armbian-config | | | armbian-config | |
|
||||
| Multimedia/Desktops | | @JMCC @jernejsk @Miouyouyou | | |
|
||||
|
||||
## Additional Armbian Roles
|
||||
|
||||
| Area | Lead Maintainers | Maintainers | Acronyms, Codenames | additional info |
|
||||
|------------------------------|-----------------|----------------------------------------------------------|---------------------|-----------------|
|
||||
| Release Management | @Igorpecovnik @Heisath @TonyMac32 @TRS-80 | [Click to view the full list of Maintainers](https://docs.armbian.com/Release_Board-Maintainers/) | | |
|
||||
| Testing and Code Quality, CI | | @Igorpecovnik | | |
|
||||
| Security | | | | |
|
||||
| Documentation | @TheLinuxBug | @Werner @TRS-80 | | |
|
||||
| Community Engagement | @TheLinuxBug | @NicoD @Tido @Werner @TRS-80 | | |
|
||||
| Legal and Financial | @Igorpecovnik | | | |
|
||||
| Web and Infrastucture | | @TheLinuxBug @cats | | |
|
||||
| Forums moderation | @Werner | [Click to view the full list of Moderators](https://forum.armbian.com/members/2-moderators/) | | |
|
||||
| IRC, Discord | @Werner | | | |
|
||||
|
||||
## Community Governance Charters and Documentation
|
||||
<b>Coming soon!</b>
|
||||
|
||||
## Hackers Emeritus
|
||||
|
||||
Members who have stepped away from the project, but had a huge impact. We always welcome their contributions and wisdom.
|
||||
|
||||
* @TKaiser
|
||||
* @zador.blood.stained
|
||||
* @RNeese
|
||||
* @Lanefu
|
||||
@@ -1,3 +1,14 @@
|
||||
---
|
||||
title: Armbian Social Media Channels
|
||||
description: Social media channels maintained by Armbian project team
|
||||
---
|
||||
|
||||
# Social media
|
||||
|
||||
## Armbian on Twitter and Mastodon
|
||||
|
||||
Armbian short announcements are done via Twitter: <https://twitter.com/armbian> and <https://fosstodon.org/@armbian>
|
||||
|
||||
# IRC Channel / Discord / Matrix
|
||||
|
||||
## 👏 Overview
|
||||
|
||||
@@ -69,7 +69,7 @@ Usage:
|
||||
|
||||
# Build options
|
||||
|
||||
These parameters are meant to be applied to the `./compile.sh` command. They are **all** optional. They can also be added to your [build configuration file](/Developer-Guide_Build-Preparation/#providing-build-configuration) to save time. Default values are marked **bold** if applicable.
|
||||
These parameters are meant to be applied to the `./compile.sh` command. They are **all** optional. They can also be added to your [build configuration file](Developer-Guide_Build-Preparation.md#providing-build-configuration) to save time. Default values are marked **bold** if applicable.
|
||||
|
||||
## Main options
|
||||
|
||||
@@ -269,6 +269,6 @@ When selecting the zstd compression level (`zstd:[1-15]`), both the host and the
|
||||
- **AUFS** ( **yes** | no ): include support for [AUFS](https://en.wikipedia.org/wiki/Aufs)
|
||||
- **SKIP_BOOTSPLASH** ( yes | **no** ): use kernel bootsplash. Disable in case of troubles
|
||||
- **CONSOLE_AUTOLOGIN** ( **yes** | no ): automatically login as root for local consoles. Disable if your security threat model requires.
|
||||
- **EXT** (`fake-vcgencmd`): execute [extension](/Developer-Guide_Extensions/) during the build
|
||||
- **EXT** (`fake-vcgencmd`): execute [extension](Developer-Guide_Extensions.md) during the build
|
||||
- `fake-vcgencmd`: include [fake vcgencmd](https://github.com/clach04/fake_vcgencmd) to monitor and control boards from [Android](https://eidottermihi.github.io/rpicheck/)
|
||||
- **INCLUDE_HOME_DIR** ( yes | **no** ): include directories created inside /home in final image.
|
||||
|
||||
@@ -1,60 +0,0 @@
|
||||
# Allwinner A10 & A20 boards
|
||||
|
||||
## Overview
|
||||
|
||||
Both *legacy* and *current* kernels are stable and production ready and mostly sharing the same features through backports.
|
||||
|
||||
- **Note: Kernel 3.4.x has been dropped due to lacking upstream support which has ended in 2017.**
|
||||
|
||||
### Features
|
||||
|
||||
- Enabled audio devices: analog, 8 channel HDMI, spdif and I2S (if wired and enabled in HW configuration)
|
||||
- Bluetooth ready (working with supported external keys)
|
||||
- [Enabled overlayfs](/User-Guide_Advanced-Features/#how-to-freeze-your-filesystem-outdated) (outdated)
|
||||
- [I2C](https://en.wikipedia.org/wiki/I%C2%B2C) ready and tested with small 16×2 LCD. Basic i2c tools included.
|
||||
- SPI ready and tested with ILI9341 based 2.4″ TFT LCD display.
|
||||
- [Drivers for small TFT LCD](https://github.com/notro/fbtft) display modules.
|
||||
- [Clustering / stacking](https://en.wikipedia.org/wiki/Cluster_(computing))
|
||||
- Onboard LED attached to SD card activity (script.bin)
|
||||
- [Docker ready](/User-Guide_Advanced-Features/#how-to-run-docker)
|
||||
- Enabled audio devices: analog, SPDIF (if available) & USB
|
||||
- [USB / UAS](https://linux-sunxi.org/USB/UAS) – more efficient disk access over USB (A20 and H3)
|
||||
- [CAN bus](https://en.wikipedia.org/wiki/CAN_bus) – Controller Area Network
|
||||
- [USB OTG connector](https://linux-sunxi.org/USB_Gadget) – OTG or host mode
|
||||
- Bluetooth ready (working with supported external keys)
|
||||
- [I2C](https://en.wikipedia.org/wiki/I%C2%B2C) ready and tested with small 16×2 LCD. Basic i2c tools included.
|
||||
- Onboard LED attached to SD card activity (not enabled on all boards yet)
|
||||
|
||||
### Bugs or limitation
|
||||
|
||||
- NAND install sometime fails. Workaround: install [~~Lubuntu to NAND~~](http://dl.cubieboard.org/software/a20-cubietruck/lubuntu/) with [~~Phoenix tools~~](http://docs.cubieboard.org/downloads) and run install again. (Links no longer available - 27/01/21 Werner)
|
||||
- Shutdown results into reboot under certain conditions.
|
||||
- SATA port multiplier support is disabled by default, can be enabled by adding kernel parameter `ahci_sunxi.enable_pmp=1`
|
||||
- Screen output from kernel is set to HDMI by default. Boot loader can detect and switch, kernel not.
|
||||
|
||||
|
||||
## Desktop
|
||||
|
||||
[](https://www.youtube.com/watch?v=hsthqj90vTU "Armbian Desktop")
|
||||
|
||||
- HW accelerated video playback (if available)
|
||||
- MALI Open GLES (if available)
|
||||
- Pre-installed: Firefox, LibreOffice Writer, Thunderbird
|
||||
- Lightweight XFCE desktop
|
||||
- Autologin, when normal user is created – no login manager (/etc/default/nodm)
|
||||
|
||||
## Notes
|
||||
|
||||
### Setting non-standard monitor settings for A10, A20 and A31 based boards in u-boot
|
||||
|
||||
Following commands (example) needs to be executed in u-boot command prompt:
|
||||
```
|
||||
setenv video-mode sunxi:1024x768-24@60,monitor=dvi,hpd=0,edid=0,overscan_x=1,overscan_y=2
|
||||
saveenv
|
||||
```
|
||||
|
||||
Since environment is reset after flashing u-boot, you need to do this after every u-boot upgrade or put this to u-boot script
|
||||
|
||||
## Resources
|
||||
|
||||
[Armbian packages repository](https://www.armbian.com/kernel/)
|
||||
@@ -1,45 +0,0 @@
|
||||
# Allwinner H3 boards
|
||||
|
||||
## Overview
|
||||
|
||||
The H3 SoC from Allwinner is meant for OTT boxes and therefore its reference design is _not_ accompanied by a separate PMIC (power management IC) unlike _A series_ Allwinner SoCs (like A10, A20, A64, ...). No PMIC means also that there is no battery charging/monitoring implemented so H3 is not that much suited for mobile devices. On the other hand some pretty cheap H3 boards were released that can be driven with rather low consumption and therefore combining H3 devices with a battery became a real use case with boards like [Orange Pi One/Lite](https://linux-sunxi.org/Orange_Pi_Lite), NanoPi [NEO and Neo AIR](https://linux-sunxi.org/FriendlyARM_NanoPi_NEO).
|
||||
|
||||
As usual [SoC](https://linux-sunxi.org/H3) and [device information](https://linux-sunxi.org/Category:H3_Devices) can be found in Linux-sunxi wiki. Same applies to status of [mainlining kernel efforts](https://linux-sunxi.org/Linux_mainlining_effort). Adding to the usual SoC feature set (I2C, SPI, PWM, UART, SDIO, GPIO and so on) H3 has one USB OTG port, 3 real USB host ports (not exposed on all devices), Fast- and Gigabit Ethernet capablities (board specific), a Mali400MP2 GPU and Allwinner's video encoding/decoding engine.
|
||||
|
||||
When CPU or GPU cores are fully utilized H3 tends to overheat over time like any other popular ARM SoC released within the last 2-3 years. With Armbian we provide sane dvfs (dynamic voltage frequency scaling) settings that help a lot with throttling. In case you plan to operate your H3 device constantly under high load please check Armbian forums first since boards behave differently (related to voltage regulation and PCB size and design -- some use copper layers to spread the heat away from the SoC). Also consider applying a heatsink to the SoC (a fan should not be necessary unless you want to do number crunching on your board and then you obviously chose the wrong device).
|
||||
|
||||
You find some [differentiation criteria regarding supported H3 devices as well as an overview/history of H3 software support in our forums](https://forum.armbian.com/topic/1351-h3-board-buyers-guide/) or use Jean-Luc's [nice comparison table](https://www.cnx-software.com/2016/06/08/allwinner-h3-boards-comparison-tables-with-orange-pi-banana-pi-m2-nanopi-p1-and-h3-olinuxino-nano-boards/#comments) (both slightly outdated since more H3 devices have been released in the meantime).
|
||||
|
||||
## Kernel support
|
||||
|
||||
Almost all features of the H3 SoC are supported on Armbian's _current_ branch. Please refer to the [Linux sunxi support sheet](https://linux-sunxi.org/Linux_mainlining_effort).
|
||||
|
||||
## Default settings
|
||||
|
||||
- CPU frequency settings are 480 MHz to 1.37 GHz on most boards (cpufreq governor is _interactive_ therefore the boards only increase CPU speed and consumption when needed). Varity might occur due to different voltage regulators and heat dissipation behaviour. Theoretically lower frequencies are possible but disabled by default due to known stability issues.
|
||||
- Armbian unlike older/other H3 OS images uses the green led as 'power on' indicator (blinking means 'ready to login' or 'shutting down'), the red led (blue on NanoPis) can be used for your own purpose.
|
||||
|
||||
## Tips and tricks (general)
|
||||
|
||||
- An insufficient power supply **is the root cause of many weird symptoms/problems**. Never trust in ratings written on the PSU since they might be wrong, the PSU might be old/dying and cable/contact resistance adds to problems. In other words: Before you blame Armbian for strange behaviour please try at least one second power supply (this applies to both PSU and cable between PSU and board if this is separate -- especially USB cables really suck due to high resistance leading to severe voltage drops).
|
||||
- In case you experience instabilities check your SD card using `armbianmonitor -c $HOME` and think about installing [RPi-Monitor for H3](https://www.cnx-software.com/2016/03/17/rpi-monitor-is-a-web-based-remote-monitor-for-arm-development-boards-such-as-raspberry-pi-and-orange-pi/) to get an idea whether you suffer from overheating (`sudo armbianmonitor -r` will install everything needed).
|
||||
- Especially for desktop images the speed of your SD card matters. If possible try to use our _armbian-install_ script to move the rootfs away from SD card. The script also works with USB disks flawlessly ([some background information](https://forum.armbian.com/topic/793-moving-to-harddisk/)).
|
||||
|
||||
## Tips and tricks (H3 specific / lowering consumption) (outdated)
|
||||
|
||||
Recent research showed that H3 boards operated as wired IoT nodes need way less power compared to Raspberry Pis in the same situation (ethernet active). If you want to use your H3 device headless (server/IoT) and care about power consumption then there exist a couple of tweaks to get your board being more energy efficient when using in the meantime unsupported 3.x kernel (no tests done yet with up-to-date _legacy_/_current_ kernel):
|
||||
|
||||
- Disabling HDMI/GPU saves ~200mW.
|
||||
- Allowing to temporarely only negotiate a Fast Ethernet connection on GbE capable boards saves +350 mW.
|
||||
- Adjusting DRAM clockspeed is surprisingly another way to control consumption (on NanoPi NEO for example changing DRAM clockspeed between 132 MHz and 672 MHz results in consumption differences of 470mW).
|
||||
- Limiting maximum CPU clockspeed will help with lowering maximum consumption (think about scripts running amok or something going terribly wrong), the same applies to limiting the count of active CPU cores.
|
||||
- Choosing a board with Fast instead of Gigabit Ethernet or disabling GbE on the latter using `ethtool` or `ifconfig` saves at least 150 mW (board specific).
|
||||
|
||||
As an example: We chose default Armbian settings for NanoPi NEO to ensure this board is not able to exceed 2W consumption when running with no peripherals connected. This resulted in CPU and DRAM clockspeed of just 480/408 MHz while _booting_ (the first ~20 seconds). In normal operation we limit maximum CPU clockspeed to 912 MHz to stay below the 2W consumption barrier even in worst case scenarios.
|
||||
|
||||
In case you want to have a few more percent maximum CPU performance you would need to set maximum cpufreq to 1200 MHz instead of 'just' 912 MHz maximum CPU clock using our new [h3consumption tool](https://forum.armbian.com/topic/1878-testers-wanted-h3consumption-to-be-included-into-future-armbian-releases/). Be warned: This will both heavily increase consumption and SoC temperature since exceeding 912 MHz CPU clockspeed means feeding the SoC with 1.3V instead of 1.1V core voltage (most smaller H3 devices use a voltage regulator only switching between two voltages to feed the SoC based on load).
|
||||
|
||||
Walking this route in the other direction is more interesting: In case you want to use an H3 device as IoT node you might want to limit both idle and maximum consumption. That should involve disabling stuff not needed (eg. HDMI/GPU since this saves 200mW) or limiting ressource consumption: Lowering maximum clockspeeds for both CPU and DRAM or even disabling CPU cores (which helps _not_ with idle consumption since ARM cores enter low-power modes if not needed but can help lowering maximum consumption requirements).
|
||||
|
||||
Since all of this stuff is based on recent research and being still WiP please consider reading through relevant threads in Armbian forums **and** join development/research/discussions: [SBC consumption/performance comparisons](https://forum.armbian.com/topic/1748-sbc-consumptionperformance-comparisons/) and [Default settings for NanoPi NEO/Air](https://forum.armbian.com/topic/1728-rfc-default-settings-for-nanopi-neoair/).
|
||||
|
||||
@@ -1,10 +0,0 @@
|
||||
# Allwinner H5 and A64 boards
|
||||
|
||||
## Overview
|
||||
|
||||
[See the generic Allwinner page](https://docs.armbian.com/Hardware_Allwinner/)
|
||||
|
||||
## Warning
|
||||
|
||||
Using the board without cooling in conjunction with the stable release of Ambian using kernel 5.4.y there is a risk of the board getting **permanently damaged** due to overheating.
|
||||
If you decide to try the board without cooling, you can use `sudo armbianmonitor -r` to keep an eye on the temperatures.
|
||||
@@ -1,24 +0,0 @@
|
||||
# Allwinner H6
|
||||
|
||||
See also [generic Allwinner page](https://docs.armbian.com/Hardware_Allwinner/),
|
||||
|
||||
## CPU frequency
|
||||
|
||||
<del>The H6 CPU frequency has ben soft-capped at 1,48 GHz to avoid thermal throttling too fast. This limit can be lifted by editing
|
||||
`/etc/default/cpufrequtils` and set `MAX_SPEED` to `1810000`.</del>
|
||||
With the release of Armbian 20.05 "Kagu" new thermal zones have been added making this limitation obsolete and therefore has been removed. All H6 boards now clocking at the highest possible value OOB.
|
||||
|
||||
**Warning**
|
||||
Adding proper cooling is highly recommended.
|
||||
|
||||
## PCIe (un-)supported
|
||||
|
||||
Some H6 SoC based boards (like Pine H64 Model a, discontinued) are shipped with a PCIe slot. This slot **cannot** work out of the box as it has to be considered as broken by design. [Linux-Sunxi](https://linux-sunxi.org/H6#Errata) writes about this:
|
||||
|
||||
> Allwinner H6 has a quirky PCIe controller that doesn't map the PCIe address space properly (only 64k accessible at one time) to CPU, and accessing the PCIe config space, I/O space or memory space will need to be wrapped. As Linux doesn't wrap PCIe memory space access, it's not possible to do a proper PCIe controller driver for H6. The BSP kernel modifies the driver to wrap the access, so it's also not generic, and only devices with modified driver will work.
|
||||
|
||||
Icenowy is working on a wrapper to make PCIe work. Check [forums](https://forum.armbian.com/topic/13529-a-try-on-utilizing-h6-pcie-with-virtualization/).
|
||||
|
||||
## Networking
|
||||
|
||||
Trouble getting ethernet connection? Check [here](https://forum.armbian.com/topic/9368-orangepi-3-h6-allwiner-chip/page/32/?tab=comments#comment-105682)
|
||||
@@ -1,189 +0,0 @@
|
||||
# Generic howto for Allwinner devices
|
||||
|
||||
## Legacy or current kernel ?
|
||||
|
||||
Many Armbian images come in two flavours : _Legacy_ (using an older kernel version) and _current_ (up-to-date LTS kernel). Depending on kernel version, the procedure to enable/disable features is not the same.
|
||||
|
||||
* _Legacy_ kernel (5.4.x): DT (Device Tree) overlays
|
||||
* _Current_ kernel (5.10.x) : DT (Device Tree) overlays
|
||||
|
||||
**Note:** Support for older kernel versiones (like 3.4.x or 3.10.x) has been dropped.
|
||||
|
||||
### What flavour am I using ?
|
||||
|
||||
Best way to know is by checking your kernel version :
|
||||
|
||||
```
|
||||
root@bananapipro:~# uname -a
|
||||
Linux bananapipro 4.5.2-sunxi #11 SMP Thu Apr 28 21:53:25 CEST 2016 armv7l GNU/Linux
|
||||
```
|
||||
|
||||
In this example the kernel version is 4.5.2 so you can use DT to tweak some settings. If you get a kernel version 3.X then you'll be certainly using FEX like on an Orange Pi Plus 2E :
|
||||
|
||||
```
|
||||
root@orangepiplus2e:~# uname -a
|
||||
Linux orangepiplus2e 5.4.45-sun8i #10 SMP PREEMPT Wed Jun 1 19:43:08 CEST 2016 armv7l GNU/Linux
|
||||
```
|
||||
|
||||
## Enable Hardware Features
|
||||
|
||||
Some boards require some manual configuration to turn on/off certain features. In some cases, the procedure is "less than obvious", so we document some basic examples here.
|
||||
|
||||
### How to reconfigure video output?
|
||||
|
||||
This affect _current_ kernel only.
|
||||
|
||||
U-Boot supports HDMI and LCD output on Allwinner sunxi SoCs, LCD output requires the `CONFIG_VIDEO_LCD_MODE` Kconfig value to be set.
|
||||
|
||||
The sunxi U-Boot driver supports the following video-mode options:
|
||||
|
||||
- `monitor=[none|dvi|hdmi|lcd|vga|composite-*]` - Select the video output to use
|
||||
|
||||
- `none`: Disable video output.
|
||||
- `dvi/hdmi`: Selects output over the hdmi connector with dvi resp. hdmi output format, if edid is used the format is automatically selected.
|
||||
- `lcd`: Selects video output to a LCD screen.
|
||||
- `vga`: Selects video output over the VGA connector.
|
||||
- `composite-pal/composite-ntsc/composite-pal-m/composite-pal-nc`: Selects composite video output, note the specified resolution is ignored with composite video output.
|
||||
- Defaults to `monitor=dvi`.
|
||||
|
||||
- `hpd=[0|1]` - Enable use of the HDMI HotPlug Detect feature
|
||||
0: Disabled. Configure DVI/HDMI output even if no cable is detected
|
||||
1: Enabled. Fallback to the LCD / VGA / none in that order (if available)
|
||||
Defaults to `hpd=1`.
|
||||
|
||||
- `hpd_delay=<int>` - How long to wait for the HDMI HPD signal in milliseconds
|
||||
When the monitor and the board power up at the same time, it may take some time for the monitor to assert the HPD signal. This configures how long to wait for the HPD signal before assuming no cable is connected.
|
||||
Defaults to `hpd_delay=500`.
|
||||
|
||||
- `edid=[0|1]` - Enable use of DDC + EDID to get monitor info
|
||||
0: Disabled.
|
||||
1: Enabled. If valid EDID info was read from the monitor the EDID info will overrides the xres, yres and refresh from the video-mode env. variable.
|
||||
Defaults to `edid=1`.
|
||||
|
||||
- `overscan_x/overscan_y=<int>` - Set x/y overscan value
|
||||
This configures a black border on the left and right resp. top and bottom to deal with overscanning displays. Defaults to `overscan_x=32` and `overscan_y=20` for composite monitors, 0 for other monitors.
|
||||
|
||||
For example to always use the HDMI connector, even if no cable is inserted, using edid info when available and otherwise initalizing it at 1024x768@60Hz, use: `setenv video-mode sunxi:1024x768-24@60,monitor=dvi,hpd=0,edid=0`.
|
||||
|
||||
Parameters regarding video must be saved into U-Boot environment file since they must be read before reading boot script. You can do this by adding `saveenv` command at the end of boot script (boot.cmd). Remember to recompile boot.cmd to boot.scr and note that changes will come into action after second boot.
|
||||
|
||||
### Connect your LCD display
|
||||
|
||||
I tried three different display connection types: I2C, (4bit) parallel and SPI. All of them are working perfectly with my image. I didn’t took a picture of the third one. It’s a standard Hitachi HD44780 based 20×4 LCD, wired and tested [according to wiringBP example](https://github.com/LeMaker/WiringBP).
|
||||
|
||||
#### I2C
|
||||
|
||||
|
||||
|
||||
I am using [this code](https://github.com/vvromanov/cb_i2c_lcd) for mainline kernel and with [changed line](https://github.com/vvromanov/cb_i2c_lcd/blob/master/i2c_lcd.c#L28): /dev/i2c-%u = /dev/i2c-2 for Legacy kernel.
|
||||
|
||||
#### SPI
|
||||
|
||||
|
||||
|
||||
- I am using [2.4″ 240×320 SPI TFT LCD Serial Port Module+5/3.3V Pbc Adapter Micro SD ILI9341](https://www.google.com/search?q=2.4%E2%80%B3+240%C3%97320+SPI+TFT+LCD+Serial+Port+Module%2B5%2F3.3V+Pbc+Adapter+Micro+SD+ILI9341&oq=2.4%E2%80%B3+240%C3%97320+SPI+TFT+LCD+Serial+Port+Module%2B5%2F3.3V+Pbc+Adapter+Micro+SD+ILI9341)
|
||||
- Wire according to [this map](https://blog.riyas.org/2014/07/quickly-test-il9341-22-inch-22-spi-tft-raspbmc-fbtft.html).
|
||||
- You have to use Armbian 1.5 or newer. Currently working only under Legacy kernel.
|
||||
- Add this to your /etc/modules:
|
||||
`fbtft_device name=adafruit22a rotate=90 speed=48000000 fps=50 gpios=reset:25,led:19,dc:24`
|
||||
- Reboot
|
||||
- Test – display some picture on the screen:
|
||||
`fbi -d /dev/fb2 -T 1 -noverbose -a yourimage.jpg`
|
||||
|
||||
#### LVDS
|
||||
|
||||
<!---
|
||||
2020-11-25 link broken, but I did not want to remove fully -TRS-80
|
||||
|
||||
-->
|
||||
|
||||
Currently working only under Legacy kernel.
|
||||
|
||||
Image has pre-loaded settings for two LVDS display.
|
||||
|
||||
To enable 7 inch.
|
||||
|
||||
`ln -sf /boot/bin/bananapilcd7.bin /boot/script.bin`
|
||||
|
||||
To enable 5 inch.
|
||||
|
||||
`ln -sf /boot/bin/bananapilcd5.bin /boot/script.bin`
|
||||
|
||||
If you need touch screen support, add this module to your /etc/modules
|
||||
|
||||
`ft5x_ts`
|
||||
|
||||
#### Framebuffer
|
||||
|
||||
[Linux Framebuffer drivers for small TFT LCD display modules.](https://github.com/notro/fbtft/wiki)
|
||||
|
||||
## FEX (outdated/unsupported, informational only)
|
||||
|
||||
### Which file should I edit
|
||||
|
||||
Armbian embed a lot of BIN files, but a symlink point to the one in use :
|
||||
|
||||
```
|
||||
root@orangepiplus2e:~# ls -la /boot/script.bin
|
||||
lrwxrwxrwx 1 root root 22 Jun 1 20:30 /boot/script.bin -> bin/orangepiplus2e.bin
|
||||
```
|
||||
|
||||
### Updating a FEX
|
||||
|
||||
You may need to use `sudo` with all the following commands.
|
||||
|
||||
The whole process won't overwrite any of your files. If you're paranoid, you can make a proper backup of your BIN file :
|
||||
|
||||
```
|
||||
cp /boot/script.bin /boot/bin/script.bin.backup
|
||||
```
|
||||
|
||||
Then you can decompile your BIN into a FEX :
|
||||
|
||||
```
|
||||
bin2fex /boot/script.bin /tmp/custom.fex
|
||||
```
|
||||
|
||||
Finally you can edit your FEX file with your favorite text editor and compile it back to a BIN :
|
||||
|
||||
```
|
||||
fex2bin /tmp/custom.fex /boot/bin/custom.bin
|
||||
```
|
||||
|
||||
The last step is to change the symlink to use your custom BIN :
|
||||
|
||||
```
|
||||
ln -sf /boot/bin/custom.bin /boot/script.bin
|
||||
```
|
||||
|
||||
### H3 based Orange Pi, legacy kernel
|
||||
|
||||
#### Enable serial /dev/ttyS3 on pins 8 and 10 of the 40 pin header
|
||||
|
||||
Update the FEX configuration (which is compiled into a .bin) located at /boot/script.bin
|
||||
|
||||
Decompile .bin to .fex
|
||||
```
|
||||
cd /boot
|
||||
bin2fex script.bin > custom.fex
|
||||
rm script.bin # only removes symbolic link
|
||||
```
|
||||
|
||||
Edit .fex file
|
||||
```
|
||||
[uart3]
|
||||
uart_used = 1 ; Change from 0 to 1
|
||||
uart_port = 3
|
||||
uart_type = 2 ; In this case we have a 2 pin UART
|
||||
uart_tx = port:PA13<3><1><default><default>
|
||||
uart_rx = port:PA14<3><1><default><default>
|
||||
```
|
||||
|
||||
Compile .fex to .bin
|
||||
```
|
||||
fex2bin custom.fex > script.bin
|
||||
```
|
||||
|
||||
Reboot
|
||||
|
||||
Notice that /dev/ttyS3 appears. That is your new UART device.
|
||||
@@ -1,101 +0,0 @@
|
||||
# Cubox and Hummingboard boards
|
||||
|
||||
## Legacy
|
||||
System images with legacy kernel
|
||||
|
||||
- Kernel [3.14.x](https://github.com/linux4kix/linux-linaro-stable-mx6) with large hardware support, headers and some firmware included
|
||||
- [Docker ready](https://forum.armbian.com/topic/490-docker-on-armbian/) – [what is Docker](https://www.docker.com/why-docker/)?
|
||||
- PCI-E operational (Hummingboard Pro, Gate & Edge)
|
||||
- mSATA / m2 operational (Hummingboard Pro & Edge)
|
||||
- Enabled audio devices: HDMI, spdif, analogue
|
||||
- [Bluetooth ready](https://wiki.debian.org/BluetoothUser) (working with Cubox-i/HB PRO on-board device or external key)
|
||||
- [I2C](https://en.wikipedia.org/wiki/I%C2%B2C) ready and tested with small 16×2 LCD. Basic i2c tools included.
|
||||
- SPI ready and tested with ILI9341 based 2.4″ TFT LCD display.
|
||||
- [Drivers for small TFT LCD](https://github.com/notro/fbtft) display modules.
|
||||
- [USB redirector](https://www.incentivespro.com/usb-server-usage.html) – for sharing USB over TCP/IP (disabled by default /etc/init.d/rc.usbsrvd)
|
||||
|
||||
### Bugs or limitation
|
||||
|
||||
- Gigabit ethernet transfer rate is around 50% of its theoretical max rate (internal chip bus limitation)
|
||||
|
||||
## Mainline
|
||||
System images with mainline kernel
|
||||
|
||||
- [Mainline](https://www.kernel.org/) with large hardware support, headers and some firmware included
|
||||
- [Docker ready](/User-Guide_Advanced-Features/#how-to-run-docker) – [what is Docker](https://www.docker.com/why-docker/)?
|
||||
- PCI-E operational (Hummingboard Pro, Gate & Edge)
|
||||
- mSATA / m2 operational (Hummingboard Pro & Edge)
|
||||
- Enabled audio devices
|
||||
- Bluetooth ready (working with supported external keys)
|
||||
|
||||
### Set board type
|
||||
By default the mainline Hummingboard / Cubox-i Armbian images are configured for the Cubox-I with a dual or quad core
|
||||
SOM.
|
||||
|
||||
To run the image on another platform or SOM the correct device tree file needs to be specified. These files are stored in
|
||||
`/boot/dtb`. To set the correct device tree blow a `fdt_file=` parameter needs to be added to `/boot/armbianEnv.txt`.
|
||||
|
||||
Set the `fdt_file=` parameter according to the list below:
|
||||
|
||||
IMX6 Solo / DualLite:
|
||||
|
||||
- [Hummingboard] `fdt_file=imx6dl-hummingboard.dtb`
|
||||
- [Hummingboard v2] `fdt_file=imx6dl-hummingboard2.dtb`
|
||||
- [Cubox-I] `fdt_file=imx6dl-cubox-i.dtb`
|
||||
|
||||
IMX6 Dual / Quad:
|
||||
|
||||
- [Hummingboard] `fdt_file=imx6q-hummingboard.dtb`
|
||||
- [Hummingboard v2] `fdt_file=imx6q-hummingboard2.dtb`
|
||||
- [Cubox-I] `fdt_file=imx6q-cubox-i.dtb` (Default)
|
||||
|
||||
If a v1.5 SOM (with eMMC) is used the device tree names need to be changed, e.g.: `imx6q-cubox-i-som-v15.dtb` or
|
||||
`imx6q-cubox-i-emmc-som-v15.dtb`.
|
||||
|
||||
### Bugs or limitation
|
||||
|
||||
- Gigabit ethernet transfer rate is around 50% of its theoretical max rate (internal chip bus limitation)
|
||||
|
||||
## Desktop
|
||||
|
||||
- Pre-installed: Firefox, LibreOffice Writer, Thunderbird
|
||||
- Lightweight XFCE desktop
|
||||
- Autologin, when normal user is created – no login manager (/etc/default/nodm)
|
||||
|
||||
## Connect your LCD display
|
||||
|
||||
I tried two different display connection types: I2C and SPI. Both are working perfectly with my image 2.6 or higher.
|
||||
|
||||
|
||||
|
||||
- I am using [2.4″ 240×320 SPI TFT LCD Serial Port Module+5/3.3V Pbc Adapter Micro SD ILI9341](https://www.google.com/search?q=2.4%E2%80%B3+240%C3%97320+SPI+TFT+LCD+Serial+Port+Module%2B5%2F3.3V+Pbc+Adapter+Micro+SD+ILI9341&oq=2.4%E2%80%B3+240%C3%97320+SPI+TFT+LCD+Serial+Port+Module%2B5%2F3.3V+Pbc+Adapter+Micro+SD+ILI9341)
|
||||
- Wire according to [this map](https://blog.riyas.org/2014/07/quickly-test-il9341-22-inch-22-spi-tft-raspbmc-fbtft.html).
|
||||
- You have to use Armbian 1.5 or newer. Currently working only under Legacy kernel.
|
||||
- Add this to your /etc/modules:
|
||||
`fbtft_device name=adafruit22a rotate=90 speed=48000000 fps=50 gpios=reset:67,led:72,dc:195 busnum=1`
|
||||
- Reboot
|
||||
- Test – display some picture on the screen:
|
||||
`fbi -d /dev/fb2 -T 1 -noverbose -a yourimage.jpg`
|
||||
- [Troubleshooting and settings for other displays
|
||||
LVDS](https://github.com/notro/fbtft/wiki)
|
||||
|
||||
## GPIO
|
||||
|
||||
[How to control HummingBoard GPIO from kernel space?](http://forum.solid-run.com/viewtopic.php?forum_uri=&t=2345&start=)
|
||||
|
||||
## Udoo Quad
|
||||
|
||||
- [Kernel 3.14.x](https://github.com/UDOOboard/linux_kernel) and [4.4.x](https://github.com/patrykk/linux-udoo) with some hardware support, headers and some firmware included
|
||||
- [Docker ready](https://forum.armbian.com/topic/490-docker-on-armbian/) – [what is Docker](https://www.docker.com/why-docker/)?
|
||||
- Wireless adapter with DHCP ready but disabled (/etc/network/interfaces, WPA2: normal connect, bonding / notebook or AP mode). It can handle between 40-70Mbit/s.
|
||||
- SATA operational
|
||||
- Enabled analogue (VT1613) and HDMI audio device
|
||||
|
||||
### Bugs
|
||||
|
||||
SATA & USB install not working on legacy kernel
|
||||
|
||||
## Udoo Neo
|
||||
|
||||
- [Kernel 3.14.x](https://github.com/UDOOboard/linux_kernel) with some hardware support, headers and some firmware included
|
||||
- Wireless adapter with DHCP ready but disabled
|
||||
@@ -1,66 +0,0 @@
|
||||
# Marvell Armada
|
||||
|
||||
## Helios4
|
||||
|
||||
### Overview
|
||||
|
||||
All builds provide 100% hardware support for Helios4.
|
||||
|
||||
### Build Version Status
|
||||
|
||||
#### Legacy
|
||||
|
||||
- U-Boot : Mainline 2019.04
|
||||
- Linux Kernel : Mainline 4.19.y
|
||||
|
||||
#### Current
|
||||
|
||||
- U-Boot : Mainline 2019.04
|
||||
- Linux Kernel : Mainline 5.4.y
|
||||
|
||||
### Known Limitations
|
||||
|
||||
* SDcard High Speed timing have compatibility issue with some brands.</br>
|
||||
Temporary workaround : Disable UHS option/support.</br>
|
||||
Can be manually enable, refer to the following [page](https://wiki.kobol.io/sdcard) (2020-11-25 link broken [archive](https://web.archive.org/web/20191113071529/https://wiki.kobol.io/sdcard/)).
|
||||
|
||||
* During SATA heavy load, accessing SPI NOR Flash will generate ATA errors.</br>
|
||||
Temporary workaround : Disable SPI NOR flash.</br>
|
||||
Can be manually enable, refer to the following [page](https://wiki.kobol.io/spi) (2020-11-25 link broken [archive](https://web.archive.org/web/20191113071543/https://wiki.kobol.io/spi/)).
|
||||
|
||||
### Notes
|
||||
|
||||
Find more details about hardware support and configuration on [Helios4 Wiki](https://wiki.kobol.io).
|
||||
|
||||
## Clearfog Pro/Base
|
||||
|
||||
### Overview
|
||||
|
||||
Both builds provide close to 100% hardware support, some slight differences are listed below.
|
||||
|
||||
### Build Version Status
|
||||
|
||||
#### Legacy/Current
|
||||
|
||||
- [Mainline kernel](https://www.kernel.org/) with large hardware support, headers and some firmware included
|
||||
- [Docker ready](/User-Guide_Advanced-Features/#how-to-run-docker)
|
||||
- Both mPCIe are operational and [convertible to mSATA](#converting-mpcie-to-msata), M2 operational
|
||||
- Added patch to unlock Atheros regulatory restrictions which unlock 5Ghz AP mode in cheap Atheros cards (ath9 driver)
|
||||
- Bluetooth ready (working with supported external keys)
|
||||
- [I2C](https://en.wikipedia.org/wiki/I%C2%B2C) ready. Basic i2c tools included.
|
||||
- [SPI](https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus) ready but untested.
|
||||
- SFP is working at up to 1GB/s even with faster fiber modules
|
||||
- SFP DDMI is operational (`sudo ethtool -m eth2`)
|
||||
|
||||
### Bugs or limitation
|
||||
|
||||
- all builds suffer from minor problems with specific mPCIe combinations. If you run into problems check [this test matrix](https://docs.google.com/spreadsheets/d/1izPD5XUzQC0ZZWb8FMBMkofN73w-m_6bjrtZK-zr_b4) for some known working/not working combinations.
|
||||
|
||||
### Converting mPCIe to mSATA
|
||||
|
||||
- To convert mPCIe to mSATA you have to enable the corresponding patches in [u-boot-mvebu](https://github.com/armbian/build/tree/master/patch/u-boot/u-boot-mvebu-dev). Afterwards rebuild u-boot with our build system and write the new u-boot to your boot medium. If you need assistance ask in the forum.
|
||||
|
||||
### Notes
|
||||
|
||||
- In case you ever run into troubles and ask for help in the forums please ensure to provide a serial console log (UART adapter on board accessible through Micro USB with 115200/8/N/1 settings)
|
||||
- The boards can boot from various sources that are adjustable with a DIP switch. Comprehensive information about the necessary preparations [available here](https://github.com/nightseas/arm_applications/blob/master/doc/getting_started_with_clearfog_base.md).
|
||||
@@ -1,48 +0,0 @@
|
||||
# Rockchip RK3399/RK3328 boards
|
||||
|
||||
## Graphics 3D hardware acceleration
|
||||
In mainline kernel, panfrost kernel driver paired with Mesa 22.0 (or more recent) provides excellent results, capable of 3D rendering and 2D composited user interfaces.
|
||||
Also Gnome and KDE compositors are perfectly usable out of the box.
|
||||
|
||||
There can be other issues like "unusual" screen resolutions like 1920x1200 are neither properly detected nor supported while classic *FullHD* 1920x1080 should be fine.
|
||||
|
||||
## USB-C
|
||||
The connector is supported and is capable of switching between USB and DP modes (tested on Orange Pi 4 LTS board).
|
||||
|
||||
## Overclock overlay
|
||||
The RK3399 can be overclocked at own risk. Use `rockchip-rk3399-opp-2ghz.dtbo` this.
|
||||
|
||||
# Rockchip RK322x/RK3288 boards
|
||||
|
||||
## Graphics 3D hardware acceleration
|
||||
In mainline kernel, panfrost (RK3288) or lima (RK322x) kernel drivers, paired with Mesa 22.0 (or more recent), provides excellent results, capable of 3D rendering and 2D composited user interfaces.
|
||||
Also Gnome and KDE compositors are perfectly usable out of the box.
|
||||
|
||||
Usually a wide range of resolutions is supported with these SoCs, due to custom HDMI timings imported in the kernel drivers through external patches from LibreELEC project. Resolution support has been reported to work up to 4k resolutions, but some unusual and uncommon setup may still have unexpected issues.
|
||||
|
||||
# Video Decoders for RK322x/RK3288/RK3328/RK3399 - updated March 2024
|
||||
|
||||
Video decoding is fully supported for these SoCs via kernel V4L2 stateless drivers like Hantro and rkvdec, though it requires userland support to be actually exploited.
|
||||
Userland support is provided by gstreamer or FFmpeg frameworks, but their support varies among distributions because some bits are still missing.
|
||||
For that reason, an experimental Debian/Ubuntu repository for Armbian is available at [https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/](https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/) to provide FFmpeg and MPV packages already compiled with the proper support for V4L2 stateless decoders.
|
||||
|
||||
Hardware available and Supported video decoders are:
|
||||
* h.264
|
||||
* h.265
|
||||
* VP8
|
||||
* VP9
|
||||
|
||||
Despite support level is getting better, at the moment of writing this documentation some bits are still moving for h.265 and VP9 and not finalized yet, though they should be usable and provide a good experience.
|
||||
|
||||
Also DRMPRIME support in the kernel is quite established right now and it is possible to have both full-screen and windowed hardware decoding.
|
||||
|
||||
Note: if you are asking about browsers, we are not there yet. Hardware video decoding and composition with existing graphics is a quite complex matter and all the actors in the pipeline should agree on the same protocols.
|
||||
|
||||
# Video Decoders for RK35xx series - updated March 2024
|
||||
|
||||
Support in the mainline kernel is not yet ready or have not been tested yet.
|
||||
These products have both rkvdec and Hantro IP (RK356x and RK3588 have Hantro G1) but there are no reports of their actual support or readiness.
|
||||
|
||||
# Video Encoders
|
||||
|
||||
All the SoCs above have Hantro IP which is capable of both decoding and encoding, but yet encoding support has not been tested and thus it is not known what is its state.
|
||||
@@ -1 +0,0 @@
|
||||
../README.md
|
||||
@@ -1,4 +1,14 @@
|
||||
# Release model
|
||||
# Rolling releases
|
||||
|
||||
Armbian makes daily rolliong releases which includes generating daily updates of stable kernels and daily releases of unstable kernels and userspace packages.
|
||||
|
||||
<https://github.com/armbian/build/releases>
|
||||
|
||||
Images are available at respective board download pages:
|
||||
|
||||
<https://www.armbian.com/download>
|
||||
|
||||
# Point releases
|
||||
|
||||
## Release Dates
|
||||
|
||||
|
||||
@@ -1 +0,0 @@
|
||||
User-Guide_Armbian_overlays.md
|
||||
@@ -1,16 +0,0 @@
|
||||
**Preparation**
|
||||
|
||||
Make sure you have a **good & reliable** SD card and a **proper power supply**. The XZ-compressed should be written with an approved imaging tool capable of validating the burn.
|
||||
|
||||
**Approved Imaging Tools**
|
||||
|
||||
* [USBImager](https://gitlab.com/bztsrc/usbimager) a lightweight cross-platform imaging tool
|
||||
* [Balena Etcher](https://www.balena.io/etcher/) an electron / node.js based cross-platform imaging tool [(may contain spyware)](https://github.com/balena-io/etcher/issues?q=is%3Aissue+spyware)
|
||||
|
||||
**Boot**
|
||||
|
||||
Insert SD card into a slot and power the board. (First) boot (with DHCP) takes up to 35 seconds with a class 10 SD Card and cheapest board.
|
||||
|
||||
**Login**
|
||||
|
||||
Login as **root** on HDMI / serial console or via SSH and use password **1234**. You will be prompted to change this password at first login. Next you will be asked to create a normal user account that is sudo enabled (beware of default QWERTY keyboard settings at this stage).
|
||||
@@ -1,45 +0,0 @@
|
||||
# Migration from Bananian to Armbian
|
||||
|
||||
*NOTE: THIS IS DEPRECATED*
|
||||
|
||||
While technically possible to do an **in-place** upgrade/crossgrade from latest Bananian release (or similar SBC distros) to Armbian currently there exists no tool helping with this and most probably will never exist. At the bottom is explained where to find ressources that help with a manual in-place upgrade but we start with outlining the problems and our recommendations:
|
||||
|
||||
## The challenges:
|
||||
|
||||
### SD cards wear out after a certain amount of data being written to
|
||||
|
||||
Only reasonable base for an migration to Armbian would be an updated Bananian installation (Bananian 16.04, already Debian Jessie based, Nico's 4.4 kernel). In case Bananian users are still on version 15.04 or earlier they need to upgrade to a more recent Bananian version anyway to move Bananian's base to Jessie. Such `apt-get dist-upgrade` tasks come with heavy write activity. Especially when planning a dist-upgrade to Stretch later this amount of random write activity on older/smaller SD cards might kill them. If the SD card is not brand new it's highly recommended to create a clone/backup first prior to every upgrade step. If the SD card is really old please be prepared that it might not survive an `apt-get dist-upgrade`.
|
||||
|
||||
### All hardware will die eventually
|
||||
|
||||
A lot of Bananian installations today have been running 24/7 for 3 years or even longer. While these little SBC are well suited for light-weight server tasks, the hardware can't exactly be called 'server grade'. Please keep this in mind if you're about to spend some time on a manual migration attempt that once you're done maybe your hardware will stop working few weeks/months later if it already runs +24 months.
|
||||
|
||||
### Hardware up to the task?
|
||||
|
||||
The vast majority of [boards Bananian runs on](https://www.bananian.org/hardware) is based on Allwinner's dual core A20 SoC which was a nice improvement over the first single-core Raspberry Pis few years ago but is pretty slow by today's standards. An awful lot of users (us Armbians **all** included) were excited by A20's 'native SATA' capabilities few years ago just to realize after purchase when using SATA attached storage that it's awfully slow and most probably the slowest 'native' SATA implementation existing (please wake up if in doubt and educate yourself [here](https://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/&do=findComment&comment=34192), [here](https://linux-sunxi.org/Sunxi_devices_as_NAS#Influence_of_the_chosen_OS_image_on_NAS_performance) or [here](https://forum.openmediavault.org/index.php/Thread/19871-Which-energy-efficient-ARM-platform-to-choose/?postID=154980#post154980). Important: combining Allwinner's crappy SATA implementation with port multipliers [is always wrong](https://github.com/armbian/build/issues/548#issuecomment-332918004)).
|
||||
|
||||
At the time of this writing (Oct 2017) Armbian supports +25 other ARM boards that show between 2 and 6 times better CPU performance than A20 devices. +20 boards we support show better network performance (A20 Gigabit Ethernet is not fully capable of 940 Mbits/sec in both directions). +15 boards support 2GB DRAM (a few even more just recently). And if you don't need Gigabit Ethernet you can get a new and fully supported board still better suited for light-weight server tasks than any Banana Pi for as less as $11 shipping included (check [this overview](https://forum.armbian.com/topic/1351-h3-board-buyers-guide/&do=findComment&comment=28169) please).
|
||||
|
||||
While this diversity of ARM species might be confusing the good news is: When Armbian is running on them they all behave the same.
|
||||
|
||||
## Alternatives to an in-place migration:
|
||||
|
||||
### Continue on same hardware but prevent SD card hassles
|
||||
|
||||
Especially if you run since years off the same SD card please be prepared that it might not survive an `apt-get dist-upgrade` and similar upgrade/crossgrade tasks. It's **strongly** recommended to clone/backup your card prior to every necessary upgrade step. Since this is time consuming and just a measure to prepare for what will happen in the future anyway (your SD card failing eventually -- if you're lucky immediately, if you're out of luck it will corrupt a lot of data dying slowly) a great idea is to buy a new one **now**. Please see [our community's collection of SD card performance tests](https://forum.armbian.com/topic/954-sd-card-performance/) and especially the 3 links at the top dealing with reliability concerns.
|
||||
|
||||
Once you bought a new, fast and hopefully reliable SD card, you should [test it according to our documentation](https://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card), then burn a fresh Armbian image on it and manually transfer data and settings from your Bananian installation. This way you preserve your current settings/data on the old Bananian SD card saving you also a lot of time/efforts to clone/backup stuff.
|
||||
|
||||
**Important note:** if you're interested in NAS use cases you could also choose an OMV image from official [download location](https://sourceforge.net/projects/openmediavault/files/) (all the ARM board images are now based on Armbian, funnily even the ones for Raspberry Pi)
|
||||
|
||||
### Replacing the hardware
|
||||
|
||||
If your Bananian installation has been running for years, you better think about evaluating new hardware now. As explained above, A20's SATA implementation is [awfully slow](https://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/&do=findComment&comment=34192) compared to good SATA implementations (Espressobin, Clearfog, Helios4) or even recent USB3 solutions, also Banana Pis can not saturate Gigabit Ethernet. It's almost 2018 now and we can choose from a variety of energy efficient boards more suited for the job.
|
||||
|
||||
[My](https://forum.armbian.com/profile/7-tkaiser/) personal strategy was turning the various A20 servers into backup devices now receiving btrfs snapshots from better suited ARM servers in the meantime. New installation on new board, carefully migrating settings from Bananas, Cubietrucks or Lime boards to new server, testing, testing, testing, new installation on A20 device, setting up btrfs send|receive, testing, testing, testing, done.
|
||||
|
||||
## In-place migration tipps:
|
||||
|
||||
Since there is no easy migration tool you can only rely on contents collected below https://github.com/armbian/build/issues/648 -- if you read carefully through we had some hope experienced Bananian users would be volunteering in providing an in-place upgrade tool from Bananian to Armbian but unfortunately to no avail. So 6 months after the problem came to our attention we're now providing this document to help those affected taking the right decisions. Still no need to hurry, Bananian receives bug and security fixes for another 6 months so take your time and evaluate carefully which way to choose.
|
||||
|
||||
Trivia: Anyone understanding german **will** enjoy Nico's refreshing [Rise and Fall of Bananian Linux](https://frank-mankel.de/kategorien/36-froscon/288-froscon-12) talk.
|
||||
@@ -153,7 +153,7 @@ Replace `eth0` with the name of your Ethernet Interface.
|
||||
|
||||
### Connecting to a wireless network
|
||||
|
||||
For connecting to a wireless network, you can use the same method as mention above for use with [`networkd` on minimal images](#connect-to-wireless-network). Just make sure to replace `renderer: networkd` with `renderer: NetworkManager`.
|
||||
For connecting to a wireless network, you can use the same method as mention above for use with [`networkd` on minimal images](#connecting-to-a-wireless-network). Just make sure to replace `renderer: networkd` with `renderer: NetworkManager`.
|
||||
|
||||
Alternatively, you can also use Network-Manager directly via the command line or GUI tools on your desktop:
|
||||
|
||||
|
||||
@@ -1,16 +0,0 @@
|
||||
To boot the image from USB flash:
|
||||
|
||||
- Write the image to a USB flash drive
|
||||
- Insert the flash drive into the USB3.0 port
|
||||
- Load the modified u-boot (from the Armbian image) using the UART method
|
||||
- Stop the default boot sequence
|
||||
- Execute in u-boot prompt: `run usbboot`
|
||||
|
||||
To flash the image to eMMC:
|
||||
|
||||
- Boot the image from USB flash
|
||||
- Write the image to eMMC using `dd` or other methods
|
||||
- Mount the eMMC partition and add a line `emmc_fix=on` to `/boot/armbianEnv.txt` file - this changes the DT during boot to switch from SD with card detect switch to a non-removable eMMC.
|
||||
- Unmount the eMMC partition and reboot
|
||||
|
||||
Please refer to [this](https://forum.armbian.com/topic/3072-clearfog-pro-emmc-requires-sd-card-to-detect-device/) forum thread for the USB boot details and [this](https://forum.solid-run.com/linux-kernel-and-bootloaders-f34/unstable-mmc-operation-with-upstream-kernel-t2986.html) thread for a discussion of known eMMC issues.
|
||||
@@ -1,16 +0,0 @@
|
||||
- manual flashing to latest u-boot is mandatory! [Download](https://dl.armbian.com/espressobin/u-boot/) the right boot flash for your board: 512,1G,2G, number of RAM chips and appropirate memory speeds. You can obtain numbers from current boot prompt. Copy this `flash-image-MEM-RAM_CHIPS-CPU_DDR_boot_sd_and_usb.bin` to your FAT formatted USB key, plug it into USB3.0 port and execute from u-boot prompt:
|
||||
|
||||
bubt flash-image-MEM-RAM_CHIPS-CPU_DDR_boot_sd_and_usb.bin spi usb
|
||||
|
||||
After updating your SPI flash with most recent "sd\_and\_usb" u-boot, you can boot from USB or SD card the exact same way.
|
||||
|
||||
- in case you came from stock boot loader or your boot environment was erased somehow, this is what you need to put into u-boot:
|
||||
|
||||
setenv initrd_addr 0x1100000
|
||||
setenv image_name boot/Image
|
||||
setenv load_script 'if test -e mmc 0:1 boot/boot.scr; then echo \"... booting from SD\";setenv boot_interface mmc;else echo \"... booting from USB/SATA\";usb start;setenv boot_interface usb;fi;if test -e \$boot_interface 0:1 boot/boot.scr;then ext4load \$boot_interface 0:1 0x00800000 boot/boot.scr; source; fi'
|
||||
setenv bootcmd 'run get_images; run set_bootargs; run load_script;booti \$kernel_addr \$ramfs_addr \$fdt_addr'
|
||||
saveenv
|
||||
- If you manage to crash your SPI, proceed with [SATA boot recovery](https://wiki.espressobin.net/tiki-index.php?page=Boot+ESPRESSObin+from+SATA+drive).
|
||||
- booting directly from SATA is currently broken.
|
||||
- rebooting works with 4.14.y and SD media while it is broken with SATA and USB (always stops)
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 754 KiB |
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user