T736 Ubuntu BSP source map

Current evidence state

Source located; config matched; toolchain binary not yet verified; no new kernel built or installed; browser not accepted.

As of C006, 12 October 2026. This C0-012 reference release packages preserved C006 evidence; this documentation update performs no fresh hardware or browser acceptance. [E06]

An evidence snapshot for the audited T736 Linux 5.15.119 system. Recheck identities on your own board and SDK.

1. Locate the right source

Supplier-provided Shenzhen Baijie / HelperBoard T736 SDK and manuals, preserved project Git objects and historical build inputs; summarized from corrected C006 evidence.

Repo project names use lichee/... while working checkouts use longan/.... Resolve both through the manifest. The android_repo archive also supplies the documented Ubuntu build route. [E04] [E05]

Resolve paths from your own SDK_ROOT containing longan/ and .repo/.

All four fixed commits are readable in the preserved complete selected repositories. Their saved path lists match the commit trees, and 20 selected file blobs were checked. This was not a complete file-content audit of every working tree. [E01]

For the compared kernel and BSP pairs, older packed commits and vendor snapshot commits have identical tree IDs. A missing commit in a partial cache or a different commit ID alone does not establish missing supplier source changes. [E01] [E05]

2. Exact configuration binding

longan/device/config/chips/t736/configs/default/linux-5.15/dragonboard_defconfig

159754 bytes · SHA256
2fd95877a161adbadd70b95644ffdd3609df942dc9b458e98c0c4c843d6361d3

C006 read the file from the pinned T736 vendor commit and matched its bytes to the preserved working file, the decompressed running configuration and two historical UVC build inputs. C007 rechecked the preserved local evidence copy against the same length and digest. [E02] [E03]

Configuration identity is an input binding. Boot artifacts, compiler compatibility, the candidate kernel and browser behavior still require their own results. The full configuration is not included.

Proposed namespace fragment

CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_UTS_NS=y

The matched baseline already has CONFIG_NAMESPACES=y; USER_NS, PID_NS and UTS_NS are disabled. The proposed fragment has not been evaluated by Kconfig, built or installed. Record every derived configuration change. [E02] [E06]

3. Toolchain mapping and remaining gap

The Android default build.config.constants and its Clang value do not identify the compiler used for this Ubuntu kernel. The historical UVC script builds two media modules, so the next task needs a complete kernel workflow. [E01] [E02] [E04] [E05]

4. Manual page map

Physical PDF pages are one-based file pages. Printed pages are the numbers shown in the document. Summaries are provided here; original PDFs are not included.

The T736 manual is the specific selection reference. Its HDMI example is 1080p; C006 retained an accepted 1440p desktop baseline. Display presets and full-image flashing require an explicit current-artifact and recovery binding. [E04] [E06]

5. Reuse this map in the next work package

1. Verify and export the pinned source inputs. Use existing complete selected Git objects; compare each commit and tree with source-map.json, then export into a new work area.
   Expected evidence: Four commit/tree identities / Verified configuration digest / Source/export manifest
2. Bind the compiler and compatible Linux host. Inspect the named GCC 10.3 archive in the candidate prebuilt repository; record binary digest, version, executable architecture, loader and host dependencies. Preserve the source mapping and actual findings separately.
   Expected evidence: Compiler binary identity / Host environment manifest / Version and execution evidence
3. Bind the current boot and recovery artifacts. Associate the current kernel, board settings, DTB/DTBO, required modules and image packing inputs with the pinned sources. Define a recovery procedure for the actual system state before selecting display presets.
   Expected evidence: Boot/module artifact manifest / Display configuration comparison / Concrete recovery artifacts and procedure
4. Resolve baseline and namespace candidate configurations. Begin with the 159754-byte matching configuration. Use the SDK wrapper and selected toolchain to resolve the baseline and the proposed three-option fragment. Save the complete diff, including automatic dependencies.
   Expected evidence: Resolved baseline digest / Resolved candidate digest / All configuration differences
5. Build and inspect the full candidate kernel and modules. Use an isolated complete-kernel workflow. The historical UVC recipe builds two media modules and is not a complete kernel recipe. Produce a concrete candidate and recovery package for review.
   Expected evidence: Build logs and tool identities / Kernel and required module digests / Reviewed candidate and recovery package
6. Validate the deployed candidate under the agreed operating scope. After candidate and recovery review, validate startup, namespace sandbox behavior, a visible GNOME Web window, the three target pages, HDMI, LightDM and the existing MCP baseline. Record actual outcomes, including failures.
   Expected evidence: Boot and recovery evidence / Visible browser/page acceptance / Display/session/MCP regression results

Use existing manuals, complete Git objects, original archives and historical inputs first. Escalate a specific unresolved gap with evidence after these checks. [E06]

Open the machine-readable next work package

6. Source digests and provenance

Use these identifiers against your own authorized supplier assets. A matching digest identifies the bytes; it does not license redistribution or establish boot compatibility.

Supplier documents

Selected source files

This map does not grant redistribution rights for supplier assets. Obtain those assets through an authorized source and retain their applicable licenses.