Re: XO communications interface naming
On Wednesday 04 Jun 2008 1:21:34 am Mikus Grinbergs wrote: > I don't have wireless - am using an USB-ethernet adapter instead. Network adapters are given logical device names using udev rules. See for rules matching "net" SUBSYSTEM in /etc/udev/rules.d (usually *persistent-net-generator.rules). On first boot, the generator creates a rule file (*persistent-net.rules) for all persistent detected devices. Subsequently, any hot plugged network device gets assigned the next available sequence number. Does your adapter have a fixed entry in this file? If not, you can add it manually. The list of active network devices is in /proc/net/dev and under /sys/class/net. HTH, Subbu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Need help creating .xo file
Hi All , I was wondering if you could help me out with this. I got the activity working fine on the OLPC. Now I want to create a .xo file for my activity so that I can install the activity on other XO's. My activity structure is as follows: ->activity -->has the .info file and the icon ->bin --> has a shell script and the exe which i have to run ->lib --> has the libs which my application is dependent on -> MANIFEST file There is a shell script in the bin folder which I have included in the exec tag in activity.info. I created the activity bundle according to the information in the post http://olpcnews.com/forum/index.php?topic=1555.0 . I have named my .xo file name.activity.xo If I unzip the .xo in the Activities folder and then restart the X-server it gets installed and I get the icon in the activity tray. I tried installing it by copying the .xo to a thumb drive and then running sugar-install-bundle on the XO but it gave me a DBUS timeout error. I also tried to install it through the browse activity as given in http://wiki.laptop.org/go/Activities#Manual_installation and through the Journal without success. Can you figure out where I am going wrong?? Thanks Shivaprasad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Cannot see activities in joyride-2005
Hello, Yesterday night I did an olpc-update to joyride-2005. After rebooting the system, I no longer had any activities in the ring view. The list view showed a list of faded out activities from /home/olpc . Thinking that it was caused by some settings in /home/olpc, I tried moving /home/olpc aside and creating an empty /home/olpc. But then X11 wouldn't even start. Does someone have a clue of how to restore the activities? Thanks, Dov ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
Shipping G1G1 machines with NAND reflash locks enabled makes little sense to me. What good is protection against malicious reflash when any attacker who can perform a reflash has physical access to the device and has password-free root access in default configurations? Instead, the justification that I recall most strongly from when I last inquired about the purpose of enabling the NAND reflash lock on G1G1 machines is that it is primarily intended to reduce support costs by making it harder to test non-Released builds via reflash. I countered that the value of the extra testing we might receive would far outweigh the extra support costs that we might incur but, evidently, my argument was not decisive. Scott - were there other justifications given for the NAND reflash lock? I vaguely recall that you argued that, by default, OFW ought to be prohibited from writing unsigned data to the NAND on the grounds that bugs in the prohibited code paths might otherwise violate security goals of clients shipping passive-kill or active-kill technologies. Did I recall your justification correctly? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Project Hosting Application: olpc-netscripts
On Tue, Jun 03, 2008 at 07:54:13PM -0700, Ixo X oxI wrote: > Great idea! > > I have some scripts, thoughts, and code I might be interested with > contributing myself. Then please show off your patches! > Is there a start to a list of tools, what they do, and maybe even a > 'request/want' list ? Nope. Feel free to write one! Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Autoreinstallation image is not signed.
On Jun 4, 2008, at 12:56 AM, Kim Quirk wrote: > thought one of the things Ivan did in Uruguay was to help them reflash > their laptops when they couldn't boot due to journal corruption I gave them a patch that they were able to push out to the machines to restore them to working order _without_ reflashing. Had they had to reflash, they would have lost all the kids' data. -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
I continue to be uncomfortable that we are sending out restricted / locked-down machines without a clear need. The arguments made so far for this are 1. "Getting G1G1 people to test security steps" 2. "Protecting G1G1 donors from installing anything but signed builds" 3. "Showing a pretty boot screen" 3. represents a bug that should be fixed. Tying pretty boot to machine-lockdown is arbitrary. 2. assumes that this is the best result for G1G1 donors, which seems unlikely to me. Discovering how to update to anything but the most aggressively promoted builds is already a sign of tech savvy. This protection would still effectively be in place for the vast majority of users for whom it matters if we aggressively recommended to users (say, after a couple of days of use) that they get a developers key if they want full control of their machines for any reason. 1. is an interesting argument. As with 2, it would still hold if recipients were actively encouraged to get developers keys if they have any interest in having full control of their machines (indeed you could say that they we would have a much better test of the dev-key acquisition process, which currently works more clearly in large batches for countries than for individuals). SJ On Tue, Jun 3, 2008 at 9:46 PM, Kim Quirk <[EMAIL PROTECTED]> wrote: > Developer program laptops are shipped out as US/International > keyboards, English language, AK flag set, which means they do NOT need > activation. They are permanently activated in the manufacturing data. > > The only thing they need to be a developer unit is a developer key. > > One more reason to add to Scott's list of why laptops are sent out to > G1G1 'write protected' is so they are protected from non-signed images > coming from malicious sources. If you don't use a developer's key to > un protect the laptop, then you can only upgrade to OLPC signed > builds. This is an important part of the bitfrost security that is > implemented and working! > > FFM - if you really got two laptops from the developer's program that > weren't activated, then could you put those details into an RT ticket > and we'll debug it there. If there really are laptops going out that > are un-activated that we don't know about, that will be a serious > problem. > > The ONLY un-activated laptops are ones built for Peru, Mexico, and > Uruguay. These are very specific SKUs and that include Spanish > keyboards. Please open a ticket and let's figure that out. > > Thanks, > Kim > > > On Tue, Jun 3, 2008 at 1:07 PM, C. Scott Ananian <[EMAIL PROTECTED]> > wrote: > > On Tue, Jun 3, 2008 at 12:43 PM, Bert Freudenberg <[EMAIL PROTECTED]> > wrote: > >> On 03.06.2008, at 18:33, ffm wrote: > >>> On Tue, Jun 3, 2008 at 12:29 PM, C. Scott Ananian > >>> <[EMAIL PROTECTED]> wrote: > Machines sent out via our developer program are always shipped out > unsecured. > >>> > >>> Yet I've just recived two laptops via said program that had security > >>> enabled. > >> > >> Indeed. The machines distributed at LinuxTag last week also came w/o > >> dev key - I think it is only the activation part that is disabled. > > > > My information may be out of date on the developer's program, since > > Adam has rebooted it recently and I don't think that developer's > > program machines actually come through OLPC any more. I should have > > said, "used to be shipped out unsecured". Adam, are the new > > developer's program machines shipped direct, or do we have an > > opportunity to (at least) include a flyer explaining how to disable > > security on the machine? > > --scott > > > > -- > > ( http://cscott.net/ ) > > ___ > > 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: Project Hosting Application: olpc-netscripts
Great idea! I have some scripts, thoughts, and code I might be interested with contributing myself. Is there a start to a list of tools, what they do, and maybe even a 'request/want' list ? :) -iXo On Tue, Jun 3, 2008 at 3:01 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > 1. Project name : olpc-netutils > 2. Existing website, if any : None > 3. One-line description : OLPC-specific user-land network software. > > 4. Longer description : Yani's collection of network status displays. > > 5. URLs of similar projects : Unknown. > > 6. Committer list > > Please let anyone with a dev account commit. Yani and I will be the > contact > people. > > 7. Preferred development model > > Please set up projects/olpc-netutils > > 8. Set up a project mailing list: > > [X] No > > 9. Commit notifications > > [EMAIL PROTECTED] > > 11. Translation > [X] Set up the laptop.org Pootle server to allow translation commits to > be made > ___ > 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: Autoreinstallation image is not signed.
> >> Specifically, http://dev.laptop.org/ticket/7125. > >> > >> What do people think of the straw man in that ticket? Should we > >> implement it? My comments are in the ticket; let's move the discussion there, where it belongs. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
Developer program laptops are shipped out as US/International keyboards, English language, AK flag set, which means they do NOT need activation. They are permanently activated in the manufacturing data. The only thing they need to be a developer unit is a developer key. One more reason to add to Scott's list of why laptops are sent out to G1G1 'write protected' is so they are protected from non-signed images coming from malicious sources. If you don't use a developer's key to un protect the laptop, then you can only upgrade to OLPC signed builds. This is an important part of the bitfrost security that is implemented and working! FFM - if you really got two laptops from the developer's program that weren't activated, then could you put those details into an RT ticket and we'll debug it there. If there really are laptops going out that are un-activated that we don't know about, that will be a serious problem. The ONLY un-activated laptops are ones built for Peru, Mexico, and Uruguay. These are very specific SKUs and that include Spanish keyboards. Please open a ticket and let's figure that out. Thanks, Kim On Tue, Jun 3, 2008 at 1:07 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote: > On Tue, Jun 3, 2008 at 12:43 PM, Bert Freudenberg <[EMAIL PROTECTED]> wrote: >> On 03.06.2008, at 18:33, ffm wrote: >>> On Tue, Jun 3, 2008 at 12:29 PM, C. Scott Ananian >>> <[EMAIL PROTECTED]> wrote: Machines sent out via our developer program are always shipped out unsecured. >>> >>> Yet I've just recived two laptops via said program that had security >>> enabled. >> >> Indeed. The machines distributed at LinuxTag last week also came w/o >> dev key - I think it is only the activation part that is disabled. > > My information may be out of date on the developer's program, since > Adam has rebooted it recently and I don't think that developer's > program machines actually come through OLPC any more. I should have > said, "used to be shipped out unsecured". Adam, are the new > developer's program machines shipped direct, or do we have an > opportunity to (at least) include a flyer explaining how to disable > security on the machine? > --scott > > -- > ( http://cscott.net/ ) > ___ > 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
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 t
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
Help packaging some OLPC network status scripts?
Friends, Yani Galanis has pieced together a variety of source code and dependencies at http://dev.laptop.org/ticket/7171 http://dev.laptop.org/ticket/7172 http://dev.laptop.org/ticket/7174 archived in http://dev.laptop.org/git/projects/olpc-netutils which I'd really like to be able to include in OLPC's August software release. Could anyone here spare a few hours to make appropriate Fedora packages for this collection of scripts? Thanks very much, Michael Stone P.S. - For people in the OLPC community who are not already familiar with Fedora and the packaging process, please see http://wiki.laptop.org/go/Developer/Fedora for some background. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Autoreinstallation image is not signed.
C. Scott Ananian-3 wrote: > > We should continue to try very hard not to let the OS become > unbootable. If it is unbootable, something Very Wrong should have > occurred and there's no guarantee that "mount the filesystem and copy > off /home" will work either. Using a dev key and a rescue disk is > probably a much better bet than any attempt at automagic. > True, but "mount the filesystem and copy off /home" is better than nothing. We have to accept that there are builds in the field that have _known_ issues, such as 650. When they occur, (and since users don't update/backup until too late...) we _need_ to have a better solution than "you didn't update, you're on your own." -FFM -- View this message in context: http://www.nabble.com/Autoreinstallation-image-is-not-signed.-tp17612809p17636472.html Sent from the OLPC Software development mailing list archive at Nabble.com. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Autoreinstallation image is not signed.
Hi, > Is there anything that can be thrown away before we start scragging > the user's work? Browser caches, or similar things? Sorry, I wasn't clear: the bug I'm envisioning solving is "the XO won't boot because there is too much stuff in the Journal". I'm not actually sure what the method for kids to fill up their NAND without going via the Journal would be; I don't think it's the common case. > Or throw away least recently used non-core activities, which > hopefully could easily be reloaded from the web or a teacher's USB > stick. I agree that we could look for large activities to delete in preference to large user-generated files. I'm trying to keep this somewhat simple because we're doing it before Sugar has even launched. - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Autoreinstallation image is not signed.
On Tue, 3 Jun 2008, Robert Myers wrote: > Chris, > >> > That said, there's a separate bug in trac about X not starting when >> > the NAND flash is full. I'm not sure if that's what you're >> > referring to as "not booting" or not, but we should fix that, too. >> >> Specifically, http://dev.laptop.org/ticket/7125. >> >> What do people think of the straw man in that ticket? Should we >> implement it? >> > > >Straw man from ticket> > > We're probably going to see this a lot in the field. It might be worth > having some recovery logic. Here's a straw-man: if disk is full at boot, > delete the single largest journal entry, iterate until disk is not full > anymore. > > > Is there anything that can be thrown away before we start scragging the > user's work? Browser caches, or similar things? > > How much space is needed for a successful boot anyways? Maybe there > ought to be a dummy file stored just for the purpose of being thrown > away in an emergency. > > Or throw away least recently used non-core activities, which hopefully > could easily be reloaded from the web or a teacher's USB stick. > > I'd think that throwing away the child's work would be one of the last > things we'd want to do. especially the largest piece of work. there are journal entries that don't store any useful info other then 'this app was used'. those should all be thrown away before any user-generated content is trashed. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Autoreinstallation image is not signed.
Chris, >> That said, there's a separate bug in trac about X not starting when >> the NAND flash is full. I'm not sure if that's what you're >> referring to as "not booting" or not, but we should fix that, too. > > Specifically, http://dev.laptop.org/ticket/7125. > > What do people think of the straw man in that ticket? Should we > implement it? > >Straw man from ticket> We're probably going to see this a lot in the field. It might be worth having some recovery logic. Here's a straw-man: if disk is full at boot, delete the single largest journal entry, iterate until disk is not full anymore. http://lists.laptop.org/listinfo/devel
Re: Autoreinstallation image is not signed.
chris wrote: > Hi, > >> That said, there's a separate bug in trac about X not starting when >> the NAND flash is full. I'm not sure if that's what you're >> referring to as "not booting" or not, but we should fix that, too. > > Specifically, http://dev.laptop.org/ticket/7125. > > What do people think of the straw man in that ticket? Should we > implement it? so others don't have to look: "Here's a straw-man: if disk is full at boot, delete the single largest journal entry, iterate until disk is not full anymore." as a user, i might prefer "delete the oldest journal entry, iterate...". but i'm not convinced either way. paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: JFFS2 error messages
On Tue, Jun 03, 2008 at 05:16:17PM +0100, David Woodhouse wrote: > On Tue, 2008-06-03 at 12:13 -0400, C. Scott Ananian wrote: > > 2008/6/3 Bill Mccormick <[EMAIL PROTECTED]>: > > > A couple of my XOs are reporting what look like FS error messages on boot: > > > > > > [91.463670] JFFS2 notice: (664) check_node_data: wrong data CRC in data > > > node at 0x1ec215f0: read 0x3e7c7e03, calculated 0xf7e1d50c > > > > Anyone want to volunteer to turn the above into a FAQ which would be > > discoverable on our wiki, so that future wonderers don't have to pry > > the information from the head of dwmw2? > > I think it's already in trac as an RFE. I couldn't find such a ticket so I created one: http://dev.laptop.org/ticket/7177 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Autoreinstallation image is not signed.
Hi, > That said, there's a separate bug in trac about X not starting when > the NAND flash is full. I'm not sure if that's what you're > referring to as "not booting" or not, but we should fix that, too. Specifically, http://dev.laptop.org/ticket/7125. What do people think of the straw man in that ticket? Should we implement it? - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
On Tue, Jun 3, 2008 at 12:29 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote: > Machines sent out via our developer program are always shipped out > unsecured. Yet I've just recived two laptops via said program that had security enabled. -FFM ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
G1G1: Security, to enable or disable...
Why were G1G1 machines shipped with firmware, kernel, and reflash locks enabled? (see http://wiki.laptop.org/go/Developer_keys ) Theft is not a good reason, as they do not require activation leases. It only seems to be a bother for people who want to help out with the OLPC project. -FFM ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Autoreinstallation image is not signed.
John, We experienced quite a large number of 'software broken' laptops when we first starting shipping both in Uruguay and in the G1G1 program. I thought one of the things Ivan did in Uruguay was to help them reflash their laptops when they couldn't boot due to journal corruption or other software related reasons. Not sure if this is the same problem. How many do you think are recoverable with software reflash? Have they been recovering these, or have these fallen into one of their other piles of 'broken' laptops? Thanks, Kim On Tue, Jun 3, 2008 at 6:47 PM, John Watlington <[EMAIL PROTECTED]> wrote: > > On Jun 3, 2008, at 11:53 AM, C. Scott Ananian wrote: > >> On Tue, Jun 3, 2008 at 11:28 AM, ffm <[EMAIL PROTECTED]> wrote: >>> C. Scott Ananian-3 wrote: http://wiki.laptop.org/go/Olpc-update#USB_upgrade >>> This will not work if the OS is not bootable and no alt-os image >>> is on the >>> disk. >> >> We should continue to try very hard not to let the OS become >> unbootable. If it is unbootable, something Very Wrong should have >> occurred and there's no guarantee that "mount the filesystem and copy >> off /home" will work either. Using a dev key and a rescue disk is >> probably a much better bet than any attempt at automagic. >> >> Please file bugs on ways you've managed to make the OS unbootable, or >> ways the alt-os image breaks (there are a few); these are likely to >> get more attention than trying to resuscitate a deprecated tool I >> wrote for firmware security debugging. > > I agree completely with Scott. > > An interesting data point, however, is that over half of the machines > sent for repair in Uruguay are fixed simply by reflashing the machine. > This may be an artifact of the old build they are using, but it is a > disturbing statistic. > > In recent months, I've only had to reflash to fix problems which > happened right after a previous reflash (#6906). > >> That said, there's a separate bug in trac about X not starting when >> the NAND flash is full. I'm not sure if that's what you're referring >> to as "not booting" or not, but we should fix that, too. >> --scott >> >> -- >> ( http://cscott.net/ ) >> ___ >> 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: Autoreinstallation image is not signed.
On Jun 3, 2008, at 11:53 AM, C. Scott Ananian wrote: > On Tue, Jun 3, 2008 at 11:28 AM, ffm <[EMAIL PROTECTED]> wrote: >> C. Scott Ananian-3 wrote: >>> http://wiki.laptop.org/go/Olpc-update#USB_upgrade >> This will not work if the OS is not bootable and no alt-os image >> is on the >> disk. > > We should continue to try very hard not to let the OS become > unbootable. If it is unbootable, something Very Wrong should have > occurred and there's no guarantee that "mount the filesystem and copy > off /home" will work either. Using a dev key and a rescue disk is > probably a much better bet than any attempt at automagic. > > Please file bugs on ways you've managed to make the OS unbootable, or > ways the alt-os image breaks (there are a few); these are likely to > get more attention than trying to resuscitate a deprecated tool I > wrote for firmware security debugging. I agree completely with Scott. An interesting data point, however, is that over half of the machines sent for repair in Uruguay are fixed simply by reflashing the machine. This may be an artifact of the old build they are using, but it is a disturbing statistic. In recent months, I've only had to reflash to fix problems which happened right after a previous reflash (#6906). > That said, there's a separate bug in trac about X not starting when > the NAND flash is full. I'm not sure if that's what you're referring > to as "not booting" or not, but we should fix that, too. > --scott > > -- > ( http://cscott.net/ ) > ___ > 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
Project:olpc-netutils has been set up
Tue, 3 Jun 2008 18:01:58 -0400, Michael Stone <[EMAIL PROTECTED]> wrote: 1. Project name : olpc-netutils Done. Your tree is here: git+ssh://[EMAIL PROTECTED]/git/projects/olpc-netutils Please follow instructions here for importing your project: http://wiki.laptop.org/go/Importing_your_project Let us know if you have any problems with your tree. Happy hacking. Cheers, -- Henry Edward Hardy [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New faster build 2009
http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build2009 Changes in build 2009 from build: 2005 Size delta: 0.00M -squeak-vm 3.10-3olpc2 +squeak-vm 3.10-3olpc3 --- Changes for squeak-vm 3.10-3olpc3 from 3.10-3olpc2 --- + fix running under compositing WM -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/faster-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Project Hosting Application: olpc-netscripts
1. Project name : olpc-netutils 2. Existing website, if any : None 3. One-line description : OLPC-specific user-land network software. 4. Longer description : Yani's collection of network status displays. 5. URLs of similar projects : Unknown. 6. Committer list Please let anyone with a dev account commit. Yani and I will be the contact people. 7. Preferred development model Please set up projects/olpc-netutils 8. Set up a project mailing list: [X] No 9. Commit notifications [EMAIL PROTECTED] 11. Translation [X] Set up the laptop.org Pootle server to allow translation commits to be made ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2009
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2009 Changes in build 2009 from build: 2005 Size delta: 0.00M -squeak-vm 3.10-3olpc2 +squeak-vm 3.10-3olpc3 --- Changes for squeak-vm 3.10-3olpc3 from 3.10-3olpc2 --- + fix running under compositing WM -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ 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: [OLPC Security] Bitfrost and dual-boot
On 30.05.2008 08:34, Albert Cahalan wrote: > On Fri, May 30, 2008 at 1:15 AM, Edward Cherlin <[EMAIL PROTECTED]> wrote: > >> On Thu, May 29, 2008 at 8:45 PM, Albert Cahalan <[EMAIL PROTECTED]> wrote: >> >>> On Thu, May 29, 2008 at 5:07 PM, Edward Cherlin <[EMAIL PROTECTED]> wrote: >>> >>> Also, I think you completely misunderstand the market. The ability to use Open FirmWare instead of a proprietary BIOS will be of intense interest to all PC vendors. I expect OFW to sweep through most of the market in no more than two or three years. >>> I can't imagine why. LinuxBIOS (now coreboot) didn't. >>> Even EFI didn't. Your wishes are not their wishes. >>> >> Albert, I'm not talking to you any more until you start making sense. >> Linux BIOS never booted any Windows other than 2000 (with ADLO), and >> That's not really true. coreboot (former LinuxBIOS) does boot XP and Vista with the right payload. I should know it, I'm one of the coreboot developers. Granted, that knowledge is not spread far and wide. >> EFI isn't Open Source. >> That's not entirely accurate. There are EFI implementations which are Open Source, but EFI is just a presentation layer and performs no hardware init, so you're back to square one. > You think the PC vendors care that EFI isn't Open Source? > You think the PC vendors care that BIOS isn't Open Source? > Really, they have NO desire for Open Source firmware. > Indeed. Some companies say that any public code for hardware init poses a threat to their intellectual property and/or is baaad for various made-up reasons. > That's your desire, not theirs. Do not assume they think like you. > I can tell you how many hardware vendors think: - Does it reduce cost? If not, scratch the idea. - Does it make the lawyers nervous? If yes, scratch the idea. In general, lawyers of hardware vendors get nervous once somebody suggests to publish anything, regardless whether the content is obvious or not. - Is it still compatible with DOS and any and all legacy operating systems ever invented (including Windows 95/98/ME)? If not, scratch the idea unless your intended market (high-end gaming rigs or somesuch) will never want that compatibility. This is evident from the mainboards you can actually buy with EFI. Regards, Carl-Daniel ___ 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
XO communications interface naming
> From a practical perspective though, in XOs, the onboard interface is > always eth0 these days. I don't have wireless - am using an USB-ethernet adapter instead. Once upon a time, my G1G1 XO would set up its wired interface on 'eth0'. I normally run Joyride, and in the last couple of months there has been __NO__ regularity in which interface name is used for which communications interface -- one build will give the 'eth0' name to the wired interface, the next build will give the 'eth1' name to the wired interface, the subsequent build is back to 'eth0', and so on. [Often, when the interface is 'eth1', the radio interface (to the non-existent school ?) is given the name 'eth2' -- but the mesh interface name remains 'msh0'.] I've given up trying to make any sense out of the names given to the communications interfaces - I just 'ifconfig' and look for the wired IP address. mikus p.s. If my XO ever suspends, the wired interface is NOT resumed (and all interfaces get set to the inboard radio). [Maybe 'suspend' is something to be avoided by systems having an active antenna.] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Localization] [Fwd: Re: #7116 NORM Never A: Possible European G1G1 program needs appropriate keyboards]
On Tue, Jun 3, 2008 at 9:39 AM, LASKE, Lionel (C2S) <[EMAIL PROTECTED]> wrote: > > Hi Edward, Hi Kim, > > Many thanks for your answer. > >> >> setxkbmap fr >> > Okay, I will try it. Of course, I need to stick some little stamps on each > key :-) I don't know sources in Europe, but one of the best in the US for key labels is Hooleon.com. It might be that we should just put a sheet in with each XO for countries where we don't print the keytops appropriately. Or just tell people how to order them. I don't use stickers for non-QWERTY layouts myself. I prefer to print out layout diagrams and learn to touch-type. Efficiency expert Frank Gilbreth got his children typewriters with blank key caps to push them to touch-typing, as he described in Cheaper by the Dozen. That's a technically but not socially viable solution to incorrect key labels. It would certainly freak out many buyers. :-( >> Arranging for printed key tops for every standard layout in Europe >> would be a logistical nightmare. The most recent proposal is to ship >> US International, although the question of Greek and Cyrillic has been >> raised. > Another idea: put several keyboard in each G1G1 box, one for the French > Keyboard, one for the Deutschland Keyboard, ... > As NN said: "Everyone should try disassembling their XO", so if someone want > a localized keyboard, it should disassembly the XO first to plug the right > keyboard. (http://wiki.laptop.org/go/Image:Keyboardstep4d.jpg). > But maybe it's a costly solution, it depend of the individual cost for the > keyboard piece. The logistical problem begins with printing the keytop labels, or more precisely with determining how many of each to print. >> Some compromise might be in order. Spanish is certainly >> available for manufacturing. Haiti does not use the French layout, so >> French has not been done. Correction: French was done for Rwanda. > As you said, the French keyboard seems to be available > (http://wiki.laptop.org/go/OLPC_French_Keyboard). > Due to the image name "800px-Rwanda-B3.png", it probably came from the Rwanda > pilot ? > > >> >> Anybody who wants to volunteer for such documentation, keyboard file, >> and scripting work should let me and Kim Quirk know. >> > Of course, I'm volunteer to help you. I'm already Volunteer and Language > Administrator to translate English to French. Few other people at OLPC France > are also contributor to the project (Samy Boutayeb, Miguel Alvarez, Xavier > Carcelle, ...) > Let me know what we could do. Are you comfortable editing Linux system files? If so, we can create a project to XO-ize all of the standard keyboard layout files. The work is not arduous, but requires great precision of execution and extreme clarity of communications. Kim, how should that project be organized? Should we file a bug for each target keyboard? I can add a table to the OLPC Keyboard Layouts Wiki page of what needs to be done, and who has signed up to do what. I can also write the procedure. I see that some XO keyboard layouts simply add an OLPC section to the standard files. Walter, Kim, what can you tell us about XO-ization? How standard are the changes for Latin-alphabet layouts? What do we know about the remaining non-Latin layouts? Who else has worked on this? > Best regards. > >Lionel. -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ "The best way to predict the future is to invent it."--Alan Kay ___ 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: [Fwd: Re: #7116 NORM Never A: Possible European G1G1 program needs appropriate keyboards]
Agreed, Ed. The legalities of each country need to be determined and met before we can include that country in a Give One Get One program. Some of the things we need to understand are: Certifications, language/keyboard requirements, messaging, non-profit status, shipping, customs, support and warranties. I believe these issues (and perhaps more) will be different for almost every country. Kim On Sat, May 31, 2008 at 11:18 AM, Edward Cherlin <[EMAIL PROTECTED]> wrote: > On Fri, May 30, 2008 at 7:09 AM, Kim Quirk <[EMAIL PROTECTED]> wrote: >> Adam and Support gang, >> >> A second G1G1 program will still be only US/International keyboards >> (http://wiki.laptop.org/go/OLPC_Keyboard_layouts#US_International_keyboard). >> There are too many logistics, production, forecasting, and shipping >> issues associated with more than a couple of SKUs (different laptop >> configurations) for a G1G1 program. > > I don't know whether that is acceptable to Europe. They want Cyrillic > (Bulgarian and Serbian layouts are completely different from each > other and from Russian, Ukrainian, and Belarusian, which are all quite > similar), Greek, and Eastern European (Czech, Slovak, Polish...are > nearly identical), at least. I can look up the standard layouts in > more detail if that will help. You need to specify exactly which > countries will be included in your version of Europe. Lithuania, > Latvia, and Estonia are EU members. So are Malta and Cyprus. Turkey is > a candidate. Croatia, Bosnia/Herzegovina, Serbia, Macedonia, > Montenegro, and Albania are not members. > > You had better get the lawyers to check out EU regulations on computer > sales. I suppose that you can get away with printing only US > International on the keyboard as long as you say so, very clearly, in > the announcements and ads, and explain how to access the other layouts > in a document shipped with the laptops. > >> But, from a languages perspective, It would be great to point >> translators for European languages (or any languages) to various ways >> in which they can help translate our wiki pages and add to the product >> translations through Pootle. > > IFYP > >> Here are some links: >> Localization of XO files: http://wiki.laptop.org/go/Localization >> Translating wiki pages: http://wiki.laptop.org/go/Translating > Pootle page, including table of localizers: http://wiki.laptop.org/go/Pootle > Pootle: http://dev.laptop.org/translate > Localization mailing list at http://lists.laptop.org/ > >> Thanks, >> Kim >> >> >> On Thu, May 29, 2008 at 3:14 PM, Adam Holt <[EMAIL PROTECTED]> wrote: >>> Dear Kim, >>> >>> Can we get some preliminary discussion going in the next couple weeks, >>> towards helping people set up fuller support >>> structure for those European languages? > > Talk to me about any language support issues that management isn't handling. > >>> Or if nothing else, an idea as to how many EU countries are liable to be >>> supported for 2008's G1G1? >>> >>> Whether it's 2 countries or 12 countries makes all the world of difference > > Uh, actually there are 27 countries in the EU, and 8 candidates. > Non-members include Switzerland, Norway, and the new countries formed > from former Yugoslavia (except Slovenia). > >>> ;) >>> --A! > > %-[ > > -- > Edward Cherlin > End Poverty at a Profit by teaching children business > http://www.EarthTreasury.org/ > "The best way to predict the future is to invent it."--Alan Kay > ___ 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: UL warning fun.
I think perhaps I should clarify that: a) the image is a joke, designed to be amusing b) NOT intended for actual use on a deployed XO c) the Spanish "translations" are in fact not literal translations d) the Spanish, like the English, is not intended to be actually helpful. Or safe. There are actual warning phrases that go along with each of the 8 icons, and I believe they are written on the flyer which comes inside the XO box, but the attached image does *not* include the actual warnings. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: UL warning fun.
C. Scott Ananian escribió: Mitch and my joint work seems to be making the rounds again, so I thought I'd take the opportunity to quickly repost the relevant URL: http://dev.laptop.org/~cscott/ul_warning.png I would like to suggest Spanish text arrangements: * Niños hacen caca -> OK * Guardarte de los terremotos -> Wrong Cuidado con los terremotos Evita los terremotos Evita aterrizajes forzosos (I like this!) * Al XO no le gustan tus pies olorosos Aleja tus pies olorosos * Los XO son gruñones cuando llueve El agua provoca mal carácter Mejor tener mugre que ver agua * Tener cuidado que carguen a tus padres completamente -> Wrong Los mayores se encargan de la carga Deja que los mayores cargen * El XO puede encender tus cigarrillos (uf! ugly, not cigarrets for children!!) La punta del cable patea La corriente está en la punta del cable * Oye, niños! Un juego nuevo! El cable puede enganchar los pies No es divertido tropezar el cable * El XO alivia la tensión Te frustras si golpeas El golpe produce frustración Golpear es aburrido (Last four Spanish messages are uncomprensible and NOT "CIGARRILLOS"!! plis!) In Spanish you have a problem with genere of the article because * El XO - el laptop - el ordenador (Spain name) * La XO - la laptop - la computadora (South America, Mexico, name) then we suggest to avoid article or name 'XO' or 'laptop'. Regards, Rodolfo Pilas signature.asc Description: OpenPGP digital signature ___ 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: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: Project hosting application: Bundlemaker
Cool! I would call this "bookbinder" if it were an activity. ___ 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: [Server-devel] Edublog notes
Greg, Wad, The people I'm working with apparently are familiar with Moodle rather than Drupal, so that might be the way to go for me&them in that sense (funny, Aymara has a different form for the "us" me-and-them, different from me-and-y'all, would be handy in this sentence), though I am very curious about the EduBlog as well. > My suggestion is to use Moodle, let teachers and sys admins set it up. Uh, might need some hand-holding there, for those prospective teachers & admin. I myself have never set up a successful Moodle server, will have to call that a priority so as to learn what a noob has to face. Have already several offers of help, so no need you personally to worry about this. > BTW I need more people to test out the EduBlog GUI during Beta test, > I need a teacher, a kid and an admin so let me know if you sign me up if you want to let me give it a try. No kids here, but I can virtualize the other two, and maybe borrow a kid or two at the crucial moments. Y'all know I am obsessive about ease of use and vocal to the point of bad manners... :-) Yama Greg Smith (gregmsmi) wrote: > Hi Yama and Wad, > > Give us a blog hosting app. and an API. EduBlog adds a one click HTML > front end with an option for teachers to approve posts. The blog can be > hosted anywhere routable from XS (e.g. on XS itself), no internet > needed. > > That's the idea, we'll see how it turns out :-) > > I'll leave it to others to comment on what blog hosting tools are > planned for XS. I believe Moodle has or will have a blog tool and if > Moodle is in default XS build that's an obvious choice. Drupal is > another option. Ceibal jam people investigated this and client side > ideas a little. See: http://wiki.laptop.org/go/Ceibal_Jam/Blogs > > My suggestion is to use Moodle, let teachers and sys admins set it up. > Then use EduBlog to allow kids to post. If kids are comfortable posting > right to Moodle Blog UI then you don't even need EduBlog. > > HTHs. > > BTW I need more people to test out the EduBlog GUI during Beta test, > target late July. You're going to need internet and preferably an XO for > the Beta. I need a teacher, a kid and an admin so let me know if you > have any contacts who are interested. > > Thanks, > > Greg S > > -Original Message- > From: Yama Ploskonka [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 03, 2008 10:23 AM > To: John Watlington > Cc: Greg Smith (gregmsmi); [EMAIL PROTECTED] > Subject: Re: [Server-devel] Edublog notes > > I second this request for off-internet solutions. > > I am currently cooperating with a Bolivian Ministry of Education project > for community/school centers which depends largely on blogging and such > tools, so I am following this thread closely for concepts / ideas / > solutions that would be obsessively user friendly. > It would be just the best of both worlds if the same tool were used for > XOs when we do get a deployment there! > > Yama > > John Watlington wrote: >> What do we provide for the schools which don't have internet access >> right now ? >> >> Should the XS contain some blog hosting software which can actually >> host the pages created by this tool ?(Pardon my ignorance of > whether >> Moodle already contains such.) >> >> wad >> >> On Jun 3, 2008, at 9:27 AM, Greg Smith (gregmsmi) wrote: >> >>> Hi Martin, >>> >>> On the sanity check, that's not it :-( >>> >>> It my fault for not explaining it better! I really hope Tarun, Marcel > >>> and Pablo are more in synch... It will be more clear once we get some > >>> draft/static HTML pages in place. >>> >>> I'll take some HTML editing help if anyone thinks they can mock up 3 >>> static HTML Pages based on the text here: >>> http://wiki.laptop.org/go/Blog_Educativo_Plan_del_Proyecto >>> >>> Here's another earlier write up which includes a network diagram >>> which may help explain the parts. >>> http://wiki.laptop.org/go/Educational_Blogger_Project >>> >>> We do not plan to code, host, share or serve any blogs! All we will >>> build is a simple front end that let's users create a blog post and >>> click once to have it appear on a Moodle Blog, Blogger.com, Drupal >>> etc. >>> >>> Kids enter content, clicks post and that's it. The back end SW >>> running on the XS takes that post and puts it on the blog e.g. >>> http://centenarioescuela38sg.blogspot.com/ >>> >>> The SW we will build on the XS may include Apache + PHP + DB for HTML > >>> towards client and probably XML + RPC or SOAP towards blog API. There > >>> will be three main web pages and we will build no client code on the >>> XO at all, just support Browse! I need it to be simple so we can >>> build in 7 weeks. >>> >>> Three web pages towards the client then APIs towards supported blog >>> systems on XS. That's everything. Let me know if that explains it >>> better or its still not clear. >>> >>> I'll think about the database comments too. Let me see what fields >>> and tables Tarun thinks he nee
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
UL warning fun.
Mitch and my joint work seems to be making the rounds again, so I thought I'd take the opportunity to quickly repost the relevant URL: http://dev.laptop.org/~cscott/ul_warning.png also: http://wiki.laptop.org/go/Replacing_the_shutdown_screen Enjoy! --scott -- ( http://cscott.net/ ) ___ 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: Software Status Meeting Tomorrow @ 1600 EDT, 2000 UTC in #olpc-meeting on freenode
On Tue, Jun 3, 2008 at 6:09 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > Martin Langhoff, our esteemed school-server architect asked us if we > could wake him up at 6:00 AM (in NZ) instead of 4:00 (AM). Can we > oblige? > > Please note the new times: > > 4:00 PM EST, 2000 UTC. > > I expect that we'll spend the bulk of our time discussing work toward > 8.2.0, a.k.a. the August Release. I'll try to make it but I'm not sure I'll manage to :( 10 pm is not best for me... Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
On Tue, Jun 3, 2008 at 12:43 PM, Bert Freudenberg <[EMAIL PROTECTED]> wrote: > On 03.06.2008, at 18:33, ffm wrote: >> On Tue, Jun 3, 2008 at 12:29 PM, C. Scott Ananian >> <[EMAIL PROTECTED]> wrote: >>> Machines sent out via our developer program are always shipped out >>> unsecured. >> >> Yet I've just recived two laptops via said program that had security >> enabled. > > Indeed. The machines distributed at LinuxTag last week also came w/o > dev key - I think it is only the activation part that is disabled. My information may be out of date on the developer's program, since Adam has rebooted it recently and I don't think that developer's program machines actually come through OLPC any more. I should have said, "used to be shipped out unsecured". Adam, are the new developer's program machines shipped direct, or do we have an opportunity to (at least) include a flyer explaining how to disable security on the machine? --scott -- ( http://cscott.net/ ) ___ 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
Activities bundle
I can't remember where the .rpm is for all the activities for late-model (recent joyride), since the joyride images no longer seem to contain any activities. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Project hosting application: Bundlemaker
1. Project name : Bundlemaker
2. Existing website, if any : http://wiki.laptop.org/go/Bundlemaker
3. One-line description : A shell script that takes an index page on
the web and pulls it, and all the pages it references, into a .xol
library bundle.
4. Longer description :Bundlemaker is a script that takes an index
page on the web and pulls it, and all the pages it references, into a
library bundle. It is useful for things like Wikislices. At the end of
running the script (it is quiet and may take several minutes as it
downloads files) you should have a bundlename.xol file in the directory
you ran the script on, ready to go on the XO.
5. URLs of similar projects :
http://wiki.laptop.org/go/Creating_a_content_bundle (but it's not a script)
6. Committer list
Username Full name SSH2 key URL
E-mail
-
--
#1 mchua Mel Chuahttp://melchua.com/tmp/id_dsa.pub
7. Preferred development model
[X] Central tree.
8. Set up a project mailing list:
[X] No
9. Commit notifications
[X] No commit notifications, please
10. Shell accounts
already have one - mchua
11. Translation
[X] Set up the laptop.org Pootle server to allow translation commits
to be made (once the script matures somewhat, the instructions to use
the script should definitely be localized.)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
On 03.06.2008, at 18:33, ffm wrote: > On Tue, Jun 3, 2008 at 12:29 PM, C. Scott Ananian > <[EMAIL PROTECTED]> wrote: >> Machines sent out via our developer program are always shipped out >> unsecured. > > Yet I've just recived two laptops via said program that had security > enabled. Indeed. The machines distributed at LinuxTag last week also came w/o dev key - I think it is only the activation part that is disabled. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
sugar on olpc3-16
Hi, for those people who need to work on something closer than f7 to what will ship in august (performance, xulrunner, X, etc), Blaketh gave this tip on #sugar: unmadindu, you can also copy the olpc-blah from /etc/pam.d/ on a working f7 laptop to the f9 laptop, then olpc-dm will work. http://pilgrim.laptop.org/~pilgrim/olpc/streams/olpc3/build16/devel_jffs2/ Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
On Tue, Jun 3, 2008 at 12:07 PM, ffm <[EMAIL PROTECTED]> wrote: > Why were G1G1 machines shipped with firmware, kernel, and reflash locks > enabled? (see http://wiki.laptop.org/go/Developer_keys ) > > Theft is not a good reason, as they do not require activation leases. > > It only seems to be a bother for people who want to help out with the OLPC > project. The original reason is that it allowed our G1G1 users to more fully exercise/test our secure boot paths, which are used in our deployment countries. This helps G1G1 users be more representative testers, and did successfully flush out security logistics issues like the ones you seem to be complaining about before they became a big issue for deployment countries. A secondary consideration was that secure boot is tied to "pretty boot", since we assume that if you are a developer you won't be scared of boot messages. A non-tech-team charge was to ensure that G1G1 machines looked pretty while booting. This seems trivial to us, but was in fact a big concern for non-developers involved in the program. These issues can probably be revisited before a second G1G1 program, but my personal feeling is that we eventually do have to make the antitheft security stuff "just work" and not get in ordinary people's way (if you're a developer, you should be able to acquire a developer key easily and you should do so). Having G1G1 use a subset of these features allows more extensive testing and thus helps us produce better software for deployment countries. So, contrary to your statement that "it only seems to be a bother for people who want to help out with the OLPC project", having security enabled is one of the direct ways that people who want to help out *are in fact already doing so*. [And complaining about security when it gets in your way, within reason, is also directly helping out. =) ] G1G1 has always had slightly mixed goals, because N% of the people buying G1G1 machines are developers, and ~(100-N)% are parents or grandparents of small children. I believe N is well below 50%, based on devel@ traffic. Machines sent out via our developer program are always shipped out unsecured. We assume that G1G1 developers have the ability to request a developer key and disable security, and we recommend they do so; the security features are not meant for them. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: JFFS2 error messages
On Tue, 2008-06-03 at 12:13 -0400, C. Scott Ananian wrote: > 2008/6/3 Bill Mccormick <[EMAIL PROTECTED]>: > > A couple of my XOs are reporting what look like FS error messages on boot: > > > > [91.463670] JFFS2 notice: (664) check_node_data: wrong data CRC in data > > node at 0x1ec215f0: read 0x3e7c7e03, calculated 0xf7e1d50c > > ... > > > > is this a known problem? > > According to Dave Woodhouse, who wrote JFFS2, these notices typically > mean that at some point you've hard powered off, and as a result JFFS > has some uncommitted data lying around on flash. It's almost always > harmless, a part of the journal which was never committed: "either it > was a new write which hadn't yet been synced, or it was a GC write > which just doesn't achieve anything now." However, these messages > *could* indicate an actual problem -- "we never came up with a good > heuristic for when _not_ to complain". Woodhouse suggests that in the > future "perhaps we should write a 'yes, I know there's a CRC failure' > node _after_ the offending node, when we reboot and find it" since > directly rewriting the node is not an option due to the mechanics of > NAND flash; that would help confine these messages to immediately > after a hard reboot. At present, you'll keep seeing a "bad CRC" > message every time that particular JFFS node is accessed until it is > eventually GC'ed. > > Anyone want to volunteer to turn the above into a FAQ which would be > discoverable on our wiki, so that future wonderers don't have to pry > the information from the head of dwmw2? I think it's already in trac as an RFE. I even respond to email about it when the email in question isn't HTML. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: JFFS2 error messages
2008/6/3 Bill Mccormick <[EMAIL PROTECTED]>: > A couple of my XOs are reporting what look like FS error messages on boot: > > [91.463670] JFFS2 notice: (664) check_node_data: wrong data CRC in data > node at 0x1ec215f0: read 0x3e7c7e03, calculated 0xf7e1d50c > ... > > is this a known problem? According to Dave Woodhouse, who wrote JFFS2, these notices typically mean that at some point you've hard powered off, and as a result JFFS has some uncommitted data lying around on flash. It's almost always harmless, a part of the journal which was never committed: "either it was a new write which hadn't yet been synced, or it was a GC write which just doesn't achieve anything now." However, these messages *could* indicate an actual problem -- "we never came up with a good heuristic for when _not_ to complain". Woodhouse suggests that in the future "perhaps we should write a 'yes, I know there's a CRC failure' node _after_ the offending node, when we reboot and find it" since directly rewriting the node is not an option due to the mechanics of NAND flash; that would help confine these messages to immediately after a hard reboot. At present, you'll keep seeing a "bad CRC" message every time that particular JFFS node is accessed until it is eventually GC'ed. Anyone want to volunteer to turn the above into a FAQ which would be discoverable on our wiki, so that future wonderers don't have to pry the information from the head of dwmw2? --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Software Status Meeting Tomorrow @ 1600 EDT, 2000 UTC in #olpc-meeting on freenode
Martin Langhoff, our esteemed school-server architect asked us if we could wake him up at 6:00 AM (in NZ) instead of 4:00 (AM). Can we oblige? Please note the new times: 4:00 PM EST, 2000 UTC. I expect that we'll spend the bulk of our time discussing work toward 8.2.0, a.k.a. the August Release. Michael ___ 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 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: Autoreinstallation image is not signed.
On Tue, Jun 3, 2008 at 11:28 AM, ffm <[EMAIL PROTECTED]> wrote: > C. Scott Ananian-3 wrote: >> http://wiki.laptop.org/go/Olpc-update#USB_upgrade > This will not work if the OS is not bootable and no alt-os image is on the > disk. We should continue to try very hard not to let the OS become unbootable. If it is unbootable, something Very Wrong should have occurred and there's no guarantee that "mount the filesystem and copy off /home" will work either. Using a dev key and a rescue disk is probably a much better bet than any attempt at automagic. Please file bugs on ways you've managed to make the OS unbootable, or ways the alt-os image breaks (there are a few); these are likely to get more attention than trying to resuscitate a deprecated tool I wrote for firmware security debugging. That said, there's a separate bug in trac about X not starting when the NAND flash is full. I'm not sure if that's what you're referring to as "not booting" or not, but we should fix that, too. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Server-devel] uruguay server hardware
There has been some questions about what hardware Uruguay is using for school servers. They are placing a second tender right now, but the first batch of servers were: (An IBM x3105) 1.6 - 1.8 GHz AMD processor 2 GB RAM 160 GB disk (two drives, in RAID 1) three NICs (one WAN, and two LAN) the intent was to have a WiFi network inside the school and another for outside the school, but they are currently only using a single WiFi network. Six USB slots DVD-RW for backup These machines stop working at temperatures higher than 40C. (Crash, not nice power-off) The RAM size was chosen to better support Squid and Dansguardian. The small disk size is due to the costs of disks when bought through server vendors and there not being XO backup at this point. Watchdog and remote monitoring boards are recommended (but not currently installed.) All errors are mine, wad ___ Server-devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/server-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 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: Autoreinstallation image is not signed.
C. Scott Ananian-3 wrote: > > http://wiki.laptop.org/go/Olpc-update#USB_upgrade > This will not work if the OS is not bootable and no alt-os image is on the disk. C. Scott Ananian-3 wrote: > > Finally, 8.2 will have better backup/restore functionality, so the > "real" solution then will be reflash+restore. > As long as backups are made automagically and often... -FFM -- View this message in context: http://www.nabble.com/Autoreinstallation-image-is-not-signed.-tp17612809p17626313.html Sent from the OLPC Software development mailing list archive at Nabble.com. ___ 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 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 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
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 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, 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
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: [Server-devel] Edublog notes
Hi Yama and Wad, Give us a blog hosting app. and an API. EduBlog adds a one click HTML front end with an option for teachers to approve posts. The blog can be hosted anywhere routable from XS (e.g. on XS itself), no internet needed. That's the idea, we'll see how it turns out :-) I'll leave it to others to comment on what blog hosting tools are planned for XS. I believe Moodle has or will have a blog tool and if Moodle is in default XS build that's an obvious choice. Drupal is another option. Ceibal jam people investigated this and client side ideas a little. See: http://wiki.laptop.org/go/Ceibal_Jam/Blogs My suggestion is to use Moodle, let teachers and sys admins set it up. Then use EduBlog to allow kids to post. If kids are comfortable posting right to Moodle Blog UI then you don't even need EduBlog. HTHs. BTW I need more people to test out the EduBlog GUI during Beta test, target late July. You're going to need internet and preferably an XO for the Beta. I need a teacher, a kid and an admin so let me know if you have any contacts who are interested. Thanks, Greg S -Original Message- From: Yama Ploskonka [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 10:23 AM To: John Watlington Cc: Greg Smith (gregmsmi); [EMAIL PROTECTED] Subject: Re: [Server-devel] Edublog notes I second this request for off-internet solutions. I am currently cooperating with a Bolivian Ministry of Education project for community/school centers which depends largely on blogging and such tools, so I am following this thread closely for concepts / ideas / solutions that would be obsessively user friendly. It would be just the best of both worlds if the same tool were used for XOs when we do get a deployment there! Yama John Watlington wrote: > What do we provide for the schools which don't have internet access > right now ? > > Should the XS contain some blog hosting software which can actually > host the pages created by this tool ?(Pardon my ignorance of whether > Moodle already contains such.) > > wad > > On Jun 3, 2008, at 9:27 AM, Greg Smith (gregmsmi) wrote: > >> Hi Martin, >> >> On the sanity check, that's not it :-( >> >> It my fault for not explaining it better! I really hope Tarun, Marcel >> and Pablo are more in synch... It will be more clear once we get some >> draft/static HTML pages in place. >> >> I'll take some HTML editing help if anyone thinks they can mock up 3 >> static HTML Pages based on the text here: >> http://wiki.laptop.org/go/Blog_Educativo_Plan_del_Proyecto >> >> Here's another earlier write up which includes a network diagram >> which may help explain the parts. >> http://wiki.laptop.org/go/Educational_Blogger_Project >> >> We do not plan to code, host, share or serve any blogs! All we will >> build is a simple front end that let's users create a blog post and >> click once to have it appear on a Moodle Blog, Blogger.com, Drupal >> etc. >> >> Kids enter content, clicks post and that's it. The back end SW >> running on the XS takes that post and puts it on the blog e.g. >> http://centenarioescuela38sg.blogspot.com/ >> >> The SW we will build on the XS may include Apache + PHP + DB for HTML >> towards client and probably XML + RPC or SOAP towards blog API. There >> will be three main web pages and we will build no client code on the >> XO at all, just support Browse! I need it to be simple so we can >> build in 7 weeks. >> >> Three web pages towards the client then APIs towards supported blog >> systems on XS. That's everything. Let me know if that explains it >> better or its still not clear. >> >> I'll think about the database comments too. Let me see what fields >> and tables Tarun thinks he needs and I'd like to get his input. >> >> Tarun and Marcel, let me know ASAP if the description above is not >> clear. I think we are in synch but it never hurts to re-ack (there's >> a reason why TCP is a triple handshake :-). >> >> BTW better book mark those two links. The main Uruguay page just got >> a major re-edit and those links are now very hard to find. >> >> Other than that the new page is packed with info and links thanks to >> Pablo! http://wiki.laptop.org/go/Uruguay >> >> Thanks, >> >> Greg S >> >> -Original Message- >> From: Martin Langhoff [mailto:[EMAIL PROTECTED] >> Sent: Monday, June 02, 2008 5:38 PM >> To: Greg Smith (gregmsmi) >> Cc: [EMAIL PROTECTED] >> Subject: Re: Edublog notes (was: Re: The road towards xs-0.3 - >> update) >> >> On Tue, Jun 3, 2008 at 7:09 AM, Greg Smith (gregmsmi) >> <[EMAIL PROTECTED]> wrote: >>> Sanity check on our high level concept. >>> >>> The core idea of this software is to present an easy to use >>> interface so kids can post to blogs. Enter text, click post you are done. >> Yes, and that's fantastic. But if I understand it right, we are >> talking about 3 stages: >> >> 1 - Blogging tool on the XO - >> >> Something like Drivel, lets the user blog on the XO even while >> disconnected. New articles an
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: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
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
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 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
JFFS2 error messages
Hi, A couple of my XOs are reporting what look like FS error messages on boot: [91.463670] JFFS2 notice: (664) check_node_data: wrong data CRC in data node at 0x1ec215f0: read 0x3e7c7e03, calculated 0xf7e1d50c ... is this a known problem? Should I raise a ticket for it, and where is the procedure for this? thx, Bill Bill McCormick Open innovation lab Nortel ESN 393-6298 External (613) 763-6298 ___ 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
[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 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: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.
>
> 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: [Server-devel] Edublog notes
I second this request for off-internet solutions. I am currently cooperating with a Bolivian Ministry of Education project for community/school centers which depends largely on blogging and such tools, so I am following this thread closely for concepts / ideas / solutions that would be obsessively user friendly. It would be just the best of both worlds if the same tool were used for XOs when we do get a deployment there! Yama John Watlington wrote: > What do we provide for the schools which don't have internet access > right now ? > > Should the XS contain some blog hosting software which can actually > host the pages created by this tool ?(Pardon my ignorance of whether > Moodle already contains such.) > > wad > > On Jun 3, 2008, at 9:27 AM, Greg Smith (gregmsmi) wrote: > >> Hi Martin, >> >> On the sanity check, that's not it :-( >> >> It my fault for not explaining it better! I really hope Tarun, Marcel >> and Pablo are more in synch... It will be more clear once we get some >> draft/static HTML pages in place. >> >> I'll take some HTML editing help if anyone thinks they can mock up 3 >> static HTML Pages based on the text here: >> http://wiki.laptop.org/go/Blog_Educativo_Plan_del_Proyecto >> >> Here's another earlier write up which includes a network diagram which >> may help explain the parts. >> http://wiki.laptop.org/go/Educational_Blogger_Project >> >> We do not plan to code, host, share or serve any blogs! All we will >> build is a simple front end that let's users create a blog post and >> click once to have it appear on a Moodle Blog, Blogger.com, Drupal >> etc. >> >> Kids enter content, clicks post and that's it. The back end SW running >> on the XS takes that post and puts it on the blog e.g. >> http://centenarioescuela38sg.blogspot.com/ >> >> The SW we will build on the XS may include Apache + PHP + DB for HTML >> towards client and probably XML + RPC or SOAP towards blog API. There >> will be three main web pages and we will build no client code on >> the XO >> at all, just support Browse! I need it to be simple so we can build >> in 7 >> weeks. >> >> Three web pages towards the client then APIs towards supported blog >> systems on XS. That's everything. Let me know if that explains it >> better >> or its still not clear. >> >> I'll think about the database comments too. Let me see what fields and >> tables Tarun thinks he needs and I'd like to get his input. >> >> Tarun and Marcel, let me know ASAP if the description above is not >> clear. I think we are in synch but it never hurts to re-ack (there's a >> reason why TCP is a triple handshake :-). >> >> BTW better book mark those two links. The main Uruguay page just got a >> major re-edit and those links are now very hard to find. >> >> Other than that the new page is packed with info and links thanks to >> Pablo! http://wiki.laptop.org/go/Uruguay >> >> Thanks, >> >> Greg S >> >> -Original Message- >> From: Martin Langhoff [mailto:[EMAIL PROTECTED] >> Sent: Monday, June 02, 2008 5:38 PM >> To: Greg Smith (gregmsmi) >> Cc: [EMAIL PROTECTED] >> Subject: Re: Edublog notes (was: Re: The road towards xs-0.3 - update) >> >> On Tue, Jun 3, 2008 at 7:09 AM, Greg Smith (gregmsmi) >> <[EMAIL PROTECTED]> wrote: >>> Sanity check on our high level concept. >>> >>> The core idea of this software is to present an easy to use interface >>> so kids can post to blogs. Enter text, click post you are done. >> Yes, and that's fantastic. But if I understand it right, we are >> talking >> about 3 stages: >> >> 1 - Blogging tool on the XO - >> >> Something like Drivel, lets the user blog on the XO even while >> disconnected. New articles and edits get placed in a queue and pushed >> out when we see the XS. This needs Sugar integration work so it's a >> candidate for a write-from-scratch effort or, more likely, a wrapping >> around the abiword-based Write.xo . >> >> 2 - Blog on the XS >> >> This should >> - display blog entries like a normal blog does >> - receive blog entries and edits from the xo-based tool >> - allow new blog entries and edits from a web UI >> - allow "approval" stages >> - "forward" blog entries & edits that are tagged 'public' to an >> internet-hosted blog >> >> Some of this aspects are _complex_, even if they sound trivial. So I >> heavily recommend a pre-existing blog tool. Grab something that is >> good, >> offers good APIs, is well maintained and known to be scalable. >> And then patch it here and there to do what we want :-) >> >> 3 - Blog on the Internet. >> >> This bit is not under our control ;-) >> >>> Let me know if you have any comments or questions and I hope its >>> clear >>> now we are not building another blog hosting system. >> Ok, so my understanding (and hope) is that you are building #1 above, >> and patching an existing blog tool for #2. >> >>> Back to the DB. The EduBlog web app needs a table to store its own >>> info (e.g. configured blog URLs, blog user name/pass, posts submitted
Re: Autoreinstallation image is not signed.
http://wiki.laptop.org/go/Olpc-update#USB_upgrade You can also boot from the ext2 build on an SD card as a recovery mechanism. Finally, 8.2 will have better backup/restore functionality, so the "real" solution then will be reflash+restore. Please don't use the autoreinstallation key. It has past its "use by" date. --scott -- ( http://cscott.net/ ) ___ 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: [Server-devel] Edublog notes (was: Re: The road towards xs-0.3 - update)
Hi Martin, On the sanity check, that's not it :-( It my fault for not explaining it better! I really hope Tarun, Marcel and Pablo are more in synch... It will be more clear once we get some draft/static HTML pages in place. I'll take some HTML editing help if anyone thinks they can mock up 3 static HTML Pages based on the text here: http://wiki.laptop.org/go/Blog_Educativo_Plan_del_Proyecto Here's another earlier write up which includes a network diagram which may help explain the parts. http://wiki.laptop.org/go/Educational_Blogger_Project We do not plan to code, host, share or serve any blogs! All we will build is a simple front end that let's users create a blog post and click once to have it appear on a Moodle Blog, Blogger.com, Drupal etc. Kids enter content, clicks post and that's it. The back end SW running on the XS takes that post and puts it on the blog e.g. http://centenarioescuela38sg.blogspot.com/ The SW we will build on the XS may include Apache + PHP + DB for HTML towards client and probably XML + RPC or SOAP towards blog API. There will be three main web pages and we will build no client code on the XO at all, just support Browse! I need it to be simple so we can build in 7 weeks. Three web pages towards the client then APIs towards supported blog systems on XS. That's everything. Let me know if that explains it better or its still not clear. I'll think about the database comments too. Let me see what fields and tables Tarun thinks he needs and I'd like to get his input. Tarun and Marcel, let me know ASAP if the description above is not clear. I think we are in synch but it never hurts to re-ack (there's a reason why TCP is a triple handshake :-). BTW better book mark those two links. The main Uruguay page just got a major re-edit and those links are now very hard to find. Other than that the new page is packed with info and links thanks to Pablo! http://wiki.laptop.org/go/Uruguay Thanks, Greg S -Original Message- From: Martin Langhoff [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 5:38 PM To: Greg Smith (gregmsmi) Cc: [EMAIL PROTECTED] Subject: Re: Edublog notes (was: Re: The road towards xs-0.3 - update) On Tue, Jun 3, 2008 at 7:09 AM, Greg Smith (gregmsmi) <[EMAIL PROTECTED]> wrote: > Sanity check on our high level concept. > > The core idea of this software is to present an easy to use interface > so kids can post to blogs. Enter text, click post you are done. Yes, and that's fantastic. But if I understand it right, we are talking about 3 stages: 1 - Blogging tool on the XO - Something like Drivel, lets the user blog on the XO even while disconnected. New articles and edits get placed in a queue and pushed out when we see the XS. This needs Sugar integration work so it's a candidate for a write-from-scratch effort or, more likely, a wrapping around the abiword-based Write.xo . 2 - Blog on the XS This should - display blog entries like a normal blog does - receive blog entries and edits from the xo-based tool - allow new blog entries and edits from a web UI - allow "approval" stages - "forward" blog entries & edits that are tagged 'public' to an internet-hosted blog Some of this aspects are _complex_, even if they sound trivial. So I heavily recommend a pre-existing blog tool. Grab something that is good, offers good APIs, is well maintained and known to be scalable. And then patch it here and there to do what we want :-) 3 - Blog on the Internet. This bit is not under our control ;-) > Let me know if you have any comments or questions and I hope its clear > now we are not building another blog hosting system. Ok, so my understanding (and hope) is that you are building #1 above, and patching an existing blog tool for #2. > Back to the DB. The EduBlog web app needs a table to store its own > info (e.g. configured blog URLs, blog user name/pass, posts submitted > but not approved by teacher, options set for each student, etc.). > Should we store that in the same DB that moodle is already using and > just create some new tables or should we create a new DB for our own use? If you are talking about the queue of blog entries on the XO-based tool, you will probably want to use sqllite. For the XS-based local blog-and-foward tool, you _really_ need to get your head around how the core tool works, and you'll find that you want to add a few columns here or there. Most blog tools will already have a "Config" table to hold configuration, so that's easy. > In the future we may want to run a query on the moodle DB and web app > DB. E.g. get user name, class and school from Moodle DB then look up > configured blogs in web app DB. IME the blog tool will expect to have a copy of the user profile to be able to run joins across the data, and grab the relevant bits. So you'll want to copy the "user profile" data into it, and lock down the "user profile" editing in the blog tool itself. It's a bit of work - I know - but it's very important that
Re: [Localization] [Fwd: Re: #7116 NORM Never A: Possible European G1G1 program needs appropriate keyboards]
FYI, Bernie, Arjun, and I had begun a transition away from Compose keys even for the US International keyboard. I don't know if OLPC has decided to go down that path or not, but it has been paved. -walter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
