| From: D. Hugh Redelmeier <[EMAIL PROTECTED]>
| I read what you wrote. I am surely not be the target audience, but it
| didn't give me much of value.
Besides being ungrammatical, this is rather blunt. I apologize.
Documentation is absolutely crucial yet creating it is often a
thankless task.
I owe David Farning a more constructive suggestion. Of course my
suggestion may be no better than his.
I'll take a stab at a possible approach:
================
State an assumed base of knowledge. Perhaps:
- the architecture of a linux desktop system.
- what role conventional hardware components play: CPU, RAM, disk,
buses (USB, SCSI, IDE), I/O devices (network, serial, video,
keyboard, printer).
- How these resources are abstracted in Linux
+ RAM is generally used to hold
* kernel code
* kernel data
* the state of running processes
+ disk-like resources are generally used for files.
Perhaps also swapping, but not often in OpenWrt.
+ networking devices have especially intricate functionality
+ other I/O: each different, but share some characteristics with a
file
- not so much, but it would be useful: how booting/initialization works
State how embedded platforms which OpenWrt might target differ. Note
that these are not absolute.
- modest hardware
- dedicated purpose (not general purpose)
- hardware often specialized for the purpose so many parts are
degenerate (eg. often no disk drive)
- software often specialized for the purpose so many parts are
degenerate (eg. no X)
- turnkey operation means that system must start and function without
supervision, and survive random power cycling.
- the platforms are very diverse (compared to PCs which all imitate
the IBM PC/AT). This mostly affects installation (flashing, for
example), booting, and initialization (including device discovery).
When you get down to it the differences are not fundamental, but they
are very real in practice.
I would then go onto a case study: OpenWrt on the Linksys WRT54GL.
[Note: all of this section is based on educated guesses.]
- enumerate hardware resources: CPU, flash, nvram, RAM, WAN ethernet,
LAN ethernet switch, I/O ports wired to lights and switch.
- enumerate firmware resources: loader(s) provided by manufacturer,
Linux kernel (stored in flash but booted into RAM), Linux disk-like
abstractions (initial ramdisk, root file system, both stored in
flash; I'm not sure if they are loaded into RAM), devices which
somehow get enumerated and /dev gets populated with nodes to access
them, the userland structure (from /) including daemons and things
they spawn. Some of this needs to be broken out into a separate
section.
- step-by-step of what happens on power-up
0) hardware reset causes most chips to initialize
== phase change: the platform boot loader takes over ==
1) the platform boot loader (in flash) starts running [I assume]
2) ??? the boot loader checks for boot_wait and may initiate a TFT
transfer & flash the flash. Then back to step 0
3) ??? the boot loader sets up a memory map for RAM and and I/O devices
4) the boot loader transfers the kernel code + initial ramdisk
contents from flash to RAM (this involves decompression)
and transfers control to the kernel
== phase change: kernel takes over & initializes ==
5) the kernel asks each of its device drivers to see if it can
recognize and initialize devices that it supports. There may be
an intermediary here: perhaps the kernel asks each of its bus
drivers to discover buses it supports, and within each bus,
devices are processed.
6) the kernel starts the userland process "init".
== phase change: userland takes over control ==
7) init is crafted to bootstrap (almost?) all of userland using the
mechanisms that the kernel provides
The system should now be in service. What it is doing is a function
of how it was configured.
- shutting down: traditionally this is accomplished by powering off
the power. A little dicy while data is being committed to
non-volatile media (flash, nvram, nfs mounts, (on other platforms)
USB devices. For traditional WRT54GL installations, such data is
limited to configuration and firmware upgrades (user is cautioned
not to pull the plug while flash is being written to).
Elaboration:
- description of the characteristics and function of the platform
bootloader
+ where it lives (first blocks of flash?)
+ out-of-box nvram contents
+ how it can be used to recover from certain classes of bricking
- description of how compressed kernel image, compressed initrd, and
squashfs or JFFS2 for / reside in flash
+ layout in flash
+ how they were put there
+ the firmware.bin top-level structure and how it gets built
- mention JTAG and what it has been used for by OpenWrt folks
- mention vestigial serial port and its uses
Branching out:
- how other targets differ. In particular, how OpenWrt must provide
for such differences
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
