Introduction & Overview

The following are the notes of getting U-Boot with SPL to boot from QSPI Flash on i.MX6ULL platform.

SPL is a stripped-down version of the full U-Boot, typically being loaded into on-chip SRAM. It is responsible for initializing the system (power, SDRAM, storage, etc.), loading the full U-Boot into SDRAM, and then jumping to the full U-Boot. (There is also a falcon mode, where SPL directly loads the kernel and jumps to the kernel.) Typically one doesn't need to use SPL on i.MX6 platform. The boot ROM is quite capable and extensible, to a point you may not even need the U-Boot at all.

In my case, I am using a board that requires the PMIC to be initialized before initializing DRAM. This could be implemented by using the plugin binary on the i.MX6 platform (essentially a small piece of code that would run before loading the full image), however in that case I would be completely on my own to figure out IO multiplexing, I2C controller programming, etc. An easier way is to use the SPL to set that up: it's designed to do that, after all. On top of that, I want the whole thing to run from SPI Flash.

Overall, I want the following features:

• U-Boot + SPL boots from QSPI Flash (W25Q32JV in my case)
• SPL should initialize the PMIC over I2C
• I start with a board that doesn't have anything:
  • eFUSE not programmed
  • Empty flash

I need the U-Boot + SPL to boot from the flash, but I also need to figure out how to set up the eFuse to let the processor try to boot from QSPI also write the U-Boot image into the empty flash. The plan would then be:

1. Load SPL into the processor's internal SRAM via USB and run the SPL to initialize the PMIC and DDR
2. Load the U-Boot into the DDR using SPL over USB and run the U-Boot
3. In the U-Boot, program the eFUSE
4. In the U-Boot, receive the U-Boot image over USB and write it into the flash.

The flash layout would look like this:

---- 0x00000 / Start ----
Empty (reserved for partition table)
---- 0x00400 / 1KB ----
QuadSPI Configuration Parameters Table, to be loaded by BROM
---- 0x01000 / 4KB ----
U-Boot SPL in imx image format, to be loaded by BROM
---- 0x12000 / 72KB ----
U-Boot in leagcy uImage format, to be loaded by SPL
---- 0xA0000 / 640KB ----
U-Boot environment variables
---- 0xA2000 / 648KB ----

Let's go over these steps.

macOS introduced EDR/ HDR support for OpenGL and Metal few years back. This years' new MacBook Pro came with HDR screens by default. This is a quick note about how to enable EDR/ HDR for GLFW.

The idea about HDR is that, typically the color rendered to the screen are clamped to [0, 1]. However when HDR is enabled, the screen could display color higher than 1.0. By default this is disabled so all colors are still clamped to 1.0.

To use HDR, it only needs 2 things to be set correctly:

1. The HDR is enabled for the OpenGL/ Metal surface so OS is not doing clamping
2. The framebuffer is using FP16 (RGBA16F) format so OpenGL is not doing clamping

To implement in GLFW, in src/nsgl_context.m, for example, do the following:

    GLFWbool useHDR;

    if (fbconfig->redBits != GLFW_DONT_CARE &&
        fbconfig->greenBits != GLFW_DONT_CARE &&
        fbconfig->blueBits != GLFW_DONT_CARE)
    {
        int colorBits;

        if (fbconfig->redBits == 16 &&
            fbconfig->greenBits == 16 &&
            fbconfig->blueBits == 16)
        {
            colorBits = 64;
            addAttrib(NSOpenGLPFAColorFloat);
            useHDR = true;
        }
        else {
            colorBits = fbconfig->redBits +
                    fbconfig->greenBits +
                    fbconfig->blueBits;

            // macOS needs non-zero color size, so set reasonable values
            if (colorBits == 0)
                colorBits = 24;
            else if (colorBits < 15)
                colorBits = 15;
            useHDR = false; 
        }

        setAttrib(NSOpenGLPFAColorSize, colorBits);
    }

This piece of code sets the framebuffer to use RGBA16F if both R/G/B channel depth is set to 16 bit. You could also modify the GLFW code to use additional hint to enable HDR.

Conditional Execution

This time we are going to take a look at how to implement the loop in SHARC+ assembly. We will be using the following simple code as an example:

// Calculate the Fibonacci number Fn, n need to be at least 2
int fibonacci(int n) {
    int a = 0, b = 1, f;
    for (int i = 1; i < n; i++) {
        f = a + b;
        a = b;
        b = f;
    }
    return f;
}

