Tags give the ability to mark specific points in history as being important
-
v1.1
Release: chip-mainline v1.1eb59dca0 · ·chip-mainline v1.1 - the download can actually be flashed v1.0 shipped a rootfs and a kernel but no bootloader, so nothing in it could be written to a board without reproducing an undocumented U-Boot build first. The flashing guide also consumed rootfs.ubifs while the release published rootfs.ubi, and referred to two scripts that were not in the repository. This release publishes the whole boot chain, built in CI from a documented patch series against upstream U-Boot v2022.01, plus a flashing initramfs and a single-command flasher: sudo ~/chip-mainline/scripts/flash-release.sh ~/chip-release It verifies the download, boots a flashing system into the board's RAM over FEL, writes the rootfs, mounts it to confirm it worked, and only then writes the boot chain. --diagnose writes nothing at all and reports which boot stage is broken, for a board that used to boot and stopped. An earlier v1.1 tag was cut and withdrawn. Its devicetree carried mainline's dr_mode = "otg" on usb_otg, because the patch series had never captured the dr_mode = "peripheral" the development tree used. With "otg" the CDC gadget never binds: no ttyGS0, no usb0, over the same micro-USB port the board is powered from. That image booted and could not be reached by any documented route. patches/0003 fixes it; CI now asserts the property on the built DTB, not only in the source; and the fix has been confirmed on hardware by booting the released kernel with the corrected devicetree and watching the gadget enumerate. The kernel is otherwise unchanged from v1.0 - same configuration, same compiler, same hash-pinned Debian packages. Known: no end-to-end flash of a released image onto a board had completed when this tag was cut. Its components have each been exercised on hardware; the whole sequence has not. -
v1.0
Release: chip-mainline v1.008a05526 · ·chip-mainline v1.0 Mainline Linux 7.1.5 and Debian 13 on the NextThing C.H.I.P., booting standalone from the onboard NAND with working SSH, WiFi and Bluetooth. Three bugs stood in the way: 1. A mainline clocksource bug that silently kills the scheduler tick. timer-sun4i.c programs the timer interval with evt - TIMER_SYNC_TICKS and returns 0. On the clockevent core's forced minimum-delta path evt IS TIMER_SYNC_TICKS, so it writes zero, which never fires - and by reporting success it stops the core ever retrying. Interrupts keep being serviced, so the board still answers pings while no task is ever scheduled again, and every detector that would catch it is itself tick-driven. timer-sun5i.c has the identical defect. Not board-specific: this affects sun4i/sun5i generally, and these are the two patches proposed upstream. 2. NAND ECC strength. The flash was written at 56-bit; mainline's table says 40, which is the chip's datasheet minimum and correct as a requirement but not as a description of the medium. Fixed in the devicetree. 3. The SPL requires a mkimage-wrapped u-boot-dtb.img. Flashing the raw .bin puts a byte-perfect U-Boot in NAND that the SPL silently rejects. Verified on hardware: NAND rootfs (UBI/UBIFS), USB gadget ethernet and serial console, SSH, WiFi and Bluetooth (RTL8723BS, including pairing and SDP against a real speaker), DRM/lima, cedrus, MMC, NTP. Composite video is verified electrically but has not been confirmed on a display - see the README. Licensed GPL-2.0, as the vendor kernel it was compared against.