| 00:00.20 | HcE | read the datasheet? |
| 00:00.25 | scanlime | Which hc module is it using? |
| 00:00.26 | HcE | why do you need to know? |
| 00:01.00 | eut | how can i find that out? |
| 00:01.28 | scanlime | should be in dmesg.. or if it's a kernel module, in lsmod |
| 00:01.30 | *** join/#edev redblue (i=star@ppp147.108-253-207.mtl.mt.videotron.ca) |
| 00:01.32 | MonMotha | scanlime: it is apparently OHCI |
| 00:01.41 | MonMotha | the one built in to the PXA27x |
| 00:01.46 | scanlime | ok. As far as I know, there's no way not to use DMA with OHCI |
| 00:02.15 | MonMotha | that's what I thought |
| 00:02.34 | eut | ohci_hcd |
| 00:03.12 | HcE | which gumstix has USB host? |
| 00:03.32 | eut | verdex |
| 00:04.06 | eut | i'm using verdex xl6p |
| 00:05.40 | HcE | lol |
| 00:05.43 | HcE | USB host 1.1 |
| 00:05.53 | eut | yeah |
| 00:05.57 | eut | 'full speed' :] |
| 00:05.58 | HcE | it is OHCI 1.0a |
| 00:06.13 | scanlime | I doubt the gumstix CPU could keep up with high-speed anyway :p |
| 00:06.40 | HcE | datasheet says it has DMA-stuff |
| 00:06.43 | HcE | really? |
| 00:06.53 | HcE | is not PXA270 running 400 something MHz? |
| 00:06.56 | MonMotha | full speed != high speed |
| 00:07.19 | HcE | I know |
| 00:07.26 | HcE | high is 480 Mbps, full is 12 |
| 00:07.27 | eut | 600Mhz |
| 00:07.33 | HcE | should be fine then |
| 00:07.43 | MonMotha | the issue would probably be memory bandwidth |
| 00:07.46 | HcE | I've managed to push quite a lot on 200 MHz CPU |
| 00:07.50 | MonMotha | most systems like that have a lack of it |
| 00:08.04 | MonMotha | especially if you have an LCD controller without a dedicated framebuffer |
| 00:08.17 | HcE | sure, then you get a bit screwed bus wize |
| 00:09.05 | MonMotha | there are some nifty ARM CPUs out there with more than one memory bus |
| 00:09.20 | HcE | can't remember if I had the LCD controller activated when I did some USB-testing |
| 00:09.43 | eut | so then what this means is that my gumstix xl6p's usb host controller does support dma so the problem with the camera driver is not a lack of dma support |
| 00:09.48 | HcE | the USB stops at around 250-300 Mbps |
| 00:09.48 | eut | ? |
| 00:10.03 | scanlime | speaking of multiple memory busses.. is anyone using the AVR32? I only recently noticed that they have a Linux port. |
| 00:10.10 | MonMotha | AT91SAM9263 claims 41.6Gbps on-chip bandwidth, but that includes the bandwidth to the TCMs (it's a crossbar switch internally) |
| 00:10.21 | MonMotha | scanlime: I've been trying to find an excuse to use it |
| 00:10.32 | HcE | scanlime: I use it, daily |
| 00:10.39 | HcE | scanlime: google my name and you'll know why ;P |
| 00:10.56 | MonMotha | oh, are you that Atmel Nordic guy? |
| 00:11.02 | HcE | MonMotha: does not help with loads of bandwidth if everything is going into the SDRAM anyway |
| 00:11.09 | scanlime | HcE: ah, cool :) |
| 00:11.32 | HcE | MonMotha: if you can do some funky buffering using SRAM banks you might get a lot improvement. IIRC 9263 has quite a lot SRAM as well |
| 00:11.39 | MonMotha | HcE: well, that particular micro has two external busses |
| 00:11.45 | HcE | I know |
| 00:11.56 | HcE | so you can have one SDRAM for framebuffer and one for the rest |
| 00:12.02 | HcE | expensive though |
| 00:12.21 | HcE | dunno what I want instead, perhaps DDR3? |
| 00:12.38 | MonMotha | HcE: well, using SDRAM on EBI1 is a pain in the ass (you lose Ethernet, IIRC), but I have an SRAM on it on one product (was going to use PSRAM, but the package wasn't friendly) |
| 00:12.38 | HcE | I have not really looked into where the latency is sane after SDRAM |
| 00:13.01 | HcE | persistent SRAM? |
| 00:13.06 | MonMotha | the peripheral muxing on that chip is dumb |
| 00:13.14 | MonMotha | Psuedo-SRAM |
| 00:13.23 | MonMotha | basically SDRAM with a controller built in that makes it look like SRAM |
| 00:13.46 | MonMotha | well, variable wait-state SRAM |
| 00:15.22 | HcE | ah, ok |
| 00:15.22 | MonMotha | problem is that those parts are usually targeted for cell phones, so they're in tiny packages |
| 00:15.37 | MonMotha | biggest I could find was a 0.75mm pitch BGA, which I didn't want to pay for the PCB specs for |
| 00:15.49 | MonMotha | SAM9263 is a 0.8mm, which I was right at the limit for on my PCB specs |
| 00:16.36 | HcE | why can you have external SRAM and not SDRAM? |
| 00:16.41 | MonMotha | but yes, the 9263 has a lot of onboard SRAM. If you have a small LCD, you can fit the framebuffer/Color LUT in SRAM, but our display is 800x480 |
| 00:16.42 | HcE | SDRAM should use fewer lines.. |
| 00:16.57 | MonMotha | HcE: the lines for the SDRAM controller are muxed with ethernet |
| 00:17.05 | MonMotha | That's just the way the did it on that chip. It's dumb. |
| 00:17.12 | HcE | that's not sane |
| 00:17.16 | MonMotha | no, it isn't |
| 00:17.36 | MonMotha | if you run the LCD controller in 24BPP mode, you lose Ethernet, too. They tried to make it work for RMII mode, but there's one signal in the wrong place. |
| 00:17.37 | HcE | I mainly work with AVR32 and AVR, so I do not see ARM's before they are done |
| 00:17.45 | MonMotha | the ARMs are very quirky |
| 00:17.54 | MonMotha | they've got good specs, but they're quirky as hell |
| 00:17.56 | MonMotha | AVR I love, though |
| 00:18.26 | MonMotha | haven't done anything with AVR32 yet. There is some concern that if the Microchip/ON purchase of Atmel were to go through (looks like it will not) that AVR32 could die |
| 00:18.36 | ds2 | anyword on Amtel surviving ? |
| 00:18.42 | HcE | none |
| 00:18.49 | HcE | BOD not done talking yet |
| 00:19.01 | HcE | and I do not think I get to know anything before they make a public notice |
| 00:19.22 | MonMotha | ds2: the conditions aren't exactly ripe for it to go through, but I've heard no official word either (I don't work there, just a customer at work) |
| 00:19.38 | HcE | 5 bucks is to little |
| 00:19.47 | MonMotha | $5 is kinda low, yes |
| 00:19.56 | HcE | so my guess is there will be a no, and then they will up the ant if they can afford |
| 00:20.02 | MonMotha | it represents a premium over their current stock value, but they are currently low (along with the rest of the market) |
| 00:20.16 | HcE | they tried getting Atmel dead cheap, and I understand the timing of the offer |
| 00:20.55 | MonMotha | HcE: all I ask is that the AVR/AVR32 guys not let the ARM guys corrupt them with their braindead peripherals |
| 00:21.02 | MonMotha | the AVR SPI controller actually works :) |
| 00:21.24 | HcE | well, the SPI from SAM is in AVR32 devices |
| 00:21.34 | ds2 | MonMotha: I figure you are a user of the chips so you might pay a bit more attention |
| 00:21.36 | HcE | but the interface is a bit different on AVR32's |
| 00:21.46 | MonMotha | HcE: did AVR32 at least fix it? :) |
| 00:21.55 | HcE | it works better |
| 00:22.01 | HcE | AP7200 seems to be quite nice |
| 00:22.07 | MonMotha | ds2: we have kept up on it, yes. It the purchase were to go through, it could certainly have some implications for us |
| 00:22.25 | MonMotha | HcE: good. I think we ended up bit banging our SPI on the SAM7s |
| 00:22.30 | HcE | lol |
| 00:22.32 | MonMotha | couldn't get it to work reliably |
| 00:22.45 | MonMotha | the hardware would fail to set completion flags |
| 00:22.53 | MonMotha | though we were attempting PIO, not DMA |
| 00:23.00 | MonMotha | Linux on the ARM9s use it in DMA mode, I know |
| 00:23.34 | HcE | PIO works fine |
| 00:23.38 | HcE | DMA can be tricky |
| 00:24.00 | MonMotha | odd. We were having issues with the completion flags not getting set. Perhaps our driver guy used the wrong flagset or something. |
| 00:24.08 | HcE | dunno |
| 00:24.17 | MonMotha | Of course, we also originally had to get it working with a Rev. A RF230 |
| 00:24.24 | HcE | hihi |
| 00:24.24 | MonMotha | the "not quite SPI" part |
| 00:24.32 | HcE | I've not used those |
| 00:24.48 | HcE | our RF guy got UC3 working fine with RF230 |
| 00:24.56 | HcE | running the zigbee stuff |
| 00:25.27 | MonMotha | they fixed it on the Rev. B (along with some other nasty errata), but the original RF230s had the data output change immediately after the clock edge on which it clocked in data, rather than on the opposite one |
| 00:25.36 | MonMotha | that apparently worked on AVR, but the ARM SPI controller had a fit |
| 00:25.47 | MonMotha | the Rev. B part speaks normal SPI |
| 00:25.54 | HcE | well, that is good |
| 00:26.12 | MonMotha | they also fixed a bunch of the 802.15.4 MAC helper stuff |
| 00:26.20 | MonMotha | those radios are actually very nice now |
| 00:26.37 | MonMotha | the Rev. A was a little weird, but the Rev. B doesn't seem to bad, and it's hard to argue with the RF performance |
| 00:26.38 | HcE | yes, very nice range |
| 00:29.16 | solar | Anybody know if the OMAP35 is ARM926EJ-S based? |
| 00:32.02 | *** join/#edev Ian_Daniher (n=it@69.61.230.246) |
| 00:32.16 | ds2 | No. |
| 00:32.21 | ds2 | it is CortexA8 |
| 00:32.37 | ds2 | solar: what fun stuff are you doing with the OMAP3's? |
| 00:42.34 | solar | ds2: nothing personaly. I just have a user in #gentoo-embedded who is unsure of which chost to setup his cross compiler for. |
| 00:42.55 | solar | I figured most omap chips are 926 based |
| 00:43.41 | solar | which would result in him using armv5te-softfloat-linux-(gnueabi|gnu|uclibc|uclibcgnueabi) |
| 00:44.07 | solar | the darn datasheet for it's 200+ pages and made my laptop crash |
| 00:49.43 | ds2 | most recent OMAP chips are not 926's based... the Davinci's are |
| 00:50.35 | ds2 | OMAP2's (N800/N810) are ARM11's; OMAP3's are CortexA8 |
| 00:51.25 | solar | know what the proper CHOST is then? |
| 00:51.42 | ds2 | CHOST? donno what a CHOST is |
| 00:52.02 | solar | CHOST/CTARGET/CBUILD are the 3 most basic terms of the toolchain :) |
| 00:52.28 | ds2 | okay... did I not say I am a kernel guy? ;) |
| 00:52.47 | solar | anyway it's the 4 part tuple. |
| 00:53.04 | solar | arm*-anything-linux-libc |
| 00:53.07 | ds2 | HOST is the system it is going to compile from, right? |
| 00:53.49 | ds2 | arm-none-linux-gnueabi- is what Code Sourcery uses |
| 00:55.09 | solar | ds2: know what CFLAGS they pass? -march= -mtunue= on that generic toolchain? |
| 00:55.23 | ds2 | let me check |
| 00:56.27 | *** join/#edev bbradley (n=bbradley@78-105-167-16.zone3.bethere.co.uk) |
| 00:57.59 | ds2 | Hmmm for the kernel, they don't have a -mtune |
| 00:58.35 | ds2 | -march=armv7a |
| 00:59.17 | ds2 | btw, if you need to use the CS code base, 2007q3 version... the later CS stuff have bugs and the stock GNU stuff doesn't have all the ARMv7 stuff merged in |
| 01:00.38 | solar | I'm just passing the info along to another guy who has what he claims is a beagle alike board. But not the beagle |
| 01:01.05 | solar | as far as omap I'm only working on the omap850 |
| 01:04.58 | ds2 | Overo? |
| 01:04.59 | ds2 | :) |
| 01:06.17 | solar | More or less this device http://www.htc.com/us/product.aspx?id=10960 |
| 01:08.24 | solar | ds2: the omap3 Know if thats softfloat ? |
| 01:18.09 | *** join/#edev kergoth (n=kergoth@ip72-201-11-30.ph.ph.cox.net) |
| 01:31.29 | ds2 | solar: that I donno... |
| 01:31.38 | ds2 | I think the EABI stuff has something to do with it |
| 01:40.11 | solar | looks like ppl are supposed to stop using -march=armv7a and start using -march=armv7-a with >gcc-4.3 |
| 01:40.54 | ds2 | are they doing that as part of the merge back into the gnu code? |
| 01:43.07 | *** join/#edev kergoth (n=kergoth@ip72-201-11-30.ph.ph.cox.net) |
| 01:43.11 | solar | Aparently -march=armv7a is a CSL-ism while CSL compilers are supposed to understand both armv7a and armv7-a |
| 01:44.20 | solar | will suggest the guy try armv7a-softfloat-linux-gnueabi |
| 01:46.31 | solar | well this gets odder |
| 01:47.54 | solar | oh I see. |
| 01:48.19 | ds2 | right but AFAIK, there are no other compiler that work for armv7 besides the CS stuff |
| 01:48.21 | solar | uboot suggests using armv5 |
| 01:49.46 | solar | here we go. Seems the armv7a-angstrom-linux-gnueabi exists. |
| 01:50.37 | ds2 | any particular reason you are rebuilding it? |
| 01:50.51 | ds2 | other then gentoo is a purist system? :) |
| 01:51.09 | solar | rebuilding? |
| 01:51.19 | ds2 | yeah... you can download CS binaries |
| 01:51.27 | solar | haha |
| 01:51.29 | solar | never. |
| 01:51.42 | solar | CS I'd like to have some words with how they do toolchains |
| 01:51.50 | ds2 | okay so it is a purity thing |
| 01:52.24 | solar | it's just how we do things. Our toolchain does things others dont. The paths we put stuff in. The ease of how things just work. |
| 01:53.24 | solar | plus.. it's fwd movement vs waiting for 3rd party always |
| 01:53.29 | ds2 | I'm not looking down on it... it is just to build it right, it takes some special toolchain magic |
| 01:53.52 | ds2 | <-- not a toolchain guy |
| 01:54.11 | solar | oh. Yeah if it reqires patches which vapier has not added to our tree I'll tell me to go the armv5 route. |
| 01:54.37 | solar | using this as a ref http://markmail.org/message/pe2s3tmnp6ptjlvg#query:armv7a-+page:1+mid:uoswcoudtcnguk37+state:results |
| 02:15.41 | ds2 | know if you will get at least a sample unit before hand to make sure everything works ? |
| 02:15.43 | ds2 | bah |
| 02:17.32 | solar | misfire? |
| 02:17.41 | ds2 | *nod* |
| 03:15.49 | ds2 | wheee video uploaded |
| 03:18.02 | solar | to your /projects/ page? |
| 03:18.51 | ds2 | no bandwidth so I have it on youtube instead... I link to it from the top page |
| 03:58.54 | *** join/#edev DrZimmerman (n=theo@77-56-228-246.dclient.hispeed.ch) |
| 05:04.25 | *** join/#edev kergoth_ (n=kergoth@ip72-201-11-30.ph.ph.cox.net) |
| 05:06.18 | *** join/#edev kergoth_ (n=kergoth@ip72-201-11-30.ph.ph.cox.net) |
| 05:26.54 | *** join/#edev davidc__ (n=davidc__@S01060002b360aacd.vc.shawcable.net) |
| 05:51.20 | *** join/#edev harpal (n=Harpal@122.169.108.195) |
| 05:53.57 | *** join/#edev landley (n=landley@cpe-70-116-30-223.austin.res.rr.com) |
| 05:53.57 | *** mode/#edev [+o landley] by ChanServ |
| 06:02.07 | *** join/#edev lyakh (n=lyakh@p57BD2695.dip0.t-ipconnect.de) |
| 06:31.46 | *** join/#edev redblue (i=star@ppp027.108-253-207.mtl.mt.videotron.ca) |
| 06:54.54 | *** join/#edev boris_OmegA (n=boris@194.51.141.172) |
| 07:06.28 | methril | yo |
| 07:10.32 | landley | waves at methril. |
| 07:11.51 | methril | :D |
| 07:43.45 | *** join/#edev [AD]Turbo (n=turbo@host60-241-dynamic.27-79-r.retail.telecomitalia.it) |
| 07:47.35 | [AD]Turbo | hi all |
| 07:52.36 | *** join/#edev hw__ (n=hw@p578b3905.dip0.t-ipconnect.de) |
| 08:13.34 | *** join/#edev linac (n=lin@124.21.247.231) |
| 08:24.20 | *** join/#edev lifeeth (n=Praneeth@unaffiliated/lifeeth) |
| 08:59.32 | *** join/#edev miknix (n=miknix@gentoo/developer/miknix) |
| 09:43.27 | *** join/#edev gcl_ (n=gcl@S01060016b61d1226.cg.shawcable.net) |
| 10:29.24 | *** join/#edev lyakh (n=lyakh@p57BD2695.dip0.t-ipconnect.de) |
| 11:01.22 | *** join/#edev dijenerate (n=dijenera@72.51.107.250) |
| 11:07.54 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 11:42.18 | *** join/#edev g1powermac (n=g1powerm@unaffiliated/g1powermac) |
| 12:52.32 | *** join/#edev mbuf (n=user@61.16.248.242) |
| 12:59.47 | *** join/#edev Crofton (n=balister@12.234.232.66) |
| 13:33.55 | *** join/#edev GPSFan (n=kenm@64.92.145.112) |
| 13:33.55 | *** mode/#edev [+o GPSFan] by ChanServ |
| 13:36.17 | *** join/#edev prpplague (n=dave@mail.americanmicrosystems.com) |
| 13:45.25 | *** join/#edev davidc__ (n=davidc__@S01060002b360aacd.vc.shawcable.net) |
| 13:59.39 | *** join/#edev kergoth (n=kergoth@ip72-201-11-30.ph.ph.cox.net) |
| 14:04.22 | *** join/#edev davidc__ (n=davidc__@S01060002b360aacd.vc.shawcable.net) |
| 14:17.37 | *** join/#edev chouimat|work (n=dieu@209.217.106.98) |
| 14:40.19 | MothaWork | anybody by chance ever worked with i.MX? |
| 14:40.26 | MothaWork | and, even less likely, used WinCE on them? |
| 14:47.26 | *** join/#edev kergoth (n=kergoth@65.200.49.156) |
| 14:53.46 | *** join/#edev CosmicPenguin (n=nobody@163.181.251.103) |
| 14:53.47 | *** mode/#edev [+o CosmicPenguin] by ChanServ |
| 14:56.03 | *** join/#edev kergoth_ (n=kergoth@65.200.49.156) |
| 14:58.34 | chouimat|work | morning |
| 15:32.22 | prpplague | lordy lordy |
| 15:32.28 | chouimat|work | ? |
| 15:32.31 | prpplague | still hasn't figured out this audio codec issue |
| 15:33.44 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 15:34.30 | CosmicPenguin | http://gizmodo.com/5066955/intel-arm-is-fat-ugly-responsible-for-all-of-iphones-problems |
| 15:34.33 | CosmicPenguin | Fight! fight! |
| 15:35.26 | kergoth_ | rolls eyes |
| 15:35.28 | kergoth_ | idiots |
| 15:37.49 | prpplague | bangs head on desk |
| 15:37.55 | prpplague | this _should_ work |
| 15:40.57 | MothaWork | CosmicPenguin: woah |
| 15:41.19 | MothaWork | the classic Intel solution: throw more CPU time at it |
| 15:42.46 | CosmicPenguin | careful there - that mindset keeps me in doughnuts |
| 15:42.49 | CosmicPenguin | mmmm.... doughnuts |
| 15:42.55 | chouimat|work | wow I'm impressed .. |
| 15:49.38 | chouimat|work | ... but the comments :) |
| 15:49.42 | chouimat|work | s/but/by |
| 16:45.31 | prpplague | this is the most difficult bug i've ever run across |
| 16:54.08 | wmat | prpplague: blame the hardware ;) |
| 16:55.01 | prpplague | wmat: doesn't help getting it fixed |
| 17:09.25 | wmat | prpplague: no, but it makes me feel better when I do it ;) |
| 17:13.32 | ds2 | try doing something completely different and forget about this bug for a day or two then come back |
| 17:13.56 | prpplague | ds2: already tried that, hehe |
| 17:14.00 | ds2 | oh |
| 17:14.22 | ds2 | prpplague: what is the current problem? |
| 17:14.35 | prpplague | ds2: same as before |
| 17:14.49 | prpplague | ds2: getting duplicated data for the first and last periods |
| 17:15.10 | ds2 | thought that was a DMA bug you found? |
| 17:15.48 | prpplague | haven't found any dma bugs as of yet |
| 17:15.58 | ds2 | you mentioned something about DMA the other day |
| 17:16.12 | prpplague | ds2: just that i suspected that is where the problem is |
| 17:16.20 | ds2 | I wonder if it is worthwhile to see if it works okay in PIO mode? |
| 17:16.37 | prpplague | ds2: the driver doesn't support pio |
| 17:17.42 | ds2 | how is it arranged on the Samsungs.... is there a hardware serial port then an ALSA layer that uses that? |
| 17:18.08 | prpplague | ds2: yea standard i2s controller |
| 17:19.06 | ds2 | I donno what is a "standard" I2S controller. On the OMAP's, there is a semi universial sync serial port called the McBSP that can put out I2S formatted streams |
| 17:19.43 | MothaWork | that's what AT91 does, too, though some AT91s also have AC97 |
| 17:20.58 | ds2 | the AT91 has a universal sync port too? |
| 17:21.06 | MothaWork | ds2: yes. They call it the SSC |
| 17:21.21 | MothaWork | it can do I2S, SPI, various codec protocols, and some other stuff |
| 17:21.36 | MothaWork | I haven't really looked into using it since I haven't had a need. The AT91 we used also has AC97 |
| 17:21.42 | MothaWork | though our board has no audio at all |
| 17:24.22 | *** join/#edev lyakh (n=lyakh@p57BD2695.dip0.t-ipconnect.de) |
| 17:33.15 | ds2 | MothaWork: that sounds somewhat like the one on the AVR |
| 17:36.14 | *** join/#edev Ei5GTB_ (n=Paul@78.16.93.102) |
| 17:45.51 | wmat | prpplague: is the bug report online somewhere? |
| 17:45.51 | prpplague | wmat: no |
| 17:45.56 | prpplague | wmat: we are the only ones using this combination of hardware |
| 17:46.50 | wmat | prpplague: what codec? |
| 17:47.01 | MothaWork | ds2: it probably is on AVR32 |
| 17:47.06 | MothaWork | AVR32 and AT91 share a bunch of peripherals |
| 17:47.35 | MothaWork | there's something on 8-bit AVR called the USI that is similar, but has much more software overhead (it's basically a shift register with a bunch of software control) |
| 17:47.51 | MothaWork | I guess xmega and some bigger AVR might have SSC |
| 17:48.39 | prpplague | wmat: wm8750 |
| 17:56.41 | ds2 | prpplague: how do you know it is being duplicated? |
| 17:57.18 | prpplague | ds2: 1) i can hear it, 2) i can see it on the scope |
| 17:58.43 | ds2 | prpplague: Hmmm.... so am I correct in saying that the WM side sent too many clocks before toggling L/R? |
| 17:59.42 | ds2 | let me rephase... it sent too many clocks before a change in L/R is recogonized by the S3C side |
| 18:02.13 | prpplague | ds2: everything looks correct |
| 18:02.57 | ds2 | prpplague: if that is the case, I would suspect maybe the S3C side is only looking at either a falling or a rising edge instead of both or just the level |
| 18:03.21 | ds2 | looking at just one edge would match what you described |
| 18:04.25 | prpplague | yea, i've tried every combination |
| 18:05.44 | ds2 | could it be an order thing, i.e. maybe it ignores your change if there is anything active? |
| 18:08.35 | prpplague | yea thought about that too |
| 18:10.33 | ds2 | could it be ALSA doing stuff to you? |
| 18:10.59 | ds2 | i.e. your driver report to ALSA a rate and somehow ALSA thinks it needs to double the number of samples to match what your driver needs |
| 18:21.04 | kergoth | hmm |
| 18:21.55 | prpplague | ds2: yea, checked that too, everything looks correct, all the rates match up |
| 18:22.44 | ds2 | prpplague: try hard coding a loop in your driver that sends out a tone? i.e something that just ignores ALSA and only sends your stuff |
| 18:23.06 | ds2 | that was handy on the OMAP... would have been nice it it didn't needed to be fixed first |
| 18:42.29 | prpplague | is getting totally frustrated with this |
| 19:17.35 | *** join/#edev roxfan (n=dunno@83.172-243-81.adsl-dyn.isp.belgacom.be) |
| 19:51.17 | *** join/#edev redblue (i=star@ppp145.108-253-207.mtl.mt.videotron.ca) |
| 19:52.12 | *** join/#edev landley (n=landley@adsl-76-197-33-46.dsl.austtx.sbcglobal.net) |
| 19:52.12 | *** mode/#edev [+o landley] by ChanServ |
| 20:13.22 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 20:24.34 | *** join/#edev echelon (n=echelon@ool-182cc7a4.dyn.optonline.net) |
| 20:25.00 | echelon | hi |
| 20:26.03 | *** join/#edev zach1 (n=zachb@c-71-192-250-122.hsd1.ma.comcast.net) |
| 20:31.05 | landley | waves at echelon. |
| 20:31.13 | echelon | :) |
| 20:31.22 | echelon | you guys use buildroot? |
| 20:32.04 | landley | I've used it before. |
| 20:32.17 | landley | Several people on here use buildroot extensively. |
| 20:33.12 | echelon | cool, i had some basic questsions about it that i can't find in the docs for some reason.. ie.. how to build a package in the package/ |
| 20:33.24 | echelon | just go into their dir and run make? |
| 20:33.42 | landley | You mean build an individual package? |
| 20:34.05 | echelon | yeah |
| 20:34.40 | landley | I know you can build those packages standalone, I forget quite how. I think you do "make -f makefile" or some such. |
| 20:35.08 | landley | You might need to do that from the top level directory, I'm not sure. |
| 20:35.10 | landley | Play with it. |
| 20:35.48 | echelon | hrm, so i guess that's the non-standard way of doing it? |
| 20:36.21 | landley | If it works reliably, it's probably fairly standard. |
| 20:36.36 | landley | They might not have bothered to _document_ it, but I believe -f makefile should work. |
| 20:36.41 | landley | I note I haven't tried it recently... |
| 20:36.46 | echelon | k |
| 20:37.11 | landley | hey prpplague: am I at all correct here? |
| 20:37.12 | MothaWork | hum, now that people are active, anybody played with i.MX before? I'm wondering if their BSPs are of usable quality. WinCE support would be nice, too (sadly). |
| 20:37.14 | echelon | also, i noticed that in wireless-tools, iwlist is just linked to iwconfig |
| 20:37.35 | landley | echelon: that could easily be correct. |
| 20:37.41 | prpplague | looks in |
| 20:37.48 | landley | Some programs figure out what behavior they should have based on what name they're called as. |
| 20:37.56 | landley | Busybox is a prime example, but gzip does the same. |
| 20:38.00 | echelon | cool |
| 20:38.07 | landley | gunzip is the same as gzip -d |
| 20:38.34 | landley | In C, you look at argv[0] to figure this out. |
| 20:39.42 | prpplague | echelon: you should be able to just type: make nameofpackage |
| 20:39.54 | prpplague | echelon: where nameofpackage is the app you want to build |
| 20:40.09 | echelon | so iwlist is just built into iwconfig for the buildroot then? |
| 20:40.15 | echelon | prpplague: thanks! :) |
| 20:40.16 | prpplague | landley: leapfrog coughed up some kernel source this week |
| 20:40.28 | echelon | prpplague: from the root directory? |
| 20:40.37 | prpplague | echelon: iwlist and iwconfig are part of wireless utils |
| 20:40.39 | prpplague | echelon: yea |
| 20:40.39 | landley | prpplague: wootage! |
| 20:40.43 | landley | Congratulations! |
| 20:40.53 | echelon | lol, you're working with leapfrog? |
| 20:41.18 | landley | echelon: no, he was trying to beat gpl source out of them for a product they'd already shipped. |
| 20:41.21 | prpplague | echelon: no, harrasing them about GPL violations |
| 20:41.34 | prpplague | echelon: make wireless-tools |
| 20:41.38 | landley | The SFLC comes through again. :) |
| 20:42.34 | echelon | prpplague: from the root buildroot directory? |
| 20:43.24 | prpplague | echelon: yep |
| 20:43.35 | prpplague | echelon: assuming you've built the toolchain and such |
| 20:43.48 | echelon | yeah, thanks again :) |
| 20:45.34 | prpplague | np |
| 20:59.55 | echelon | make: *** No rule to make target `wireless_tools'. Stop. |
| 21:01.02 | echelon | same with wireless-tools |
| 21:02.01 | prpplague | wireless-tools |
| 21:02.08 | echelon | yeah, same |
| 21:02.21 | prpplague | echelon: sounds like you have something broken |
| 21:02.28 | echelon | make: Nothing to be done for `wireless-tools'. |
| 21:02.30 | echelon | oh |
| 21:02.35 | echelon | nothing to be done |
| 21:02.43 | prpplague | echelon: that means it is already built |
| 21:02.51 | echelon | heh |
| 21:03.02 | echelon | so how does the packaging system work? |
| 21:03.09 | echelon | or do i just copy over the binaries? |
| 21:04.11 | prpplague | echelon: normally if you build it, it gets put into your root image |
| 21:04.23 | prpplague | echelon: there isn't any real "packaging" with buildroot |
| 21:05.05 | echelon | i see.. i have to check how my device does it |
| 21:05.17 | echelon | i thought maybe it used ipkg |
| 21:06.37 | *** join/#edev sunrunner20|prom (n=jamesdoe@pool-71-123-227-217.dllstx.fios.verizon.net) |
| 21:12.31 | echelon | have you guys used tinyx? |
| 21:13.09 | CosmicPenguin | These days we call it 'kdrive' |
| 21:13.55 | echelon | yeah, i know.. but buildroot seems to only have a package for tinyx and tinyx-old |
| 21:14.07 | ds2 | is it still called Kdrive after the commit to Xorg? |
| 21:16.15 | CosmicPenguin | <PROTECTED> |
| 21:16.16 | CosmicPenguin | dmx kdrive Makefile.am vfb xfree86xnest xquartzxwin |
| 21:16.21 | CosmicPenguin | yes... :) |
| 21:16.57 | prpplague | echelon: kdrive/tinyx isn't very well supported in buildroot, buildroot generally are for devices that are headless or have custom fb applications |
| 21:17.33 | echelon | oh, mine has lcd/keyboard, etc |
| 21:18.26 | kergoth | might want to look into something like oe instead, echelon |
| 21:18.29 | prpplague | echelon: might consider using something like OE or poky |
| 21:18.31 | kergoth | what are you looking to do with it? |
| 21:19.28 | echelon | i tried oe, but the guys maintaining the project haven't updated in a while, so all the oe stuff is broken |
| 21:19.38 | kergoth | what? |
| 21:19.47 | kergoth | there are tons of commits every day |
| 21:19.49 | echelon | and it links to glibc |
| 21:19.57 | kergoth | it has glibc and uclibc, last time i looked |
| 21:20.05 | echelon | kergoth: i meant for the project for my device |
| 21:20.43 | kergoth | what device? |
| 21:20.59 | echelon | http://www.openzipit.org/ .. the z2 |
| 21:21.35 | ds2 | always Gentoo Embedded |
| 21:21.41 | echelon | huh? |
| 21:22.18 | CosmicPenguin | Of all the componaits, "OE doesn't update enough" isn't one I've heard |
| 21:22.21 | CosmicPenguin | complaints even |
| 21:22.27 | kergoth | heh, generally exactly the opposite |
| 21:22.49 | echelon | CosmicPenguin: i didn't say oe doesn't update enough.. i said my project maintainer doesn't update whenever there is an oe update |
| 21:22.54 | prpplague | echelon: the z2 has been pretty much dead since the zipit folks put out their very restricted license agreements |
| 21:23.12 | CosmicPenguin | Thats what you get for depending on a distribution |
| 21:23.16 | echelon | really? i've never heard about this |
| 21:24.25 | prpplague | echelon: i was the one who found the jtag and uarts pads |
| 21:24.34 | echelon | cool :D |
| 21:24.59 | kergoth | project maintainer? either there's a machine conf file in the upstream oe repository, or you're using someone's private oe metadata repo. you'd be better off with the former |
| 21:25.24 | kergoth | glares at the clock |
| 21:26.15 | echelon | so what's wrong with the license? |
| 21:32.19 | *** join/#edev sunrunner20 (n=jamesdoe@pool-71-123-184-114.dllstx.fios.verizon.net) |
| 21:33.53 | prpplague | echelon: you can't share any of the information |
| 21:34.02 | echelon | like? |
| 21:34.06 | prpplague | kergoth: iirc GPSFan is the one maintaining |
| 21:34.23 | prpplague | echelon: pinouts, memory locations, register values |
| 21:35.03 | echelon | well it's not so much of a problem with me |
| 21:36.03 | echelon | eh.. i just scp'ed iwconfig over to the z2 in /sbin/.. now when i enter iwconfig, i get this.. -sh: iwconfig: not found |
| 21:36.27 | solar | FYI. kdrive is on it's last leg. The upstream guy named Keith.*something* is doing away with kdrive officially and telling ppl to use minimal xorg setups. |
| 21:36.28 | echelon | even though it auto-completes iwconfig |
| 21:37.02 | solar | till then it's quite tasty |
| 21:37.06 | CosmicPenguin | solar: that same Keith is the 'k' in kdrive |
| 21:37.14 | CosmicPenguin | solar: it is important to remember who he works for |
| 21:37.25 | solar | i don't know alot of the details. |
| 21:37.32 | solar | sees what he can dig up |
| 21:37.38 | prpplague | echelon: that means that the iwconfig you compiled doesn't match the libraries that the are on the x2 already |
| 21:37.55 | ds2 | <PROTECTED> |
| 21:37.56 | ds2 | ;) |
| 21:38.05 | CosmicPenguin | solar: http://en.wikipedia.org/wiki/Keith_Packard |
| 21:38.20 | echelon | hrm |
| 21:38.29 | echelon | so how do i rebuild it? |
| 21:38.39 | ds2 | CosmicPenguin: any relations to the company Carla ruined? |
| 21:38.48 | CosmicPenguin | Direct relation |
| 21:39.07 | prpplague | echelon: you'll have to hand edit the makefile the build |
| 21:39.22 | prpplague | echelon: what are you trying to do? |
| 21:39.57 | echelon | trying to install iwconfig on the z2? |
| 21:40.08 | prpplague | echelon: for what purpose? to setup wifi? |
| 21:40.13 | echelon | yeah |
| 21:40.15 | kergoth | http://www.facebook.com/group.php?gid=44868280344 |
| 21:40.51 | prpplague | echelon: there is a reason that wireless-tools aren't on the build, there is no open source gspi support for the marvell chipset at the moment |
| 21:41.05 | *** join/#edev miknix (n=miknix@gentoo/developer/miknix) |
| 21:41.13 | prpplague | miknix: greetings |
| 21:41.25 | miknix | hello prpplague |
| 21:41.47 | echelon | ah! |
| 21:42.12 | echelon | but how does wpa_supplicant work? |
| 21:43.11 | prpplague | echelon: it shouldn't if you'd a fresh build of the firmware |
| 21:45.09 | echelon | so iwconfig should work? |
| 21:46.25 | solar | wonders if echelon missed the part/logic to why wireless-tools was not included in the build. |
| 21:46.26 | echelon | probably |
| 21:46.33 | solar | scroll to 6mins ago |
| 21:47.34 | echelon | so i can associate the card to an ap using wpa_supplicant, but not iwconfig? |
| 21:49.36 | solar | CosmicPenguin: I think I might of talked to that guy at the beerforge @ OSCON this year. |
| 21:53.00 | *** join/#edev sunrunner20|prom (n=jamesdoe@pool-71-123-227-217.dllstx.fios.verizon.net) |
| 21:55.04 | prpplague | echelon: are you using the default firmware or did you build a new firmware image? |
| 21:55.15 | echelon | prpplague: default |
| 21:55.25 | echelon | i'm using the shell hack |
| 21:55.58 | prpplague | echelon: then you should be able to build static version of iwconfig and iwlist to use on the device |
| 21:56.14 | echelon | thanks :) |
| 21:56.17 | echelon | so that's the only problem |
| 21:57.12 | *** join/#edev CosmicPenguin (n=nobody@163.181.251.103) |
| 21:57.12 | *** mode/#edev [+o CosmicPenguin] by ChanServ |
| 21:58.36 | ds2 | so it has come down to my silly hack suggestion of -static... |
| 22:01.06 | *** join/#edev irotas (n=irotas@CPE00131042e14d-CM0018c0b37a44.cpe.net.cable.rogers.com) |
| 22:01.17 | echelon | so how do i clean the iwconfig build, since it doesn't let me do 'make wireless-tools' |
| 22:01.24 | *** part/#edev irotas (n=irotas@CPE00131042e14d-CM0018c0b37a44.cpe.net.cable.rogers.com) |
| 22:01.44 | echelon | ah.. -dirclean |
| 22:04.32 | *** join/#edev sunrunner20 (n=jamesdoe@pool-71-170-40-107.dllstx.fios.verizon.net) |
| 22:05.01 | ds2 | can anyone think of a reason why I cannot do 25 PAN connections on the hammer with a bluetooth USB dongle |
| 22:12.36 | prpplague | ds2: not enough end points |
| 22:13.03 | ds2 | prpplague: each pan connection uses a separate endpoint? |
| 22:13.05 | ds2 | sigh |
| 22:13.35 | prpplague | ds2: that is my understanding |
| 22:13.47 | ds2 | prpplague: know of a quick way to dump the number of endpoints used? |
| 22:14.23 | prpplague | sorry no |
| 22:14.36 | ds2 | oh boy this is going to be a fun 48 hours then |
| 22:15.28 | ds2 | prpplague: how many ep's do I have on the hammer? |
| 22:15.46 | prpplague | ds2: iirc 4 |
| 22:16.07 | ds2 | okay, I can find 5 other devices to test it |
| 22:31.05 | echelon | ds2: $(MAKE) -C $(WIRELESS_TOOLS_BUILD_DIR) CC=$(TARGET_CC) CFLAGS="$(TARGET_CFLAGS)" LDFLAGS=-all-static iwmulticall ? |
| 22:32.16 | ds2 | <PROTECTED> |
| 22:32.40 | echelon | during make or configure? |
| 22:33.19 | ds2 | uh... make I guess |
| 22:33.29 | ds2 | bottom line is ld or gcc needs to be called with -static |
| 22:34.36 | echelon | merci! :D |
| 22:35.09 | echelon | now i can build wavemon |
| 22:38.01 | echelon | hrmph.. card doesn't support scanning |
| 22:38.33 | echelon | oops.. wrong interface |
| 22:47.01 | miknix | is there someone owning a neo freerunner? |
| 22:47.56 | ds2 | it ran away ;) |
| 22:48.16 | CosmicPenguin | don't quit your day job |
| 22:50.32 | miknix | lol |
| 22:51.19 | miknix | I'm thinking in buying one but I read somewhere it shares the vga adapter bus with some other peripheral |
| 22:59.35 | miknix | http://www.craveonline.com/articles/gear/04650868/openmoko_freerunner.html |
| 23:00.11 | miknix | too bad to see a opengl capable chipset located on a shared bus with the sd host controller : \ |
| 23:29.15 | *** join/#edev roxfan2 (n=dunno@83.172-243-81.adsl-dyn.isp.belgacom.be) |
| 23:30.28 | *** join/#edev prpplague (n=prpplagu@ppp-70-244-162-142.dsl.rcsntx.swbell.net) |
| 23:30.39 | solar | build it. Dont buy it |
| 23:31.56 | prpplague | solar: does that apply to strippers? |
| 23:32.53 | prpplague | solar: whats the word on the gui build? |
| 23:34.38 | prpplague | is exhausted |
| 23:34.51 | prpplague | i've been burning the candle at both ends |
| 23:39.49 | prpplague | landley: whats been cookin lately? |
| 23:39.56 | prpplague | landley: haven;t seen you around much |
| 23:40.10 | prpplague | landley: some head hunter emailed me |
| 23:40.14 | prpplague | landley: from the austin area |
| 23:40.23 | prpplague | landley: mentioned your name |
| 23:42.12 | prpplague | doh |
| 23:53.38 | joe_bleau | prpplague: ping |
| 23:54.04 | joe_bleau | prpplague: been thinking on your comment about Diji being dead by summer |
| 23:54.16 | prpplague | joe_bleau: yea? |
| 23:54.23 | joe_bleau | prpplague: and it reminds me of the juicebox--I don't think there was much interest in that hack |
| 23:54.31 | joe_bleau | until it was discontinued and discounted. |
| 23:54.44 | joe_bleau | Maybe the best thing would be for them to kill it off |
| 23:54.51 | joe_bleau | and the hackers can pick 'em up cheap. |
| 23:55.03 | prpplague | joe_bleau: indeed |
| 23:55.09 | joe_bleau | If there's not a big selection of carts, no demand. |
| 23:56.01 | joe_bleau | There, I feel better now. Thanks. |
| 23:56.02 | miknix | solar, hey, how's your hangover? |
| 23:56.30 | solar | I've not had a chance to start tmws hangover yet |
| 23:58.05 | *** join/#edev kergoth (n=kergoth@ip72-201-11-30.ph.ph.cox.net) |
| 23:58.36 | ds2 | procrastinating? :) |
| 23:59.23 | solar | still got a bit of work to accomplish |