A tablet, a familiar core, a different machine

The first time poulsback was deliberately offered the Fujitsu tablet’s GPU, it refused. The console stayed visible, the device stayed unbound, and the next boot returned to the stock Linux driver. For a project whose usual success looks like a rotating cube, that was a useful change of pace.

The Dell Inspiron 1210 has carried most of the hardware work so far. It runs the project’s Mesa and Xorg stack on GMA500, giving us a machine on which to compare images, trace frames and measure changes. The new reference is a Fujitsu STYLISTIC Q550/C: a 2011 tablet with an Atom Z670 and GMA600. It puts a familiar graphics family inside a substantially different computer.

Getting Debian onto it, understanding its stock display driver and checking that our module leaves it alone have already taught us something. Poulsback has not rendered a frame on this tablet. Its SGX core identity, revision and running clock remain unread. This chapter is about making the next steps possible without confusing a working console with a working renderer.

Same same, but different?

Intel’s GMA500 and GMA600 are based on Imagination’s PowerVR SGX535 family. That gives the project a reason to investigate reuse of the shader compiler and rendering work. The surrounding chip still decides where registers live, how memory is mapped, which display pipe feeds the panel and how power reaches each block.

The useful comparison is therefore larger than the name on the GPU:

The tablet identifies as Fujitsu FMVNQ4LE, with an FJNB230 board and Phoenix BIOS 1.25. It has 2 GiB of RAM, a 10.1-inch panel and a Toshiba SSD reporting 62.0 GB, or about 57.8 GiB.

There is also an N-trig DuoSense pen and multitouch controller, a camera, Wi-Fi, Bluetooth, fingerprint and smartcard readers. HDMI appears as a separate PCI function, alongside an HDA audio controller. An enumerated device is a starting point for testing; it does not tell us whether its complete function works.

Getting past the firmware

The Atom Z670 is a 32-bit x86 processor, as Intel’s Z6xx datasheet describes. This installation uses Debian 12’s i386 edition, whose release notes explain its i686 baseline. CPU compatibility was straightforward. The boot handoff took more investigation.

Some existing research USB images booted on the Q550, but the Debian installer candidates did not behave like the same media on the Dell. The productive path was IA32 UEFI: firmware loaded GRUB, GRUB loaded Linux, and then the screen stopped providing useful evidence.

At that point, changing the installer again would have been guesswork. The important improvement was observation. earlycon=efifb keep_bootcon let the kernel print through the framebuffer supplied by the firmware. The last visible messages were around the EFI runtime memory map. That narrowed the investigation to the runtime-services handoff; it did not identify an exact failing firmware instruction.

Disabling those services with efi=noruntime let the Debian installer continue. The system now boots Debian 12 with a 6.1 i686 PAE kernel. The workaround stays in the installed system’s kernel command line, including its recovery entries. Keeping it only in an ordinary menu entry would leave an unpleasant surprise precisely when recovery was needed.

There is a second consequence. With runtime services disabled, Linux cannot use EFI variables to register the usual firmware boot entry. That does not mean the machine has no NVRAM. It means this booted kernel cannot use that interface. The installation keeps the IA32 removable-media fallback loader at EFI/BOOT/BOOTIA32.EFI, which the firmware can start without a newly registered entry. Debian’s GRUB configuration keeps that fallback copy updated.

The setup steps are recorded in a provisioning script. It applies the machine’s boot parameters, key-only SSH access, package setup and sleep policy, and holds the chosen kernel. A repeat run retained the intended configuration on this installation. The script also applies available package updates, so it does not freeze the entire software environment. Builds happen elsewhere; the tablet does not need a compiler and kernel headers just to run an experiment.

Firmware files are only part of a working peripheral

The first inventory checked which firmware files the loaded drivers could request. Debian’s firmware packages supplied the external USB Ethernet adapter’s firmware and the rt2870.bin file used by the Wi-Fi driver. The wireless regulatory database was also installed. The Wi-Fi interface was down during this check, so a present firmware file is the result we can claim; a tested wireless connection is still a separate result. The stock GPU display path needs no additional firmware file to light the panel.

