| 00:01.11 | prpplague | ho ho hum |
| 00:02.52 | GPSFan | g1powermac_apl: the only command you really need from busybox-static is switch_root. a stand alone static version would probably work just fine, since there are no libraries in /lib in the zipit normal rootfs. |
| 00:09.05 | *** join/#edev prpplague (n=dave123_@ppp-70-245-135-149.dsl.rcsntx.swbell.net) |
| 00:09.13 | prpplague | grumbles |
| 00:09.23 | *** mode/#edev [+o prpplague] by ChanServ |
| 00:10.00 | prpplague | Mirell heard from landley? |
| 00:22.43 | g1powermac_apl | woohoo, got networking working, well, without wep atm |
| 00:25.11 | *** join/#edev prpplague^2 (n=dave123_@ppp-70-245-135-149.dsl.rcsntx.swbell.net) |
| 00:40.27 | g1powermac_apl | hmm, still not getting anywhere with the wep |
| 00:47.09 | *** join/#edev roxfan2 (n=dunno@184.222-200-80.adsl-dyn.isp.belgacom.be) |
| 01:17.53 | g1powermac_apl | bah, I just disabled wep, like it was really doing anything anyway |
| 01:18.18 | g1powermac_apl | if anyone could get past the mac address filtering and hidden ssid, they could easily get passed the wep |
| 01:19.17 | g1powermac_apl | nice, I can ssh into my zipit now |
| 01:26.30 | SpeedEvil | hidden SSID isn't a barrier. |
| 01:26.45 | SpeedEvil | Nor is MAC filtering - if anyone has a clue. |
| 01:27.05 | g1powermac_apl | neither is wep really |
| 01:27.09 | SpeedEvil | Or the appropriate script/app. |
| 01:27.48 | g1powermac_apl | well, if I could only get the stupid thing to work on wep |
| 01:28.01 | SpeedEvil | g1powermac_apl: have you done the iwconfig thign? |
| 01:28.11 | g1powermac_apl | yup, thats what I'm doing |
| 01:28.24 | g1powermac_apl | I'm currently using iwconfig to set it up without wep |
| 01:28.34 | SpeedEvil | I mean for WEP? |
| 01:28.46 | g1powermac_apl | the second I stick the wep key in the iwconfig line, it doesn't want to work |
| 01:28.58 | g1powermac_apl | keeps saying network is unreachable or connection was refused |
| 01:30.14 | g1powermac_apl | I wonder, do the letters in the 26 digit hex wep key have to be capitalized? |
| 01:30.27 | SpeedEvil | no |
| 01:30.30 | MonMotha | depends on what you're typing them into |
| 01:30.46 | SpeedEvil | use hex keys on both ends - not ascii |
| 01:30.47 | MonMotha | most just run chunks of it through strtol or similar |
| 01:31.01 | MonMotha | but yeah, if you use the "passphrase" option, it has to match exactly |
| 01:31.05 | MonMotha | and even then, there's no real standard |
| 01:31.19 | g1powermac_apl | I'm not using passphrase |
| 01:31.24 | g1powermac_apl | its hex at both ends |
| 01:33.21 | g1powermac_apl | I mean here's my iwconfig line: iwconfig eth0 essid SSID key WEPKEY |
| 01:33.33 | g1powermac_apl | it works fine once I take out the key |
| 01:33.39 | g1powermac_apl | but with the key, it dies |
| 01:33.47 | SpeedEvil | I do each thing on a seperate line |
| 01:33.59 | MonMotha | you may have to specifically put access into a certain mode |
| 01:34.05 | MonMotha | i.e. shared secret, open |
| 01:34.20 | g1powermac_apl | well, if I attempt to do it on separate lines, it dies |
| 01:34.29 | g1powermac_apl | at the first line, ie setting the ssid |
| 01:34.52 | g1powermac_apl | I tried adding 'open' after 'key', did nothing |
| 01:42.34 | g1powermac_apl | well, I'll play with it tomorrow |
| 01:42.58 | g1powermac_apl | bbiab |
| 01:47.27 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 02:10.01 | RobotGuy | WiFi has to be ad-hoc or managed (infrastructure). |
| 02:10.26 | RobotGuy | Oh. He left. |
| 03:41.45 | prpplague | google maps finally updated satellite images for my neighborhood |
| 03:41.52 | prpplague | but still no street address |
| 03:45.04 | SpeedEvil | passes prpplague openstreetmap.org |
| 03:49.43 | prpplague | no map data at all for my area |
| 03:51.23 | SpeedEvil | I thought you were US. I guess that means no tiger data in your area, and nobodies there. |
| 03:51.39 | prpplague | i am in the US |
| 03:52.01 | SpeedEvil | yeah - I mean - so I guess |
| 03:52.13 | SpeedEvil | should be asleep. |
| 03:52.33 | prpplague | SpeedEvil sorry don't understand |
| 03:53.21 | SpeedEvil | I meant something more like. 'As you're in the US, I guess that means that there is no TIGER data for your area, and nobodies updated it on the ground yet.' |
| 03:53.47 | prpplague | ahh and not likely to |
| 03:54.05 | RobotGuy | Wow, I'm still here. |
| 03:54.07 | SpeedEvil | Well - coverage is increasing. |
| 03:54.38 | SpeedEvil | The project did only start a couple of years ago. |
| 03:55.17 | prpplague | funny i've never even heard of it |
| 03:55.29 | prpplague | is it pretty popular in the UK and EU? |
| 03:55.49 | SpeedEvil | http://openstreetmap.org/?lat=51.521&lon=-0.156&zoom=10&layers=B0FT |
| 03:55.51 | SpeedEvil | london |
| 03:56.13 | SpeedEvil | There is substantially more mapping in the UK and EU |
| 03:56.47 | SpeedEvil | That - the london mapping - is all user generated. |
| 03:57.38 | prpplague | looks |
| 03:58.23 | prpplague | hmm |
| 03:58.44 | RobotGuy | That's pretty cool! |
| 03:59.03 | prpplague | doesn't seem that detailed |
| 03:59.22 | prpplague | i zoom in and just get "coming soon more osm" |
| 03:59.43 | RobotGuy | It looks detailed enough for navigation, even though it doesn't have landmarks and such on it. |
| 03:59.47 | SpeedEvil | It should zoom in to one tile being 100m |
| 03:59.52 | SpeedEvil | or so |
| 04:00.10 | SpeedEvil | On the scale that is. |
| 04:00.29 | prpplague | hmm it doesn't seem to be doing that for me |
| 04:00.34 | RobotGuy | I got a good zoom with enough to read the street names. |
| 04:00.50 | prpplague | i just get "more osm coming soon" |
| 04:01.01 | SpeedEvil | Odd. |
| 04:01.17 | RobotGuy | I never saw that message. |
| 04:01.26 | SpeedEvil | Does http://openstreetmap.org/?lat=51.534827&lon=-0.174175&zoom=18&layers=B0FT |
| 04:01.49 | SpeedEvil | show a scale of 20m, and a map including a railway station (red dot) |
| 04:02.14 | RobotGuy | I see that. |
| 04:02.26 | SpeedEvil | There are occasional issues with the server. |
| 04:02.49 | RobotGuy | I seem to be doing well with it. :D |
| 04:03.14 | prpplague | interesting, i see 20m scale, but all i get is "more osm coming soon" |
| 04:04.20 | SpeedEvil | Maybe an openlayers problem. |
| 04:04.42 | prpplague | i'll give it a test at the office tomorrow |
| 04:04.55 | SpeedEvil | http://informationfreeway.org/ is an alternative view of the map |
| 04:05.01 | prpplague | doesn't seem to have barbados listed |
| 04:05.23 | SpeedEvil | The namefinder is broken at the moment. |
| 04:05.36 | SpeedEvil | The 'planet' - the XML dataset - got too large for it. |
| 04:05.39 | SpeedEvil | It's some 50G |
| 04:05.57 | prpplague | interesting application |
| 04:06.11 | prpplague | SpeedEvil one of things i envisioned for barbados was to collect gps data for the island |
| 04:06.24 | prpplague | SpeedEvil current even the barbados gov has no accurate map info |
| 04:06.29 | SpeedEvil | :/ |
| 04:07.13 | prpplague | i figured i'd get a laptop and a good gps receiver |
| 04:07.22 | prpplague | drive all of the island collection road info |
| 04:07.39 | prpplague | and then i'd be able to provide gps devices for tourists |
| 04:07.59 | prpplague | only 40% of the roads in barbados have names or designation |
| 04:08.00 | prpplague | s |
| 04:09.35 | prpplague | SpeedEvil the osm page seems really slow |
| 04:10.28 | SpeedEvil | Barbados has some roads. |
| 04:10.33 | SpeedEvil | http://informationfreeway.org/?lat=13.204271865311984&lon=-59.57787709200705&zoom=11&layers=B000F000F |
| 04:10.54 | SpeedEvil | prpplague: that can be an issue from some places - nobodies tracked down the reason yet. |
| 04:11.00 | *** join/#edev sunrunner20|prom (n=jamesdoe@pool-71-164-133-252.dllstx.fios.verizon.net) |
| 04:11.11 | prpplague | SpeedEvil very interesting, i got nothing |
| 04:12.11 | SpeedEvil | On the above page? |
| 04:12.26 | prpplague | yea |
| 04:12.43 | SpeedEvil | what browser? |
| 04:12.50 | prpplague | nothing but a blue page with a square that says the same, more osm coming |
| 04:12.59 | prpplague | firefox on both windows and linux |
| 04:13.17 | SpeedEvil | ff1.5 here. |
| 04:13.51 | prpplague | interesting |
| 04:13.56 | SpeedEvil | It's being worked on - but nobodies figured out why the server is misbehaving. |
| 04:14.00 | prpplague | i'll try again at the office in the morning |
| 04:14.02 | SpeedEvil | It's intermittent. |
| 04:14.10 | SpeedEvil | goes to sleep. |
| 04:14.12 | SpeedEvil | Night. |
| 04:14.37 | prpplague | SpeedEvil later |
| 04:27.18 | *** join/#edev Appleman1234 (n=Appleman@131.181.47.14) |
| 04:29.28 | *** join/#edev sunrunner20 (n=jamesdoe@pool-71-164-162-182.dllstx.fios.verizon.net) |
| 04:31.55 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 04:52.53 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 05:20.42 | *** join/#edev harpal (n=harpal@121.246.75.165) |
| 05:27.40 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 05:34.13 | *** join/#edev magnetron (n=magnetro@unaffiliated/magnetron) |
| 05:46.41 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 06:05.43 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 06:11.47 | *** join/#edev drath_ (i=vmaster@p5B07DBAB.dip.t-dialin.net) |
| 06:35.20 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 06:35.23 | *** join/#edev DrZimmerman (n=theo@77-56-246-76.dclient.hispeed.ch) |
| 06:55.35 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 07:21.51 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 07:23.58 | *** join/#edev [AD]Turbo (n=turbo@host24-241-dynamic.22-79-r.retail.telecomitalia.it) |
| 07:43.51 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 08:13.36 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 08:14.09 | *** join/#edev hw_ (n=hw@p578b3905.dip0.t-ipconnect.de) |
| 08:21.56 | *** join/#edev lyakh (n=lyakh@p57BD291F.dip0.t-ipconnect.de) |
| 08:32.38 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 08:32.43 | [AD]Turbo | yo |
| 08:51.26 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 09:15.14 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 09:33.29 | *** join/#edev [AD]Turbo (n=turbo@host24-241-dynamic.22-79-r.retail.telecomitalia.it) |
| 09:34.32 | *** join/#edev [AD]Turbo (n=turbo@host24-241-dynamic.22-79-r.retail.telecomitalia.it) |
| 09:35.17 | *** join/#edev kaza_lite (n=danishJa@116.71.161.176) |
| 10:51.22 | *** join/#edev likewise (n=likewise@82-171-51-231.ip.telfort.nl) |
| 10:56.35 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 11:37.02 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 11:44.04 | *** join/#edev GPSFan (n=kenm@12.10.255.246) |
| 11:44.04 | *** mode/#edev [+o GPSFan] by ChanServ |
| 11:55.27 | *** join/#edev g1powermac_apl (i=g1powerm@CPE-76-177-156-202.natcky.res.rr.com) |
| 12:43.19 | *** join/#edev howtoo (n=howtoo@195.159.62.66) |
| 12:58.50 | *** join/#edev chouimat|work (n=dieu@209.217.106.98) |
| 13:03.25 | chouimat|work | morning |
| 13:07.14 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 13:19.56 | mbuf | chouimat|work, morning |
| 13:36.27 | GPSFan | g1powermac_PB: you might ask prpplague about wep support in the marvell gspi driver. |
| 13:46.06 | g1powermac_PB | GPSFan: yea, I was thinking of doing that when prpplague comes back |
| 13:47.41 | g1powermac_PB | bbiab |
| 14:03.59 | GPSFan | g1powermac_PB: if the z2 under the zipit main app supports wep then it should be possible to get it to work uwing wirelesss tools. it's the same .ko driver in each case, it may be a private ioctl, or some such. The libertas driver supports wep. |
| 14:21.24 | *** join/#edev Mr_Bonga (n=Rui_Silv@194.65.138.120) |
| 14:21.42 | *** join/#edev MothaWork (n=monmotha@mail.forwardengineering.com) |
| 14:23.11 | *** join/#edev chouimat|work (n=dieu@209.217.106.98) |
| 14:27.06 | *** join/#edev prpplague (n=dave@mail.americanmicrosystems.com) |
| 14:31.41 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 14:33.39 | prpplague | ho ho hum |
| 14:34.22 | prpplague | did anyone besides me have problems accessing slashdot this morning?\ |
| 14:36.00 | chouimat|work | nope |
| 14:37.51 | prpplague | must have been a texas thing |
| 14:37.55 | solar | works for me when I don't spell it slashdog |
| 14:38.31 | chouimat|work | prpplague: http://www.theregister.co.uk/2008/04/29/wikipedia_blocked_doj_ip/ |
| 14:39.21 | prpplague | solar: hehe |
| 14:39.38 | prpplague | it was only for about an hour early this morning |
| 14:43.53 | prpplague | anyone tried the enc28j60 driver in 2.6.25 yet? |
| 14:51.55 | likewise | anyone know a part (preferably with Linux driver) that does battery/power management, voltage supervisor, touchscreen controller, but no audio and thus cheaper? |
| 14:53.22 | prpplague | likewise: there are a number of TI parts, as well as NXP |
| 14:53.32 | prpplague | likewise: most will have min qty orders though |
| 14:58.59 | *** join/#edev CosmicPenguin (n=nobody@163.181.251.103) |
| 14:58.59 | *** mode/#edev [+o CosmicPenguin] by ChanServ |
| 15:02.14 | prpplague | CosmicPenguin: greetings crack daddy |
| 15:06.25 | *** join/#edev g1powermac (n=g1powerm@unaffiliated/g1powermac) |
| 15:14.52 | g1powermac | heya prpplague |
| 15:14.56 | g1powermac | got a question for ya |
| 15:15.43 | prpplague | shoot |
| 15:15.49 | g1powermac | how is the wep support for the 88W8686? I can't seem to get iwconfig to setup my zipit to use to wep |
| 15:16.12 | g1powermac | is there some other way to tell the 88W8686 to use my wep key outside of iwconfig? |
| 15:16.52 | prpplague | g1powermac: we have no problems using iwconfig with the 88W8385 (which is identical code wise) |
| 15:17.03 | g1powermac | hmm |
| 15:17.12 | prpplague | g1powermac: what kind of problem are you seeing? |
| 15:17.22 | g1powermac | its the strangest thing, the second I enable wep on my router I get the following issue |
| 15:17.33 | *** join/#edev sunrunner20 (n=jamesdoe@pool-71-164-162-182.dllstx.fios.verizon.net) |
| 15:18.08 | g1powermac | if I first set the ssid for eth0, it tells me something about either the network is unreachable or the connection is refused |
| 15:18.15 | g1powermac | even before setting the wep key |
| 15:18.50 | prpplague | g1powermac: yea, that makes sense |
| 15:19.05 | g1powermac | ok, so what should I try to do? |
| 15:19.14 | g1powermac | I've tried setting the wep key first, but that didn't work either |
| 15:19.16 | prpplague | g1powermac: the marvell reference driver fails if the network can't be connected when the initial ssid is set |
| 15:19.33 | g1powermac | ahh |
| 15:19.57 | prpplague | g1powermac: are you bringing up the wlan first? i.e. iwconfig eth0 up |
| 15:20.15 | prpplague | g1powermac: the marevell reference driver is very bad |
| 15:20.21 | g1powermac | hmm, I did ifconfig eth0 up. . . |
| 15:20.36 | g1powermac | and have done it before and after the wep key |
| 15:21.16 | prpplague | hmm |
| 15:21.47 | g1powermac | but I'll try iwconfig eth0 up this time |
| 15:21.52 | g1powermac | maybe thats what it needs |
| 15:22.05 | prpplague | g1powermac: should be able to do an ifconfig eth0 up, iwconfig eth0 {wep key} , iwconfig eth0 {ssid} |
| 15:22.28 | g1powermac | ok, I'll try that pattern |
| 15:22.30 | prpplague | g1powermac: thats suppose to be ifconfig |
| 15:22.35 | prpplague | g1powermac: i did a typo |
| 15:22.38 | g1powermac | k |
| 15:23.03 | g1powermac | don't think I've tried it in that order |
| 15:23.27 | g1powermac | the only test I've done with the wep key first was with ifconfig done at the end |
| 15:27.55 | g1powermac | oh, that reminds me, were you able to look into the status of the 88W8686 spi driver? |
| 15:30.50 | prpplague | was i suppose to? |
| 15:38.47 | g1powermac | was just wondering :-) |
| 15:40.15 | prpplague | i haven't been looking too closely at it |
| 15:43.06 | g1powermac | k |
| 15:52.35 | g1powermac | woot, got my magnifying lens visor thingie with lights, its so incredibly cheap looking, but so useful at the same time ;-) |
| 16:11.35 | *** join/#edev bbradley (n=bbradley@92-235-133-146.cable.ubr17.azte.blueyonder.co.uk) |
| 16:23.47 | *** join/#edev Mr_Bonga (n=Rui_Silv@194.65.138.120) |
| 16:38.35 | prpplague | solar: http://news.slashdot.org/news/08/04/30/1455205.shtml |
| 16:40.04 | *** join/#edev g1powermac_ (n=g1powerm@rrcs-64-183-163-253.west.biz.rr.com) |
| 16:44.42 | g1powermac_ | prpplague, just tried it this time on my router here, reconfigured it for simple 40bit wep, and it still isn't working |
| 16:45.53 | g1powermac_ | this is the exact error: Error for wireless request "Set ESSID" (8B1A) : SET failed on device eth0; connection refused |
| 16:46.35 | g1powermac_ | and thats doing the ifconfig first, key second, and the ssid third |
| 16:50.04 | g1powermac_ | brb, resetting the network to use wpa. . . |
| 16:52.56 | *** join/#edev g1powermac___ (n=g1powerm@rrcs-64-183-163-253.west.biz.rr.com) |
| 16:53.40 | g1powermac | prpplague, so not sure whats going on. . . |
| 17:09.06 | *** join/#edev Redhatte1 (n=vk4fsjl@203.94.56.252) |
| 17:28.09 | *** join/#edev RobotGuy (n=robotguy@dsl093-038-072.pdx1.dsl.speakeasy.net) |
| 17:30.04 | g1powermac | GPSFan, what is the number of the chip that is next to the 88W8686? |
| 17:35.37 | RobotGuy | Greetings |
| 17:35.48 | g1powermac | heya RobotGuy |
| 17:36.39 | g1powermac | still hasn't gotten anywhere with wep on the zipit |
| 17:36.55 | RobotGuy | g1powermac: What is the problem? |
| 17:37.30 | g1powermac | it just doesn't want to set the wep key, and then when it goes to set the ssid, it dies |
| 17:37.46 | g1powermac | this is the exact error: Error for wireless request "Set ESSID" (8B1A) : SET failed on device eth0; connection refused |
| 17:38.06 | RobotGuy | g1powermac: Give me a minute or so and I will post what works for me on the Wiki. |
| 17:38.12 | prpplague | g1powermac: sure you got the right essid? |
| 17:38.20 | prpplague | g1powermac: do a iwlist eth0 scan |
| 17:38.21 | g1powermac | I'm wondering if there's other ways to set the wep key |
| 17:38.25 | prpplague | g1powermac: just to see whats there |
| 17:38.38 | g1powermac | prpplague, yup, since it works when I disable wep on the router |
| 17:39.18 | g1powermac | can't do that right now, everything here is switched back to wpa, but will try when i get back home |
| 17:41.34 | g1powermac | the zipit software definitely does something funky with the wifi chip to initialize it, since the MAC address for it is set in the the zipit software |
| 17:41.52 | g1powermac | ifconfig shows a different MAC address than the one thats written on the bottom of the zipit |
| 17:42.26 | prpplague | anyone gotten their tax rebate yet? |
| 17:42.37 | g1powermac | not me |
| 17:43.04 | g1powermac | though our rebates are going right back to the gov't to pay for taxes for the store :( |
| 17:44.15 | RobotGuy | g1powermac: OK, the info is added on the WiFi link. |
| 17:44.29 | g1powermac | prpplague, is there more of a direct way to set MAC address and wep for the marvell chip? |
| 17:44.51 | prpplague | g1powermac: there is a app tool that is available with the driver |
| 17:45.02 | prpplague | g1powermac: i don't know if it is included with the zipit rootfs |
| 17:45.03 | RobotGuy | prpplague: Package? |
| 17:45.05 | g1powermac | RobotGuy, which wiki? |
| 17:45.11 | prpplague | RobotGuy: what? |
| 17:45.13 | RobotGuy | g1powermac: Hammer Wiki |
| 17:45.24 | g1powermac | link? |
| 17:45.41 | RobotGuy | www.elinux.org/Hammer_Board |
| 17:46.04 | RobotGuy | prpplague: Have you checked with shipping? |
| 17:46.17 | g1powermac | RobotGuy, interesting |
| 17:46.24 | prpplague | RobotGuy: no but i will in about 20 minutes, they are at lunch |
| 17:46.33 | RobotGuy | prpplague: OK, thanks. |
| 17:46.51 | g1powermac | prpplague, hmm, don't think they included it |
| 17:46.59 | RobotGuy | g1powermac: I have found that I have to do things in a certain order to have it all work. |
| 17:47.38 | g1powermac | prpplague, can't access the wifi chip at all in /proc or /dev? |
| 17:48.05 | prpplague | g1powermac: it all depends on what was configured during the compile |
| 17:48.29 | g1powermac | RobotGuy, you see, the interesting thing is if I get rid of wep and just go basic wifi, iwconfig works fine |
| 17:49.00 | RobotGuy | g1powermac: All I can say is try things in the order I have them and see if it works. |
| 17:49.11 | g1powermac | prpplague, hmm, anyway I can determine that? |
| 17:49.29 | prpplague | not really |
| 17:49.42 | prpplague | g1powermac: its pretty limiting |
| 17:49.51 | g1powermac | RobotGuy, I've done a very similar approach, just with less stuff set |
| 17:49.54 | RobotGuy | g1powermac: You have to have the correct modules configured in your kernel for you wifi chip. |
| 17:50.13 | RobotGuy | g1powermac: Very similar is not exact. |
| 17:50.26 | g1powermac | has done: ifconfig eth0 up, iwconfig essid SSID, iwconfig key WEPKEY |
| 17:50.36 | g1powermac | I've also swapped those steps around |
| 17:51.00 | RobotGuy | g1powermac: I tried many different orderings and such before I got a setup that works. |
| 17:51.28 | g1powermac | RobotGuy, of course, but we're using the modules that came with the zipit |
| 17:52.55 | RobotGuy | I'm going to try installing PCLinuxOS MiniMe on a thumb drive today. |
| 17:53.04 | g1powermac | RobotGuy, the only thing with your setup is that it'll die at setting the ssid |
| 17:53.40 | g1powermac | it doesn't go past setting the ssid, unless that one line before it does something to stop it |
| 17:53.47 | RobotGuy | g1powermac: You must have something else wrong then or the wrong version of wireless-tools. You need v29 or later. |
| 17:54.02 | g1powermac | got v29 |
| 17:54.26 | RobotGuy | I've helped all I can then. I don't know anything about the ZipIt. |
| 17:54.27 | g1powermac | wonder if I should try the beta version |
| 17:56.02 | g1powermac | you know, this is interesting |
| 17:56.14 | g1powermac | I'm reading the start script for the zipit |
| 17:56.45 | g1powermac | and no matter if you setup wep or wpa, they always startup wpa_supplicant |
| 17:57.57 | g1powermac | hmm |
| 17:58.13 | g1powermac | wpa_supplicant can do wep. . . |
| 17:58.18 | g1powermac | did not know this. . . |
| 18:02.26 | RobotGuy | I do not start up supplicant |
| 18:02.48 | g1powermac | RobotGuy, yea, but this is a patched supplicant to run on the zipit. . . |
| 18:02.54 | RobotGuy | thinks that sounds an awful lot like replicant |
| 18:04.59 | g1powermac | ok, going to have to try this. . .bbiab |
| 18:06.24 | RobotGuy | Wow, that www.pendrivelinux.com site is very cool! |
| 18:14.58 | GPSFan | g1powermac_PB: if the z2 under the zipit main app supports wep then it should be possible to get it to work uwing wirelesss tools. it's the same .ko driver in each case, it may be a private ioctl, or some such. The libertas driver supports wep. |
| 18:15.04 | GPSFan | g1powermac: http://www.paonia.com/~kenm/Pix/images/Zipit/Z2/AGF00010.JPG |
| 18:15.19 | GPSFan | g1powermac: sorry, been busy, cul.. |
| 18:19.07 | *** join/#edev g1powermac_ (n=g1powerm@rrcs-64-183-163-253.west.biz.rr.com) |
| 18:24.50 | *** join/#edev g1powermac___ (n=g1powerm@rrcs-64-183-163-253.west.biz.rr.com) |
| 18:25.06 | g1powermac___ | hmm, no real luck with that either |
| 18:33.20 | prpplague | CosmicPenguin: ping |
| 18:43.11 | GPSFan | g1powermac: the two chips in the lower left are probably a T/R switch and a power amp. the one on the right is a Marvell part, prpplague might know what it is. |
| 18:44.14 | prpplague | GPSFan: which picture? |
| 18:44.54 | *** join/#edev ico2 (n=ico2@modem-2564.cheetah.dialup.pol.co.uk) |
| 18:45.04 | GPSFan | g1powermac: http://www.paonia.com/~kenm/Pix/images/Zipit/Z2/AGF00010.JPG |
| 18:45.28 | GPSFan | MRVL W886 |
| 18:45.41 | prpplague | hmm don't recognize that one, all of our 8686 designs are single chip |
| 18:45.56 | prpplague | its possible a rf transceiver |
| 18:46.27 | prpplague | hmm, no too small |
| 18:47.33 | GPSFan | hard to say. I haven't seen any marvell chipset designs before, The T/R switch and power amp are usually in those form factor packages. |
| 18:53.59 | g1powermac | GPSFan, excellent, thanks |
| 18:59.16 | g1powermac | I'm replacing your old shot with this one |
| 18:59.23 | g1powermac | on the site |
| 19:00.35 | g1powermac | ok, for this wireless issue, I really need to be able to connect to the zipit over usb so I can more easily debug the wep problem |
| 19:00.49 | g1powermac | I think I'll try my hand at making a cable today |
| 19:07.31 | *** join/#edev Crofton (n=balister@66-207-66-26.black.dmt.ntelos.net) |
| 19:08.37 | RobotGuy | Sheesh, even with just a minimal dev build, having a native toolchain still makes the image 87 MB. |
| 19:09.20 | RobotGuy | Well, OK, got Python and SQLite on there also. |
| 19:09.51 | GPSFan | g1powermac: you will have to compile the appropriate usb drivers as well. usb gaget, maybe mass storage, etc.. |
| 19:10.15 | g1powermac | GPSFan, figured that |
| 19:10.24 | RobotGuy | If there is any usb storage, usb-storage will be required, as well as scsi support. |
| 19:11.01 | g1powermac | wants to do tcp/ip over usb so I could just ssh into my zipit |
| 19:11.02 | RobotGuy | scsi-disk for sure and maybe scsi-generic |
| 19:11.10 | GPSFan | g1powermac: yeah, that picture is better for showing just the wifi part, on the other I wanted some of the CPU to show as well. |
| 19:11.13 | RobotGuy | g1powermac: Gadget Ethernet |
| 19:11.37 | g1powermac | alrighty |
| 19:11.46 | g1powermac | now what about on the linux pc side? |
| 19:12.04 | RobotGuy | g1powermac: I haven't mastered the PC side of a Gadget Ethernet link yet. |
| 19:12.11 | g1powermac | k |
| 19:12.59 | RobotGuy | I haven't managed to build a new working kernel for my Kubuntu linux yet. I have not figured out how to create an initrd for it. |
| 19:13.55 | g1powermac | hmm, forgot how to do it myself |
| 19:14.04 | g1powermac | I usually don't do initrd |
| 19:14.30 | g1powermac | I just make sure ext3 or whatever the rootfs is, is compiled into the kernel |
| 19:14.43 | prpplague | RobotGuy: you seen the sodimm cpu card thats on the M5900? |
| 19:15.28 | RobotGuy | prpplague: I have not seen that. I might like it. |
| 19:15.40 | prpplague | RobotGuy: well i had a question |
| 19:15.49 | RobotGuy | prpplague: I might have an answer. |
| 19:15.55 | prpplague | RobotGuy: http://www.elinux.org/M5900 |
| 19:16.05 | prpplague | RobotGuy: first look at the 7210 sodimm |
| 19:16.18 | GPSFan | g1powermac: when you get your usb cable wired up be sure to post a close-up picture of the wireing so others (me) may duplicate it. ;>) |
| 19:16.35 | g1powermac | hehe, sure |
| 19:16.43 | RobotGuy | prpplague: I think you linked the wrong thing |
| 19:17.02 | g1powermac | technically once I get my board xrayed, we won't have to worry about that stuff any more |
| 19:17.08 | prpplague | looks |
| 19:17.15 | prpplague | no thats the right item |
| 19:17.40 | prpplague | RobotGuy: looks at the 7210 sodimm |
| 19:18.02 | RobotGuy | prpplague: Oooooooooooooooooooooooo, nice, and small. |
| 19:18.36 | RobotGuy | prpplague: Something like that would make an interesting addition with a small carrier board. |
| 19:18.37 | prpplague | RobotGuy: if you had a sodimm socket that it would snap into and have something like 60 .1" pins |
| 19:19.01 | prpplague | RobotGuy: think that would be interesting? |
| 19:19.37 | RobotGuy | prpplague: Yes, I think it would be very interesting.. Hmmmm, small backplane and add-on modules.. Hmmmmm, possibilities. |
| 19:20.15 | RobotGuy | thinks |
| 19:20.25 | RobotGuy | Many ideas. |
| 19:20.51 | g1powermac | prpplague, those are pretty cool |
| 19:20.51 | RobotGuy | prpplague: What are the dimmensions of that sodimm module? |
| 19:21.21 | prpplague | 1.5x2.7 |
| 19:21.51 | RobotGuy | prpplague: Ooooooooooooh, nice size. I think I could fit that onto an RSR. :) |
| 19:22.01 | prpplague | rsr? |
| 19:22.18 | RobotGuy | prpplague: In fact I know I could. A small horizontal backplane. Really Small Robot. |
| 19:22.45 | prpplague | well you still have to account for the sodimm socket |
| 19:22.46 | RobotGuy | prpplague: Something to build a small swarm from, using ZigBee for communications. |
| 19:23.03 | CosmicPenguin | prpplague: poing |
| 19:23.26 | prpplague | CosmicPenguin: hey personal question, you have health insurance for you and your wife thru amd? |
| 19:23.35 | RobotGuy | prpplague: The SoDimm fits nicely within the dimmensions I have defined for my RSRs. Mounting it horizontally with a small backplane for add-ons. |
| 19:23.45 | CosmicPenguin | prpplague: yep |
| 19:23.50 | RobotGuy | CosmicPenguin: piong. :) |
| 19:24.01 | prpplague | CosmicPenguin: mind if i ask how much a month it costs? |
| 19:24.07 | CosmicPenguin | ummm... great question |
| 19:24.24 | CosmicPenguin | lets find out |
| 19:24.55 | RobotGuy | prpplague: Consider this - that SoDimm module mounted in the same orientation, but with say a 3 module backplane kind of setup to allow other like form factor modules to be added to it. |
| 19:25.31 | prpplague | RobotGuy: i am sorry, i'm not able to picture your description |
| 19:25.42 | CosmicPenguin | prpplague: looks like $202 for health and dental for two adults and a baby |
| 19:25.48 | RobotGuy | prpplague: A horizontal stack of SoDimms. |
| 19:25.58 | prpplague | CosmicPenguin: wow, thats pretty darn good |
| 19:26.59 | RobotGuy | prpplague: I am allowing a 2.75" x 2.75" compartment for electronics on an RSR. |
| 19:27.53 | prpplague | ok |
| 19:28.34 | RobotGuy | I'd like to make it even smaller but most off the shelf components I want to use are a minimum of around 2.7" per dimension. |
| 19:29.31 | RobotGuy | I can see other possibilities for a module like that SoDimm also though. |
| 19:30.24 | prpplague | anyone want about 2000 sa-1110 sodim boards that failed QA tests? |
| 19:30.27 | prpplague | hehe |
| 19:32.51 | prpplague | doesn't feel good today |
| 19:34.41 | solar | wonders if prpplague ever shoved that nail into the mail |
| 19:35.14 | prpplague | solar: we are running behind on production, there was a problem with the pick-n-place data |
| 19:35.32 | prpplague | solar: probably going to be monday or tuesday |
| 19:36.10 | prpplague | solar: if you are in a hurry, i can see about getting one of the beta units |
| 19:40.36 | prpplague | departs so that he may acquire his offspring from the knowledge dispersment center |
| 19:42.05 | solar | prpplague: not really. |
| 19:42.34 | RobotGuy | wmat: ping |
| 19:42.56 | solar | prpplague: I've managed to break my development environment for the arm-softfloat-linux-uclibc CHOST in some odd and unusual way and wont be able to look at it any sooner than this weekend |
| 19:43.21 | solar | but our last firmware + kernels work like a charm |
| 19:44.01 | RobotGuy | solar: He went to the reprogramming center to reaquire his offspring. |
| 19:45.55 | g1powermac | bbiab |
| 19:47.58 | RobotGuy | I'm going off to tinker with Linux and thumb drives. |
| 19:48.04 | RobotGuy | BBL |
| 20:09.58 | *** join/#edev sunrunner20 (n=jamesdoe@pool-71-164-162-182.dllstx.fios.verizon.net) |
| 20:12.24 | *** join/#edev ico2_ (n=ico2@modem-3978.cougar.dialup.pol.co.uk) |
| 20:19.05 | *** join/#edev agaffney_ (n=agaffney@gentoo/developer/pdpc.active.agaffney) |
| 20:28.18 | *** join/#edev g1powermac_apl (i=g1powerm@CPE-76-177-156-202.natcky.res.rr.com) |
| 20:28.44 | g1powermac_apl | returns |
| 20:29.00 | g1powermac_apl | GPSFan, so what other patches have you done to your zipit kernel? |
| 20:29.03 | chouimat|work | see last column: http://en.wikipedia.org/w/index.php?title=Comparison_of_file_systems&oldid=209063556#Features |
| 20:29.07 | chouimat|work | g1powermac_apl: ^^^^ |
| 20:29.56 | g1powermac_apl | chouimat|work, umm |
| 20:30.34 | GPSFan | g1powermac_apl: I haven' done any patches. ethicalclone came up with the keyboard driver. I compiled the fb driver with console rotation enabled. no patches though. |
| 20:30.35 | g1powermac_apl | interesting info, but don't see the relevance |
| 20:30.35 | chouimat|work | g1powermac_apl: someone has a bad sense of humour |
| 20:30.52 | g1powermac_apl | GPSFan, ahhh |
| 20:31.49 | g1powermac_apl | chouimat|work, hahahah, had to do a horizontal scroll to see the last column |
| 20:32.38 | g1powermac_apl | GPSFan, sounds good, gonna try to enable the usb gadget stuff |
| 20:33.30 | GPSFan | g1powermac_apl: good deal, I've no time for much of anything today, so "best of luck". |
| 20:33.40 | g1powermac_apl | alrighty |
| 20:43.47 | prpplague | http://blog.makezine.com/archive/2008/04/shapeshifting_robots.html |
| 20:43.52 | prpplague | wow thats pretty interesting |
| 20:44.22 | roxfan2 | transformers! |
| 20:45.02 | chouimat|work | prpplague: [16:29] <chouimat|work> see last column: http://en.wikipedia.org/w/index.php?title=Comparison_of_file_systems&oldid=209063556#Features |
| 20:45.05 | prpplague | roxfan2: more like "Iron Giant" reassembly |
| 20:45.18 | roxfan2 | didn't watch that one |
| 20:45.57 | prpplague | hehe |
| 20:46.05 | prpplague | chouimat|work: funny funny |
| 20:47.58 | prpplague | thats too funny and a little macabre |
| 20:54.32 | g1powermac_apl | ls |
| 20:54.35 | g1powermac_apl | oops |
| 21:13.48 | g1powermac_apl | interesting, all modules in respect to usb gadget and ethernet loaded just fine on the zipit |
| 21:13.53 | g1powermac_apl | now i need to make a cable |
| 21:18.44 | g1powermac_apl | interesting messages in the dmesg |
| 21:19.17 | *** join/#edev Redhatter (n=vk4fsjl@2001:388:f000:0:0:0:0:279) |
| 21:19.37 | g1powermac_apl | http://www.pastebin.ca/1003310 |
| 21:19.53 | g1powermac_apl | the bit at the end is the most interesting |
| 21:20.00 | g1powermac_apl | about power levels |
| 21:21.49 | prpplague | g1powermac_apl: is that the zipit side or host pc side? |
| 21:22.09 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 21:22.52 | prpplague | uh wait, why are you running the dummy hci? |
| 21:23.23 | *** join/#edev RobotGuy (n=robotguy@dsl093-038-072.pdx1.dsl.speakeasy.net) |
| 21:23.33 | g1powermac_apl | prpplague, zipit side |
| 21:23.45 | ds2 | wow 92mA limit... wonder who makes a current limiter accurate to 8mA ;) |
| 21:23.47 | prpplague | g1powermac_apl: looks like you have something misconfigured |
| 21:23.56 | g1powermac_apl | hmm |
| 21:24.23 | prpplague | ds2: limit is 8mA |
| 21:24.48 | ds2 | still, that is quite some granularity |
| 21:24.55 | prpplague | yea |
| 21:25.12 | g1powermac_apl | prpplague, in the config for the kernel, the dummy hcd is the only option i have to choose |
| 21:25.14 | prpplague | ds2: its really has nothing to do with accuracy |
| 21:25.23 | prpplague | ds2: its just what the device is reporting |
| 21:25.24 | RobotGuy | returns |
| 21:25.28 | ds2 | *nod* |
| 21:25.37 | ds2 | just seems stupid to do it like that |
| 21:25.47 | RobotGuy | I'm not going to be able to test a bootable USB Thumb Drive |
| 21:25.49 | prpplague | g1powermac_apl: that means you don't have something enable to give you the usb host/device |
| 21:25.58 | g1powermac_apl | hmm |
| 21:25.59 | ds2 | it is like having a speed limit of 56.522222mph on a freeway |
| 21:26.04 | prpplague | ds2: why? |
| 21:26.13 | g1powermac_apl | prpplague, question is. . .what |
| 21:26.21 | prpplague | ds2: thats the whole purpose of reporting the current |
| 21:26.43 | ds2 | if it can't do it that level of accuracy, round up |
| 21:26.48 | prpplague | g1powermac_apl: i'd check the kconfig to see what options you need |
| 21:27.08 | prpplague | ds2: sorry i'm not following you |
| 21:27.30 | ds2 | prpplague: I just think those numbers should reflect the level of accuracy of the system |
| 21:27.58 | prpplague | ds2: those numbers are meant as a value to add up |
| 21:28.11 | prpplague | ds2: not the accuracy of current limiter |
| 21:28.25 | ds2 | i know that |
| 21:28.41 | prpplague | i guess i'm not understanding then |
| 21:28.52 | ds2 | put it another way, I like things to use significant digits (like in science) |
| 21:29.23 | prpplague | ds2: what aspect of that value is not correct then? |
| 21:29.26 | ds2 | or metrology where you only report things to what your instrument is graduated to |
| 21:29.48 | ds2 | so if the instrument graduated in 10mA's, reports should be in multiples of 10mA |
| 21:30.01 | ds2 | making more sense? |
| 21:30.06 | RobotGuy | It's about significant figures in a value reflecting the accuracy of the measuring instrument. |
| 21:30.29 | prpplague | ds2: the measurements for the usb current are on 1mA granularity |
| 21:30.53 | prpplague | ds2: 0 to 500mA |
| 21:31.14 | ds2 | that would imply (using the same metrology rules) that the system needs to be able to shut of things if it exceeds it by merely 1mA |
| 21:31.36 | RobotGuy | I don't think significant figures of a value apply in this case though. |
| 21:31.53 | prpplague | ds2: that value is not intended to be used as part of the current limiting capabilities |
| 21:32.21 | prpplague | ds2: that value is strictly software information |
| 21:32.31 | RobotGuy | ds2: Applying significant figures to measurement values in this case does not work. |
| 21:32.46 | prpplague | ds2: current limiting is fixed at either 100mA or 500mA depending on the device |
| 21:33.23 | RobotGuy | ds2: It's only applicable in cases of decimal values like 1.05 A or 5.50 volts. |
| 21:40.39 | prpplague | ds2: as an example, if a hub has a total of 400mA available for 4 ports, it can "budget" out the 400mA |
| 21:40.46 | ds2 | yeah, I see your point.. I just don't agree with it from a pure metrology standpoint |
| 21:41.06 | prpplague | ds2: if you plug in a 10mA device in one port, and then a 300mA in another port, you are still under budget |
| 21:41.20 | prpplague | ds2: but if you plug in another 100mA device , it will report that it is over budget |
| 21:41.44 | ds2 | right, and my complain is if a device asks for 11mA and another device asks for 390mA... is that really an over current condition? |
| 21:41.48 | ds2 | my argument is no. |
| 21:41.52 | prpplague | ds2: if the device reports 90mA but at some point draws 100mA, the 400mA current limit will kick in |
| 21:42.24 | prpplague | ds2: correct, it is not an over current condition, it is an over current budget condition |
| 21:42.52 | ds2 | prpplague: yes, and that's what I don't agree with. it should have a tolorence that reflects reality |
| 21:43.17 | prpplague | ds2: the device isn't suppose to turn on untill the host approves the 11mA |
| 21:43.24 | prpplague | ds2: or of the 390mA |
| 21:44.53 | prpplague | ds2: the usb spec says that a device is suppose to pull less than 1mA iirc when doing initial enumeration |
| 21:46.19 | prpplague | ds2: the tolerance is for the overall budget, not for the individual device |
| 21:46.41 | ds2 | that's where I think it is wrong |
| 21:46.56 | ds2 | but then there are so many violations of the specs going on, it doesn't matter |
| 21:47.05 | prpplague | ds2: why is that? |
| 21:47.44 | ds2 | prpplague: the sig. figure/tolerance should be carried through the entire calculation, IMO |
| 21:48.27 | prpplague | ds2: so you argument is that if a device asks for 8mA it should be limited it 8mA |
| 21:49.31 | prpplague | ds2: is that correct? |
| 21:49.38 | ds2 | prpplague: not quite - if it asks for 8mA and the host just uses 8 as a calculating value - it better be prepared to limit things at single mA boundries |
| 21:50.05 | ds2 | if not, it should treat 8mA requests the same as if it was a 10mA (and be able to limit on 10mA or finer boundaries) |
| 21:50.20 | *** join/#edev nhoman (n=homann@79.97.106.107) |
| 21:50.27 | ds2 | honoring and using 8mA means, IMO, having ability to go down to 1mA resolution |
| 21:50.30 | prpplague | ds2: ok, let me see if have this clear |
| 21:51.27 | prpplague | ds2: if a device asks for 8mA you want to be able to limit the current to the accuracy of the requested amount |
| 21:52.15 | ds2 | yep |
| 21:52.53 | prpplague | ds2: ok which boils down to the question of: what is the purpose of the over current detection? |
| 21:53.31 | ds2 | at the crudest level - fire prevention! |
| 21:53.57 | prpplague | ds2: to prevent a device from exceding the maximum current that is available to it |
| 21:53.58 | SpeedEvil | reducing demand on the battery |
| 21:54.07 | prpplague | SpeedEvil: no |
| 21:54.25 | prpplague | SpeedEvil: thats the control of the software, not the over current detection |
| 21:54.53 | SpeedEvil | reducing maximum power required on the power system as a whole then. |
| 21:54.55 | prpplague | ds2: if a device is designed to only be able to support 100mA, the current draw should not exceed that |
| 21:55.08 | ds2 | okay, and the converse of that is to make sure all connected device that has been allowed to run can run. |
| 21:55.11 | SpeedEvil | should read backscroll. |
| 21:55.41 | prpplague | ds2: correct, its a two fold piece |
| 21:55.51 | ds2 | so far we are in agreement |
| 21:55.58 | prpplague | ds2: the over current protection is to make sure the overall max has not been excedded |
| 21:56.32 | ds2 | right |
| 21:56.49 | RobotGuy | prpplague: Did you check? |
| 21:56.53 | prpplague | ds2: the purpose of the "annoucement" of how much current is required has two purposes itself, one being to help calculate the over all current budget, the other being to make sure the current doesn't exced the max available |
| 21:57.10 | ds2 | we are still in agreement |
| 21:57.24 | prpplague | RobotGuy: yea, its going out today, they had a large shipment that had to go out, plus there were some additional things included |
| 21:57.52 | RobotGuy | prpplague: Additional things for me? OK. |
| 21:58.03 | prpplague | ds2: but your assertion is that over current detection should be done on the individual request not for the overal budget |
| 21:58.20 | RobotGuy | Probably USB thumb drives for me to check out. |
| 21:58.31 | ds2 | yes, and that doesn't violate anything you've said |
| 21:58.52 | prpplague | ds2: that may be true, but thats not how the USB spec is written |
| 21:59.02 | prpplague | or atleast how its implemented |
| 21:59.07 | ds2 | if you cannot detect overcurrent accurate to the nearly 1mA, you shouldn't act as if you are capable |
| 21:59.39 | prpplague | ds2: but see it doesn't have to be 1mA accurate |
| 21:59.42 | g1powermac_apl | prpplague, its kinda odd, i had to change the arch type to get more options |
| 21:59.58 | prpplague | ds2: it only needs to be for most cases accurate for measuring 100mA or 500mA |
| 22:00.09 | g1powermac_apl | prpplague, had to switch from the pxa arch to the IXP4xx |
| 22:00.38 | ds2 | if it is not really accurate to 1mA, then a total of 101mA vs 100mA is not distinguishable |
| 22:00.48 | prpplague | ds2: that is correct |
| 22:00.57 | ds2 | it may be a safe error to reject something because of that but that does not make it correct |
| 22:01.05 | prpplague | ds2: most boards you can overcurrent to around 110mA before it turns off the port |
| 22:01.12 | g1powermac_apl | prpplague, though supposedly the ixp4xx is also intel xscale |
| 22:01.59 | prpplague | ds2: and on most boards you can overcurrent to around 525mA before the current protection kicks in |
| 22:02.17 | MothaWork | you only really need to enforce current limits electrically if you have a reason to |
| 22:02.23 | ds2 | heh... on PCs, you can often pull up to 2A before any real limit kicks in |
| 22:02.27 | prpplague | MonMotha: exactly |
| 22:02.48 | MothaWork | however, if you enforce them in software (by denying a setting change to a higher current), you SHOULD (RFC sense) enforce them in hardware, since many devices lie |
| 22:03.13 | prpplague | MonMotha: right |
| 22:03.35 | MothaWork | and presumably, if you approved a certain current limit but could not approve a higher current limit, there are hardware limitations that you are enforcing with software |
| 22:03.38 | prpplague | MothaWork: exactly |
| 22:03.52 | g1powermac_apl | prpplague, any idea? |
| 22:04.15 | MothaWork | the idea is that the device can decide gracefully what modes of operation are permissible, but the host should have the ability (and always has the authority) to enforce a power budget. That's only really necessary if there's actually a power budget to begin with |
| 22:04.16 | prpplague | MonMotha: for instance if your max current is 100mA and you approve 50mA, but it actually draws 125mA it should shut the port down |
| 22:04.23 | RobotGuy | I'm going to switch to Windows where I can tinker with my Renesas Starter Kits and Microchip PICs/dsPICs. I don't have any way to tinker with my ARM stuff right now. |
| 22:04.32 | prpplague | g1powermac_apl: sorry idea about what? hehe |
| 22:05.01 | g1powermac_apl | prpplague, its kinda odd, i had to change the arch type to get more options |
| 22:05.07 | g1powermac_apl | prpplague, had to switch from the pxa arch to the IXP4xx |
| 22:05.18 | g1powermac_apl | prpplague, though supposedly the ixp4xx is also intel xscale |
| 22:05.21 | prpplague | g1powermac_apl: that probably means something in your pxa270 config isn't correct |
| 22:05.23 | MothaWork | correct. but if you ask for 50mA and draw 45, that's fine, of course. And I would argue that on a system where power is not critical (all interconnects are overspecified, and power itself is not a scarce resource), that omitting per-port configurable OC limits in hardware is acceptable. |
| 22:05.38 | g1powermac_apl | prpplague, sigh. . . |
| 22:05.39 | MothaWork | however, in that case, your software is also likely to approve any power request up to the 500mA max |
| 22:06.23 | g1powermac_apl | prpplague, here's what the USB_GADGET_PXA2XX wants: depends on (ARCH_PXA && PXA25x) || ARCH_IXP4XX |
| 22:06.28 | prpplague | MonMotha: right but the question is if you have something that asks for 50mA, should you be limiting it to 50mA |
| 22:06.32 | MothaWork | if your software has a reason to go denying power requests to USB devices, it needs to be prepared to back that up with hardware, simply because devices lie, and presumably the reason is good enough that damage or improper/undesirable operation may result form a device pulling more than was authorized |
| 22:06.44 | g1powermac_apl | prpplague, obviously if I select the pxa arch, I get the first part |
| 22:06.48 | prpplague | g1powermac_apl: which means that the pxa270 isn't configured |
| 22:06.56 | MothaWork | prpplague: I think you should be prepared to limit it at least to the granularity to which your software manages power |
| 22:06.59 | g1powermac_apl | its the PXA25x part I can't find in the kernel config |
| 22:07.16 | MothaWork | so if your software wants to manage down to the nearest mA because of battery draw concerns, hardware needs to enforce that |
| 22:07.37 | g1powermac_apl | prpplague, I have done searches in menuconfig for that, but to real no avail |
| 22:07.39 | MothaWork | however, if software only manages to the nearest 100mA, and a device asks for 50mA, I see no problem with letting it draw 100mA anyway as long as that is ALWAYS safe |
| 22:07.48 | prpplague | g1powermac_apl: search for what? |
| 22:07.53 | MothaWork | but I also see no problem with turning the darned thing off the instant it hits 50.1 |
| 22:08.09 | ds2 | and if the enforcement is only good to the nearest 100mA, software, IMO, should treat requests on that level so a 8mA request is the same as say a 10mA or even 100mA |
| 22:08.26 | MothaWork | basically, I would say that if a higher power request would be approved, then it's OK to limit to that higher levle |
| 22:08.49 | MothaWork | however, if software would deny a higher request due to limited power, it needs to back that up in hardware. Presumably there's a hardware reason to deny the higher request, anyway. |
| 22:09.14 | g1powermac_PB | prpplague: the PXA25x dependency |
| 22:09.16 | MothaWork | it may not be a "catches on fire" level reason. It may just be for the purposes of battery life, but it should be willing/able to turn the device off if it goes over |
| 22:09.38 | prpplague | g1powermac_apl: the zipit is pxa270 , and thats probably what you have it configured for |
| 22:10.07 | ds2 | sure or maybe the board is wired with 30G on the power pins and drawing over XYZ mA will drop the voltage below min. spec ;) |
| 22:10.13 | g1powermac_PB | yes, but the gadget support for the pxa2xx required that PXA25x thing |
| 22:10.19 | g1powermac_PB | *requires |
| 22:11.05 | MothaWork | ds2: that's a valid reason to deny the request AND shut it off if it tries |
| 22:11.06 | prpplague | g1powermac_apl: yes, my point is that the pxa25x is basically identical to the pxa27x, so its probably just that the kernel you are using hasn't been updated with the pxa27x config |
| 22:11.13 | prpplague | g1powermac_apl: what kernel version is it? |
| 22:11.22 | g1powermac_PB | prpplague: 2.6.21.1 |
| 22:11.45 | MothaWork | but I'd argue that if the device asks for, say 10mA, but the port can, at present, support 100mA, AND software would approve a 100mA request, then it's OK to limit to 100mA |
| 22:11.51 | MothaWork | even though the device only asked for 10 |
| 22:12.30 | prpplague | ds2: ok i see your point now, its just not how i normally implement usb power and its not normally how the usb hub chipsets i've used implement power |
| 22:12.48 | MothaWork | of course, the port's power capabilities may change, and 100mA may no longer be possible, at which point the device operating outside of the limits it asked for may have to get shut off. It was "in the wrong" to begin with, but operation was permitted on the basis that it was possible. |
| 22:13.04 | MothaWork | basically the old "be liberal in what you accept and be conservative in what you send" approach |
| 22:13.21 | MothaWork | oh, I wouldn't say this management philosophy is "common", but I'd say it's acceptable |
| 22:13.39 | MothaWork | I also find it acceptable to simply say "this device asked for X mA, and it's over - shut it off now" |
| 22:13.46 | MothaWork | where X is determined at enumeration time |
| 22:14.00 | MothaWork | and may get updated upon change to an alternate setting, of course |
| 22:14.30 | MothaWork | the granularity of X is somewhat hardware dependent, but I would say that software shouldn't go denying things based on granularity that it can't enforce in hardware |
| 22:15.38 | prpplague | MonMotha: yea, my practice has always been worst case, if i'm willing to approve upto 100mA thats where my overcurrent detect is at |
| 22:15.59 | prpplague | MonMotha: if i approve anything less than 100mA, its fine unless it tries to draw more than 100mA |
| 22:16.14 | prpplague | g1powermac_apl: checking now |
| 22:16.47 | ds2 | not what we are talking about here but for mobile devices, it would nice to force an enumeration on a change of power event (i.e. AC power to battery or vice versa); don't think that is part of the spec |
| 22:17.24 | SpeedEvil | bus reset is about it IIRC |
| 22:19.12 | prpplague | g1powermac_apl: yea if you look at the handhelds.org 2.6 tree you can see where they added the 27x supprot |
| 22:19.20 | prpplague | g1powermac_apl: doesn't look to be in the main tree |
| 22:20.46 | prpplague | g1powermac_apl: http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/drivers/usb/gadget/Kconfig?rev=1.43&content-type=text/x-cvsweb-markup |
| 22:21.36 | prpplague | heads home |
| 22:34.30 | *** join/#edev ico2_ (n=ico2@modem-3991.chameleon.dialup.pol.co.uk) |
| 22:36.24 | *** join/#edev CosmicPe1guin (n=nobody@163.181.251.103) |
| 22:37.03 | *** mode/#edev [+o CosmicPenguin] by ChanServ |
| 22:40.18 | *** join/#edev chouimat (n=dieu@kde/developer/chouinard) |
| 22:54.09 | MothaWork | ds2: IIRC there was a spec update for that |
| 22:54.13 | MothaWork | though it may have been part of the OTG thing |
| 22:54.36 | MothaWork | going home |
| 23:08.19 | *** join/#edev CosmicPenguin (n=nobody@163.181.251.103) |
| 23:08.20 | *** mode/#edev [+o CosmicPenguin] by ChanServ |
| 23:09.41 | *** join/#edev RobotGuy (i=robotguy@dsl093-038-072.pdx1.dsl.speakeasy.net) |
| 23:13.36 | *** join/#edev nhoman_ (n=homann@79.97.106.107) |
| 23:29.21 | g1powermac_apl | hmm |
| 23:29.42 | g1powermac_apl | ponders what he needs to do with this kernel |
| 23:48.37 | *** join/#edev ico2 (n=ico2@modem-3991.chameleon.dialup.pol.co.uk) |
