RE: WDS problems observed in today's testing
We encountered this problem elsewhere and found out that the latest version of the firmware from Linksys (only works on the WRT54G v8 routers btw; might also work for the WAP54G as well) resolves the WDS problem. http://www.linksys.com/servlet/Satellite?blobcol=urldatablobheadername1 =Content-Typeblobheadername2=Content-Dispositionblobheadervalue1=text% 2Fplainblobheadervalue2=inline%3B+filename%3DWRT54G-v8_v8.00.5_fwReleas eNotes.txtblobkey=idblobtable=MungoBlobsblobwhere=1193773201628ssbin ary=truelid=8663037401B159 (Please paste the above link on your browser; clicking on the above link somehow didn't work for me). In the firmware version 8.00.5, it specifically mentions: Resolves issue with using a WAP54G in repeater mode. This looks to be a fairly recent version of the firmware. Regards, Ronak -Original Message- From: [EMAIL PROTECTED] [mailto:devel- [EMAIL PROTECTED] On Behalf Of Jim Gettys Sent: Monday, March 03, 2008 10:38 AM To: [EMAIL PROTECTED] Cc: OLPC Developer's List Subject: Re: WDS problems observed in today's testing On Mon, 2008-03-03 at 10:22 -0800, Javier Cardona wrote: Jim, On 3/3/08, Jim Gettys [EMAIL PROTECTED] wrote: These were WRT54GL's running OpenWRT, just to ask the exact configuration? Not sure if it was a WRT54G or WRT54GL, but I'm certain that it was running the original Linksys firmware. Yup. They will always have the problem. My point was that if you see a WRT54G (as opposed to the WRT54GL), you have to dig deeper to figure out if they can run OpenWRT or not. Some can; some cannot Nothing like changing hardware in a significant way without changing the model number. This has details: http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/WRT54G?highlight=(O pe nWrtDocs/Hardware) - Jim -- Jim Gettys One Laptop Per Child ___ 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: Testing the Wireless driver changes
After downloading the firmware, the ARM is told by the boot2 to jump to a specific location of the internal memory. If the firmware is not downloaded, the boot2 starts the grab the firmware from the Flash and jumps to the same location of the internal memory once that is done. The flash tool does not figure out anything here. The boot2 code is smart enough to figure that out. Best Regards, Ronak From: Michail Bletsas [mailto:[EMAIL PROTECTED] Sent: Saturday, January 19, 2008 10:23 AM To: Dan Williams; Ronak Chokshi Cc: Ricardo Carrano; devel; David Woodhouse; Giannis Galanis; [EMAIL PROTECTED] Subject: Re: Testing the Wireless driver changes Does the Boot2 code take care of figuring out the correct address to write the thick firmware to, or does the flash tool have to figure out the address to write it to? Normally this address is embedded in the firmware flash file header, is there an address the tool should check for to verify, or is that address completely irrelevant because the boot2 code is smart enough to figure out where to put it? Dan, You have to ask Ronak that. Right now the flash writing logic lives in the firmware. M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: [Testing] Build 472 - testing
True. Please treat our suggestions of builds only as recommendations. The final decision of which build should be used for the major milestones should come from within OLPC based on the accomplishments planned for that milestone. This is the model we usually follow with most of our other customers/projects as well. Thanks Ronak From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michail Bletsas Sent: Sunday, July 01, 2007 6:11 AM To: Dan Williams Cc: [EMAIL PROTECTED]; Kim Quirk; OLPC Developer's List; [EMAIL PROTECTED] Subject: Re: [Testing] Build 472 - testing No we don't M. Dan Williams [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 06/30/2007 11:37 PM To Kim Quirk [EMAIL PROTECTED] cc [EMAIL PROTECTED], OLPC Developer's List [EMAIL PROTECTED] Subject Re: [Testing] Build 472 - testing On Sat, 2007-06-30 at 08:10 -0400, Kim Quirk wrote: It looks like we may need/want to get the latest Marvell firmware and all known flag day updates into the build on Monday (if possible). At some point we just have to take the hit and ask everyone to upgrade, laptops and servers. As you mention, Dan, we need to do this in Cambridge first... so maybe this should be in Monday's build. I know we have the Marvell firmware (or can get it). Is there anything outstanding that we are still waiting on to have this flag day? We need to get Ronak's sign-off on any firmware that we plan to put in public builds. That can take a few days, though sometimes it's quick. Dan Is there a reason NOT to do this as soon as possible? Thanks, Kim On 6/30/07, Dan Williams [EMAIL PROTECTED] wrote: On Fri, 2007-06-29 at 21:37 -0400, John (J5) Palmieri wrote: On Fri, 2007-06-29 at 11:23 -0400, Kim Quirk wrote: Test Groups, Build 472 is available, but the biggest problem is that it doesn't get on the mesh or infrastructure AP. Some activities are working and there is more to see in the Journal than the previous build. I'm hoping that we can get another build today with the network problem fixed since that would be important for our 'Release Candidate 1'. Today's milestone is to get to RC1 which has most of the basic functionality that was available in 406 builds. If we can get the mesh connecting again, that would be great! Test release notes: http://wiki.laptop.org/go/Test_Group_Release_Notes (Anyone can add notes about this release page -- please do) I couldn't fix the mesh issues with the current NetworkManager so I have backtracked to an earlier working version in build478. This one gets on the mesh and also on AP points. http://olpc.download.redhat.com/olpc/streams/development/build478/ So thinking about it again, we don't expect the new svn2621 NM bits to work with any existing mesh networks because the server software and hardware needs to change. We have to have a flag day in Cambridge too before we can get the new NM automeshing bits, because the new bits aren't compatible with the old bits on the server side. Dan ___ Testing mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/testing ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
