x11vnc and vncviewer for classroom
wmb at laptop.org
Mon Nov 24 13:06:22 EST 2008
scott at gnuveau.net wrote:
> Its not, but if one wants to boot some of the time as a thin client, and
> some of the time as as a standalone computer, then it becomes very handy.
> It also allows "thin-clientness" without altering the filesystem on the
> XO, preserving all the good work done on that software environment. What
> I was thinking of with the original question was the following scenario:
> An XO user runs the stock onboard software stack most of the time. The
> same user visits a location with an LTSP server. He wants to take
> advantage of the additional computing power available on that LTSP server,
> so he plugs into the ethernet, and boots disklessly as a LTSP thin client,
> w/o any reconfiguration necessary on his part, or any reconfiguration of
> the LTSP server. I happen to make solar powered LTSP servers that are
> being deployed in many of the same areas as the XO. I want to know what I
> need to support on the server side to allow this functionality. PXE
> requires no alteration to either system... hence my original question.
Network boot is part of the normal sequence but it's after the other
choices. The order is USB, then SD, then NAND, then USB wired
ethernet, and finally wireless LAN. The reason for that order is
because net boot is rarely used in our target customer scenario and the
act of checking for network connectivity is time consuming. On most OFW
systems, you could change that order simply by changing a configuration
variable in non-volatile storage, but on OLPC, that ability is disabled,
because I wanted the machine to really be like a "toaster" as far as the
firmware is concerned - no knobs to turn to the wrong setting, and
therefore no support calls resulting from incorrect settings.
But there is a solution. OFW boots by loading a Forth script name
/boot/olpc.fth . That script can be as short as a single "boot"
command, but normally it does a few other things such as setting the
Linux cmdline arguments to device-specific values (e.g. NAND booting
requires root=mtd0 rootfstype=jffs2) and perhaps checking for firmware
updates. That script can contain arbitrary Forth/OFW commands, so in
the general case it can do anything that you want.
You could modify /boot/olpc.fth on the NAND to perform some network
operation to determine whether to go the network boot route, and if that
operation fails, proceed with the normal "boot Linux from NAND" code.
One quick test would be to see if a wired USB ethernet adapter is
present; that can be done rather quickly, whereas actually going out
onto the network and doing a DHCP operation can take several seconds,
especially in the failing case where it has to retry several times.
As an alternative to TFTP, you could also load the file via HTTP. That
has advantages over TFTP in some network environments.
>> XO's OFW firmware can load kernels and initramfs's over either USB
>> Ethernet adapters or the built-in wireless, using TFTP or HTTP or NFS.
> OK, but that requires some user interaction with OFW, correct?
As indicated above, that interaction can be automated by adding it to
the /boot/olpc.fth script .
> You are saying that OFW can behave like PXE, by pulling a dhcp address via
> wireless then TFTPing a kernel/initrd? If so, that probably solves my
> problem, enumerated above.
It could be as simple as changing the boot-device configuration variable
in olpc.fth, the re-executing boot . But that would slow down the boot
in the non-network case. It would be better if you could find some
quick way to check.
Wireless net boot has several steps that are reasonably quick in the
"success" case, but rather long (due to timeouts and retries) in the
"fail" case, including:
* Downloading the wireless firmware to the WLAN chip (no timeout, but
takes a second or two)
* Scanning for and associating with an access point
* Interacting with a DHCP server
* Interactingn with a TFTP server
>> It's also possible to boot diskless with root on NFS. In fact that's
>> how the manufacturer runs their Linux-based burn-in diagnostics.
> LTSP uses a NBD for root filesystem in recent releases, iirc.
That would be up to the Linux kernel to take care of that. You might
have to set the cmdline properly or something in the olpc.fth script.
OFW can load from an NFS server, but that ability is not necessary. The
kernel and initramfs can be loaded from anywhere, then it can worry
about the root fs for itself.
>> What you can't do is run an absolutely stock distro, because you need a
>> kernel that supports the OLPC-specific hardware.
> Which devices in particular? Can these device drivers be merged into the
> upstream kernel tree, or are we still dealing with a binary blob
There is an effort to get everything upstream, but I'm not sure about
the status of that. There are several OLPC-specific devices - DCON,
CaFe NAND, some audio GPIO tweaks - plus startup tweaks for interacting
with the OFW device tree to get the system configuration, embedded
controller interaction for battery status, and fast non-ACPI power
The only binary blob component is the firmware for the wireless LAN module.
>> Devel mailing list
>> Devel at lists.laptop.org
More information about the Devel