Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, Jun 3, 2008 at 12:08 PM, David Woodhouse [EMAIL PROTECTED] 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? 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. Oh! I refuse to start playing these childish games with you. Please try to be professional. All I said is based on what was reported in the wiki. If there is more detail to it, great! Thanks. Wad! -- dwmw2 ___ 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 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. wad ___ 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
[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. 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 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 boot2_image_name /sys/class/net/eth2/lbs_boot2 echo firmware_image_name /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 boot2_image_name /sys/class/net/eth2/lbs_boot2
echo firmware_image_name /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 10:37 -0400, Michail Bletsas wrote: The userspace tool is extremely awkward to use (since it requires the driver modules to be unloaded which in turn makes the identification of devices on the XO even more difficult) I believe there's a way for libusb to unbind the existing driver and steal the device for itself. We just never bothered to _do_ it because it was never really an issue. Dan? -- dwmw2 ___ 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:12 -0400, Dan Williams wrote: 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? And if we _are_ going to do it in the driver, which is far from clear, then look at the way the dell_rbu driver gets firmware from userspace with an asynchronous request_firmware() call. That's probably the way we'd want to do it. -- dwmw2 ___ 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 boot2_image_name /sys/class/net/eth2/lbs_boot2 echo firmware_image_name /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:34 -0300, Ricardo Carrano wrote: 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. Bug number(s), please. -- dwmw2 ___ 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, 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 boot2_image_name /sys/class/net/eth2/lbs_boot2
echo firmware_image_name /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.
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
___
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:44 -0300, Ricardo Carrano wrote: Please check comment on: http://wiki.laptop.org/go/Active_Antenna_Reprogramming#User_Space_Method Where am I looking? The 'has failed twice' claim? That's hardly a decent bug report. Put a coherent report in trac, and we'll look at it. Let's see a dump of the contents of the flash on the offending units. The userspace tool does exactly the same as the kernel was doing to program the firmware -- there's absolutely no reason why it should be any different. -- dwmw2 ___ 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, Jun 3, 2008 at 11:49 AM, David Woodhouse [EMAIL PROTECTED] wrote: On Tue, 2008-06-03 at 11:44 -0300, Ricardo Carrano wrote: Please check comment on: http://wiki.laptop.org/go/Active_Antenna_Reprogramming#User_Space_Method Where am I looking? The 'has failed twice' claim? That's hardly a decent bug report. Put a coherent report in trac, and we'll look at it. Let's see a dump of the contents of the flash on the offending units. I'll have to go with what's reported there (which I didn't write, true). I can't afford to brick my only active antenna. Moreover, I still do not get what's the problem of doing this in the kernel. The userspace tool does exactly the same as the kernel was doing to program the firmware -- there's absolutely no reason why it should be any different. -- dwmw2 ___ 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, Jun 3, 2008 at 11:35 AM, David Woodhouse [EMAIL PROTECTED] wrote: On Tue, 2008-06-03 at 11:34 -0300, Ricardo Carrano wrote: 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. Bug number(s), please. Please check comments on: http://wiki.laptop.org/go/Active_Antenna_Reprogramming#User_Space_Method -- dwmw2 ___ 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
[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 boot2_image_name /sys/class/net/eth2/lbs_boot2 echo firmware_image_name /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 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. 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. 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, Jun 3, 2008 at 11:35 AM, David Woodhouse [EMAIL PROTECTED] wrote: On Tue, 2008-06-03 at 11:34 -0300, Ricardo Carrano wrote: 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. Bug number(s), please. Please check comment on: http://wiki.laptop.org/go/Active_Antenna_Reprogramming#User_Space_Method -- dwmw2 ___ 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
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. wad On Jun 3, 2008, at 10:49 AM, David Woodhouse wrote: On Tue, 2008-06-03 at 11:44 -0300, Ricardo Carrano wrote: Please check comment on: http://wiki.laptop.org/go/ Active_Antenna_Reprogramming#User_Space_Method Where am I looking? The 'has failed twice' claim? That's hardly a decent bug report. Put a coherent report in trac, and we'll look at it. Let's see a dump of the contents of the flash on the offending units. The userspace tool does exactly the same as the kernel was doing to program the firmware -- there's absolutely no reason why it should be any different. -- dwmw2 ___ 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] libertas: add sysfs hooks to update boot2 and persistent firmware
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? 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. -- dwmw2 ___ 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 boot2_image_name /sys/class/net/eth2/lbs_boot2 echo firmware_image_name /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
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. 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
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. 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? 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 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
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. 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 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 boot2_image_name /sys/class/net/eth2/lbs_boot2
echo firmware_image_name /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;
+
+ return ret;
+}
+
+/**
+ *
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 mfg image runtime firmware 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
Dan Williams [EMAIL PROTECTED] wrote on 06/03/2008 01:50:59 PM: 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. In general, you don't have to touch boot2 (and with the newer chips you won't be able, even if you wanted ;-) The discussion here is mainly on how to burn new firmware into stand-alone active antenna modules which are going to be used around XOs. Thus, it is very important to make sure that we can program those using XOs. 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
Dan Williams wrote: 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 If you have a unit that you brick we can program a new chip and swap it at 1cc. Assuming that we have a copy of the boot2 code somewhere. -- Richard Smith [EMAIL PROTECTED] One Laptop Per Child ___ 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: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_. -- dwmw2 ___ 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: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
Hello, On Tue, Jun 3, 2008 at 11:38 AM, Dan Williams [EMAIL PROTECTED] wrote: 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? The latter is true. The runtime firmware only supports the UPDATE_FW and UPDATE_BOOT2. Supporting FW_BY_USB in firmware would be pretty tricky :) 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. There should be no side effects. However, the 5.110.X firmware (and the 5.126.X on non-active antennas) freezes the USB stack if we send the UPDATE_FW or UPDATE_BOOT2 commands. We believe this is a firmware bug and will bring it up with Marvell. But ultimately there should be no side affects regardless of the hardware. 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. This is a valid concern that is not addressed in my patch. I don't think grabbing driver_lock is a good solution, though, because the fw prog is likely to take a while and we sleep all over the place. I think it might be better to manipulate priv-cur_cmd and priv-dnld_sent in a suitable fashion in the sysfs functions. I'll investigate and resubmit the patches. Any input would be appreciated. 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 firmware images that get flashed are stand-alone images for the active antennas released at [1], not regular USB firmware images. The image that gets flashed will only run when the active antenna is powered up without a host. If you inadvertently flash an active antenna with the wrong firmware image, you can recover it by simply reflashing. In contrast, the boot2 that gets flashed is the only boot2. [1] http://www.laptop.org/teamwiki/index.php/Image:Standalone-firmware.tgz 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. The risk of corrupting the firmware image is not major. The user can just reflash when power is available. However, if power fails or if the system sleeps during a boot2 update, the device will be bricked. The only defense against this is making the sysfs hook write-only by root. Ciao, Brian 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
[PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
To update boot2, copy the boot2 and firmware images to /lib/firmware and:
echo boot2_image_name /sys/class/net/eth2/lbs_boot2
echo firmware_image_name /sys/class/net/eth2/lbs_fw
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) {
--
1.5.2.5
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
