OrangePI Zero overlay and uboot/armbian

The Armbian has good documentation about how to use device overlays for their uboot scripts.  I wanted to dive a little deeper and understand some of the basics and still use buildroot.

Boot process of uboot, there is a file on the FAT partition boot.src, this is a binary file generated by mkimage.  The source file is in board/orangepi/orangepi-zero boot.sh:
setenv fdt_high ffffffff
setenv load_addr "0x44000000"
echo "Boot script loaded from ${devtype}"

setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rootwait

fatload mmc 0 $kernel_addr_r zImage
fatload mmc 0 $fdt_addr_r sun8i-h2-plus-orangepi-zero.dtb
fdt addr ${fdt_addr_r}
fdt resize 65536
setenv processorName sun8i-h3-
setenv overlays i2c0  spi-spidev
for overlay_file in ${overlays}; do
    echo " looking for  ${processorName}${overlay_file}.dtbo"
    if fatload mmc 0 ${load_addr} ${processorName}${overlay_file}.dtbo; then
        echo "Applying user provided DT overlay ${overlay_file}.dtbo"
        fdt apply ${load_addr} || setenv overlay_error "true"
    fi
done


bootz $kernel_addr_r - $fdt_addr_r

So, what happens is the device tree overlays are merged in uboot with the dtb file loaded for the board using fdt command line tools.  This allows to change the board dtb without always recompiling it.

Post any questions you have.   So, spi and i2c are now using device tree overlays.

Here is the overlay for SPI:
/dts-v1/;
/plugin/;

/ {
    compatible = "allwinner,sun8i-h3";

    fragment@0 {
        target-path = "/aliases";
        __overlay__ {
            spi0 = "/soc/spi@01c68000";
            spi1 = "/soc/spi@01c69000";
        };
    };

    fragment@1 {
        target = <&spi0>;
        __overlay__ {

            #address-cells = <1>;
            #size-cells = <0>;
            status = "disabled";

            spidev@1 {
                compatible = "linux,spidev";
                reg = <0>;
                spi-max-frequency = <1000000>;
            };
        };
    };

    fragment@2 {
        target = <&spi1>;
        __overlay__ {

            #address-cells = <1>;
            #size-cells = <0>;
            status = "okay";

            spidev@2 {
                compatible = "linux,spidev";
                reg = <0>;
                spi-max-frequency = <25000000>;
            };
        };
    };
};


so, this completes the task of using overlays.  Next DHCP and zeroconfig.

Also, have a modification to EEM USB handler, to improve performance.  Also, thinking of adding a way to use several packets at once based on the size of the packet.

Merge latest changes from Cleanflight

Updated the repo with the latest CleanFlight changes, the merge compiled and ran on x86.  I'm in the middle of updating OrangePI buildroot to use some patches from Armbian and start using device tree overlays.  This makes it easier to add I2C etc without changing the orangePI zero DTS. More on that in the next couple of posts.  i.e basic device overlays using uboot via fdt commands.

Cleanflight configurator is working, the imu processing was not enabled, so, now the graphic is now updating.  

Also move the process to a core, using cpu isolation   (via taskset, etc) to reduce jitter.

Also, working on using dnsmasq as a dhcp server with mdev, this allows I/O board to get a IP address and try zeroconfig/DNS-Based Service Discovery.  The goal is to use names, instead of hard coded IP addresses, so when moving to WiFi networking there will not be a conflict.   Confusing?  I'm too ;)

Updated the I/O EEM packet handling to increase the performance, takes about 23us per 64 byte USB packet.  The goal is to have a 512 UDP packet take less then a 1ms. 

Looked at the GPS handling, right now, GPS parsing is handled on the I/O card, tho goal being to reduce processing in the main loop.  Still looking at the code and how RTH and stabilization process the GPS information.

Tasks Order:

• Update Kernel/u-boot to use overlays
• 4.13 kernel is booting along with u-boot (Now)
• updating boot.src to process device tree overlays  (in progress)
• Dynamic IP addressing 
• Test DHCP server first
• Add zeroconfig with MDNS on lwIP 
•  
•  Retest EEM USB Ethernet
• Add LED API 
• Cleanflight uses two LED APIs will use the basic one, i.e 3 LEDs and test the speed of UDP updating LEDs from Linux
• Add PWM reciever API
• The I/O is processing PWM from receiver, will forward this info onto Cleanflight  validate the configurator is working.