Normally, to implement it in assembly you would have code like this (RISC-V assembly for example):

    li t0, 0 # a
    li t1, 1 # b
    li t3, 1 # loop counter
loop_start:
    add t2, t0, t1
    mv t0, t1
    mv t1, t2
    addi t3, t3, 1
    blt t3, a0, loop_start

    mv a0, t2

A similar thing could be implemented in SHARC+ as well. Let's take a look at the code first (note the code is fairly inefficient, and we will improve that gradually):

    r2 = 1; // loop counter
    r8 = 0;
    r12 = 1;
loop_start:
    r0 = r8 + r12;
    r8 = r12;
    r12 = r0;
    r2 = r2 + 1;
    comp(r2, r4);
    if lt jump loop_start;

Aside from the syntax difference, one major difference is that SHARC+ uses flags to do the conditional jump, so a comparison instruction might be necessary before the condition. In this example, the loop counter is compared against the end condition. If the loop counter is less than (lt) the end condition, it jumps back to the beginning of the loop. If it is counting down, then we could use flags that directly compare the last result with zero. There are other conditional codes (and there complementary) available:

Prologue

During the past year, I found myself writing a lot of SHARC+ assembly code. For me, the SHARC is quite an interesting ISA. It's in some way very different from other general-purpose RISC processors. From a quick search, there is no SHARC+ assembly programming tutorial I can find online. As a result, I am writing one myself. This is more or less a quick guide instead of a complete document. For the latter, please read the official SHARC+ PRM (programming reference manual).

This guide assumes knowledge of the C programming language and common computer architecture. Familiarity with at least one kind of assembly language (x86, arm, MIPS, z80, etc.) would help a lot.

If you are intending to learn to program the SHARC+ DSP, hope this tutorial will help you. If you are just a computer architecture enthusiast like me, just wanting to learn about this architecture, hope you would find this tutorial interesting.

(Figure: SHARC+ core diagram, source: SHARC+ PRM)

Introduction

SHARC, which stands for Super Harvard Architecture Single-Chip Computer, is a series of DSPs designed and sold by Analog Devices Inc since 1991. By the time of writing (2021), there are 3 variants of the ISA:

• SHARC (correspond to SHARC-V core)
• TigerSHARC
• SHARC+ (correspond to SHARC-XI core)

This series of tutorials only apply to SHARC and SHARC+. All the processors in the 215xx series use the SHARC+ core. About the core name, SHARC-V simply means it has a 5-stage pipeline, and SHARC-XI simply means it has an 11-stage pipeline. SHARC+ is backward compatible with SHARC.

Introduction

This blog post is about the initial board bring up process of the Archer. Archer is the codename for our EPD laptop prototype at EI2030. This is not a comprehensive bringup guide, but rather document the issues I found and the corresponding solutions. The processor being used is the i.MX 7Dual.

DDR

DDR Stress Test

When there is no vaild boot devices, i.MX would enter mfgtools or USB recovery mode. In this mode the DDR stress test tool provided by NXP could be used to test the DDR read/ write leveling values. Though generally if the board is well designed, it should pass the stress test at room temperature without special calibration.

One thing to note is that, in Freescale SoCs, DDR3-800 is actually DDR3-792, and DDR3-1066 is actually DDR3-1056. Enter 396 MHz and 528 MHz respectively to test two modes.

DDR frequency

On i.MX7D, the DDR frequency could be set from anywhere up to 528MHz (DDR3-1056). By default, Boot ROM sets the DDR PLL to 1056MHz. Neither u-boot nor kernel would touch the DDR PLL settings. In kernel, the kernel would switch the DDR frequency between 24MHz, 99MHz, and 528MHz by choosing the clock source from CLKOSC, PFD396/4, and DDR PLL respectively. As an conclusion, to adjust the DDR clock frequency (for example, downclock from 1056 to 792), one could simply modify the DDR PLL settings in the DCD before u-boot starts.

Example:

/* Set DDR PLL to 792 MHz */
DATA 4 0x30360070 0x00113021
DATA 4 0x30360074 0x00113021
DATA 4 0x30360078 0x00113021
DATA 4 0x3036007C 0x00113021

DATA 4 0x30360070 0x00603021
DATA 4 0x30360074 0x00603021
DATA 4 0x30360078 0x00603021
DATA 4 0x3036007C 0x00603021

CHECK_BITS_SET 4 0x30360070 0x80000000
CHECK_BITS_SET 4 0x30360074 0x80000000
CHECK_BITS_SET 4 0x30360078 0x80000000
CHECK_BITS_SET 4 0x3036007C 0x80000000