User:NiteHawk

= Hardware =

H3

 * Xunlong Orange Pi PC

A64

 * Pine64+ (1GB, WiFi) - Thanks to apritzel.

A20

 * LeMaker Banana Pi

Current issues / problems encountered:
 * U-Boot regression: For v2015.07 the switch to driver model breaks U-Boot compilation when  is defined (reported to ML). v2015.10 fixed that.
 * Commit c32a6fd breaks MII detection (and thus U-Boot networking) for Banana Pi, fc8991c fixes it again. However that means networking support in U-Boot v2016.03 is broken.
 * Current U-Boot master may crash during USB initialization: http://lists.denx.de/pipermail/u-boot/2016-April/250372.html (patch available, but only merged into u-boot-usb.git so far). Fixed with commit cfb3f1c (contained in v2016.05-rc1).

I'm currently staying with (and recommending) U-Boot release v2015.04 for the BPi. That version works well while enabling all the features I tend to use. As of v2015.10, U-Boot support is rather complete again - one missing thing is support for the (green) status led.

Mainline kernel "missing clock-frequency property": A suggested patch never made it anywhere?

Cortex-M3

 * STM32 VL Discovery board

= Contributions =

linux-sunxi

 * Extend "fel spl" command to handle both parts of u-boot-sunxi-with-spl.bin, and have "fel uboot" interact with U-Boot (support autostart of script via bootcmd_fel). Merged into sunxi-tools (and U-Boot v2015.10).
 * see also: github sunxi-tools

U-Boot patches
http://patchwork.ozlabs.org/project/uboot/list/?submitter=66075&state=*

= Scratchpad = Move along, nothing to see here...

Addendum for Retrieving_device_information
 * This is usually an indication that the SPL (or boot0) wasn't loaded/executed properly. You might have to select an alternative method (UART) of entering FEL, or use  before giving the "read" commands.

See http://irclog.whitequark.org/linux-sunxi/2016-04-29#16309060 ff. Also: This method seems outdated / unreliable anyway - it isn't guaranteed that the sought information is present at those specific DRAM locations?

Using sunxi-fel on Windows
Under Windows (unlike Linux) every USB device that an application program wishes to access must have a suitable USB driver installed. This means that any device that shows up as "unknown" in your Device Manager will be  - typical symptoms would be an ERROR: Allwinner USB FEL device not found! message, or even libusb_open ERROR -12: Operation not supported or unimplemented on this platform when trying to enforce the specific device with the  option.

Zadig to the rescue
Fortunately, there's a very convenient utility to help with the USB driver setup. Grab your copy from http://zadig.akeo.ie/.

Before launching it, make sure your Allwinner device is connected and in FEL mode.



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.


 * 1) (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.
 * 2) 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 sunxi-fel.exe has special driver requirements, those should be stated in the accompanying documentation. When in doubt, select WinUSB for a "generic" driver (available from Win XP SP3 onwards).
 * 3) Click "Install Driver". Voilà - from now on your device should no longer be "unknown" in Device Manager, and sunxi-fel is expected to work with it.


 * Sunxi-fel_win32.png

Troubleshooting:
 * If you have listdevs.exe 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.
 * 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.

Here be dragons: If you want to toy with this, get precompiled binaries from https://ci.appveyor.com/project/n1tehawk/sunxi-tools/build/artifacts.

= External documentation (links / 'bookmarks') =


 * NanoPi M1 (low-cost H3 board)
 * Some BPi-M2+ information

NEON
&rarr; ARM architecture, Advanced SIMD (NEON)

TrustZone

 * ARM architecture, Security extensions (TrustZone)
 * ARM Infocenter, TrustZone Technology
 * TrustZone Protection Controller Register Guide

sunxi NAS

 * Using the Allwinner A10/A20 as a home server

sunxi-tools / FEL boot
(snippets from U-Boot and linux-sunxi mailing lists)
 * |U-Boot| sunxi: Support uploading 'boot.scr' to RAM over USB OTG in FEL mode
 * |linux-sunxi| Re: sunxi-tools: extend fel utility to handle SPL + U-Boot binary