The CPU reported microcode revision 0x104.

Bluetooth was the exception in the firmware inventory. Its BCM20702 device requested a board-specific patch file that was absent from the checked Debian and upstream firmware collections. The recorded Linux boot did not load that patch. Pairing and Bluetooth audio have not been tested, and the graphics work does not depend on them.

The boot log also records a failed ACPI fixed-power-button probe and an I2C-controller mapping failure. The TPM reported that it was disabled or deactivated, followed by IMA communication errors. These messages give the peripheral investigation concrete starting points.

The kernel marked the timestamp counter unstable because it halts in deeper idle states. It switched the main clocksource to HPET and the default tracing clock to global. Those recorded boot decisions matter when interpreting frame traces.

A working panel with several unfinished edges

The stock gma500_gfx driver provides the first display baseline: a readable 1280 × 800 text console, at 32 bits per pixel, with a 5120-byte row stride. It is KMS display support. It does not provide the SGX acceleration that poulsback is trying to build.

Its startup illustrates how much platform code sits between a graphics core and a lit panel. The driver attempts to read an Oak Trail panel configuration table, the GCT, through an address obtained from the GPU’s PCI configuration. On this machine that address lies in ACPI NVS memory. The attempted uncached mapping conflicts with an existing write-back mapping, and Linux reports Unable to read GCT!.

The mapping failed before the driver could read the structure’s contents. The stock driver takes its VBT path instead and obtains a usable panel mode. The LVDS connector returns no EDID, yet the firmware-provided timing is sufficient to make the built-in display work.

HDMI has a different problem. Its DDC bus, used to ask an attached monitor about supported modes, tries to register a fixed I2C adapter number already taken by the driver’s GMBUS adapters. Registration fails with a warning. The inventory shows a disconnected HDMI-related connector with no modes or EDID. The tablet has an HDMI port, but we have not tested an external monitor or audio through that connection. Connector detection, a displayed image and audible monitor output each still need their own check.

Brightness control is another distinct boundary. The driver logs that it is skipping its Oak Trail backlight registration, and /sys/class/backlight remains empty. ACPI describes brightness methods, and Fujitsu-specific ACPI devices are present, but no usable backlight interface appeared. The open Linux code also has an earlier PWM initialization path, which can run before backlight registration. The live PWM values have not been captured; resolving brightness control needs both the register path and its ACPI counterpart.

Two findings came from reading the open Linux code rather than provoking the machine. First, the Oak Trail sleep path uses offsets from a power-management base that this platform path never initializes. With a zero base, those offsets reach I/O ports in the legacy interrupt-controller range. System sleep is masked on this Q550 while that path is investigated; we did not attempt suspend or hibernation to see how it would fail.

Second, pipe A’s generic base and surface entries point to the same surface-address register. The update path leaves the separate linear-offset register unwritten. A zero-offset console does not establish correct panning or page-flip behaviour. Our port needs to keep those operations distinct and measure them, rather than infer their correctness from the readable console.

These boundaries explain why adding a device ID is such a small part of a graphics port. The panel can work while brightness, external displays, buffer changes and sleep each still require their own implementation and evidence.

Following the open Linux trail

The old PSB name is useful when searching Linux history. GMA500 entered staging in Linux 2.6.39. By Linux 3.1, the driver configuration offered experimental GMA600 support for Moorestown and Oak Trail LVDS platforms. It explicitly excluded HDMI and MIPI support at that stage. Those are versioned statements about that driver, rather than a promise of a complete old tablet stack.

The earlier driver also contained SGX identity reads that the current KMS path no longer performs. Old code can therefore explain which observation is missing from a modern boot, even when it is unsuitable as a driver to install. The aim is to understand the contracts that still need testing.

