| 00:08.35 | *** join/#edev JoeLlama (n=snork@unaffiliated/joellama) |
| 00:45.42 | *** join/#edev linac (n=lin@121.201.109.107) |
| 01:26.26 | *** join/#edev Crofton (n=balister@63.224.149.101) |
| 01:49.21 | *** join/#edev kergoth (n=kergoth@ip68-3-163-239.ph.ph.cox.net) |
| 02:20.23 | *** join/#edev linac (n=lin@125.77.75.237) |
| 02:21.35 | *** join/#edev dthompso00 (n=dthompso@c-68-61-0-59.hsd1.mi.comcast.net) |
| 02:46.19 | *** join/#edev JoeLlama (n=snork@unaffiliated/joellama) |
| 02:56.40 | *** join/#edev landley (n=landley@cpe-70-116-30-223.austin.res.rr.com) |
| 02:56.40 | *** mode/#edev [+o landley] by ChanServ |
| 02:57.08 | landley | waves at prpplague. |
| 03:09.37 | *** join/#edev chouimat|work (n=dieu@209.217.106.98) |
| 03:40.14 | landley | So the once-dominant sound chip vendor (an area now thoroughly commoditized) bought out an also-ran in the 3D graphics market (3dlabs), and based on that expertise they're coming out with arm chips: http://creativezii.com/2009/01/creative-zii-platform-unveiled/#more-30 |
| 03:40.32 | landley | It says: The new chip is being built in collaboration with ARM (CPU core), Microsoft (Windows Media), and Opera (Internet). With support from these big names, device potential is extremely vast. |
| 03:40.48 | landley | Because a hardware vendor partnering with microsoft at the design stage is just _brimming_ with potential... |
| 03:49.20 | MonMotha | landley: yes, you end up with USB |
| 03:49.53 | ds2 | but but USB is such a "fine" protocol |
| 03:49.57 | ds2 | ;) |
| 03:51.57 | Mirell | Heh |
| 03:54.49 | MonMotha | ds2: if enforcing the (terrible) Windows Driver Model at the protocol level is a good thing, getting the power supply standard next to useless, and an iffy-at-best connector design are "fine", then, yes, USB is "fine" |
| 03:55.04 | MonMotha | though the USB HID standard at least isn't bad |
| 03:55.12 | MonMotha | surprisingly complete and yes reasonably simple |
| 03:55.15 | MonMotha | s/yes/yet/ |
| 03:56.47 | MonMotha | IEEE 1394 is pretty nice |
| 03:56.50 | MonMotha | sadly, it never caught on |
| 03:57.06 | MonMotha | I wish they had made a "device lite" version for small stuff like mice, keyboards, etc. |
| 03:57.23 | MonMotha | then it could have the ubiquity of USB and yet handle mass storage and networking much, much better |
| 03:57.39 | MonMotha | basically, come up with a compatible way to eliminate the need for DMA |
| 03:58.03 | archae0pteryx | how is ieee 1394 nicer than USB, I never looked at either |
| 03:59.48 | MonMotha | archae0pteryx: USB is pretty much just a mess. The enumeration is heavily based on WDM, and that can cause some headaches given how weird WDM can get. The high-speed standard is clearly a bolted-on hack, and CPU overhead can get a bit high since the DMA stuff also seems an afterthought on the host controllers. |
| 04:00.25 | MonMotha | power is a mess. 5V at 500mA isn't enough to power big stuff, but yet it's enough to require some protection. 5V is also inconvenient in these days of 3.3 and 1.8/1.2V I/O standards |
| 04:00.27 | ds2 | the HS standard... heheheh |
| 04:00.46 | MonMotha | then there's peer to peer operation...OTG is, well, a mess doesn't begin to describe HNP and such |
| 04:00.46 | ds2 | I'd disagree on the power part |
| 04:01.04 | ds2 | 5V is good... unless you want to go higher |
| 04:01.10 | MonMotha | I want like 12V |
| 04:01.33 | MonMotha | you can still use a linear supply for really low power stuff like mice and keyboards, but it provides plenty of "room" for a buck supply for higher power device |
| 04:01.39 | ds2 | but that pretty much means no linear regulators |
| 04:01.45 | MonMotha | also lets you deliver more power with the same current |
| 04:02.10 | MonMotha | it does limit the usefulness of linear supplies, yes, but 5Vbus to 3.3V is tough since Vbus can go down to 4.5V and still be in-spec |
| 04:02.17 | MonMotha | tough for a switcher, that is |
| 04:02.47 | ds2 | Oh in that sense |
| 04:03.06 | MonMotha | if everything is 1.2 or 1.8V, 5Vbus isn't as bad |
| 04:03.32 | ds2 | the signaling is at 3.3 so... |
| 04:03.34 | MonMotha | 5V devices can be tough, though, if you can't tolerate the potential range and transients on Vbus |
| 04:03.59 | MonMotha | yes, you'll always need SOME 3.3V, but potentially enough to just use a small linear |
| 04:04.26 | ds2 | 5V devices are just stupid thesedays ;) |
| 04:04.47 | MonMotha | IEEE1394 pretty much just says "power comes in on these lines and will be from 9-36V" (I think that's the range). The device has to deal with it, but that's not really a problem for a buck regulator. |
| 04:04.54 | ds2 | but spec'ing it at 5.5V might be better and give it a max 0.5V drop |
| 04:05.17 | MonMotha | but then you have to allow some room on th ehigh end, and you end up at 6V, which is too high for 5V CMOS use usualy |
| 04:05.37 | MonMotha | I'd just say make it 9 or 12V (12 is handy since PCs already have that everywhere) and tell people to deal with it. |
| 04:06.10 | ds2 | a 5.5V zener to clip it if it comes out high |
| 04:06.11 | MonMotha | small stuff can just use a plain linear. At 100mA, a linear solution still only dissipates 0.7W, which is handleable by a D2PAK. At full power, everybody will use a SMPS, which isn't a problem. |
| 04:06.34 | MonMotha | but what about current inrush if it turns out high? |
| 04:06.49 | MonMotha | that zener might get awfully hot, and the wire might see pretty high currents (EMI problems, mostly) |
| 04:07.05 | MonMotha | USB already has odd issues with soft-start, a zener clamp would just make it worse |
| 04:07.19 | ds2 | I just don't like 5V devices |
| 04:07.26 | MonMotha | there is the USB+Power standard that Dell (and some others) adopted |
| 04:07.34 | MonMotha | I never really read up on it, but it seemed like an OK idea |
| 04:07.34 | ds2 | my interest in 5.5V is to give some margin for chaging batteries |
| 04:08.14 | ds2 | the thing with 12V is I don't see that many 12V solid state switches... most seem to top out at 5.5V or 6V max |
| 04:08.22 | ds2 | but that might be a chicken and egg issue |
| 04:08.31 | MonMotha | one option would be to have an enumeration power line at 3.3 or 5V and then a "power line" at "whatever the device asks for" |
| 04:08.38 | MonMotha | I think that's kinda how USB+Power worked |
| 04:08.44 | ds2 | ewwwwww |
| 04:08.54 | MonMotha | you enumerated on the 5Vbus, and then asked for whatever on the other lines |
| 04:09.10 | ds2 | that almost means a programmable power supply |
| 04:09.13 | MonMotha | there are lots of power standards that work like that |
| 04:09.20 | MonMotha | but yes, it does mean a programmable power supply |
| 04:09.35 | MonMotha | however, the entire design philosophy behind USB is that the device end is cheap, but the host end is expensive |
| 04:09.55 | MonMotha | that's what gave way to the host/device architecture |
| 04:10.05 | MonMotha | rather than the mostly peer-peer architecture of IEEE1394 |
| 04:10.19 | MonMotha | and that's why we have the abomination that is USB OTG |
| 04:10.36 | ds2 | but in the light of mobile devices, I rather not have a programmable power supply |
| 04:10.54 | ds2 | having to boost a Li Ion cell to 5V is bad enough |
| 04:11.05 | MonMotha | well, you can make that part optional |
| 04:11.28 | MonMotha | basically, if the device is portable or otherwise not a "full host", and you have a device that needs that function, it just doesn't work |
| 04:11.35 | MonMotha | that's kinda how USB OTG behaves anyway |
| 04:11.59 | MonMotha | a full blow PC (including normal notebooks), generally have reasonable high voltage rails (at least 12V) floating around anyway |
| 04:12.02 | ds2 | I guess... but the biggest problems with OTG is the lack of power |
| 04:12.38 | MonMotha | ok, so allow Vbus to range from 3.3-5V and have the extra +power option on "Full blown hosts" |
| 04:13.03 | *** join/#edev Redhatter (n=vk4msl@2001:388:f000:0:0:0:0:5) |
| 04:13.07 | MonMotha | many devices would work as it stands, and devices with large power requirements (like printers, scanners, etc.) can ask full blown hosts (i.e. big PCs) for more power |
| 04:13.14 | MonMotha | of course, you can't make that kind of change at this point... |
| 04:13.40 | MonMotha | though I bet if you did, ~80% of devices would work fine |
| 04:13.50 | ds2 | having an allowance for up to 1A on a single connector would be nice |
| 04:14.03 | MonMotha | yes, but then you need bigger wires |
| 04:14.08 | ds2 | rather not fiddle with the power or we will be in another cycle of wait for cheap silicon |
| 04:14.18 | ds2 | fatter wires come quicker then new silicon |
| 04:14.23 | MonMotha | true |
| 04:14.40 | MonMotha | this is all pointless discussion, though. USB Vbus is 4.5-5.5V. End of story |
| 04:14.44 | ds2 | it look long enough to get cheap host controllers |
| 04:14.46 | MonMotha | that standard was set in ~1996 |
| 04:15.27 | MonMotha | I'm just saying that it's not the way I would have probably done it, and I"m pointing out that IEEE1394 takes a different approach |
| 04:15.47 | MonMotha | USB seemed very (perhaps overly) concerned about device cost. IEEE1394 seemed to take the approach of "let's get it 'right'" |
| 04:16.13 | MonMotha | which resulted in a minimal device cost that put it out of reach of most common peripherals |
| 04:16.43 | MonMotha | i.e. the stuff that USB was originally meant to address: keyboards, mice, joysticks, small storage devices, etc. |
| 04:18.29 | ds2 | but then the USB spec has been ignored/violated so many times.... |
| 04:19.08 | MonMotha | well, that certainly doesn't help |
| 04:19.19 | ds2 | even MS violates that spec |
| 04:19.25 | MonMotha | everybody violates it |
| 04:19.30 | ds2 | and most PC's don't even enforce the power limit |
| 04:19.45 | MonMotha | part of the problem is that it's a terrible spec |
| 04:19.59 | MonMotha | well, the power limit is an interesting thing. Actually, it was very forward thinking of them. |
| 04:20.58 | ds2 | it may be but there are so much silicon out there :( |
| 04:20.58 | MonMotha | well, when I say it's a terrible spec, I don't necessarily mean the technical nature of it (though that's bad, too), but that the specification itself is bad |
| 04:20.58 | MonMotha | as in it's poorly written, ambiguous, and makes assumptions |
| 04:21.05 | MonMotha | like the giant section on the VHDL derived state machine for the host controller |
| 04:21.09 | MonMotha | what's up with that? |
| 04:21.28 | MonMotha | that's not how you document behavior (and they even specifically say that it's intended for reference) |
| 04:21.45 | MonMotha | the problem is that their reference implementation effectively comprises the spec, as other parts are ambiguous |
| 04:21.53 | ds2 | heh... no arguments there |
| 04:22.22 | MonMotha | I deal with USB rather frequently, and I don't think it's a good spec |
| 04:22.50 | MonMotha | it does work, but there are several aspects I think are either poorly thought out, bad practice, poorly documented, or (frequently) some combination thereof |
| 04:23.01 | MonMotha | but it's here to stay, so I'll deal with it |
| 04:23.29 | MonMotha | I have not yet read USB 3.0, so I'll withhold judgement for now |
| 04:23.33 | ds2 | I don't argue the spec is good; my main point is we are beyond the point of return |
| 04:23.39 | MonMotha | I agree, we are |
| 04:23.40 | *** join/#edev linac (n=lin@125.77.75.237) |
| 04:24.18 | MonMotha | from the sound of it, USB 3.0 kinda acknowledges that and attempts to reimplement things in a better, but backwards compatible manner |
| 04:24.27 | MonMotha | I should go grab a copy of the draft some time |
| 04:24.47 | ds2 | think they were showing a USB 3.0 demo at CES |
| 04:25.23 | MonMotha | yeah, there are some early implementations |
| 04:25.39 | MonMotha | it's supposedly based on or similar to PCIe |
| 04:26.02 | MonMotha | though I question then why we don't just come up with a hot swap connector/cabling system for PCIe (the standard already supports hot swap, and ExpressCard uses it) |
| 04:26.42 | MonMotha | we could even make the connectors backwards compatible to USB 2.0 and call it USB 3.0 :) |
| 04:27.01 | MonMotha | (who knows, maybe that's what they did, I haven't read the technical docs) |
| 04:27.29 | ds2 | though there is a cable standard for ExpressCard? seem to recall someone talking about it at a show |
| 04:27.44 | MonMotha | there might be |
| 04:28.00 | MonMotha | there is some semblance of a cable standard for PCIe that's pushed by Molex, I think |
| 04:28.03 | MonMotha | it's not cheap, though |
| 04:28.19 | MonMotha | that may just be due to low volume; I don't know |
| 04:28.40 | MonMotha | it also supports up to 16 lanes, so that might explain the cost |
| 04:29.02 | MonMotha | for these applications, 1 lane (in each direction) should be sufficient |
| 04:29.16 | MonMotha | another option might be to find a standard way to run all this over eSATA |
| 04:29.30 | MonMotha | eSATA is of course electrically almost identical to PCIe |
| 04:29.46 | MonMotha | they're both LVDS at similar voltages |
| 04:55.21 | ds2 | SATA needs to die |
| 04:55.27 | ds2 | rotating media... BAH |
| 04:55.30 | landley | You can't quiesce a system with active USB. It has to poll the device 250 times/second according to the spec. |
| 04:56.07 | ds2 | you can yank power underneath it |
| 04:58.56 | landley | ds2: flash devices are unusable with conventional read/write filesystems. |
| 04:59.20 | landley | All those USB flash devices give you no way to query the erase granularity of the device, which is way bigger than the 512 byte block (or 4k) the filesystem allocates in. |
| 04:59.53 | landley | So you go to write 3 scattered blocks, you journal that you're doing it, and yank power between the "erase" and "rewrite" cycles and suddenly find out you have a megabyte of zeroes stomped over the middle of your filesystem. |
| 05:00.04 | landley | Which is something that even fsck won't catch if it's not in the metadata, by the way. |
| 05:00.23 | landley | Could be a megabyte after the sector you touched, a megabyte before, or your sector might be in the middle of that megabyte. |
| 05:00.50 | landley | And if it _is_ metadata, your fsck will catch it but what's it gonna do about thousands of inodes being completely lost? |
| 05:01.29 | landley | Flash filesystems can do something about that (albeit badly), but they need to query the erase granularity which is something that flash drives pretending to be normal block devices don't report. |
| 05:02.06 | ds2 | landley: conventional fs's should not be used. |
| 05:02.29 | landley | And then there's the limited write cycle issue, which a build server can go through in a week even with good block rotation, again because of the granularity issue. You're erasing lots and lots and lots of adjacent data every time your build server writes a "blah.o" file. |
| 05:04.09 | landley | So your options are "cache a lot and be willing to lose megabytes of data if you get a panic or hardware failure", or "sync a lot, rewriting existing data a whole bunch, and burn out the media in a couple months of normal usage". |
| 05:04.17 | landley | Flash ain't the panacea you seem to be implying. |
| 05:29.43 | *** join/#edev moi1234 (n=moi@ip70-179-18-67.sd.sd.cox.net) |
| 05:41.52 | MonMotha | landley: how about flash with e.g. MRAM buffer? |
| 05:42.52 | MonMotha | keep everything 100% non-volatile while letting the FTL (or filesystem, if it is managing directly via a suitable interface) buffer things up so that a full erase block is used when needed |
| 05:43.09 | MonMotha | even 32MB of MRAM isn't unreasonably priced these days, though it would certainly blow the budget of cheap USB flash drives |
| 05:43.36 | MonMotha | and yes, the bus poll nature of USB wrt power management and true async interrupt stuff is a problem |
| 06:14.06 | *** join/#edev DrZimmerman (n=theo@77-56-225-121.dclient.hispeed.ch) |
| 06:24.15 | *** join/#edev mbuf (n=shakthim@59.96.11.218) |
| 06:25.45 | *** join/#edev archae0pteryx (n=snewman@69-12-128-192.dsl.static.sonic.net) |
| 06:30.46 | *** join/#edev ZeZu (n=null@c-98-227-56-17.hsd1.in.comcast.net) |
| 06:52.52 | *** join/#edev lyakh (n=lyakh@p57BD2BB5.dip0.t-ipconnect.de) |
| 06:53.09 | *** join/#edev JoeLlama (n=snork@unaffiliated/joellama) |
| 07:04.48 | *** join/#edev mbuf (n=shakthim@59.92.23.6) |
| 07:34.36 | *** join/#edev davidc__ (n=davidc__@S01060002b360aacd.vc.shawcable.net) |
| 08:23.25 | *** join/#edev ZeZu (n=null@c-98-227-56-17.hsd1.in.comcast.net) [NETSPLIT VICTIM] |
| 08:31.56 | *** join/#edev JoeLlama (n=snork@unaffiliated/joellama) |
| 08:49.14 | *** join/#edev KazaLite (n=kazaLite@116.58.8.130) |
| 09:16.50 | *** join/#edev ZeZu (n=null@c-98-227-56-17.hsd1.in.comcast.net) |
| 09:22.21 | *** join/#edev lyakh (n=lyakh@p57BD2BB5.dip0.t-ipconnect.de) |
| 10:41.02 | *** join/#edev hw (n=hw@p578b3905.dip0.t-ipconnect.de) |
| 11:05.28 | *** join/#edev roxfan (i=dunno@232.34-244-81.adsl-dyn.isp.belgacom.be) |
| 11:06.49 | *** join/#edev gustavoz (n=gustavoz@imhotep.toptech.com.ar) |
| 12:30.20 | *** join/#edev g1powermac (n=g1powerm@unaffiliated/g1powermac) |
| 12:35.34 | *** join/#edev linac (n=lin@121.201.109.107) |
| 12:45.06 | *** join/#edev linac (n=lin@121.201.109.107) |
| 12:45.06 | *** join/#edev Redhatter (n=vk4msl@gentoo/developer/redhatter) |
| 12:55.14 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 13:08.29 | *** join/#edev flavioribeiro (n=avaty@189.71.5.77) |
| 14:05.32 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 14:11.24 | *** join/#edev adyer (n=adyer@adsl-69-223-13-78.dsl.chcgil.ameritech.net) |
| 14:20.56 | *** join/#edev GPSFan (n=kenm@64.92.143.179) |
| 14:20.56 | *** mode/#edev [+o GPSFan] by ChanServ |
| 14:22.17 | prpplague | greetings folks |
| 14:24.33 | GPSFan | prpplague: g'day |
| 14:37.15 | prpplague | ho ho hum |
| 14:37.26 | prpplague | sad sad day at AML |
| 14:37.28 | Mirell | Miaoning. |
| 14:37.32 | Mirell | Oh? |
| 14:37.47 | prpplague | i "got the memo" this morning, linux is dead at AML |
| 14:38.21 | prpplague | all linux at AML will stop at the end of january |
| 14:38.30 | prpplague | s/linux/linux dev |
| 14:40.13 | GPSFan | sheds a tear for AML & prpplague |
| 14:40.16 | Mirell | o.O |
| 14:40.42 | chouimat|work | sends a beer to prpplague and takes a few moment of silence |
| 14:42.31 | prpplague | they didn't get a single questionare back from the trade show that had the linux option checked |
| 14:42.46 | prpplague | not one out of 5000 responses |
| 14:42.57 | prpplague | (5042 to be exact) |
| 14:50.24 | chouimat|work | prpplague: trade show ... if the companies over there where like the one here they didn't the technical guys to it |
| 14:56.11 | prpplague | chouimat|work: this one is for those IT/CIO 's doing purchasing of systems |
| 14:56.33 | chouimat|work | prpplague: exactly what I said ... ;) |
| 14:57.40 | prpplague | chouimat|work: yea, really doesn't matter about the tech, these are you guys that approve the direction and purchasing |
| 14:57.54 | prpplague | chouimat|work: if they aren't interested in purchasing linux, it isn't getting purchased |
| 14:58.00 | chouimat|work | so ture |
| 14:59.52 | prpplague | chouimat|work: last year at least we had some check the linux box, it was about 20% last year |
| 15:05.58 | *** join/#edev silverpower (n=michi@atheme/bofh/silverpower) |
| 15:19.09 | *** join/#edev kergoth (n=kergoth@ip68-3-163-239.ph.ph.cox.net) |
| 15:37.13 | *** join/#edev kergoth (n=kergoth@ip68-3-163-239.ph.ph.cox.net) |
| 15:41.29 | *** join/#edev CosmicPenguin (n=nobody@66-162-99-237.static.twtelecom.net) |
| 15:43.31 | *** part/#edev adyer (n=adyer@adsl-69-223-13-78.dsl.chcgil.ameritech.net) |
| 15:59.28 | *** join/#edev mbuf (n=shakthim@59.92.73.226) |
| 16:03.02 | CosmicPenguin | kergoth: http://lkml.org/lkml/2009/1/13/508 |
| 16:03.05 | CosmicPenguin | That might interest you |
| 16:05.44 | prpplague | CosmicPenguin: greetings |
| 16:05.54 | CosmicPenguin | prpplague: morning |
| 16:06.08 | CosmicPenguin | daughter-in-law feeling better? |
| 16:06.15 | CosmicPenguin | step daughter I guess... |
| 16:06.15 | prpplague | CosmicPenguin: hehe you see that AMD made the top ten list of companies that are predicted to go belly up in 2009? |
| 16:06.21 | CosmicPenguin | heh - no - url? |
| 16:06.25 | prpplague | CosmicPenguin: yea somewhat |
| 16:07.26 | prpplague | CosmicPenguin: i'll have to dig up the url |
| 16:08.26 | prpplague | CosmicPenguin: it's official, all linux dev at AML ends at the end of the january |
| 16:08.38 | CosmicPenguin | when is your last day? |
| 16:09.36 | prpplague | is moving over to wince dev for now |
| 16:10.26 | prpplague | plus i still have to support the legacy linux devices for atleast a year or so |
| 16:10.38 | prpplague | CosmicPenguin: http://www.channelinsider.com/c/a/News/Dire-Predictions-Tech-Vendors-That-May-Not-Survive-2009/ |
| 16:11.37 | prpplague | CosmicPenguin: out of 5000 questionares at the trade show, they didn't get a single response with anyone wanting or planning to use linux based handhelds/kiosks |
| 16:12.43 | mbuf | prpplague, from whom? |
| 16:12.56 | Mirell | prpplague: That's sad, but it makes the business decision make sense. |
| 16:13.20 | mbuf | prpplague, with cost-cutting, people will tend to move to FOSS; |
| 16:13.29 | prpplague | mbuf: CIO/IT admins |
| 16:13.41 | CosmicPenguin | Did you for real send me a URL that doesn't work with firefox? |
| 16:13.59 | prpplague | CosmicPenguin: works fine on my firefox |
| 16:14.06 | CosmicPenguin | flash? |
| 16:14.24 | prpplague | yea |
| 16:14.28 | CosmicPenguin | ahhh... |
| 16:16.39 | CosmicPenguin | What 10 are on the list? |
| 16:17.33 | prpplague | i don't recall all of them, seems like vmware, novell, and AMD were all on there |
| 16:19.24 | CosmicPenguin | heh - one of the companies I interviewed with and the other I justl eft |
| 16:22.17 | prpplague | apparently motorola/symbol spent alot of time at the company booth at the trade show |
| 16:22.27 | prpplague | which has alot of people concerned |
| 16:22.48 | prpplague | motorola/symbol has a history of buying up smaller companies just to close them down |
| 16:27.04 | CosmicPenguin | I dunno about these predictions |
| 16:27.05 | CosmicPenguin | sun? |
| 16:28.32 | CosmicPenguin | That was a false article - they didn't actually think any of the companies were going away |
| 16:44.16 | *** join/#edev Omegamoon (n=egoe@demolitionman.xs4all.nl) |
| 16:56.24 | *** join/#edev Omegamoon (n=egoe@demolitionman.xs4all.nl) |
| 16:59.20 | *** part/#edev Omegamoon (n=egoe@demolitionman.xs4all.nl) |
| 17:02.45 | *** join/#edev Omegamoon (n=egoe@demolitionman.xs4all.nl) |
| 17:38.16 | *** join/#edev dijenerate (n=dijenera@72.51.74.174) |
| 17:41.54 | CosmicPenguin | Noika is making the next version of QT available under the LPGL |
| 17:52.40 | CosmicPenguin | LGPL even |
| 17:54.27 | *** join/#edev lyakh (n=lyakh@p57BD2BB5.dip0.t-ipconnect.de) |
| 18:14.39 | *** join/#edev adyer (n=adyer@adsl-69-223-13-78.dsl.chcgil.ameritech.net) |
| 18:23.52 | *** join/#edev archae0pteryx (n=snewman@207.47.42.130.static.nextweb.net) |
| 18:36.21 | *** join/#edev sleipnir (n=Sleipnir@p4FDD6158.dip.t-dialin.net) |
| 18:48.40 | *** part/#edev adyer (n=adyer@adsl-69-223-13-78.dsl.chcgil.ameritech.net) |
| 18:58.29 | *** join/#edev dijenerate (n=dijenera@72.51.106.88) |
| 19:07.26 | archae0pteryx | Cosmicpenguin: saw that about QT, sounds cool, guess I need to check it out |
| 19:12.56 | *** join/#edev adyer (n=adyer@adsl-69-223-13-78.dsl.chcgil.ameritech.net) |
| 19:17.16 | Redhatter | CosmicPenguin: That's good news in a way... I've been using wxWidgets lately for a couple of apps I've written (for work; my own stuff is GPLv2 mostly) since I'm not keen on mixing proprietary with GPL. (wxWidgets is LGPL) However, if Qt is now LGPL, I guess I could move across to it. |
| 19:18.54 | keesj | I did Qt a few years ago and really liked it |
| 19:20.08 | keesj | it made c++ doable |
| 19:35.48 | *** join/#edev damunix (n=damunix@brc29-1-82-245-194-55.fbx.proxad.net) |
| 19:36.06 | damunix | ' evening |
| 19:40.07 | archae0pteryx | Does anyone know of any good conferences for embedded / embedded linux other than ESC / ELC on the US west coast |
| 19:40.13 | *** join/#edev Bluenarf (n=Paul@apollo.paulsnet.org) |
| 19:46.33 | *** join/#edev JoeLlama (n=snork@unaffiliated/joellama) |
| 19:48.05 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 19:57.08 | *** join/#edev prpplague (n=prpplagu@ppp-70-244-162-101.dsl.rcsntx.swbell.net) |
| 19:57.11 | prpplague | ho ho hum |
| 19:57.24 | prpplague | wince dev is sooooo much different when it comes to sharing information |
| 20:06.29 | GPSFan | prpplague: you gonna get a chance to peek at the pix looking for my cs & int pins? |
| 20:06.57 | prpplague | GPSFan: later today, i brought my z2 board home |
| 20:07.11 | prpplague | GPSFan: i've got to go see a lawyer about my stepdaughters child support |
| 20:07.22 | prpplague | GPSFan: be back later this afternoon |
| 20:07.31 | GPSFan | ah, best of luck... |
| 20:07.42 | prpplague | GPSFan: sorry for the long delay, but i had been putting off a bunch of stuff until after the trade show |
| 20:07.49 | prpplague | GPSFan: now i have to get it don |
| 20:07.50 | prpplague | done |
| 20:07.54 | GPSFan | yeah, no problemo. |
| 20:10.38 | prpplague | wonders if he starts a bunch of wince howto's on elinux if m$ would come after him |
| 20:13.49 | prpplague | ho ho hum |
| 20:13.52 | prpplague | grumbles |
| 20:21.02 | damunix | hi prpplague |
| 20:29.55 | prpplague | damunix: greetings |
| 20:30.10 | prpplague | damunix: from what i can tell so far the USB host issue is related to the s3c24xx subset |
| 20:30.12 | damunix | how are you prpplague ? |
| 20:30.17 | prpplague | damunix: i have dig some deeper as i have time |
| 20:30.37 | damunix | prpplague: any try with .28 ? |
| 20:31.07 | prpplague | damunix: not yet, i've been working on some wince stuff |
| 20:31.23 | damunix | prpplague: ok |
| 20:31.35 | damunix | prpplague: so no issue for the moment ? |
| 20:32.02 | prpplague | damunix: i am sorry i did not understand your question |
| 20:32.20 | damunix | no solution, |
| 20:32.53 | damunix | prpplague: no solution for the moment (sorry :) ? |
| 20:33.34 | prpplague | damunix: correct |
| 20:33.43 | prpplague | damunix: probably in the next few days as i have time |
| 20:33.47 | damunix | ok ;) |
| 20:33.55 | prpplague | GPSFan has me scheduled already to do some debugging for him |
| 20:34.58 | prpplague | damunix: it is on my list of things to get done, so have some patience |
| 20:35.01 | damunix | prpplague: I'm not sure, but doesn't Openmoko use the s3c2410 chip ? Doesn't they use with usb host (not shure about this)? |
| 20:35.35 | damunix | prpplague: no pb :) |
| 20:36.30 | damunix | just hope it will work :p |
| 20:37.48 | prpplague | damunix: no they only use the USB device support not host |
| 20:37.53 | prpplague | damunix: iirc |
| 20:38.01 | prpplague | damunix: i haven't looked in awhile though |
| 20:38.42 | prpplague | damunix: you could check the openmoko wiki to see if they are |
| 20:39.06 | damunix | prpplague: appears to work : http://wiki.openmoko.org/wiki/USB_host |
| 20:39.19 | prpplague | on what kernel version ? |
| 20:40.12 | damunix | same :http://wiki.openmoko.org/wiki/Samsung_S3C2410 |
| 20:42.32 | prpplague | doesn't say what kernel version |
| 20:43.38 | damunix | lol, I'm looking for this |
| 20:45.37 | prpplague | looks like they are using 2.6.26, but the ohci driver isn't part of the default configuration |
| 20:46.07 | prpplague | damunix: the standard phone doesn't use the host controller, so i would be willing to bet not many people have tested it |
| 20:46.40 | damunix | I know that in the new openmoko device (freerunner), usb host work |
| 20:47.17 | prpplague | best to double check the kernel version and see if there are any patch |
| 20:52.29 | damunix | das_plague: do you ever had kernel null pointer dereference ? |
| 20:57.24 | *** join/#edev flavioribeiro (n=avaty@189.71.5.77) |
| 21:21.55 | Mirell | Hmm.. |
| 21:31.47 | *** join/#edev archae0ptery1 (n=snewman@207.47.42.130.static.nextweb.net) |
| 21:47.08 | Mirell | Anyone happen to know a disassembler for MIPS? |
| 21:47.55 | roxfan | objdump? |
| 21:48.03 | roxfan | ida can do mips too |
| 21:48.20 | Mirell | Ahh.. |
| 21:49.00 | Mirell | Hmm... |
| 21:49.20 | Mirell | is trying to figure out how exactly a vmlinux.bin kernel image is run.. |
| 21:50.34 | Mirell | I would have thought that the initial part of the file would have a jump instruction for the kernel_entry point.. |
| 21:50.40 | Mirell | But it's just a blank first page |
| 21:51.53 | roxfan | x86 kernel now also has entrypoint later |
| 21:52.08 | roxfan | maybe it's the same thing |
| 21:52.44 | roxfan | hm, i downloaded test image for qemu... and the kernel is an elf file o.o |
| 21:53.11 | Mirell | roxfan: Yep |
| 21:53.49 | Mirell | roxfan: But I'm trying to get the kernel on the router as a binary file, and it's frustrating me, since I know it can run it if I tell it on the console to load it as an ELF |
| 21:54.05 | Mirell | But it loads it into memory at 0x80001000, and jumps to there and starts |
| 21:54.15 | Mirell | Which if the initial page is blank...it's not going to do anything.. |
| 21:54.31 | *** part/#edev Omegamoon (n=egoe@demolitionman.xs4all.nl) |
| 22:01.49 | roxfan | i see a jump to kernel_entry at 80010400 if that helps |
| 23:22.55 | das_plague | Mirell: sjhill is the mips guru |
| 23:23.08 | das_plague | Mirell: but he doesn't get much irc time anymore |
| 23:23.21 | das_plague | Mirell: if he talks to much, guys in black suits come and get you |
| 23:25.43 | Mirell | Heh |
| 23:28.52 | CosmicPenguin | yeah - thats not a joke |
| 23:32.21 | Mirell | o.O |
| 23:37.19 | joe_bleau | This is weird--my ALIX won't boot to Linux unless I have the VGA cable connected. |
| 23:40.39 | CosmicPenguin | are you running X? |
| 23:47.22 | *** join/#edev chouimat|away (n=dieu@r2351064.cidc.net) |
| 23:50.32 | CosmicPenguin | Wow, Nortel filed for chapter 11? |
| 23:50.53 | CosmicPenguin | also, RIP Ricardo Motalban |
| 23:50.56 | CosmicPenguin | de plane! |
| 23:51.47 | Mirell | My eyes..they burn... |
| 23:51.54 | Mirell | No more hexdumps..please... |
| 23:52.58 | joe_bleau | No X, but I'm using vesafb for my app (SDL based). |
| 23:53.25 | joe_bleau | I've configured grub for serial output, so I can confirm that grub attempts to boot the kernel |
| 23:53.29 | joe_bleau | But nothing past that. |
| 23:53.38 | CosmicPenguin | yeah - you are hanging waiting for the EDID probe in VESA to finish |
| 23:54.26 | joe_bleau | So, this is by design? Or is there a workaround? |
| 23:54.44 | CosmicPenguin | its a bug |
| 23:54.47 | joe_bleau | (I'm really impressed you know what's wrong...it took me at least an hour to track it down.) |
| 23:54.50 | MonMotha | sounds like another instance of "stupid long timeout" |
| 23:55.08 | MonMotha | there seem to be a few timeouts in Linux that have no basis in reality |
| 23:55.12 | joe_bleau | It's not a killer, since we should be connected most of the time. |
| 23:55.26 | CosmicPenguin | Its in the BIOS - the only possible workaround is to avoid the EDID probe |
| 23:55.40 | CosmicPenguin | and you might not even be able to avoid that |
| 23:55.49 | MonMotha | oh, this system uses ROM code for an EDID probe? |
| 23:55.56 | CosmicPenguin | yeah, through vesa |
| 23:55.57 | MonMotha | many embedded systems do that purely in Linux |
| 23:56.01 | MonMotha | I see |
| 23:56.04 | CosmicPenguin | this is x86, fool! |
| 23:56.08 | MonMotha | oh, heh |
| 23:56.19 | CosmicPenguin | yep |
| 23:56.19 | MonMotha | and this is #edev! :) |
| 23:56.31 | CosmicPenguin | its embedded... mostly |
| 23:56.34 | MonMotha | I pretty much assume ARM, MIPS, PPC, etc. in here |
| 23:56.39 | MonMotha | but I guess PC-104 might qualify |
| 23:56.47 | joe_bleau | Hey, if I'm off-topic, I'll shut up. |
| 23:57.15 | CosmicPenguin | its not super off topic |
| 23:57.46 | MonMotha | you're in here enough that it's not a problem |
| 23:57.54 | MonMotha | I just didn't see the mention of PC-ish |