Re: [PATCH stable] libertas: Extend CMD_MESH_CONFIG to get and set persistent mesh default params.
On Fri, 2008-05-16 at 17:51 +0200, Stefanik Gábor wrote:
> On Fri, May 16, 2008 at 4:50 PM, Johannes Berg
> <[EMAIL PROTECTED]> wrote:
> > On Fri, 2008-05-16 at 15:09 +0100, David Woodhouse wrote:
> >> On Thu, 2008-05-15 at 11:01 -0700, Brian Cavagnolo wrote:
> >> > This patch is based on a patch from Shailendra Govardhan. It introduces
> >> > several new iwprivs: {get,set}_bootflag {get,set}_boottime
> >> > {get,set}_def_chan
> >> > {get,set}_def_protid {get,set}_def_metid {get,set}_def_meshcap
> >> > {get,set}_def_meshid. These commands are only supported on Marvell
> >> > hardware
> >> > that implements persistent defaults, such as the OLPC Active Antenna.
> >> > Accordingly, this patch may not be suitable for upstream merging.
> >
> >> But this is the _one_ thing which might actually be OK to do with a
> >> private ioctl, since it's very hardware-specific. Unlike like all the
> >> mesh-mangling stuff where we really ought to be compatible with o11s.
> >>
> >> So maybe, just maybe, we _can_ do this with iwpriv and push that
> >> upstream.
> >
> > Maybe we do, after all, need an iwpriv equivalent in cfg80211/nl80211 so
> > that we can kill wext at some point.
> >
> > Or maybe this should be in sysfs or so?
> >
> > johannes
> >
>
> Or maybe in configfs? That's a better place for configuration options.
> (BTW rt2x00 uses debugfs as an iwpriv replacement, so that's another
> possibility.)
I keep proposing debugfs too, but in some cases the commands aren't just
for poking around with stuff. configfs is probably a better answer to
tweakables that aren't just ricer-geekporn.
Dan
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Sun, 2008-05-18 at 20:48 +0100, David Woodhouse wrote:
> On Tue, 2008-05-13 at 15:38 +0100, David Woodhouse wrote:
> > > On an SMP host, are you sure we can't end up setting the multicast list
> > > simultaneously on the two logical devices?
> >
> > (A: No.)
>
> Try it like this... completely untested and hence probably broken in
> some stupid and minor way, but testing is something for tomorrow, not
> Sunday night when I'm supposed to be cooking dinner.
>
> We now merge duplicates from the two address lists while we're building
> the CMD_MAC_MULTICAST_ADR packet to send to the device, so we don't
> artificially limit each device to MRVDRV_MAX_MULTICAST_LIST_SIZE/2
> addresses. We'll go into allmulti mode only if the total number of
> addresses, excluding duplicates, exceeds the limit. Although I'm not
> wonderfully happy that we don't have any way of interrogating the
> firmware for its limit; what happens when we send more addresses than
> the firmware can cope with?
Is the firmware multicast address limit the same for every firmware from
5.0.x up to 9? Is it something that people with the firmware dev kit
can change with a recompile? Because if it changes between any of the
firmware revisions already out there (including for 8385 CF, 8686 SDIO,
8388 USB, etc) then we'll probably need a lookup table. I just hope the
different firmwares does something sensible when they get more than they
can handle?
Dan
> We also deal with the locking issues -- that we could be in
> lbs_set_multicast_list() for eth0 and msh0 simultaneously on two
> different CPUs -- by punting the actual work to a workqueue. Which can
> lock and use the multicast lists directly from each device, so we don't
> need our own copy of each.
>
> And it moves CMD_MAC_MULTICAST_ADR to a direct command, as we have been
> doing for all commands.
>
> Overall, it results in the net addition of five lines of code, instead
> of the 64 lines added by the previous version :)
> diff --git a/drivers/net/wireless/libertas/cmd.c
> b/drivers/net/wireless/libertas/cmd.c
> index 6328b95..2473ba8 100644
> --- a/drivers/net/wireless/libertas/cmd.c
> +++ b/drivers/net/wireless/libertas/cmd.c
> @@ -778,28 +778,6 @@ out:
> return ret;
> }
>
> -static int lbs_cmd_mac_multicast_adr(struct lbs_private *priv,
> - struct cmd_ds_command *cmd,
> - u16 cmd_action)
> -{
> - struct cmd_ds_mac_multicast_adr *pMCastAdr = &cmd->params.madr;
> -
> - lbs_deb_enter(LBS_DEB_CMD);
> - cmd->size = cpu_to_le16(sizeof(struct cmd_ds_mac_multicast_adr) +
> - S_DS_GEN);
> - cmd->command = cpu_to_le16(CMD_MAC_MULTICAST_ADR);
> -
> - lbs_deb_cmd("MULTICAST_ADR: setting %d addresses\n",
> pMCastAdr->nr_of_adrs);
> - pMCastAdr->action = cpu_to_le16(cmd_action);
> - pMCastAdr->nr_of_adrs =
> - cpu_to_le16((u16) priv->nr_of_multicastmacaddr);
> - memcpy(pMCastAdr->maclist, priv->multicastlist,
> -priv->nr_of_multicastmacaddr * ETH_ALEN);
> -
> - lbs_deb_leave(LBS_DEB_CMD);
> - return 0;
> -}
> -
> /**
> * @brief Get the radio channel
> *
> @@ -1279,8 +1257,7 @@ void lbs_set_mac_control(struct lbs_private *priv)
> cmd.action = cpu_to_le16(priv->mac_control);
> cmd.reserved = 0;
>
> - lbs_cmd_async(priv, CMD_MAC_CONTROL,
> - &cmd.hdr, sizeof(cmd));
> + lbs_cmd_async(priv, CMD_MAC_CONTROL, &cmd.hdr, sizeof(cmd));
>
> lbs_deb_leave(LBS_DEB_CMD);
> }
> @@ -1392,10 +1369,6 @@ int lbs_prepare_and_send_command(struct lbs_private
> *priv,
>cmdptr, cmd_action);
> break;
>
> - case CMD_MAC_MULTICAST_ADR:
> - ret = lbs_cmd_mac_multicast_adr(priv, cmdptr, cmd_action);
> - break;
> -
> case CMD_802_11_MONITOR_MODE:
> ret = lbs_cmd_802_11_monitor_mode(cmdptr,
> cmd_action, pdata_buf);
> @@ -1484,7 +1457,7 @@ int lbs_prepare_and_send_command(struct lbs_private
> *priv,
> ret = lbs_cmd_bcn_ctrl(priv, cmdptr, cmd_action);
> break;
> default:
> - lbs_deb_host("PREP_CMD: unknown command 0x%04x\n", cmd_no);
> + lbs_pr_err("PREP_CMD: unknown command 0x%04x\n", cmd_no);
> ret = -1;
> break;
> }
> diff --git a/drivers/net/wireless/libertas/cmdresp.c
> b/drivers/net/wireless/libertas/cmdresp.c
> index 5abecb7..4c3c5ec 100644
> --- a/drivers/net/wireless/libertas/cmdresp.c
> +++ b/drivers/net/wireless/libertas/cmdresp.c
> @@ -316,7 +316,6 @@ static inline int handle_cmd_response(struct lbs_private
> *priv,
>
> break;
>
> - case CMD_RET(CMD_MAC_MULTICAST_ADR):
> case CMD_RET(CMD_802_11_RESET):
> case CMD_RET(CMD_802_11_AUTHENTICATE):
> case CMD_RET(CMD_802_11_BEACON_STOP):
> @@ -376,8 +375,8 @@ static inlin
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Mon, 2008-05-19 at 12:05 +0100, David Woodhouse wrote: > On Mon, 2008-05-19 at 07:01 -0400, Dan Williams wrote: > > Is the firmware multicast address limit the same for every firmware from > > 5.0.x up to 9? Is it something that people with the firmware dev kit > > can change with a recompile? Because if it changes between any of the > > firmware revisions already out there (including for 8385 CF, 8686 SDIO, > > 8388 USB, etc) then we'll probably need a lookup table. > > If we can avoid a lookup table, that would be nice. Perhaps we could > list the MAC addresses after trying to set them, and see how many we get > back? Unless there's a better way... That wouldn't help if some version of firmware couldn't handle the case when it's given more than it's max (see below). > > I just hope the different firmwares does something sensible when they > > get more than they can handle? > > Like automatically going into ALLMULTI mode? That would be nice, but I > find it unlikely. No, like not bounds-checking the given list against an internal max value and overrunning a buffer, because it expects the driver to be bounds-checking the value and not giving it more than it can handle. That's probably not the case, but would be nice to have some confirmation that various firmware versions do handle this OK. If they do, then we can play some tricks like reading it back to see if they all get set correctly or whatnot. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 10:37 -0400, Michail Bletsas wrote: > [EMAIL PROTECTED] wrote on 06/03/2008 10:12:31 AM: > > > On Mon, 2008-06-02 at 17:12 -0700, Brian Cavagnolo wrote: > > > To update boot2, copy the boot2 and firmware images to /lib/firmware > and: > > > > > > echo > /sys/class/net/eth2/lbs_boot2 > > > echo > /sys/class/net/eth2/lbs_fw > > > > So why are we doing this with the driver, and not the userspace update > > tool? Marvell keeps wanting to do firmware update in the driver, and we > > (David and I at least) keep saying no. If there are issues that prevent > > the userspace firmware update tool from working, then we need to fix > > those issues. Firmware updates from the driver were a disaster the > > first time around, and I don't quite see how that may have changed this > > time? > > > > If you really want, the userspace tool can be rewritten in C. > > > It is not a matter of Python vs C. > The userspace tool is extremely awkward to use (since it requires the > driver modules to be unloaded which in turn makes the identification of How does it make the ID more difficult? What do we need besides the bcdDevice ID that tells us what boot2 version the device has? Is there something more needed to find out if the device has larger EEPROM for active antenna support perhaps? > devices on the XO even more difficult) and it bricks wireless modules > while the driver method doesn't. So the statement that "firmware updates > from the driver were a disaster" is simply not true. It bricks the modules because the only people with the access to the docs and firmware (Marvell) didn't try to debug the issue, or correct the tool. There's only so much _I_ can do without access to the firmware source itself if other people who have the info aren't really jumping on these problems, when I don't have the info. > This is low level hardware functionality that needs to be implemented in a > fail-safe manner. Out testing has showed that the driver/firmware method > (the driver just controls the memory updating code on the firmware) is > more robust than the userspace tool. The original issue was that the driver needed to be told how to flash using module parameters, which is just a non-starter. A dynamic, sysfs-based interface is quite a lot better; I'm willing to keep discussing that solution. But some questions: 1) is the interface extendable to flashing firmware on CF & SDIO 8385 and SD 8686 too? 2) does the patch handle resets and everything correctly, ie can I flash the firmware and then immediately start using the device? Can I also stop using the device and flash the firmware on-demand without unloading the driver? Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 11:18 -0400, John Watlington wrote: > On Jun 3, 2008, at 11:08 AM, David Woodhouse wrote: > > > On Tue, 2008-06-03 at 11:03 -0400, John Watlington wrote: > >> > >> My bad. This is now Trac #7170 > >> http://dev.laptop.org/ticket/7170 > >> > >> All of the information in this ticket comes from email exchanged with > >> dcbw and dwmw2 when I first discovered it. > > > > Didn't we fix that months ago by increasing the time we wait for > > flashing? Is this really what Ricardo was talking about? > > I think you are referring to same increased time that Dan mentions in > his comment ?I don't remember any discussion after that email > exchange (on Feb. 1, 2008). But then again, my memory is going... > > > He needs to be careful he doesn't get the same kind of reputation as > > Michail already has. We have enough people whose words need to be > > taken > > with a _large_ pinch of salt around here already. > > Let's keep the discussion professional, please. > > I was under the impression that there was one big difference between > the method > used in the driver and the userspace method. One uses the host > processor to > do the programming, and the other uses the ARM on the module. Nope. There is no difference. They both should send _exactly_ the same USB byte stream to the usb8388. If they do not, there is a bug. Unfortunately nobody at Marvell who actually _has_ documentation on how to flash for the active antenna and later boot2 firmware changes (if any) volunteered that information or tried to fix the tool, to my knowledge. I didn't have active antenna hardware myself, and therefore I can't risk bricking the _only_ usb8388 I have with random firmware that wasn't intended for my part. I'm happy to test this out and try to get the userspace tool working again if given: 1) one or more active antenna modules to potentially brick 2) documentation on what exactly has changed (if anything) between boot2 3107 and the active antenna boot2 firmware dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Mon, 2008-06-02 at 17:12 -0700, Brian Cavagnolo wrote:
> To update boot2, copy the boot2 and firmware images to /lib/firmware and:
>
> echo > /sys/class/net/eth2/lbs_boot2
> echo > /sys/class/net/eth2/lbs_fw
So why are we doing this with the driver, and not the userspace update
tool? Marvell keeps wanting to do firmware update in the driver, and we
(David and I at least) keep saying no. If there are issues that prevent
the userspace firmware update tool from working, then we need to fix
those issues. Firmware updates from the driver were a disaster the
first time around, and I don't quite see how that may have changed this
time?
If you really want, the userspace tool can be rewritten in C.
Dan
> Signed-off-by: Brian Cavagnolo <[EMAIL PROTECTED]>
> ---
> drivers/net/wireless/libertas/if_usb.c | 65
>
> 1 files changed, 65 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/if_usb.c
> b/drivers/net/wireless/libertas/if_usb.c
> index 91413a6..6a32f37 100644
> --- a/drivers/net/wireless/libertas/if_usb.c
> +++ b/drivers/net/wireless/libertas/if_usb.c
> @@ -46,6 +46,62 @@ static void if_usb_free(struct if_usb_card *cardp);
> static int if_usb_submit_rx_urb(struct if_usb_card *cardp);
> static int if_usb_reset_device(struct if_usb_card *cardp);
>
> +/* sysfs hooks */
> +
> +/**
> + * Set function to write firmware to device's persistent memory
> + */
> +static ssize_t if_usb_firmware_set(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t count)
> +{
> + struct lbs_private *priv = to_net_dev(dev)->priv;
> + struct if_usb_card *cardp = priv->card;
> + char fwname[FIRMWARE_NAME_MAX];
> + int ret;
> +
> + sscanf(buf, "%29s", fwname); /* FIRMWARE_NAME_MAX - 1 = 29 */
> + ret = if_usb_prog_firmware(cardp, fwname, BOOT_CMD_UPDATE_FW);
> + if (ret == 0)
> + return count;
> +
> + return ret;
> +}
> +
> +/**
> + * lbs_fw attribute to be exported per ethX interface through sysfs
> + * (/sys/class/net/ethX/lbs_fw). Use this like so to write firmware to the
> + * device's persistent memory:
> + * echo usb8388-5.126.0.p5.bin > /sys/class/net/ethX/lbs_fw
> + */
> +static DEVICE_ATTR(lbs_fw, 0200, NULL, if_usb_firmware_set);
> +
> +/**
> + * Set function to write firmware to device's persistent memory
> + */
> +static ssize_t if_usb_boot2_set(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t count)
> +{
> + struct lbs_private *priv = to_net_dev(dev)->priv;
> + struct if_usb_card *cardp = priv->card;
> + char fwname[FIRMWARE_NAME_MAX];
> + int ret;
> +
> + sscanf(buf, "%29s", fwname); /* FIRMWARE_NAME_MAX - 1 = 29 */
> + ret = if_usb_prog_firmware(cardp, fwname, BOOT_CMD_UPDATE_BOOT2);
> + if (ret == 0)
> + return count;
> +
> + return ret;
> +}
> +
> +/**
> + * lbs_boot2 attribute to be exported per ethX interface through sysfs
> + * (/sys/class/net/ethX/lbs_boot2). Use this like so to write firmware to
> the
> + * device's persistent memory:
> + * echo usb8388-5.126.0.p5.bin > /sys/class/net/ethX/lbs_boot2
> + */
> +static DEVICE_ATTR(lbs_boot2, 0200, NULL, if_usb_boot2_set);
> +
> /**
> * @brief call back function to handle the status of the URB
> * @param urb pointer to urb structure
> @@ -246,6 +302,12 @@ static int if_usb_probe(struct usb_interface *intf,
> usb_get_dev(udev);
> usb_set_intfdata(intf, cardp);
>
> + if (device_create_file(&priv->dev->dev, &dev_attr_lbs_fw))
> + lbs_pr_err("cannot register lbs_fw attribute\n");
> +
> + if (device_create_file(&priv->dev->dev, &dev_attr_lbs_boot2))
> + lbs_pr_err("cannot register lbs_boot2 attribute\n");
> +
> return 0;
>
> err_start_card:
> @@ -271,6 +333,9 @@ static void if_usb_disconnect(struct usb_interface *intf)
>
> lbs_deb_enter(LBS_DEB_MAIN);
>
> + device_remove_file(&priv->dev->dev, &dev_attr_lbs_boot2);
> + device_remove_file(&priv->dev->dev, &dev_attr_lbs_fw);
> +
> cardp->surprise_removed = 1;
>
> if (priv) {
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 11:34 -0300, Ricardo Carrano wrote: > On Tue, Jun 3, 2008 at 11:12 AM, Dan Williams <[EMAIL PROTECTED]> wrote: > > On Mon, 2008-06-02 at 17:12 -0700, Brian Cavagnolo wrote: > >> To update boot2, copy the boot2 and firmware images to /lib/firmware and: > >> > >> echo > /sys/class/net/eth2/lbs_boot2 > >> echo > /sys/class/net/eth2/lbs_fw > > > > So why are we doing this with the driver, and not the userspace update > > tool? Marvell keeps wanting to do firmware update in the driver, and we > > (David and I at least) keep saying no. If there are issues that prevent > > the userspace firmware update tool from working, then we need to fix > > those issues. Firmware updates from the driver were a disaster the > > first time around, and I don't quite see how that may have changed this > > time? > > A necessary rectification: > Firmware updates from the driver are the only method that works > currently. If we want to name one method a "disaster", we would have > to choose the userspace tool, since it will brick many of your active > antennae. It worked up until boot2 3109; and then apparently nobody at OLPC cared enough to fix the tool after that, and nobody at Marvell cared enough to tell anyone what changed so that somebody _could_ fix the tool. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 11:26 -0400, Dan Williams wrote: > On Tue, 2008-06-03 at 10:37 -0400, Michail Bletsas wrote: > > [EMAIL PROTECTED] wrote on 06/03/2008 10:12:31 AM: > > > > > On Mon, 2008-06-02 at 17:12 -0700, Brian Cavagnolo wrote: > > > > To update boot2, copy the boot2 and firmware images to /lib/firmware > > and: > > > > > > > > echo > /sys/class/net/eth2/lbs_boot2 > > > > echo > /sys/class/net/eth2/lbs_fw > > > > > > So why are we doing this with the driver, and not the userspace update > > > tool? Marvell keeps wanting to do firmware update in the driver, and we > > > (David and I at least) keep saying no. If there are issues that prevent > > > the userspace firmware update tool from working, then we need to fix > > > those issues. Firmware updates from the driver were a disaster the > > > first time around, and I don't quite see how that may have changed this > > > time? > > > > > > If you really want, the userspace tool can be rewritten in C. > > > > > It is not a matter of Python vs C. > > The userspace tool is extremely awkward to use (since it requires the > > driver modules to be unloaded which in turn makes the identification of > > How does it make the ID more difficult? What do we need besides the > bcdDevice ID that tells us what boot2 version the device has? Is there > something more needed to find out if the device has larger EEPROM for > active antenna support perhaps? > > > devices on the XO even more difficult) and it bricks wireless modules > > while the driver method doesn't. So the statement that "firmware updates > > from the driver were a disaster" is simply not true. > > It bricks the modules because the only people with the access to the > docs and firmware (Marvell) didn't try to debug the issue, or correct > the tool. There's only so much _I_ can do without access to the > firmware source itself if other people who have the info aren't really > jumping on these problems, when I don't have the info. > > > This is low level hardware functionality that needs to be implemented in a > > fail-safe manner. Out testing has showed that the driver/firmware method > > (the driver just controls the memory updating code on the firmware) is > > more robust than the userspace tool. > > The original issue was that the driver needed to be told how to flash > using module parameters, which is just a non-starter. A dynamic, > sysfs-based interface is quite a lot better; I'm willing to keep > discussing that solution. But some questions: > > 1) is the interface extendable to flashing firmware on CF & SDIO 8385 > and SD 8686 too? So this point is moot because the patch is only applicable to USB right now, and we don't have any USB devices other than 8388. The question below still stands though... Dan > 2) does the patch handle resets and everything correctly, ie can I flash > the firmware and then immediately start using the device? Can I also > stop using the device and flash the firmware on-demand without unloading > the driver? > > Dan > > > ___ > libertas-dev mailing list > [EMAIL PROTECTED] > http://lists.infradead.org/mailman/listinfo/libertas-dev ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 11:30 -0400, Michail Bletsas wrote: > [EMAIL PROTECTED] wrote on 06/03/2008 11:20:51 AM: > > > > > > > > A necessary rectification: > > > Firmware updates from the driver are the only method that works > > > currently. If we want to name one method a "disaster", we would have > > > to choose the userspace tool, since it will brick many of your active > > > antennae. > > > > It worked up until boot2 3109; and then apparently nobody at OLPC cared > > enough to fix the tool after that, and nobody at Marvell cared enough to > > tell anyone what changed so that somebody _could_ fix the tool. > > > Dan, > > The required functionality is a superset of what the userspace tool was > originally developed to do (update the boot2 code). > We now have a much bigger firmware blob to write to the EEPROM (besides > the boot2 code) and Marvell always felt that it is better for the ARM > processor on the wireless module to handle that task. That's fine, since there is no real difference in the flashing procedure between boot2 and normal firmware AFAICT, the tool should work with that firmware just fine. And a slight correction, but "better for the ARM processor" is wrong, because it's _always_ been the ARM updating the normal (ie non-boot2) firmware in this scenario, even if the userspace tool was doing it. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 13:49 -0400, Michail Bletsas wrote: > Dan Williams <[EMAIL PROTECTED]> wrote on 06/03/2008 01:20:11 PM: > > > On Tue, 2008-06-03 at 13:03 -0400, Michail Bletsas wrote: > > > Dan Williams <[EMAIL PROTECTED]> wrote on 06/03/2008 11:26:21 AM: > > > > > > > > > > > > > > > > > It is not a matter of Python vs C. > > > > > The userspace tool is extremely awkward to use (since it requires > the > > > > > driver modules to be unloaded which in turn makes the > identification > > > of > > > > > > > > How does it make the ID more difficult? What do we need besides the > > > > bcdDevice ID that tells us what boot2 version the device has? Is > there > > > > something more needed to find out if the device has larger EEPROM > for > > > > active antenna support perhaps? > > > > > > It makes it more difficult because instead of network interfaces > (eth0, > > > eth1 etc), one ends up having to deal with USB ids. > > > In devices with multiple intefaces (an XO with an active antenna for > > > example), that is very confusing. > > > > This is fair; except that the network interface name is subject to > > change and you can't guarantee that eth0 will always be the same device > > unless you use something like udev rules to rename devices on the fly > > when they are plugged in based on the device's MAC address, which > > requires loading the driver first. The kernel has never had a guarantee > > about device ordering. > > > > So if you _really_ want to make sure you're updating the right device, > > then you get Marvell to start putting real serial #s into the USB > > interface's serial number slot instead of 0. My usb8388 says: > > > > bcdDevice 31.02 > > iManufacturer 1 Marvell > > iProduct2 MARVELL Wireless Device > > iSerial 0 <- > > bNumConfigurations 1 > > > > that's the only way to guarantee that you're updating the device you > > want to update. > > > That's a good suggestion. > From a practical perspective though, in XOs, the onboard interface is > always eth0 these days. Yes, but I thought the discussion was more about active antenna updates, where you may have more than one usb8388, and thus you actually care about updating a specific adapter. In the normal XO case, you only have one usb8388, and thus the userspace flash tool will work just fine. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 13:03 -0400, Michail Bletsas wrote: > Dan Williams <[EMAIL PROTECTED]> wrote on 06/03/2008 11:26:21 AM: > > > > > > > > > It is not a matter of Python vs C. > > > The userspace tool is extremely awkward to use (since it requires the > > > driver modules to be unloaded which in turn makes the identification > of > > > > How does it make the ID more difficult? What do we need besides the > > bcdDevice ID that tells us what boot2 version the device has? Is there > > something more needed to find out if the device has larger EEPROM for > > active antenna support perhaps? > > It makes it more difficult because instead of network interfaces (eth0, > eth1 etc), one ends up having to deal with USB ids. > In devices with multiple intefaces (an XO with an active antenna for > example), that is very confusing. This is fair; except that the network interface name is subject to change and you can't guarantee that eth0 will always be the same device unless you use something like udev rules to rename devices on the fly when they are plugged in based on the device's MAC address, which requires loading the driver first. The kernel has never had a guarantee about device ordering. So if you _really_ want to make sure you're updating the right device, then you get Marvell to start putting real serial #s into the USB interface's serial number slot instead of 0. My usb8388 says: bcdDevice 31.02 iManufacturer 1 Marvell iProduct2 MARVELL Wireless Device iSerial 0 <- bNumConfigurations 1 that's the only way to guarantee that you're updating the device you want to update. > > > > > devices on the XO even more difficult) and it bricks wireless modules > > > while the driver method doesn't. So the statement that "firmware > updates > > > from the driver were a disaster" is simply not true. > > > > It bricks the modules because the only people with the access to the > > docs and firmware (Marvell) didn't try to debug the issue, or correct > > the tool. There's only so much _I_ can do without access to the > > firmware source itself if other people who have the info aren't really > > jumping on these problems, when I don't have the info. > > Marvell already has a working method. Are you suggesting that they are > obliged to support yours on top of theirs? They are obliged to work with the upstream community to find a solution that works for everyone, not just their customers. The solution they originally had didn't work for us (upstream or OLPC), and thus we developed the userspace flash tool. Now that CozyBit/Marvell have taken a different, better approach we can restart the discussions around it. Personally, I don't particularly care either way. The userspace flash tool does have some benefits, specifically that you don't have to load the driver before you flash the device, because the patch that's been posted will only allow the firmware to be flashed after the driver has been bound and potentially started the device, loaded the original firmware, and turned on the radio. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Mon, 2008-06-02 at 17:12 -0700, Brian Cavagnolo wrote:
> To update boot2, copy the boot2 and firmware images to /lib/firmware and:
>
> echo > /sys/class/net/eth2/lbs_boot2
> echo > /sys/class/net/eth2/lbs_fw
So by this point the driver has already sent BOOT_CMD_FW_BY_USB and
there's already a runtime firmware loaded on the device.
Am I correct in assuming that the runtime firmware implements _all_ the
same boot commands that the boot2 firmware does, including UPDATE_BOOT2
(flash new boot2 to EEPROM), FW_BY_USB (execute uploaded firmware but do
not flash), and UPDATE_FW (flash new runtime firmware to EEPROM)? Or
does the runtime firmware only support flashing, not re-executing itself
with FW_BY_USB?
Are there _any_ side effects of sending the boot command to a running
firmware? We didn't have to care about these before because the module
wasn't loaded, and when you were done flashing you were supposed to load
the module which would reset the card.
You'll need to grab priv->driver_lock before calling if_usb_prog_fw().
If you don't, anyone can issue WEXT commands or call 'ifconfig eth0 up'
and start inserting random commands into the command queue. I'm not
even sure grabbing priv->driver_lock will help you here, because the
firmware upload code was always executed _before_ there was a network
interface registered with the system, and thus doesn't need to do _any_
locking at all. So just grabbing priv->driver_lock doesn't necessarily
stop other USB commands from getting issued, though in practice since
you have to have priv->driver_lock held before grabbing a free cmd_node
from the driver core, this would stop the driver core from sending
commands during a firmware upload. So the behavior you'd get would be
that an iwconfig call would block until the firmware upload was
complete, then immediately send the pending command to the firmware.
Hence my question about side-effects above.
Does the loaded runtime firmware just write the new firmware to EEPROM
and then continue as normal? If so, I assume that the new firmware is
not expected to be active until (a) reboot, (b) USB port reset, (c) OLPC
EC-triggered reset, (d) CMD_802_11_RESET, or (e) hotplug of the active
antenna.
The code probably shouldn't allow updating the firmware if the battery
is low. Unfortunately, this isn't something that can or should be
stuffed into the driver, which is one great benefit of doing the update
in userspace. Second, you probably want to make sure that the system is
prohibited from entering the suspend state during a firmware update.
This is also probably better done via userspace. Obviously neither of
these two is implemented in the current userspace tool but they would be
nice, and not something that can be done from the kernel side in any
upstream-able manner.
Dan
> Signed-off-by: Brian Cavagnolo <[EMAIL PROTECTED]>
> ---
> drivers/net/wireless/libertas/if_usb.c | 65
>
> 1 files changed, 65 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/if_usb.c
> b/drivers/net/wireless/libertas/if_usb.c
> index 91413a6..6a32f37 100644
> --- a/drivers/net/wireless/libertas/if_usb.c
> +++ b/drivers/net/wireless/libertas/if_usb.c
> @@ -46,6 +46,62 @@ static void if_usb_free(struct if_usb_card *cardp);
> static int if_usb_submit_rx_urb(struct if_usb_card *cardp);
> static int if_usb_reset_device(struct if_usb_card *cardp);
>
> +/* sysfs hooks */
> +
> +/**
> + * Set function to write firmware to device's persistent memory
> + */
> +static ssize_t if_usb_firmware_set(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t count)
> +{
> + struct lbs_private *priv = to_net_dev(dev)->priv;
> + struct if_usb_card *cardp = priv->card;
> + char fwname[FIRMWARE_NAME_MAX];
> + int ret;
> +
> + sscanf(buf, "%29s", fwname); /* FIRMWARE_NAME_MAX - 1 = 29 */
> + ret = if_usb_prog_firmware(cardp, fwname, BOOT_CMD_UPDATE_FW);
> + if (ret == 0)
> + return count;
> +
> + return ret;
> +}
> +
> +/**
> + * lbs_fw attribute to be exported per ethX interface through sysfs
> + * (/sys/class/net/ethX/lbs_fw). Use this like so to write firmware to the
> + * device's persistent memory:
> + * echo usb8388-5.126.0.p5.bin > /sys/class/net/ethX/lbs_fw
> + */
> +static DEVICE_ATTR(lbs_fw, 0200, NULL, if_usb_firmware_set);
> +
> +/**
> + * Set function to write firmware to device's persistent memory
> + */
> +static ssize_t if_usb_boot2_set(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t count)
> +{
> + struct lbs_private *priv = to_net_dev(dev)->priv;
> + struct if_usb_card *cardp = priv->card;
> + char fwname[FIRMWARE_NAME_MAX];
> + int ret;
> +
> + sscanf(buf, "%29s", fwname); /* FIRMWARE_NAME_MAX - 1 = 29 */
> + ret = if_usb_prog_firmware(cardp, fwname, BOOT_CMD_UPDATE_BOOT2);
> + if (ret == 0)
> + return count;
>
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 13:09 -0400, Michail Bletsas wrote: > Dan Williams <[EMAIL PROTECTED]> wrote on 06/03/2008 12:09:11 PM: > > > On Tue, 2008-06-03 at 11:30 -0400, Michail Bletsas wrote: > > > [EMAIL PROTECTED] wrote on 06/03/2008 11:20:51 > AM: > > > > > > > > > > > > > > > > A necessary rectification: > > > > > Firmware updates from the driver are the only method that works > > > > > currently. If we want to name one method a "disaster", we would > have > > > > > to choose the userspace tool, since it will brick many of your > active > > > > > antennae. > > > > > > > > It worked up until boot2 3109; and then apparently nobody at OLPC > cared > > > > enough to fix the tool after that, and nobody at Marvell cared > enough to > > > > tell anyone what changed so that somebody _could_ fix the tool. > > > > > > > Dan, > > > > > > The required functionality is a superset of what the userspace tool > was > > > originally developed to do (update the boot2 code). > > > We now have a much bigger firmware blob to write to the EEPROM > (besides > > > the boot2 code) and Marvell always felt that it is better for the ARM > > > processor on the wireless module to handle that task. > > > > That's fine, since there is no real difference in the flashing procedure > > between boot2 and normal firmware AFAICT, the tool should work with that > > firmware just fine. > > > > And a slight correction, but "better for the ARM processor" is wrong, > > because it's _always_ been the ARM updating the normal (ie non-boot2) > > firmware in this scenario, even if the userspace tool was doing it. > > > > There has to be a real difference since the flashing code is in the > firmware which the userspace tool doesn't load, relying on whatever > support was originally in the boot2 code. There is support for flashing using either the MFG firmware images (.img files), or the chunked firmware files (.bin files). The MFG images are flashed by the runtime firmware, while the chunked format is flashed by the boot2 firmware. To flash Boot2 with an MFG firmware (which first loads the runtime firmware), you use the -m command to the flash tool like so: ./libertas-flash.py -m The current code appears to assume that an MFG flash will only flash boot2 firmware, and only supports runtime firmware update when the flashing is performed by boot2. It looks pretty easy to add support for MFG flashing of the runtime firmware, by the runtime firmware, since the support is already there for boot2 update by runtime firmware. Which brings us to Feb. I didn't understand exactly how the active antennas were supposed to get flashed, which (from your comments) looks to be a runtime firmware flash from the runtime firmware using BOOT_CMD_UPDATE_FW. I didn't have any active antennas at the time to test with nor firmware that would go on them. I also didn't have any details about exactly how the active antennas differed from the XO usb8388. Re-reading the comments in #7170 show Wad was trying to do a runtime-firmware update of the Boot2 code only, not a runtime firmware update of the runtime firmware. That had always worked on XOs, leading me to suspect some difference in hardware behavior between XO and active antenna. Dan > Because of the uniqueness of the active antenna's hardware, Marvell moved > the code that was specific to the active antenna flashing into the > firmware. If I remember correctly, the trend for the boot2 code is to make > it as small as possible and burn it into the device's ROM in the newer > devices. > > > M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 22:08 +0100, David Woodhouse wrote: > On Tue, 2008-06-03 at 11:28 -0400, Dan Williams wrote: > > I'm happy to test this out and try to > > get the userspace tool working again if given: > > Last time I knew, the userspace tool _was_ working. > > Although we'd stripped out the support from the kernel driver ages ago > and wrote libertas-flash.py, Michail for some reason told Marvell to put > it back into the driver instead of updating libertas-flash.py as they > should have done -- but we _fixed_ that back in January when I was in > Mongolia and had active antennae to update, didn't we? > > I'm a bit confused that we're having the same discussion _again_. Yeah, me too. But it doesn't look like the tool will update the runtime firmware from the runtime firmware, it'll only update the runtime firmware from the boot2 firmware. If they are indeed pulling the update capability out of future boot2 versions, then we'll need to update the tool to handle this. dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Setting up the mesh device
On Tue, 2008-06-24 at 19:42 +0100, Sjoerd Simons wrote: > Hi, > > I'm currently working on adding support for the olpc mesh device to NM 0.7. I feel sorry for you :) In some ways 0.7 has made it a lot better for you (concurrent device support) and in other ways it's made it a bit harder (more encapsulation of devices due to a well-thought-out object model). > From what i understand from David Woodhouse we should be able to really use > it as two seperated devices these days (with the obvious constraint that it > shares the radio ofcourse). Some testing shows that i can indeed use the mesh > while the eth0 is completely unconfigured. > > Now when configuring the msh0 device NM 0.6 does the following: >0. Set eth0 in ad-hoc mode >1. Set eth0's essid to olpc-mesh >2. Wait for an association event on eth0 >3. Continue with ip configuration. It was done on eth0 because at the time it was implemented, common attributes were defined to be set on ethX and were removed from mshX entirely. Due to discussions late last year, they got added back to the mshX interfaces, but there was no functional break and thus no need to update NM. You can now set the parameters directly on the mshX device. > Which makes me wonder about the following things: >* Why is the eth0 device set in ad-hoc mode? See above. Should need this any more, the mesh device should be set adhoc now instead. >* In what way is the olpc-mesh essid special for eth0? It's not, but setting an SSID is the way in WEXT that you say "do this all for me". So the card will technically not be set up how you want it until you set the SSID. You can simply set the SSID on the mesh interface now and not on the eth interface. >* What's the actual meaning of the association event on eth0 for the msh0 > and why should we wait on it. And if it's important, why is this event on > eth0 instead of msh0 ? You need to wait for the association event before going ahead with any additional configuration, because that's the signal that the firmware has joined the right IBSS and that it's set up to send and receive traffic. I don't know offhand if the firmware sends the association event on the mesh interface these days; it used to, and it should, if the SIOCSIWESSID command is done on the mesh interface. If it doesn't do this, then the driver should be changed to fix that and ensure that commands sent to the mesh interface return events there and not on ethX. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Setting up the mesh device
On Tue, 2008-06-24 at 18:09 -0400, Polychronis Ypodimatopoulos wrote: > Sjoerd Simons wrote: > > I'm setting the ESSID on the msh0 interface indeed. But i never get an > > association event on it.. While i even get an association event on eth0 when > > it's not up (but with msh0 being up obviously) :) Seems i've got some more > > bugs > > to file > > > > Why would you set an ESSID on the mshX interface in the first place? I > understand that, from a solid layering perspective, you should be able > to set essids on mshX since it's treated as a wireless interface, but it > would logically separate network users. It's hard enough as it is to > discover nodes in different channels (although different channels do > have a radio scaling advantage). You need a way to tell the firmware that you'd like to apply the configuration. And once you tell the firmware that, the firmware somehow needs to notify you that it's completed the requested operations. There is a small but noticeable amount of time between when you send the request, and when the firmware has completed the channel change and set up the state. If you don't wait for the notification, you'll assume you can send traffic when you actually cannot, and things like mDNS announcements and such will be lost. With WEXT, setting either the SSID or the BSSID are those triggers, and the SIOCGIWAP event is the notification. Unfortunately, because WEXT doesn't have a direct link between requests and replies, we have to enforce stricter semantics on behavior. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Setting up the mesh device
On Wed, 2008-06-25 at 02:34 +0100, Sjoerd Simons wrote: > On Tue, Jun 24, 2008 at 06:09:58PM -0400, Polychronis Ypodimatopoulos wrote: > > Sjoerd Simons wrote: > >> I'm setting the ESSID on the msh0 interface indeed. But i never get an > >> association event on it.. While i even get an association event on eth0 > >> when > >> it's not up (but with msh0 being up obviously) :) Seems i've got some more > >> bugs to file > > > > > Why would you set an ESSID on the mshX interface in the first place? I > > understand that, from a solid layering perspective, you should be able > > to set essids on mshX since it's treated as a wireless interface, but it > > would logically separate network users. It's hard enough as it is to > > discover nodes in different channels (although different channels do > > have a radio scaling advantage). > > Because we can? Seriously it's not for NetworkManager to decide this kind of > policy, some higher layer needs to tell it what to do. If that's the same > essid > for all machine that's fine (most likely the update sugar NM bits will just > have one essid hardcoded). The current wireless firmware might not even > actually bother with checking essid's on traffic all. The firmware's mesh functionality doesn't care what the SSID is. The only thing that distinguishes one mesh from another is the tuple of (channel, encryption). I don't even think BSSID matters (which it does in ad-hoc and infrastructure networks). Thus, the only policy that upper layers can or need to apply is the channel and encryption that the connection might use; hence why we eventually exposed the separate channels in Sugar. Dan > The more important part, like Dan explained, is that this is the way > to tell wireless drivers in linux to go and configure what's needed and tell > us > when they're ready for actual traffic (by means of an association event). So > we > can start doing things like dhcp and/or autoip. > > Sjoerd ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Creating / Importing Sugar bundles in Fedora environment
On Wed, 2007-05-30 at 22:40 +0200, Ludovic FERRE wrote: > Hello, > > I am running Sugar on a Fedora 6 emulated system. I found the Develop > activity on the Wiki (http://wiki.laptop.org/go/Develop) and wanted to > install it. > > I have copied the source with git, but I don't know how to register > the bundle with the sugar environment. I found sugar-install-bundle > but didn't manage to find any documentation on how to use (command > line args?). > > What should a software bundle look like (tar ball?) and how could I > install the Develop activity to run it? Are you using sugar-jhbuild? If so, you can unzip the bundle in build/share/activities dan > Thanks in advance, > Ludovic > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] eBook Reader user interface
On Tue, 2007-06-05 at 12:38 -0700, Don Hopkins wrote: > print "Hello world!" > > I have made a version of the Read activity that supports navigation > and control with the gamepad, and has a few new features and > improvements. > The main problem is getting the two gamepads to send unique keycodes > that are not the numeric keypad arrow keys it currently sends (because > those are already bound to functions that don't do the appropriate > thing). > The problem right now is that somebody needs to run the command "chmod > a+rwx /dev/input/event1" to give Python the permission to perform the > ioctl that remaps the keys. > The solution to that problem is to decide on a standard set of > keycodes and have the operating system set them when it boots. > I have tried several sets of keycodes, unsuccessfully. The higher > keycodes with numbers >512 never seem to make it to the X server. > I tried using the keycodes for the higher numbered function keys > (KEY_F13 [183] - KEY_F20 [190]), which made it to the X server, but > all report X keycodes 0. > There may be some magic that needs to be done in > the /etc/X11/xorg.conf file to admit those keycodes, or maybe some > other arcane X server configuration. > So for now I am mapping to the letters "esdx" and "ijkm" to test out > the gamepad code until the OLPC has a fixed set of distinguishable > keypad keycodes. > It will be very nice to have a gamepad text input method like > triggerfinger or dasher, to input real text in book mode! > > The next issue is rotation. I have made the activity respond to top > level window resize events by running "xrandr" to figure out which > direction the screen is rotated. I think the plan here is to have Sugar or the hardware manager send out events so that activities know when the screen is rotated. > Then it remaps the behaviors it assigns to the gamepads according to > the screen rotation. > I think screen rotation should be handled by the application, not the > operating system, because in some cases the application might want to > associate commands with the LABELS of the gamepad keys instead of the > DIRECTIONS of the keys, so it would not want to rotate their meaning. So basically, you mean not _rotation_ handled by the activity, but allowing the game button meanings to be specified by the activity depending on variables like rotation, right? > For example, a tic-tac-toe game that wanted to use X for X and O for O > would not want to remap the keys on screen rotation! (Admittedly > contrived, but hey it's a popular game!) c(-; > It would be great if there were a way to find out the screen rotation > via dbus. Maybe there is but I just haven't figured it out yet. Could > we add that, if it's not yet supported, please? Yes, that's the way it should work. > Also, I wrote some stuff in the comments of the bug about the screen > rotation button: it's way too easy to rotate the screen > accidentally (not to mention turn the machine off accidentally, > ESPECIALLY when the screen is upside down and you reach for what you > think is the rotation button!!!)... The power button functionality will be changed to put the machine to sleep rather than power off. We may have a 2-second timeout before it sleeps though, to alleviate this problem further. Note that it's the EC that dictates the 4-second poweroff when holding down the power button, and we can't change that behavior easily. We can make momentary presses of the power button, or holding it down up to 4 seconds, do anything we want fairly easily though. > I propose that both the screen rotation button and the power button > simply pop up big fat obvious dialogs that pop down and do nothing if Dialogs aren't the right solution here. > you press the button again, but require you to either press and hold > the button, or press another button (like the arrow keys) to actually > rotate the screen or power the system down. That's pretty indirect; I'd argue the more direct the better. The button has a rotation icon, and when you press it, it should rotate the screen. > That will let users rotate the screen absolutely in one shot with the > arrow keys without going through all the intermediate rotations. > Rotating is extremely expensive because it laboriously repaints the > entire screen, requiring the application to do all kinds of memory > allocation of giant page sized double buffers. So it should be very > hard to do it accidentally, while right now it's very hard not to do > it accidentally. This is not a problem with the B3 units and the LX processor, because the LX is (a) faster and (b) can accelerate resizes. It's so damn quick on the LX you'll be literally blown away after seeing it on a B1/B2. Obviously the activity has to redraw; but that should already be as fast as possible. > Of course the consequences of accidentally shutting the system down > with a mere press of the button are much worse, so the same thing goes > tenfold for the pow
Re: GEODE Power Saving
On Fri, 2007-06-08 at 15:51 +0100, Richard Hughes wrote: > Does the geode support frequency or voltage scaling? If so, how is this > communicated to userspace? But as I indicated in my other mail to your general power management query, we can turn off various components of the geode independently and save some power. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power Management
On Fri, 2007-06-08 at 14:51 +0100, Richard Hughes wrote: > OLPC now uses the olpc-hardware-manager python service to do power > management tasks. This is not really suitable for long term use, and we > can't easily do clever things with this infrastructure. Right; we'd pretty much decided that we should be moving most of the functions that control hardware to HAL callouts and just poking HAL to do things like this. Perhaps my idea of how all this should work is out of date :) > I'm proposing to use OHM (ohm.freedesktop.org) to do the clever things, > and apply system wide policy. OHM has working code, and I'm currently > preparing a package for olpc. I've got some time now I'm interning at > Red Hat (and now I've finished my exams...). I want to integrate this, > and hopefully have a kick-ass solution that is long-term supportable in > as little time as possible. > > OHM sits above HAL and lets HAL do the heavy lifting for reporting > events and doing actions. HAL is already packaged and being used for > OLPC. OHM is incredibly lightweight, and has a flexible compiled plugin > system for the rules, making it an ideal choice in my opinion. I wrote > most of the code, so consider my opinion very biased :-) > > I'm thinking about system power management interactions for the OLPC. So > far I've got: Just on the _display_ side we've got 4 orthogonal choices for power management, so things can be as fine-grained as we want: 1) Let DCON do the display refreshes a) when we do this, there is no point to have the Video Processor of the Geode on. So we can forcibly turn this off independent of the normal Geode sleep state. The Graphics Processor will notice this automatically and power itself down. b) Can put the Geode itself to sleep here 2) Turn panel refresh rate down from 50Hz to 25Hz (saves 60mW) 3) Backlight on/off/up/down 4) Panel itself on/off We also want to be _very_ aggressive about putting the system to sleep and waking it up on keypresses or mouse events. For example, the system should go to sleep whenever it's idle for more then a few seconds. The canonical case here is ebook mode; if you haven't pressed a button for a few seconds, make the DCON refresh the display and put the main CPU to sleep. Key presses will wake the machine up when you hit "page down". The motto is "sleep as often as possible". > • When system idle for > 10 seconds and on battery we dim screen to 40% > • When system idle for > 30 seconds we turn the screen off I assume here you mean "turn off backlight". > • When system idle for > 1 minute we suspend, assuming we have no > inhibits and CPU load is low This is way too laid-back. We should be suspending and letting the DCON refresh the display within a few seconds of going idle. A minute is really a long time. > • When AC removed reduce brightness by 20% > • When battery power < 10% turn of wireless Way too high a threshold here too. The wireless should be always on except when the machine is completely shut down. It should be maybe 2% or 3%, not 10. > • When battery power < 2% then shutdown > • When the lid is closed then turn off screen and suspend > • When battery power < 30% and not on AC then tell applications to use > low power mode (low quality video, only essential tasks) > • When the power button is pressed then save state and shutdown (we > probably should hibernate... can we do this yet?) No, the power button is the "suspend me" button. The only way of completely powering off is either (a) through the UI or (b) removing the battery. We'll never be doing suspend-to-disk/hibernate because there's just not enough flash. It's either suspend-to-ram or off. > • If we interrupt the screen dim or power-off, then the time to dim is > doubled (task) > • If we are inhibited (system update) we do not auto-suspend > • If the ambient brightness is very high (outside mode), switch the > panel into reflective mode Not sure we can detect this, even with a camera. We don't have a brightness sensor like some phones do, and the camera should only be on when it's needed by an activity (for security reasons). There are also hardware-connected LEDs that tell you when the camera and mic are on for specifically this reason. If the camera is on and no activity you're in is using the camera, there's something wrong. We may have to have some UI bits here or a keyboard combo to switch to reflective mode since it's very hard to autodetect when you want this or not. Dan > I've been talking much to cjb and dwmw2, and of course blizzard, and > they have given me much of the hardware information I need. > > Suggestions, feedback and cool feature ideas welcome, > > Thanks, > > Richard. > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listi
Re: Power Management
On Fri, 2007-06-08 at 11:14 -0400, Dan Williams wrote: > On Fri, 2007-06-08 at 14:51 +0100, Richard Hughes wrote: > > OLPC now uses the olpc-hardware-manager python service to do power > > management tasks. This is not really suitable for long term use, and we > > can't easily do clever things with this infrastructure. > > Right; we'd pretty much decided that we should be moving most of the > functions that control hardware to HAL callouts and just poking HAL to > do things like this. Perhaps my idea of how all this should work is out > of date :) > > > I'm proposing to use OHM (ohm.freedesktop.org) to do the clever things, > > and apply system wide policy. OHM has working code, and I'm currently > > preparing a package for olpc. I've got some time now I'm interning at > > Red Hat (and now I've finished my exams...). I want to integrate this, > > and hopefully have a kick-ass solution that is long-term supportable in > > as little time as possible. > > > > OHM sits above HAL and lets HAL do the heavy lifting for reporting > > events and doing actions. HAL is already packaged and being used for > > OLPC. OHM is incredibly lightweight, and has a flexible compiled plugin > > system for the rules, making it an ideal choice in my opinion. I wrote > > most of the code, so consider my opinion very biased :-) > > > > I'm thinking about system power management interactions for the OLPC. So > > far I've got: > > Just on the _display_ side we've got 4 orthogonal choices for power > management, so things can be as fine-grained as we want: > > 1) Let DCON do the display refreshes >a) when we do this, there is no point to have the Video Processor of > the Geode on. So we can forcibly turn this off independent of > the normal Geode sleep state. The Graphics Processor will notice > this automatically and power itself down. >b) Can put the Geode itself to sleep here > 2) Turn panel refresh rate down from 50Hz to 25Hz (saves 60mW) > 3) Backlight on/off/up/down > 4) Panel itself on/off > > We also want to be _very_ aggressive about putting the system to sleep > and waking it up on keypresses or mouse events. For example, the system > should go to sleep whenever it's idle for more then a few seconds. The > canonical case here is ebook mode; if you haven't pressed a button for a > few seconds, make the DCON refresh the display and put the main CPU to > sleep. Key presses will wake the machine up when you hit "page down". > > The motto is "sleep as often as possible". > > > • When system idle for > 10 seconds and on battery we dim screen to 40% > > • When system idle for > 30 seconds we turn the screen off > > I assume here you mean "turn off backlight". > > > • When system idle for > 1 minute we suspend, assuming we have no > > inhibits and CPU load is low > > This is way too laid-back. We should be suspending and letting the DCON > refresh the display within a few seconds of going idle. A minute is > really a long time. let me clarify here; this is somewhat activity dependent. Ebook, Web, Abiword, and text Chat are great cases for very aggressive suspend. But of course games are likely not. The sugar shell itself may also have different heuristics. We will have Wake On LAN functionality too so that, for example, if we're chatting with somebody, we can suspend the CPU and do DCON refresh when idle, and then get woken up when the other person sends an IM. dan > > • When AC removed reduce brightness by 20% > > • When battery power < 10% turn of wireless > > Way too high a threshold here too. The wireless should be always on > except when the machine is completely shut down. It should be maybe 2% > or 3%, not 10. > > > • When battery power < 2% then shutdown > > • When the lid is closed then turn off screen and suspend > > • When battery power < 30% and not on AC then tell applications to use > > low power mode (low quality video, only essential tasks) > > • When the power button is pressed then save state and shutdown (we > > probably should hibernate... can we do this yet?) > > No, the power button is the "suspend me" button. The only way of > completely powering off is either (a) through the UI or (b) removing the > battery. We'll never be doing suspend-to-disk/hibernate because there's > just not enough flash. It's either suspend-to-ram or off. > > > • If we interrupt the screen dim or power-off, then the time to dim is > > doubled (task) > > • If we are inhibited (system update) we do not a
Re: GStreamer issues
On Sun, 2007-06-10 at 04:24 -0400, Noah Kantrowitz wrote: > So I am working with the camera, trying to get it to dump to a PNG (or > anything else for that matter). My current problem is that I can't > reliably determine when it has finished the capture and has written to a > file. My gst pipeline is 'v4l2src ! ffmpegcolorspace ! pngenc ! filesink > location="/tmp/snap.png"'. I would think that MESSAGE_EOS would mean it > is done, but dumping the filesize at that point shows it is still 0 > bytes. Anyone have any ideas (other than shell out to gst-launch for > every capture)? Take a look at the "Camera" activity included on the machines. It has the ability to take snapshots. Dan > --Noah > > > plain text document attachment (signature.asc) > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGa55FA9fEp2eRsU8RAusKAJ95X/AvjQvAjvMe/f3a6A05XtEZMgCgj9ga > aXHAYoZdlvyQGTu6CQvjPiU= > =YRus > -END PGP SIGNATURE- > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: How to obtain serial number in linux
On Thu, 2007-06-21 at 13:48 +0800, David Woodhouse wrote: > On Thu, 2007-06-21 at 00:50 -0400, Ivan Krstić wrote: > > David Woodhouse wrote: > > > I remember a lot of noise and pointless paranoia, but no actual _mess_. > > > > A lot of noise and pointless paranoia over something with no practical > > benefits and plenty of abuse potential sure as hell qualifies as a mess > > in my book. There was a tremendous amount of consumer and media backlash > > including a request for a formal FTC investigation. > > Well, it was an Intel chip. Of _course_ it was a mess :) > > But 'consumer and media backlash' happens over a lot of pointless and > irrelevant things, while simultaneously _not_ happening in other > situations where it really should. Media fuss isn't really a good metric > of anything but media fuss. > > Are we going to hide MAC addresses too? I've heard some of the tinfoil > hat contingent witter about how those could lead the black helicopters > to you too¹. Good point, MAC address is available to anyone AFAIK. It's also a nice way of getting a constant UID (after hashing it of course). Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO in-field upgrades
On Mon, 2007-06-25 at 12:25 -0400, C. Scott Ananian wrote: > On 6/25/07, Christopher Blizzard <[EMAIL PROTECTED]> wrote: > > Most of the stuff that Alex has done is (carefully) independent of any > > vserver or container discussion. Specifically, the update system in > > question could be applied inside of a container as easy as it would be > > outside of the container. > > I not sure I agree that the filesystem portion of the implementation > ought to be completely independent of the network portion. I think > that networking desiderata are going to impact our choices among the > various upgrade schemes, and I'd prefer to have a high level design > for the whole thing before we get too attached to particular bits of > code. As one example, since network reliability goes down quickly as > message size increases, it seems (to me, at least) that our upgrade > data messages should be made as small as possible. It's not clear to > me that our current design minimizes upgrade transfer size. > > > Re: broadcast, that's basically the same as any laptop exposing presence > > information. For _transmission_ of an update, it's an interesting > > question as to whether or not to use a multicast update kind of thing. > > Do laptops usually wake each other up to process presence information? > [Hopefully not.] Should they do so for urgent security upgrades? > [Hopefully.] > > Here's a draft proposal: > We listen to multicast address foo:bar:xxx:xxx: if we > currently have version # n installed on the machine. Then we won't be > woken up by our friends announcing that they have version n like we > do, but we will be woken up as soon as someone gets version n+1. > > On 6/25 Alex L wrote: > > mDNS *is* multicast. But the blobs won't be exposed over mDNS, that is > > far to much data for a protocol like that. > > Really? Do we know that? What's a typical 0-day patch look like? > Have we tried to see how few bits it could be squashed into? No, stuffing actual update data into the mDNS TXT records is completely impractical. First off, you're limited by UDP packet size, and I'm sure our updates are going to be larger than 512 bytes (even with UDP packet sizes up to the MTU). mDNS never carries actual _data_, it carries a service description about the data. The data itself is always out-of-band WRT mDNS. Dan > > Binary diffs seem much less useful. They enforce a specific base version > > that you have to have around, and they enforce the direction of upgrade. > > This is *exactly* why we need to have the big picture view. My > understanding is that we *are* expecting all laptops to have identical > bases, that the upgrade propagation rate and upgrade (in)frequency > will be sufficient that all laptops will be running the same version > of the software (save for a few stragglers who go on a long trip for a > few weeks), and that the vserver copy-on-write mechanism will be used > to perform rollback (so that we only need to worry about the forward > direction). > > I'm not saying that my assumptions are correct. But I feel that > deciding file formats before we've come to a big picture consensus may > be premature. > > > If you can cheaply generate at runtime (on the client) a minimal diff > > between any two versions you can avoid storing unnecessary information, > > Not sure exactly what you're getting at here: that we transfer > complete blobs over the network but store them on the XO as binary > diffs? My working assumption is that network and storage costs on the > XO should be minimized as much as possible. Transferring complete > blobs fails on these grounds. > --scott > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[PATCH] xf86-amd-devel: fix lx Xv downscaling
Try #2.
diff --git a/src/amd_lx_video.c b/src/amd_lx_video.c
index e1e51aa..a4cd91b 100644
--- a/src/amd_lx_video.c
+++ b/src/amd_lx_video.c
@@ -365,6 +365,7 @@ LXDisplayVideo(ScrnInfoPtr pScrni, int id, short width,
short height,
unsigned long yExtra, uvExtra = 0;
DF_VIDEO_POSITION vidPos;
DF_VIDEO_SOURCE_PARAMS vSrcParams;
+ int err;
memset(&vSrcParams, 0, sizeof(vSrcParams));
@@ -401,16 +402,14 @@ LXDisplayVideo(ScrnInfoPtr pScrni, int id, short width,
short height,
/* Set up scaling */
df_set_video_filter_coefficients(NULL, 1);
-
- if ((drawW >= srcW) && (drawH >= srcH))
-df_set_video_scale(width, height, drawW, drawH,
- DF_SCALEFLAG_CHANGEX | DF_SCALEFLAG_CHANGEY);
- else if (drawW < srcW)
-df_set_video_scale(drawW, height, drawW, drawH,
- DF_SCALEFLAG_CHANGEX | DF_SCALEFLAG_CHANGEY);
- else if (drawH < srcH)
-df_set_video_scale(width, drawH, drawW, drawH,
- DF_SCALEFLAG_CHANGEX | DF_SCALEFLAG_CHANGEY);
+
+ err = df_set_video_scale(width, height, drawW, drawH,
+DF_SCALEFLAG_CHANGEX | DF_SCALEFLAG_CHANGEY);
+ if (err != CIM_STATUS_OK) {
+/* Note the problem, but do nothing for now. */
+ErrorF("Video scale factor too large: %dx%d -> %dx%d\n",
+ width, height, drawW, drawH);
+ }
/* Figure out clipping */
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH] xf86-amd-devel: fix lx Xv downscaling
On Mon, 2007-06-25 at 17:21 -0400, Bernardo Innocenti wrote: > Dan Williams wrote: > > Try #2. > > Does ti fix http://dev.laptop.org/ticket/1601 perhaps? _maybe_, but this was tested on Xorg 1.1.99, so there may be more stuff with 1.3 that's broken. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh network vs broadcast/multicast question
On Tue, 2007-06-26 at 15:22 +0200, Alexander Larsson wrote: > Hi dan, I have some questions on the mesh network for the updates work. > > What is the broadcast domain for a laptop on the mesh? (I.E. how far are > broadcast messages sent)? Is it just the set of nodes reachable from > your machine, or are broadcasts forwarded by the mesh? Michail? > This affects how avahi works, as avahi only uses local broadcasts. > > Another question is on multicasts. How many hops do multicast packets > live on the mesh? And are there any other limits than nr of hops to > avoid multicast loops? (Otherwise its likely that nodes see multicast > packages many times, especially in dense networks.) Michail? > I read on the olpc wiki about the mesh using three different channels. > My understanding on this is that these pretty much generate three > separate mesh networks that are routed between by the school server, and > that laptops can end up on any channel. Right. We have only one radio in the laptops, and therefore we can only tune to one channel at a time. However, having all laptops on one channel would be detrimental from a bandwidth perspective, since all laptops share the bandwidth of the channel, which isn't large (54Mbps but that's certainly not seen in the real-world). > Does this mean that two laptops next to each other can be on two > completely different networks? This means broadcasts (and by extension Yes. But if they are at school, then you'll be able to see that person because you'll both be connected to the school server. We only (ideally) run into problems when one or the other laptop can't connect to the school server, and they are on different channels. > Avahi) cannot reach from one laptop to the other. Is this true? And are > we doing something to work around this (like letting users manually > switch channels)? We are letting users manually "search" for friends, which is a fairly lengthy process that involves jumping to each channel, searching for friends and activities using mDNS, then to the next channel, etc. You'll be warned if you do something that will make you jump to a different channel, and therefore break stuff. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Ivan's XO Field Upgrade Proposal
On Tue, 2007-06-26 at 11:48 -0400, C. Scott Ananian wrote: > Ivan dropped by 1cc tonight, and I was able to squeeze the details of > *his* field upgrade proposal out of him. As I haven't yet seen him > email this to the list, I'll try to state it for him. Hopefully he > can then give a diff against my version, which will save him time. > > The XO already needs to "call home" to .laptop.org as part of > the antitheft system. In addition to the bits which tell it "you're > not stolen", the response also includes the version number of the > latest system software. I assume the version number is a simple > integer. > > If the laptop's version is not up to date, it tries to get the bits > from the school server. It it sees the school server, but the school > server doesn't have the bits (yet), it backs off a retries later. If > it doesn't have a school server, or the retry on the school server > fails, it gets the bits directly from Cambridge. > > The "get the bits" phase is as simple as practical: rsync. The school > server maintains a complete image of the XO filesystem, possibly in a > small number of versions. The XO just rsyncs with the school server > to get the updated files. This magically does the proper > binary-differencing thing, and is robust against connection failure, > data corruption, etc. If it can't get the bits from the school > server, it just rsyncs directly against a .laptop.org machine in > Cambridge. > > We use vserver copy-on-write to do the atomic upgrade. There is a > 'fake root' context (which i'll call /fakeroot here) which has all the > files in the filesystem. Activity containers & etc are created out of > /fakeroot. The upgrade process starts out with a copy-on-write clone > of /fakeroot, which it rsyncs to get the new filesystem. We then > either: > a) save this new tree as /upgraded-root (or some such) and on reboot > swap /fakeroot and /upgraded-root, or... > b) do some sort of pivot_root to swap these trees without rebooting. > This latter approach has more technical risk, but is still A Simple > Matter Of Software and permits live upgrades. > > Some notes: > a) rsync scales, as demonstrated by rsync.kernel.org. We can use > load-sharing, anycast addresses, etc if necessary (if it turns out > that very many laptops are not getting updates from a school server). > The important thing is that this complexity is on our side and is not > propagated to the XO software. > b) This completely punts on XO-to-XO upgrades. This complexity is > not necessary for version 1.0, and (given the efficient rsync > protocol) doesn't buy you all that much. It can be added later, > either via a different mechanism or by rsync between machines. > c) This proposal has no way to push upgrades. Again, this can be > added later (eg, a signed broadcast packet which says, "upgrade now to > version N". The actual upgrade is then identical.) > d) The filesystem can (should) contain a manifest, as described in > Alex's proposal, which is signed and can be used to > authenticate/validate the upgrade. The manifest is rsynced along with > the rest of the files, and then checked. We also use rsync-over-ssh > with fixed keys to ensure that we're only rsyncing with 'real' update > servers. > > Scott's comments (Ivan's not heard all of these, he might not agree): > a) I enthusiastically recommend this approach. It seems to be the > simplest thing with reasonable performance that will work. It avoids > reinventing the wheel, and it seems to have very few dependencies > which might break it. Improvements can be made to the rsync protocol > if better efficiency is desired, and that work will help not only OLPC > but also the (myriad) users of rsync. > b) For simplicity, I favor (re)using rsync in other places where we > need synchronization and/or file distribution. For example, I think > that the school servers use rsync in order to get their copies of the > XO filesystem. > c) No extra protocols or dependencies. rsync should be statically > linked. "School server doesn't have version N" should be read as > "rsync to school server fails", rather than involving some extra > protocol or query. I'd like to see the driver program written in a > compiled language and statically linked as well, to provide robustness > in case an upgrade breaks python (say). > e) The rsync protocol is interactive. There are more round-trips than > in other proposals, but the process is robust: if it fails, it can > just be restarted and it will magically continue where it left off. > f) We can "do better" than rsync, because we know what files are on > the other side, and can use this to send better diffs. This > improvement could be added to rsync directly, rather than creating > special XO-only code. (Option to preseed rsync with a directory of > files known to be on the remote machine.) > g) I believe that we can use "plain old" hard links when we do the > rsync, instead of requiring a
Re: Ivan's XO Field Upgrade Proposal
On Tue, 2007-06-26 at 12:16 -0400, C. Scott Ananian wrote: > On 6/26/07, Dan Williams <[EMAIL PROTECTED]> wrote: > > Downside of this is, as Alex pointed out, it'll load the mesh a _lot_ > > more than XO->XO updates. > > Not necessarily. Rsync is pretty efficient: we're still basically > distributing just (blockwise) diffs. And we can always do XO-to-XO > later: the important thing is to get a rock-solid basis. The selling > point (to me) is the simplicity. Like I said: its the simplest thing > that works. I'm not arguing simplicity; just that we have to be aware of the implications of having lots of XOs pulling from the server with some overlap with this method, but we don't with XO->XO. We just have to make the tradeoffs clear, and understand them. Dan > I can do some benchmarks if people actually need to see numbers. > --scott > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh network vs broadcast/multicast question
On Tue, 2007-06-26 at 16:07 -0400, Frank Ch. Eigler wrote: > Dan Williams <[EMAIL PROTECTED]> writes: > > > [...] We are letting users manually "search" for friends, which is > > a fairly lengthy process that involves jumping to each channel, > > searching for friends and activities using mDNS, then to the next > > channel [...] > > Does this mean that one needs a school server/bridge in order to talk > to two differently-channeled friends ? Yes. You must spread the XOs between channels to maximize the overall system bandwidth, but you can't directly talk to people on different channels because only have one actual radio. Most places have APs connected with ethernet on the backhaul, and so in the office or wherever, they are already bridging between wired & wireless for you. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh network vs broadcast/multicast question
On Tue, 2007-06-26 at 17:10 -0400, Frank Ch. Eigler wrote: > Hi - > > On Tue, Jun 26, 2007 at 04:49:40PM -0400, Dan Williams wrote: > > [...] > > > Does this mean that one needs a school server/bridge in order to talk > > > to two differently-channeled friends ? > > > > Yes. You must spread the XOs between channels to maximize the overall > > system bandwidth [...] > > Is it obvious that this benefit (increased aggregate bandwidth) is > worth the cost (the necessity for a special bridge - possibly > hamstringing an ad-hoc mesh away from the schoolhouse)? How > bandwidth-hungry are common XO activities anyway? It depends, but packing 50 normal laptops onto a single radio channel _today_ with infrastructure APs doesn't really work well, especially when they all start to talk. We're likely to have that many laptops in a single classroom, and when you get a couple classrooms next each other... Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh network vs broadcast/multicast question
On Wed, 2007-06-27 at 15:18 +0200, Alexander Larsson wrote: > On Tue, 2007-06-26 at 11:34 -0400, Michail Bletsas wrote: > > The key point to remember in order to derive answers to these questions is > > that our mesh network operates at layer-2 > > For all practical purposes, there aren't any differences between broadcast > > and multicast frames and every node maintains a table of recently > > forwarded broadcast frames so that they are not broadcasted multiple > > times. > > > > One can limit the radious of the (layer-2) neighborhood be means of > > controlling the Mesh TTL field. > > That is a global setting though, and not something we want applications > to touch. > > Is there a way for a program to figure out which of a list of ip > addresses are neighbours in the mesh (i.e. 1 hop away)? Some combination of the ARP cache and the forwarding table from the firmware would probably be able to give us that information. For each node that is 1 hop away in the fowarding table, check the ARP cache and grab the IP address. '/sbin/iwpriv msh0 fwt_list' gives you the FWT info, though the fields are a bit hard to discern unless you've got the driver source. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: System update spec proposal
On Wed, 2007-06-27 at 17:42 +0200, Alexander Larsson wrote:
> On Tue, 2007-06-26 at 15:03 -0400, Mike C. Fletcher wrote:
>
> > My understanding here is that Alex's system is currently point-to-point,
> > but that we don't yet have any way to distribute it on the mesh? That
> > is, that we are looking at a research project to determine how to make
> > it work in-the-field using some form of mesh-based discovery protocol
> > that's going to try to optimise for connecting to local laptops. I
> > personally don't care which way we distribute, but I'm wary of having to
> > have some mesh-network-level hacking implemented to provide discovery of
> > an update server.
>
> I'm not sure what you mean here exactly. Discovery is done using avahi,
> a well known protocol which we are already using in many places on the
> laptop. The actual downloading of file uses http, which is a well known
> protocol with many implementations.
>
> The only thing i'm missing atm is a way to tell which ip addresses to
> prefer downloading from since they are close. This information is
> already availible in the mesh routing tables in the network driver (and
> possibly the arp cache), and its just a question of getting this info
> and using it to drive what servers to pick for downloading.
So, like michail said, do something like:
n = 0
while (True) {
buf = output of (iwpriv msh0 fwt_list_neigh n)
if (buf == "(null)")
break; // all done
hwaddr = parsed[0] // Grab the 'ra' field (1st one)
ip4addr = lookup_hwaddr_in_arp(hwaddr)
n++;
}
Look on the 'olpc' branch of the libertas driver here:
http://git.infradead.org/?p=libertas-2.6.git;a=blob;f=drivers/net/wireless/libertas/README;hb=olpc
http://git.infradead.org/?p=libertas-2.6.git;a=blob;f=drivers/net/wireless/libertas/ioctl.c;hb=olpc
The README has a description of the command, and the ioctl.c has the
implementation. Just search for the string "neigh" and you'll find it.
Dan
> > > Basically aside from the vserver bits, which no one has seen, I don't
> > > see a particular advantage to using rsync. In fact, I see serious
> > > downsides since it misses some of the key critical advantages of using
> > > our own tool not the least of which is that we can make our tool do what
> > > we want and with rsync you're talking about changing the protocols.
> > >
> > Hmm, interestingly I see "using our own tool" as a disadvantage, not a
> > huge one, but a disadvantage nonetheless, in that we have more untested
> > code on the system (and we already have a lot), and in this case, in a
> > critical must-never-fail system. For instance, what happens if the user
> > is never connected to another XO or school server, but only connects to
> > a (non-mesh) WiFi network? Does the mesh-broadcast upgrade discovery
> > protocol work in that case?
>
> Avahi works fine for these cases too. Of course, since it was originally
> created for normal networks. However, if you never come close to another
> OLPC machine, then we won't find a machine to upgrade against. Its quite
> trivial to make it pull from any http server on the net, but that has to
> be either polled (which I don't like) or initiated manually (which might
> be fine).
>
>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: object store apis
On Thu, 2007-06-28 at 13:59 -0400, SJ Klein wrote: > Hello all, > > Thibaut is the author of meshboard.xo [1], a mesh community-board app that > currently (as a hack) uses its own xml-rpc server in each instance to send > messages to others running the activity. > > Ryan Trinkle is interested in working on message passing and discovery of > small pieces of content over the network -- items on a community board, or > selections from a set of wiki articles that a group is sharing. Copying > Lenny Foner who's been involved in related discussions. > > What's the right way for activities like meshboard to pass posts or > updates? Where should feedback about the object store API or desired > API go? Tubes, most likely. Given the activity ID, everyone should be able to reconnect to the same tube and then meshboard would sync stuff amongst each buddy's instance. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Upgrades and image manifests
On Tue, 2007-06-19 at 14:39 +0200, Alexander Larsson wrote: > Hi, > > My name is Alexander Larsson, and I just started working on the field > upgrade system of the olpc laptops. I have some ideas I'd like to > explain and get feedback on. > > The olpc uses a full-image system, as opposed to the per-package > versioning scheme of deb or rpms. So, an upgrade consists of replacing > your system files with a full copy of a later (or earlier) version of > the system image. We want to support both upgrading from a central > server or from another laptop, and we want to minimize the data we have > to download for an upgrade. > > To support this we create a manifest that describes each image, and we > save a copy of the current image manifest installed on the laptop. The > manifest format is very similar to the git "tree" object, and describes > each file by listing name, metadata and sha1 hash value of the contents. > > Here is a small example: > - > link 777 500:500 foo bar > blob 664 500:500 4e1243bd22c66e76c2ba9eddc1f91394e57f9f83 changed.txt > blob 664 500:500 65ef9261ad6cfaa8403f2fa66d8edfada1445e5a common > blob 664 500:500 f660633c832712eba3c6edd39151987e46bc3f87 image1.txt > blob 711 500:500 empty logfs.pdf > dir 775 500:500 subdir1 > blob 664 500:500 empty subdir1/file1.txt > blob 664 500:500 7448d8798a4380162d4b56f9b452e2f6f9e24e7a subdir1/file2.txt > --- > > Given a manifest for the current image and a manifest for the image to > upgrade to it is very simple and cheap to calculate what changes you > need to make to transform the image (on the client), and what sha1 blobs > you need to download. You can then download the file blobs from whatever > source you have (they are self-verifying, since they are named by the > sha1 hash of the content) and do the upgrade. Two questions here: 1) what does the scheme do in the case where the file it's about to replace on the local machine isn't the same as what the manifest on the local machine says? ie, local changes have changed the sha1 hash of the local file. That's essentially a policy decision, do we replace when there are local changes or don't we. A %config-type thing could work here to mark files that you may/may not always want to replace. 2) After downloading a blob, I assume the tool sha1s the downloaded file to ensure that it's content matches the name, right? > It is very simple to host the blobs. We just put them all in a directory > named by sha1 and export that with a http server. One can also host > multiple versions of an image in the same directory, while minimizing > the space used for common data. (Possibly one might want to gzip the > blobs too.) > > I've written some code (attached) to generate and manipulate manifests > like these. There are three tools: > > * generate-manifest: This generates a manifest files given a path to a > directory containing the image tree. You can also make it populate a > directory of sha1-named blobs by giving it a blob directory with -b. > > * diff-manifest: Gives a simple visual diff between two manifests. If > you pass it -b it will instead give a list of all blobs required to > update between the two manifests. > > * upgrade-manifest: Updates an image from one manifest to another, given > a path of a directory with the required blobs. > > Using these tools I upgraded from > olpc-redhat-stream-development-build-406-20070507_2141-devel_ext3-tree > to olpc-redhat-stream-development-build-406-20070507_2157-ext3-tree in a > directory on my development machine, so it seems to work so far. > > For finding and downloading updates I was thinking of using avahi to > publish the image id + version, and then downloading the data and > manifests using http. That way that clients can detect machines around > them with later versions and auto-download (and apply automatically or > later). The individual laptops can publish the version of the image they > are using, and a school server can publish several versions. From the > point of view of the individual laptop searching for upgrades they will > look the same. Of course, we'd have to sign the manifests with some key > to make sure you can't just auto-upgrade any machine to a rouge image. > > Now over to the questions I have: > > I'd like to put this code in a repository somewhere. Where should I put > it? > > Does OLPC use selinux or xattrs? Because if so we have to extend the > manifest format. > > We need a library to do http downloads. I see we're shipping libcurl on > the laptop. Is it ok to use this library? Yeah, though the ironic thing just occurred to me that libcurl is (along with Mozilla) one of the more frequently updated pieces of a linux distro :) > (We also need a very simple http sever that maps sha1 -> file in system > image for laptop-to-laptop upgrades, but I think we can do that without > using a library.) "simple" means lighttpd in my mind, but apache has a longer track record. > Is usi
Re: Upgrades and image manifests
On Fri, 2007-06-29 at 14:21 +0200, Alexander Larsson wrote: > On Fri, 2007-06-29 at 08:22 -0400, Dan Williams wrote: > > Two questions here: > > > > 1) what does the scheme do in the case where the file it's about to > > replace on the local machine isn't the same as what the manifest on the > > local machine says? ie, local changes have changed the sha1 hash of the > > local file. That's essentially a policy decision, do we replace when > > there are local changes or don't we. A %config-type thing could work > > here to mark files that you may/may not always want to replace. > > At the moment it only touches the files that are affected by the diff in > the manifest. If a file wasn't changed in the manifests we don't even > look at it. However, if the file we're replacing has changed locally, we > currently throw that away. > > > 2) After downloading a blob, I assume the tool sha1s the downloaded file > > to ensure that it's content matches the name, right? > > Yeah, or rather, while downloading. > > > > We need a library to do http downloads. I see we're shipping libcurl on > > > the laptop. Is it ok to use this library? > > > > Yeah, though the ironic thing just occurred to me that libcurl is (along > > with Mozilla) one of the more frequently updated pieces of a linux > > distro :) > > I ended up using urllib2 in python. Right, python too :) If we get a factory python process (didn't we have one at one point?) we save some memory. > > > (We also need a very simple http sever that maps sha1 -> file in system > > > image for laptop-to-laptop upgrades, but I think we can do that without > > > using a library.) > > > > "simple" means lighttpd in my mind, but apache has a longer track > > record. > > simple means 300 lines of C code in serve-manifest.c... That may work even better, 300 lines is certainly 1,000,000 times easier to audit for security problems than all of apache or lighttpd. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Upgrades and image manifests
On Tue, 2007-06-19 at 14:39 +0200, Alexander Larsson wrote: > Hi, > > My name is Alexander Larsson, and I just started working on the field > upgrade system of the olpc laptops. I have some ideas I'd like to > explain and get feedback on. > > The olpc uses a full-image system, as opposed to the per-package > versioning scheme of deb or rpms. So, an upgrade consists of replacing > your system files with a full copy of a later (or earlier) version of > the system image. We want to support both upgrading from a central > server or from another laptop, and we want to minimize the data we have > to download for an upgrade. > > To support this we create a manifest that describes each image, and we > save a copy of the current image manifest installed on the laptop. The > manifest format is very similar to the git "tree" object, and describes > each file by listing name, metadata and sha1 hash value of the contents. > > Here is a small example: > - > link 777 500:500 foo bar > blob 664 500:500 4e1243bd22c66e76c2ba9eddc1f91394e57f9f83 changed.txt > blob 664 500:500 65ef9261ad6cfaa8403f2fa66d8edfada1445e5a common > blob 664 500:500 f660633c832712eba3c6edd39151987e46bc3f87 image1.txt > blob 711 500:500 empty logfs.pdf > dir 775 500:500 subdir1 > blob 664 500:500 empty subdir1/file1.txt > blob 664 500:500 7448d8798a4380162d4b56f9b452e2f6f9e24e7a subdir1/file2.txt > --- > > Given a manifest for the current image and a manifest for the image to > upgrade to it is very simple and cheap to calculate what changes you So the manifest you update to is an interesting piece, and it's easier because where you get it from is completely orthogonal to the update process. So, you could: 1) as others have suggested, XO periodically contacts the school server 2) XO sends it's current image, asks what to update to, if anything 3) school server makes policy decision about update 4) school server sends back new manifest 5) XO verifies manifests signature 6) XO downloads changesets This is cool, because it doesn't matter _where_ you get the changesets from, be it the school server (which should be seeding the changesets anyway), or from another XO. It optimizes for bandwidth, but not at the expense of any security. You already know what changesets are valid based on the signature-verified server-provided manifest, and on the self-verifying sha1 of the changesets that anyone can provide to you. All in all, simple, straightforward, and not very much code. Dan > need to make to transform the image (on the client), and what sha1 blobs > you need to download. You can then download the file blobs from whatever > source you have (they are self-verifying, since they are named by the > sha1 hash of the content) and do the upgrade. > > It is very simple to host the blobs. We just put them all in a directory > named by sha1 and export that with a http server. One can also host > multiple versions of an image in the same directory, while minimizing > the space used for common data. (Possibly one might want to gzip the > blobs too.) > > I've written some code (attached) to generate and manipulate manifests > like these. There are three tools: > > * generate-manifest: This generates a manifest files given a path to a > directory containing the image tree. You can also make it populate a > directory of sha1-named blobs by giving it a blob directory with -b. > > * diff-manifest: Gives a simple visual diff between two manifests. If > you pass it -b it will instead give a list of all blobs required to > update between the two manifests. > > * upgrade-manifest: Updates an image from one manifest to another, given > a path of a directory with the required blobs. > > Using these tools I upgraded from > olpc-redhat-stream-development-build-406-20070507_2141-devel_ext3-tree > to olpc-redhat-stream-development-build-406-20070507_2157-ext3-tree in a > directory on my development machine, so it seems to work so far. > > For finding and downloading updates I was thinking of using avahi to > publish the image id + version, and then downloading the data and > manifests using http. That way that clients can detect machines around > them with later versions and auto-download (and apply automatically or > later). The individual laptops can publish the version of the image they > are using, and a school server can publish several versions. From the > point of view of the individual laptop searching for upgrades they will > look the same. Of course, we'd have to sign the manifests with some key > to make sure you can't just auto-upgrade any machine to a rouge image. > > Now over to the questions I have: > > I'd like to put this code in a repository somewhere. Where should I put > it? > > Does OLPC use selinux or xattrs? Because if so we have to extend the > manifest format. > > We need a library to do http downloads. I see we're shipping libcurl on > the laptop. Is it ok to use this library? > (We also nee
Re: Upgrades and image manifests
On Tue, 2007-06-19 at 14:39 +0200, Alexander Larsson wrote: > Hi, > > My name is Alexander Larsson, and I just started working on the field > upgrade system of the olpc laptops. I have some ideas I'd like to > explain and get feedback on. One more thing :) I'm sure you know, but something people haven't brought up in the whole updates discussion yet is the whole picture. It's not just about the mechanical process of getting updates from point A to point B, since that completely forgets the users who's XO we're trying to update. It's critical to give some user visibility into the update process. While the tool needs to be resilient against users moving around and downloads timing out, the user also needs the _ability_ to see what the tool is doing, even if the UI or the user don't always want to or care. Sugar may want to notify the user when an update starts so the user knows why their machine is now slower, and why their WLAN light is always on. We should have at least the ability to do the Sidekick thing and allow the user to postpone certain updates, but after a week it gets applied automatically. We may want to show the progress of the update, to give users visibility into the process and when to expect it to get done. We need to notify the user than an update is done, and we would suggest that they reboot (possibly based on a metadata flag in the manifest for "suggest-reboot=yes"). The update daemon must provide a fair amount read-only status information before and during the update process to allow the GUI bits the flexibility to present that information to the user in the way it sees fit. In the ideal world, that means a D-Bus service that sends signals at various stages and has methods Sugar can call to get more information about the update process. However, that links in more libraries and adds vulnerability window to a critical piece of the system. So in that sense, even though a D-Bus server model is a very good one from an API point of view, perhaps the most responsible method would be simple text files that Sugar can inotify and get the required information. Oh, and we should probably rate-limit or connection-limit the local HTTP server that's serving updates so we don't hammer one particular XO. This could mean putting an _advisory_ "try-me=true/false" flag in the mDNS advertisement that we switch depending on the current connection load. The server would obviously still boot users if there were too many connections, but at least using the 'try-me' gives other laptops more information about whether they should try to connect right away, or try a different XO that may advertise the same blob. Have you thought about what information the mDNS record would advertise? In the best case, it's as large of a UDP packet as we can push out. And since we can probably deal easily with packets up to the wireless MTU (which is something > 2000 bytes), there's more room than the traditional 512 byte UDP packet. However, the space in the mDNS announcement is not unlimited, so I don't think we could put the entire blob list in there :) There's certainly enough room to put a build number, HTTP server port number, manifest hash, etc. Dan > The olpc uses a full-image system, as opposed to the per-package > versioning scheme of deb or rpms. So, an upgrade consists of replacing > your system files with a full copy of a later (or earlier) version of > the system image. We want to support both upgrading from a central > server or from another laptop, and we want to minimize the data we have > to download for an upgrade. > > To support this we create a manifest that describes each image, and we > save a copy of the current image manifest installed on the laptop. The > manifest format is very similar to the git "tree" object, and describes > each file by listing name, metadata and sha1 hash value of the contents. > > Here is a small example: > - > link 777 500:500 foo bar > blob 664 500:500 4e1243bd22c66e76c2ba9eddc1f91394e57f9f83 changed.txt > blob 664 500:500 65ef9261ad6cfaa8403f2fa66d8edfada1445e5a common > blob 664 500:500 f660633c832712eba3c6edd39151987e46bc3f87 image1.txt > blob 711 500:500 empty logfs.pdf > dir 775 500:500 subdir1 > blob 664 500:500 empty subdir1/file1.txt > blob 664 500:500 7448d8798a4380162d4b56f9b452e2f6f9e24e7a subdir1/file2.txt > --- > > Given a manifest for the current image and a manifest for the image to > upgrade to it is very simple and cheap to calculate what changes you > need to make to transform the image (on the client), and what sha1 blobs > you need to download. You can then download the file blobs from whatever > source you have (they are self-verifying, since they are named by the > sha1 hash of the content) and do the upgrade. > > It is very simple to host the blobs. We just put them all in a directory > named by sha1 and export that with a http server. One can also host > multiple versions of an image in the same
Re: Build 472 - testing
On Fri, 2007-06-29 at 21:37 -0400, John (J5) Palmieri wrote: > On Fri, 2007-06-29 at 11:23 -0400, Kim Quirk wrote: > > Test Groups, > > Build 472 is available, but the biggest problem is that it doesn't get > > on the mesh or infrastructure AP. Some activities are working and > > there is more to see in the Journal than the previous build. > > > > I'm hoping that we can get another build today with the network > > problem fixed since that would be important for our 'Release Candidate > > 1'. Today's milestone is to get to RC1 which has most of the basic > > functionality that was available in 406 builds. If we can get the mesh > > connecting again, that would be great! > > > > Test release notes: http://wiki.laptop.org/go/Test_Group_Release_Notes > > (Anyone can add notes about this release page -- please do) > > I couldn't fix the mesh issues with the current NetworkManager so I have > backtracked to an earlier working version in build478. This one gets on > the mesh and also on AP points. > > http://olpc.download.redhat.com/olpc/streams/development/build478/ So thinking about it again, we don't expect the new svn2621 NM bits to work with any existing mesh networks because the server software and hardware needs to change. We have to have a flag day in Cambridge too before we can get the new NM automeshing bits, because the new bits aren't compatible with the old bits on the server side. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build 472 - testing
On Fri, 2007-06-29 at 14:17 -0400, John (J5) Palmieri wrote: > On Fri, 2007-06-29 at 11:23 -0400, Kim Quirk wrote: > > Test Groups, > > Build 472 is available, but the biggest problem is that it doesn't get > > on the mesh or infrastructure AP. Some activities are working and > > there is more to see in the Journal than the previous build. > > > > I'm hoping that we can get another build today with the network > > problem fixed since that would be important for our 'Release Candidate > > 1'. Today's milestone is to get to RC1 which has most of the basic > > functionality that was available in 406 builds. If we can get the mesh > > connecting again, that would be great! > > > > Test release notes: http://wiki.laptop.org/go/Test_Group_Release_Notes > > (Anyone can add notes about this release page -- please do) > > > > > > John, > > Can we get a changelog with each build now? Between the changelog and > > the release information that can be provided on the 'Test Group > > Release Notes', we will be providing some good info for those who want > > to use the latest build. > > > > Regards, > > Kim > > > Ok, starting to do ChangeLogs with each build. I think I found the > networking issue which I will fix in the next build. For now if you > want you can log into root at a terminal and type > > chmod +x /etc/NetworkManager/callouts/* > > That should fix things. Grr; I knew I needed to do this and apparently forgot when doing the new RPM. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build 472 - testing
On Sat, 2007-06-30 at 08:10 -0400, Kim Quirk wrote: > It looks like we may need/want to get the latest Marvell firmware and > all known flag day updates into the build on Monday (if possible). At > some point we just have to take the hit and ask everyone to upgrade, > laptops and servers. > > As you mention, Dan, we need to do this in Cambridge first... so maybe > this should be in Monday's build. I know we have the Marvell firmware > (or can get it). Is there anything outstanding that we are still > waiting on to have this flag day? We need to get Ronak's sign-off on any firmware that we plan to put in public builds. That can take a few days, though sometimes it's quick. Dan > Is there a reason NOT to do this as soon as possible? > > Thanks, > Kim > > On 6/30/07, Dan Williams <[EMAIL PROTECTED]> wrote: > On Fri, 2007-06-29 at 21:37 -0400, John (J5) Palmieri wrote: > > On Fri, 2007-06-29 at 11:23 -0400, Kim Quirk wrote: > > > Test Groups, > > > Build 472 is available, but the biggest problem is that it > doesn't get > > > on the mesh or infrastructure AP. Some activities are > working and > > > there is more to see in the Journal than the previous > build. > > > > > > I'm hoping that we can get another build today with the > network > > > problem fixed since that would be important for our > 'Release Candidate > > > 1'. Today's milestone is to get to RC1 which has most of > the basic > > > functionality that was available in 406 builds. If we can > get the mesh > > > connecting again, that would be great! > > > > > > Test release notes: > http://wiki.laptop.org/go/Test_Group_Release_Notes > > > (Anyone can add notes about this release page -- please > do) > > > > I couldn't fix the mesh issues with the current > NetworkManager so I have > > backtracked to an earlier working version in build478. This > one gets on > > the mesh and also on AP points. > > > > > http://olpc.download.redhat.com/olpc/streams/development/build478/ > > So thinking about it again, we don't expect the new svn2621 NM > bits to > work with any existing mesh networks because the server > software and > hardware needs to change. > > We have to have a flag day in Cambridge too before we can get > the new NM > automeshing bits, because the new bits aren't compatible with > the old > bits on the server side. > > Dan > > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: [Testing] Build 472 - testing
On Sun, 2007-07-01 at 10:15 -0700, Ronak Chokshi wrote: > True. Please treat our suggestions of builds only as recommendations. > The final decision of which build should be used for the major > milestones should come from within OLPC based on the accomplishments > planned for that milestone. This is the model we usually follow with > most of our other customers/projects as well. Ok, I was under the impression that we had to get sign-off for any CozyBit built firmware before CozyBit could give it to us, before we could put it in builds. Is that invalid, or has that changed? Dan > > > Thanks > > Ronak > > > > __ > From:[EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Michail Bletsas > Sent: Sunday, July 01, 2007 6:11 AM > To: Dan Williams > Cc: [EMAIL PROTECTED]; Kim Quirk; OLPC Developer's List; > [EMAIL PROTECTED] > Subject: Re: [Testing] Build 472 - testing > > > > > > No we don't > > M. > > > > > > Dan Williams <[EMAIL PROTECTED]> > Sent by: > [EMAIL PROTECTED] > > 06/30/2007 11:37 PM > > >To > > > Kim Quirk > <[EMAIL PROTECTED]> > > >cc > > > [EMAIL PROTECTED], "OLPC Developer's List" <[EMAIL PROTECTED]> > > > Subject > > > Re: [Testing] > Build 472 - > testing > > > > > > > > > > > > > > > > > On Sat, 2007-06-30 at 08:10 -0400, Kim Quirk wrote: > > It looks like we may need/want to get the latest Marvell firmware > and > > all known flag day updates into the build on Monday (if possible). > At > > some point we just have to take the hit and ask everyone to upgrade, > > laptops and servers. > > > > As you mention, Dan, we need to do this in Cambridge first... so > maybe > > this should be in Monday's build. I know we have the Marvell > firmware > > (or can get it). Is there anything outstanding that we are still > > waiting on to have this flag day? > > We need to get Ronak's sign-off on any firmware that we plan to put in > public builds. That can take a few days, though sometimes it's quick. > > Dan > > > > Is there a reason NOT to do this as soon as possible? > > > > Thanks, > > Kim > > > > On 6/30/07, Dan Williams <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-06-29 at 21:37 -0400, John (J5) Palmieri wrote: > > > On Fri, 2007-06-29 at 11:23 -0400, Kim Quirk wrote: > > > > Test Groups, > > > > Build 472 is available, but the biggest problem is that > it > > doesn't get > > > > on the mesh or infrastructure AP. Some activities are > > working and > > > > there is more to see in the Journal than the previous > > build. > > > > > > > > I'm hoping that we can get another build today with the > > network > > > > problem fixed since that would be important for our > > 'Release Candidate > > > > 1'. Today's milestone is to get to RC1 which has most of > > the basic > > > > functionality that was available in 406 builds. If we > can > > get the mesh > > > > connecting again, that would be great! > > > > > > > > Test release notes: > > http://wiki.laptop.org/go/Test_Group_Release_Notes > > > > (Anyone can add notes about this release page -- please > > do) > > > > > > I couldn't fix the mesh issues with the current > > NetworkManager so I have > > > backtracked to an earlier working version in build478. > This > > one gets on > > > the mesh and also on AP points. > > > > > > > > > http://olpc.download.redhat.com/olpc/streams/development/build478/ > > > > So thinking about it again, we don't expect the new svn2621 > NM > > bits to > > work with any existing mesh networks because the server > > software and > > hardware needs to change. > > > > We have to have a flag day in Cambridge too before we can > get > > the new NM > > automeshing bits, because the new bits aren't compatible > with > > the old > > bits on the server side. > > > > Dan > > > > > > > > ___ > Testing mailing list > [EMAIL PROTECTED] > http://lists.laptop.org/listinfo/testing > > > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Upgrades and image manifests
On Fri, 2007-06-29 at 12:26 -0400, C. Scott Ananian wrote: > Please read Ivan's update proposal. He addresses many of the > peripheral issues that have arisen, re user notification, etc. > > At this point, as far as I'm concerned, the only open question is how > we get a filesystem image onto the laptop once we know which one to > get. Ivan suggests rsync; I refined that somewhat with a > directory-at-a-time rsync using manifests; someone else (Mike?) > proposed bittorrent, and previously I proposed a bespoke solution > using binary diffs and multicast. > > Alex's work is interesting, but we need to see benchmarks if we're not > going to make a decision based on just fiat and personality. I've > posted up/download bandwidth for upgrades between 464-465 and 465-466. > Following up on Mike's suggestion, I've also patched bittorrent to > allow using it for upgrades: the net bandwidth usage is something like > 30MB, because it does not use block compression. I can post more > detailed comparisons if people are interested. Please perform the > equivalent benchmarks on the updatinator, before we continue this > discussion. With updatinator, bsdiff-ing the changes between files and gzipping new files is the sweet spot. I tested plain blobs, gzipped blobs, bzip2-ed blobs, bsdiff + gzip, and bsdiff + bzip2. Unfortunately, bzip2's memory consumption on decompress isn't all that great according to other people's research, and gzip gives us the best balance between compression ratio and decompression mem/cpu usage. Scott, you may also want to re-test the rsync benchmarks using rsync compression to make the bandwidth numbers in the rsync benchmarks go down. You didn't mention anything specifically about using wire compression, but the numbers look like you hadn't used it? This patch adds bsdiff + gzip compression to updatinator: http://people.redhat.com/dcbw/updatinator-bsdiff-gzip.patch The difference sizes, using "du -csb" on the difference blob directory are as follows. This is the amount of data that would be transferred over the network, not including HTTP headers. 464->465: 6,869,799 bytes 465->466: 18,870,574 bytes The resulting image directories verify with both verify-manifest and diff -rua. As an improvement, we should provide a manifest-diff file for each update path (along with the manifests for the actual image) that lists the blobs with their own sha1 sum so that they are self-verifying. This would also simplify the patch quite a bit because there would be less path-munging. The diff-manifest tool that generates the blob diffs will output this data in a somewhat suitable format already. Cheers, Dan Procedure: 1) get the 465 and 466 "tree" files 2) unpack those trees 3) diff-manifest -g 465-466 465 466 465-manifest.txt 466-manifest.txt 4) cp -r 465 465-test 5) upgrade-manifest -b 465-466 -d 465-test 465-manifest.txt 466-manifest.txt 6) verify-manifest 466-manifest.txt 465-test ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: .xo bundles (was Re: #1803 HIGH Trial-2: Add Chat activity to builds)
On Tue, 2007-07-03 at 23:47 +0200, Bert Freudenberg wrote: > > Comment (by J5): > > > > Replying to [comment:4 bert]: > >> Replying to [comment:3 J5]: > >>> This was generated incorrectly. First the version should be -9 > >>> second > > the activity should be Chat-9.xo. It looks like it was simply > > zipped up > > instead of using the packaging tools. > >> > >> Not sure what else is wrong, but simply zipping up is surely as > >> valid as > > using whatever tools there are, right? > > > > No, right now it works but in the future there is no guarantee as > > we may > > do post processing. Also python setup.py dist creates a clean package > > without any of the stray development files (such as MacOS resource > > files) > > getting packaged up. > > Such garbage should not be included obviously. But I'd much prefer if > bundles stay simple zip files without added magic. What kind of "post > processing" do you imagine that could not be easily done manually? Generating the signature and verification information for the bundle for signed bundles, which may eventually be required for automatic installation without nice big warning signs. To manually do that, you'd have to sha1 every file in the bundle, add that to some manifest files, and sha1 the manifest file, etc. A lot harder than just zipping the bundle up, because each time you change a file in the bundle, the old signature is invalid. I'm sure you'd want to do this automatically rather having to do it manually and zipping up the bundle. Originally I'd planned to use a JAR-type signing mechanism for bundles, but that may/may not change. It doesn't have any impact on _developing_ bundles, but would when the time came to make a .xo out of your activity. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[PATCH] cafe_ccic: add support for VIDIOC_ENUM_FRAMESIZES and VIDIOC_ENUM_FRAMEINTERVALS
Newer gstreamer v4l2 plugins require these ioctls to determine supported
frame sizes and rates. Unfortunately, the kernel v4l2 bits don't have
members in 'struct video_device' for these ioctls, so we have to
override the generic ioctl handler for these two functions. They report
only VGA size @ 30fps as being supported for now.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
diff --git a/drivers/media/video/cafe_ccic.c b/drivers/media/video/cafe_ccic.c
index 4710044..41cdb69 100644
--- a/drivers/media/video/cafe_ccic.c
+++ b/drivers/media/video/cafe_ccic.c
@@ -1716,6 +1716,63 @@ static int cafe_vidioc_s_parm(struct file *filp, void
*priv,
return ret;
}
+static int cafe_vidioc_enum_framesizes(struct cafe_camera* cam,
+ void __user * arg)
+{
+ struct v4l2_frmsizeenum frmsize;
+
+ if (copy_from_user(&frmsize, arg, sizeof(frmsize)))
+ return -EFAULT;
+
+ if (frmsize.index != 0)
+ return -EINVAL;
+
+ if (frmsize.pixel_format != V4L2_PIX_FMT_YUYV &&
+ frmsize.pixel_format != V4L2_PIX_FMT_RGB444 &&
+ frmsize.pixel_format != V4L2_PIX_FMT_RGB565)
+ return -EINVAL;
+
+ frmsize.type = V4L2_FRMSIZE_TYPE_DISCRETE;
+
+ frmsize.discrete.width = VGA_WIDTH;
+ frmsize.discrete.height = VGA_HEIGHT;
+ memset(&frmsize.reserved, 0, sizeof(frmsize.reserved));
+
+ if (copy_to_user(arg, &frmsize, sizeof(frmsize)))
+ return -EFAULT;
+
+ return 0;
+}
+
+static int cafe_vidioc_enum_frameintervals(struct cafe_camera* cam,
+ void __user * arg)
+{
+ struct v4l2_frmivalenum frmival;
+
+ if (copy_from_user(&frmival, arg, sizeof(frmival)))
+ return -EFAULT;
+
+ if (frmival.index != 0)
+ return -EINVAL;
+
+ if (frmival.pixel_format != V4L2_PIX_FMT_YUYV &&
+ frmival.pixel_format != V4L2_PIX_FMT_RGB444 &&
+ frmival.pixel_format != V4L2_PIX_FMT_RGB565)
+ return -EINVAL;
+
+ if (frmival.width != VGA_WIDTH || frmival.height != VGA_HEIGHT)
+ return -EINVAL;
+
+ frmival.type = V4L2_FRMSIZE_TYPE_DISCRETE;
+ frmival.discrete.numerator = 1;
+ frmival.discrete.denominator = 30;
+ memset(&frmival.reserved, 0, sizeof(frmival.reserved));
+
+ if (copy_to_user(arg, &frmival, sizeof(frmival)))
+ return -EFAULT;
+
+ return 0;
+}
static void cafe_v4l_dev_release(struct video_device *vd)
{
@@ -1724,6 +1781,23 @@ static void cafe_v4l_dev_release(struct video_device *vd)
kfree(cam);
}
+static int cafe_v4l_ioctl(struct inode* inode, struct file* filp,
+unsigned int cmd, unsigned long arg)
+{
+ struct cafe_camera *cam = filp->private_data;
+
+ switch (cmd) {
+ case VIDIOC_ENUM_FRAMESIZES:
+ return cafe_vidioc_enum_framesizes(cam, (void __user *)arg);
+ case VIDIOC_ENUM_FRAMEINTERVALS:
+ return cafe_vidioc_enum_frameintervals(cam, (void __user *)arg);
+ default:
+ break;
+ }
+
+ return video_ioctl2(inode, filp, cmd, arg);
+}
+
/*
* This template device holds all of those v4l2 methods; we
@@ -1737,7 +1811,7 @@ static const struct file_operations cafe_v4l_fops = {
.read = cafe_v4l_read,
.poll = cafe_v4l_poll,
.mmap = cafe_v4l_mmap,
- .ioctl = video_ioctl2,
+ .ioctl = cafe_v4l_ioctl,
.llseek = no_llseek,
};
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: can't get wireless working on B2 updated to 406
On Fri, 2007-07-06 at 15:01 -0400, Chris Ball wrote: > Hi, > >>raidautorun: failed to open /dev/md0: No such device or address > > That's normal. > >> from a root shell ifconfig only lists the lo interface. > > That's bad. Please open a bug on http://dev.laptop.org/query and attach > the file created by "dmesg > file". You might try removing all power > (AC and battery) and rebooting, in case the problem goes away. Well, it depends on whether you did "ifconfig" or "ifconfig -a". If the interface isn't up, it won't show up with a plain "ifconfig". That's not extremely surprising if NM couldn't connect to anything. 406 does try mesh stuff, so if you haven't already connected to an infrastructure access point, it's also not surprising that you wouldn't get wireless connectivity until you did that. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: can't get wireless working on B2 updated to 406
On Fri, 2007-07-06 at 22:08 -0400, Stephen Bannasch wrote: > At 5:48 PM -0400 7/6/07, Dan Williams wrote: > >On Fri, 2007-07-06 at 15:01 -0400, Chris Ball wrote: > >> Hi, > >> > >>>raidautorun: failed to open /dev/md0: No such device or address > >> > >> That's normal. > >> > >>> from a root shell ifconfig only lists the lo interface. > >> > >> That's bad. Please open a bug on http://dev.laptop.org/query and attach > >> the file created by "dmesg > file". You might try removing all power > >> (AC and battery) and rebooting, in case the problem goes away. > > > >Well, it depends on whether you did "ifconfig" or "ifconfig -a". If the > >interface isn't up, it won't show up with a plain "ifconfig". That's > >not extremely surprising if NM couldn't connect to anything. 406 does > >try mesh stuff, so if you haven't already connected to an infrastructure > >access point, it's also not surprising that you wouldn't get wireless > >connectivity until you did that. > > My WAP is broadcasting it's SSID and is using WPA/WPA2 Personal. We only recently fixed WPA support, and the UI currently doesn't show any WPA access points. You should still be able to see them with "iwlist eth0 scan" though. > When I startup the XO I don't get any icons in the upper right listing > available SSID's and noting appears when I open the local network icon. > > This is the result of running ifconfig -a: > > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > What else should I see? > > I assumed I'd see a wireless interface in the list. Whats the output of "/sbin/lsmod" ? Can you provide the output of "dmesg" too? If you're not seeing the devices with "ifconfig -a", then the modules for them are not being loaded. Thanks, Dan > Do you know if this error message means anything? > > eth0 no private ioctls > > It's generated on startup when running: olpc-configure. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] cafe_ccic: add support for VIDIOC_ENUM_FRAMESIZES and VIDIOC_ENUM_FRAMEINTERVALS
On Fri, 2007-07-06 at 16:30 -0600, Jonathan Corbet wrote: > Dan Williams <[EMAIL PROTECTED]> wrote: > > > Newer gstreamer v4l2 plugins require these ioctls to determine supported > > frame sizes and rates. Unfortunately, the kernel v4l2 bits don't have > > members in 'struct video_device' for these ioctls, so we have to > > override the generic ioctl handler for these two functions. They report > > only VGA size @ 30fps as being supported for now. > > Interesting, I didn't know about that. I just sent a question off to > Mauro (the V4L2 maintainer) on why those ioctls aren't wired up through > video_ioctl2(). His answer, essentially, is "nobody was using them > yet." Well, gstreamer 0.10.6 now is using those, and in 2.6.22, apparently 4 different drivers have hooked up the FRAMESIZES, and one of those has hooked up FRAMEINTERVALS (pwc, for example, but it doesn't even use the video_ioctl2 hook). The old method of determining largest framesize was complete crack and broke with a lot of drivers, so I'm a great fan of having these explicit commands :) You used to pass in the basically INT_MAX and the driver was supposed to clip that and return what it supported, but since v4l2 drivers are about where wireless+WEXT was 2 years ago, of course nobody has consistent behavior even though v4l2 actually has a spec. > I don't think this patch is destined for the mainline in its current > form. The right thing to do is to add callbacks for those commands and > support them for all drivers through video_ioctl2(). Shouldn't be that Yeah, that's obviously the right thing to do. However, it's not in 2.6.22 yet, and we probably won't ship 2.6.23 in our first release, so we may need to carry some patch like this in olpc-2.6 until we move to 2.6.23. See below for more details :) > hard of a thing to do. Once that's done, the cafe_ccic driver should > really just push those commands down to the sensor layer. Then you > could actually enumerate the real frame sizes and supported rates and > you would not have to wire assumptions about the supported video formats > into the controller driver. > > I'm traveling (again, sigh) next week, but could probably hack something > up the week after if you don't want to spend more time on this. I'm not sure I'll have time... It's still unknown whether or not we need to move to gstreamer-plugins-good-0.10.6 (which is where the rewritten v4l2src is), because we still need to investigate whether it solves some of the various problems we've seen. If we do move to 0.10.6, we'll need this patch or something like it. If it doesn't, we stick with 0.10.5. Thanks, Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: pivot_root on boot
On Sat, 2007-07-07 at 00:12 -0400, C. Scott Ananian wrote: > Quick recap of early boot: > a) open firmware checks the status of the key, and > signature-checks and boots either the primary or the backup kernel, > passing "fs=primary" or "fs=backup" on the kernel command-line. > b) an initramfs script looks for an activation record in /, and > initiates activation if not found. If it is found, then we pivot_root > to root:/primary or root:/backup, depending on the value of the 'fs' > command-line parameter. > > I've prototyped this process on a hacked build 488. All the "real" > filesystem (except boot) is moved down one level to /a, and we > pivot_root to /a during startup. Some things I found out: > > a) we actually already have an initrd for our kernel, which is built > with klibc and is mostly useless: it loads a few modules and invokes > klibc's "run-init" to deallocate the initramfs and pivot to the new > root. > b) pivoting to a directory which is not a mount point (ie, not the > root directory of the mounted fs) is problematic. The --move option > to mount only works on mount points. We can --move to the real root > and then chroot to the subdirectory, but then this causes problems > when we want to remount the real root rw after fsck: mount -o > remount,rw / doesn't work, because / isn't actually the mount point. > In fact, we can't see the actual mount point anymore. > > Suggestions: > a) get rid of the existing initrd. Un-module the necessary IDE and > olpc_nand drivers. > b) Create new initrd with activation and "pivot" code. > c) Don't try to pivot_root to the 'real' filesystem. Instead use symlinks: >/boot -> /current/boot >/bin -> /current/bin > Then we can swing the /current symlink from /a to /b to select either > the primary or the backup filesystem. My gut feeling is, let's get the bits to actually generate/support two filesystems into the machine and working before we land something that lets us choose between two filesystems. Boot process is already complicated enough that adding another level to it that may/may not be actually _used_ depending on whether or not we get all the other necessary bits in, doesn't sound like a good idea to me at the moment... I'm basically just worried that if the other stuff doesn't land, we have a bunch of other (unused) pieces that were intended to support the pieces that didn't land, and then we have to spend effort to rip them out. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
cafe_ccic slowness in VIDIOC_S_FMT
Hi, The gstreamer is taking a long time to start the pipeline, so I put some debugging info into the v4l2 source. Here's what I got: 0:00:02.40365 v4l2src v4l2src_calls.c:874:gst_v4l2src_set_capture: V4L2SRC: Setting capture format to 640x480, format YUYV 0:00:02.403785000 v4l2src v4l2src_calls.c:887:gst_v4l2src_set_capture: *** VIDIOC_G_FMT: 22 microseconds 0:00:06.059932000 v4l2src v4l2src_calls.c:901:gst_v4l2src_set_capture: *** VIDIOC_S_FMT: 3655992 microseconds 0:00:06.061419000 v4l2src v4l2src_calls.c:916:gst_v4l2src_set_capture: *** VIDIOC_G_PARM: 1313 microseconds 0:00:06.082901000 v4l2src v4l2src_calls.c:927:gst_v4l2src_set_capture: *** VIDIOC_S_PARM: 21368 microseconds 0:00:06.083023000 v4l2src v4l2src_calls.c:1014:gst_v4l2src_capture_init: initializing the capture system 0:00:06.083127000 v4l2src v4l2src_calls.c:1023:gst_v4l2src_capture_init: *** calling REQBUFS, requested 2 buffers 0:00:06.088328000 v4l2src v4l2src_calls.c:1028:gst_v4l2src_capture_init: *** called REQBUFS, got 6 buffers So here you see that calling VIDIOC_S_FMT takes 3655992 microseconds, which is a _really_ long time. Turns out that cafe_cam_configure() from s_fmt_cap() takes 378 jiffies. Breaking this down, the pieces of cafe_cam_configure() and the jiffies they take are: INT_INIT: 301352 -> 301682 (330) S_FMT: 301682 -> 301725 ( 43) set_flip: 301725 -> 301729 ( 4) All INT_INIT does is write the default registers to the chip, which is a lot of calls to (eventually) i2c_smbus_xfer() in drivers/i2c/i2c-core.c. I'm not sure where it goes after that. I assume that each call probably does an mdelay or something. Is there anything that can be done to batch these register writes together, or cut down the time that calling cafe_cam_configure() will take? It takes a _really_ long time to set up for streaming capture as seen from userspace... Thanks, Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: updatinator benchmarking (Was: rsync benchmarking)
On Wed, 2007-07-11 at 23:47 +1000, [EMAIL PROTECTED] wrote: > Alexander, > > I should mention that doing better than rsync with a custom solution > is not unexpected. rsync tries to be fairly general purpose, and > special purpose delta tools can almost always do better, as they can > take advantage of more information about the data. Well, what we're more concerned about is spreading around the load of updates, both from a network traffic perspective and a server-utilization perspective than any type of "beating" of rsync. More of a peer-to-peer model using standard protocols like HTTP. Nothing against rsync, it's quite appropriate for a centrally-managed system with fairly reliable network connections, but that's not the problem that updatinator is actually attempting to solve... different approaches to the same problem really. Dan > At least rsync provides a harder target to beat than scp or ftp would, > so its useful in that way :-) > > One thing to watch is round trips. Large numbers of http GET requests > means lots of round trips. rsync uses very few round trips, so it > tends to do well on high latency links. > > Cheers, Tridge > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New autoreinstallation scripts with activation support.
On Mon, 2007-07-16 at 00:15 -0400, C. Scott Ananian wrote: > On 7/15/07, C. Scott Ananian <[EMAIL PROTECTED]> wrote: > > Please test the autoreinstallation process and let me know if you find > > problems. Also verify that a file named 'keylist' is placed on your > > USB key by the autoreinstallation process. > > The file-formerly-known-as-keylist has been renamed to 'leases.xo'. > So that's the file to look for after you autoreinstall. Is it a zipfile with an activity/ folder inside? If not, then we can't use .xo, because that's the extension we've chosen for activity bundles. John has plans for a mime type too... I don't have any other ideas off the top of my head than .dat :) Dan > --scott > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Dramatic image size reduction
On Fri, 2007-07-20 at 10:23 -0400, Bernardo Innocenti wrote: > Build 511 was 290MB, build 513 dropped to 218MB, but > I couldn't find anything in the ChangeLog to justify > this dramatic improvement. Anyone has a clue? The library was broken and was removed. I should have noted that in the changelog. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: text channel
On Sat, 2007-07-21 at 17:18 +0200, Bert Freudenberg wrote: > > Comment (by dcbw): > > > > You don't actually need Tubes here. Each activity has it's own text > > channel (even if it doesn't have tubes), which is what we were > > going to > > use to do the corkboard stuff. The text channel may possibly be > > abused > > for this, though we'd have to check what the link-local stuff does. > > This sounds interesting. Looking for more details I found > > http://wiki.laptop.org/go/Activity_Sharing > > which doesn't really explain what is actually implemented right now, > nor what the actual API to use e.g. the text channel would be. > > Where would I have to look? It basically gives you access to the underlying XMPP chat channel which is what you'd be using if you started a Jabber chat with somebody. Take a look in src/activity.py in the PS, for example _handle_share_join(), and the get_channels() will return the object path of the text channel to your activity, so that you can talk to Telepathy directly. The Chat activity uses the text channel, and so is probably the best guide for how to get it and use it. dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: "Could not activate this XO" error
On Sun, 2007-07-22 at 20:54 -0400, Kim Quirk wrote: > Thanks Mitch! I didn't know that. > > Do you think that is the best way to do the downgrade? I already > changed the Autoreinstallation page to the notes I above. The possible > problem at the end of the downgrade didn't sound good; and we are > going to start using stable release numbers >1000, so if you do change > it back, please keep that in mind. you rename the nand.xxx files to something like nand6.img and nand6.crc, and change the build # to 6 in olpc.fth. OFW compares the version it finds in olpc.fth to the version it sees in the existing OS on the NAND, so regardless of what build # is in the nand files, it'll overwrite the NAND if you make the olpc.fth version higher than what's on the NAND. Dan > Thanks, > Kim > > On 7/22/07, Mitch Bradley <[EMAIL PROTECTED]> wrote: > Kim Quirk wrote: > > I don't recommend that your rename your nand to a higher > build number > > than it actually is just to avoid a downgrade. You may never > be able > > to catch up (or catch back down to the proper version). > > > > Renaming the installation file does not change the version > number that > is actually stored in the NAND FLASH as a result of the > installation. > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Adding 'Collaboration' to an activity
On Sun, 2007-07-22 at 17:48 -0400, Julius B. Lucks wrote: > Hi All, > > > I am working on Kuku Anakula (Hungry Chicken), which is an educational > quiz game for the XO (see wiki.laptop.org/go/Kuku). In the game, a > quiz question is posed in the upper left corner of the screen. The > player (a chicken) moves around a grid, with each grid square > containing a possible answer. The goal is for the player to move to > and 'eat' the correct answers for the posed questions. > > > Currently, Kuku is only a one-player game. We would like to expand to > multiple players on expanded grids - either in competition with each > other, or working together to progress through the quiz questions. > Kuku is written in pygame. > > > Is there a standard way for activities to implement collaborative > elements such as this? Are their standard API's for exchanging data > between XO's? Yeah, it's called "Tubes" and is an extension of the D-Bus IPC system into a networked environment. It's more complicated than it needs to be right now, but it works and a few activities (memory, connect4) have already done it. Take a look at: http://dev.laptop.org/git.do?p=projects/connect-activity;a=summary http://dev.laptop.org/git.do?p=projects/memorygame;a=summary The simplest example is: http://dev.laptop.org/git.do?p=projects/hellomesh;a=tree Dan > > I appreciate any information that could help me get started. > > > Cheers, > > > Julius > > --- > Please Reply to My Permanent Address: [EMAIL PROTECTED] > http://www.openwetware.org/wiki/User:Julius_B._Lucks > > > > > > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] First impressions of a B4 machine
On Mon, 2007-07-23 at 06:29 +0100, Ivo Emanuel Gonçalves wrote: > Hello Sugar and Devel lists, > > I finally got my hands on a B4 machine, which I will be using for Xiph > compatibility tests, among other things. > > However, I got so many things to say about the system presently that I > might as well just post a First Impressions thread. Hopefully, some > of my points will be considered to improve the XO laptop. > > The first thing I noticed is how tiny the laptop is. I'm really > enjoying the hardware, and I believe it's a real killer combination > for a durable and powerful machine for children. The laptop is > perhaps too heavy for a child, though. I can notice the weight, so I > imagine how a badly nourished child will deal with the weight by > him/herself, perhaps for 1 or 2 km's to the nearest school. Maybe the > components will be more and more miniaturized in following versions? > It's still a valid concern. One question; did you get a NiMH or a LiFePo4 battery? LiFePo4 have "Battery Sample" written on them. They are quite a bit lighter than the NiMH ones. > Speaking of the components, I have a few environmental concerns, but I > think I will save them for a future thread. > > Being able to rotate the display of a screen that can already rotate > 360º is pretty useful, not to mention awesome. Congrats to whoever > designed the system. > > Booting XO was fast for a Linux system, but very likely not fast > enough for a child expecting it to turn on immediately. I guess it > can't be helped. What could be done, however, is hide the diagnostic > dialogs with a simple splash screen stating POWERING ON, or LOADING, > or whatever. It's cute and would not confuse the children. I mean, > we don't want them to think: "Hey, what's all this alien garbage on > the screen?", instead of paying attention to class. They will have a boot splash screen, just haven't gotten there yet. We also haven't put the time into optimizing startup time, because it's pretty low-hanging fruit and fairly easy to do. There are more pressing things right now (getting the networking/sharing to work for example) but this is something we fully intend to do. > I have to say that Sugar looks pretty neat. Really neat. It's simple > to understand, efficient, and easy to use. What's not so obvious is > that you have to push the square button on the top right to be able to > go back to Sugar after loading a program. Took me a while to figure > that out. It's a no-brainer afterwards, though. > > I don't understand why the XO asks for my name after I turned it on > for the first time, as it has never greeted me by my name since, nor > does it seem that my name has any importance for school work. It > doesn't even show up on the /home folder. I suppose this may change > in the future of the XO development, but right now it makes no sense > to be there. I have really seen no point to the color switcher of the > XO logo, either. It seems my "version" of the XO logo stays in > Sugar's background, but otherwise seems to have no other use. It > doesn't seem we may switch the color afterwards, either. Useless > distraction. These are both so that other children on the mesh can recognize you. You probably have build 406.15 on the machine, you probably want to update to something in the 500-series, which has a lot more of the network capabilities. Each child is represented by a color combination and a nickname. If you work on documents together, you'll see the XO icons of the other children you worked on it with. If you look in the Mesh View, you'd see other XOs that yours can see, represented by the XO icon in that child's colors. The roll-over contains the child's nickname. > Before going over the software choice, may I question why the choice > for Fedora? Yes, I understand the OLPC has some kind of agreement > with Red Hat, and it's all fine and well, but Fedora is known for its > "bloatness". Why not look into smaller and more XO-adequated distros > like Damn Small and similar? Is it because of SELinux? SELinux may > be put on any distro. We haven't yet put a lot of work into slimming down the distribution, but this is tradeoff between taking stuff out and forward maintenance. Slimdown is someting that'll start happening soon. > One of the big issues I have found so far should be easy to solve. > And that's the file system. Pretty much every program under the XO > with an Open/Save File dialog displays the entire mess that is the There actually aren't going to be open/save dialogs, and they are no longer there in the current builds. You might want to reflash with a development image to see what the current state of the Journal is. > Linux filesystem. Are children supposed to even see that? Why not > use a .hidden file? Most GTK and Qt applications that I know of obey > its rules and hide every file marked that shouldn't be seen. And that > kind of behavior makes sense. They should only see /
Re: Non-XOs showing up in neighborhood
On Tue, 2007-07-24 at 00:36 +0800, Trent Lloyd wrote: > Hi Sjoerd, > > Sjoerd Simons wrote: > > On Mon, Jul 23, 2007 at 05:16:17PM +0200, Michael Rueger wrote: > > > >> Sjoerd Simons wrote: > >> > >> > >>> The Chat activity can uses multi-user chats afaik, which is something only > >>> supported by telepathy-salut (it's not standardized). So you won't be > >>> able to > >>> talk to them unless they use a Telepathy based client. > >>> > >> So this mean everybody in wireless range and a Telepathy client can chat > >> with the kids on the XO mesh? > >> > > > > Yes. There is no (real) difference in the telepathy-salut you can install on > > your normal machine and the one on the XO. So you can talk to each-other. > > > > Joining the mesh without an XO is hard though (as afaik there are no other > > machines supporting 802.11s). I'm assuming the Jonathan was using a normal > > wireless network when he saw others online, not a mesh. > > > I was under some kind of weird impression you could join the mesh as a > ad-hoc client, you just wouldn't actually participate in any meshing, > which seems to be confirmed by the fact at GUADEC, for example, you'd > see an 'olpc-mesh' network as ad-hoc? > > No idea if this actually works, however, or perhaps I'm totally bongo > bananas No, not really... the wireless part is a virualized adapter, and the mesh interface piggybacks on the normal 802.11 interface. The mesh has a comletely different frame format, so normal laptops are not able to speak olpc mesh. However, to get the mesh stuff up, you have to bring up the normal 802.11 interface in ad-hoc mode, which means it beacons, which means you'll see "olpc-mesh" from other machines. Those machines can join the 802.11 ad-hoc network, but that's separate from the "mesh". dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: updatinator status, issues
On Thu, 2007-07-26 at 17:00 +0200, Alexander Larsson wrote: > I've updated autoupdatinator (the peer-to-peer mDNS version of the > updatinator downloader) to work with the new repository layout where > manifests are stored as blobs. I've tested it by publishing an apache > http server with a static avahi server file, and it works well. > > I also updated the server-release tool that lets you publish the olpc:s > current image via avahi, but when testing this on my XOs I immediately > ran into an issue. When trying to download a blob I got a 404 error. It > turns out this was due to the manifest listing /var/lib/rpm/__db.001, > which gets removed from the root filesystem at boot. > > In general I think there are problems with trying to do updates like > this if we don't have a pristine version of the current image (even when > using e.g. rsync and not updatinator), and we're currently modifying the > image all over the place (writing logs, removing rpm db files etc). What > is the current status of the vserver work? Perhaps we need to start > thinking about that stuff now so we can get robust updates... > > Anyway, the updatinator stuff is in git for people who'd like to play > with the code. I did an update from 530 -> 535 yesterday and it worked perfectly, preserving all my user data. Nice job. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Adding the olpc-register script to olpc-util
On Sat, 2007-07-28 at 11:43 -0400, C. Scott Ananian wrote:
> On 7/27/07, Nelson Elhage <[EMAIL PROTECTED]> wrote:
> > This is a patch to olpc-util to add a script to register the XO with
> > the schoolserver for purposes of backup for trial 2
> > (http://dev.laptop.org/ticket/24).
>
> > +sn = read_ofw('mfg-data/SN')
> > +uuid = read_ofw('mfg-data/U#')
>
> Certain old machines don't have SN or U# data. You should have
> read_ofw return None if the file it is looking for doesn't exist, and
> then follow the above two lines with:
>
> sn = sn or 'SHF'
> uuid = uuid or '----'
>
> That should make things work properly on B1s and hand-built
> preproduction machines, among others.
>
> We should think about how we handle a classroom full on B1s (which
> have no SN data) on the school server side. B1s do have UUID, so
> maybe we should create the schoolserver account based on the first 8
> characters of the UUID in this case. This shouldn't make a difference
> to the XO code, since the XO ought to take whatever account name the
> schoolserver gives it.
>
> I don't believe I have the bits to commit a patch to olpc-util. Could
> someone who does (danw? dcbw?) commit this and then ping me to let me
> know it's in?
We should probably do the fixes for B1s first...
I also apparently didn't get the first copy of this mail, not sure where
it went...
Dan
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Libertas firmware update testing
Hi, This firmware came in too late for the Trial-2 builds, but we'd like testing nonetheless. If anyone wants to give it a run, I've prepared an RPM you can install on the XO: wget http://people.redhat.com/dcbw/olpc/libertas-usb8388-firmware-5.110.17.p0-1.olpc1.noarch.rpm rpm -Uhv libertas-usb8388-firmware-5.110.17.p0-1.olpc1.noarch.rpm There aren't any really user-visible changes, but we're interested in things like if the wireless just goes off into la-la land, or other oddities of that nature. Thanks, Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Adding the olpc-register script to olpc-util
On Mon, 2007-07-30 at 14:08 -0400, Nelson Elhage wrote:
> Here's a fixed version of the patch.
Built as:
http://koji.fedoraproject.org/koji/taskinfo?taskID=84355
dan
> - Nelson
>
> On Mon, Jul 30, 2007 at 08:03:00AM -0400, Dan Williams wrote:
> > On Sat, 2007-07-28 at 11:43 -0400, C. Scott Ananian wrote:
> > > On 7/27/07, Nelson Elhage <[EMAIL PROTECTED]> wrote:
> > > > This is a patch to olpc-util to add a script to register the XO with
> > > > the schoolserver for purposes of backup for trial 2
> > > > (http://dev.laptop.org/ticket/24).
> > >
> > > > +sn = read_ofw('mfg-data/SN')
> > > > +uuid = read_ofw('mfg-data/U#')
> > >
> > > Certain old machines don't have SN or U# data. You should have
> > > read_ofw return None if the file it is looking for doesn't exist, and
> > > then follow the above two lines with:
> > >
> > > sn = sn or 'SHF'
> > > uuid = uuid or '----'
> > >
> > > That should make things work properly on B1s and hand-built
> > > preproduction machines, among others.
> > >
> > > We should think about how we handle a classroom full on B1s (which
> > > have no SN data) on the school server side. B1s do have UUID, so
> > > maybe we should create the schoolserver account based on the first 8
> > > characters of the UUID in this case. This shouldn't make a difference
> > > to the XO code, since the XO ought to take whatever account name the
> > > schoolserver gives it.
> > >
> > > I don't believe I have the bits to commit a patch to olpc-util. Could
> > > someone who does (danw? dcbw?) commit this and then ping me to let me
> > > know it's in?
> >
> > We should probably do the fixes for B1s first...
> >
> > I also apparently didn't get the first copy of this mail, not sure where
> > it went...
> >
> > Dan
> >
> >
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: olpc-redhat-stream-development-devel_ext3.img version info.
On Mon, 2007-08-06 at 08:51 +1000, James Cameron wrote: > On Sun, Aug 05, 2007 at 06:08:05AM -0800, C.W. Holeman II wrote: > > I have : > > olpc-redhat-stream-development-devel_ext3.img > > which I am running with qemu. How do I ask it what version it is? > > Mount this filesystem, then read the file /boot/olpc_build > > This problem was probably contributed to by your downloading of the file > using a name that didn't have a version number. The build output tree > has files with version numbers as well, and they give you the same data. > So once you identify the build, you could rename the file. > > I don't know if there is a need for unversioned image files, but it is > probably too much trouble to argue this point. This was done to allow a "latest" link that always grabbed the latest version, which is easiest done with a stable filename. Dan > The build output tree also now uses "osN.img" and "osN.crc" naming, for > the JFFS2 images, where N is the build number. > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Does sugar web browser support extensions?
On Tue, 2007-08-14 at 15:43 -0400, Samuel Klein wrote: > what was the reason not to support firefox addons again? Well, it's not really a decision, but more of a side-effect. The best and most flexible embedding technology to use is pyxpcom. We're embedding a Gecko engine into a different app, and this is of course not firefox. We are not using XUL as the UI toolkit, which is likely what most firefox addons require. It's sort of like Epiphany. You can't put firefox addons into epiphany because epiphany is actually native and doesn't use XUL. We are shipping xulrunner though, so it's conceivable that whenever a xulrunner-based FF comes out it'll just run with the xulrunner we've got, but be completely unsugared. Dan > firefox runs smoothly on my B4... and it's pretty great to have access > to Google Gears, for instance. > > SJ > > On 8/14/07, Noah Kantrowitz <[EMAIL PROTECTED]> wrote: > > If you mean normal Firefox add-ons. It does not. We use a simpler > > core called XULRunner. It does support extensions of a sort using > > PyXPCom, though I don't (yet) know much about those. > > > > --Noah > > > > On Aug 14, 2007, at 3:00 PM, Kleber Infante wrote: > > > > > Hi all, > > > > > > I saw in a post that Sugar web browser does not support extensions. > > > Is that true? > > > If it´s true, what can be done? > > > > > > I would like to know how to install an extension in XO browser. I > > > wanna try to port an Firefox extension to sugar browser. > > > > > > thanks > > > ___ > > > Devel mailing list > > > Devel@lists.laptop.org > > > http://lists.laptop.org/listinfo/devel > > > > ___ > > Devel mailing list > > Devel@lists.laptop.org > > http://lists.laptop.org/listinfo/devel > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Question about Libertas and anycast_mask
On Fri, 2007-08-31 at 10:03 -0400, John Watlington wrote: > Dan, > The Reliance team in India is having trouble getting the > anycast_mask flag set. > > A mesh interface is configured and up and running. They echo 1 > / > sys/class/net/msh0/anycast_mask, > but subsequent cat /sys/class/net/msh0/anycast_mask return 0. > > I've never run into this. Can anyone suggest why this is happening, > and how to fix it ? We need the kernel version and firmware version they are using. Are they on an XO? A school server? Have they modified anything? What's the git commit hash of the kernel, or the version of the kernel RPM? Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Marvell
On Mon, 2007-09-10 at 10:31 -0700, Edward Cherlin wrote: > As I understand it, the microkernel for the Marvell wireless chipset > is the only remaining proprietary software on the Laptop, and although > we want to get rid of it, nothing is happening. > http://dev.laptop.org/ticket/46 > Is that correct? > > Richard Stallman told me on Saturday that this is the only impediment > to him recommending the XO. Whatever your personal opinions about RMS > might be, he can be a valuable ally, and the price for his support is > quite modest, since we want to do this anyway. > > Several people have commented on the bug page that they want to work > on this piece of the problem, but nobody seems to have organized it. > I'm willing to be the focus of the effort. We need the Marvell > documentation, and the location of the code OLPC has written on top of > the microkernel. (Both easy enough, I assume.) Then we need a bit of > advice on what to use. TinyOS has been suggested. > > But first we need some commitment. Who would like to work on it? Who > would be willing to advise? Somebody needs to take ownership of the issue and run with it. There's no bandwidth right now to do that at OLPC. You might also note to RMS that the EC code is also not open, and of course neither of these two issues is any different than a generic laptop you buy off the street. If RMS can't recommend the XO to anyone, then he _certainly_ can't recommend a normal Thinkpad, Dell, HP, etc to anyone either, because they also contain proprietary, non OSS code in their ECs and other parts. I believe people are somewhat farther looking into open EC code than wireless firmware bits though. And it's not just the runtime firmware. Would RMS refuse to recommend the XO because the boot2 firmware that's burned into SPI flash on the wireless module (like our current firmware and EC firmware is) is not open even if the runtime wireless firmware was open? Dan > -- > Edward Cherlin > Earth Treasury: End Poverty at a Profit > http://wiki.laptop.org/go/Earth_Treasury > WIRE AFRICA http//www.wireafrica.org/ > http://www.linkedin.com/in/cherlin > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Marvell
On Mon, 2007-09-10 at 22:37 -0400, Albert Cahalan wrote: > Edward Cherlin writes: > > > We need the Marvell documentation, and the location of the code OLPC > > has written on top of the microkernel. (Both easy enough, I assume.) > > You'd think so, but nobody has coughed this up despite repeated pleas. > I can't even get the extra hardware I asked for, which gets to be > rather critical when the time comes to test what things do. > I also didn't get my project hosting request approved. > > Not that documentation is required; reverse engineering is fun. > > Martin Langhoff quoting Edward Cherlin: > > >> Who would like to work on it? > > > > I think that is the key problem. If someone can hack in that area > > (of which I only know enough to say that I cannot even get started), > > and is interested/motivated enough to do it, they'd be doing it already. > > The only thing you can do is roll up your sleeves and hack on it > > yourself if you can, and start posting code and notes. > > Indeed. Join the party. Notes are here: > http://wiki.laptop.org/go/88W8388 > > For those who haven't ever tried it: reverse engineering is fun! > It's a really intense mental activity. Unlike regular coding, it's > even more fun with a friend. It would make a wonderful activity > for sharing over the mesh. Of course, it's still plenty of fun all > by yourself as you empty a 12-pack of Mountain Dew at 4:00 AM. > Nothing is better for satisfying a hard-core hacking urge. > > At least initially, you don't even need hardware for this. You can > post your discoveries right here, anonymously if you prefer. Just > get the firmware files and go for it. > > BTW, if any of you are in the USA and start really enjoying this > kind of thing, I can probably get you a job doing it full-time. > > Bernardo Innocenti writes: > > > Implementing the whole 802.11 protocol stack and doing that without > > any documentation of the MAC hardware and maybe with no access to > > fancy RF equipment for testing the output... > > > > ...*that* would be no fun! Or maybe a lot of fun, depending on > > how much you like challenges! > > It is fun as long as you believe that the effort is appreciated and > that documentation will not appear without your efforts. > > It is even more fun if you can discover dark secrets, such as when > somebody spotted Marvell using the GPL eCos OS for a different chip. > That guy even had the balls to attack the firmware with objdump. > Most people prefer an interactive disassembler like IDA or ChARMeD. > > Dan Williams writes: > > > Somebody needs to take ownership of the issue and run with it. > > There's no bandwidth right now to do that at OLPC. > > No problem. Please approve the hosting request. Also, I can only > do so much without hardware. Ideally I'd have hardware to spare, > because it is possible to scramble the boot2 firmware and may > even be possible to do other hardware damage. I'll certainly need > something to sniff mesh packets, and doing the mesh protocol will > not work without enough devices for a mesh. > > > And it's not just the runtime firmware. Would RMS refuse to > > recommend the XO because the boot2 firmware that's burned > > into SPI flash on the wireless module > > Maybe. In any case, open boot2 firmware would be a good idea. > Somebody needs to find a way to unbrick a chip with messed-up > boot2 firmware. This is "simple". You unsolder the SPI flash from the 8388 board and solder in a freshly programmed SPI flash chip (or the bricked one just fixed). For this of course you need some soldering skills, and an SPI flash programmer. We've bricked SPI flash before and done this procedure to figure out exactly _why_ the flash was bricked (the updater didn't wait long enough for the 8388 to write the new boot2 to the SPI flash) and then to resurrect the part. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: More 16 vs 24 bpp profiling
On Tue, 2007-09-11 at 13:03 -0400, Bernardo Innocenti wrote:
> (adding xorg-devel@ on Cc)
>
> On 09/11/2007 11:29 AM, Jordan Crouse wrote:
> > On 11/09/07 13:05 +0200, Stefano Fedrigo wrote:
> >> I've done some more profiling on the 16 vs. 24 bpp issue.
> >> This time I used this test:
> >> https://dev.laptop.org/git?p=sugar;a=blob;f=tests/graphics/hipposcalability.py
> >>
> >> A simple speed test: I measured the time required to scroll down and up
> >> one time all the generated list. Not extremely accurate, but I repeated
> >> the
> >> test a few times with consistent results (+- 0.5 secs). Mean times:
> >>
> >> xserver 1.4
> >> 16 bpp: 37.9
> >> 24 bpp: 40.7
> >>
> >> xserver 1.3
> >> 16: 46.4
> >> 24: 50.1
> >>
> >> At 24 bpp we're a little slower. 1.3 is 20% slower than 1.4. The pixman
> >> migration patch makes the difference: 1.3 spend most of that 20% in
> >> memcpy().
> >>
> >> The oprofile reports are from xserver 1.4. I don't see much difference
> >> between 16 and 24, except that at 24 bpp, less time is spent in pixman and
> >> more
> >> in amd_drv. At 16 bpp pixman_fill() takes twice the time.
> >>
> >> Unfortunately without a working callgraph it's not very clear to me what's
> >> happening in amd_drv. At 24bpp gp_wait_until_idle() takes twice the
> >> time...
> >
> > What can we do to fix this? I would really like to know who is calling
> > gp_wait_until_idle().
>
> I think the invocation in lx_get_source_color() can safely
> go away, as exaGetPixmapFirstPixel() has always done
> correct locking even in 1.3.
>
> But because the1x1 source pixmap used as solid color is
> still being uploaded to the framebuffer, I'd expect
> exaGetPixmapFirstPixel() to indirectly call the driver
> download hook and, thus, stall the GPU anyway.
>
> If this tiny pixmap was at least reused, the second
> time it would be already in system memory. And it
> seems that Cairo is trying to cache patterns in the CR.
>
> Problem is, many GTK widgets like to create a new CR on every
> repaint event, thus rendering the cache quite effective for a
> typical workload of a window with several small widgets in it.
> But I've stumbled in the caching code a few months ago while
> debugging something else, so I may very well be mistaken.
>
> On git's master, Michel Dänzer has recently been pushing
> a long run of EXA performance patches. I've had only a
> quick glance, but it seems they may cure
>
> $ git-log 8cfcf9..e8093e | git-shortlog
> Michel Dänzer (14):
> EXA: Track valid bits in Sys and FB separately.
> Add DamagePendingRegion.
> EXA: Support partial migration of pixmap contents between Sys and FB.
> EXA: Hide pixmap pointer outside of exaPrepare/FinishAccess whenever
> possible.
> EXA: Improvements for trapezoids and triangles.
> EXA: exaImageGlyphBlt improvements.
> EXA: Improvements for 1x1 pixmaps.
> EXA: RENDER improvements.
> EXA: Remove superfluous manual damage tracking.
> EXA: exaGetImage improvements.
> EXA: exa(Shm)PutImage improvements.
> EXA: Use exaShmPutImage for pushing glyphs to scratch pixmap in
> exaGlyphs.
> EXA: exaFillRegion{Solid,Tiled} improvements.
> EXA: Exclude bits that will be overwritten from migration in
> exaCopyNtoN.
>
>
> Aleph, I guess it may be useful to re-run tests after applying
> these patches. In case merging them on the 1.4 branch happens
> to be difficult, using the code from master should be ok.
> They don't seem to have diverged too much, yet.
>
>
> > Also, I think we're spending way too much time in
> > gp_color_bitmap_to_screen_blt() - is there any way we
> > can get more indepth profiling in that one function?
>
> Good idea!
>
> Meanwhile, I looked at gp_color_bitmap_to_screen_blt() and it
> seems we're issuing a separate blit per horizontal line of the
> source data. That is correct for the general case, where the
> destination width may not match the source pitch.
>
> However, when we invoke gp_color_bitmap_to_screen_blt() for
> uploads, I'd expect the destination buffer to match the source,
> so a single blit would work.
>
> If my guess is right, special casing "pitch == width*bpp"
> would be a big win. Anyone minds adding an ErrorF()?
>
>
> NOTE ALEPH: I think we stopped development in the xf86-amd-devel
> repo some time ago. The correct driver nowadays would be the
> fd.o one. Jordan, do you confirm this?
Would be nice to know since I'll need to know where to get the sources
for the RPM updates from... But ISTR mail about this to this to
xorg-devel@ last month, I think you're right.
Dan
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: More 16 vs 24 bpp profiling
On Tue, 2007-09-11 at 14:19 -0400, Bernardo Innocenti wrote: > On 09/11/2007 01:32 PM, Bernardo Innocenti wrote: > > > The 16bpp codepath has to be broken somewhere if > > it takes twice the time to copy half the bits :-) > > It strikes me that we don't see any time spent in > pixman_fill_mmx(), even though it's not inlinable. > > For some reason, pixman thinks it cannot accelerate > 16bpp fills with MMX, at least on the Geode. > > Might be worth investigating... We did have to patch the MMX check in pixman long ago, maybe that got broken somehow? There were actually two, an update to the cpu flags and also a strcmp() on the processor ID that had to be fixed to get pixman to detect MMX capability on the geode. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Marvell
On Thu, 2007-09-13 at 12:27 +0200, David Woodhouse wrote: > On Thu, 2007-09-13 at 06:12 -0400, Bernardo Innocenti wrote: > > > There was an alternative libertas driver which uses the device in 'dumb' > > > mode with the kernel's mac80211 stack. Coupled with mesh support in > > > mac80211 that might make a somewhat suboptimal alternative to truly free > > > firmware. > > > > Fascinating. This way at least we use a smaller portion of the closed > > firmware. Where is this driver maintained? > > 'Maintained' is a bit of a strong word what we have is found at > http://lists.infradead.org/pipermail/libertas-dev/2007-August/000641.html That's the 8335 though, which is much more of a softmac part than the 8388. The two are not driver level or firmware level compatible :( Dan > > And is mesh networking really (going to be) supported in softmac? > > It's a safe bet that the mac80211 stack will grow 802.11s support at > some point. It may well be useful for us to do it relatively soon. We > could use _any_ Linux-supported softmac card to interact with the mesh > that way. > > > I'd suggest whoever starts a firmware rewriting effort to go this > > route, at least initially. So they can relay on known-good mac80211 > > code while rewriting just a tiny low-level RF driver. > > s/known-good/debuggable/ -- and it might not require too many changes to > the existing firmware. > > In the long run, softmac¹ definitely isn't the way to go for XO -- even > if you switch it to being completely autonomous while the XO is off, you > just don't want to be processing all the infrastructure stuff on the > Geode. For _debugging_ generic mesh stuff, however, I suspect that's > precisely how we want it. > > When it comes to time to thinking about Gen2... CSR have fullmac devices > and a whole lot of Linux clue. Definitely worth investigating. > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: wireless networking
On Thu, 2007-09-13 at 14:08 +0100, Victor Lazzarini wrote: > Hi all, > > Got the delivery of two B4 machines and joined the list today. I am > trying to test the system, so would like to get some help. I am > starting with networking; I have not yet updated to the latest OS image, > though. > > I got the two machines side by side. Shouldn't they see each other > in Sugar's neighboorhood? > > I opened the terminal and set them to the same essid but still no sign. Yes, iwconfig is incompatible with NetworkManager because iwconfig changes the parameters underneath NM. You also need an IP address before the two will talk, and when NM manages the connection, it'll do that for you automatically. If you connect them both to the same AP using the GUI, or you remove the saved network config bits in ~/.sugar/default/nm/networks and just start them up and wait a while, they will fall back to channel 1 and mesh with each other. Dan > Also, should they not see other AdHoc machines around them (say > other windows, linux, OSX). > > Suggestions? > > Victor > Victor Lazzarini > Music Technology Laboratory > Music Department > National University of Ireland, Maynooth > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: wireless networking
On Thu, 2007-09-13 at 19:52 +0100, Victor Lazzarini wrote: > Thanks, I am now seeing my wireless router on > the machines and can ping other machines connected > to it. Wired internet seems to work (as far as ifconfig > and ping are concerned). > > Two questions: > > 1. How should I set my hostname and fix it to work > with DHCP? The hostname isn't changed by NM because that breaks Xauth and stops you from being able to launch X apps. I'd say don't set a custom hostname; if you're using DHCP then you either (a) won't get the same IP address each time, or (b) you've set up the DHCP server to provide a "static" IP anyway. > 2. How do I add DNS servers? I had a look at the > obvious place, /etc/resolv.conf, but there is > comment saying that it should not be edited (although > the file was empty). Add these to your DHCP server's DNS server list. > and a third one: how do I set http proxies for the > browser? That is the only way they allow me out of the > lab network. I think yum should work fine through the > proxy once I have everything set up correctly with the > wired network. I think yum can be set up to use HTTP proxies in it's conf file. Dan > Thanks a lot for the assistance. > > Victor > > > > > On Thu, 2007-09-13 at 14:08 +0100, Victor Lazzarini wrote: > > > Hi all, > > > > > > Got the delivery of two B4 machines and joined the list > > > today. I am trying to test the system, so would like to > > > get some help. I am starting with networking; I have not > > > yet updated to the latest OS image, though. > > > > > > I got the two machines side by side. Shouldn't they see > > > each other in Sugar's neighboorhood? > > > > > > I opened the terminal and set them to the same essid but > > still no sign. > > > > Yes, iwconfig is incompatible with NetworkManager because > > iwconfig changes the parameters underneath NM. You also > > need an IP address before the two will talk, and when NM > > manages the connection, it'll do that for you > > automatically. > > > > If you connect them both to the same AP using the GUI, or > > you remove the saved network config bits in > > ~/.sugar/default/nm/networks and just start them up and > > wait a while, they will fall back to channel 1 and mesh > > with each other. > > > > Dan > > > > > Also, should they not see other AdHoc machines around > > > them (say other windows, linux, OSX). > > > > > > Suggestions? > > > > > > Victor > > > Victor Lazzarini > > > Music Technology Laboratory > > > Music Department > > > National University of Ireland, Maynooth > > > > > > ___ > > > Devel mailing list > > > Devel@lists.laptop.org > > > http://lists.laptop.org/listinfo/devel > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Anybody do BGA rework?
On Fri, 2007-09-14 at 00:36 -0400, Albert Cahalan wrote: > I'm wondering if one could replace the 88W8385 > on a gumstix board with an 88W8388 swiped from > an Xbox 360 wireless device. > > They appear to be the same chip package. This of > course does not ensure that enough of the > connections are compatible, but I think there is > reason to be optimistic. Seems to me it would be easier to either: 1) replace the SPI flash on the XBox 360 adapter (should be a 6 or 8 pin part) with one from an XO or flashed another SPI chip with the XO boot2 (as long as the Boot1 code in ROM on the 8388 itself doesn't verify boot2, which it may do for XBox, who knows) 2) unsolder the wireless daughterboard from an XO and hook up a cut USB cable to the right pins on the daughterboard. If you want USB back you should just be able to plug the USB cable into the XO and it'll work. So you don't really destroy the wireless capability of the XO here. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: wireless networking
On Mon, 2007-09-17 at 06:55 -0400, Jim Gettys wrote: > On Thu, 2007-09-13 at 16:10 -0400, Dan Williams wrote: > > On Thu, 2007-09-13 at 19:52 +0100, Victor Lazzarini wrote: > > > Thanks, I am now seeing my wireless router on > > > the machines and can ping other machines connected > > > to it. Wired internet seems to work (as far as ifconfig > > > and ping are concerned). > > > > > > Two questions: > > > > > > 1. How should I set my hostname and fix it to work > > > with DHCP? > > > > The hostname isn't changed by NM because that breaks Xauth and stops you > > from being able to launch X apps. > > I thought this got fixed in X quite a while ago (something like 18 > months ago). It certainly used to be a PITA. Certainly not fixed, I just tested it out and it fails miserably. It is a PITA. Somebody who knows X needs to fix Xauth to not rely on hostnames. The xauth cookie depends on the hostname of the machine at the time xinit gets run, so we either need to change our xinit stuff to put 127.0.0.1 there for a hostname, or suck up the fact that changing the hostname kills the ability to start X apps. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: radio off guarantee?
On Tue, 2007-09-18 at 18:52 +0200, [EMAIL PROTECTED] wrote: > moin, > > On Tue, 18 Sep 2007 14:42:51 +1000 > James Cameron <[EMAIL PROTECTED]> wrote: > > > > Do we need a solid way to turn off the RF before it's OK to use an XO > > > on an airplane? > > > > Our target market usually won't have this problem. > > Yes, but the developers need a solid way to switch of the RF. The Test XO > target market are developers and sometimes they travel by air. > > Javier wrote: > # killall NetworkManager > # iwpriv eth0 radiooff > > How could we ensure not bringing up the RF at boot time? Which file takes > care of this at fedora systems? Add a hardware killswitch if you want to be 100% sure. There is no single file that "takes care of this" on any system really. But if you remove the kernel modules, firmware will not get uploaded to the card, and therefore the radio will essentially do nothing AFAIK. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: radio off guarantee?
On Tue, 2007-09-18 at 15:33 -0400, Richard A. Smith wrote: > John Watlington wrote: > > > While it makes sense to turn off the wireless networking interface on > > developer > > So there's a slight problem with powering off the wireless interface > from an electrical standpoint. You can't. > At least not if you want a working system. > > WLAN_EN controls WLAN_3.3V. +3.3V is derived from WLAN_3.3V. So if you > drop WLAN_3.3V you lose +3.3V and you also lose: > > VDDIO on the LX700 > Pullups on the PCI bus. > Pullups on the jtag lines > Supply voltages for COREPLL, GLPLL, and DOTPLL on the LX700 > Power supply to the LX700 Therm alarm circuits > Power supply to the system clock chip. > > And lots of other stuff...you get the idea. System no workie. > > That leaves 3 alternatives: > > 1 Don't load the wlan firmware. > 2 Load the firmware and tell wlan xmit to shutdown > 3 Hold the WLAN module in reset. > > #3 Can be done via the EC but there's currently not a command to _hold_ > it in reset. There is a reset WLAN command which will strobe the reset > line for 1ms. I can add enable/disable reset commands if 1 and 2 are > not viable. 1 and 2 are certainly viable and should be the preferred methods I think. Note that right now trying to rmmod usb8xxx panics the kernel for some reason. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power envelope (was Re: radio off guarantee?)
On Tue, 2007-09-18 at 12:12 -0400, Mike C. Fletcher wrote: > John Watlington wrote: > >>> Suppose I'm someplace where I don't expect or want to do any mesh > >>> networking. > >>> How much would turning off the radio help battery life? > >>> > >> Last I checked, the effect was very small. There will be occasional > >> scans as the unit hunts around for nearby radios. One could save more > >> by making those scans back off rather than provide a UI element. > >> > > > > We see 700 to 800 mW consumed by the mesh interface, and as with most > > WiFi interfaces, receiving consumes as much power as transmitting. > > > Isn't that about 1/2 of our total power budget? .7 to .8 W on a < 2W > machine? I'd thought the Marvell chip was supposed to be down in the > .3W range. Obviously haven't been following the hardware closely The .3W number is applicable to _infrastructure_ mode with the Marvell part, because the device (like most 802.11 devices) can go into powersave poll mode when in a BSS. In ad-hoc situations, of course, there is no central controller buffering frames and sending out the TIM and therefore you have to have your RX pieces powered on most of the time to receive traffic from other stations, or you start missing frames entirely. You can't use the same powersave algorithms in a mesh (or adhoc even) network as you can use in an infrastructure network. Of course everything in the world right now pretty much uses infrastructure networks, and so the powersave algorithms are tuned for that. But mesh requires new powersave algorithms, or at least an implementation of existing algorithms. There's enough work getting the mesh implemented and working well right now without throwing power algorithms into the mix. Dan > enough. (http://wiki.laptop.org/go/Power_Management is where I got the > .3W idea). Is that .7W something we'll be able to bring down with > software to reduce collisions or the like? University of Toronto's > system's group has algorithms that optimise for power savings by > reducing collisions, if that would help. > > From the same page, we'd only last 20 hours at ~.7W draw with a *full* > charge (and with hand-charging a full charge likely won't be there, > especially at the end of the day), which means that the machines are > going to be dead each morning (having drained their batteries keeping up > an unused network all night). With a 40 hour period (.3W) we were > possibly going to have some juice left in the morning (need to be at > > 1/4 power when you shut off for the night), but that becomes less likely > with a 20 hour period (need to be at >1/2 power when you shut off for > the night). > > While it makes sense to turn off the wireless networking interface on > > developer > > machines, we are hesitant to add this to the UI. We are really > > relying on laptops > > to extend the mesh away from the school. > > > If we really are spending half our power budget on the mesh network I > would imagine that kids will want to be able to turn it off. Yes, > meshing is good, but if you could double your battery life while you're > at home reading, that would be very worthwhile too. What about *only* > keeping the mesh up (continuously) if you are actually routing packets? > > That is, wake up the mesh interface every few minutes, check to see if > your new routing structure makes you a link that is desirable, and only > stay on if that's the case. (I realise I'm talking about long-term > projects here). You'd need the machines to be able to queue up messages > to go out so that they could leap at the request and say "yes, please > stay up" when a linking machine pops on to check for need (implying from > activity requests on the local machine would be likely be sufficient, > but a simple UI might be workable too). If the network is inactive for > X period, go into periodic sleep mode again to save energy. > > Even if you had to wake up the processor for a few seconds to run the > code that decides whether to sleep, it's only about double the power of > running the mesh for those seconds, and it could save you the entire > power budget for a few minutes. Of course, in the field it may be that > the mesh is so densely used that it's never going to go down with that > algorithm, but it seems like something we need to investigate if we > really are losing that much power to the interface. > > Just a thought, > Mike > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #3593 NORM Trial-3: Mesh channel randomization breaks NM 'mesh-start' tweakable
On Wed, 2007-09-19 at 06:18 -0400, Walter Bender wrote:
> I would recommend not making the patch; I think I found it confusing
> only because I didn't know that random impacted link-local. But do we
> still default to channel 1 if no school server is found?
No, I'm not confident that we do.
Dan
> -walter
>
> On 9/18/07, Zarro Boogs per Child <[EMAIL PROTECTED]> wrote:
> > #3593: Mesh channel randomization breaks NM 'mesh-start' tweakable
> > -+--
> > Reporter: dcbw | Owner: jg
> > Type: defect | Status: new
> > Priority: normal | Milestone: Trial-3
> > Component: network manager | Version:
> > Keywords: |Verified: 0
> > -+--
> > Since we switched back to randomized mesh channels two weeks ago at the
> > request of the server team, this inadvertently broke expectations about
> > how the /etc/NetworkManager/mesh-start file affects things when using
> > local-only. In this case, if you do local-only through mesh-start, you
> > are not guaranteed to come up on channel 1 because the start channel is
> > random.
> >
> > Please determine if this is trial-3 material or not. Obviously, the
> > factors against fixing this for trial-3 are that:
> >
> > 1) our target users for trial 3 aren't expected to have to do this
> > 2) you can always switch directly to mesh-1 from the UI
> > 3) we are in code freeze
> >
> > However, the fix is low-risk and does not affect normal codepaths.
> >
> > ```
> > Index: src/nm-device-802-11-mesh-olpc.c
> > ===
> > --- src/nm-device-802-11-mesh-olpc.c(revision 2824)
> > +++ src/nm-device-802-11-mesh-olpc.c(working copy)
> > @@ -459,7 +459,10 @@
> > self->priv->use_mesh_beacons = TRUE;
> > }
> >
> > - self->priv->channel = get_random_channel ();
> > + if (self->priv->default_first_step == MESH_S4_P2P_MESH)
> > + self->priv->channel = 1;
> > + else
> > + self->priv->channel = get_random_channel ();
> >
> > self->priv->activation_started_ids = g_hash_table_new
> > (g_direct_hash,
> > g_direct_equal);
> > @@ -1718,7 +1721,10 @@
> > nm_device_set_active_link (NM_DEVICE (self), FALSE);
> > if (reinit_state) {
> > self->priv->step = self->priv->default_first_step;
> > - self->priv->channel = get_random_channel ();
> > + if (self->priv->default_first_step ==
> > MESH_S4_P2P_MESH)
> > + self->priv->channel = 1;
> > + else
> > + self->priv->channel = get_random_channel
> > ();
> > self->priv->chans_tried = 0;
> > self->priv->channel_locked = FALSE;
> > }
> > @@ -1754,7 +1760,10 @@
> > self->priv->channel =
> > nm_act_request_get_mesh_channel (req);
> > self->priv->channel_locked = TRUE;
> > } else {
> > - self->priv->channel = get_random_channel ();
> > + if (self->priv->default_first_step ==
> > MESH_S4_P2P_MESH)
> > + self->priv->channel = 1;
> > + else
> > + self->priv->channel = get_random_channel
> > ();
> > }
> > }
> > ```
> >
> > --
> > Ticket URL:
> > One Laptop Per Child
> > OLPC bug tracking system
> >
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: #3593 NORM Trial-3: Mesh channel randomization breaks NM 'mesh-start' tweakable
On Wed, 2007-09-19 at 07:50 -0400, Dan Williams wrote:
> On Wed, 2007-09-19 at 06:18 -0400, Walter Bender wrote:
> > I would recommend not making the patch; I think I found it confusing
> > only because I didn't know that random impacted link-local. But do we
> > still default to channel 1 if no school server is found?
>
> No, I'm not confident that we do.
I should add that this was likely an oversight and is quite easy to
correct.
>
> Dan
>
>
> > -walter
> >
> > On 9/18/07, Zarro Boogs per Child <[EMAIL PROTECTED]> wrote:
> > > #3593: Mesh channel randomization breaks NM 'mesh-start' tweakable
> > > -+--
> > > Reporter: dcbw | Owner: jg
> > > Type: defect | Status: new
> > > Priority: normal | Milestone: Trial-3
> > > Component: network manager | Version:
> > > Keywords: |Verified: 0
> > > -+--
> > > Since we switched back to randomized mesh channels two weeks ago at the
> > > request of the server team, this inadvertently broke expectations about
> > > how the /etc/NetworkManager/mesh-start file affects things when using
> > > local-only. In this case, if you do local-only through mesh-start, you
> > > are not guaranteed to come up on channel 1 because the start channel is
> > > random.
> > >
> > > Please determine if this is trial-3 material or not. Obviously, the
> > > factors against fixing this for trial-3 are that:
> > >
> > > 1) our target users for trial 3 aren't expected to have to do this
> > > 2) you can always switch directly to mesh-1 from the UI
> > > 3) we are in code freeze
> > >
> > > However, the fix is low-risk and does not affect normal codepaths.
> > >
> > > ```
> > > Index: src/nm-device-802-11-mesh-olpc.c
> > > ===
> > > --- src/nm-device-802-11-mesh-olpc.c(revision 2824)
> > > +++ src/nm-device-802-11-mesh-olpc.c(working copy)
> > > @@ -459,7 +459,10 @@
> > > self->priv->use_mesh_beacons = TRUE;
> > > }
> > >
> > > - self->priv->channel = get_random_channel ();
> > > + if (self->priv->default_first_step == MESH_S4_P2P_MESH)
> > > + self->priv->channel = 1;
> > > + else
> > > + self->priv->channel = get_random_channel ();
> > >
> > > self->priv->activation_started_ids = g_hash_table_new
> > > (g_direct_hash,
> > > g_direct_equal);
> > > @@ -1718,7 +1721,10 @@
> > > nm_device_set_active_link (NM_DEVICE (self), FALSE);
> > > if (reinit_state) {
> > > self->priv->step =
> > > self->priv->default_first_step;
> > > - self->priv->channel = get_random_channel ();
> > > + if (self->priv->default_first_step ==
> > > MESH_S4_P2P_MESH)
> > > + self->priv->channel = 1;
> > > + else
> > > + self->priv->channel = get_random_channel
> > > ();
> > > self->priv->chans_tried = 0;
> > > self->priv->channel_locked = FALSE;
> > > }
> > > @@ -1754,7 +1760,10 @@
> > > self->priv->channel =
> > > nm_act_request_get_mesh_channel (req);
> > > self->priv->channel_locked = TRUE;
> > > } else {
> > > - self->priv->channel = get_random_channel ();
> > > + if (self->priv->default_first_step ==
> > > MESH_S4_P2P_MESH)
> > > + self->priv->channel = 1;
> > > + else
> > > + self->priv->channel = get_random_channel
> > > ();
> > > }
> > > }
> > > ```
> > >
> > > --
> > > Ticket URL: <https://dev.laptop.org/ticket/3593>
> > > One Laptop Per Child <https://dev.laptop.org>
> > > OLPC bug tracking system
> > >
> >
> >
>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: FreeBe, Displaylink
On Wed, 2007-09-26 at 06:52 -0700, big one wrote: > > No VGA/EGA/CGA. > > This is some sort of free VESA BIOS and the author said the source code can > be ported to Linux platform: > > http://www.talula.demon.co.uk/freebe/ > > Another option is virtual graphics card (VGC) from Displaylink. The actual > chipset is located on remote display unit such as Samsung SyncMaster 940UX. > > http://www.displaylink.com > > Can the above product be used with public version of OLPC XO laptops? Why don't you tell us what higher level goal you are trying to achieve, instead of continually posting lower level stuff? It would probably save time. Are you just trying to run old DOS apps on the XO? Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Marvell
On Thu, 2007-09-27 at 19:52 +1000, Alex Gibson wrote: > Javier Cardona wrote: > > On 9/13/07, Bernardo Innocenti <[EMAIL PROTECTED]> wrote: > > > >> Are there patents on 802.11s? Even though > >> it's an IEEE standard? > >> > > > > http://standards.ieee.org/db/patents/pat802_11.html > > > > Scroll down to 802.11s. Apple, Microsoft and Fujitsu do at least > > provide the patent/application number. The other 8 companies will > > probably wait until the standard is ratified. That gives them more > > "leverage". > > > > > > > Don't forget the Australian CSIRO holds key patents that 802.11 is built on. Clarification; I believe that's _802.11n_, right? Or at most 802.11 a/g/n. I believe any patents that might allegedly cover WiFi are related to OFDM modulation which plain 802.11b does not use. Dan > Hence all the wireless chipset providers and users(device manufacturers) > in trouble for knowingly infringing the CSIRO patent/s. > > http://www.theregister.co.uk/2007/09/21/802_11n_patent_threat/ > http://www.wi-fiplanet.com/news/article.php/3647841 > > http://news.zdnet.com/Wi-Fi+standards+face+patent+threat/2100-9595_22-6137372.html?part=netscape-zdnet&tag=mynetscape&subj=technews > > http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=5,487,069.PN.&OS=PN/5,487,069&RS=PN/5,487,069 > > > > -- > UTS CRICOS Provider Code: 00099F > DISCLAIMER: This email message and any accompanying attachments may contain > confidential information. If you are not the intended recipient, do not > read, use, disseminate, distribute or copy this message or attachments. If > you have received this message in error, please notify the sender > immediately and delete this message. Any views expressed in this message > are those of the individual sender, except where the sender expressly, and > with authority, states them to be the views the University of Technology, > Sydney. Before opening any attachments, please check them for viruses and > defects. > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh driver in ubuntu
On Wed, 2007-09-26 at 15:22 -0400, Polychronis Ypodimatopoulos wrote:
> I have Ubuntu 7.04 with 2.6.20-16 and want to use the 8388 USB module
> with my system. I guess I either need to jump to 2.6.22, or compile the
> driver for 2.6.20. I would prefer the second as the upstream version of
> the driver does not come with all the features I need. So, do I just get
> the driver and compile it? Any directions on the wiki?
There are a few things to do if you really want to build the driver for
2.6.20. Off the top of my head:
1) set 'skb->dev = ...' in libertas_upload_rx_packet() in rc.c to ensure
the skb device is correct, which kernels < 2.6.22 don't do (patch
attached)
2) you'll run into an undefined radiotap flag (patch attached)
3) sysfs classdev changes in main.c and possibly debugfs.c (I don't have
patch for this any more)
Dan
diff --git a/drivers/net/wireless/libertas/rx.c b/drivers/net/wireless/libertas/rx.c
index b5beaa1..6f35607 100644
--- a/drivers/net/wireless/libertas/rx.c
+++ b/drivers/net/wireless/libertas/rx.c
@@ -138,10 +138,13 @@ void libertas_upload_rx_packet(wlan_private * priv, struct sk_buff *skb)
{
lbs_deb_rx("skb->data %p\n", skb->data);
- if (priv->mesh_dev && IS_MESH_FRAME(skb))
+ if (priv->mesh_dev && IS_MESH_FRAME(skb)) {
+ skb->dev = priv->mesh_dev;
skb->protocol = eth_type_trans(skb, priv->mesh_dev);
- else
+ } else {
+ skb->dev = priv->dev;
skb->protocol = eth_type_trans(skb, priv->dev);
+ }
skb->ip_summed = CHECKSUM_UNNECESSARY;
netif_rx(skb);
@@ -368,6 +371,15 @@ static int process_rxed_802_11_packet(wlan_private * priv, struct sk_buff *skb)
/* XXX must check this value for pad */
radiotap_hdr.hdr.it_pad = 0;
radiotap_hdr.hdr.it_len = sizeof(struct rx_radiotap_hdr);
+#define IEEE80211_RADIOTAP_RX_FLAGS 14
+/* For IEEE80211_RADIOTAP_RX_FLAGS */
+#define IEEE80211_RADIOTAP_F_RX_BADFCS 0x0001 /* frame failed crc check */
+
+/* For IEEE80211_RADIOTAP_TX_FLAGS */
+#define IEEE80211_RADIOTAP_F_TX_FAIL 0x0001 /* failed due to excessive
+ * retries */
+#define IEEE80211_RADIOTAP_F_TX_CTS 0x0002 /* used cts 'protection' */
+#define IEEE80211_RADIOTAP_F_TX_RTS 0x0004 /* used rts/cts handshake */
radiotap_hdr.hdr.it_present = RX_RADIOTAP_PRESENT;
/* unknown values */
radiotap_hdr.flags = 0;
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: mesh driver in ubuntu
On Tue, 2007-10-02 at 07:49 +1000, Joel Stanley wrote: > On 9/27/07, Polychronis Ypodimatopoulos <[EMAIL PROTECTED]> wrote: > > I have Ubuntu 7.04 with 2.6.20-16 and want to use the 8388 USB module > > with my system. I guess I either need to jump to 2.6.22, or compile the > > driver for 2.6.20. I would prefer the second as the upstream version of > > the driver does not come with all the features I need. So, do I just get > > the driver and compile it? Any directions on the wiki? > > I got the USB module working with the stock Ubuntu Gutsy kernel. > > I'm not sure if it was necessary, but as the md5 of the ubuntu > usb8388.bin didn't match anything I could find, I updated with the > firmware from a recent OLPC build. > > copy xo:/lib/firmware/usb8388.bin to ubuntu:/lib/firmware/'uname > -r'/usb8388.bin, plug in your USB dongle, you should be good to go. They may be using the older usb8388 firmware from last summer that you can download directly from the Marvell site. http://www.marvell.com/drivers/driverDisplay.do?dId=160&pId=38 Marvell posted 5.110.17.p2 firmware in august. Also, any firmware that OLPC makes available may be redistributed by others (like distros) without needing any permission or anything from Marvell (thanks to blizzard & marvell for working this out). dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: retrieving the activity bundle directory
On Thu, 2007-10-11 at 14:29 +0100, Victor Lazzarini wrote: > Hi everyone, > > does anyone know if is there a way to retrieve the > activity bundle top directory name under python/sugar? You should be able to: from sugar.activity import activity my_bundle_path = activity.get_bundle_path() Dan > Thanks > > Victor > Victor Lazzarini > Music Technology Laboratory > Music Department > National University of Ireland, Maynooth > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
On Thu, 2007-10-25 at 10:15 +0100, Simon McVittie wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > We still have one set of OLPC-specific patches to Salut (the link-local > collaboration backend) that has been rejected upstream, which is the one > that adds support for the deprecated ip4-address buddy property. This was > used during a transitional period to enable simple TCP-based collaboration > for activities that didn't use Tubes; Sjoerd is reluctant to keep this > patch set, because it's meant to have gone away by now! Erik ported Read over to tubes and is working on the camera app AFAIK. I'm not sure if the read bits went into git though? There were some small issues with the patch that needed be corrected before pushing to git for Read. One other user might be Etoys. Dan > Is anyone still using this property? If not, can we kill it? It was > added in Trial-2, and it was meant to be gone by Trial-3 but was left in > just in case, so it really ought to disappear. When it does, we can > delete some code from Salut and Presence Service. > > Places it's exposed in the APIs, which I propose to get rid of: > > PS D-Bus API: Buddy.GetProperties() returns a dict that contains > "ip4-address": "10.0.0.1" (or whatever), and Buddy.PropertyChanged > signal includes a dict that can contain the same > > sugar.presence: Buddy has a GLib property "ip4-address" (aka > buddy.props.ip4_address) and can emit it in its property-changed signal > > The Read activity appears to be the only thing in my jhbuild that uses > ip4-address (#4297). It should be ported to either stream tubes (when they're > ready in Salut, which should be this or next week) or D-Bus tubes (now). > > Gabble already supports stream tubes, so stream-tube support can be > implemented on a branch and tested against Gabble. Porting from plain TCP > to stream tubes should be very straightforward; I hope to produce a > proof-of-concept patch for Read later today. > > Simon > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net > > iD8DBQFHIF7HWSc8zVUw7HYRAvp6AJ9G/Xiw27pPPMm0g02vhXzRhzUxqwCfW27Z > nh1B/wqe7GD/xf/YaOPVaw8= > =42L7 > -END PGP SIGNATURE- > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Configurable beacon interval
On Wed, 2007-10-24 at 15:42 -0700, Javier Cardona wrote:
> From: Brajesh Dave <[EMAIL PROTECTED]>
>
> See https://dev.laptop.org/ticket/2750#comment:12
>
> Requires firmware version 5.110.19.p0 or newer, available here:
> http://dev.laptop.org/pub/firmware/libertas/
What I'd like to do with patches from now on (now that Libertas is fully
merged upstream) is to split out the OLPC specific parts (like the
ioctls) and channel those directly into olpc-2.6 through Andres, but
push the generic bits straight to linux-wireless and John Linville. I'd
like to get rid of libertas-2.6 alltogether, and if people have
individual enhancements that they want to carry outside of wireless-2.6
then they should get personal git repos to carry those.
So for this patch, the following file hunks should not be sent upstream:
drivers/net/wireless/libertas/README
drivers/net/wireless/libertas/ioctl.c
drivers/net/wireless/libertas/wext.c
drivers/net/wireless/libertas/wext.h
The rest look like great candidates for linux-wireless@ and
wireless-2.6. For about 3 weeks or so we've been pushing all libertas
patches to linux-wireless, and I'll send a mail to libertas-dev about
it.
Comments below...
> Signed-off-by: Ashish Shukla <[EMAIL PROTECTED]>
> Signed-off-by: Javier Cardona <[EMAIL PROTECTED]>
> ---
> drivers/net/wireless/libertas/README| 20 +++
> drivers/net/wireless/libertas/cmd.c | 25 ++
> drivers/net/wireless/libertas/cmdresp.c | 22
> drivers/net/wireless/libertas/dev.h |2 +
> drivers/net/wireless/libertas/host.h|2 +
> drivers/net/wireless/libertas/hostcmd.h |7
> drivers/net/wireless/libertas/ioctl.c | 54
> +++
> drivers/net/wireless/libertas/join.c|4 ++-
> drivers/net/wireless/libertas/wext.c|1 +
> drivers/net/wireless/libertas/wext.h|1 +
> 10 files changed, 137 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/README
> b/drivers/net/wireless/libertas/README
> index 34fc1ff..73f1893 100644
> --- a/drivers/net/wireless/libertas/README
> +++ b/drivers/net/wireless/libertas/README
> @@ -143,6 +143,26 @@ ledgpio
> Note: LED0 is invalid
> Note: Maximum Number of LEDs are 16.
>
> +bcn_control
> + This command is used to enable disable beacons. This can also be used
> + to set beacon interval.
> +
> + Usage:
> + iwpriv ethX bcn_control [enable] [beacon_interval]
> +
> + enable: 0 to disable beacon. 1 to enable beacon.
> + beacon_interval: 20 - 1000ms.
> +
> + Examples:
> + 1. iwpriv ethX bcn_control
> +Returns (x, y), where x if 1, indicates beacon is enabled, y
> +beacon period.
> + 2. iwpriv ethX bcn_control 0
> +Turns off beacon transmission.
> + 3. iwpriv ethX bcn_control 1 500
> +Enable beacon with beacon interval 500ms.
> +
> +
> fwt_add
> This command is used to insert an entry into the FWT table. The list of
> parameters must follow the following structure:
> diff --git a/drivers/net/wireless/libertas/cmd.c
> b/drivers/net/wireless/libertas/cmd.c
> index 98295e1..a2dcb74 100644
> --- a/drivers/net/wireless/libertas/cmd.c
> +++ b/drivers/net/wireless/libertas/cmd.c
> @@ -901,6 +901,28 @@ static int wlan_cmd_mesh_access(wlan_private * priv,
> return 0;
> }
>
> +static int wlan_cmd_bcn_ctrl(wlan_private * priv,
> + struct cmd_ds_command *cmd,
> + u16 cmd_action)
> +{
> + struct cmd_ds_802_11_beacon_control
> + *bcn_ctrl = &cmd->params.bcn_ctrl;
> + wlan_adapter *adapter = priv->adapter;
> +
> + lbs_deb_enter(LBS_DEB_CMD);
> + cmd->size =
> + cpu_to_le16(sizeof(struct cmd_ds_802_11_beacon_control)
> + + S_DS_GEN);
> + cmd->command = cpu_to_le16(CMD_802_11_BEACON_CTRL);
> +
> + bcn_ctrl->action = cpu_to_le16(cmd_action);
> + bcn_ctrl->beacon_enable = cpu_to_le16(adapter->beacon_enable);
> + bcn_ctrl->beacon_period = cpu_to_le16(adapter->beacon_period);
> +
> + lbs_deb_leave(LBS_DEB_CMD);
> + return 0;
> +}
> +
> void libertas_queue_cmd(wlan_adapter * adapter, struct cmd_ctrl_node
> *cmdnode, u8 addtail)
> {
> unsigned long flags;
> @@ -1395,6 +1417,9 @@ int libertas_prepare_and_send_command(wlan_private *
> priv,
> S_DS_GEN);
> ret = 0;
> break;
> + case CMD_802_11_BEACON_CTRL:
> + ret = wlan_cmd_bcn_ctrl(priv, cmdptr, cmd_action);
> + break;
> default:
> lbs_deb_host("PREP_CMD: unknown command 0x%04x\n", cmd_no);
> ret = -1;
> diff --git a/drivers/net/wireless/libertas/cmdresp.c
> b/drivers/net/wireless/libertas/cmdresp.c
> index da72dfc..6f4039b 1006
Re: [PATCH] Configurable beacon interval
On Thu, 2007-10-25 at 13:38 -0400, Andres Salomon wrote: > On Thu, 25 Oct 2007 13:29:50 -0400 > Dan Williams <[EMAIL PROTECTED]> wrote: > > > On Wed, 2007-10-24 at 15:42 -0700, Javier Cardona wrote: > > > From: Brajesh Dave <[EMAIL PROTECTED]> > > > > > > See https://dev.laptop.org/ticket/2750#comment:12 > > > > > > Requires firmware version 5.110.19.p0 or newer, available here: > > > http://dev.laptop.org/pub/firmware/libertas/ > > > > What I'd like to do with patches from now on (now that Libertas is > > fully merged upstream) is to split out the OLPC specific parts (like > > the ioctls) and channel those directly into olpc-2.6 through Andres, > > but push the generic bits straight to linux-wireless and John > > Linville. I'd like to get rid of libertas-2.6 alltogether, and if > > people have individual enhancements that they want to carry outside > > of wireless-2.6 then they should get personal git repos to carry > > those. > > > > Note that we (OLPC) are shipping with 2.6.22. Please let me know > of any important fixes/enhancements that are already upstream (or in > linville's tree), and I will cherry-pick them. > > I will commit the 3 patches that Javier sent. Sure; I'm still pretty sure there aren't any that OLPC cares about. I'll go back through them and check. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Retry frame transmission when libertas driver is busy.
On Fri, 2007-11-02 at 16:17 -0700, Javier Cardona wrote: > Andres, > > On 11/2/07, Andres Salomon <[EMAIL PROTECTED]> wrote: > > On Fri, 02 Nov 2007 12:54:35 -0700 (PDT) > > Ashish Shukla <[EMAIL PROTECTED]> wrote: > > > > So, uh.. This patch is from Javier, but was originally written by > > Ashish? Did I get the attribution right? :) > > It's from Ashish. I just verified it and forwarded it on his behalf. > > > Is this simply a workaround to make the driver more reliable with the > > (broken) p0 firmware, or is it an actual fix (ie, is the proper > > behavior to be returning NETDEV_TX_BUSY rather than dropping packets)? > > It's an actual fix: the driver should not drop frames in that > situation. There is also a firmware fix that the QA team has tested > together with this patch. Can we please post these patches to linux-wireless if they don't contain any OLPC-specific ioctls and such? Even if they do, the generic parts that don't touch ioctl.c can get posted on linux-wireless too. Otherwise Andres is going to have a _really_ nasty time merging with new kernel releases. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Unicode in filenames
On Thu, 2007-11-15 at 09:54 -0500, C. Scott Ananian wrote: > Joyride-277 doesn't validate, because it contains a file from the > library with a filename in non-normalized unicode. The file is named > 'Annobo?n_Bioko-thumb.jpg', where the ? should be a separated accent > on the o, but it is actually stored on the filename with a combined > 'o+accent' glyph. > > Now, at first blush this is a bug in the (fast) contents verifier, > which I will fix: all strings should be unicode-normalized before they > are compared. But it seems like this raises issues with (for example) > URLs to library content. Should we enforce the constraint that all > filenames are unicode-normalized on disk, so that we can guarantee > that a (unicode-normalized) URL will always resolve correctly? Everything on disk should be UTF-8. Anything that's not UTF-8 will not be guaranteed to work. Filenames need to be converted to UTF-8 before the file is opened/created/renamed/etc. Dan > Otherwise we run the risk of someone editing a file and resaving it > with a name which *appears* identical, but is actually encoded > differently on disk, and having URLs to the file mysteriously break. > > For the technically-minded, we're talking about using the UTF-8 > encoding of Unicode Normalization Form D, as discussed (briefly) at > http://wiki.laptop.org/go/Canonical_JSON. The problem has arisen > because the old libraries used normalized filenames, but we've > switched to installing the libraries from RPMs, and apparently > non-normalized filenames have snuck in. If I were to hazard a guess, > I'd say that the tar command normalizes filenames as they are > archived, while RPM does not. > > My proposal is to ensure that all filenames in the base system (at > least) are in normalization form D. I will write a checker in the > build process to ensure this, and we should probably eventually write > checkers for the activity/library bundle tools that will do the same. > --scott > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[RFC PATCH] libertas: turn radio off when down
Backport of a patch to olpc-2.6 I'm going to post to linux-wireless.
When both interfaces are down (~IFF_UP), turn off the radio to save
power. When either interface is opened (via iwconfig up or otherwise)
turn the radio back on unless the radio was explicitly disabled by the
user via 'iwconfig txpower off' which also is the previous behavior
without this patch.
This should allow NetworkManager to be told to go to sleep, at which
point it will mark all devices down, and with this patch should turn off
the radio and save power.
It also cleans up some of the mess that was *_open, the intent for which
(unless I'm reading that code wrong) was just to check whether the
interface was up or not, since that's what open/close do.
Comments?
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
diff --git a/drivers/net/wireless/libertas/cmd.c
b/drivers/net/wireless/libertas/cmd.c
index caf0b1c..5a15b56 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -479,6 +479,8 @@ static int wlan_cmd_802_11_snmp_mib(wlan_private * priv,
return 0;
}
+#define TURN_ON_RF 0x01
+
static int wlan_cmd_802_11_radio_control(wlan_private * priv,
struct cmd_ds_command *cmd,
int cmd_action)
@@ -510,7 +512,7 @@ static int wlan_cmd_802_11_radio_control(wlan_private *
priv,
break;
}
- if (adapter->radioon)
+ if (adapter->radio_on)
pradiocontrol->control |= cpu_to_le16(TURN_ON_RF);
else
pradiocontrol->control &= cpu_to_le16(~TURN_ON_RF);
@@ -1112,7 +1114,7 @@ int libertas_set_radio_control(wlan_private * priv)
CMD_OPTION_WAITFORRSP, 0, NULL);
lbs_deb_cmd("RADIO_SET: radio %d, preamble %d\n",
- priv->adapter->radioon, priv->adapter->preamble);
+ priv->adapter->radio_on, priv->adapter->preamble);
lbs_deb_leave_args(LBS_DEB_CMD, "ret %d", ret);
return ret;
diff --git a/drivers/net/wireless/libertas/cmdresp.c
b/drivers/net/wireless/libertas/cmdresp.c
index d391391..433d481 100644
--- a/drivers/net/wireless/libertas/cmdresp.c
+++ b/drivers/net/wireless/libertas/cmdresp.c
@@ -991,7 +991,7 @@ int libertas_process_event(wlan_private * priv)
}
lbs_pr_info("EVENT: MESH_AUTO_STARTED\n");
adapter->mesh_connect_status = LIBERTAS_CONNECTED;
- if (priv->mesh_open == 1) {
+ if (priv->mesh_dev->flags & IFF_UP) {
netif_wake_queue(priv->mesh_dev);
netif_carrier_on(priv->mesh_dev);
}
diff --git a/drivers/net/wireless/libertas/dev.h
b/drivers/net/wireless/libertas/dev.h
index 404ca50..62c3e75 100644
--- a/drivers/net/wireless/libertas/dev.h
+++ b/drivers/net/wireless/libertas/dev.h
@@ -100,9 +100,6 @@ struct wlan_mesh_stats {
/** Private structure for the MV device */
struct _wlan_private {
- int open;
- int mesh_open;
- int infra_open;
int mesh_autostart_enabled;
__le16 boot2_version;
@@ -339,7 +336,8 @@ struct _wlan_adapter {
u16 nextSNRNF;
u16 numSNRNF;
- u8 radioon;
+ u8 user_radio_on;
+ u8 radio_on;
u32 preamble;
/** data rate stuff */
diff --git a/drivers/net/wireless/libertas/host.h
b/drivers/net/wireless/libertas/host.h
index 00d5675..eb516be 100644
--- a/drivers/net/wireless/libertas/host.h
+++ b/drivers/net/wireless/libertas/host.h
@@ -183,10 +183,6 @@
#define CMD_TYPE_SHORT_PREAMBLE 0x0002
#define CMD_TYPE_LONG_PREAMBLE 0x0003
-#define TURN_ON_RF 0x01
-#define RADIO_ON0x01
-#define RADIO_OFF 0x00
-
#define SET_AUTO_PREAMBLE 0x05
#define SET_SHORT_PREAMBLE 0x03
#define SET_LONG_PREAMBLE 0x01
diff --git a/drivers/net/wireless/libertas/main.c
b/drivers/net/wireless/libertas/main.c
index 2b104d2..f07d5b4 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -11,7 +11,9 @@
#include
#include
#include
+#if CONFIG_OLPC
#include
+#endif
#include
#include
@@ -406,8 +408,6 @@ static int libertas_dev_open(struct net_device *dev)
lbs_deb_enter(LBS_DEB_NET);
- priv->open = 1;
-
if (adapter->connect_status == LIBERTAS_CONNECTED) {
netif_carrier_on(priv->dev);
}
@@ -433,20 +433,33 @@ static int libertas_dev_open(struct net_device *dev)
*/
static int libertas_mesh_open(struct net_device *dev)
{
- wlan_private *priv = (wlan_private *) dev->priv ;
+ wlan_private *priv = (wlan_private *) de
Re: [RFC PATCH] libertas: turn radio off when down
On Tue, 2007-11-20 at 23:38 -0600, [EMAIL PROTECTED] wrote: > > Question. > > How is this intended to interact with the mesh connectivity intended for > the laptops? I'm of the understanding that the mesh being powered and on > is more or less a baseline design feature of the XO-as-platform. Yes, though for the first gen machines it's likely that more aggressive power management will be required than was originally thought. However, see my mail to Ashish for more detail. > Or is this an "airplane mode" feature that's going to get a button-push or > other widget activation to activate? Mostly for airplane mode, and to turn off the power when the device isn't being used at all. When both interfaces are marked down, you can't pass any traffic through the device anyway. There are cases where mesh forwarding is desirable but the machine is asleep for longer periods of time, in these cases there is no real reason to close the device anyway. Dan > I fully support the notion of making it possible to quickly and easily > disable the radio, as well as mesh-y bits, saving power and reducing RF in > situations where one is either clearly out-of-contact or prohibited from > emitting excess RF energy, but I would want it to be: > > 1) very difficult to do by accident > > 2) give some indication that the radio is currently off, making it easy to > quickly re-enable the radio. > > What's the plan for UI for this? > > --elijah > > > On Wed, 21 Nov 2007, James Cameron wrote: > > > Date: Wed, 21 Nov 2007 16:26:57 +1100 > > From: James Cameron <[EMAIL PROTECTED]> > > To: Dan Williams <[EMAIL PROTECTED]> > > Cc: Andres Salomon <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > > Brajesh Dave <[EMAIL PROTECTED]> > > Subject: Re: [RFC PATCH] libertas: turn radio off when down > > > > On Tue, Nov 20, 2007 at 11:18:07PM -0500, Dan Williams wrote: > >> This should allow NetworkManager to be told to go to sleep, at which > >> point it will mark all devices down, and with this patch should turn off > >> the radio and save power. > > > > Good. > > > >> Comments? > > > > Very slight possibility of further factorisation seen, but probably not > > worth it. Otherwise it seemed to make sense. Is it in a build yet? > > > > Acked-by: James Cameron <[EMAIL PROTECTED]> > > > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: [RFC PATCH] libertas: turn radio off when down
On Tue, 2007-11-20 at 21:45 -0800, Ashish Shukla wrote:
> Mesh forwarding is always on. Therefore, disabling radio when interface
> in not up will disable mesh forwarding as well. Have you thought of
> this?
Yes, though interactions with suspend/resume need to be investigated
here.
First, if NM is told to sleep and marks the device down (ohm would be
doing this normally via a lid button event or such), that means that
either somebody is on an airplane, or the laptop really, really should
get turned _all_ the way off without mesh forwarding.
If you would like to keep mesh forwarding on, the mesh device shouldn't
be brought down [1]. This leads into suspend/resume land. Basically,
when the machine suspends, the mesh device should be kept IFF_UP and NM
shouldn't be told to sleep, since this will be happening very often on
OLPC. I'm not sure if the networking core closes the device on suspend,
hopefully not; if it doesn't close the device, then nothing else should
be touching it and things will work correctly.
Last I knew there were cases where mesh forwarding was _not_ supposed to
be on due to the high power drain of the 8388 when the radio was
enabled, plus the airplane case. As long as the networking core doesn't
close the devices on suspend, this patch shouldn't have side-effects on
mesh forwarding.
Dan
[1] when doing long suspends, when the resume occurs userspace will need
to redo the networking setup anyway, scanning and searching for the
school server or default mesh channel, because a long suspend most
likely means you changed location and increases the likelihood that the
networking situation around you changed as well.
> Thanks
> -Ashish
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dan
> > Williams
> > Sent: Wednesday, November 21, 2007 9:48 AM
> > To: [EMAIL PROTECTED]
> > Cc: Brajesh Dave; Andres Salomon
> > Subject: [RFC PATCH] libertas: turn radio off when down
> >
> > Backport of a patch to olpc-2.6 I'm going to post to linux-wireless.
> > When both interfaces are down (~IFF_UP), turn off the radio to save
> > power. When either interface is opened (via iwconfig up or otherwise)
> > turn the radio back on unless the radio was explicitly disabled by the
> > user via 'iwconfig txpower off' which also is the previous behavior
> > without this patch.
> >
> > This should allow NetworkManager to be told to go to sleep, at which
> > point it will mark all devices down, and with this patch should turn
> off
> > the radio and save power.
> >
> > It also cleans up some of the mess that was *_open, the intent for
> which
> > (unless I'm reading that code wrong) was just to check whether the
> > interface was up or not, since that's what open/close do.
> >
> > Comments?
> >
> > Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
> >
> > diff --git a/drivers/net/wireless/libertas/cmd.c
> b/drivers/net/wireless/libertas/cmd.c
> > index caf0b1c..5a15b56 100644
> > --- a/drivers/net/wireless/libertas/cmd.c
> > +++ b/drivers/net/wireless/libertas/cmd.c
> > @@ -479,6 +479,8 @@ static int wlan_cmd_802_11_snmp_mib(wlan_private *
> priv,
> > return 0;
> > }
> >
> > +#define TURN_ON_RF 0x01
> > +
> > static int wlan_cmd_802_11_radio_control(wlan_private * priv,
> > struct cmd_ds_command *cmd,
> > int cmd_action)
> > @@ -510,7 +512,7 @@ static int
> wlan_cmd_802_11_radio_control(wlan_private * priv,
> > break;
> > }
> >
> > - if (adapter->radioon)
> > + if (adapter->radio_on)
> > pradiocontrol->control |= cpu_to_le16(TURN_ON_RF);
> > else
> > pradiocontrol->control &= cpu_to_le16(~TURN_ON_RF);
> > @@ -1112,7 +1114,7 @@ int libertas_set_radio_control(wlan_private *
> priv)
> > CMD_OPTION_WAITFORRSP, 0, NULL);
> >
> > lbs_deb_cmd("RADIO_SET: radio %d, preamble %d\n",
> > - priv->adapter->radioon, priv->adapter->preamble);
> > + priv->adapter->radio_on, priv->adapter->preamble);
> >
> > lbs_deb_leave_args(LBS_DEB_CMD, "ret %d", ret);
> > return ret;
> > diff --git a/drivers/net/wireless/libertas/cmdresp.c
> b/drivers/net/wireless/libertas/cmdresp.c
> > index d391391..433d481 100644
> > --- a/drivers/net/wireless/libertas/cmdresp.c
> > +++ b/drivers/net/wireless/libertas/cmdresp.c
> > @@ -991,7 +991,7 @@ int libertas_proces
Re: [RFC PATCH] libertas: turn radio off when down
On Wed, 2007-11-21 at 02:06 -0500, Chris Ball wrote: > Hi Dan, > >> Last I knew there were cases where mesh forwarding was _not_ >> supposed to be on due to the high power drain of the 8388 when the >> radio was enabled, plus the airplane case. As long as the >> networking core doesn't close the devices on suspend, this patch >> shouldn't have side-effects on mesh forwarding. > > The current setup is: > > suspend: caused by idleness, radio stays on, unicast wakeups stay on This implies that the device is not downed, since unicast wakeups would be useless if the device wasn't receiving. > sleep: caused by lid close or power button, radio stays on, wakeups off This case could be the one that kills the patch if it's anticipated this state would last more than some number of minutes (10 or 20 maybe?). > I think it's still undecided whether sleep should leave the radio on or > not -- we need to take power measurements now that mesh beacons can be > disabled and see whether the power consumption is significantly reduced. That would be quite interesting to see, yes. >> [1] when doing long suspends, when the resume occurs userspace will >> need to redo the networking setup anyway, scanning and searching >> for the school server or default mesh channel, because a long >> suspend most likely means you changed location and increases the >> likelihood that the networking situation around you changed as >> well. > > Is there a dbus message OHM can pass to NM for this? (If not, maybe > you could mention which NM functions perform the full scan/search so > that we can wrap them?) Well, basically sleep & wake will be what you want here. That's the normal path on regular laptops when suspend/hibernate is used, and will cause NM to down all devices. If ohm is doing the intelligent power control stuff here, then it could certainly be the thing that tells NM to go to sleep and turn off the radios. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Upgrading to Fedora 8
On Mon, 2007-12-10 at 19:05 -0500, Bernardo Innocenti wrote: > Yesterday I tried upgrading yoyride to Fedora 8, to see > how much pain it would be. > > After enabling the fedora repo in /etc/yum.repos.d/fedora.repo and > tweaking it to make it fetch from version 8, I just did: > > init 3 > yum -y dist-upgrade --exclude poppler > init 5 > > Going to init 3 is necessary to conserve memory, otherwise > yum fights with sugar and cranks the system to death. > > Excluding poppler precents a dependency problem in our > custom package. > > Surprisingly, everything worked perfectly after the update, > until I rebotted. > > Then I got into a minor glitch that prevents input hotplug from > working when the X server is run by the unprivileged user olpc > (X is a suid binary). If I run X manually from the console, > everything works fine. There's probably a stricter check on > the EUID somewhere in dbus or in hal. NetworkManager will lose the mesh interface if you update to 0.7, FYI. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Voice IM project proposal
On Wed, 2007-12-12 at 10:39 -0500, Chris Ball wrote: > Hi, > >> We do already have a video-chat activity under development - due to >> priorities it hasn't been updated in a while but collaboration on >> that would be welcome. > > In particular I think the problems with video-chat were: > >* There's no stream/VOIP support in Gabble (or was it Salut?) Well, you really, really want to do the video/voip stuff out-of-band WRT the jabber-based communication protocols that salut & gabbled do. So you use the presence system to _find_ the other person you want to talk to (or use SIP or whatever), but you have to use some other mechanism than jabber to actually talk to that person. So neither Gabble nor Salut are actually involved in any of this. >* We don't have a video codec to use! We don't think we can handle > the CPU load of encoding and decoding Theora in real time. The > previous videoconferencing demo used h.263, but we're guessing we > can't ship that for patent reasons (although I don't think anyone's > done the research?). There are three versions of H.263: H.263, H.263+ and H.263/2000 (or H.263++). The first one and second might be usable, but H.263/2000 is totally unusable for legal/patent reasons. And, of course, it would be best to work on getting the Theora encoder/decoder working faster for the XO hardware to ensure that there's a completely free, open, and unencumbered solution available. Dan > If anyone's willing to hack on this, I think it'd be a really useful > project. Video conferencing was a killer demo when we hooked it up > a year ago, it'd be a shame not to be able to offer it. > > The GIT source for the Video Chat activity is: > >http://dev.laptop.org/git?p=projects/video-chat-activity;a=summary > > - Chris. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Unable to initialize camera (via mmap interface)
On Wed, 2007-12-12 at 16:03 -0800, Peter Krenesky wrote:
> Hi all,
>
> I'm trying to initialize the camera device and running into some
> errors. I'm attempting to use the mmap interface initialized by
> VIDIOCGMBUF ioctl. the ioctl is returning -1 and errno is 22.
>
> Is VIDIOCGMBUF/mmap even supported by the driver/device? If so, any
> ideas on what can be going wrong?
What's normally used right now to get video out of the device is
GStreamer. You can see what GStreamer is doing from the stuff in
v4l2src_calls.c. Specifically, look at gst_v4l2src_capture_init(). You
probably want to use the QBUF/DQBUF functionality.
Dan
>
> Here is the c++ code that is causing the problem:
>
> video_mbuf mmap_buf_info;
> if (-1 == ioctl(vidfd, VIDIOCGMBUF, &mmap_buf_info))
> {
> printf ("ERROR: %i \n", errno);
> close();
> return(HXR_ENC_NO_VIDEO_CAPTURE);
> }
>
>
>
> thanks,
>
> -peter
>
>
>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: WPA - testing
On Thu, 2007-12-13 at 11:10 +0100, Pascal Scheffers wrote: > Works for me on a Sitecom WL-174 WPA-PSK network. One of yesterdays > joyrides. Works for me with 650 against a Linksys WRT54GC after disabling the SIGCHLD handler in /usr/bin/sugar-shell. I actually can't get it to fail, though I'm in a less-RF-heavy environment than 1CC is, and I'm pretty near to the AP itself. However, Marco has seen problems with using the -ddd switch to wpa_supplicant, mainly because output to the console is so slow. What might be happening here is that the driver batches together configuration commands, backing off the timeout for ending the batch by 500ms every time a command comes in. But if wpa_supplicant is logging to the console with debug output, those commands might not come in fast enough, leading to half-complete configuration batches being sent to the driver. This is a limitation of the Wireless Extensions kernel API. Unfortunately, -ddd is pretty much required to get usable debug output from wpa_supplicant, though logging to a file on flash using the '-f' switch (or touching /etc/NetworkManager/log-supplicant when using NM) will do the trick. The other problem is that since wpa_supplicant isn't running all the time and gathering scan results (this is fixed with NM 0.7 SVN) there's a startup hit while wpa_supplicant launches, gets scan results (which, due to driver deficiencies that have recently been fixed, might take a while), and finds the AP to associate with. NetworkManager may have assumed that the association has timed out by this point, since it times the association out after 20 seconds or so. In normal machines, if you haven't associated within ~30 seconds, something is awfully wrong. But on OLPC, that timeout might need to be larger due to memory pressure and processor speed. Dan > - Pascal. > > >It's fixed yeah, that's why I'm asking to test it with a recent build. > >Ticket #5044. It went in joyride two weeks ago. It's reported working > >in both joyride and 657. > > > >Marco > >___ > >Devel mailing list > >Devel@lists.laptop.org > >http://lists.laptop.org/listinfo/devel > > > > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WPA - testing
On Thu, 2007-12-13 at 15:14 -0500, Michail Bletsas wrote: > > > "Ricardo Carrano" <[EMAIL PROTECTED]> wrote on 12/13/2007 > 02:54:11 PM: > > > > > > - Whatever changed between 1407 and 1416 seem to have really crashed > > WPA support, I > > mean, now we cannot set it to work via wpa_supplicant anymore. > > > Maybe something as simple as actually rebuilding wpa_supplicant? I'd look first at what changed between builds... If the supplicant hasn't been updated for quite a while (it shouldn't have been) then it's much less likely to be a problem. I'm not sure what a rebuild would solve here... Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WPA anomalies in recent Joyride builds
On Tue, 2007-12-18 at 11:14 -0500, Marcus Leech wrote: > I use WPA-PSK (WPA personal) at home, and I've noticed anomalies. > > One of the big ones is that it keeps re-prompting for the passphrase > (this is with Joyride 1438), and tearing-down the > association. I looked at /var/log/messages while this was going on, > and it seems like it starts the association logic, > puts up the password prompt, and then times out the association > attempt after 8 seconds--which typically isn't enough > time to type in the passphrase! It turns out that NetworkManager has > a wired-in 8 second timer for > re-association attempts, and 20 seconds for initial association attempts. This only comes into play when there's an ongoing _connection_, it doesn't come into play when you're typing in the password. When NM needs a password from you, it pauses the connection process until you enter the password or cancel. When it has the secrets it needs to connect, it _then_ will start timers during the association. There's an 8-second link timer, and an overall 20 second association timer. The 8-second link timer only gets triggered if the driver sends a disconnection event after association has started, or when a successful association is established. If the link isn't re-established after 8 seconds, NM will terminate the connection because the driver hasn't reassociated with the AP. That time might be a little bit low, but it's pretty reasonable. The 4-Way WPA handshake doesn't take that long, and if it does, you're most definitely so far near the margins of your network that you won't be able to pass frames anyway. The 20 second overall association timer should probably get bumped up, and I've got a NetworkManager in the OLPC-2 collection queued up to build if required. The problem here is that, due to driver issues, the spawned wpa_supplicant may not have had enough time to scan and find the AP you're looking for. This is due mainly to driver issues, but is exacerbated by the fact that a new wpa_supplicant is spawned for each connection. Later versions of NetworkManager use a long-running wpa_supplicant process so this isn't as much of a problem. > I'm not sure how this seems to work OK on a regular Fedora system--which > is using almost the same version of Because you're not using the libertas driver on the regular Fedora system, and because a regular system doesn't have the memory and speed constraints of the OLPC WRT to spawn time and memory pressure. Things just run slower on the OLPC so timeouts like this must be adjusted upwards. > NetworkManager. It's possible that the password-prompting happens > before we go into the timer-controlled > region of the state machine--have we mucked with this at all? Is the Yes, the password prompting happens before either of the mentioned timeouts is started. > password dialog one of our own, or > just a standard one with Sugar decorations? It's provided by Sugar, from sugar/hardware/* Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
