improve doc for outputs and hardware

Changed my mind about "installer" as a first-class concept, at least
in the current implementation. Not every documented output is an
installer
This commit is contained in:
Daniel Barlow 2023-11-12 17:15:58 +00:00
parent 262efaabe6
commit f61e737b54
11 changed files with 133 additions and 45 deletions

View file

@ -6,17 +6,31 @@
This device is based on a 64 bit Mediatek MT7622 ARM platform, This device is based on a 64 bit Mediatek MT7622 ARM platform,
and is "work in progress" in Liminix. and is "work in progress" in Liminix.
The factory flash image contains ECC errors that make it incompatible .. note:: The factory flash image contains ECC errors that make it
with Liminix: you need to use the `OpenWrt UBI Installer <https://github.com/dangowrt/owrt-ubi-installer>`_ to rewrite the partition layout before incompatible with Liminix: you need to use the `OpenWrt
you can flash Liminix onto it (or even use it with "tftpboot", UBI Installer <https://github.com/dangowrt/owrt-ubi-installer>`_ to
if you want the wireless to work). rewrite the partition layout before you can flash
Liminix onto it (or even use it with
:ref:`system-outputs-tftpboot`, if you want the wireless
to work).
Hardware summary
================
- MediaTek MT7622BV (1350MHz) - MediaTek MT7622BV (1350MHz)
- 128MB NAND flash - 128MB NAND flash
- 512MB RAM - 512MB RAM
- b/g/n wireless using MediaTek MT7622BV (MT7615E driver) - b/g/n wireless using MediaTek MT7622BV (MT7615E driver)
- a/n/ac/ax wireless using MediaTek MT7915E - a/n/ac/ax wireless using MediaTek MT7915E
'';
Installation
============
Installation is currently a manual process (you need a :ref:`serial <serial>` conection and
TFTP) following the instructions at :ref:`system-outputs-ubimage`
'';
system = { system = {
crossSystem = { crossSystem = {

View file

@ -1,4 +1,4 @@
rec { {
system = { system = {
crossSystem = { crossSystem = {
config = "mips-unknown-linux-musl"; config = "mips-unknown-linux-musl";
@ -13,6 +13,9 @@ rec {
GL.iNet GL-AR750 GL.iNet GL-AR750
**************** ****************
Hardware summary
================
The GL-AR750 "Creta" travel router features: The GL-AR750 "Creta" travel router features:
- QCA9531 @650Mhz SoC - QCA9531 @650Mhz SoC
@ -22,28 +25,32 @@ rec {
- 16MB NOR Flash - 16MB NOR Flash
- supported in OpenWrt by the "ath79" SoC family - supported in OpenWrt by the "ath79" SoC family
As with many GL.iNet devices, the stock vendor firmware
is a fork of OpenWrt, meaning that the plain binary
``firmware.bin`` that Liminix builds can be flashed using the
vendor web UI and the U-Boot emergency "unbrick" routine
The GL-AR750 has two distinct sets of wifi hardware. The 2.4GHz The GL-AR750 has two distinct sets of wifi hardware. The 2.4GHz
radio is part of the QCA9531 SoC, i.e. it's on the same silicon as radio is part of the QCA9531 SoC, i.e. it's on the same silicon as
the CPU, the Ethernet, the USB etc. The device is connected to the the CPU, the Ethernet, the USB etc. The device is connected to the
host via AHB, the "Advanced High-Performance Bus" and it is host via `AHB <https://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_Architecture>`_ and it is
supported in Linux using the ath9k driver. The 5GHz support, on the supported in Linux using the ath9k driver. 5GHz wifi
other hand, is provided by a QCA9887 PCIe (PCI embedded) WLAN chip: is provided by a QCA9887 PCIe (PCI embedded) WLAN chip,
I haven't looked closely at the router innards to see if this is
actually physically a separate board that could be unplugged, but
as far as Linux is concerned it behaves as one. This is
supported by the ath10k driver. supported by the ath10k driver.
Installation
============
As with many GL.iNet devices, the stock vendor firmware
is a fork of OpenWrt, meaning that the binary created by
:ref:`system-outputs-flashimage` can be flashed using the
vendor web UI or the U-Boot emergency "unbrick" routine.
For flashing from an existing Liminix system (we believe that) it
is necessary to first boot into a :ref:`system-outputs-kexecboot`
system, otherwise you'll be overwriting flash partitions while
they're in use - and that might not end well.
Vendor web page: https://www.gl-inet.com/products/gl-ar750/ Vendor web page: https://www.gl-inet.com/products/gl-ar750/
OpenWrt web page: https://openwrt.org/toh/gl.inet/gl-ar750 OpenWrt web page: https://openwrt.org/toh/gl.inet/gl-ar750
''; '';
installer = "flashimage";
module = {pkgs, config, ... }: module = {pkgs, config, ... }:
let let
@ -95,7 +102,7 @@ rec {
FEATURE_DD_IBS_OBS = "y"; # ath10k_cal_data needs skip_bytes,fullblock FEATURE_DD_IBS_OBS = "y"; # ath10k_cal_data needs skip_bytes,fullblock
}; };
hardware = { hardware = {
defaultOutput = installer; defaultOutput = "flashimage";
loadAddress = "0x80060000"; loadAddress = "0x80060000";
entryPoint = "0x80060000"; entryPoint = "0x80060000";
flash = { flash = {
@ -145,9 +152,14 @@ rec {
url = "https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.15.71.tar.gz"; url = "https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.15.71.tar.gz";
hash = "sha256-yhO2cXIeIgUxkSZf/4aAsF11uxyh+UUZu6D1h92vCD8="; hash = "sha256-yhO2cXIeIgUxkSZf/4aAsF11uxyh+UUZu6D1h92vCD8=";
}; };
# Mainline linux 5.19 doesn't have device-tree support for
# this device or even for the SoC, so we use the extensive
# OpenWrt kernel patches
extraPatchPhase = '' extraPatchPhase = ''
${openwrt.applyPatches.ath79} ${openwrt.applyPatches.ath79}
''; '';
config = { config = {
ATH79 = "y"; ATH79 = "y";
PCI = "y"; PCI = "y";

View file

@ -25,6 +25,17 @@
- assuming we want to use the wireless - we need to build MTD - assuming we want to use the wireless - we need to build MTD
support into the kernel even if we're using TFTP root. support into the kernel even if we're using TFTP root.
Installation
============
The stock vendor firmware is a fork of OpenWrt, meaning that the
binary created by :ref:`system-outputs-flashimage` can be flashed
using the vendor web UI or the U-Boot emergency "unbrick" routine.
For flashing from an existing Liminix system (we think) it
is necessary to first boot into a :ref:`system-outputs-kexecboot`
system, otherwise you'll be overwriting flash partitions while
they're in use - and that might not end well.
Vendor web page: https://www.gl-inet.com/products/gl-mt300a/ Vendor web page: https://www.gl-inet.com/products/gl-mt300a/

View file

@ -13,10 +13,22 @@
GL.iNet GL-MT300N-v2 GL.iNet GL-MT300N-v2
******************** ********************
The GL-MT300N-v2 "Mango" is is very similar to the MT300A, but is The GL-MT300N-v2 "Mango" is is very similar to the :ref:`MT300A <GL.iNet GL-MT300A>, but is
based on MT7628 instead of MT7620. It's also marginally cheaper based on the MT7628 chipset instead of MT7620. It's also marginally cheaper
and comes in a yellow case not a blue one. It's different again and comes in a yellow case not a blue one. Be sure your device is
to the v1, which has only half the RAM. v2 not v1, which is a different animal and has only half as much RAM.
Installation
============
The stock vendor firmware is a fork of OpenWrt, meaning that the
binary created by :ref:`system-outputs-flashimage` can be flashed
using the vendor web UI or the U-Boot emergency "unbrick" routine.
For flashing from an existing Liminix system (we think) it
is necessary to first boot into a :ref:`system-outputs-kexecboot`
system, otherwise you'll be overwriting flash partitions while
they're in use - and that might not end well.
Vendor web page: https://www.gl-inet.com/products/gl-mt300n-v2/ Vendor web page: https://www.gl-inet.com/products/gl-mt300n-v2/

View file

@ -16,7 +16,7 @@ let
:ref:`system-outputs-${d.installer}` :ref:`system-outputs-${d.installer}`
'' ''
else ""; else "";
in (d'.description + installer)) in d'.description)
devices; devices;
in in
writeText "hwdoc" '' writeText "hwdoc" ''

View file

@ -12,7 +12,7 @@ Liminix
development development
modules modules
hardware hardware
installers outputs
Indices and tables Indices and tables

View file

@ -1,12 +1,12 @@
Outputs Outputs
####### #######
Liminix *outputs* are artefacts that can be installed or run somehow Liminix *outputs* are artefacts that can be installed somehow on a
on a target device, or "installers" which run on a target device target device, or "installers" which run on the target device to
to perform the installation. perform the installation.
There are different outputs because different target devices need There are different outputs because different target devices need
different artefacts or have different ways to get that artefact different artefacts, or have different ways to get that artefact
installed. The options available for a particular device are described in installed. The options available for a particular device are described in
the section for that device. the section for that device.

View file

@ -2,10 +2,18 @@
;; (local { : view } (require :fennel)) ;; (local { : view } (require :fennel))
(local outputs (collect [k v (ipairs arg)] (fn output? [option]
(values v true))) (match option.loc
["system" "outputs" & _] true
_ false))
(each [_ option (ipairs (yaml.load (io.read "*a")))] (fn sorted-options [options]
(when (. outputs option.name) (table.sort
options
(fn [a b] (< a.name b.name)))
options)
(each [_ option (ipairs (sorted-options (yaml.load (io.read "*a"))))]
(when (and (output? option) (not option.internal))
(print (.. ".. _" (string.gsub option.name "%." "-") ":") "\n") (print (.. ".. _" (string.gsub option.name "%." "-") ":") "\n")
(print option.description))) (print option.description)))

View file

@ -17,26 +17,42 @@ in
]; ];
options = { options = {
system.outputs = { system.outputs = {
# the convention here is to mark an output as "internal" if
# it's not a complete system (kernel plus userland, or installer)
# but only part of one.
kernel = mkOption { kernel = mkOption {
type = types.package; type = types.package;
internal = true;
description = '' description = ''
kernel
******
Kernel vmlinux file (usually ELF) Kernel vmlinux file (usually ELF)
''; '';
}; };
dtb = mkOption { dtb = mkOption {
type = types.package; type = types.package;
internal = true;
description = '' description = ''
dtb
***
Compiled device tree (FDT) for the target device Compiled device tree (FDT) for the target device
''; '';
}; };
uimage = mkOption { uimage = mkOption {
type = types.package; type = types.package;
internal = true;
description = '' description = ''
uimage
******
Combined kernel and FDT in uImage (U-Boot compatible) format Combined kernel and FDT in uImage (U-Boot compatible) format
''; '';
}; };
manifest = mkOption { manifest = mkOption {
type = types.package; type = types.package;
internal = true;
description = '' description = ''
Debugging aid. JSON rendition of config.filesystem, on Debugging aid. JSON rendition of config.filesystem, on
which can run "nix-store -q --tree" on it and find which can run "nix-store -q --tree" on it and find
@ -45,10 +61,10 @@ in
}; };
rootfs = mkOption { rootfs = mkOption {
type = types.package; type = types.package;
internal = true;
description = '' description = ''
root filesystem (squashfs or jffs2) image root filesystem (squashfs or jffs2) image
''; '';
internal = true;
}; };
}; };
}; };

View file

@ -20,18 +20,17 @@ in {
ubimage ubimage
******* *******
First-time installation of a UBIFS Liminix system presently can only This output provides a UBIFS filesystem image and a small U-Boot script
be done from the U-Boot command line (or from a ramdisk-based recovery to make the manual installation process very slightly simpler. You will
system: see "kexecboot" but we don't have detailed instructions for need a serial connection and a network connection to a TFTP server
this process yet). containing the filesystem image it creates.
These steps were tested on a Belkin RT3200 (also known as Linksys .. warning:: These steps were tested on a Belkin RT3200 (also known as
E8450). Other devices may be set up differently, so use them as Linksys E8450). Other devices may be set up differently,
inspiration and don't just paste them blindly. Consult the Liminix so use them as inspiration and don't just paste them
manual for how to connect a serial cable to your device and get into blindly.
U-Boot
1) determine which MTD device is being used for UBI and the partition name: 1) determine which MTD device is being used for UBI, and the partition name:
.. code-block:: console .. code-block:: console

View file

@ -17,11 +17,27 @@ in {
tftpboot = mkOption { tftpboot = mkOption {
type = types.package; type = types.package;
description = '' description = ''
Directory containing files needed for TFTP booting tftpboot
********
This output is intended for developing on a new device.
It assumes you have a serial connection and a
network connection to the device and that your
build machine is running a TFTP server.
The output is a directory containing kernel and
root filesystem image, and a script :file:`boot.scr` of U-Boot
commands that will load the images into memory and
run them directly,
instead of first writing them to flash. This saves
time and erase cycles.
It uses the Linux `phram <https://github.com/torvalds/linux/blob/master/drivers/mtd/devices/phram.c>`_ driver to emulate a flash device using a segment of physical RAM.
''; '';
}; };
boot-scr = mkOption { boot-scr = mkOption {
type = types.package; type = types.package;
internal = true;
description = '' description = ''
U-Boot commands to load and boot a kernel and rootfs over TFTP. U-Boot commands to load and boot a kernel and rootfs over TFTP.
Copy-paste into the device boot monitor Copy-paste into the device boot monitor