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.

Introduction

TIM or Alice Mobile IDOL (Internet Device on Linux) is a MID (Mobile Internet Device) that was once produced back in 2007 - 2009 (rough time frame, not confirmed). IDOL is among one of the many OEM varients of the Compal Jax10. Most of the varients have the following spec:

• Intel Atom Z500 processor (45nm, 1C1T, 800MHz)
• Intel US15W chipset (GMA 500 Integrated Graphics)
• 512MB DDR-2 memory
• 2 x Intel Z140 2GB SSD
• Bluetooth
• AirDio AD1111 WiFi (Marvell SD8686 SDIO chip)
• 4.8" 800x480 Touchscreen
• U-blox NEO-5Q GPS
• Dual Camera (3MP AF)

The following is a (maybe incomplete) list of the models produced:

• Aigo P8860
• Aigo P8861 (8GB SSD)
• Aigo P8861H (8GB SSD, HSDPA 3G)
• Aigo P8880 (8GB SSD, HSDPA 3G)
• Aigo P8880E (8GB SSD, EVDO 3G)
• Aigo P8880T (8GB SSD, TD-SCDMA 3G)
• Aigo P8888 (EVDO 3G)
• Aigo P8888W (HSDPA 3G)
• Aigo P8895 (HSDPA 3G)
• Compal Jax10
• Gigabyte M528 (HSDPA 3G)
• SDFR M! PC Pocket (HSDPA 3G, French version)
• Itelco TIM Alice Mobile IDOL (HSDPA 3G, Italian version)

Many of the version comes with Linux pre-installed. However the hardware is capable of running Windows XP. This blog post is about installing Windows XP on to the Alice Mobile / TIM variant. Maybe also applies to Windows 7 or other Windows version as well.

I know this is probably 10 years too late, but if anyone happens to have this machine, hopefully this could be helpful.