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

Some notes during my own RT board bring up process.

QSPI XIP

QSPI XIP is the recommended way to run the code. Critical sections could be loaded to ITCM if needed. Will compare the performance difference later.

NXP AN12183 gives a good overview about the XIP boot flow, and provided several configurations for other Flash devices. However, the provided configurations were wrong. When using these configurations, the processor would stuck in the Boot ROM area (0x20000) after the image is loaded. The best approach is still to read the datasheet for the specific device used (including all suffix in the model number). Here is my configuration for W25Q32JV:

// Configuration for W25Q32
const flexspi_nor_config_t qspiflash_config = {
    .memConfig =
        {
            .tag                = FLEXSPI_CFG_BLK_TAG,
            .version            = FLEXSPI_CFG_BLK_VERSION,
            .readSampleClkSrc   = kFlexSPIReadSampleClk_LoopbackFromSckPad,
            .csHoldTime         = 3u,
            .csSetupTime        = 3u,
            .columnAddressWidth = 0u,
            .configCmdEnable    = 0u,
            .controllerMiscOption = 0u,
            .deviceType = kFlexSpiDeviceType_SerialNOR,
            .sflashPadType = kSerialFlash_4Pads,
            .serialClkFreq = kFlexSpiSerialClk_30MHz,
            .lutCustomSeqEnable = 0u,
            .sflashA1Size  = 4u * 1024u * 1024u,
            .lookupTable =
                {
                    // Read LUTs
                    FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xEB, RADDR_SDR, FLEXSPI_4PAD, 0x18),
                    FLEXSPI_LUT_SEQ(MODE8_SDR, FLEXSPI_4PAD, 0xFF, DUMMY_SDR, FLEXSPI_4PAD, 0x04),
                    FLEXSPI_LUT_SEQ(READ_SDR, FLEXSPI_4PAD, 0x04, STOP, 0, 0),
                },
        },
    .pageSize           = 256u,
    .sectorSize         = 4u * 1024u,
    .blockSize          = 64u * 1024u,
    .isUniformBlockSize = false,
};

The read LUT should match the timing diagram given in the datasheet:

The RADDR (row address) is 24 bits (0x18), there is a 8-bit Mode (MODE8), needs to be 0xFx, followed by 4 dummy cycles (DUMMY), finally it reads data.

Note: my board design didn't leave the DQS pad floating, so I had to loopback from SCK. For optimal performance, leave the DQS pad floating, and use DQS loopback.

Introduction

I recently bought few Plannar EL640.480-AM series panels. They are monochrome 10.4" 640x480 TFEL panels with an STN LCD interface. It is similar to DPI (sometimes called RGB), the screen is timed with HVSync signals, and needs to be continuously refreshed. But, as a monochrome screen, the pixel is 1bpp, so the data bus transmits multiple pixels at a time. These screens are also dual-scan: there are two "raster beams" at the same time, one refresh from the top of the screen, the other one refreshes from the middle of the screen. They are supposed to be refreshed at 120 Hz.

This creates some interesting challenges: It expects to be driving with an STN LCD controller. However, where can I find one?

• There used to be dedicated graphics controllers such as NM128 or CT65530 that could drive STN LCDs directly. But they have been long obsolete.
• ARM SoCs from the early 2000s typically has an LCD controller that is capable of driving STN LCDs. However many of these SoCs are also being deprecated or obsolete.
• There used to display controller chips that could convert VGA into STN LCD signals. But I don't know any specific models. I suspect they are also being deprecated.

If not using dedicated hardware (and I am not too interested in buying one anyway), there are several alternative ways to drive it:

• Use a really fast microcontroller with a large SRAM to Bit-Bang the GPIO to generate the video signal.
• Use a CPLD/FPGA to generate the timing

I have used both methods before. The first method:

• https://www.zephray.me/post/anxin_320160

The second method:

• https://hackaday.io/project/160738-cstron-cstn-lcd-monitor/log/160613-cstron-monitor-powered-by-an-ancient-cstn-screen

I am going to use the microcontroller way this time again. But this time I am going to use the RP2040, which has a very powerful IO engine called PIO. We will see how it would help us with driving the screen and offload the CPU core.

Claimer: The methods described here are provided as-is. Use at your own risk.

I am new to RP2040, this is the first time I use the PIO. So the program provided here is likely not optimal.

这个屏幕其实是很久以前买的了，是一个叫做LITE ARRAY的公司产的EL屏幕，网上也找不到什么数据手册。样子倒是确实非常接近Plannar的EL320.256-FD6，使用起来是否一样……之后就知道啦。屏幕有效区域尺寸为4.8英寸，屏幕显示比例为5:4。

驱动

由于没有资料，只能想办法套其它屏幕的资料。经过测量，可以得出以下的引脚定义：

1-2: 高压DCDC输入
3-4: 逻辑供电输入
5,7: 浮空
6,8,10,12,14,16: 接地
9,11,13,15: 输入信号

所有的输入信号经过了一层74HC14D，倒是方便了使用3.3V IO直接驱动。对比一下EL320.256-FD6的数据手册，不难发现电源部分的定义是相同的，只是少了两个信号。考虑到屏幕板上有FPGA和RAM，屏幕应该为自刷新屏幕，有可能接上电源就能够显示了。结果确实如此：

那么下一步就是要怎么把数据写进去了。我这里选择了使用树莓派4平台进行驱动，树莓派4的GPIO用来驱动这个屏幕应该是完全没有问题的。使用树莓派而不是单片机应该会在之后播放Bad Apple的时候提供一些便利。在进行了一些简单的尝试后，结论是：只要按照正常非自刷新屏幕的HVsync接口时序写数据进去就可以了。

Introduction

Coremark is a cross-platform CPU benchmark tool. I would like to create a Linux boot floppy disk that would boot on a real Intel 80386 machine and then run the coremark. It should support 80386SX with as little as ~8MB of RAM.

** WARNING **: The method described here is tested and failed to work on real machines / 86box. This project is not considered as done, and may be revisited in the future.

Buildroot

The buildroot is used to compile the gcc 5 that will be used to compile the kernel and the coremark. Linux distribution offered compiler doesn't quite work here because:

1. We are stuck with Linux 3.2.102 if 386 support is necessary. Linux 3.2 can only be built with gcc 3-5 by default.
2. The libc bundled with distribution compiler is unlikely to target i386. This cause issues when trying to link them statically into the build.

Buildroot Config

The last buildroot version that supports 386 is the 2016.02 version. Download, extract and run make menuconfig.

Set target architecture to i386, and target machine to 386. Set gcc version to 5.x. In bootloaders, select syslinux, image to install is mbr.

Buildroot Patch

There are several patches that is required to build the system correctly, apply them to the buildroot.