Best long-term approach for converting a 47" RK3288 Android advertising display into a Shopify kiosk?
Post
I am converting an older 47-inch Android advertising display into a customer-facing Shopify and pre-order kiosk. I would appreciate opinions from people experienced with Rockchip boards, embedded Linux, digital signage, and industrial displays. Hardware Display model: BE-AD-AF47-IRT Type: 47-inch advertising/touch display Power supply: P160A Mainboard marking: RK3288_MID REV2.0 SoC: Rockchip RK3288 Architecture: ARMv7/armhf, not ARM64 RAM: 2 GB Samsung DDR3 Storage: approximately 8 GB Samsung eMMC Current OS: Android 5.1.1 Kernel: Linux 3.10.0, vendor build #609 Android hardware name: rk30board Android model/device: rk3288 Build type: userdebug ro.debuggable=1 ro.secure=1 Bootloader property reports “unknown” Loader timestamp in kernel command line: 2017-08-29 Wi-Fi module: AP6212 Ethernet: available RTC battery: present Recovery/reset button: present Connections Two USB-A host ports One damaged Micro-USB port, probably the original OTG/device port microSD slot Ethernet HDMI connector, but it is not yet confirmed whether this is input or output Internal display and backlight connectors UART pads on the underside marked GND, RX, TX and 3V3 No soldering equipment is currently available USB findings Both USB-A ports provide approximately 5.03–5.06 V. Both appear to be host-only ports. A USB-A-to-A data cable with a USB power blocker was tested. Neither USB-A port exposed Rockchip Loader Mode to a Windows PC. The broken Micro-USB port was probably the intended OTG/device connection. USB storage devices are detected normally by Android. Display Internal display connection appears to be LVDS. Resolution: 1920 × 1080 at 60 Hz The cabinet is physically portrait-oriented. Linux framebuffer: /dev/graphics/fb0 Pixel format reported by the Rockchip display controller: ARGB8888 Bits per pixel: 32 Stride: 7680 bytes Virtual framebuffer size: 1920 × 3240, apparently triple-buffered Linux Xorg fbdev output works. Correct portrait orientation is achieved using clockwise framebuffer rotation. Colors currently look somewhat pale and blue/cool. Rockchip BCSH values are at neutral defaults: brightness 128 contrast 256 saturation/contrast 256 hue neutral Contrast, saturation and per-channel gamma tests are being evaluated. Touchscreen USB HID touchscreen Reported name: SAMDE THEOE USB VID:PID: 1ff7:001d Linux event device: /dev/input/event2 Absolute X/Y range: 0–32767 Multitouch slots: 10 Touch works under Linux/Xorg. After portrait rotation, the correct mapping is: screen X = touch Y screen Y = inverted touch X Final touch calibration is accurate across the display. eMMC partition layout The device uses the old Rockchip partition style rather than a modern Android A/B layout. uboot → mmcblk0p1 misc → mmcblk0p2 resource → mmcblk0p3 kernel → mmcblk0p4 boot → mmcblk0p5 recovery → mmcblk0p6 backup → mmcblk0p7 cache → mmcblk0p8 kpanic → mmcblk0p9 system → mmcblk0p10 metadata → mmcblk0p11 userdata → mmcblk0p12 radical_update → mmcblk0p13 user → mmcblk0p14 Backup and recovery status Two complete eMMC readbacks were created. The preferred backup was split into four files and verified with SHA-256. Original boot, kernel, resource, DTB and recovery data were extracted and preserved. The original recovery partition was separately backed up and hashed. Several experimental recovery images were tested but did not boot correctly. The original recovery was restored and verified byte-for-byte afterward. Android currently boots normally. No Linux image has been written to the internal eMMC. Bootloader, boot partition and Android system remain unchanged. Methods that did not work Direct microSD boot Multiple RK3288/Armbian images were written and verified. The microSD card itself is readable by Android. The board still boots Android from eMMC. The likely causes are eMMC boot priority and a board-specific bootloader/DTB. The tested generic Armbian image did not start this custom board. Rockchip Loader Mode through USB-A Both USB-A ports were tested. Neither appeared as a Rockchip device on Windows. They are almost certainly host-only ports. UART UART2/ttyFIQ0 appears to be the serial console. Probable pins were identified: GPIO7_C6 = RX GPIO7_C7 = TX Pads are on the underside of the board. A reliable connection would require soldering or a pogo-pin fixture. 3V3 must not be connected to a USB-UART adapter; only GND, adapter RX and adapter TX would be used. Custom recovery route Test recovery images could be written and read back successfully. They produced a black screen and did not complete their SD-card test. The original recovery was restored. This route has been abandoned for now. What currently works We built a Debian 12 armhf root filesystem inside a 3 GB ext4 image stored on the microSD card. Android’s vendor kernel mounts the image through a loop device, then Debian runs in a chroot. This is not CPU virtualization: Debian processes run directly on the RK3288 kernel. Working components: Debian 12 armhf glibc 2.36 on the vendor 3.10 kernel Chromium 150 Xorg 1.21 fbdev video driver evdev touchscreen driver Openbox Ethernet/network access portrait display rotation accurate touch calibration Onboard virtual keyboard frameless Chromium app mode Shopify storefront in full-screen mode custom pre-order web application The Android UI can be stopped temporarily by stopping Zygote and SurfaceFlinger. Xorg then takes over the framebuffer. A watchdog restarts Android automatically after every test. The current setup successfully displays and operates: a custom touch-optimized pre-order web application product categories shopping cart quantities customer contact form age confirmation privacy consent virtual touch keyboard The custom pre-order application currently sends orders to its own POST /api/order endpoint. It explicitly uses payment at pickup after age verification. It is not yet connected to Shopify checkout or online payment. Performance observations Total RAM: approximately 2 GB Android had roughly 779 MB completely free during one measurement. Approximately 971 MB was being used as reclaimable filesystem cache. Visible Android processes consumed roughly 150–250 MB combined. When Android’s UI services are stopped, most resources are available to Debian and Chromium. Chromium currently uses software rendering because a usable Linux Mali acceleration stack has not yet been configured. Project requirements Shopify and the custom pre-order application real customer purchases or payment at pickup full-screen touch operation virtual keyboard automatic return to the start page after inactivity automatic advertising outside opening hours browser/session data cleared between customers no visible Android navigation automatic recovery if Chromium crashes reliable 24/7 operation later central administration rollback must remain possible Current strategic options Option A: Keep the existing RK3288 Use Android’s vendor kernel only as an invisible hardware and driver layer. Automatically mount Debian from the SD card, stop the Android UI and launch Debian/Xorg/Chromium. Advantages: Display, touch, Ethernet and USB already work. No bootloader replacement. Android remains available as a fallback. Low risk. Disadvantages: Old 3.10 vendor kernel. Only 2 GB RAM. No confirmed GPU acceleration in Debian. Requires a small Android bootstrap mechanism for automatic startup. Option B: Native Linux boot on the RK3288 Build a custom boot image using the original vendor kernel and DTB, then switch_root directly into Debian on the SD card or eMMC. Advantages: Cleaner native Linux boot. Removes the remaining Android userspace. Major risk: The Micro-USB OTG port is broken. USB-A does not provide Loader Mode. Generic SD boot does not work. If the replacement boot image fails, network ADB also disappears. Stock recovery rollback from a non-booting system has not yet been proven. Therefore writing the boot partition is currently considered unsafe. Option C: Replace the mainboard Possible replacement: Raspberry Pi 5 with 8 GB RAM and NVMe SSD Compute Module 5 with eMMC and carrier board Intel N100/N150 mini-PC The existing touchscreen should be reusable over USB. The remaining unknown is the LCD panel interface. If the cabinet has a real HDMI input, replacement is easy. If the panel is LVDS-only, the exact LCD panel model must be identified and a matching HDMI-to-LVDS controller must be used. Panel voltage, LVDS channel count, bit depth and backlight control must match exactly. Questions for the community Would you keep the working Android-kernel/Debian-chroot arrangement or replace the board? Is a Raspberry Pi 5 suitable for reliable 24/7 Chromium kiosk use, or would you prefer a Compute Module 5 or an x86 N100 system? Has anyone successfully booted native Linux on a custom RK3288_MID REV2.0 advertising board? Is there a safe boot-chain approach when OTG is broken and the board ignores generic microSD boot media? Is it worth trying to use the vendor Mali libraries from Android with Linux Chromium, or is software rendering the practical limit? What would be the safest way to identify and replace the LVDS controller? Are there any important privacy, session-reset or payment-security issues we should consider for a public Shopify kiosk? I can provide detailed board, connector, recovery and panel photos if useful. THANKS
Intent Score
2
Intent
99
Confidence
Summary
The post is about converting an Android advertising display into a Shopify kiosk, not about windows or window replacement.
Reasoning
This is clearly a software/embedded hardware and digital signage discussion with no meaningful connection to homeowner window problems, comparisons, or replacement considerations.
Extracted Signals
- software/hardware project
“I am converting an older 47-inch Android advertising display into a customer-facing Shopify and pre-order kiosk.”
- embedded systems focus
“people experienced with Rockchip boards, embedded Linux, digital signage, and industrial displays”
- display hardware details
“Hardware Display model: BE-AD-AF47-IRT”
Model: gpt-5.4-mini · Prompt: v3 · 8/10/2026, 5:01:42 PM