reTerminal D1001 - Wiki and documentation completely useless. I need better support

Products & Technology
1

Hello,

I managed to get ESP-IDF installed and configured for the D1001. I can even build and flash the supplied example FW on the github page of the D1001. However, it just does not work. The documentation and wiki page is just not sufficient to support someone to start developing for that product.

As a result, my D1001 is bricked… I ‘could’ flash the factory default firmware .bin-files that are on the git-page, but it lacks total guidance on how to even do that…

Please SEEED Studio, I am a long time user of reTerminals (all versions) but support on getting started on this D1001 is completely non-existant.

2

Ok. After a vacation I picked this project up again. I managed to get the EC25 EU working and I have internet connected now. I can build and flash from the source code. At the moment I am looking into getting the D1001 into landscape mode, but it does not want to. There is a commented out line of code in the source code supplied by Seeed, that hints to screen rotation, however, uncommenting this line breaks the boot, it goes in panic… Any idea’s on this one?

3

Hi there,

\So I have seen this come up a number of times, in different versions and updates, Looking into it’s root cause I see this ,

That kernel panic on boot when enabling rotation is a known bug in the vendor BSP/kernel tree for the reTerminal / D1001 (Raspberry Pi Compute Module 4 base) display pipeline.

The issue stems from how the Raspberry Pi DSI display driver (panel-raspberrypi-touchscreen or Seeed’s custom panel-seeed-reterminal) interacts with the DRM/KMS graphics stack and hardware orientation flags in the Device Tree versus the kernel framebuffer.

When you uncomment the orientation property in the Device Tree Overlay or driver source, the DRM subsystem attempts to set a hardware rotation transform during early boot before the DSI video timing registers or display memory buffers are properly allocated, causing a kernel panic or null pointer dereference in drm_atomic_helper.

How to Achieve Landscape Mode Safely (Without Kernel Panics)

Instead of forcing the rotation at the low-level kernel driver/Device Tree source level (which triggers the driver crash), leave the driver default intact and apply the rotation in User Space or via DRM/KMS Kernel Command Line Parameters.

Method 1: Kernel Command Line (DRM/KMS Level) — Recommended

This rotates the screen during early boot (console + graphics) at the DRM display framework level without modifying driver source code.

  1. Open /boot/firmware/cmdline.txt (or /boot/cmdline.txt on older Pi OS builds).

  2. Append the video rotation parameter to the end of the existing single line (do NOT create a new line):

video=DSI-1:720x1280M@60,rotate=90

If rotate=90 doesn’t flip it to your preferred landscape orientation, try rotate=270).*

Method 2: Device Tree Overlay Config (config.txt)

If you are using the standard VC4 DRM driver (vc4-kms-v3d or vc4-fkms-v3d), set the display orientation using the video overlay parameters in /boot/firmware/config.txt:

# Force display orientation via KMS
dtoverlay=vc4-kms-v3d
display_lcd_rotate=1

Note: display_lcd_rotate=1 rotates 90° (landscape), 3 rotates 270°.

Fixing Touchscreen Alignment in Landscape

When you rotate the D1001 display to landscape via user-space or KMS, the capacitive touch matrix (Goodix or I2C touch controller) will still be mapped to portrait coordinates.

To rotate touch input to match your landscape screen:

  1. Create or edit /etc/X11/xorg.conf.d/40-libinput.conf (or /etc/udev/rules.d/98-touchscreen.rules).

  2. Set the Coordinate Transformation Matrix for the touch device:

    • 90° Rotation (Landscape): 0 1 0 -1 0 1 0 0 1

    • 270° Rotation (Inverted Landscape): 0 -1 1 1 0 0 0 0 1

HTH

GL :slight_smile: PJ :v:

there is another thread on here about it also. long way back though :grin:

4

Hi Pj,

Thanks for your extensive answer, it looks like you have invested some time in that elaborate post, but I’m afraid to tell you that I know the issue you are describing, as I already have some in-depth experience with the reterminal CM-based devices. However, my question is about the D1001, which is ESP32P4-based so your remarks are not applicable I’m afraid.

5

Hi there,

WOW< Certainly, :grin:
Aha, my mistake! Having ‘reTerminal’ in the mix defaulted my brain straight to the CM4 Linux stack. For the ESP32-P4 D1001, it’s a very different beast under ESP-IDF.

The panic you’re hitting when uncommenting that rotation line in Seeed’s BSP is because the ESP32-P4’s esp_lcd MIPI-DSI DMA framebuffers are allocated in PSRAM with strict line-stride alignments matching the native $720 \times 1280$ panel. Toggling hardware rotation at the panel driver level breaks those stride bounds and triggers an immediate memory access panic on boot.

The fix:

  1. Leave Seeed’s BSP/hardware panel driver untouched in its default native mode.

  2. Apply the $90^\circ$ or $270^\circ$ rotation at the graphics framework layer instead (e.g., using lv_disp_set_rotation(disp, LV_DISP_ROT_90); in LVGL v8 or lv_display_set_rotation() in v9).

This lets the ESP32-P4 DMA engine push native vertical frames to the MIPI bridge without crashing, while LVGL handles rendering your UI horizontally in PSRAM.

would be a suggestion on this use case, P4 ? the slipped that one past me… :wink:

HTH
GL :slight_smile: PJ :v:

What is it with the display stuff, they really have some kinks with that in all of theses edge platforms.. ?

6

Ok. Tried it… kind of. The fix you suggest is actually what is commented, I believe… This is Seeed’s original code:

bsp_display_cfg_t cfg = {
        .lvgl_port_cfg = ESP_LVGL_PORT_INIT_CONFIG(),
        .buffer_size = BSP_LCD_H_RES * BSP_LCD_V_RES,
        // .buffer_size = BSP_LCD_DRAW_BUFF_SIZE,
        .double_buffer = BSP_LCD_DRAW_BUFF_DOUBLE,
        .flags = {
            .buff_dma = false,
            .buff_spiram = true,
            .sw_rotate = true,
        }
    };
    lv_display_t *display = bsp_display_start_with_config(&cfg);
    // bsp_display_rotate(display, LV_DISPLAY_ROTATION_90);

Take attention to the commented-out line // bsp_display_rotate, which is:

void bsp_display_rotate(lv_display_t *disp, lv_disp_rotation_t rotation)
{
    lv_disp_set_rotation(disp, rotation);
}

So my first idea was to uncomment this line of course… but that results in a panic…