The old stacks retained for the Dell did not supply a ready-made tablet port. The inspected PSB 4.42 source admits Poulsbo IDs 8108 and 8109. The retained Linux EMGD 1.8 source adds Tunnel Creek’s 4108, but its active device table still omits the Q550’s 4102. Lincroft definitions do appear in disabled code, and some partial LVDS paths are real. A device constant is a clue to investigate; a working platform implementation requires considerably more.

Intel’s published EMGD history needs similarly careful reading. Its version 1.14 feature matrix lists the E6xx and Z5xx/US15W platforms. Those columns do not establish support for the Q550’s Z670.

There was a wider Linux story around the processor: Intel’s Z670 development-kit brief lists MeeGo 1.2 for that development platform. It gives the search a contemporary Linux reference, while the software still needs to be matched to this Fujitsu board and its display configuration.

The first load, and the deliberate refusal

Our first module experiment left stock gma500_gfx bound to the GPU. Loading poulsback in that state checked its kernel compatibility and registration without offering it the device. The module loaded, bound nothing and unloaded again. The stock console remained available throughout.

That check preceded a necessary admission change. The module had inherited a broad PCI device table, while the accelerated path was designed around the Dell. We narrowed admission to the supported GMA500 device and placed an explicit guard at the beginning of probe, before framebuffer removal or GPU register access.

The next experiment used a one-time boot with stock gma500_gfx disabled. The firmware’s EFI framebuffer kept the console visible at 1024 × 768; this was not the stock driver’s 1280 × 800 panel configuration. Poulsback loaded without binding a device. We then deliberately requested a probe through Linux’s driver_override mechanism.

The guard produced exactly the intended refusal:

refusing 8086:4102: only the GMA 500 8086:8108 binds

Our probe returned before touching GPU or display registers, and the device stayed unbound. A reboot restored the normal stock-driver configuration. Loading a module and rejecting a GPU are useful checks of those paths; they do not establish successful GPU initialization. That boundary is now explicit instead of being hidden behind a much later failure.

A lesson from x87 before the GPU ran

The CPU suites produced a separate surprise. We built their i686 executables and ran them on the Atom Z670. Fifty-one of the 52 executables passed. The remaining vertex test also failed in the i686 build container, which was a strong clue that the tablet’s GPU had nothing to do with it.

The test compared a model’s float result with an expression whose intermediate value could remain in x87 extended precision. On an ordinary 64-bit host, the same exact comparison had not exposed the difference. Making the expected rounding explicit corrected the test itself. The GPU was never involved in that failure.

A second machine earns its place even before its renderer works. It can exercise the intended CPU architecture, expose assumptions in tests and make the difference between host validation and GPU validation concrete.

From a safe baseline to a graphics port

The next stage begins with observation. Debian’s installed kernel includes mmiotrace, which can record the stock driver’s CPU memory-mapped I/O accesses during bring-up. That is a planned reference capture, not an experiment already completed. As the Linux tracing documentation explains, it is an MMIO observation tool; it does not reveal every firmware action, DMA transfer or internal operation in the GPU.

Read-only identity checks must establish the SGX core and revision before we decide how much of the existing engine can carry over. A chip profile can then supply the platform’s register windows, power rules and display adapter, while retaining a shared renderer where the evidence supports it.

Memory visibility, interrupt delivery and completion come before ambitious scenes. The port then needs small 2D and 3D checks, followed by panel presentation: correct buffer addresses, measured latch timing, vblank and safe retirement of the previous image. Only after those foundations should Xorg, Present and the existing application tests establish a tablet result of their own.

Brightness needs a clear owner. HDMI needs real monitor data, an image, hotplug and audible sound through a monitor’s speakers, with each outcome tested separately. Power transitions and repeated suspend/resume follow their own qualification. MSVDX video decoding remains a separate later task.

The order has no promised completion date. Each step should answer a small question and leave a usable baseline for the next one. The Dell’s hardware demos show what the existing stack can do on its recorded builds; the hardware guide explains the stages we hope to connect on the Q550. This tablet’s first successful refusal gives us a clear place to begin.