x11vnc and vncviewer for classroom

[Mitch Bradley]

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
> somewhere?
>   

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 
management code.

The only binary blob component is the firmware for the wireless LAN module.

> Enjoy,
> Scott
>
>   
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>>
>>     
>
>