Jump to content

Brow Mosh

Members
  • Posts

    2
  • Joined

  • Last visited

Everything posted by Brow Mosh

  1. Yes @Nick A. Tried that also. Copilot mentioned this to me: 🟦 If you want to keep fighting this board… I can help you explore: - FEL mode flashing - Using the vendor Android recovery to write eMMC - Dumping the vendor kernel and trying to boot it - Porting the vendor MMC driver (very advanced) But I want to be honest with you: none of these paths are easy, and none guarantee success. Now, I asked it to elaborate on the idea: Let’s unpack this in a way that actually makes sense, Brow — because FEL sounds simple (“just plug in USB and flash it”), but on H618 TV boxes it becomes a whole different beast. I’ll keep it clean, structured, and honest. --- 🟦 Why FEL mode sounds easy On paper, FEL is Allwinner’s built‑in USB recovery mode: - You connect the box to a PC - Press a button or short two pads - The SoC enters FEL - You use sunxi-fel to upload U‑Boot or write eMMC In theory, it’s the “ultimate backdoor” for fixing a broken board. --- 🟥 Why FEL is complicated on your specific device Your Transpeed 8K618‑T is not a dev board. It’s a mass‑produced TV box with: - No FEL button - No exposed pads - No documentation - No schematic - No guarantee the USB port even supports FEL - Vendor boot ROM sometimes disables FEL - USB port may be wired through a hub or switch - Some boxes require opening the case and shorting tiny test pads - Some require holding reset while powering - Some require UART strap pins - Some require a special cable - Some simply do not support FEL at all So the first complication is: You don’t know how to enter FEL on this board. --- 🟥 Second complication: FEL only gives you RAM access FEL lets you: - Upload a U‑Boot binary into RAM - Execute it - Use that U‑Boot to access eMMC But here’s the catch: You must provide a U‑Boot binary that supports your hardware. Mainline U‑Boot does not support: - Your weird SD wiring - Your PMIC - Your DRAM timing - Your eMMC layout - Your HDMI - Your regulators Vendor U‑Boot does, but: - You don’t have the vendor U‑Boot binary - You don’t have the vendor DRAM init code - You don’t have the vendor MMC driver - You don’t have the vendor DTB So even if FEL works, you still need a working U‑Boot image to upload — and we don’t have one. --- 🟥 Third complication: writing eMMC through FEL is slow and fragile Even if you get FEL working and even if you get a working U‑Boot: - Writing eMMC over FEL is extremely slow - If the connection drops, you brick the device - You must manually partition eMMC - You must manually install boot0, boot1, U‑Boot, DTB, rootfs - You must manually fix extlinux.conf - You must manually fix environment variables This is not like flashing a Raspberry Pi. It’s more like doing open‑heart surgery with a butter knife. --- 🟥 Fourth complication: your board’s MMC subsystem is already unstable We’ve already seen: - SD card hangs - MMC controller wedges - Linux freezes on /dev/mmcblk* - Armbian initramfs fails - MiniArch freezes - Vendor kernel is the only thing that works If the MMC hardware is unstable under Linux, it may also be unstable under FEL‑booted U‑Boot. Meaning: Even if FEL works, you might not be able to write eMMC reliably. --- 🟦 So why did I say FEL is complicated? Because on a proper Allwinner dev board, FEL is easy. But on a cheap TV box with undocumented wiring, FEL becomes a puzzle with these problems: | Problem | Why it matters | |--------|----------------| | No FEL button | You don’t know how to enter FEL | | Unknown test pads | You may need to open the board | | Vendor may disable FEL | Some boxes block FEL in BOOT0 | | USB wiring unknown | FEL may not work on the exposed port | | Need vendor U‑Boot | Mainline U‑Boot won’t boot your hardware | | Need vendor DRAM init | Otherwise RAM won’t initialize | | Need vendor MMC driver | Otherwise eMMC won’t be writable | | MMC hardware unstable | Even FEL‑booted U‑Boot may hang | This is why FEL is not a magic fix here. --- 🟩 Could we try FEL anyway? Yes — if you want, I can guide you through: - Checking if FEL is available - Finding the FEL pads - Using sunxi-fel - Dumping BOOT0 - Dumping vendor U‑Boot - Rebuilding a hybrid U‑Boot - Flashing eMMC manually But I want you to understand the reality: It’s a research project, not a guaranteed solution. --- 🟦 If you want to try FEL, I can walk you through step 1 right now Step 1 is simple: Connect the box to your PC via USB‑A to USB‑A cable, then power it on. On your PC, run: ` sunxi-fel version ` If it prints something → FEL works. If it says “no device found” → we need to try hardware tricks. Just tell me if you want to go down this path.
  2. Hi guys. Just sharing my experience. After reading @Johan S success story, I bought a Transpeed 8K 4GB 64GB. (https://www.aliexpress.com/item/1005005534455685.html) Apparently, mine is different, and nothing, I've tried, worked. But sharing is caring, so here we go. 🧩 DEVICE SPECIFICATION & FULL FINDINGS SUMMARY 📦 Device Identity Model: Transpeed 8K618‑T (or clone variant) SoC: Allwinner H618 (sun50i‑h618 family) CPU: Quad‑core ARM Cortex‑A53 DRAM: 4 GB DDR3 PMIC: AXP1530 (BOOT0), AXP313 (BL31) Boot Chain: BOOT0 → BL31 → Vendor U‑Boot 2025 → Kernel 🧠 DRAM & Bootloader Behavior DRAM training succeeds at 648 MHz DRAM type: DDR3 DRAM size: 4096 MB Bootloader reports chip ID 0x2100 BL31 applies CPU errata 855873 & 1530924 Vendor U‑Boot loads: Kernel DTB Initrd (always) → cannot be disabled Vendor U‑Boot ignores Armbian boot scripts and forces initramfs boot 💾 STORAGE 1. SD Card Slot — NON‑STANDARD HARDWARE This is the root cause of all Linux failures. BOOT0 reports: card no is 2 → SD wired to MMC2, not MMC0 sdcard 2 line count 8 → 8‑bit bus width (SD normally max 4‑bit) MMC 5.1 → SD treated as eMMC, not SD Speed: 50 MHz (HSSDR52/SDR25) Vendor U‑Boot handles it Mainline Linux cannot Linux symptoms: sunxi-mmc ... data error send stop command failed lsblk hangs ls /dev/mmcblk* hangs Kernel freezes on MMC access Armbian drops to initramfs MiniArch boots but freezes shortly after Conclusion: The SD interface is electrically non‑standard and incompatible with mainline Linux. 2. eMMC Detected as /dev/mmcblk2 Stable under vendor bootloader Linux could use it — but SD instability prevents reaching userspace 🖥️ DISPLAY HDMI DDC errors: pinctrl_get for HDMI2.0 DDC fail tv_power failed Likely missing regulators in DTB HDMI output unreliable 🌐 NETWORKING Ethernet PHY: AC300 Should work under Linux if system boots Wi‑Fi: AIC8800 (doable. Android is rooted, so just copy '/aicsdio', 'aic8800_fdrv.ko' and 'aic8800_bsp.ko') 🧪 IMAGES TESTED Armbian Armbian-unofficial_25.05.0-trunk_Transpeed-8k618-t_bookworm_edge_6.12.11_server Armbian-20240726-unofficial_24.8.0-trunk_Transpeed-8k618-t_bookworm_edge_6.7.12_server Results: Always dropped to initramfs Could not mount /dev/mmcblk0p2 init=/bin/sh ignored (because vendor U‑Boot forces initrd) SD access hangs kernel No path to userspace MiniArch MiniArch-20240715-6.18.3-board-h618.transpeed-8k618-t-SD-Image MiniArch-20240715-6.18.3-board-h618.vontar_h618-SD-Image Results: Kernel boots Reaches userspace Shows login banner Then freezes due to SD/MMC errors lsblk and ls /dev/mmcblk* hang MiniArch boots further than Armbian, but still fails due to the same SD hardware issue. 🖧 UART TESTING Tried multiple UART speeds: 115200 (default) 921600 (Android kernel switches to this mid‑boot) Other speeds (varied) Findings: Vendor U‑Boot uses 115200 Android kernel switches to 921600, causing “garbage” output MiniArch & Armbian stay at 115200 UART is stable — not the issue 🧪 BOOT PARAMETER TESTING Tried: init=/bin/sh root=/dev/ram Removing root= Editing armbianEnv.txt Editing extlinux.conf Disabling overlays Changing DTBs Adding earlycon Adding rootwait Adding rootdelay=10 Findings: Vendor U‑Boot ignores Armbian boot parameters Always loads initrd → always enters initramfs init=/bin/sh never executed under Armbian MiniArch does honor init=/bin/sh, but MMC hangs prevent installation 🧨 ROOT CAUSE SUMMARY The device has non‑standard SD/MMC wiring: SD slot wired to MMC2 (normally eMMC controller) SD slot uses 8‑bit MMC mode SD slot uses MMC 5.1 protocol SD slot uses 50 MHz high‑speed timing Vendor kernel supports this Mainline Linux does not This causes: Armbian initramfs failures MiniArch kernel freezes MMC access hangs eMMC inaccessible No way to install Linux No way to reach userspace reliably This is a hardware design incompatibility, not a software bug. 🟩 FINAL ASSESSMENT The device is not compatible with mainline Linux, because: SD interface is wired incorrectly Vendor U‑Boot forces initramfs MMC controller hangs under mainline drivers eMMC cannot be accessed due to SD instability DTB regulators missing HDMI DDC errors (Wi‑Fi requires proprietary driver Android works because it uses the proprietary Allwinner MMC driver. Mainline Linux does not.) 🟦 Images
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines