https://linux-sunxi.org/api.php?action=feedcontributions&user=Karlp&feedformat=atomlinux-sunxi.org - User contributions [en]2024-03-28T17:20:27ZUser contributionsMediaWiki 1.35.8https://linux-sunxi.org/index.php?title=Fastboot&diff=25267Fastboot2023-02-10T15:02:30Z<p>Karlp: bootloader-version was always wrong, replaced in u-boot 29a81142b</p>
<hr />
<div>= Using fastboot on sunxi devices =<br />
<br />
Fastboot is a diagnostic protocol, primarily used to modify the<br />
filesystems on the flash device via USB or UDP. It requires that<br />
the device is started in a boot loader or Secondary Boot Loader mode.<br />
<br />
This document currently walks through an installation with a device<br />
with eMMC storage.<br />
<br />
== Prerequisites ==<br />
<br />
* fastboot binaries installed on client machine<br />
* sunxi-tools installed on client machine (optional)<br />
* u-boot tools (mkimage)<br />
* u-boot binaries for the target sunxi device<br />
* filesystem images:<br />
** root file system containing operating system<br />
** EFI partition (VFAT) for u-boot scripts<br />
* Sunxi device connected to client via OTG port<br />
<br />
== Getting your device into Fastboot mode ==<br />
<br />
To enter into fastboot mode, execute the `fastboot` command in<br />
U-Boot:<br />
<br />
fastboot usb 0<br />
<br />
On the client machine, you can check whether the device is visible<br />
using the `fastboot devices` command. And for fun, you can also<br />
fetch the bootloader version using the fastboot protocol:<br />
<br />
$ fastboot devices <br />
1234567890abcdef Android Fastboot<br />
$ fastboot getvar version-bootloader<br />
version-bootloader: U-Boot 2023.01-00003-g84563525cd<br />
Finished. Total time: 0.000s<br />
<br />
== Preparing the device for flashing ==<br />
<br />
{{alert|On some older devices booting directly from eMMC might fail due to BROM not supporting newer eMMC variants. To overcome this, some manufacturers are also populating the board with [[Bootable SPI flash|SPI EEPROM for storing the SPL and u-boot]], so you do not have to populate '''loader1/loader2''' partitions.}}<br />
<br />
Now that the device is in the fastboot mode, we can continue with<br />
creating the partitions on the device. By default, u-boot for sunxi<br />
defines following partitions:<br />
<br />
* loader1 - partition for SPL - secondary program loader (not needed for [[Bootable SPI flash|SPI-based bootloader]])<br />
* loader2 - partition for u-boot (not needed for SPI-based bootloader)<br />
* esp - EFI system partition (VFAT), for u-boot scripts (boot.scr)<br />
* system - Root partition for system<br />
<br />
These partitions have also assigned GUID's according to [https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ Discoverable Partitions Specification], to enable automatic discovery of partitions and their mountpoints.<br />
<br />
You can start by formatting the internal storage by executing the<br />
`fastboot oem format` command from client:<br />
<br />
fastboot oem format<br />
<br />
This equivalent to running the `gpt write mmc 1 $partitions` from u-boot.<br />
<br />
== Flashing the device ==<br />
<br />
Now that we have the partitions created, all that is left for us<br />
is to flash the data.<br />
<br />
`loader1` is used for storing the Secondary Program Loader, in our<br />
case, it is the `spl/sunxi-spl.bin` in the u-boot directory:<br />
<br />
fastboot flash loader1 spl/sunxi-spl.bin<br />
<br />
`loader2` is for storing the u-boot binary. Depending on architecture, it's either `u-boot.img` (for arm32) and `u-boot-sunxi-with-spl.fit.itb (for arm64) :<br />
<br />
fastboot flash loader2 <file..><br />
`esp` partition (EFI System Partition) can be kept empty, although<br />
if it is VFAT partition, u-boot automatically looks up the `boot.scr`<br />
file for device-specific configuration. (You can create empty vfat<br />
partition by `fallocate -l 32M esp.img && mkfs.vfat esp.img`)<br />
<br />
fastboot flash esp esp.img<br />
<br />
`system` partition is where the operating system resides. Creating<br />
that is left as an exercise to the reader.<br />
<br />
fastboot flash system system.img<br />
<br />
Now, if everything has been properly set up (aka proper kernel<br />
with machine-specific dtb installed on system.img, and boot.scr<br />
on esp partition), you can reboot the machine:<br />
<br />
fastboot reboot<br />
<br />
= See also =<br />
* [[U-Boot/USB_Mass_Storage|U-Boot USB Mass Storage Gadget]] as an alternative to getting system image into onboard storage</div>Karlphttps://linux-sunxi.org/index.php?title=CSI&diff=23488CSI2020-08-20T21:06:47Z<p>Karlp: link was broken, moved to current latest pointer. goal is always API->Interfaces->Sub device</p>
<hr />
<div>= CSI on mainline Linux with v4l2 =<br />
<br />
The CSI (CMOS Sensor Interface) hardware block is partially supported in mainline Linux.<br />
Support for the hardware block found on [[A31]] and later generations is already upstream,<br />
while the one found on [[A10]]/[[A20]] is being worked on, as of 2019/04/12.<br />
<br />
Currently parallel and BT.656 (embedded sync) interfaces are supported. MIPI CSI-2 is not.<br />
<br />
The mainline driver uses v4l2 with the sub-device API and media controller API.<br />
<br />
== Kernel config options ==<br />
To enable the driver, please first check if you have the '''VIDEO_DEV''', '''MEDIA_CONTROLLER''' and<br />
'''VIDEO_V4L2_SUBDEV_API''' Kconfig options enabled.<br />
<br />
Then once you enable '''V4L_PLATFORM_DRIVERS''' you should be able to enable '''VIDEO_SUN6I_CSI''' for the A31 CSI driver.<br />
For the A10/A20 CSI driver, enable '''VIDEO_SUN4I_CSI'''. (Provided you have the patches applied.)<br />
<br />
== Userspace configuration ==<br />
It is recommended to use an up-to-date version of v4l-utils, as older versions, such as the one in Debian Stable (1.12.x)<br />
has some bugs, and doesn't understand all formats or knobs.<br />
<br />
The usage of the media controller and sub-device API means configuration of the capture options<br />
is slightly complicated. The '''media-ctl''' and '''v4l2-ctl''' are used.<br />
<br />
=== Media bus and capture formats ===<br />
To see the current settings of the media bus, use<br />
<br />
<nowiki><br />
$ media-ctl --print-topology<br />
<br />
Media controller API version 5.1.0<br />
<br />
Media device information<br />
------------------------<br />
driver sun6i-csi<br />
model Allwinner Video Capture Device<br />
serial<br />
bus info<br />
hw revision 0x0<br />
driver version 5.1.0<br />
<br />
Device topology<br />
- entity 1: sun6i-csi (1 pad, 1 link)<br />
type Node subtype V4L flags 0<br />
device node name /dev/video0<br />
pad0: Sink<br />
<- "ov5640 1-003c":0 [ENABLED,IMMUTABLE]<br />
<br />
- entity 5: ov5640 1-003c (1 pad, 1 link)<br />
type V4L2 subdev subtype Sensor flags 0<br />
device node name /dev/v4l-subdev0<br />
pad0: Source<br />
[fmt:UYVY8_2X8/640x480 field:none]<br />
-> "sun6i-csi":0 [ENABLED,IMMUTABLE]<br />
</nowiki><br />
<br />
On systems with the Cedrus driver enabled, the media device may not be the default one, in which case you should use<br />
<br />
$ media-ctl --device /dev/mediaN --print-topology<br />
<br />
To set the capture format (including the bus format and capture size), you specify the properties of the source pad.<br />
<br />
$ media-ctl --set-v4l2 '"ov5640 1-003c":0[fmt:UYVY8_2X8/720x480]'<br />
<br />
Here the entity name '''"ov5640 1-003c"''' can also be replaced with the entity ID '''5'''.<br />
<br />
This configures a capture size of 720x480 pixels with the UYVY8_2X8 bus format, which is YUV 4:2:0.<br />
See [https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/subdev-formats.html Media Bus Formats] for a list and description of formats.<br />
<br />
The capture resolution specified here must match what is requested by the capture application,<br />
otherwise the kernel driver will report an error and refuse to capture.<br />
<br />
=== Sensor sub-device configuration ===<br />
Sensors can have a number of control knobs that can be configured from userspace. These range from image orientation to power line frequency to test patterns.<br />
<br />
To see the full list of control knobs along with menu item descriptions, use<br />
<br />
<nowiki><br />
$ v4l2-ctl --list-ctrls-menus<br />
<br />
User Controls<br />
<br />
contrast (int) : min=0 max=255 step=1 default=0 value=0 flags=slider<br />
saturation (int) : min=0 max=255 step=1 default=64 value=64 flags=slider<br />
hue (int) : min=0 max=359 step=1 default=0 value=0 flags=slider<br />
white_balance_automatic (bool) : default=1 value=1 flags=update<br />
red_balance (int) : min=0 max=4095 step=1 default=0 value=0 flags=inactive, slider<br />
blue_balance (int) : min=0 max=4095 step=1 default=0 value=0 flags=inactive, slider<br />
exposure (int) : min=0 max=65535 step=1 default=0 value=885 flags=inactive, volatile<br />
gain_automatic (bool) : default=1 value=1 flags=update<br />
gain (int) : min=0 max=1023 step=1 default=0 value=248 flags=inactive, volatile<br />
horizontal_flip (bool) : default=0 value=0<br />
vertical_flip (bool) : default=0 value=0<br />
power_line_frequency (menu) : min=0 max=3 default=1 value=1<br />
0: Disabled<br />
1: 50 Hz<br />
2: 60 Hz<br />
3: Auto<br />
<br />
Camera Controls<br />
<br />
auto_exposure (menu) : min=0 max=1 default=0 value=0 flags=update<br />
0: Auto Mode<br />
1: Manual Mode<br />
<br />
Image Processing Controls<br />
<br />
test_pattern (menu) : min=0 max=4 default=0 value=0<br />
0: Disabled<br />
1: Color bars<br />
2: Color bars w/ rolling bar<br />
3: Color squares<br />
4: Color squares w/ rolling bar<br />
</nowiki><br />
<br />
Note that if the system has multiple video devices, you may need to specify which one to use:<br />
<br />
$ v4l2-ctl --device=/dev/videoN --list-ctrls-menus<br />
<br />
To set an option, use<br />
<br />
$ v4l2-ctl --set-ctrl=vertical_flip=1<br />
<br />
Or multiple options at once<br />
<br />
$ v4l2-ctl --set-ctrl=power_line_frequency=2,vertical_flip=1,horizontal_flip=1<br />
<br />
== Capturing Images ==<br />
<br />
=== FFMpeg ===<br />
FFMpeg supports capturing from v4l2 devices. However it does not support configuration of the media bus or sub-devices.<br />
Please use the commands shown in the previous sections instead.<br />
<br />
To capture from the first video device, use<br />
<br />
$ ffmpeg -s WxH -i /dev/video0 output.mjpg<br />
<br />
This captures and encodes a video of W by H pixels from the first video device to an M-JPEG file.<br />
<br />
Note that W and H must match what you previously set with '''media-ctl'''. The system default is 640x480.<br />
<br />
If you also specified a different bus format, such as JPEG_1X8, you will need to tell FFMpeg as well, using<br />
<br />
$ ffmpeg -input_format mjpeg -s WxH -i /dev/video0 output.mjpg<br />
<br />
<br />
== Caveats / TODOs ==<br />
<br />
=== JPEG media bus format buffers ===<br />
The JPEG media bus format support in the driver does not trim the returned buffer.<br />
In other words, the full buffer is passed back to userspace, with trailing zeros.<br />
This means the user will end up with enormous JPEG files without post-processing.<br />
<br />
There are already several JPEG parsers in the kernel. A proposal was made to combine<br />
and generalize them, which could then be used in our CSI driver to detect the end<br />
of the JPEG stream. This has not been implemented yet.<br />
<br />
=== MIPI CSI-2 ===<br />
While a few Allwinner SoCs support MIPI CSI-2, details on the hardware is sparse.<br />
No one has attempted to support this yet.<br />
<br />
= BSP kernel supported camera's sensors table =<br />
{| class="wikitable"<br />
|-<br />
! scope="row" | Vendor !! Part Number !! Pixels !! Type !! Specification !! Focus !! AVDD !! DOVDD !! DVDD !! AFVCC !! NOTE<br />
|-<br />
| OmniVision || OV7670 || 0.3M || Photo/Video || 640*480@30fps<br />352*176@30fps<br />320*240@30fps<br />176*144@30fps || Fixed focus || 2.8 || 2.8 || 1.8 || NC || <br />
|-<br />
| OmniVision || OV2655 || 2M || Photo/Video || 1600*1200<br />800*600@30fps<br />640*480@30fps || Fixed focus || 2.8 || 2.8 || 1.5 || NC || Basic image can fine tune the effect<br />
|-<br />
| OmniVision || OV2643 || 2M || Photo/Video || 1600*1200<br />1280*760@30fps<br />640*480@30fps || Fixed focus || 2.8 || 2.8 || 1.5 || NC || Module FPC needs to be as short as possible <br />
|-<br />
| OmniVision || OV3660 || 3M || Photo/Video || 2048*1536@5fps<br />1600*1200@5fps<br />1280*720@30fps<br />640*480@30fps || Fixed focus || 2.8 || 2.8 || 1.8 || NC || <br />
|-<br />
| OmniVision || OV5640 || 5M || Photo/Video || 2592*1936@5fps<br />2048*1536@5fps<br />1600*1200@5fps<br />1280*960@5fps<br />1024*768@5fps<br />1920*1080@30fps<br />1280*720@30fps<br />640*480@30fps || Fixed focus/Autofocus || 2.8 || 2.8 || 1.5 || 2.8~3 || 1.OV5640 drive capability module selection FPC.<br />Need to be as short as possible.<br />2. Recommendation module model effects and auto-focus function is fine.<br />If the election of the other modules, and does not guarantee results.<br />
|-<br />
| OmniVision || OV5647 || 5M || Photo/Video || 5M@15fps<br />1080p@30fps<br />720p@30fps || Autofocus || 2.8 || 2.8 || 1.5 || 2.8 || <br />
|-<br />
| Micron || MT9V112 || 0.3M || Photo/Video || 640*480@30fps || Fixed focus || 2.8 || 2.8 || 1.8 || NC || <br />
|-<br />
| Micron || MT9M112 || 1.3M || Photo/Video || 1280*1024@15fps<br />640*512@30fps || Fixed focus || 2.8 || 2.8 || 1.8 || NC || <br />
|-<br />
| Micron || MT9M113 || 1.3M || Photo/Video || 1280*1024@15fps<br />640*512@30fps || Fixed focus || 2.8 || 2.8 || 1.8 || NC || <br />
|-<br />
| Micron || MT9D112 || 1.3M || Photo/Video || 1600*1200@15fps<br />640*480@30fps || Fixed focus || 2.8 || 2.8 || 1.8 || NC || <br />
|-<br />
| Galaxy Core || GC0307 || 0.3M || Video || 640*480@15fps || Fixed focus || 2.8 || 2.8 || 1.8 || NC || <br />
|-<br />
| Galaxy Core || GC0308 || 0.3M || Video || 640*480@15fps || Fixed focus || 2.8 || 2.8 || 1.8 || NC || <br />
|-<br />
| Galaxy Core || GC0309 || 0.3M || Video || 640*480@15fps || Fixed focus || 2.8 || 2.8 || 1.8 || NC || <br />
|-<br />
| Galaxy Core || GC0329 || 0.3M || Video || 640*480@15fps || Fixed focus || 2.8 || 2.8 || 1.8 || NC || <br />
|-<br />
| Galaxy Core || GT2005 || 2M || Photo/Video || 1600*1200@15fps<br />1280*720@15fps<br />800*600@30fps<br />640*480@30fps || Fixed focus || 2.8 || 2.8 || 1.8 || NC || <br />
|-<br />
| Galaxy Core || GT2035 || 2M || Photo/Video || 1600*1200@2fps<br />1280*720@10fps<br />800*600@10fps<br />640*480@10fps || Fixed focus || 2.8 || 2.8 || 1.8 || NC || <br />
|-<br />
| Galaxy Core || GC2015 || 2M || Photo/Video || 1600*1200@2fps<br />1280*1024@2fps<br />1024*768@2fps<br />800*600@8fps<br />640*480@8fps || Fixed focus || 2.8 || 2.8 || 2.8 || NC || <br />
|-<br />
| Hynix || HI704 || 0.3M || Video || 640*480@20fps || Fixed focus || 2.8 || 2.8 || 2.8 || NC || I2C and other devices share may be a conflict<br />
|-<br />
| Hynix || HI253 || 6M || Photo/Video || 1600*1200<br />1280*720@15fps<br />800*600@30fps<br />640*480@30fps<br />320*240@30fps || Fixed focus/Autofocus || 2.8 || 2.8 || 1.8 || NC || <br />
|-<br />
| SETi || SIV121D || 0.3M || YUV || 640x480@30fps || Fixed focus || 2.8 || 1.8/2.8 || internal || NC || based on SIV121C datasheet<br />
|-<br />
| Superpix || SP0838 || 0.3M || Video || 640*480@20fps || Fixed focus || 2.8 || 2.8 || 1.8 || NC || <br />
|-<br />
| Superpix || SP2518 || 2M || Video || 1600*1200@15fps || Fixed focus || 2.8 || 2.8 || 1.8 || NC || <br />
|-<br />
| Samsung || S5K4EC || 5M || Photo/Video || 2560*1920@7.5fps<br />2048*1536@7.5fps<br />1920*1080@15fps<br />1280*720@30fps<br />640*480@30fps || Autofocus || 2.8 || 2.8 || 1.2 || 2.8~3 || <br />
|-<br />
| TOSHIBA || T8ET5 || 5M || Video || 5M@15fps<br />2048*1536@7.5fps<br />1080p@30fps<br />720p@30fps || Autofocus || 2.8 || 2.8 || 1.5 || 2.8 || <br />
|}<br />
<br />
==Reference==<br />
<strike>*[http://service.awbase.com:8000/faq/index.php/%E6%94%AF%E6%8C%81%E5%88%97%E8%A1%A8] Allwinnertech Wiki</strike><br />
<br />
[[Category:Hardware]]<br />
[[Category:Tutorial]]</div>Karlphttps://linux-sunxi.org/index.php?title=FEL&diff=23276FEL2020-04-19T14:52:50Z<p>Karlp: added suitable addresses for the watchdog reset tip for h3/h5 as well</p>
<hr />
<div>FEL is a low-level subroutine contained in the [[BROM|BootROM]] on Allwinner devices. It is used for initial programming and recovery of devices using USB.<br />
<br />
{{note||Your device therefore needs to be attached to a host (your PC) by means of a '''USB cable''', connected to a port where the sunxi device will present itself as a USB 'slave' (i.e. in device mode). Usually that means the "OTG" connector.<ref><br />
There are exceptions to this rule, where boards might require you to connect to specific ports and/or use non-standard cables. Most notably is the [[Pine64#FEL_mode|Pine64]].</ref>}}<br />
<br />
= Tools for talking FEL mode =<br />
<br />
Our [[sunxi-tools|tools]] repository has some tools for dealing with FEL mode. If you haven't done so already, [[Sunxi-tools#Building|retrieve the repository and build it]].<br />
<br />
= Entering FEL mode =<br />
<br />
While there are a few different ways to trigger FEL mode, they are not always equal. Some do low-level initialization (load Boot0 and Boot1), and some don't.<br />
<br />
If you are going to use FEL mode to retrieve device information, you need a to pick a method of entering FEL mode that initializes Boot1.<br />
<br />
== Power off your device ==<br />
<br />
Before you try to enter FEL mode, make sure that your device is '''truly powered off'''. Do not leave any cables attached.<br />
<br />
{{warn|2=|Due to a common design flaw, [[UART#Board_won.27t_shut_down_completely|(current leaking from) the UART]] will often keep the device in a slightly working state. So before you power up your device again: disconnect your UART, and re-attach it.}}<br />
<br />
== Triggering FEL mode ==<br />
=== Through a special FEL button ===<br />
<br />
This is either called '''recovery''' or '''uboot''' or '''fel'''. If your device features such a button, you just need to hold it during power-up, and the device should have entered FEL mode just fine.<br />
<br />
=== By holding a standard button ===<br />
<br />
This is usually one of the standard tablet buttons, like the '''VOL+''' key or something.<br />
<br />
The following seems to work:<br />
* Press and hold the suspected or reported FEL key.<br />
* Press and hold the power key for about 2 seconds.<br />
* Release the power key, and press it at least 3 times immediately.<br />
<br />
Boot1 is initialized using this method.<br />
<br />
=== Through serial console ===<br />
<br />
If you have access to the [[UART]] already, you can send the character '1' ('2' on some devices) to the device during power-up.<br />
<br />
Boot1 is initialized using this method.<br />
<br />
With later SoCs, Allwinner's U-boot supports the "efex" command.<br />
<br />
If "efex" is not available in your U-boot, you can use the simple uboot "go" command with arguments pointing to the return FEL address:<br><br />
http://linux-sunxi.org/BROM#Other_booting_methods<br><br />
=> go 0xffff0020 <br />
<br>Starting application at 0xFFFF0020 ... <br />
<br />
<br />
Entering this command at the u-boot prompt will enter into FEL mode.<br />
<br />
{{note|This is just an ''alternative way of entering FEL mode''. FEL itself can/will <u>not</u> talk over the serial connection! In other words: You still have to connect a USB cable to make actual use of FEL and associated tools.}}<br />
<br />
=== Through a special SD card image ===<br />
<br />
Included in our [[sunxi-tools|sunxi-tools repository]], there is a small SDCARD boot image that does nothing more than jump to FEL.<br />
<br />
Just install it on an sdcard as you would with the u-boot SPL ('''be sure to change <code>/dev/sdX</code> to where your sdcard is'''):<br />
<br />
<pre><br />
wget https://github.com/linux-sunxi/sunxi-tools/raw/master/bin/fel-sdboot.sunxi<br />
dd if=fel-sdboot.sunxi of=/dev/sdX bs=1024 seek=8<br />
</pre><br />
<br />
=== By having no valid boot image ===<br />
<br />
If the [[BROM]] doesn't find any valid boot image, it will automatically enter FEL mode.<br />
<br />
Thus for most devices that don't feature onboard NAND or eMMC, this should apply when you simply remove the SD/µSD card.<br />
<br />
== Verifying FEL mode ==<br />
<br />
=== A new USB device appears ===<br />
<br />
When you run lsusb, you should see the following in it:<br />
<br />
<pre>Bus 001 Device 074: ID 1f3a:efe8</pre><br />
<br />
=== Running the sunxi-fel tool ===<br />
<br />
<pre>> ./sunxi-fel version<br />
AWUSBFEX soc=00162500(A13) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000</pre><br />
<br />
=== Serial output ===<br />
<br />
If the method you chose initialized boot1, then you should see something like this over serial:<br />
<br />
<pre>HELLO! BOOT0 is starting!<br />
boot0 version : .3.0<br />
dram size =1024<br />
Succeed in opening nand flash.<br />
Succeed in reading Boot1 file head.<br />
The size of Boot1 is 0x00036000.<br />
The file stored in 0X00000000 of block 2 is perfect.<br />
Check is correct.<br />
Ready to disable icache.<br />
Succeed in loading Boot1.<br />
Jump to Boot1.<br />
[ 0.145] boot1 version : 1.3.1a<br />
[ 0.145] pmu type = 3<br />
[ 0.145] bat vol = 4117<br />
[ 0.176] axi:ahb:apb=3:2:2<br />
[ 0.176] set dcdc2=1400, clock=1008 successed<br />
[ 0.178] key<br />
[ 2.486] you can unclench the key to update now<br />
[ 2.486] key found, jump to fel</pre><br />
== Common Pitfalls ==<br />
<br />
=== It failed! ===<br />
<br />
Try again, make sure you fully power down the device and make sure you get the order of events right. You'll get there.<br />
<br />
=== Reading over USB fails ===<br />
<br />
If the following happens:<br />
<pre>> ./sunxi-fel read 0x43000000 0x20000 script.bin<br />
libusb usb_bulk_send error -7</pre><br />
<br />
Then you probably are trying to read things that only get initialized when boot0 and boot1 have been loaded. Try another method of entering FEL mode, one that does initialize to boot1.<br />
<br />
= FEL Protocol =<br />
<br />
The FEL is actually a tiny usb stack implementing [[FEL/Protocol|a special USB protocol]].<br />
<br />
Part of it is implemented in our [https://github.com/linux-sunxi/sunxi-tools/blob/master/fel_lib.c tools repository] and can be used as reference code.<br />
<br />
= Tips and tricks =<br />
<br />
* if you get usb_bulk_send error -7 after some command it means soc/fel stack left fel mode or crashed. you either booted something or hung the device<br />
* you can reset via fel by enabling watchdog: <br />
** For A10 compatible ./sunxi-fel writel 0x01c20c94 3<br />
** For H3/H5 compatible ./sunxi-fel writel 0x01c20cb8 1<br />
* Or, if in u-boot, use: mw 0x01c20c94 3 ; ; ; ;<br />
This will go back to FEL mode regardless if the device's FEL mode jumper/button is in place. Note that a couple of blank lines are needed after the mw for some reason.<br />
<br />
= See also =<br />
<br />
* [[FEL/USBBoot| Booting using FEL]]<br />
<br />
[[Category:USB OTG]]<br />
[[Category:Boot]]<br />
[[Category:Software]]<br />
<br />
= References =<br />
<references/></div>Karlphttps://linux-sunxi.org/index.php?title=Linux_mainlining_effort&diff=22859Linux mainlining effort2019-11-04T12:33:50Z<p>Karlp: 5.5 planned stuff</p>
<hr />
<div>The purpose of this page is to try and define sub-goals and milestones for the mainlining effort, containing goals and sub-goals with milestones for adding Allwinner support in the upstream mainline Linux Kernel.<br />
<br />
=Overview=<br />
The idea is to submit the code needed to run the Linux kernel on Allwinner SoCs upstream, ie. to the official Linux kernel.<br />
<br />
This can be achieved by following the concept outlined in the ''Your new ARM SoC Linux support check-list!'' article published by Thomas Petazzoni from Bootlin.<ref>http://www.elinux.org/images/a/ad/Arm-soc-checklist.pdf</ref><ref>[http://www.cnx-software.com/2013/01/16/your-new-arm-soc-linux-support-check-list-elce-2012/ Your New ARM SoC Linux Support Check-List – ELCE 2012]</ref><br />
<br />
Where relevant, I have attempted to include who is currently working on an item, mostly separate from any particular mainlining goal.<br />
<br />
=Status=<br />
<br />
The [[Mainline_Kernel_Howto|Mainline Kernel howto]] contains the currently used repositories for the mainlining process. The U-Boot repository and toolchain is described in the [[Mainline U-Boot|Mainline U-Boot howto]].<br />
<br />
The [[:Category:Mainline_Kernel | Mainline Kernel category ]] gives an overview of currently supported devices.<br />
<br />
== Status Matrix ==<br />
<br />
The goal of this matrix is to give an easy view of work on each SoC worked on by linux-sunxi.<br />
<br />
{| class="wikitable" style="text-align: center; width: 100%;"<br />
|-<br />
! style="width: 10%; text-align: left;" colspan="2" | Model<br />
! [[F1C100s|F1C-<br>100s]]<br />
! [[A10]]<br />
! [[A10s]]<br />
! [[A13]]<br>[[R8]]<br />
! [[A20]]<br />
! [[A23]]<br />
! [[A31]]<br />
! [[A33]]<br>[[R16]]<br />
! [[A64]]<br />
! [[A80]]<br />
! [[A83T]]<br />
! [[GR8]]<br />
! [[H3]]<br />
! [[H5]]<br />
! [[H6]]<br />
! [[R40]]<br>[[T3]]<br />
! [[V3]]<br>[[V3s]]<br>[[S3L]]<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | AC97<br />
| N/A<br />
| style="background: red;" | NO<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | [[Audio Codec]]<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.4<br />
| style="background: lightgreen;" | 4.4<br />
| style="background: lightgreen;" | 4.4<br />
| style="background: lightgreen;" | 4.4<br />
| style="background: lightgreen;" | 4.10<br />
| style="background: lightgreen;" | 4.10<br />
| style="background: lightgreen;" | 4.11<br />
| style="background: lightgreen;" | 5.0<br />
| N/A<br />
| N/A<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen;" | 4.10<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: red;" | NO<br />
<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.13<br />
<br />
|-<br />
| style="text-align: left;" rowspan="3" | ADC<br />
| style="text-align: left;" | GPADC<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: lightgreen;" | 4.12<br />
| N/A<br />
| style="background: orange;" | [[Linux mainlining effort#Minor_drivers|WIP]]<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
| N/A<br />
| style="background: lightgreen;" | 4.12<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" | Thermal<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 3.16<br />
| style="background: lightgreen;" | 3.14<br />
| style="background: lightgreen;" | 3.14<br />
| style="background: lightgreen;" | 3.16<br />
| style="background: darkgreen;" | ?<br />
| style="background: orange;" | [[Linux_mainlining_effort#Minor_drivers|WIP]]<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: orange;" | [[Linux_mainlining_effort#Minor_drivers|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Minor_drivers|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Minor_drivers|WIP]]<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: orange;" | [[Linux_mainlining_effort#Minor_drivers|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Minor_drivers|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Minor_drivers|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Minor_drivers|WIP]]<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" | Touch<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 3.16<br />
| style="background: lightgreen;" | 3.14<br />
| style="background: lightgreen;" | 3.14<br />
| style="background: lightgreen;" | 3.16<br />
| N/A<br />
| style="background: orange;" | [[Linux mainlining effort#Minor_drivers|WIP]]<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
| N/A<br />
| style="background: lightgreen;" | 4.9<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
| N/A<br />
<br />
|-<br />
| rowspan="4" style="text-align: left;" | [[CSI|Camera]]<br />
<br />
| style="text-align: left;" | BT656<br />
| style="background: red;" | NO<br />
| style="background: orange;" | [[Linux_mainlining_effort#Major_drivers|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Major_drivers|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Major_drivers|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Major_drivers|WIP]]<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 5.0<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 5.1<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 5.3<br />
| style="background: orange;" | [[Linux_mainlining_effort#Major_drivers|WIP]]<br />
| style="background: lightgreen;" | 5.0<br />
| style="background: lightgreen;" | 5.0<br />
| style="background: darkgreen;" | ?<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 5.0<br />
<br />
|-<br />
| style="text-align: left;" | ISP<br />
| N/A<br />
| style="background: red;" | NO<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
| N/A<br />
| style="background: red;" | NO<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
<br />
|-<br />
| style="text-align: left;" | MIPI-CSI<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
<br />
|-<br />
| style="text-align: left;" | Parallel<br />
| style="background: red;" | NO<br />
| style="background: orange;" | [[Linux_mainlining_effort#Major_drivers|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Major_drivers|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Major_drivers|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Major_drivers|WIP]]<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 5.0<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 5.1<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 5.3<br />
| style="background: orange;" | [[Linux_mainlining_effort#Major_drivers|WIP]]<br />
| style="background: lightgreen;" | 5.0<br />
| style="background: lightgreen;" | 5.0<br />
| style="background: darkgreen;" | ?<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 5.0<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | Clocks<br />
| style="background: lightgreen;" | 5.0<br />
| style="background: lightgreen;" | 3.10<br />
| style="background: lightgreen;" | 3.11<br />
| style="background: lightgreen;" | 3.10<br />
| style="background: lightgreen;" | 3.12<br />
| style="background: lightgreen;" | 3.17<br />
| style="background: lightgreen;" | 3.12<br />
| style="background: lightgreen;" | 4.2<br />
| style="background: lightgreen;" | 4.10<br />
| style="background: lightgreen;" | 3.19<br />
| style="background: lightgreen;" | 4.13<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen;" | 4.8<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: lightgreen;" | 4.17<br />
| style="background: lightgreen;" | 4.14<br />
| style="background: lightgreen;" | 4.11<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | CPUFreq (DVFS)<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.0<br />
| style="background: lightgreen;" | 4.0<br />
| style="background: lightgreen;" | 4.0<br />
| style="background: lightgreen;" | 4.0<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.2<br />
| style="background: lightgreen;" | 4.11<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.17<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.18<br />
| style="background: orange;" | [[Linux_mainlining_effort#Minor_drivers|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Minor_drivers|WIP]]<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | [[Cryptographic_Hardware_Accelerators|Crypto]]<br />
| N/A<br />
| style="background: lightgreen;" | 4.3<br />
| style="background: lightgreen;" | 4.13<br />
| style="background: lightgreen;" | 4.13<br />
| style="background: lightgreen;" | 4.3<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 4.3<br />
| style="background: lightgreen;" | 4.3<br />
| style="background: lightgreen;" | 5.5<br />
| style="background: lightgreen;" | 5.5<br />
| style="background: lightgreen;" | 5.5<br />
| style="background: lightgreen;" | 4.13<br />
| style="background: lightgreen;" | 5.5<br />
| style="background: lightgreen;" | 5.5<br />
| style="background: lightgreen;" | 5.5<br />
| style="background: lightgreen;" | 5.5<br />
| style="background: darkgreen;" | ?<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | Display (SimpleFB)<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 3.19<br />
| style="background: lightgreen;" | 3.19<br />
| style="background: lightgreen;" | 4.0<br />
| style="background: lightgreen;" | 3.19<br />
| style="background: lightgreen;" | 3.19<br />
| style="background: lightgreen;" | 3.19<br />
| style="background: lightgreen;" | 3.19<br />
| style="background: lightgreen;" | 4.17<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen" | 4.16<br />
| style="background: lightgreen" | 4.16<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
<br />
|-<br />
| rowspan="8" style="text-align: left;" | Display<br />
([https://dri.freedesktop.org/wiki/DRM/ DRM])<br />
<br />
| style="text-align: left;" | CVBS<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.9 ?<br />
| style="background: lightgreen;" | 4.7<br />
| style="background: red;" | NO<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" | HDMI Audio<br />
| N/A<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| N/A<br />
| style="background: red;" | NO<br />
| N/A<br />
| style="background: red;" | NO<br />
| N/A<br />
| style="background: orange;" | WIP<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| N/A<br />
| style="background: orange;" | WIP<br />
| style="background: orange;" | WIP<br />
| style="background: orange;" | WIP<br />
| style="background: red;" | NO<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" | HDMI CEC<br />
| N/A<br />
| style="background: lightgreen;" | 4.15<br />
| style="background: lightgreen;" | 4.14<br />
| N/A<br />
| style="background: lightgreen;" | 4.15<br />
| N/A<br />
| style="background: lightgreen;" | 4.15<br />
| N/A<br />
| style="background: lightgreen;" | 4.20<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.17<br />
| N/A<br />
| style="background: lightgreen;" | 4.17<br />
| style="background: lightgreen;" | 4.17<br />
| style="background: lightgreen;" | 5.2<br />
| style="background: orange;" | WIP<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" | HDMI Video<br />
| N/A<br />
| style="background: lightgreen;" | 4.15<br />
| style="background: lightgreen;" | 4.13<br />
| N/A<br />
| style="background: lightgreen;" | 4.15<br />
| N/A<br />
| style="background: lightgreen;" | 4.15<br />
| N/A<br />
| style="background: lightgreen;" | 4.20<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.17<br />
| N/A<br />
| style="background: lightgreen;" | 4.17<br />
| style="background: lightgreen;" | 4.17<br />
| style="background: lightgreen;" | 5.0<br />
| style="background: lightgreen;" | 4.19<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" | LVDS<br />
| N/A<br />
| style="background: darkgreen;" | ?<br />
| N/A<br />
| N/A<br />
| style="background: darkgreen;" | ?<br />
| style="background: darkgreen;" | ?<br />
| style="background: darkgreen;" | ?<br />
| style="background: darkgreen;" | ?<br />
| style="background: darkgreen;" | ?<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 4.16<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: darkgreen;" | ?<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" | MIPI DSI<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: darkgreen;" | ?<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.18<br />
| style="background: orange;" | [[Linux_mainlining_effort#Major_drivers|WIP]]<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: orange;" | [[Linux_mainlining_effort#Major_drivers|WIP]]<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" | RGB<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.15<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 4.7<br />
| style="background: lightgreen;" | 4.15<br />
| style="background: lightgreen;" | 5.1<br />
| style="background: lightgreen;" | 4.10<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen;" | 5.3<br />
| style="background: lightgreen;" | 4.17<br />
| style="background: lightgreen;" | 4.16<br />
| style="background: lightgreen;" | 4.9<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.13<br />
<br />
|-<br />
| style="text-align: left;" | VGA<br />
| N/A<br />
| style="background: red;" | NO<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | DMA<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.3<br />
| style="background: lightgreen;" | 4.3<br />
| style="background: lightgreen;" | 4.3<br />
| style="background: lightgreen;" | 4.3<br />
| style="background: lightgreen;" | 3.18<br />
| style="background: lightgreen;" | 3.17<br />
| style="background: lightgreen;" | 4.2<br />
| style="background: lightgreen;" | 4.15<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen;" | 4.2<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: lightgreen;" | 5.3<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.13<br />
<br />
|-<br />
| style="text-align: left;" rowspan="2" | [[Ethernet]]<br />
| style="text-align: left;" | [[Ethernet#EMAC|EMAC]]<br />
| rowspan="2"| N/A<br />
| style="background: lightgreen;" | 3.11<br />
| style="background: lightgreen;" | 3.11<br />
| rowspan="2"| N/A<br />
| style="background: lightgreen;" | 3.11 <br />
| rowspan="2"| N/A<br />
| N/A<br />
| rowspan="2"| N/A<br />
| style="background: lightgreen;" rowspan="2" | 4.15<br />
| style="background: lightgreen;" rowspan="2" | 5.1<br />
| style="background: lightgreen;" rowspan="2" | 4.16<br />
| rowspan="2"| N/A<br />
| style="background: lightgreen;" rowspan="2" | 4.15<br />
| style="background: lightgreen;" rowspan="2" | 4.15<br />
| style="background: lightgreen;" rowspan="2" | 5.0<br />
| style="background: lightgreen;" rowspan="2" | 4.18<br />
| style="background: lightgreen;" rowspan="2" | 4.13<br />
<br />
|-<br />
| style="text-align: left;" | [[Ethernet#GMAC|GMAC]]<br />
<br />
| N/A<br />
| N/A<br />
| style="background: lightgreen;" | 3.15<br />
| style="background: lightgreen;" | 3.17<br />
<br />
|-<br />
| style="text-align: left;" rowspan="2" | GPU(3D)<br />
| style="text-align: left;" | [[Mali]]<br />
| style="background: grey; color: white;" | ?<br />
| style="background: lightgreen;" | 5.2<br />
| style="background: grey; color: white;" | ?<br />
| style="background: grey; color: white;" | ?<br />
| style="background: lightgreen;" | 5.2<br />
| style="background: grey; color: white;" | ?<br />
| N/A<br />
| style="background: grey; color: white;" | ?<br />
| style="background: lightgreen;" | 5.2<br />
| N/A<br />
| N/A<br />
| style="background: grey; color: white;" | ?<br />
| style="background: lightgreen;" | 5.2<br />
| style="background: lightgreen;" | 5.2<br />
| style="background: orange;" | [[Linux mainlining effort#Minor_drivers|WIP]]<br />
| style="background: grey; color: white;" | ?<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" | [[PowerVR]]<br />
| style="background: grey; color: white;" | ?<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | HW Spinlocks<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| N/A<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| N/A<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | [[I2C]]<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 3.11<br />
| style="background: lightgreen;" | 3.12<br />
| style="background: lightgreen;" | 3.11<br />
| style="background: lightgreen;" | 3.13<br />
| style="background: lightgreen;" | 3.18<br />
| style="background: lightgreen;" | 3.15<br />
| style="background: lightgreen;" | 4.2<br />
| style="background: lightgreen;" | 4.10<br />
| style="background: lightgreen;" | 3.19<br />
| style="background: lightgreen;" | 4.16<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: lightgreen;" | 4.19<br />
| style="background: lightgreen;" | 4.15<br />
| style="background: lightgreen;" | 4.11<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | I2S<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.8<br />
| style="background: darkgreen;" | ?<br />
| N/A<br />
| style="background: lightgreen;" | 4.8<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 4.13<br />
| style="background: lightgreen;" | 4.11<br />
| style="background: lightgreen;" | 4.17<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.16<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen;" | 4.14<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | IOMMU<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: red" | NO<br />
| N/A<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | [[IR]]<br />
| style="background: red" | NO<br />
| style="background: lightgreen;" | 3.17<br />
| style="background: lightgreen;" | 4.0<br />
| style="background: lightgreen;" | 4.0<br />
| style="background: lightgreen;" | 3.17<br />
| N/A<br />
| style="background: lightgreen;" | 4.0<br />
| N/A<br />
| style="background: lightgreen;" | 5.4<br />
| style="background: lightgreen;" | 4.5<br />
| style="background: lightgreen;" | 4.20<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen;" | 4.6<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: lightgreen;" | 5.4<br />
| style="background: darkgreen;" | ?<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | Keypad<br />
| N/A<br />
| style="background: orange;" | WIP<br />
| N/A<br />
| N/A<br />
| style="background: orange;" | WIP<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: red;" | NO<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | LRADC<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 4.0<br />
| style="background: lightgreen;" | 4.0<br />
| style="background: lightgreen;" | 4.0<br />
| style="background: lightgreen;" | 4.0<br />
| style="background: lightgreen;" | 4.0<br />
| style="background: lightgreen;" | 4.0<br />
| style="background: lightgreen;" | 4.2<br />
| style="background: lightgreen;" | 5.3<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 5.2<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: darkgreen;" | ?<br />
| style="background: darkgreen;" | ?<br />
| N/A<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 4.13<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | MsgBox<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: orange;" | [[Linux_mainlining_effort#Core_Stuff|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Core_Stuff|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Core_Stuff|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Core_Stuff|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Core_Stuff|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Core_Stuff|WIP]]<br />
| N/A<br />
| style="background: orange;" | [[Linux_mainlining_effort#Core_Stuff|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Core_Stuff|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Core_Stuff|WIP]]<br />
| N/A<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | [[NAND]]<br />
| N/A<br />
| style="background: darkgreen;" | ?<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 4.12 <ref name="mlc">While the NAND controller itself is supported, the NAND technology found on the vast majority of boards isn't. See [[MTD_Driver#Challenges|this page]] </ref><br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 4.9 <ref name="mlc"/><br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 4.9 <ref name="mlc" /><br />
| style="background: darkgreen;" | ?<br />
| style="background: darkgreen;" | ?<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 4.9 <ref name="mlc" /><br />
| style="background: darkgreen;" | ?<br />
| style="background: darkgreen;" | ?<br />
| style="background: red;" | NO<br />
| style="background: darkgreen;" | ?<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | PCIe<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: black; color: white;" | NO <ref name="h6-pcie">Allwinner H6 has a quirky PCIe controller that doesn't map the PCIe address space properly to CPU,<br />
and accessing the PCIe config space, IO 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.</ref><br />
| N/A<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | Pinctrl<br />
| style="background: lightgreen;" | 5.0<br />
| style="background: lightgreen;" | 3.9<br />
| style="background: lightgreen;" | 3.9<br />
| style="background: lightgreen;" | 3.9<br />
| style="background: lightgreen;" | 3.12<br />
| style="background: lightgreen;" | 3.18<br />
| style="background: lightgreen;" | 3.12<br />
| style="background: lightgreen;" | 4.2<br />
| style="background: lightgreen;" | 4.6<br />
| style="background: lightgreen;" | 3.19<br />
| style="background: lightgreen;" | 4.4<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen;" | 4.5<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: lightgreen;" | 4.17<br />
| style="background: lightgreen;" | 4.14<br />
| style="background: lightgreen;" | 4.11<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | [[PWM_Controller|PWM]]<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.0<br />
| style="background: lightgreen;" | 4.4<br />
| style="background: lightgreen;" | 4.4<br />
| style="background: lightgreen;" | 4.0<br />
| style="background: lightgreen;" | 4.4<br />
| style="background: orange;" | [[Linux_mainlining_effort#Minor_drivers|WIP]]<br />
| style="background: lightgreen;" | 4.4<br />
| style="background: lightgreen;" | 4.19<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.16<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: orange;" | [[Linux_mainlining_effort#Minor_drivers|WIP]]<br />
| style="background: orange;" | [[Linux_mainlining_effort#Minor_drivers|WIP]]<br />
| style="background: lightgreen;" | 4.12<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | [[RSB]]<br />
| style="background: red;" | NO<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: lightgreen;" | 4.4<br />
| N/A<br />
| style="background: lightgreen;" | 4.4<br />
| style="background: lightgreen;" | 4.13<br />
| style="background: lightgreen;" | 4.3<br />
| style="background: lightgreen;" | 4.14<br />
| N/A<br />
| style="background: grey; color: white;" | ?<br />
| style="background: grey; color: white;" | ?<br />
| style="background: grey; color: white;" | ?<br />
| N/A<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | [[RTC]]<br />
| N/A<br />
| style="background: lightgreen;" | 3.14<br />
| N/A<br />
| N/A<br />
| style="background: lightgreen;" | 3.14<br />
| style="background: lightgreen;" | 3.18<br />
| style="background: lightgreen;" | 3.18<br />
| style="background: lightgreen;" | 4.2<br />
| style="background: lightgreen;" | 4.10<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: lightgreen;" | 4.5<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: lightgreen;" | 5.4<br />
| style="background: lightgreen;" | 5.0<br />
| style="background: lightgreen;" | 4.11<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | [[SATA]]<br />
| N/A<br />
| style="background: lightgreen;" | 3.15<br />
| N/A<br />
| N/A<br />
| style="background: lightgreen;" | 3.15<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: lightgreen;" | 4.20<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | SD/ [[eMMC|MMC]]<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 3.16<br />
| style="background: lightgreen;" | 3.16<br />
| style="background: lightgreen;" | 3.16<br />
| style="background: lightgreen;" | 3.16<br />
| style="background: lightgreen;" | 3.18<br />
| style="background: lightgreen;" | 3.16<br />
| style="background: lightgreen;" | 4.2<br />
| style="background: lightgreen;" | 4.11<br />
| style="background: lightgreen;" | 4.0<br />
| style="background: lightgreen;" | 4.14<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen;" | 4.5<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: lightgreen;" | 4.19<br />
| style="background: lightgreen;" | 4.14<br />
| style="background: lightgreen;" | 4.11<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | SMP<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: lightgreen;" | PSCI<br />
| style="background: lightgreen;" | PSCI<br />
| style="background: lightgreen;" | PSCI<br />
| style="background: lightgreen;" | PSCI<br />
| style="background: lightgreen;" | PSCI<br />
| style="background: lightgreen;" | 4.17<br />
| style="background: lightgreen;" | 4.18<br />
| N/A<br />
| style="background: lightgreen;" | PSCI<br />
| style="background: lightgreen;" | PSCI<br />
| style="background: lightgreen" | PSCI<br />
| style="background: lightgreen;" | PSCI<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | [[SPDIF]]<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.7<br />
| N/A<br />
| N/A<br />
| style="background: lightgreen;" | 4.7<br />
| N/A<br />
| style="background: lightgreen;" | 4.9<br />
| N/A<br />
| style="background: lightgreen;" | 4.17<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 4.13<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen;" | 4.11<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: lightgreen;" | 5.4<br />
| style="background: darkgreen;" | ?<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | [[SPIdev|SPI]]<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 3.16<br />
| style="background: lightgreen;" | 3.15<br />
| style="background: lightgreen;" | 3.15<br />
| style="background: lightgreen;" | 3.15<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 3.15<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 4.15<br />
| style="background: darkgreen;" | ?<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen;" | 4.10<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: red;" | NO<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 4.13<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | [[SRAM Controller|SRAM]]<br />
| style="background: lightgreen;" | 5.0<br />
| style="background: lightgreen;" | 4.2<br />
| style="background: lightgreen;" | 4.2<br />
| style="background: lightgreen;" | 4.2<br />
| style="background: lightgreen;" | 4.2<br />
| style="background: lightgreen;" | 4.19<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.19<br />
| style="background: lightgreen;" | 4.19<br />
| N/A<br />
| N/A<br />
| style="background: lightgreen;" | 4.2<br />
| style="background: lightgreen;" | 4.19<br />
| style="background: lightgreen;" | 5.0 <br />
| style="background: lightgreen;" | 5.1 <br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | [[USB]]<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 3.15<br />
| style="background: lightgreen;" | 3.15<br />
| style="background: lightgreen;" | 3.15<br />
| style="background: lightgreen;" | 3.15<br />
| style="background: lightgreen;" | 4.3<br />
| style="background: lightgreen;" | 3.16<br />
| style="background: lightgreen;" | 4.3<br />
| style="background: lightgreen;" | 4.11<br />
| style="background: lightgreen;" | 4.2<br />
| style="background: lightgreen;" | 4.14<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen;" | 4.8<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: lightgreen;" | 5.0<br />
| style="background: lightgreen;" | 4.15<br />
| style="background: lightgreen;" | 4.11<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | [[USB_OTG_Controller_Register_guide#USB_OTG|USB OTG]]<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.3<br />
| style="background: lightgreen;" | 4.3<br />
| style="background: lightgreen;" | 4.3<br />
| style="background: lightgreen;" | 4.3<br />
| style="background: lightgreen;" | 4.8<br />
| style="background: lightgreen;" | 4.3<br />
| style="background: lightgreen;" | 4.8<br />
| style="background: lightgreen;" | 4.11<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 5.2<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: lightgreen;" | 5.0<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 4.11<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | USB3<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: red" | NO<br />
| N/A<br />
| N/A<br />
| N/A<br />
| N/A<br />
| style="background: orange;" | [[Linux_mainlining_effort#Minor_drivers|WIP]]<br />
| N/A<br />
| N/A<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | [[Video_Engine|VE]] | [[Sunxi-Cedrus]]<br />
| style="background: red;" | NO<br />
| style="background: lightgreen;" | 5.1<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 4.20<br />
| style="background: lightgreen;" | 4.20<br />
| style="background: darkgreen;" | ?<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 4.20<br />
| style="background: lightgreen;" | 5.0<br />
| style="background: red;" | NO<br />
| style="background: red;" | NO<br />
| style="background: darkgreen;" | ?<br />
| style="background: lightgreen;" | 4.20<br />
| style="background: lightgreen;" | 5.0<br />
| style="background: lightgreen;" | 5.2 <br />
| style="background: red;" | NO<br />
| style="background: darkgreen;" | ?<br />
<br />
|-<br />
| style="text-align: left;" colspan="2" | Watchdog<br />
| style="background: lightgreen;" | 5.0<br />
| style="background: lightgreen;" | 3.12<br />
| style="background: lightgreen;" | 3.12<br />
| style="background: lightgreen;" | 3.12<br />
| style="background: lightgreen;" | 3.12<br />
| style="background: lightgreen;" | 3.18<br />
| style="background: lightgreen;" | 3.18<br />
| style="background: lightgreen;" | 4.2<br />
| style="background: lightgreen;" | 4.17<br />
| style="background: lightgreen;" | 3.19<br />
| style="background: lightgreen;" | 4.6<br />
| style="background: lightgreen;" | 4.9<br />
| style="background: lightgreen;" | 4.5<br />
| style="background: lightgreen;" | 4.12<br />
| style="background: lightgreen;" | 5.3<br />
| style="background: lightgreen;" | 4.15<br />
| style="background: lightgreen;" | 4.11<br />
<br />
|-<br />
! style="width: 10%; text-align: left;" colspan="2" | Model<br />
! [[F1C100s|F1C-<br>100s]]<br />
! [[A10]]<br />
! [[A10s]]<br />
! [[A13]]<br />
[[R8]]<br />
! [[A20]]<br />
! [[A23]]<br />
! [[A31]]<br />
! [[A33]]<br />
[[R16]]<br />
! [[A64]]<br />
! [[A80]]<br />
! [[A83T]]<br />
! [[GR8]]<br />
! [[H3]]<br />
! [[H5]]<br />
! [[H6]]<br />
! [[R40]]<br />
[[T3]]<br />
! [[V3s]]<br />
<br />
|}<br />
<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
|-<br />
! Legend<br />
|-<br />
| style="background: lightgreen;" | In Linux mainline since version x<br />
|-<br />
| style="background: darkgreen;" | Nobody works on it, but it should be compatible with already done drivers<br />
|-<br />
| style="background: orange;" | Somebody works on it<br />
|-<br />
| style="background: red;" | No support, nobody works on it<br />
|-<br />
| style="background: black; color: white;" | support impossible<br />
|-<br />
| style="background: grey; color: white;" | Status is unknown/to be completed<br />
|}<br />
<br />
== Work In Progress ==<br />
<br />
=== Core Stuff ===<br />
*[[AR100]] firmware (WiP: Samuel Holland) [https://github.com/crust-firmware/crust ARISC firmware for sunxi SoCs ]<br />
<br />
* Message box (WiP: Samuel Holland) [https://lore.kernel.org/patchwork/cover/1117050/ Allwinner sunxi message box support patch-v4]<br />
<br />
* [[A13]] PSCI Suspend / Resume / CPUIdle (WiP: Antoine Tenart) [http://lists.denx.de/pipermail/u-boot/2016-September/265453.html patch-v1]<br />
<br />
=== Major drivers ===<br />
<br />
* HDMI Audio [[A64]] / [[H3]] / [[H5]] / [[H6]] WIP Jernej Škrabec (jernej) / LibreELEC<br />
<br />
* [[R40]] MIPI-DSI WIP Jagan Teki [https://patchwork.freedesktop.org/series/62062/ drm/sun4i: Allwinner R40 MIPI-DSI support] <br />
<br />
* [[A64]] MIPI-DSI WiP Jagan Teki [https://lore.kernel.org/patchwork/cover/1049604/ drm/sun4i: Allwinner A64 MIPI-DSI support patch-v8]<br />
<br />
* [[H6]] USB 3 WiP Icenowy Zheng [https://lore.kernel.org/patchwork/cover/1058917/ Allwinner H6 USB3 support patch-v5]<br />
<br />
* [[AC100]] Audio codec WiP Ondrej Jirman [https://github.com/megous/linux/commits/linux-tbs WIP branch]<br />
<br />
* [[A10]] CSI WiP Maxime Ripard [https://lore.kernel.org/patchwork/cover/1058765/ media: Allwinner A10 CSI support v5] <br />
<br />
* HEVC/H.265 video decoding WiP Paul Kocialkowski [https://lore.kernel.org/patchwork/cover/1143012/ HEVC/H.265 stateless support for V4L2 and Cedrus]<br />
<br />
=== Minor drivers ===<br />
<!-- Please move the newest entry to the top --><br />
* [[A64]] / [[H3]] / [[H5]] / [[H6]] / [[R40]] Thermal WIP Yangtao Li [https://patchwork.kernel.org/cover/11088251/ add thermal driver for h6 v5]<br />
* [[H6]] <br />
** PWM WIP Jernej Škrabec [https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=197209 pwm: sun4i: Add support for Allwinner H6 v2] <br />
** Cpufreq (DVFS) WIP Yangtao Li [https://lore.kernel.org/patchwork/cover/1042857/ arm64: dts: allwinner: h6: Enable CPU DVFS(cpufreq)]<br />
<br />
* [[H5]] Cpufreq (DVFS) WIP Chen-Yu Tsai [https://patchwork.kernel.org/cover/10787869/ arm64: dts: allwinner: h5: Enable CPU DVFS (cpufreq)]<br />
* [[R40]] PWM (WIP Hao Zhang [https://www.spinics.net/lists/kernel/msg2731498.html patch-v2])<br />
* [[A31]]/[[A31s]] PWM support (WiP: Siarhei Volkau [http://lists.infradead.org/pipermail/linux-arm-kernel/2017-February/486405.html patch-v1])<br />
* [[A20]] Keypad (WiP: Yassin Jaffer (ddc) [http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/370079.html patch])<br />
* [[A64]] / [[A80]] / [[A83T]] / [[H5]] Thermal driver WIP: Philipp Rossak (embed-3d) v3-branch: <br />
** [https://github.com/embed-3d/linux/tree/embed-3d/sunxi-ths-v3 sunxi-ths-v3] <br />
** [https://patchwork.kernel.org/cover/10582083/ IIO-based thermal sensor driver for Allwinner H3 and A83T SoC]<br />
<br />
=== Boards ===<br />
<br />
== Planned for 5.5 ==<br />
<br />
*[[H6]]<br />
**Crypto<br />
**GPU(3D) Mali<br />
<br />
*[[A64]] / [[A80]] / [[A83T]] / [[H3]] / [[H5]] / [[R40]] <br />
**Crypto<br />
<br />
* [[Bluetooth#AMPAK|Broadcom-based (AMPAK modules) Bluetooth]] support on<br />
** Emlid Neutis<br />
<br />
New Devices Supported<br />
* [[H3]]<br />
** [[FriendlyARM_NanoPi_Duo2]]<br />
<br />
== Merged for 5.4 ==<br />
* [[A64]]<br />
** IR<br />
* [[H6]]<br />
** IR<br />
** RTC<br />
** SPDIF<br />
New Devices Supported<br />
* [[A64]]<br />
** [[Olimex A64-OLinuXino]] eMMC<br />
* [[H6]]<br />
** [[Tanix TX6]]<br />
* [[S3]]<br />
** [[Litchee Zero Plus]]<br />
<br />
== Merged for 5.3 ==<br />
* [[A64]]<br />
** LRADC<br />
** RGB LCD<br />
* [[A83T]]<br />
** CSI<br />
* [[H6]]<br />
** DMA<br />
** Watchdog<br />
* multiple SoCs<br />
** [[Cedrus]] h264<br />
<br />
== Merged into 5.2 ==<br />
* [[A83T]]<br />
** LRADC<br />
** USB OTG<br />
<br />
* [[H6]]<br />
** [[Cedrus]]<br />
<br />
* multiple SoCs<br />
** [[Mali Open Source Driver|Lima]]<br />
** [[Mali Open Source Driver|Panfrost]]<br />
<br />
* [[Bluetooth#AMPAK|Broadcom-based (AMPAK modules) Bluetooth]] support on<br />
** Banana-Pi-M2-Zero<br />
<br />
New Devices Supported<br />
* [[H6]]<br />
** [[Beelink GS1]]<br />
** [[Xunlong Orange Pi 3]]<br />
<br />
== Merged into 5.1 ==<br />
* A10<br />
** Cedrus<br />
** PMU<br />
<br />
* A20<br />
** Audio Codec improvements<br />
<br />
* A23<br />
** Display pipeline<br />
** LCD enabled on Q8 A23 tablets<br />
<br />
* A64<br />
** ARM Architectural Timer errata workaround<br />
** PMU<br />
** CSI<br />
<br />
* A80<br />
** GMAC support<br />
<br />
* CSI in general<br />
** RGR565 support<br />
** JPEG pass-through support<br />
<br />
* [[Bluetooth#AMPAK|Broadcom-based (AMPAK modules) Bluetooth]] support on<br />
** [[Banana Pi M2+]]<br />
** [[Banana Pi M2 Ultra]]<br />
<br />
* [[LCD]] enabled on [[A13]] [[Q8]] tablets<br />
<br />
== Merged into 5.0 ==<br />
* A64<br />
** Cedrus<br />
** DTS changes for audio codec<br />
<br />
* F1C100s<br />
** initial F1C100s support<br />
<br />
* H6<br />
** Ethernet<br />
** DE3/HDMI support<br />
** USB 2.0<br />
<br />
* H3 / H5<br />
** CSI Support<br />
<br />
* H5<br />
** Cedrus<br />
<br />
* R40<br />
** RTC<br />
<br />
* T3<br />
** initial T3 support<ref>https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b7badd1d7aa61087010803affa19bb83fb5a0af1</ref><br />
<br />
* V3s<br />
** CSI Support<br />
<br />
* [[Bluetooth#AMPAK|Broadcom-based (AMPAK modules) Bluetooth]] support on<br />
** [[Sinovoip Banana Pi M2 Magic | Banana Pi M2 Magic]]<br />
** [[Banana Pi M3]]<br />
** [[Banana Pi M64]]<br />
** [[Cubietruck]]<br />
** [[Cubietech_Cubietruck_Plus|Cubietruck Plus]]<br />
<br />
New Devices Supported<br />
* [[Xunlong Orange Pi Lite 2]]<br />
<br />
== Merged into 4.20 ==<br />
<br />
* A13 / A20 / A33 / H3<br />
** Cedrus driver<br />
<br />
* A83T<br />
** IR receiver<br />
<br />
* A64<br />
** Cleanup for device tree files<br />
** HDMI support<br />
** Audio codec support (DTS changes will be merged in 5.0)<br />
<br />
* H3 / H5<br />
** SID<br />
<br />
* R40<br />
** SATA<br />
<br />
New Devices Supported<br />
* [[Pine64]] LTS<br />
* [[Xunlong Orange Pi One Plus]]<br />
* [[Xunlong Orange Pi Zero Plus 2]] (H3 variant)<br />
* [[Sinovoip Banana Pi M2+]] (H5 variant)<br />
<br />
== Merged into 4.19 ==<br />
<br />
* A10 / A13 / A20 / A23 / A33<br />
** SRAM controller / system control<br />
<br />
* A64<br />
** SRAM controller / system control<br />
** Display clocks and bus<br />
** RTC clock output<br />
** PWM<br />
** R_I2C<br />
<br />
* H3<br />
** SRAM controller / system control<br />
<br />
* H6<br />
** MMC<br />
** PMIC<br />
<br />
* R40<br />
** HDMI support<br />
<br />
Board Changes<br />
* SPI flash node for [[Orange Pi PC 2]] and [[Pine64#Variants | Pine64 SoPINE]]<br />
* Use lid switch as wake-up source for A64 based laptops<br />
* LEDs added for [[PineH64]]<br />
<br />
New Devices<br />
* [[Pine Pinebook]]<br />
* Amarula A64-Relic<br />
<br />
== Changes merged up to 4.18 ==<br />
Changes up to 4.18 can be found on [[Linux mainlining history]] page.<br />
<br />
=References=<br />
<references /><br />
<br />
= See also =<br />
* [[Mainline Kernel Howto]]<br />
* [[Possible setups for hacking on mainline]]<br />
* [[Linux Kernel]]<br />
**[[Toolchain]]<br />
<br />
=External Links=<br />
* [http://www.kernel.org kernel.org] - Official website for the Linux Kernel<br />
** [http://github.com/torvalds/linux http://github.com/torvalds/linux] - Linus Torvalds' GitHub account with the upstream Linux kernel<br />
* [http://www.kernel.org/doc/ Linux Kernel documentation index]<br />
* [http://www.kernel.org/doc/man-pages/ Linux Kernel man pages]<br />
* [http://kernelnewbies.org/ Kernel Newbies Site - Excellent source of information for people new to kernel]<br />
* [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary Linus' kernel tree for 2.6]<br />
* [https://bugzilla.kernel.org/ Kernel bugzilla] - [https://bugzilla.kernel.org/show_bug.cgi?id=15790 Regressions for each of recent versions]<br />
* [http://www.fsfla.org/svnwiki/selibre/linux-libre/ Linux-libre project - Maintains and distributes fully free kernel]<br />
* [http://lingrok.org/ LinGrok, Linux kernel source code cross-reference]<br />
* [https://elixir.bootlin.com/linux/latest/source?a=arm Bootlin LXR (Linux Cross Reference)]<br />
* [http://lists.infradead.org/pipermail/linux-arm-kernel/ linux-arm-kernel - Mailing list archive]<br />
===How to upstream===<br />
* [http://www.elinux.org/images/a/ad/Arm-soc-checklist.pdf Your new ARM SoC Linux support check-list! by Thomas Petazzoni of Bootlin]<br />
*[http://www.cnx-software.com/2014/03/04/linux-kernel-upstreaming-how-to-linaro-connect-asia-2014/ Linux Kernel Upstreaming How-To (CNXSoft - Embedded Software Development)]<br />
**[http://www.youtube.com/watch?v=dY7fikYZ42c Matt Porter's YouTube video talk on “Upstreaming 101" (LCA14-111)]<br />
***[http://www.linaro.org/documents/download/65f888c674508efcf9bd5d90398a186a530d01c4c78db Matt Porter's presentation slides for “Upstreaming 101" (LCA14-111)]<br />
**[https://www.youtube.com/watch?v=FiQ5uV_Mm5c Matt Porter's YouTube video talk on “Upstreaming 201" (LCA14-112)]<br />
***[http://www.linaro.org/documents/download/7b9920fcc89589bad9063d87d9137f08530d020b71924 Matt Porter's presentation slides for “Upstreaming 201" (LCA14-112)]<br />
*[http://www.cnx-software.com/2011/08/19/how-to-write-and-submit-a-linux-kernel-patch/ How to Write and Submit a Linux Kernel Patch (CNXSoft - Embedded Software Development)]<br />
** [http://www.youtube.com/watch?v=LLBrBBImJt4 YouTube Video- Write and Submit your first Linux kernel Patch]<br />
** [http://www.cnx-software.com/pdf/kernel-tutorial/kernel_patch_tutorial.pdf Greg Kroah-Hartman Kernel Tutorial Write and Submit your first Linux Kernel Patch]<br />
*[http://www.linaro.org/connect-lca14/resources Linaro resources page from LCA (Linaro Connect Asia) 2014]<br />
<br />
=Notes=<br />
<references group=note /><br />
<br />
[[Category:Development]]</div>Karlphttps://linux-sunxi.org/index.php?title=FriendlyARM_NanoPi_NEO_%26_AIR&diff=22858FriendlyARM NanoPi NEO & AIR2019-11-04T12:29:49Z<p>Karlp: /* WiFi */ drop patch notes, it's well supported by mainline now, two year old patch links to a mailing list are no longer useful.</p>
<hr />
<div>{{Infobox Board<br />
| image = [[File:Duetto_di_NanoPi.jpg|250px]]<br />
| manufacturer = [http://www.friendlyarm.net/ FriendlyARM]<br />
| dimensions = 40''mm'' x 40''mm''<br />
| release_date = July (NEO) / Oct (Air) 2016<br />
| website = [http://nanopi.io/nanopi-neo.html NanoPi NEO] / [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air NanoPi NEO Air]<br />
| soc = [[H3]] @ 1.2Ghz<br />
| dram = 256MiB (K4B2G1646Q-BCK0) or 512MiB (K4B4G1646Q-BCK0) DDR3<br />
| power = DC 5V @ 2A via microUSB or pin headers<br />
| audio = microphone, stereo line-out, I²S and [[SPDIF|S/PDIF]] on pin headers<br />
| network = 10/100Mbps Ethernet ([[Sun8i emac|H3 built-in PHY]]) or BT4.0/WiFi 802.11 b/g/n ([[Wifi#Ampak|Ampak AP6212]])<br />
| storage = µSD and 8GB eMMC (Air)<br />
| usb = 1 USB2.0 Host (NEO), 1 USB2.0 OTG<br />
| other = 24 pin camera connector (Air)<br />
| headers = UART, SPI, I²C, 2x USB2.0 Host, analog audio, microphone<br />
}}<br />
<br />
NanoPi NEO and NEO Air are [[H3]] based small form-factor development boards produced by [[:Category:FriendlyARM|FriendlyARM]]. The NEO comes with integrated 100 Mbps Ethernet while NEO Air provides network with 802.11n WiFi. Both boards have a SD card slot, but NEO Air also includes 8GB eMMC. A lot of functionality is provided via the unpopulated headers on both boards.<br />
<br />
= Identification =<br />
Small, square board, blue soldermask, ⌀3mm mounting holes in the corners. USB type-A, Ethernet jack (with integrated magnetics) and four-pin header for UART/power near one of the edges, microSD and USB micro-B at opposite edge mounted on top side, 12 and 24 GPIO pin headers (not fitted, pads only) near other edges. Allwinner H3 and single DDR3 chip mounted on the bottom. Sticker indicating amount of RAM is placed on the Ethernet jack. Device can also be ordered without USB and Ethernet soldered (see gallery below)<br />
<br />
On the top side of the board, next to USB A connector, the following is silkscreened:<br />
<pre>FRIENDLYARM<br />
NanoPi NEO</pre><br />
<br />
Starting in September 2016 a new PCB revision 1.1 is available (changes: [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO#Layout audio signals on the GPIO header, voltage regulator])<br />
<br />
{{H3_Support_status|board=NanoPi NEO and NEO Air|uboot_defconfig='''nanopi_neo''' (supported since v2016.11) or '''nanopi_neo_air''' (supported since v2017.05)|kernel_dtb='''sun8i-h3-nanopi-neo.dtb''' or '''sun8i-h3-nanopi-neo-air.dtb''' (depending on the board)|hdmi_support=|legacy_instructions=The .fex file is available from [https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/h3/xunlong_orange_pi_pc.fex xunlong_orange_pi_pc.fex].|status_extra=NanoPi NEO shares nearly all hardware details with [[Orange Pi One]]. Detailed device information can be found on [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO] and [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air]<br />
<br />
== Images ==<br />
<br />
FriendlyARM's UbuntuCore with Qt-Embedded image can be found [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO#Make_an_Installation_TF_Card here]. It boots a new variant of Allwinner's 3.4.39 BSP kernel, USB and Ethernet are working fine. Armbian images for NEO based on 3.4.112 (containing new IoT low power settings) or 4.6.7 can be found [http://www.armbian.com/nanopi-neo/ here].<br />
<br />
== BSP ==<br />
<br />
FriendlyARM provides a [https://github.com/friendlyarm/h3_lichee BSP based on a newer Allwinner 3.4.39 variant] on Github.<br />
}}<br />
<br />
= Expansion Port =<br />
<br />
Both NanoPi NEO and NEO Air feature one 12-pin and one 24-pin GPIO header. Air's pin-out for those headers and the DVP camera connector can be found [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air#Diagram.2C_Layout_and_Dimension here]. On NEO PCB rev. 1.0 analog audio signals were present on the 12-pin header that were replaced by digital audio starting with PCB rev. 1.1. With PCB rev. 1.3 position of the UART debug header has changed and a new 5-pin analog audio header has been added (same as on NEO 2 and NEO Plus 2). All pin-out information in [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO#Diagram.2C_Layout_and_Dimension FriendlyELEC's wiki page].<br />
<br />
= Tips, Tricks, Caveats =<br />
<br />
== FEL mode ==<br />
<br />
No [[FEL]] button. UBOOT/FEL signal pulled-up by R254 (10kΩ, mounted on the bottom side, close to H3).<br />
<br />
== LEDs ==<br />
<br />
The board has two LEDs, mounted on the top side, between micro USB and microSD:<br />
* A red LED, labelled "PWR", connected to the PL10 pin and to 3.3V via weak pull-up, thus being able to represent three states:<br />
** full brightness when GPIO is set to output high<br />
** reduced brightness when GPIO is set to high impedance state<br />
** turned off when GPIO is set to output low.<br />
* A blue LED, labelled "STAT", connected to the PA10 pin.<br />
<br />
== Voltage regulators / heat ==<br />
<br />
NanoPi NEO/Air use the same voltage regulator as NanoPi M1 and Orange Pi One/Lite switching between 1.1V and 1.3V (SY8113B [https://www.olimex.com/Products/Breadboarding/BB-PWR-8113/resources/SY8113.pdf datasheet]). Unlike the Xunlong boards which contain a thick copper layer inside the PCB to spread heat away from the SoC FriendlyARM chose a different design. This and maybe the smaller PCB size lead to higher temperatures compared to Orange Pis and in case you want to operate the NEO under constant high load think about adding a heatsink (FriendlyARM provides one combined with a 2mm heat pad that can be securely mounted on the board -- see gallery images below.<br />
<br />
On NanoPi NEO PCB rev 1.0 U7 next to DRAM is an LDO voltage regulator that provides 1.2V for various SoC parts and 1.1V for the internal Ethernet PHY. It overheats a lot and is rated 500mA max. When ordering FriendlyARM's heatsink maybe combining it with a larger heatpad that covers the whole SBC's surface is a better option than now (using a small 15x15 heat pad that connects SoC with heat sink but decreases heat dissipation for all other SBC components this way).<br />
<br />
== DRAM ==<br />
<br />
NanoPi NEO is available with 256 MiB or 512 MiB but only in single bank configuration. NanoPi Air is available with 512 MiB (also single bank).<br />
<br />
DRAM is clocked at '''432 MHz''' by the hardware vendor. [[User:Tkaiser]] did some consumption and thermal measurements just to find out that the board deadlocks pretty fast when running lima-memtester regardless of DRAM clockspeed (happens within minutes) but as soon as an annoying fan is added to FriendlyARM's heatsink blowing air between heatsink and SoC the board survives lima-memtester running at 600 MHz for several hours (board found powered off after increasing up to 672 from userspace after another hour). Since visual feedback is impossible on a board that lacks any display output we should consider 432 MHz to be a sane default since it both helps decreasing heat and consumption.<br />
<br />
Based on [[User:Tkaiser]]'s tests reducing DRAM clockspeed by 24 MHz more (with BSP kernel 408 MHz is the lowest allowed clockspeed) is even better since it does not affect performance that much (negligible according to tinymembench) but both temperature and consumption are lowered a lot by switching from 432 MHz to 408 MHz. Test results [http://forum.armbian.com/index.php/topic/1728-rfc-default-settings-for-nanopi-neoair/?view=getlastpost here] and description of test setup [http://forum.armbian.com/index.php/topic/1665-rfc-using-a20-board-with-armbian-as-powermeter/#entry13765 there] (using another sunxi board's AXP209 to do consumption measurements). BSP kernel boots happily with ''CONFIG_DRAM_CLK=408'' and ''CONFIG_SYS_CLK_FREQ=480000000'' set in u-boot 2016.07.<br />
<br />
The single bank DRAM configuration is slower than dual bank configuration on all other H3 devices. Even more when taking the different DRAM clockspeeds into account. Using [https://github.com/ssvb/tinymembench tinymembench] and looking at ''standard memcpy'' numbers, NEO/Air clocked with 408 or 432 MHz show ~435 MB/s while other H3 boards with dual bank DRAM clocked at 624 MHz reach ~900 MB/s (for more details see [http://forum.armbian.com/index.php/topic/1748-sbc-consumptionperformance-comparisons/#entry13958 post #13 in this thread in Armbian forums]). When using [https://github.com/pooler/cpuminer cpuminer] then NEO/Air clocked with 1200 MHz achieve 1.83/1.85833 khash/s with DRAM clocked at 408/432 MHz while an Orange Pi Lite with identical settings (HDMI/Mali disabled and also clocking at 1200 MHz) achieves 2.10867 khash/s with DRAM clocked at 624 MHz (that's a ~12 percent performance loss with this specific workload only due to different DRAM configuration and clockspeed)<br />
<br />
== WiFi ==<br />
NanoPi NEO AIR has an [[Wifi#Ampak|Ampak AP6212]] chip, which needs [https://vps.vdwaa.nl/~jelle/brcm/ special firmware files].<br />
<br />
== USB ==<br />
<br />
The one USB host port exposed as type A receptacle is usb3. Both usb1 and usb2 are available via solder holes.<br />
<br />
== Analog Audio ==<br />
<br />
On NanoPi Air analog audio out and mic in is available on 4 solder pads next to the camera connector. Please check schematic for details.<br />
<br />
= Adding a serial port =<br />
<br />
== Locating the UART ==<br />
<br />
[[File:Nanopi-uart.JPG|thumb|240px|NanoPi NEO UART pins]]<br />
<br />
Four-pin UART0 header is placed next to USB type-A connector. Pinout: GND, 5V, TX, RX. Pin 1 (GND) is the one furthest from the board edge. Logic voltage is 3.3V.<br />
For more instructions refer to our [[UART|UART Howto]].<br />
<br />
= Pictures =<br />
<br />
== NanoPi NEO ==<br />
<gallery><br />
File:NanoPi_NEO_top.jpg<br />
File:NanoPi_NEO_bottom.jpg<br />
File:NanoPi_NEO_1.jpg<br />
File:NanoPi_NEO_2.jpg<br />
File:NanoPi_NEO_3.jpg<br />
File:NanoPi_NEO_4.jpg<br />
File:Nanopi-front.JPG<br />
File:Nanopi-back.JPG<br />
File:Nano_Heatsink.jpg<br />
File:NanoPi_NEO_Cluster.jpg<br />
</gallery><br />
<br />
== NanoPi NEO Air ==<br />
<gallery><br />
File:NanoPi_Air_1.jpg<br />
File:NanoPi_Air_2.jpg<br />
File:NanoPi_Air_3.jpg<br />
</gallery><br />
<br />
= Variants =<br />
<br />
== NanoPi NEO Core ==<br />
<br />
In the NEO Core variant, the ethernet and USB A connectors are replaced with unpopulated headers. The variant also comes with onboard eMMC (4GB/8GB/16GB/32GB).<br />
<br />
= See also =<br />
<br />
* [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air Air device page on FriendlyARM wiki page]<br />
* [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO NEO device page on FriendlyARM wiki page]<br />
* [http://forum.armbian.com/index.php/topic/1580-nanopi-neo-air Armbian forum thread for both devices]<br />
* [http://wiki.friendlyarm.com/wiki/images/9/98/NanoPi-NEO-Air-1608-Schematic.pdf NEO Air Schematic for PCB rev 1.0]<br />
* [http://wiki.friendlyarm.com/wiki/images/a/aa/NanoPi-NEO-1606-Schematic.pdf NEO Schematic for PCB rev 1.0]<br />
* [http://wiki.friendlyarm.com/wiki/images/c/c4/NanoPi-NEO-V1.1-1607-Schematic.pdf NEO Schematic for PCB rev 1.1]<br />
* [http://wiki.friendlyarm.com/wiki/images/1/1c/NanoPi-NEO-V1.2-1608-Schematic.pdf NEO Schematic for PCB rev 1.2]<br />
* [http://wiki.friendlyarm.com/wiki/images/9/99/NanoPi-NEO-1606-dimensions%28dxf%29.zip board mechanical drawings (dxf)]<br />
<br />
== Manufacturer images ==<br />
See the manufacturer's device pages above since links change from time to time.<br />
<br />
[[Category:Devices]]<br />
[[Category:H3 Boards]]<br />
[[Category:FriendlyARM]]<br />
[[Category:Devices with Ethernet port]]<br />
[[Category:Devices with Wifi]]<br />
[[Category:Mainline_U-Boot]]<br />
[[Category:Mainline_Kernel]]</div>Karlphttps://linux-sunxi.org/index.php?title=FriendlyARM_NanoPi_Duo2&diff=22857FriendlyARM NanoPi Duo22019-11-04T12:22:32Z<p>Karlp: Initial page for Duo2</p>
<hr />
<div>{{Infobox Board<br />
| image = [[File:Device_front.jpg|250px]]<br />
| manufacturer = [http://www.friendlyarm.net/ FriendlyARM]<br />
| dimensions = 55''mm'' x 25.4''mm''<br />
| release_date = July 2018<br />
| website = [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_Duo2 Device Product Page]<br />
| soc = [[H3]] @ 1.2Ghz<br />
| dram = 512MiB DDR3-1600<br />
| nand = 0<br />
| power = USB OTG or pin headers, 5V, 2A per manufacturer<br />
| lcd = n/a<br />
| touchscreen = n/a<br />
| video = n/a<br />
| audio = line out and mic in on pin headers<br />
| network = 10/100Mbps Ethernet on pin headers([[Sun8i emac|H3 built-in PHY]]) or BT4.0/WiFi 802.11 b/g/n ([[Wifi#Ampak|Ampak AP6212]])<br />
| storage = µSD, SPI NOR flash footprint<br />
| usb = 1 USB2.0 OTG, 2x USB2.0 Host on pin headers<br />
| other = IRDA, 24 pin camera connector (CSI/OV5640)<br />
| headers = 2xUART, 1xSPI, 1xI2C, 1xEthernet, 2xUSB2.0 Host,Line out, Mic In, CVBS, IRRX<br />
}}<br />
<br />
{{Remove_only_when_finished|This page is still missing pictures.}}<br />
<br />
Compared to other boards, the main selling point here is extremely compact size and ability to be plugged into a breadboard. USB OTG, functional wifi+bt, and a footprint for SPI flash round out the distinguishing features.<br />
<br />
= Identification =<br />
The Duo2 is a small narrow black PCB, densely packed, with "NanoPi Duo2" in very small silkscreen.<br />
<br />
The PCB has the following silkscreened on it:<br />
<pre>NanoPi Duo2<br />
v1.0 1807</pre><br />
<br />
= Sunxi support =<br />
<br />
== Current status ==<br />
Supported in mainline from 5.5<br />
<br />
== Images ==<br />
[[http://download.friendlyarm.com/nanopiduo2| FriendlyARM provides linux 4.14 based images]]<br />
<br />
== BSP ==<br />
FriendlyARM provides both 4.14 and 3.4 legacy trees. <br />
=== 4.14 tree ===<br />
* https://github.com/friendlyarm/linux.git -b sunxi-4.14.y<br />
=== 3.4 tree ===<br />
There's very little reason to use this tree. The board is supported by 4.14 from FriendlyARM themselves, and in mainline from 5.5.<br />
The tree is available at https://github.com/friendlyarm/h3_lichee.git with [[http://wiki.friendlyarm.com/wiki/index.php/NanoPi_Duo2#Make_Your_Own_Linux_System | documentation on the FriendlyARM wiki]]<br />
<br />
== Manual build ==<br />
<br />
You can build things for yourself by following our [[Manual_build_howto | Manual build howto]] and by choosing from the configurations available below.<br />
<br />
=== U-Boot ===<br />
<br />
==== Mainline U-Boot ====<br />
There's no explicit duo2 support in U-Boot, and it's unclear if that's valuable. The [[FriendlyARM_NanoPi_Air]] is equivalent for most purposes. Providing a separate name for the duo2 would be a trivial patch if desired.<br />
<br />
=== Linux Kernel ===<br />
<br />
==== Mainline kernel ====<br />
<br />
Use the ''{{Edit|sun8i-h3-nanopi-duo2.dtb}}'' device-tree binary.<br />
<br />
==== Sunxi/Legacy Kernel ====<br />
<br />
Not documented as not considered useful at this stage.<br />
<br />
== FEL mode ==<br />
No FEL button, the UBOOT pin is pulled up via 10K.<br />
<br />
== LEDS ==<br />
A red and green led are available. The red is pulled up, and intended as a power indicator. Green is free for use.<br />
<br />
== WIFI/Bluetooth ==<br />
The [[Bluetooth#Ampak|Ampak AP6212]] is quite well supported by linux, but it does require suitable firmware files, both for the wifi portion, and the bluetooth portion.<br />
<br />
== Locating the UART ==<br />
<br />
The primary debug uart (uart0) is on the GPIO2 header, at the end nearest the USB connector. There is silk marking RX/TX/Ground.<br />
<br />
= Pictures =<br />
<br />
{{Remove|Take some pictures of your device, [[Special:Upload | upload them]], and add them here. DO NOT UPLOAD PICTURES WHICH YOU PLUCKED OFF THE INTERNET.}}<br />
<br />
<gallery><br />
File:Device_front.jpg<br />
File:Device_back.jpg<br />
File:Device_buttons_1.jpg<br />
File:Device_buttons_2.jpg<br />
File:Device_board_front.jpg<br />
File:Device_board_back.jpg<br />
</gallery><br />
<br />
= See also =<br />
* [[FriendlyARM_NanoPi_Air]] Very similar device, largely just a form factor change<br />
* [http://wiki.friendlyarm.com/wiki/images/a/ab/Schematic_NanoPi_Duo2-V1.0-1807.pdf Schematic for PCB rev 1.0]<br />
* [http://wiki.friendlyarm.com/wiki/index.php/File:Dimensions_NanoPi_Duo2_V1.0_1807_PCB.rar board mechanical drawings (dxf)]<br />
<br />
== Manufacturer images ==<br />
See the manufacturer's device pages above since links change from time to time.<br />
<br />
[[Category:Devices]]<br />
[[Category:H3 Boards]]<br />
[[Category:FriendlyARM]]<br />
[[Category:Devices with Wifi]]<br />
[[Category:Mainline_Kernel]]</div>Karlphttps://linux-sunxi.org/index.php?title=Wifi&diff=22856Wifi2019-11-04T12:09:18Z<p>Karlp: /* Ampak */ add link to bluetooth docs as well</p>
<hr />
<div>=Driver specific information=<br />
<br />
== Allwinner ==<br />
<br />
{| border=1<br />
!scope="col" | Device || Type || sdio id || sunxi-3.4 kernel || mainline kernel<br />
|-<br />
| XR819 || SDIO || [http://pastebin.com/b2NAcvgt 0020:2281] || xradio_wlan ||<br />
|}<br />
<br />
For [http://certifications.prod.wi-fi.org/pdf/certificate/public/download?cid=WFA61880 XR819] BSP driver can found [http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/drivers/net/wireless/xradio/ here] and firmware blobs can be found [http://filez.zoobab.com/allwinner/h2/201609022/android/hardware/broadcom/wlan/bcmdhd/firmware/xr819/ there] or [https://github.com/igorpecovnik/lib/tree/master/bin/firmware-overlay/xr819 here]. A more recent driver variant can be found at [https://transfer.sh/F2ogJ/patch-add-support-xr819.tar.gz patch-add-support-xr819.tar.gz].<br />
<br />
Also some documentation is available now: [[File:XR819_Datasheet_V1.0-EN.pdf]] and [[File:XR819_Application_Guide_V1.0-CH.pdf]]<br />
<br />
May be related to ST cw1XX0 [https://irclog.whitequark.org/linux-sunxi/2016-12-27].<br />
<br />
Initial comparison between cw1200 (<tt>drivers/net/wireless/st/cw1200</tt>) and xradio driver shows that the source code for two drivers are really similar and the st1200 driver can be improved to support both devices.<br />
<br />
A working out-of-tree driver for mainline kernels is at [https://github.com/fifteenhex/xradio].<br />
<br />
== Ampak ==<br />
<br />
Ampak combines broadcom wifi and [[Bluetooth#AMPAK|bluetooth]] chips in single modules.<br />
<br />
=== Ampak Devices ===<br />
{| border=1<br />
!scope="col" | Device || Type || usb/sdio id || module || sunxi-3.4 kernel || mainline kernel<br />
|-<br />
| AP6181 || SDIO/UART || 02d0:a962 || See right || bcmdhd || brcmfmac<br />
|-<br />
| AP6210 || SDIO/UART || 02d0:a962 || See right || bcmdhd || brcmfmac<br />
|-<br />
| AP6212 || SDIO/UART || 02d0:a9a6 || See right || || brcmfmac<br />
|-<br />
| AP6330 || SDIO/UART || 02d0:4330 || See right || || brcmfmac<br />
|-<br />
| AP6335 || SDIO/UART || 02d0:4335 || See right || || brcmfmac<br />
|}<br />
<br />
== Broadcom ==<br />
<br />
=== Broadcom Devices ===<br />
{| border=1<br />
!scope="col" | Device || Type || usb id || module || sunxi-3.4 kernel || mainline kernel<br />
|-<br />
| || || || || ||<br />
|}<br />
<br />
== Espressif ==<br />
<br />
[http://www.espressif.com Espressif] is a fairly young Chinese company.<br />
=== Espressif Devices ===<br />
<br />
{| border=1<br />
!scope="col" | Device || Type || sdio id || module || sunxi-3.4 kernel || mainline kernel<br />
|-<br />
| ESP8089 || SDIO || 6666:1111 || || || out-of-tree driver exists<br />
|}<br />
<br />
=== ESP8089 ===<br />
Firstly, you should use Hans de Goede's [https://github.com/jwrdegoede/linux-sunxi/tree/sunxi-wip sunxi-wip kernel branch] containing various bits and pieces needed to make things work.<br />
<br />
Driver itself is currently in its own repository:<br />
<pre><br />
git clone https://github.com/jwrdegoede/esp8089.git<br />
git checkout -B cleanup origin/cleanup<br />
cd ../linux<br />
make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnu- modules M=../esp8089 CONFIG_ESP8089=m<br />
</pre><br />
Do not forget to copy <tt>firmware/*.bin</tt> to <tt>/lib/firmware/</tt> on the target system.<br />
<br />
== iNet ==<br />
<br />
=== iNet Devices ===<br />
{| border=1<br />
!scope="col" | Device || Type || usb id || module || sunxi-3.4 kernel || mainline kernel<br />
|-<br />
| iNet i10 || || || || ||<br />
|}<br />
<br />
== RDA ==<br />
<br />
[http://www.rdamicro.com/ RDA Microelectronics] is a relatively unknown and new chinese chipmaker.<br />
<br />
{| border=1<br />
!scope="col" | Device || Type || usb id / sdio id || module || sunxi-3.4 kernel || mainline kernel<br />
|-<br />
| RDA5990P || || || || || <br />
|-<br />
| RDA5991 || SDIO || 5449:0145 || || ||<br />
|}<br />
<br />
The [http://www.rdamicro.com/products/Detail_273.aspx RDA5990P] is a single chip solution which includes Wifi, Bluetooth and an FM radio. Some code for this wifi chip is available in [https://github.com/linuxium/3188-SRC-ORIG/tree/master/kernel/drivers/net/wireless/rda5990 a Rockchip RK3188 kernel tree], but nobody has tested or ported this code yet.<br />
<br />
Datasheets: [http://pkgbuild.com/~jelle/RDA5990P_RDA.pdf RDA5990P] [http://pkgbuild.com/~jelle/RDA5990_RDA.pdf RDA5990]<br />
<br />
== Realtek ==<br />
<br />
Most of the USB-based Realtek 8xxx are supported by the '''rtl8xxxu''' which is using the MAC80211 framework. Please always try this driver first, because it seems to be a lot more stable than "official" driver.<br />
=== USB-based ===<br />
{| border=1<br />
!scope="col" | Device || Type || USB id || mainline kernel || legacy (sunxi-3.4)<br />
|-<br />
| RTL8188CTV || USB || 0bda:8176 || <tt>'''rtl8xxxu'''</tt> / <tt>rtl8192cu</tt> || <tt>8192cu</tt><br />
|-<br />
| RTL8188CUS || USB || 0bda:8176 || <tt>'''rtl8xxxu'''</tt> / <tt>rtl8192cu</tt> || <tt>8192cu</tt><br />
|-<br />
| RTL8188ETV || USB || 0bda:0179 || <tt>rtl8188eu</tt> (staging) || <tt>8188eu</tt> (see below)<br />
|-<br />
| RTL8188EUS || USB || 0bda:8179 || <tt>rtl8188eu</tt> (staging) || <tt>8188eu</tt> (see below)<br />
|-<br />
| RTL8192CU || USB || 0bda:018a || <tt>rtl8192cu</tt> || <tt>8192cu</tt><br />
|- <br />
| RTL8723AU || USB || 0bda:0724 || <tt>'''rtl8xxxu'''</tt> / <tt>rtl8723au</tt> (staging) || <tt>8723au</tt><br />
|-<br />
|}<br />
<br />
=== SDIO-based ===<br />
{| border=1<br />
!scope="col" | Device || Type || SDIO id || mainline kernel || legacy (sunxi-3.4)<br />
|-<br />
| RTL8189ES || SDIO || ?? || out-of-tree driver (see below) || ??<br />
|-<br />
| RTL8189FTV || SDIO || <tt>024c:f179</tt> || out-of-tree driver (see below) || ??<br />
|-<br />
| RTL8723BS<br>RTL8703AS || SDIO || <br />
<tt><br />
024c:0523<br><br />
024c:0623<br><br />
024c:0626<br><br />
024c:b723</tt><br />
|| <tt>r8723bs</tt> (staging) || <tt>8723bs</tt><br />
|- <br />
| RTL8822BS || SDIO || ?? || out-of-tree driver [https://github.com/ChalesYu/rtl8822bs-aml link] || ??<br />
|}<br />
<br />
<br />
==== RTL8189ES / RTL8189ETV ====<br />
Driver has its own repository:<br />
<pre><br />
git clone https://github.com/jwrdegoede/rtl8189ES_linux.git<br />
cd rtl8189ES_linux.git<br />
make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnu- KSRC=../linux<br />
</pre><br />
<br />
<br />
==== RTL8189FTV ====<br />
Driver has its own repository:<br />
<pre><br />
git clone https://github.com/jwrdegoede/rtl8189ES_linux.git<br />
cd rtl8189ES_linux.git<br />
git checkout -B rtl8189fs origin/rtl8189fs<br />
make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnu- KSRC=../linux<br />
</pre><br />
<br />
=== Legacy sunxi-3.4 kernel support ===<br />
==== Driver refusing to load ====<br />
When using the '''rt5370sta''', '''8188eu''', '''8189es''' or '''8192cu''' drivers, which are all for USB based realtek devices, it might occur that the driver refuses to load:<br />
<br />
<pre><br />
ERR: script_parser_fetch usb_wifi_usbc_num failed<br />
modprobe: can't load module 8188eu (kernel/drivers/net/wireless/rtl8188eu/8188eu.ko): Cannot allocate memory <br />
</pre><br />
<br />
This is because the usb_wifi_para section is missing from your script.bin:<br />
<br />
<pre><br />
[usb_wifi_para]<br />
usb_wifi_used = 1<br />
usb_wifi_usbc_num = 2<br />
</pre><br />
<br />
Where usb_wifi_usbc_num is the usbc to which your realtek usb wireless chip is attached.<br />
<br />
Edit the .fex file and create the script .bin as explained in our [[Manual_build_howto | Manual build howto]], and [[New_Device_howto#Step_6:_Add_support_to_sunxi-boards | send a patch to sunxi-boards in to our mailinglist.]]<br />
<br />
==== 8188eu driver on sunxi-3.4 ====<br />
The sunxi-3.4 branch currently has [https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/net/wireless/rtl8188eu/include/rtw_version.h v4.1.2_4787.20120803] available. There are newer versions available at https://github.com/lwfinger/rtl8188eu/ which are [https://github.com/lwfinger/rtl8188eu/blob/master/include/rtw_version.h v4.1.4_6773.20130222] and [https://github.com/lwfinger/rtl8188eu/blob/v4.1.8_9499/include/rtw_version.h v4.1.8_9499.20131104]. There's also a v4.1.8 file available at https://github.com/LazyZhu/myblog/raw/gh-pages/file/RTL8188EUS_RTL8189ES_linux_v4.1.8_9499.20131104.zip which is likely the original from Realtek.<br />
<br />
Here's how to compile the latest version from Realtek:<br />
<br />
Extract the driver/rtl8188EUS_rtl8189ES_linux_v4.1.8_9499.20131104.tar.gz from the RTL8188EUS_RTL8189ES_linux_v4.1.8_9499.20131104.zip file and extract it. These instructions assume your <code>linux-sunxi</code> directory is in the same directory as your <code>rtl8188EUS_rtl8189ES_linux_v4.1.8_9499.20131104</code> directory. It's also assumed that you've configured the kernel to include the 8188eu driver that's part of linux-sunxi.<br />
<br />
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -C ../linux-sunxi/ M=`pwd` modules<br />
<br />
copy the <code>8188eu.ko</code> file over to the device and then install it into your kernel with the following commands (on the device as root):<br />
<br />
modprobe -r 8188eu<br />
rm -rf /lib/modules/`uname -r`/kernel/drivers/net/wireless/rtl8188eu<br />
install -p -m 644 8188eu.ko /lib/modules/`uname -r`/kernel/drivers/net/wireless/<br />
/sbin/depmod<br />
modprobe 8188eu<br />
<br />
There are two changes you may want to make in <code>include/autoconf.h</code>:<br />
<br />
1. The default is to output a LOT of logging and you can disable that by commenting out the following line:<br />
#define CONFIG_DEBUG /* DBG_871X, etc... */<br />
<br />
2. The default is to disable the activity LED on the wifi device which you may want to see to know that it's working. You can change that by un-commenting the following line:<br />
//#define CONFIG_LED<br />
<br />
= Software Configuration =<br />
== Debian/ubuntu with NetworkManager==<br />
NetworkManager uses its own wpa_supplicant configuration. That is the reason why manually editing /etc/network/interfaces to use wpa_supplicant does not work together with NetworkManager.<br />
<br />
You have to disable all interfaces in /etc/network/interfaces e.g. by commenting out each line by inserting "#" as a first character. <br />
<br />
You even have to '''disable Ethernet section''' to use wifi in network manager. Here is an example<br />
# interfaces(5) file used by ifup(8) and ifdown(8)<br />
auto lo<br />
iface lo inet loopback<br />
<br />
#allow-hotplug eth0<br />
#iface eth0 inet dhcp<br />
<br />
#auto eth0<br />
#iface eth0 inet static<br />
#address 192.168.101.50<br />
#netmask 255.255.255.0<br />
#gateway 192.168.101.1<br />
#broadcast 192.168.101.255<br />
<br />
#auto wlan0<br />
#iface wlan0 inet dhcp<br />
# wpa-ssid YOUR-NETWORK-NAME<br />
# wpa-key-mgmt WPA-PSK<br />
# wpa-group TKIP CCMP<br />
# wpa-psk YOUR-NETWORK-KEY<br />
<br />
<br />
At your desktop there should emerge a network icon from NetworkManager in the task bar. You can edit the network setting with the gui dialogs.<br />
<br />
== Debian/ubuntu without NetworkManager==<br />
=== Setup with wpa_supplicant and without network manager ===<br />
<br />
There are many tutorials out there on how to do this. Here is [http://prupert.wordpress.com/2010/06/25/how-to-configure-wireless-wifi-networking-in-ubuntu-via-the-command-line-cli/ a good one].<br />
<br />
==== Disabling networkmanager. Fully. ====<br />
<br />
Even with the common trick of putting the following in /etc/NetworkManager/NetworkManager.conf<br />
<pre><br />
[ifupdown]<br />
managed=true<br />
</pre><br />
the despotic NetworkManager still will be messing up your careful setup from /etc/network/interfaces, and you might, once again, be left without wifi upon the next reboot.<br />
<br />
To stop NetworkManager from running altogether, you can run the following (as root):<br />
<br />
<pre><br />
echo "manual" > /etc/init/network-manager.override<br />
</pre><br />
<br />
Now, at least on ubuntu, your wifi driver, wpa_supplicant and ifupdown will not be smacked about anymore.<br />
<br />
==== Simple and dumb WPA setup ====<br />
<br />
Install the following packages, if they are not installed already:<br />
<br />
apt-get install wireless-tools wpasupplicant<br />
<br />
Edit /etc/network/interfaces and add the following:<br />
<br />
auto wlan0<br />
iface wlan0 inet dhcp<br />
wpa-ssid YourSSID<br />
wpa-psk YourWPASharedKey<br />
<br />
This is the most basic, but static, setup possible for wifi. If you need anything more, you need to read up on wpa_supplicant, or run through one of the tutorials referenced above.<br />
<br />
= Devices =<br />
<br />
The following devices all come with an built-in wifi chip.<br />
<br />
<categorytree mode=pages hideroot=on depth=1>Devices_with_Wifi</categorytree><br />
<br />
[[Category:Tutorial]]<br />
[[Category:Software]]</div>Karlphttps://linux-sunxi.org/index.php?title=Bluetooth&diff=22815Bluetooth2019-10-31T23:37:13Z<p>Karlp: added a few notes on adding ampak support to a new board, post linux 5.2</p>
<hr />
<div>= Overview of the Bluetooth Stack =<br />
Bluetooth provides a large number of application [http://en.wikipedia.org/wiki/List_of_Bluetooth_profiles profiles]. Examples are playing audio between devices (A2DP), wireless keyboards and mice (HID) and transferring data wirelessly between devices (FTP, OPP).<br />
<br />
These application profiles work on a stack of [http://en.wikipedia.org/wiki/List_of_Bluetooth_protocols protocols], similar in concept to the networking and USB stacks. For example the Object Push Profile (OPP) uses the OBject EXchange (OBEX) protocol, which uses the Radio Frequency COMMunication (RFCOMM) protocol, which uses the Logical Link Control and Adaptation Protocol (L2CAP), which uses the Host Controller Interface (HCI) protocol, which uses the radio link protocols.<br />
<br />
This can rapidly become a complex area, but the user space tools make this all "just work" for users. It is beyond the scope of this page to configure Bluetooth profiles.<br />
<br />
The focus of this wiki page is on the interface between host and controller.<br />
<br />
= User Space =<br />
The collection of user space tools is maintained by the [http://www.bluez.org Bluez] project.<br />
Note that the tool chain requires D-Bus. For application development the [http://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc D-Bus API is documented in the Bluez source].<br />
<br />
A contemporary short instruction for CLI usage can be found in the [https://wiki.archlinux.org/index.php/bluetooth#Configuration_via_the_CLI Archlinux Wiki].<br />
<br />
= Host Controller Interface (HCI) =<br />
The Host Controller Interface is a lower level protocol in the Bluetooth stack. A host is usually a PC, tablet, SBC, phone, etc. A controller is the chip with the Bluetooth radio. Although some simpler Bluetooth devices, such as a headset, may have the host and controller implemented on a single processor.<br />
<br />
The communication layer between host and controller can be over a number of interfaces, for example UART, USB and SPI.<br />
<br />
The purpose of a Bluetooth driver for a sunxi system on chip is to set up the Bluetooth controller ready for user space to provide Bluetooth applications.<br />
<br />
= HCI Transport Layer =<br />
This is the physical interface between host and controller. A number of [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/bluetooth transport layer drivers] are provided in the Linux kernel and the Kernel's [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/bluetooth/Kconfig Kconfig file] for the drivers gives a useful description.<br />
<br />
== UART ==<br />
The Linux kernel driver is <kbd>hci_uart</kbd><br />
<br />
This is a serial interface and there are several protocols used, e.g. H4, H5, BCSP. The H4 protocol is probably the most common and uses serial control lines. The H5 protocol is a three-wire protocol so no serial control lines are used. There are also a number of proprietary protocols, BCSP (BlueCore Serial Protocol) being an example.<br />
<br />
The datasheet for the controller and the schematics for the device should be enough to determine which protocol is used.<br />
<br />
== USB ==<br />
The Linux kernel driver is <kbd>btusb</kbd><br />
<br />
== Other ==<br />
Examples are SPI and SDIO. These transport layers do not appear to be used in any devices with AllWinner SoCs.<br />
<br />
= Controller Specific Information =<br />
This section contains details on Bluetooth controller chips used alongside sunxi system on chips and how to drive them. A controller chip will need one or more of the following:<br />
* Power management, usually wake and sleep<br />
* Configuration of the transport between host and controller, often over UART, but could also be SPI or USB<br />
* Copying of controller's firmware to controller on start up<br />
* Co-ordination on the host with other drivers, e.g. Bluetooth A2DP will also need the audio driver configured<br />
<br />
== AMPAK ==<br />
From Linux 5.2, there's nice clean upstream support for broadcom bluetooth. See http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/610954.html for the full details. If you're adding bluetooth nodes to existing hardware, the quick traps are:<br />
* missing the [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi#n103 clocks/clock-names nodes] on the wifi_pwrseq node.<br />
* thinking that the [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi#n228 "bt-reset-n" signal should be flagged as active low].<br />
Remember, you need kernel config option CONFIG_SERIAL_DEV_BUS to be able to select CONFIG_BT_HCIUART_BCM<br />
If you have these wrong, your kernel will keep reporting lines like ```Bluetooth: hci0: command 0x0c03 tx timeout``` 0x0c03 is the standard HCI request to reset the part, so this means your device is not (yet) responsive.<br />
Once this is all correct, your next trap will be finding suitable firmware, and getting it named correctly, though fortunately at this point, the kernel will simply tell you. linux-firmware repo has very few of the bluetooth files, your best bet is [https://github.com/armbian/firmware/tree/master/ap6212 armbian's] [https://github.com/armbian/firmware/tree/master/ap6210 repo], though they will all need renaming, because armbian patched all that too.<br />
=== AP6210 ===<br />
The AMPAK AP'''6210''' combines Broadcom Wifi (BCM433'''62''') and Bluetooth 4.0 (BCM207'''10''') chips in a single [http://en.wikipedia.org/wiki/System_in_package system in package]. The package exposes only the Bluetooth chip's UART transport layer. Audio is carried over a PCM interface.<br />
<br />
Procedure for Sunxi Linux 3.4 kernel:<br />
* [[Cubietruck/Bluetooth]] - notes on this Wiki about the Cubietruck that contains an AP6210<br />
* [http://archlinuxarm.org/forum/viewtopic.php?f=33&t=7253 "Got bluetooth working on Cubietruck - proof of concept"] - Arch Linux forum<br />
* [https://github.com/EddyBeaupre/ap6210 EddyBeaupre/ap6210] - GitHub, "Wifi and Bluetooth driver for CubieTruck"<br />
<br />
Procedure for mainline Linux kernel:<br />
* [https://github.com/phelum/CT_Bluetooth phelum/CT_Bluetooth] - working procedure for Bluetooth with AP6210 using both Linux mainline and 3.4 kernels, still a work in progress and the author is seeking feedback on the [[Mailing_list]]<br />
* [https://github.com/wens/linux/commit/b3df2aa9dfb48d58ee590c9686dfc0e3946de5fc "ARM: dts: sun7i: add bluetooth module to CubieTruck DTS"] - patch as an example DTS file<br />
* [[User_talk:Sehraf]] - Sehraf has notes on an attempt to get the AP6210 working<br />
<br />
== Broadcom ==<br />
Broadcom provide a [https://code.google.com/p/broadcom-bluetooth/ tool] for Linux to configure and test Broadcom Bluetooth chips. The tool source code is licensed under the Apache License 2.0. Binaries are also available for download. This tool can be used to upload firmware to the controller. For example a firmware upload over UART:<br />
brcm_patchram_plus -d --no2bytes --patchram firmware_file.hcd /dev/ttyS1<br />
=== BCM20710 ===<br />
The BCM20710 provides both SPI and UART transport layers. See [http://dl.linux-sunxi.org/users/turl/20710-DS103-RDS.pdf BCM20710 datasheet] for more details.<br />
<br />
The firmware needs to be uploaded to the controller. The firmware .hcd file is available [http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/ here].<br />
<br />
== Realtek ==<br />
<br />
=== 8723au ===<br />
<br />
This device has no driver included in the kernel, but you can install it separately. It also supports [[Wifi#8723au|Wifi]] functionality.<br />
<br />
The Bluetooth functionality is included in the hardware that does the wifi, so you may need to have the wifi drivers described above working to also have this working. However, don't expect it to work particularly well as there appear to be numerous bugs (in either the driver or the hardware or both). There seems to also be an issue where using both wifi and bluetooth at the same time cause severe interference to the point where connections are dropped (this has been seen in the stock Android firmware as well).<br />
<br />
check out the code from https://github.com/lwfinger/rtl8723au_bt.git and compile with the following command:<br />
<br />
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -C ../linux-sunxi/ M=`pwd` modules<br />
<br />
'''NOTE:''' This command assumes that you checked out the rtl8723au_bt repo into the same directory as the linux-sunxi repo (note the <code>../linux-sunxi/</code> points to where your local kernel repository is)<br />
<br />
copy the *.bin and *.ko files over to the device and run the following on the device (as root) where you have your files:<br />
<br />
mkdir -p /lib/firmware/rtk_bt<br />
cp rlt8723a_chip_b_cut_bt40_fw_asic_rom_patch-svn8511-0x0020342E-20121105-LINUX_USB.bin /lib/firmware/rtk_bt/rtk8723a.bin<br />
install -p -m 644 rtk_btusb.ko /lib/modules/`uname -r`/kernel/drivers/bluetooth/<br />
/sbin/depmod<br />
modprobe rtk_btusb<br />
<br />
Apparently, the RTL8723AU driver (r8728au) in mainline serves only wifi, though it has an option to coexist with BT.<br />
[https://github.com/lwfinger/rtl8723au_bt/tree/new rtl8723au_bt, branch new] is the work repository for<br />
a current bluetooth driver.<br />
<br />
=== 8723bs ===<br />
Firmware and userspace loader can be found [https://github.com/lwfinger/rtl8723bs_bt here].<br />
<br />
[[Category:Tutorial]]<br />
[[Category:Software]]</div>Karlphttps://linux-sunxi.org/index.php?title=Bootable_SPI_flash&diff=22630Bootable SPI flash2019-08-13T14:37:43Z<p>Karlp: sunxi-fel spi support has landed upstream</p>
<hr />
<div>== Introduction ==<br />
<br />
All currently known Allwinner SoCs can boot from SPI flash, which usually has the lowest [[BROM|boot priority]] and is probed only after all the other options fail ([[Bootable SD card|SD card]], [[NAND]] and [[eMMC]]).<br />
<br />
== Information for devboard designers ==<br />
The SPI flash can be used to store a bootable firmware on the low cost development boards, which do not offer any other kind of non-removable storage (NAND or eMMC).<br />
<br />
The minimum amount of the required storage would be <b>1 MiB (8 Mbit)</b> to fit a user friendly bootloader with some advanced features. The prices of suitable SPI NOR flash chips seem to be around 10-20 cents on AliExpress (or even as low as [http://www.aliexpress.com/item/W25Q16BVSSIG-W25Q16BVSIG-2MB-SOP8/32660083443.html only 4 cents]?). This is non-negligible, but might be still worth it at least to avoid the frustrated ''"I plugged the power but there is nothing on the monitor"'' support requests from inexperienced users.<br />
<br />
There is no point using SPI NOR flash chips larger than <b>16 MiB (128 Mbit)</b>. The primary use for this additional space would be a storage of some size reduced Linux kernel together with a small [https://buildroot.org/ Buildroot] generated compressed initrd image. And if no operating system is found on the SD card, then this built-in kernel+initrd can be booted instead. The whole point of having a kernel+initrd bundle in addition to just a bootloader is that developing the initrd is relatively easy, because it can be implemented using scripting languages and rely on existing GUI toolkits (Qt, FLTK, ...) or offer a text based user interface (via [https://en.wikipedia.org/wiki/Dialog_%28software%29 dialog] or something similar). As for the provided functionality, it can do some hardware diagnostic self-tests and even update itself over Internet. In order to have a realistic size estimate, we can look at the [https://github.com/ssvb/lima-memtester/releases/tag/20151207-orange-pi-pc-fel-test kernel+intrd used for lima-memtester] and see that it's size is less than 7 MiB, which would fit even into a 8 MiB (64 Mbit) SPI NOR flash chip. So it's a tight fit with 8 MiB (64 Mbit) and a lot of headroom with 16 MiB (128 Mbit). And an additional factor to consider is that programming NOR flash is slow and maxes at around ~200 KiB/s, so having smaller firmware reduces the time needed for flashing.<br />
<br />
U-Boot can run UEFI applications since the release v2016.05, such as Grub2 or anything else. This is very nice, because it may provide a middle ground solution in terms of the firmware size (not as easy to implement as the kernel+initrd, but at least better than native U-Boot application hacks). There are some UEFI ports of the scripting language interpreters already available, such as [https://firmwaresecurity.com/2015/05/28/lua-for-uefi Python/Lua] and [https://firmwaresecurity.com/tag/mruby-on-efi-shell Ruby] ([[User:Ssvb|Ssvb]]'s favorite). But it is still not quite clear what is the UEFI GUI toolkits story.<br />
<br />
The SPI flash chip needs to be connected to SPI0 pins (port C), which are multiplexed with NAND. There are also HOLD and WP pins, which need to be pulled up and optionally connected to the SoC GPIO pins for implementing write protect control in software. The table below lists the exact pins for different SoC variants and some additional notes:<br />
<br />
{| class="wikitable"<br />
! SoC name<br />
! SPI0 pins (MOSI,MISO,CLK,CS)<br />
! Total number of SPI controllers<br />
! Available SPI controllers if SPI flash is used<br />
! Possible implications of using SPI flash<br />
! Notes<br />
|-<br />
| [[A10]]/[[A20]] || PC0,PC1,PC2,PC23 || 4 || 4 || Nothing significant. || SPI0 is also available on pins PI12,PI13,PI11,PI10 and can be used for other purposes even if a bootable SPI flash is hooked to PC0,PC1,PC2,PC23.<br />
|-<br />
| [[A13]] || PC0,PC1,PC2,PC3 || 3 || 2 || Only one NAND chip can be used. || The SPI0_CS0 pin is multiplexed with NCE1 (the CS pin of the second NAND).<br />
|-<br />
| [[H3]]/[[H5]] || PC0,PC1,PC2,PC3 || 2 || 1 || Only one NAND chip can be used. The only remaining free SPI1 controller is multiplexed with UART3 on pins PA15,PA16,PA14,PA13. || The SPI0_CS pin is multiplexed with NAND_CE1 (the CS pin of the second NAND).<br />
|-<br />
| [[A64]] || PC0,PC1,PC2,PC3 || 2 || 1 || Only one NAND chip can be used. The only remaining free SPI1 controller is multiplexed with LCD and CCIR (camera?) on pins PD2,PD3,PD1,PD0 and this may be a problem. || The SPI0_CS pin is multiplexed with NAND_CE1 (the CS pin of the second NAND).<br />
|}<br />
It looks like SPI is getting gradually phased out from the newer Allwinner SoCs. This may be a problem for providing the necessary SPI pins for the [http://elinux.org/RPi_Low-level_peripherals#General_Purpose_Input.2FOutput_.28GPIO.29 Raspberry Pi compatible expansion headers] or [https://en.wikipedia.org/wiki/UEXT OLIMEX UEXT connectors].<br />
<br />
== The BROM implementation details ==<br />
<br />
[[File:Pine64_board_booted_over_SPI.jpg|thumb|160px|A demo showcasing the SPI boot on Pine64]]<br />
<br />
For SPI NOR flash booting, the BROM sets up 6 MHz (OSC24M with divisor 4?) clock frequency for SPI0 and then issues a sequence of Read Data Bytes (03h) commands. Each of these commands is encoded in 4 bytes (1 byte for the command id and 3 bytes for the address). The first command reads 256 bytes from the address 0. If a valid eGON header is recognized, then a sequence of commands reading 2048 byte blocks is done next. The first 2048 byte block is read from the address 0, the second 2048 byte block is read from the address 2048 and this continues until the whole first stage bootloader is transferred.<br />
<br />
Some SoCs can also boot from SPI NAND flash. Here the BROM tries to read a valid first stage bootloader starting from page number 0, 32, 64, 96, 128, 160, 192 and 224. It only reads the first 1024 bytes from every page. Since it simply sends the standard SPI NAND flash commands, it is a good idea to use a flash with ECC turned on by default and is performed by the flash itself, since errors cannot otherwise be corrected.<br />
<br />
As an experiment, it is possible to configure SPI on one board in the slave mode, connect jumper wires and emulate the SPI flash for the BROM in another board. But the timing constraints are too tight to do a perfect emulation. A perfect emulation would need to correctly handle the Read Data Bytes command, which means that after the last bit of the address is received, the first bit of data from that address needs to be served back in the next SPI cycle. With such a protocol, we can't benefit from any kind of receive and transmit buffering and make use of the hardware SPI controller. For the GPIO bit-banging implementation of the 6 MHz SPI, we have around ~170 cycles per SPI bit at the 1008 MHz CPU clock frequency. This time is comparable to the DRAM access latency, so we are in a big trouble if we get any L2 cache misses (though this can be mitigated by prefetching the right cache line after receiving just enough of the address bits). Moreover, the GPIO itself is relatively slow and it takes a huge amount of CPU cycles to read/write GPIO registers. So a simplistic approach is just to use the SPI controller hardware, ignore any received commands and stream the data according to the expected pattern. That would be 4 padding bytes, then 256 initial bytes of the firmware, then 4 bytes padding again and 2048 initial bytes of the firmware, etc. And this works, see the picture on the right side :-)<br />
<br />
Such SPI flash emulation using another board probably does not make much practical sense because it is possible to just connect a real SPI flash chip to the SPI pins. This was only a method get some information about the BROM behaviour. A more complete SPI flash emulation might be an interesting exercise to be done using the upcoming [https://olimex.wordpress.com/2016/05/06/ice40hx1k-evb-open-source-hardware-fpga-board-designed-with-kicad-and-working-with-icestorm-foss-toolchain-first-prototypes-are-ready-and-run iCE40HX1K-EVB open source hardware FPGA board from OLIMEX].<br />
<br />
== Software development and trying something here and now ==<br />
<br />
{{alert|This section is a bit out of date because the [[Xunlong Orange Pi PC 2]] board is now available and it has built-in SPI flash. Some other boards are also underway and are expected to become available soon.}}<br />
<br />
[[File:Xunlong Orange Pi PC with improvised SPI flash shield.jpg|thumb|160px|W25Q SPI flash module connected to the board expansion header]]<br />
<br />
While there are no known boards with built-in SPI flash, it is still possible to arrange some test setup. The SPI0 pins are often available on the expansion headers. The picture on the right side shows how the SPI0_CS,SPI0_CLK,SPI0_MOSI,SPI0_MISO,3V3,GND pins on the [[Xunlong Orange Pi PC]] expansion header are connected to the CS,CLK,DI,DO,VCC,GND pins on the [http://www.ebay.com/itm/W25Q-Windbond-Serial-Flash-Memory-Module-SPI-W25Q128B-BIOS-25Q64BVSIG-EEPROM-/181873964697 W25Q SPI flash module]. The wires are entangled and tied in a knot, with the SPI flash module being more or less fixated in place and sticking upwards. Not a very aesthetically pleasing sight, but it works fine for testing the software.<br />
<br />
The availability of the SPI0 (port C) pins on the expansion headers is both a blessing and a curse for the existing development boards, such as [[Xunlong Orange Pi PC]] and [[Pine64]]:<br />
* On one hand, we can connect an SPI flash module to these pins using jumper wires and use this for prototyping and debugging code. Also some vendor may start making and selling nice factory-made SPI flash shields for the Raspberry Pi compatible expansion header.<br />
* On the other hand, adding on-board SPI flash in the next revision of the same development board may be problematic because this can break compatibility with the existing shields and the software already developed for them. The device tree does not seem to be good enough (please correct this statement if it is wrong) and has no concept of describing standard GPIO expansion headers with full flexibility of transparently remapping pins in different board revisions. For example, replacing SPI0 pins with SPI1 pins on the 40pin Raspberry Pi compatible expansion header and describing this change only in one place in the board-specific DTS file (so that no changes are necessary in any shield-specific device tree overlays or in the userland software).<br />
<br />
== U-Boot support ==<br />
<br />
{| class="wikitable"<br />
! SoC name<br />
! SoC support status in U-Boot<br />
|-<br />
| [[A10]] || Supported since v2016.09. But still untested because SPI0 is not easily accessible on popular boards. The test has been done only using a SPI2 based modification.<br />
|-<br />
| [[A13]] / [[A20]] [[A64]] / [[H3]] || Supported since v2016.09<br />
|-<br />
| [[H5]] || WIP<br />
|}<br />
<br />
==== The SPL ====<br />
<br />
===== Current status =====<br />
<br />
The basic SPI boot support is available since v2016.09 release. Note that booting from SPI flash is currently disabled by default and it is necessary to add one line to the board defconfig in order to use it:<br />
<br />
CONFIG_SPL_SPI_SUNXI=y<br />
<br />
In principle, enabling SPI flash support by default on every sunxi board should have no negative consequences for any other use cases, because this code only gets activated when the SPL part has been booted from SPI (by looking at the byte at the [https://patchwork.ozlabs.org/patch/622173/ offset 0x28 in the SPL header]). The only potential concern is the code size, which gets increased by ~370 bytes.<br />
<br />
===== Future improvements =====<br />
<br />
Taking care of the [https://github.com/ARM-software/arm-trusted-firmware ATF] and the [[AR100]] firmware may need some additional tricks on AArch64 (packing multiple blobs in a [http://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/source_file_format.txt FIT] container? or use something more lightweight?). Though this is not really SPI boot specific.<br />
<br />
Running SPI at only 6 MHz might be not fast enough and adding something like ~0.5 second to the boot time (needed to transfer ~500KB of the main U-Boot binary). In order to improve boot time a little bit, probably the SPL header can be extended to include a special optional field for the maximum supported SPI clock speed and also the number of dummy cycles for the Read Data Bytes at Higher Speed (0Bh) command. This information can be added to the SPL header by the firmware flasher software (see the "Upgrading the SPI flash firmware" section).<br />
<br />
==== The main U-Boot binary ====<br />
<br />
The main U-Boot binary can get a more complete implementation for handling SPI flash, also with a full write support by making use of the driver model and the existing SPI framework. However please also see the "Security considerations" section below, because it might be unreasonable to allow accessing the SPI flash from U-Boot in the case if U-Boot runs in the non-secure mode on AArch64. Either way, the SPI flash support in the main U-Boot binary is very much optional.<br />
<br />
==== SPI driver ====<br />
<br />
A [https://github.com/StephanvanSchaik/u-boot/tree/sunxi-spi driver model compatible SPI driver for u-boot] was worked on and is now available in mainline u-boot (see below). In combination with the earlier work on the SPL, this driver allows for booting both u-boot and Linux from SPI flash. At the moment, the following boards have been tested:<br />
<br />
* H2+ Orange Pi Zero with Macronix MX25L1605D 16 Mbit<br />
* A20 OLinuXino LIME 2 with Winbond W25Q128BV 128 Mbit (booting FIT image from SPI flash)<br />
* A64 Pine64+ with Winbond W25Q128BV 128 Mbit (using [https://github.com/apritzel/u-boot/tree/sunxi64-beta apritzel's sunxi64-beta64 branch])<br />
* A64 OLinuXino with Eon EN25Q64 64 Mbit (using [https://github.com/apritzel/u-boot/tree/sunxi64-beta apritzel's sunxi64-beta64 branch])<br />
<br />
Commits are available that modify the configs and device trees for these boards to enable full support by default.<br />
<br />
After the u-boot binary has been built, it can be run on the board using the sunxi-fel tool or by programming the SPI flash chip. To load and boot a FIT image stored at 0x100000, the following sequence of commands can be used (assuming the size of the image is 0x400000):<br />
<br />
sf probe 0:0 6000000<br />
sf read 42000000 100000 400000<br />
bootm 0x42000000<br />
<br />
The flash chip can also be erased and modified from within u-boot.<br />
<br />
If you are trying to boot u-boot SPL from SPI flash directly on an Allwinner A10/A20 board, then make sure to power it using USB Y or AC. When the USB OTG cable is attached to a computer to power the board, it won't boot.<br />
<br />
===== Mainline u-boot =====<br />
<br />
A SPI flash driver is now available in mainline u-boot:<br />
<br />
https://git.denx.de/?p=u-boot.git;a=commit;h=7f25d8179776226a8ecfbaad3d3a88e9acd89f28<br />
<br />
You will need to enable CONFIG_SPI, CONFIG_SUN4I_SPI, CONFIG_CMD_SF, CONFIG_CMD_SSPI, CONFIG_DM_SPI, CONFIG_DM_SPI_FLASH, CONFIG_SPI_FLASH and optionally CONFIG_SPI_FLASH_MACRONIX and CONFIG_SPI_FLASH_WINBOND.<br />
<br />
The device tree of the device will also need to be modified; see the various dts commits here: https://github.com/StephanvanSchaik/u-boot/commits/sunxi-spi<br />
<br />
== Reliability considerations ==<br />
<br />
The SPI NOR flash chips are typically rated for 100000 erase cycles and 20 years of data retention. Also they have much lower data density than NAND and are sold without bad blocks. Still it is an open question whether any bad blocks may appear over time on some fraction of devices (if anyone has any relevant references, please add them here).<br />
<br />
As a way to mitigate the risks, it may be possible to write a small bootable stub into the first 4096 byte sector on the SPI flash. The smallest possible size reduces the chances of it being damaged, also it does not need to be updated nearly as frequently as U-Boot. Right after this stub, there can be two copies of the regular U-Boot SPL. The bootable stub can then do the checksum verification and pick a non-damaged SPL copy (if one of them goes bad). As an additional bonus, such stub can support 40 KiB size for the SPL, thus overcoming the BROM limitation. As for the main U-Boot binary, storing two copies would waste too much space. But having CRC32 protected data blocks and an extra parity block can make it more damage resistant.<br />
<br />
A rather old, but [http://www.infradead.org/pipermail/linux-mtd/2005-October/014153.html interesting post] in the linux-mtd mailing list explained how the NOR flash wears out. Presumably it takes time for the unreliable bit to flip from 0 to 1, so this has some implications on the verification stage after the firmware had been programmed (do we need an extra delay there?).<br />
<br />
== Security considerations ==<br />
<br />
It's a good idea to prevent unauthorized update of the firmware code (search for "BIOS trojan" keywords on google for more information on this topic). A malicious software trying to gain even more control over the system after exploiting one of the [https://en.wikipedia.org/wiki/Privilege_escalation privilege escalation] bugs in Linux could try a few tricks, listed in the table below.<br />
<br />
{| class="wikitable"<br />
! A possible attack vector<br />
! Risk mitigation<br />
|-<br />
| Program the SPI flash using the SPI0 controller. || There are some secure/non-secure peripheral access configuration knobs in the newer SoC variants, which can be investigated. {{red|Still untested and needs to be confirmed.}}<br />
|-<br />
| Program the SPI flash using simple GPIO bit-banging. || There are some secure/non-secure peripheral access configuration knobs in the newer SoC variants, which can be investigated. If restricting non-secure access to a single SPI CS pin is not possible on the GPIO port C, then the HOLD pin or the WP pin could be connected to one of the pins on the port L and asserted by the firmware. The whole port L can be then configured as secure only. {{red|Still untested and needs to be confirmed.}}<br />
|-<br />
| Write its own bootloader to some accessible higher priority bootable media (for example an SD card) and then program the SPI flash from it. || Some SoCs have special pins to configure the default boot order (the UBOOT_SEL pins in [[A31]]). The other SoCs could probably use MMC1 instead of MMC0 for the SD card slot to ensure that the firmware always boots for the SPI flash. {{red|Still untested and needs to be confirmed.}}<br />
|}<br />
<br />
Ideally, the user should have full control over the firmware upgrade (it is the user who owns the device and not the other way around). When having physical assess to the device, the firmware is always upgradable from the FEL mode (which is activated by pressing a hardware FEL button). And for the sake of convenience, when doing upgrades on the device itself, the firmware can implement asymmetric cryptography to ensure that upgrade only happens to new versions of the firmware from the same trusted author.<br />
<br />
== Upgrading the SPI flash firmware ==<br />
<br />
Multiple methods could be potentially used:<br />
* For dealing with completely bricked non-bootable boards, the most simple solution would be probably to use the sunxi-fel tool with an added feature to backup and flash the firmware.<br />
* For additional users convenience, it would be nice to support upgrading the firmware from the running system too.<br />
<br />
=== Using the sunxi-fel tool ===<br />
<br />
The sunxi-fel tool can be run on an x86 desktop system to program the SPI flash over a Micro-USB cable and bring a non-bootable Allwinner device back to life <ref name="spi_flash_vailability">Assuming that the device has an SPI flash chip connected to SPI0 and boots from it in the first place, which is usually not the case except for [[Xunlong Orange Pi PC 2]] and probably [[ViPER MovieMate]].</ref>. Just upgrading or initially programming the SPI flash firmware on a perfectly working device is possible too. <br />
<br />
Trying to check if there is a real SPI flash chip connected to SPI0 pins (after connecting some Allwinner device to your desktop PC via a Micro-USB cable and booting the device in [[FEL]] mode):<br />
<br />
./sunxi-fel spiflash-info<br />
<br />
Programming a compiled U-Boot image to the SPI flash:<br />
<br />
./sunxi-fel -p spiflash-write 0 u-boot-sunxi-with-spl.bin<br />
<br />
Checking if flash programming has been successful:<br />
<br />
./sunxi-fel -p spiflash-read 0 `stat -c %s u-boot-sunxi-with-spl.bin` spi-flash-read-data.bin<br />
cmp -b u-boot-sunxi-with-spl.bin spi-flash-read-data.bin<br />
<br />
After this, the U-Boot bootloader should be successfully getting booted from the SPI flash after rebooting the device (assuming that no higher priority boot media is available).<br />
<br />
<references/><br />
<br />
=== Using the [https://www.flashrom.org flashrom] tool from a running Linux system on the device ===<br />
<br />
{{alert|It is not clear whether doing firmware updates via flashrom or some other generic tool is a great idea. Not having the firmware write-protected against unauthorized modifications is one concern. Another concern is the fact that the firmware updater needs to be at least a little bit intelligent and try to prevent the user from doing obviously stupid acts (such as flashing an incompatible firmware intended for a different device model).}}<br />
<br />
In order to be able to access the SPI flash from Linux, it is necessary to have some device tree nodes describing this hardware. There are two possible ways to do this:<br />
* Have the SPI0 bus described as a generic spidev node.<br />
* Have the exact SPI flash chip description in the device tree.<br />
<br />
Both of these approaches are technically correct. But from the ideological point of view, the latter solution is [http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/304243.html required]. One more difficulty is that the SPI flash is multiplexed with NAND and this also needs to be addressed properly. Rather than editing DTS files all the time (especially if the SPI flash is hooked to the expansion header), this information can be added to the device tree on the fly by the U-Boot bootloader.<br />
<br />
As for the sunxi SPI driver in the mainline kernel, it is currently in a rather bad shape and does not support sending/receiving SPI messages larger than the FIFO size. Since the FIFO size is only 64 bytes and programming the SPI flash is normally done as 256 byte pages, such limitation most likely renders the SPI driver unusable for this particular use case (to be confirmed). There is some ongoing work, trying to address the sunxi SPI driver problems in the mainline kernel:<br />
* http://lkml.iu.edu/hypermail/linux/kernel/1404.0/00647.html<br />
* http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/263745.html<br />
* https://www.marc.info/?l=linux-arm-kernel&m=146584014828666&w=3<br />
<br />
None of these tasks is particularly challenging from the purely technical point of view, but kernel bureaucrats may turn this activity into a long lasting open source show...<br />
<br />
=== Using some special firmware upgrade interface ===<br />
<br />
The firmware may try to expose a simple interface for upgrading itself. It also may make use of a digital signature check and other safety measures. We need to find out if there are any standard interfaces of this kind already specified for AArch32/AArch64 hardware. The https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/firmware-update.md page may be a good start.<br />
<br />
Before using the firmware upgrade interface, the kernel should temporarily stop using SPI0 and/or NAND. And also preferably temporarily release the SPI0/NAND pins, so that the firmware can confirm this fact itself. The HOLD or WP pin can be used for enabling/disabling access to the SPI flash hardware. And this pin should be preferably accessible only from the firmware, but not from the kernel (of course this is only relevant if we do care about security).<br />
<br />
Please note that even if the firmware upgrade fails (or is not implemented at all), it is always possible to use the sunxi-fel tool.<br />
<br />
== The list of known SPI flash chips ==<br />
<br />
The Read JEDEC ID (9Fh) command is supposed to be around since 2003. The Read SFDP command is relatively new and is documented in the JEDEC standard JESD216, published on 2011. The updated JESD216B standard from 2013 also describes how to use capacities larger than 128 Mbit in a generic way (such capacities exceed the legacy 24-bit addressing mode and can't be used with the old commands).<br />
<br />
=== Macronix MX25L1606E ===<br />
<br />
[[File:SPI Flash Macronix MX25L1606E.png|thumb|160px|]]<br />
<br />
This is a 16 Mbit chip, which is used by the [[Xunlong Orange Pi PC 2]] board. Supports the JEDEC ID (9Fh) command and returns the 0xC22015 id. Also supports the Read SFDP (0x5A) command and returns:<br />
<pre><br />
00000000: 53 46 44 50 00 01 01 ff 00 00 01 09 30 00 00 ff SFDP........0...<br />
00000010: c2 00 01 04 60 00 00 ff ff ff ff ff ff ff ff ff ....`...........<br />
00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................<br />
00000030: e5 20 81 ff ff ff ff 00 00 ff 00 ff 08 3b 00 ff . ...........;..<br />
00000040: ee ff ff ff ff ff 00 ff ff ff 00 ff 0c 20 10 d8 ............. ..<br />
00000050: 00 ff 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ................<br />
00000060: 00 36 00 27 f6 4f ff ff fe cf ff ff ff ff ff ff .6.'.O..........<br />
00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................<br />
</pre><br />
<br />
Based on the information from the [http://www.macronix.com/Lists/Datasheet/Attachments/5089/MX25L1606E,%203V,%2016Mb,%20v1.8.pdf datasheet], the Typical Page Program Time (256 bytes) is 0.6 ms and the Typical Block Erase Time (64 KiB) is 400 ms. Simple calculations show that the expected flashing speed would be<br />
<br />
1 / (0.6 ms / 256 bytes + 400 ms / 65536 bytes) = <b>~118 kB/s</b>.<br />
<br />
=== Winbond 25Q128FVSG ===<br />
<br />
[[File:SPI Flash Winbond 25Q128FVSG.jpg|thumb|160px|]]<br />
<br />
This is a 128 Mbit chip, which is used by the [[Pine64|SOPINE A64 compute module]]. Supports the JEDEC ID (9Fh) command and returns the 0xEF4018 id. Also supports the Read SFDP (0x5A) command and returns:<br />
<pre><br />
00000000: 53 46 44 50 00 01 00 ff 00 00 01 09 80 00 00 ff SFDP............<br />
00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................<br />
00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................<br />
00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................<br />
00000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................<br />
00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................<br />
00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................<br />
00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................<br />
00000080: e5 20 f1 ff ff ff ff 07 44 eb 08 6b 08 3b 42 bb . ......D..k.;B.<br />
00000090: fe ff ff ff ff ff 00 00 ff ff 21 eb 0c 20 0f 52 ..........!.. .R<br />
000000a0: 10 d8 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ................<br />
000000b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................<br />
</pre><br />
It is conforming to the old JESD216 standard. This old standard can only specify write granularity as either 1 byte or 64 bytes, while we want to use full 256 bytes page size for better performance. So it makes sense to identify this chip using the JEDEC ID (9Fh) command and use the retrieved id for a table lookup.<br />
<br />
Based on the information from the [http://www.winbond.com/resource-files/w25q128fv%20rev.l%2008242015.pdf datasheet], the Typical Page Program Time (256 bytes) is 0.7 ms and the Typical Block Erase Time (64 KiB) is 150 ms. Simple calculations show that the expected flashing speed would be<br />
<br />
1 / (0.7 ms / 256 bytes + 150 ms / 65536 bytes) = <b>~199 kB/s</b>.<br />
<br />
Note that unlike the erasing/programming operation, reading speed is very fast for the NOR flash and is only limited by the SPI interface.<br />
<br />
=== 25Q128FV ===<br />
<br />
[[File:SPI Flash Noname 25Q128FV.jpg|thumb|160px|]]<br />
<br />
This is a noname 128 Mbit chip, which is used in [http://www.ebay.com/itm/W25Q-Windbond-Serial-Flash-Memory-Module-SPI-W25Q128B-BIOS-25Q64BVSIG-EEPROM-/181873964697 W25Q SPI flash module] from ebay. Supports the JEDEC ID (9Fh) command and returns the 0xEF4018 id (the same as the Winbond 25Q128FVSG). Does not support the Read SFDP (0x5A) command, but other than this seems to be pretty much compatible.<br />
<br />
== See also ==<br />
* [https://en.wikipedia.org/wiki/Flash_memory#NOR_memories Wikipedia on NOR flash]<br />
* [http://www.cypress.com/file/202606/download Migrating from Winbond W25Q-FV, Micron N25Q-A, and Macronix M25L-F Devices to Cypress S25FL-L] (useful for checking the SPI commands compatibility overview)<br />
<br />
[[Category:Hardware]]<br />
[[Category:Boot]]</div>Karlphttps://linux-sunxi.org/index.php?title=FEL/USBBoot&diff=22629FEL/USBBoot2019-08-13T14:35:44Z<p>Karlp: Added new spiflash-* commands</p>
<hr />
<div>On [[FEL/USBBoot#SoC support status|supported Allwinner SoCs]] it is possible to boot over USB OTG. This requires only minimal changes compared to the build steps in [[Manual_build_howto | the manual build howto]], and these changes are explained on this wiki page.<br />
<br />
By booting over USB OTG, it is possible to forgo the SD-Card entirely, and it is especially useful for devices where no [[UART]] can be found, or where the UART is multiplexed with the SD-Card. You can then use [[MicroSD_Breakout | a micro-SD breakout adapter]] to access the serial port.<br />
<br />
= Install the tools =<br />
<br />
There is a utility in [[Sunxi-tools | the sunxi-tools repository]] called 'sunxi-fel'. This utility is used for booting the system over USB and it needs to be installed first.<br />
<br />
The command line syntax of the <code>sunxi-fel</code> utility:<br />
<pre><br />
Usage: sunxi-fel [options] command arguments... [command...]<br />
-v, --verbose Verbose logging<br />
-p, --progress "write" transfers show a progress bar<br />
-l, --list Enumerate all (USB) FEL devices and exit<br />
-d, --dev bus:devnum Use specific USB bus and device number<br />
--sid SID Select device by SID key (exact match)<br />
<br />
spl file Load and execute U-Boot SPL<br />
If file additionally contains a main U-Boot binary<br />
(u-boot-sunxi-with-spl.bin), this command also transfers that<br />
to memory (default address from image), but won't execute it.<br />
<br />
uboot file-with-spl like "spl", but actually starts U-Boot<br />
U-Boot execution will take place when the fel utility exits.<br />
This allows combining "uboot" with further "write" commands<br />
(to transfer other files needed for the boot).<br />
<br />
hex[dump] address length Dumps memory region in hex<br />
dump address length Binary memory dump<br />
exe[cute] address Call function address<br />
reset64 address RMR request for AArch64 warm boot<br />
memmove dest source size Copy <size> bytes within device memory<br />
readl address Read 32-bit value from device memory<br />
writel address value Write 32-bit value to device memory<br />
read address length file Write memory contents into file<br />
write address file Store file contents into memory<br />
write-with-progress addr file "write" with progress bar<br />
write-with-gauge addr file Output progress for "dialog --gauge"<br />
write-with-xgauge addr file Extended gauge output (updates prompt)<br />
multi[write] # addr file ... "write-with-progress" multiple files,<br />
sharing a common progress status<br />
multi[write]-with-gauge ... like their "write-with-*" counterpart,<br />
multi[write]-with-xgauge ... but following the 'multi' syntax:<br />
<#> addr file [addr file [...]]<br />
echo-gauge "some text" Update prompt/caption for gauge output<br />
ver[sion] Show BROM version<br />
sid Retrieve and output 128-bit SID key<br />
clear address length Clear memory<br />
fill address length value Fill memory<br />
<br />
spiflash-info Retrieves basic information<br />
spiflash-read addr length file Write SPI flash contents into file<br />
spiflash-write addr file Store file contents into SPI flash<br />
</pre><br />
<br />
{{warn|some Linux distributions are already providing packaging for sunxi-tools. However they are also removing certain tools and renaming executables at their discretion. If you encounter troubles with the sunxi-tools package from your distro, then getting sunxi-tools directly from the [https://github.com/linux-sunxi/sunxi-tools github repository] is always an option.}}<br />
<br />
= Switch your device into FEL mode =<br />
<br />
Before the 'sunxi-fel' tool can actually talk to your device, the device needs to be connected to your PC using a "USB A to USB mini/micro B" cable.<br />
<br />
And then the device needs to be switched into FEL mode. Please refer to the [[FEL | FEL howto]] for information on how to boot to FEL mode. Device pages should mention the button which triggers FEL mode as well.<br />
<br />
If you run:<br />
<pre> sunxi-fel version </pre><br />
<br />
and it returns something like:<br />
<pre> AWUSBFEX soc=00162500(A13) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000 </pre><br />
<br />
Then you have successfully switched the device into FEL mode and it is ready to accept commands or load the system over USB.<br />
<br />
= Boot the system over USB =<br />
<br />
== Mainline U-Boot (v2015.04 and newer versions) ==<br />
<br />
=== Getting the mainline U-Boot sources ===<br />
To obtain the U-Boot sources, clone the current U-Boot master branch:<br />
<br />
<pre><br />
git clone git://git.denx.de/u-boot.git<br />
cd u-boot<br />
</pre><br />
<br />
Or alternatively the 'next' branch from the sunxi custodian tree:<br />
<br />
<pre><br />
git clone -b next git://git.denx.de/u-boot-sunxi.git<br />
cd u-boot-sunxi<br />
</pre><br />
<br />
Both of these branches are bleeding edge and may contain bugs from time to time. If you encounter troubles, try a tarball with the latest formal U-Boot release before giving up.<br />
<br />
=== Booting U-Boot over USB ===<br />
<br />
Then just do a regular u-boot build:<br />
<pre><br />
make CROSS_COMPILE=arm-linux-gnueabihf- Cubietruck_defconfig<br />
make CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc)<br />
</pre><br />
<br />
And boot it over USB (the 'sunxi-fel uboot' command requires an up to date version of sunxi-tools):<br />
<pre><br />
sunxi-fel uboot u-boot-sunxi-with-spl.bin<br />
</pre><br />
<br />
This boots U-Boot over USB. And after U-Boot takes control, it starts scanning various default locations for the boot.scr file in order to boot the rest of the system.<br />
<br />
=== Booting the whole system over USB (U-Boot + kernel + initramfs) ===<br />
<br />
This needs to be used with <b>U-Boot v2015.10</b> or newer (which can automatically find the 'boot.scr' blob in RAM after it had been uploaded there by 'sunxi-fel').<br />
<br />
Assuming that you have a kernel image, a correct dtb blob for your hardware, a [[Mainline U-Boot#Install_U-Boot|boot script blob]] and an initrd image, booting all of this can be done with just a single 'sunxi-fel' invocation:<br />
<pre><br />
sunxi-fel -v uboot u-boot-sunxi-with-spl.bin \<br />
write 0x42000000 uImage \<br />
write 0x43000000 sun7i-a20-cubietruck.dtb \<br />
write 0x43100000 boot.scr \<br />
write 0x43300000 rootfs.cpio.lzma.uboot<br />
</pre><br />
<br />
If you wonder about all the magic addresses used in the command line above, the right values can be found in the [http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/sunxi-common.h U-Boot sources] in <tt>MEM_LAYOUT_ENV_SETTINGS</tt> definition:<br />
<pre><br />
bootm_size = 0xf000000<br />
kernel_addr_r = 0x42000000<br />
fdt_addr_r = 0x43000000<br />
scriptaddr = 0x43100000<br />
pxefile_addr_r = 0x43200000<br />
ramdisk_addr_r = 0x43300000<br />
</pre><br />
<br />
Somewhere between U-Boot v2017.03 and v2017.07, U-Boot switched to a new SPL format, which is not compatible with sunxi-tools release <=1.4.2 provided by some distros. The tool will print error message such as<br />
<pre><br />
sunxi SPL version mismatch: found 0x02 > maximum supported 0x01.<br />
You need a more recent version of this (sunxi-tools) fel utility.<br />
</pre><br />
You will need a later sunxi-tools from git to avoid this problem.<br />
<br />
=== Overriding environment variables with uEnv-style data ===<br />
<br />
With v1.4 and above, the <tt>sunxi-fel</tt> utility has gained the ability to pass environment data to U-Boot via FEL.<br />
<br />
''key=<value>'' pairs from a textual representation will get '''merged with the default environment''';<br />
similar to U-Boot's <code>import -t</code> command, or what older U-Boot did with the ''uEnv.txt'' file on autoboot.<br />
<br />
:{{note|{{red|This requires an up-to-date U-Boot (v2016.09 or later), plus you need to start your data with a special 'magic' signature:}}}}<br />
:<pre>#=uEnv</pre><br />
<br />
The signature will allow the sunxi-fel "write" command to detect uEnv-style data - and will cause it to flag this transfer accordingly, in turn requesting U-Boot v2016.09+ to import it afterwards. You may override arbitrary environment variables this way, including the <code>bootcmd</code>.<br />
<br />
==== Example ====<br />
<br />
Use your text editor to save a ''my.env'' file with<br />
<pre><br />
#=uEnv<br />
myvar=world<br />
bootcmd=echo "Hello $myvar."<br />
</pre><br />
<br />
and then test it with<br />
<pre>./sunxi-fel uboot u-boot-sunxi-with-spl.bin write 0x43100000 my.env</pre><br />
<br />
You should see U-Boot's autoboot print the corresponding message and drop you to the prompt, proving that you have successfully overwritten the default "bootcmd".<br />
<br />
=== Early kernel development for new SoCs ===<br />
<br />
Because FEL boot is supported by the BROM code, it is readily available out of the box. The 'sunxi-fel' tool only needs to be patched to add the SRAM layout information, but this is [https://github.com/linux-sunxi/sunxi-tools/commit/65bcc0501382db606ab5a5b5eb39f6f1c06b2df8 usually very simple] and also extensively documented on this wiki page. A relatively challenging task is the U-Boot support, because it needs the DRAM initialization code for the SPL. But assuming that the U-Boot bootloader is already available, FEL boot can be used for kernel development even when there is no Ethernet or MMC support in the kernel yet. For the sake of convenience, it is best to write [https://github.com/linux-sunxi/sunxi-tools/blob/master/bin/fel-sdboot.sunxi fel-sdboot.sunxi] to the SD card (substitute /dev/sdX with the appropriate block device of your card reader):<br />
<pre><br />
wget https://github.com/linux-sunxi/sunxi-tools/raw/master/bin/fel-sdboot.sunxi<br />
dd if=fel-sdboot.sunxi of=/dev/sdX bs=1024 seek=8<br />
</pre><br />
<br />
Then just use the instructions from the previous section [[FEL/USBBoot#Booting_the_whole_system_over_USB_.28U-Boot_.2B_kernel_.2B_initramfs.29|about U-Boot + kernel + initramfs]]. And after the MMC support is implemented in the kernel, it becomes possible to move the rootfs to the SD card and get rid of the initrd image. But FEL USB boot is still useful until either Ethernet or USB becomes good enough for booting over network.<br />
<br />
== Legacy mainline U-Boot (v2015.04 and older versions) ==<br />
<br />
<div class="mw-collapsible mw-collapsed"><br />
<span style="color:red">'''Is here for historical reference only (click on the 'Expand' link to see it):'''</span><br />
<div class="mw-collapsible-content"><br />
<br />
The U-Boot had to be configured using "*_'''felconfig'''" option before compiling (instead of "*_defconfig", as that builds a SPL only suitable for MMC boot). For example, in the case of a Cubietruck board, that would be:<br />
<pre><br />
make CROSS_COMPILE=arm-linux-gnueabihf- Cubietruck_felconfig<br />
make CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc)<br />
</pre><br />
<br />
Then just use the 'sunxi-fel' tool to upload various pieces to certain magic addresses (the magic CONFIG_SPL_TEXT_BASE=0x2000 and CONFIG_SYS_TEXT_BASE=0x4a000000 values can be found in the [http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/sunxi-common.h;h=6cfd7e148900 U-Boot sources]). And execute them in a certain order:<br />
<br />
<pre><br />
echo == upload the SPL to SRAM and execute it ==<br />
sunxi-fel write 0x2000 spl/u-boot-spl.bin<br />
sunxi-fel exe 0x2000<br />
<br />
sleep 1 # wait for DRAM initialization to complete<br />
<br />
echo == upload the main u-boot binary to DRAM ==<br />
sunxi-fel write 0x4a000000 u-boot.bin<br />
<br />
echo == execute the main u-boot binary ==<br />
sunxi-fel exe 0x4a000000<br />
</pre><br />
<br />
This boots U-Boot over USB. And after U-Boot takes control, it starts scanning various default locations for the boot.scr file in order to boot the rest of the system.<br />
</div><br />
</div><br />
<br />
== Legacy u-boot-sunxi ==<br />
<div class="mw-collapsible mw-collapsed"><br />
<span style="color:red">'''Is here for historical reference only (click on the 'Expand' link to see it):'''</span><br />
<div class="mw-collapsible-content"><br />
<br />
=== Preparing U-Boot ===<br />
<br />
U-boot needs to be built specifically for booting over USB. This is called FEL mode, and enabling this disables the full SD card (for u-boot, script.bin and the kernel might re-enable it later on).<br />
<br />
Just follow the [[U-Boot#Compile_U-Boot | guide to compile u-boot]], but [[U-Boot#Determine_build_target | select a target]] whose name has '''_FEL'''.<br />
<br />
=== Manual loading ===<br />
<br />
While the script from the next section is perhaps better, you can now choose to load u-boot manually:<br />
<br />
<pre><br />
sunxi-fel write 0x2000 ../u-boot/spl/u-boot-spl.bin<br />
sunxi-fel exe 0x2000<br />
sleep 1 # Wait for DRAM initialization to complete<br />
sunxi-fel write 0x4a000000 ../u-boot/u-boot.bin<br />
sunxi-fel exe 0x4a000000<br />
</pre><br />
<br />
=== usb-boot script ===<br />
<br />
There was a script in the older releases of [[Sunxi-tools]] called [[Sunxi-tools#usb-boot | usb-boot]]. You can download this script from github using the tag for an old version 1.2:<br />
<br />
<pre><br />
wget https://raw.githubusercontent.com/linux-sunxi/sunxi-tools/v1.2/usb-boot<br />
chmod +x usb-boot<br />
</pre><br />
<br />
And then use it as follows:<br />
<br />
<pre>Usage: ./usb-boot u-boot-spl.bin u-boot.bin [boot.scr] [kernel script.bin [initramfs]]</pre><br />
<br />
u-boot-spl.bin and u-boot.bin are the [[U-Boot|u-boot binaries]] which are [[FEL/USBBoot#Preparing_U-Boot | FEL enabled]].<br />
<br />
[[Manual_build_howto#boot.cmd | boot.scr]] is the u-boot script. If you do not specify a file ending with .scr the default is used.<br />
<br />
uImage is your [[Linux_Kernel#Compilation | compiled kernel image]].<br />
<br />
[[Manual_build_howto#Building_script.bin | script.bin]] is your hw configuration converted to binary from .fex.<br />
<br />
initramfs is an optional initramfs/initrd image in u-boot mkimage format.<br />
</div><br />
</div><br />
<br />
== Using sunxi-fel on Windows ==<br />
<br />
* https://github.com/linux-sunxi/sunxi-tools/tree/windows#using-sunxi-tools-under-windows<br />
* Prebuilt Win64 binaries: https://github.com/eperie/build-scripts/releases/download/v1.1/sunxi-fel.exe - ''Experimental, use at your own risk!''<br />
<br />
=== Mandatory USB driver ===<br />
<br />
Under Windows (unlike Linux) every USB device that an application program wishes to access '''must have a suitable USB driver installed'''.<br />
<br />
This means that ''any device that shows up as "unknown" in your Device Manager will be {{red|inaccessible}}'' - typical symptoms would be an <tt>ERROR: Allwinner USB FEL device not found!</tt> message, or even<br />
<pre>libusb_open() ERROR -12: Operation not supported or unimplemented on this platform</pre><br />
when trying to enforce the specific device with the <code>--dev</code> option.<br />
<br />
=== Zadig to the rescue ===<br />
<br />
Fortunately, there's a very convenient utility to help with the USB driver setup. Grab your copy from http://zadig.akeo.ie/.<br />
<br />
Before launching it, make sure your Allwinner device is connected and in [[FEL]] mode.<br />
<br />
[[File:Zadig-fel-winusb-instructions.png]]<br />
<br />
<br>Initially, the Zadig utility should only present you a single "Unknown Device #1". If it happens to actually list multiple devices, make sure you pick the correct one by verifying the '''USB ID''', shown as "'''1F3A:EFE8'''" in above picture.<br />
<br />
# ''(Optional, but recommended)'' Tick the "Edit" checkbox on the right hand side, and enter a more descriptive name for the USB ID in question. This helps a lot later, to distinguish your Allwinner device from other USB entries in the Device Manager.<br />
# Select the desired USB driver. This depends on the Windows executables you intend to use; namely the specific version of ''libusb'' that those binaries were compiled with. If your <tt>sunxi-fel.exe</tt> has special driver requirements, those should be stated in the accompanying documentation. When in doubt, select [http://windows.libusb.info/ '''WinUSB'''] for a "generic" driver (available from Win XP SP3 onwards).<br />
# Click "Install Driver". Voilà - from now on your device should no longer be "unknown" in Device Manager, and <tt>sunxi-fel</tt> is expected to work with it.<br />
<br />
:[[File:Sunxi-fel_win32.png|500px]]<br />
<br />
<br>'''Troubleshooting:'''<br />
* If you have <tt>listdevs.exe</tt> available in your package, you may use it to check that Windows detects your device at all, and to determine the ''libusb'' bus/device numbers.<br />
* In case you selected the wrong driver, you may simply re-run Zadig to install another. Use "''Options''", "''List All Devices''" and pick the desired one (keeping an eye on the USB ID once more). Alternatively you can use the Windows Device Manager to remove/uninstall the driver (effectively rendering the device "unknown" again), and then start from scratch.<br />
----<br />
<br />
= Adding support for new SoC variants =<br />
<br />
If everything is already working fine for you, then you can stop reading here :-) But sometimes you may get messages like '''"SPL: Unsupported SoC type"''' or '''"Warning: no 'soc_sram_info' data for your SoC"''' when trying to use the instructions from the previous sections. In this case, doing some work to add support for your SoC may be required. It is also a good idea to first check the [[FEL/USBBoot#SoC support status|SoC support status]] table below.<br />
<br />
== SoC support status ==<br />
<br />
{| class="wikitable"<br />
! SoC name<br />
! SoC support status in sunxi-tools <ref name="uboot"><br />
Basic FEL commands like "read", "write" and "exe" are already supported in a generic way on every SoC. This table column only shows support status for advanced commands like "spl" and "uboot".<br />
</ref><br />
! SoC support status in U-Boot<br />
! "sunxi-fel write" speed <ref name="speed"><br />
The transfer speed can be measured by running the following commands:<br />
<pre><br />
# Execute only the SPL part of the U-Boot image in order to initialize DRAM<br />
sunxi-fel spl u-boot-sunxi-with-spl.bin<br />
<br />
# Upload a file to DRAM ('-p' enables a progress display, which includes transfer speed)<br />
sunxi-fel -p write 0x42000000 uImage<br />
</pre><br />
You can use any file instead of "uImage". Larger file size means better speed measurement accuracy, so pick something that has size of at least several megabytes. Please note that the devices, which have MMU disabled, are currently expected to show slow transfer speeds (this can be probably improved later).<br />
</ref><br />
! USB DFU speed<br />
! MMU setup<br />
! Stack pointers <ref name="stack"><br />
There are two stacks in FEL mode:<br />
* 'sp_irq' is the value of the IRQ stack pointer register. The IRQ stack is typically empty, which means that the 'sp_irq' is pointing to both top and bottom of this stack (unless the processor is currently handling an IRQ).<br />
* 'sp' is the value of the normal stack pointer register, also available to your code when it is executed via "sunxi-fel exe" command. This stack typically contains quite a bit of data between 'sp' and 0x7000 (which was written there by the FEL code from BROM).<br />
When uploading data via "sunxi-fel write" command, be sure not to overwrite these stacks (don't touch the data in SRAM below 'sp_irq' and above 'sp').<br />
</ref><br />
! Notes<br />
|-<br />
| Allwinner [[A10]] || Supported || Supported || ~600 KB/s || ~3.2 MB/s || Enabled by BROM, ttbr0=0x20000 || sp_irq=0x02000, sp=0x05DF8 || <br />
|-<br />
| Allwinner [[A13]] || Supported || Supported || ~570 KB/s (win7 laptop), ~940kB/s (linux opipc) || || Enabled by BROM, ttbr0=0x08000 || sp_irq=0x02000, sp=0x05DF8 || <br />
|-<br />
| Allwinner [[A20]] || Supported || Supported || ~960 KB/s || ~3.7 MB/s|| Enabled by BROM, ttbr0=0x20000 || sp_irq=0x02000, sp=0x05E08 || <br />
|-<br />
| Allwinner [[A23]] || Supported || Supported || || || Enabled by BROM, ttbr0=0x08000 || ||<br />
|-<br />
| Allwinner [[A31s]] || Supported || Supported || ~510 KB/s || || Enabled by BROM, ttbr0=0x20000 || sp_irq=0x02000, sp=0x05E08 || <br />
|-<br />
| Allwinner [[A33]] || Supported || Supported || ~191 KB/s || || Not enabled by BROM || ||<br />
|-<br />
| Allwinner [[A64]] || Supported || Supported <ref name="spl32">Requires a 32-bit SPL build. There is a not-mainline(able) [https://github.com/apritzel/u-boot/commits/sunxi64-fel32 sunxi64-fel32] branch for that, also pre-built [https://github.com/apritzel/pine64/tree/master/binaries binaries] for easy use with sunxi-fel.</ref> || ~510 KB/s || || Not needed <ref name="goodspeed">The BROM in A64 is not [https://github.com/ssvb/sunxi-tools/commit/b4116008efe28016ca85de83a7e1d453a1d7e745 troublesome] anymore and "sunxi-fel hexdump 0x1c14200 16" works fine for retrieving SID. This indicates somewhat better implementation and the MMU speed boosting workaround is not needed.</ref> || sp_irq=0x12000, sp=0x15E08 || SPL needs to be loaded at 0x10000 (instead of 0x0)<br />
|-<br />
| Allwinner [[A80]] || Supported || Supported || ~930 KB/s (boot0) || || Not enabled by BROM || sp_irq=0x12000, sp=0x15AD0 || SPL needs to be loaded at 0x10000 (instead of 0x0)<br />
|-<br />
| Allwinner [[A83T]] || Supported || Supported || ~510 KB/s (~191 KB/s if MMU not enabled) || || Enabled by sunxi-fel, ttbr0=0x44000 || sp_irq=0x00002000, sp=0x00005E08 ||<br />
|-<br />
| Allwinner [[H3]] || Supported || Supported || ~960 KB/s || || Enabled by sunxi-fel, ttbr0=0x44000 || sp_irq=0x00002000, sp=0x00005E08 ||<br />
|-<br />
| Allwinner [[H5]] || Supported || Supported <ref name="spl32" /> || ? || || ? || sp_irq=0x12000, sp=0x15E08 || SPL needs to be loaded at 0x10000<br />
|-<br />
| Allwinner [[H6]] || Supported || Supported <ref name="spl32" /> || ~177 KB/s || || Not enabled by BROM || sp_irq=0x22000, sp=0x25E08 || SPL needs to be loaded at 0x20000<br />
|-<br />
| Allwinner [[R8]] || Supported || Supported || ~500 KB/s || || Enabled by BROM, ttbr0=0x08000 || sp_irq=0x02000, sp=0x05DF8 || basically like A13,<br>handled by same ''soc_id''<br />
|-<br />
| Allwinner [[R40]] || Supported || Supported || ? || || Not enabled by BROM || sp_irq=0x02000, sp=0x05E08 ||<br />
|}<br />
<br />
<references/><br />
<br />
== General description of the "sunxi-fel uboot" command implementation ==<br />
Allwinner is treating booting over USB in a special way, and this behaviour is unfortunately hardcoded in the [[BROM]]. The main differences between booting from MMC/NAND and booting from USB are:<br />
* For booting from the SD card or NAND, the BROM code is searching for a special eGON signature on a bootable media and loading up to 32K (in fact a bit less than that) of the initial code to the address 0x0 in SRAM (that's typically the SRAM section A1) and then executes it. This initial code (known as "SPL" in U-Boot or "boot0" in the Allwinner's bootloader) configures the DRAM to get access to more storage space, then loads the main part of the bootloader and the rest of the system there.<br />
* For booting via FEL, the Allwinner's idea is that we are supposed to upload only something like up to ~15K of code at the address 0x2000 in SRAM and execute it.<br />
This is at least inconsistent and definitely not good for us. U-Boot used to require a special size-optimized variant of the SPL specifically for booting via FEL, which also had the base address changed from 0x0 to 0x2000 as an additional inconvenience. Having a special variant of the SPL means an extra configuration to maintain. And the code size limitation is also a nasty problem because a certain set of features has to be disabled. But the "spl" and "uboot" commands, which are implemented by the "sunxi-fel" tool, can work-around this limitation by smuggling just the ordinary MMC or NAND variant of the U-Boot SPL into SRAM. More technical details are provided below.<br />
<br />
The reason why we have ~15K code size limitation when booting via FEL is illustrated on the picture below. When we are booting the device in FEL mode, a special code is activated in the BROM and starts communicating over USB using FEL protocol. The USB driver code from the BROM allocates two stacks at rather inconvenient locations inside of the first 32K of SRAM. The IRQ handler stack is set at the address 0x2000 and grows down. And the ordinary application stack is set at the address 0x7000 and also grows down. These stacks make the SRAM space fragmented, and the largest usable contiguous ~15K area is sandwiched between these two stacks. Overwriting either of these stacks via the "sunxi-fel write" crashes the device and it just stops responding to further FEL commands. So uploading a normal U-Boot SPL (which typically has size slightly larger than 20K) to the address 0x0 via "sunxi-fel write" command with the intention to execute it via "sunxi-fel exe" command does not work as expected.<br />
<br />
[[File:FEL uboot memory map.jpg]]<br />
<br />
So, how do we solve this problem? Allwinner devices typically have more than 32K of SRAM (the smallest total amount of SRAM among all devices is 48K in Allwinner A13). And we can use extra SRAM locations as a backup storage for the FEL stacks (shown as "backup area 1" and "backup area 2" on the picture above). We also upload a special [https://github.com/linux-sunxi/sunxi-tools/blob/1627b13718bae612a2cb14bb03de5bfd578280be/fel-to-spl-thunk.S thunk code], which is responsible for swapping the content of the FEL stacks with the content of these backup areas before jumping to the address 0x0. Now in order to execute a full-fledged SPL from U-Boot, we only need to split the SPL into chunks and upload it to SRAM, writing the parts which are supposed to overlap the FEL stacks to the backup areas. Executing the thunk code saves the FEL stacks to the backup areas, reassembles the SPL together and passes control to the SPL.<br />
<br />
Why do we need to backup the original FEL stacks? The reason is that just uploading and executing the SPL alone is not enough to boot the system. The SPL code is very small and its primary task is to setup clocks and initialize the DRAM. After the DRAM is initialized, all the storage space problems are resolved and we want to load the main U-Boot code to the device. And for this we still need the BROM FEL code alive and getting control back, so that it can still talk with the 'sunxi-fel' tool over USB and execute FEL commands. Hence the SPL returns control back to the thunk code. The thunk code swaps FEL stacks with backup areas again and finally passes control back to the FEL code in the BROM, which is able to happily resume its work because it has all the original data back in its stacks.<br />
<br />
== The SoC-specific mandatory thing ==<br />
<br />
The previous section describes how the "sunxi-fel spl" and "sunxi-fel uboot" commands work. But not everything is perfect. One inconvenient thing is that the SRAM address space layout (and the location of the backup areas) may be different for different SoC variants. Hence we need to provide the [https://github.com/linux-sunxi/sunxi-tools/blob/01f9972842085f6dea59c64fca39f0107678af4a/fel.c#L325 SRAM layout description information] for each SoC in the source code of the 'sunxi-fel' program. The comments in the source code should provide reasonable explanations. And here is an example of such SRAM layout information for A31:<br />
<pre><br />
/*<br />
* A31 is very similar to A10/A13/A20, except that it has no SRAM at 0x8000.<br />
* So we use the SRAM section at 0x44000 instead. This is the memory, which<br />
* is normally shared with the OpenRISC core (should we do an extra check to<br />
* ensure that this core is powered off and can't interfere?).<br />
*/<br />
sram_swap_buffers a31_sram_swap_buffers[] = {<br />
{ .buf1 = 0x01800, .buf2 = 0x44000, .size = 0x800 },<br />
{ .buf1 = 0x05C00, .buf2 = 0x44800, .size = 0x8000 - 0x5C00 },<br />
{ 0 } /* End of the table */<br />
};<br />
<br />
soc_sram_info soc_sram_info_table[] = {<br />
{<br />
.soc_id = 0x1633, /* Allwinner A31 */<br />
.thunk_addr = 0x46E00, .thunk_size = 0x200,<br />
.swap_buffers = a31_sram_swap_buffers,<br />
},<br />
{ 0 } /* End of the table */<br />
};<br />
</pre><br />
Basically, the first backup area for A31 is set at 0x44000 and covers the IRQ stack (0x1800-0x2000). The second backup area is set at 0x44800 and covers the normal FEL stack plus also some extra area above it (0x5C00-0x8000). The thunk code is placed at 0x46E00.<br />
<br />
== The SoC-specific bonus features ==<br />
<br />
* While this is not strictly required, we can [https://github.com/linux-sunxi/sunxi-tools/commit/e4b3da2b17ee9d7c5cab9b80e708b3a309fc4c96 tweak the cacheability attributes of the memory sections by modifying the MMU translation table]. This improves the performance of the "sunxi-fel write" command and helps to significantly reduce the time needed to upload large chunks of data to DRAM.<br />
<br />
* The Cortex-A8 based SoC variants need [https://github.com/linux-sunxi/sunxi-tools/commit/f6a1382b4a2337f34ff5c52b83c3666c2f57247d a tweak for the AUXCR L2EN bit]. Without this, the L2 cache ends up disabled in Linux after booting over FEL.<br />
<br />
== Testing ==<br />
<br />
After adding the support for a new SoC variant to the 'sunxi-fel' tool, it makes sense to actually test whether it works. In the case if U-Boot already has support for this particular SoC variant, the testing is simple and can be done by just running '''"sunxi-fel uboot u-boot-sunxi-with-spl.bin"''' command and confirming that U-Boot starts properly on the device.<br />
<br />
In the case if U-Boot still does not have full support for this particular SoC variant yet, testing still can be done using the Allwinner's boot0 bootloader. If you have some boot0-based bootable SD card image (let's call it 'sdcard-image.bin'), then you can:<br />
* write this image to an SD card<br />
* extract the boot0 part from this image via running '''"dd if=sdcard-image.bin of=boot0.bin bs=1024 skip=8 count=32"'''<br />
* switch the device into FEL mode<br />
* insert the SD card<br />
* run '''"sunxi-fel spl boot0.bin"'''<br />
If the system boots normally, in the same way as just doing a normal boot from the SD card, then the 'sunxi-fel' tool is working fine. Please note that you may get error messages from the 'sunxi-fel' tool while doing this. This is normal and expected (boot0 does not return control back to the FEL code in BROM but instead does its usual booting of the system from the SD card).<br />
<references/><br />
<br />
= Potential future improvements =<br />
<br />
There is quite a lot of room for improvement:<br />
* Allow the 'sunxi-fel spl' command to also use raw SD card images in addition to just recognizing 'u-boot-sunxi-with-spl.bin' format.<br />
* Store the magic addresses (CONFIG_SYS_TEXT_BASE, kernel_addr_r, fdt_addr_r, scriptaddr, ramdisk_addr_r) in the [[EGON]] header extension in order to avoid the need of passing them to the 'sunxi-fel' tool as command line parameters.<br />
* Single U-Boot binary for both the regular UART serial console and the UART over the [[MicroSD Breakout]] configurations. The configuration option can be provided to the 'sunxi-fel' tool in a command line argument and handed over to to U-Boot in the eGON header extension.<br />
<br />
The exact eGON header extension format needs to be formalized. We should also check whether it can provide backwards/forward compatibility with the Allwinner's BOOT0 bootloader.<br />
<br />
= Known issues =<br />
<br />
Please report problems to https://github.com/linux-sunxi/sunxi-tools/issues<br />
<br />
= See also =<br />
<br />
* [[FEL]]<br />
* [[miniroot]]<br />
<br />
[[Category:Tutorial]]<br />
[[Category:Boot]]</div>Karlphttps://linux-sunxi.org/index.php?title=FriendlyARM_NanoPi_NEO_%26_AIR&diff=21779FriendlyARM NanoPi NEO & AIR2018-11-26T11:45:19Z<p>Karlp: update neo air support state, drop bad links</p>
<hr />
<div>{{Infobox Board<br />
| image = [[File:Duetto_di_NanoPi.jpg|250px]]<br />
| manufacturer = [http://www.friendlyarm.net/ FriendlyARM]<br />
| dimensions = 40''mm'' x 40''mm''<br />
| release_date = July (NEO) / Oct (Air) 2016<br />
| website = [http://nanopi.io/nanopi-neo.html NanoPi NEO] / [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air NanoPi Air]<br />
| soc = [[H3]] @ 1.2Ghz<br />
| dram = 256MiB (K4B2G1646Q-BCK0) or 512MiB (K4B4G1646Q-BCK0) DDR3<br />
| power = DC 5V @ 2A via microUSB or pin headers<br />
| audio = microphone, stereo line-out, I²S and [[SPDIF|S/PDIF]] on pin headers<br />
| network = 10/100Mbps Ethernet ([[Sun8i emac|H3 built-in PHY]]) or BT4.0/WiFi 802.11 b/g/n ([[Wifi#Ampak|Ampak AP6212]])<br />
| storage = µSD and 8GB eMMC (Air)<br />
| usb = 1 USB2.0 Host (NEO), 1 USB2.0 OTG<br />
| other = 24 pin camera connector (Air)<br />
| headers = UART, SPI, I²C, 2x USB2.0 Host, analog audio, microphone<br />
}}<br />
<br />
{{Remove_only_when_finished|This page needs to be properly filled according to the [[New_Device_howto |New Device Howto]] and the [[New_Device_page|New Device Page guide]].}}<br />
<br />
= Identification =<br />
Small, square board, blue soldermask, ⌀3mm mounting holes in the corners. USB type-A, Ethernet jack (with integrated magnetics) and four-pin header for UART/power near one of the edges, microSD and USB micro-B at opposite edge mounted on top side, 12 and 24 GPIO pin headers (not fitted, pads only) near other edges. Allwinner H3 and single DDR3 chip mounted on the bottom. Sticker indicating amount of RAM is placed on the Ethernet jack. Device can also be ordered without USB and Ethernet soldered (see gallery below)<br />
<br />
On the top side of the board, next to USB A connector, the following is silkscreened:<br />
<pre>FRIENDLYARM<br />
NanoPi NEO</pre><br />
<br />
Starting in September 2016 a new PCB revision 1.1 is available (changes: [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO#Layout audio signals on the GPIO header, voltage regulator])<br />
<br />
{{H3_Support_status|board=NanoPi NEO and NEO Air|uboot_defconfig='''nanopi_neo''' (supported since v2016.11) or '''nanopi_neo_air''' (supported since v2017.05)|kernel_dtb='''sun8i-h3-nanopi-neo.dtb''' or '''sun8i-h3-nanopi-neo-air.dtb''' (depending on the board)|hdmi_support=|legacy_instructions=The .fex file is available from [https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/h3/xunlong_orange_pi_pc.fex xunlong_orange_pi_pc.fex].|status_extra=NanoPi NEO shares nearly all hardware details with [[Orange Pi One]]. Detailed device information can be found on [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO] and [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air]<br />
<br />
== Images ==<br />
<br />
FriendlyARM's UbuntuCore with Qt-Embedded image can be found [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO#Make_an_Installation_TF_Card here]. It boots a new variant of Allwinner's 3.4.39 BSP kernel, USB and Ethernet are working fine. Armbian images for NEO based on 3.4.112 (containing new IoT low power settings) or 4.6.7 can be found [http://www.armbian.com/nanopi-neo/ here].<br />
<br />
== BSP ==<br />
<br />
FriendlyARM provides a [https://github.com/friendlyarm/h3_lichee BSP based on a newer Allwinner 3.4.39 variant] on Github.<br />
}}<br />
<br />
= Expansion Port =<br />
<br />
Both NanoPi NEO and NEO Air feature one 12-pin and one 24-pin GPIO header. Air's pin-out for those headers and the DVP camera connector can be found [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air#Diagram.2C_Layout_and_Dimension here]. On NEO PCB rev. 1.0 analog audio signals were present on the 12-pin header that were replaced by digital audio starting with PCB rev. 1.1. With PCB rev. 1.3 position of the UART debug header has changed and a new 5-pin analog audio header has been added (same as on NEO 2 and NEO Plus 2). All pin-out information in [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO#Diagram.2C_Layout_and_Dimension FriendlyELEC's wiki page].<br />
<br />
= Tips, Tricks, Caveats =<br />
<br />
== FEL mode ==<br />
<br />
No [[FEL]] button. UBOOT/FEL signal pulled-up by R254 (10kΩ, mounted on the bottom side, close to H3).<br />
<br />
== LEDs ==<br />
<br />
The board has two LEDs, mounted on the top side, between micro USB and microSD:<br />
* A red LED, labelled "PWR", connected to the PL10 pin and to 3.3V via weak pull-up, thus being able to represent three states:<br />
** full brightness when GPIO is set to output high<br />
** reduced brightness when GPIO is set to high impedance state<br />
** turned off when GPIO is set to output low.<br />
* A blue LED, labelled "STAT", connected to the PA10 pin.<br />
<br />
== Voltage regulators / heat ==<br />
<br />
NanoPi NEO/Air use the same voltage regulator as NanoPi M1 and Orange Pi One/Lite switching between 1.1V and 1.3V (SY8113B [https://www.olimex.com/Products/Breadboarding/BB-PWR-8113/resources/SY8113.pdf datasheet]). Unlike the Xunlong boards which contain a thick copper layer inside the PCB to spread heat away from the SoC FriendlyARM chose a different design. This and maybe the smaller PCB size lead to higher temperatures compared to Orange Pis and in case you want to operate the NEO under constant high load think about adding a heatsink (FriendlyARM provides one combined with a 2mm heat pad that can be securely mounted on the board -- see gallery images below.<br />
<br />
On NanoPi NEO PCB rev 1.0 U7 next to DRAM is an LDO voltage regulator that provides 1.2V for various SoC parts and 1.1V for the internal Ethernet PHY. It overheats a lot and is rated 500mA max. When ordering FriendlyARM's heatsink maybe combining it with a larger heatpad that covers the whole SBC's surface is a better option than now (using a small 15x15 heat pad that connects SoC with heat sink but decreases heat dissipation for all other SBC components this way).<br />
<br />
== DRAM ==<br />
<br />
NanoPi NEO is available with 256 MiB or 512 MiB but only in single bank configuration. NanoPi Air is available with 512 MiB (also single bank).<br />
<br />
DRAM is clocked at '''432 MHz''' by the hardware vendor. [[User:Tkaiser]] did some consumption and thermal measurements just to find out that the board deadlocks pretty fast when running lima-memtester regardless of DRAM clockspeed (happens within minutes) but as soon as an annoying fan is added to FriendlyARM's heatsink blowing air between heatsink and SoC the board survives lima-memtester running at 600 MHz for several hours (board found powered off after increasing up to 672 from userspace after another hour). Since visual feedback is impossible on a board that lacks any display output we should consider 432 MHz to be a sane default since it both helps decreasing heat and consumption.<br />
<br />
Based on [[User:Tkaiser]]'s tests reducing DRAM clockspeed by 24 MHz more (with BSP kernel 408 MHz is the lowest allowed clockspeed) is even better since it does not affect performance that much (negligible according to tinymembench) but both temperature and consumption are lowered a lot by switching from 432 MHz to 408 MHz. Test results [http://forum.armbian.com/index.php/topic/1728-rfc-default-settings-for-nanopi-neoair/?view=getlastpost here] and description of test setup [http://forum.armbian.com/index.php/topic/1665-rfc-using-a20-board-with-armbian-as-powermeter/#entry13765 there] (using another sunxi board's AXP209 to do consumption measurements). BSP kernel boots happily with ''CONFIG_DRAM_CLK=408'' and ''CONFIG_SYS_CLK_FREQ=480000000'' set in u-boot 2016.07.<br />
<br />
The single bank DRAM configuration is slower than dual bank configuration on all other H3 devices. Even more when taking the different DRAM clockspeeds into account. Using [https://github.com/ssvb/tinymembench tinymembench] and looking at ''standard memcpy'' numbers, NEO/Air clocked with 408 or 432 MHz show ~435 MB/s while other H3 boards with dual bank DRAM clocked at 624 MHz reach ~900 MB/s (for more details see [http://forum.armbian.com/index.php/topic/1748-sbc-consumptionperformance-comparisons/#entry13958 post #13 in this thread in Armbian forums]). When using [https://github.com/pooler/cpuminer cpuminer] then NEO/Air clocked with 1200 MHz achieve 1.83/1.85833 khash/s with DRAM clocked at 408/432 MHz while an Orange Pi Lite with identical settings (HDMI/Mali disabled and also clocking at 1200 MHz) achieves 2.10867 khash/s with DRAM clocked at 624 MHz (that's a ~12 percent performance loss with this specific workload only due to different DRAM configuration and clockspeed)<br />
<br />
== WiFi ==<br />
NanoPi NEO AIR has an [[Wifi#Ampak|Ampak AP6212]] chip, which needs [https://vps.vdwaa.nl/~jelle/brcm/ special firmware files]. [http://marc.info/?l=devicetree&m=148751513807893 Patch to enable WiFi support]<br />
<br />
== USB ==<br />
<br />
The one USB host port exposed as type A receptacle is usb3. Both usb1 and usb2 are available via solder holes.<br />
<br />
== Analog Audio ==<br />
<br />
On NanoPi Air analog audio out and mic in is available on 4 solder pads next to the camera connector. Please check schematic for details.<br />
<br />
= Locating the UART =<br />
<br />
[[File:Nanopi-uart.JPG|thumb|240px|NanoPi NEO UART pins]]<br />
<br />
Four-pin UART0 header is placed next to USB type-A connector. Pinout: GND, 5V, TX, RX. Pin 1 (GND) is the one furthest from the board edge. Logic voltage is 3.3V.<br />
For more instructions refer to our [[UART|UART Howto]].<br />
<br />
= Pictures =<br />
<br />
== NanoPi NEO ==<br />
<gallery><br />
File:NanoPi_NEO_top.jpg<br />
File:NanoPi_NEO_bottom.jpg<br />
File:NanoPi_NEO_1.jpg<br />
File:NanoPi_NEO_2.jpg<br />
File:NanoPi_NEO_3.jpg<br />
File:NanoPi_NEO_4.jpg<br />
File:Nanopi-front.JPG<br />
File:Nanopi-back.JPG<br />
File:Nano_Heatsink.jpg<br />
File:NanoPi_NEO_Cluster.jpg<br />
</gallery><br />
<br />
== NanoPi NEO Air ==<br />
<gallery><br />
File:NanoPi_Air_1.jpg<br />
File:NanoPi_Air_2.jpg<br />
File:NanoPi_Air_3.jpg<br />
</gallery><br />
<br />
= See also =<br />
<br />
* [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air Air device page on FriendlyARM wiki page]<br />
* [http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO NEO device page on FriendlyARM wiki page]<br />
* [http://forum.armbian.com/index.php/topic/1580-nanopi-neo-air Armbian forum thread for both devices]<br />
* [http://wiki.friendlyarm.com/wiki/images/9/98/NanoPi-NEO-Air-1608-Schematic.pdf NEO Air Schematic for PCB rev 1.0]<br />
* [http://wiki.friendlyarm.com/wiki/images/a/aa/NanoPi-NEO-1606-Schematic.pdf NEO Schematic for PCB rev 1.0]<br />
* [http://wiki.friendlyarm.com/wiki/images/c/c4/NanoPi-NEO-V1.1-1607-Schematic.pdf NEO Schematic for PCB rev 1.1]<br />
* [http://wiki.friendlyarm.com/wiki/images/1/1c/NanoPi-NEO-V1.2-1608-Schematic.pdf NEO Schematic for PCB rev 1.2]<br />
* [http://wiki.friendlyarm.com/wiki/images/9/99/NanoPi-NEO-1606-dimensions%28dxf%29.zip board mechanical drawings (dxf)]<br />
<br />
== Manufacturer images ==<br />
See the manufacturer's device pages above since links change from time to time.<br />
<br />
[[Category:Devices]]<br />
[[Category:H3 Boards]]<br />
[[Category:FriendlyARM]]<br />
[[Category:Devices with Ethernet port]]<br />
[[Category:Devices with Wifi]]<br />
[[Category:Mainline_U-Boot]]<br />
[[Category:Mainline_Kernel]]</div>Karlp