• [00:00:30] <jkridner|work> time for Sunday night hockey!
  • [00:00:42] <jkridner|work> hockey twice in one weekend! yea!
  • [00:00:54] * koen notices it's 2 am
  • [00:02:42] <sakoman_> good night koen :-)
  • [00:03:59] <vlad_> jkridner|work: there's hockey?
  • [00:04:14] <jkridner> playing, not watching.
  • [00:04:21] <vlad_> ah!
  • [00:04:27] <jkridner> also, I play roller, so not "real" hockey.
  • [00:04:37] <jkridner> g'night all
  • [00:18:47] * NishanthMenon (n=Nishanth@cpe-24-27-74-89.tx.res.rr.com) has joined #beagle
  • [00:19:05] * NishanthM (n=Nishanth@cpe-24-27-74-89.tx.res.rr.com) Quit (Read error: 110 (Connection timed out))
  • [00:23:11] * JoeyBorn (n=jborn@adsl-75-2-248-175.dsl.chcgil.sbcglobal.net) Quit ("Bears v Colts season opener")
  • [00:43:20] * jrmuizel (n=jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) Quit (Remote closed the connection)
  • [00:57:00] * nooomem (n=chatzill@ip68-100-201-32.dc.dc.cox.net) Quit ("ChatZilla 0.9.83 [Firefox 3.0.1/2008070208]")
  • [01:21:14] * NishanthM (n=Nishanth@cpe-24-27-74-89.tx.res.rr.com) has joined #beagle
  • [01:23:11] * NishanthMenon (n=Nishanth@cpe-24-27-74-89.tx.res.rr.com) Quit (Read error: 110 (Connection timed out))
  • [01:59:28] * prpplague (n=dave123_@ppp-70-244-162-73.dsl.rcsntx.swbell.net) has joined #beagle
  • [02:10:21] * watermark (n=eli@c-24-18-27-243.hsd1.wa.comcast.net) has joined #beagle
  • [02:26:44] * NishanthMenon (n=Nishanth@cpe-24-27-74-89.tx.res.rr.com) has joined #beagle
  • [02:27:40] * NishanthM (n=Nishanth@cpe-24-27-74-89.tx.res.rr.com) Quit (Read error: 110 (Connection timed out))
  • [02:39:21] * jrmuizel (n=jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) has joined #beagle
  • [03:01:03] <jkridner> whoa. OS X actually built console-image using OE.
  • [03:01:24] <jkridner> I got the debugger up, but didn't need it apparently.
  • [03:01:33] <jkridner> not that I'd know where to put the breakpoints anyway.
  • [03:01:48] * NishanthM (n=Nishanth@cpe-24-27-74-89.tx.res.rr.com) has joined #beagle
  • [03:04:01] <jkridner> wait, this makes no sense.... http://tinderbox.openembedded.net/builds/29316/
  • [03:04:18] <jkridner> why would it say 'succeeded' if so many packages didn't build.
  • [03:04:43] <jkridner> hmmm, images/beagleboard directory is empty. :(
  • [03:08:49] <ds2> there is ice in TX for hockey?
  • [03:09:00] * ds2 prepares to watch out for falling beacon from the sky ;)
  • [03:09:37] <prpplague> jkridner made some progress this weekend on jtag for the beagle
  • [03:10:56] <jkridner> ds2: I play roller hockey. yes, we do manage to keep some ice frozen indoors. Houston should be well known by the power of our air conditioners. lot's of oil to burn to run them.
  • [03:11:06] <jkridner> prpplague: great!
  • [03:11:14] <ds2> =)
  • [03:12:27] * NishanthMenon (n=Nishanth@cpe-24-27-74-89.tx.res.rr.com) Quit (Read error: 110 (Connection timed out))
  • [03:13:31] <prpplague> jkridner i was able to manually add the scan chain to the JRC and query the arm core
  • [03:13:55] <prpplague> jkridner is there any additional information about the JRC that TI uses in the omap?
  • [03:14:08] <ds2> btw, in case anyone else is also considering it, attempting a daughter board on top of the beagle does not work out well... looks like the daughter board has to be on the bottom or sit off board via a short ribbon cable :/
  • [03:14:11] <jkridner> what is "JRC"?
  • [03:14:34] <ds2> JTAG Resource Controller maybe?
  • [03:14:44] <prpplague> JTAG Route Controller, i think the doc you provided also refers to it as a TAP Router
  • [03:15:07] <jkridner> ds2: or tall connectors or not go over much of the board.
  • [03:15:27] <ds2> jkridner: then you loose access to the JTAG pins
  • [03:15:38] <jkridner> k. I believe it is called "ICE Pick" internally. but I understand what you mean by TAP Router.
  • [03:15:49] <ds2> the jtag pins + the HDMI connector's mounting flange restrict things
  • [03:16:00] <jkridner> ds2: exactly. so aim your daughter-board away.
  • [03:16:35] <jkridner> the first protos were made with the connectors on top, but I like them on bottom for the purpose of clearing the connectors... but then you can't set the board down without tall stand-offs.
  • [03:16:51] <jkridner> easy answer was to leave the connector off, since you'd have to solder anyway.
  • [03:16:51] <ds2> jkrider: the HDMI mounting flange makes it tricky to do that unless I route my board off so there is a tab just as wide as the header
  • [03:17:06] <jkridner> the micrel ethernet board pics I saw just use wires soldered.
  • [03:17:24] * chase_ (n=chase@d75-152-103-96.abhsia.telus.net) Quit (Read error: 113 (No route to host))
  • [03:17:30] <jkridner> newer boards don't have the flange, but it'd still be in the way.
  • [03:17:56] <prpplague> jkridner yea sorry i tend to use the base name for device rather than the marketing name, hehe
  • [03:18:32] <ds2> besides, the connectors metal top would require me to keep a layer of polymide tap on the bottom for insulation...tall stand offs work when one has access to a lathe to make custom standoffs ;)
  • [03:18:39] <prpplague> jkridner i'm curious why the omap3 stuff didn't follow the same pattern with usage of the emu0/emu1 features
  • [03:18:52] <jkridner> as? davinci?
  • [03:18:56] <prpplague> yea
  • [03:19:42] <jkridner> different groups with different histories.
  • [03:19:45] <ds2> maybe it is an artifact of the davinci vs OMAP evolution
  • [03:19:57] <prpplague> requiring usage of the JRC adds a large amount complexity for smaller jtag applications like openocd
  • [03:20:07] <prpplague> ds2 thats possible
  • [03:20:33] <ds2> prpplague: once you have that working, I would be curious to try and see if it works on the 2420 (N800)
  • [03:20:45] <prpplague> currently the openocd design is based on a framework of having all available jtag chains connected on initial startup of the openocd system
  • [03:21:21] <prpplague> if you look at the bdi log, there system originally works in the same manner
  • [03:21:54] <ds2> the N800 has no well known way of recovering if one screws up NoLo (equip of X-Loader, AFAIKI)
  • [03:21:55] <prpplague> however for the omap3 stuff, the initial startup is bypassed inorder to add the additional items to the scanchain
  • [03:22:35] <ds2> prpplague: the OMAP can't be the only thing that requires that... maybe it is a useful to to add a hook to provide for this early config'ing?
  • [03:23:38] <prpplague> indeed, it is not the only that has that feature, but it is the only one that doesn't provide an option to bypass the JRC and connect the arm directly to the jtag
  • [03:23:50] <prpplague> ds2 yes, i've already started working on that
  • [03:24:04] <prpplague> short paste
  • [03:24:08] <prpplague> - TARGET: processing reset request
  • [03:24:08] <prpplague> - TARGET: BDI executes scan chain init string
  • [03:24:08] <prpplague> - TARGET: Bypass check 0x00000001 => 0x00000002
  • [03:24:08] <prpplague> - TARGET: JTAG exists check passed
  • [03:24:12] * jrmuizel (n=jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) Quit ()
  • [03:24:24] <prpplague> you can see the BDI config bupasses the initial check
  • [03:24:34] <prpplague> so that it can add the scanchain items later
  • [03:25:58] <prpplague> ds2 basically need a flag in the openocd .cfg file that indicates that the initial checks are to be bypassed and that the JRC needs to be initialized using a specified script
  • [03:26:01] <jkridner> what else do you want to do with the TAP router besides put the ARM in the chain?
  • [03:26:24] <jkridner> back after a bit
  • [03:26:45] <prpplague> jkridner thats basically it, but i'd like to know more about how the data is passed to the arm core
  • [03:27:17] <prpplague> jkridner mainly to make sure that the JRC isn't blocking or filters specific aspects of the jtag
  • [03:34:04] <geist> trying to get a bdi working on the omap3530?
  • [03:34:16] <geist> I have a working .cfg file for 3430, should be the same
  • [03:36:37] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) Quit (Read error: 104 (Connection reset by peer))
  • [03:36:51] <geist> guess not, looks like it's working for you anyway
  • [03:38:27] * feig (n=ejf3@c-76-118-153-30.hsd1.ma.comcast.net) Quit (Remote closed the connection)
  • [03:39:02] * feig (n=ejf3@c-76-118-153-30.hsd1.ma.comcast.net) has joined #beagle
  • [03:39:44] <ds2> geist: you work on the 3430?
  • [03:39:54] <prpplague> geist thanks, but i'm actually getting beagle working with openocd and flyswatter board
  • [03:40:20] <geist> ds2: yes
  • [03:40:45] <geist> thus far the 3530 seems to be pretty much the same, minues a couple of peripherals
  • [03:40:57] <geist> though i'm a little curious about their errata
  • [03:41:12] <geist> the usb part has quite a few nasty errata on 3430, and i dont see the same thing on 3530
  • [03:41:21] <geist> not sure if it's just fixed, or i'm looking at the wrong errata list
  • [03:41:26] <ds2> geist: nice... was wondering how many people here are also 3430 users
  • [03:41:41] <ds2> geist: on the MUSB side?
  • [03:42:14] <geist> ds2: yeah. simultaneous in/out dma can cause corruption, and looks like double buffering is broken (i spent a week on that last week)
  • [03:42:36] <geist> and the mmc part has a lot of errata too, dont see similar stuff on 3530
  • [03:43:11] <ds2> geist: I think that was discussed on the l-o list... wasn't the concensus that the simultaenous I/O dma is not used in the current driver?
  • [03:43:11] <geist> but anyway, i'll ask my TI rep about it
  • [03:43:47] <geist> dont see why not. if the driver uses musb dma, then it's bound to at some point queue a rx and tx at the same time
  • [03:43:59] <ds2> basic MUSB seems to work with the current driver on the SDP
  • [03:43:59] <geist> the 'solution' is to pick rx or tx, and use the system dma on the other one
  • [03:44:08] <prpplague> ds2 a quick check of the docs for several jtag units shows that the router option is fairly new in all of them
  • [03:44:09] <ds2> geist: I think there is some convoluted logic to avoid it
  • [03:44:21] <geist> the fix may already be in the tree, is my guess
  • [03:44:29] <ds2> prpplague: oh :(
  • [03:44:43] <ds2> geist: there is there aways forcing it to be PIO ;)
  • [03:44:51] <geist> and it's nasty too, on the other hand the usb rx isn't terribly efficient in the linux driver anyway
  • [03:44:59] <geist> i mostly hit it because i was wrirting my own driver for another system
  • [03:45:08] <ds2> geist: ah
  • [03:45:10] <geist> and i was using all the bells and whistles (dma, double buffering, etc)
  • [03:45:14] <geist> and it was hitting all sorts of bugs
  • [03:45:20] <geist> musb is made of fail
  • [03:45:28] <ds2> I mostly hack the l-o driver
  • [03:45:42] <ds2> it sounds like you actually manage to get the mythical MUSB detailed docs?
  • [03:45:50] <geist> yeah, you're not missing a lot
  • [03:45:56] <geist> they're not great
  • [03:46:11] <geist> and it's a pretty crappy part, but it's infinitely better than the old classic omap full speed usb controller
  • [03:46:15] <geist> that was a real POS
  • [03:46:35] <geist> it sits in about the middle of all the usb controllers i've written drivers for over the years
  • [03:46:39] * NishanthMenon (n=Nishanth@cpe-24-27-74-89.tx.res.rr.com) has joined #beagle
  • [03:46:47] <geist> i give it about a 5. it'd get a 7 if it wasn't full of bugs :)
  • [03:47:19] <ds2> heh... the musb driver in the l-o gives me headaches each time I have to fix something so anything is better then that ;)
  • [03:47:59] <ds2> geist: what do you use as your 3430 reference? SDP or Zoom or ?
  • [03:48:00] <prpplague> ds2 yea, should be able to retro fit openocd with the features for the router
  • [03:48:08] <geist> ds2: other
  • [03:48:12] <geist> can't talk about it though
  • [03:48:18] <geist> SUPR SEKRIT
  • [03:48:21] <ds2> understood
  • [03:48:32] <geist> but i do have an sdp, haven't fired it up in a while though
  • [03:48:40] * NishanthM (n=Nishanth@cpe-24-27-74-89.tx.res.rr.com) Quit (Read error: 110 (Connection timed out))
  • [03:49:21] <ds2> prpplague: does this appear to be an ARM inspired thing or an OMAP thing? Wondering about other ARMv7 implementations
  • [03:49:29] <geist> but yeah, one of the nice things about working with TI is you actually get the docs (musb, twl4030)
  • [03:49:42] <ds2> you must have a better rep
  • [03:49:51] <geist> oh wow you have a rep and they dont give you that?
  • [03:49:58] <geist> you need to lay on em, they'll break
  • [03:49:58] <ds2> or better magic ;)
  • [03:50:31] <ds2> I give them slack on the MUSB part since it isn't really their stuff in the firs tplace
  • [03:50:47] <geist> yeah but they should just drop you a doc, it's no biggie
  • [03:50:58] <geist> but believe me, you dont wanna see it
  • [03:51:01] <geist> your eyes will burn
  • [03:51:04] <ds2> 'should' and what happens in reality are 2 different things
  • [03:51:16] <ds2> my eyes are in cinders already from looking at the l-o driver
  • [03:51:26] * geist hasn't figured out what l-o means
  • [03:51:34] <ds2> Linux-OMAP git tree
  • [03:51:40] <geist> ah that
  • [03:51:43] <ds2> the 'public' OMAP kernel
  • [03:51:56] <geist> yeah, there are so many damn omap impementations out there
  • [03:52:03] <geist> hopefully they'll start converging on omapzoom
  • [03:52:37] <geist> if you wanna ship something with this thing you sort of have to pick your poison and deal with all the different implementations
  • [03:52:52] <ds2> when someone, ANYONE, publishes a kernel that works with all the hardware on the Zoom, then I'll be convinced
  • [03:53:03] <geist> you ultimately want to pick the winner, so later on as you merge it wont become a nightmare
  • [03:53:33] <ds2> =)
  • [03:53:34] <geist> i just hate how the omapzoom kernels just hack omap2 support to get omap3
  • [03:53:42] <geist> it's so nasty, piles of ifdefs
  • [03:53:56] <geist> take the plunge man, copy it, call it mach-omap3!
  • [03:54:08] <ds2> problem is they share a lot
  • [03:54:20] <ds2> that'll just move the problem into plat-omap
  • [03:54:32] <geist> except all the places that the omapzoom tree hasn't done a lot
  • [03:54:36] <geist> ie, real dynamic power management
  • [03:54:48] <geist> we had to just write our own implementation of that, it's a total hack fest on omapzoom
  • [03:54:57] <geist> and that's quite a bit different on omap3 vs omap2
  • [03:54:59] <ds2> actually, which kernel is the omapzoom kernel? i.e. where is the sources hosted?
  • [03:55:06] <geist> omapzoom.org
  • [03:55:14] <geist> there's a git tree, not sure what relationship it has to linux-omap
  • [03:55:19] <geist> it's pseudo official from TI, I believe
  • [03:55:23] <geist> and it seems to be pretty sane
  • [03:55:28] <ds2> isn't that just the hacked up WTBU kernel to support Zoom?
  • [03:55:44] <ds2> i.e. it uses display lib in arch/plat-omap/display.c
  • [03:55:51] <geist> seems to have gone past that
  • [03:56:07] <ds2> sigh.. Yet another kernel
  • [03:56:08] <geist> it was originally for that board, but it seems to be the pseudo official TI kernel drop, I think
  • [03:56:28] <geist> yeah, dont get me started on the omap display crap
  • [03:56:37] <geist> at some point it doesn't make sense to try to share all the code
  • [03:56:38] * midoi (n=deb@adsl-75-16-123-150.dsl.crchtx.sbcglobal.net) has joined #beagle
  • [03:56:39] <ds2> the original kernel has diverage seriously :(
  • [03:56:43] <geist> just friggin branch it and clean
  • [03:56:59] <ds2> I'll keep my rants to a min. in a public forum =)
  • [03:57:08] <geist> but yeah, the biggest problem we've had with most of the omap trees is their power management is a joke
  • [03:57:16] <geist> suspend is basically hard code a bunch of crap for this board
  • [03:57:27] <geist> as opposed to doing it right and having all the drivers do the Right Thing
  • [03:57:49] <ds2> IIRC, there exists such a kernel,sort of
  • [03:58:20] <geist> i know it exists, because we wrote it
  • [03:58:23] <geist> but there may be another
  • [04:04:28] <prpplague> jkridner hehe having ti document SPRU739 would be a big help, but i'm not holding my breath, hehe
  • [04:08:20] * midoi (n=deb@adsl-75-16-123-150.dsl.crchtx.sbcglobal.net) Quit ("Leaving.")
  • [04:09:01] <prpplague> if anyone is interested in the icepick functionality, here is a good presentation - http://focus.ti.com/lit/ml/sprp603/sprp603.pdf
  • [04:09:10] <ds2> geist: there is another one
  • [04:09:36] <ds2> i was in the middle of getting features from all the bits and peices all over the place
  • [04:09:47] <geist> probably. we started hacking omap3 before there were any public ones
  • [04:09:53] <geist> so we were kind of on our own for a bit...
  • [04:09:53] <geist> sigh
  • [04:10:13] <ds2> heh
  • [04:11:37] <NishanthMenon> prpplague: thanks for the link.. does look interesting read :)
  • [04:13:42] <prpplague> i've added it to the wiki
  • [04:13:58] <prpplague> i've been wading thru it all today
  • [04:14:54] <jkridner|work> prpplague: if it has an SPRU #, I'm surprised it isn't available. I guess it could be under NDA. I don't find it on the "Extranets" I have access to. You might drop a request on community.ti.com.
  • [04:15:27] <prpplague> jkridner|work will do in the morning
  • [04:16:00] <prpplague> jkridner|work its titled "ICEPick Techincal Reference"
  • [04:17:36] <geist> jkridner|work: you work at TI? (just trying to get the names right)
  • [04:18:21] <jkridner|work> yes.
  • [04:18:40] <jkridner|work> my first name is Jason.
  • [04:18:46] <geist> I see you work on the weekends as well
  • [04:19:08] <jkridner|work> Beagle is a bit of a work of "passion".
  • [04:19:24] <jkridner|work> I'm pretty excited about what I'll be able to do with it.
  • [04:19:26] <geist> what area of the company you in? I may have emailed you before...
  • [04:19:33] <prpplague> jkridner|work or "obession" ?
  • [04:19:39] <prpplague> hehe
  • [04:19:44] * prpplague jokes with jkridner
  • [04:19:44] <jkridner|work> I pretty much hate computers and Beagle gives me the chance to build one from the ground-up that is really low power.
  • [04:19:47] <jkridner|work> :)
  • [04:20:31] <jkridner|work> I work in Catalog Processor applications.
  • [04:20:58] <geist> ah, probably havne't bumped in you then
  • [04:21:01] <jkridner|work> I have responsibility for our operating system roadmap and engagements with community developers.
  • [04:21:12] <geist> i generally deal with the wireless group
  • [04:21:21] <geist> omap 331, 1510, 3430, etc
  • [04:21:48] <geist> oh and 850 and 2430
  • [04:22:00] <jkridner|work> I know quite a few of those guys. I joined the catalog team when we brought OMAP3 to the catalog.
  • [04:22:21] * shiv (n=root@59.160.172.220) has joined #beagle
  • [04:22:21] <geist> yeah, it's weird how TI does the cross marketing for those things
  • [04:22:33] <geist> rename it, do a quick rev, call it soemthing completely different
  • [04:22:36] <jkridner|work> I was previously tech lead for our PMP/PND group.
  • [04:23:11] <jkridner|work> I wrote a bunch of software for our MP3 player chipsets which is what got me on the PMP route.
  • [04:23:42] <geist> killer
  • [04:23:55] <jkridner|work> (USB, CF card with FAT, etc. drivers all on C5000 DSPs).
  • [04:24:05] <geist> hey that reminds me, I should see if i can get he docs to this TI part in this keyspan serial adapter
  • [04:24:19] <geist> it died, must have wiped out it's rom, so when it boots up it claims it's a TI blahblah in serial upload mode
  • [04:24:25] <geist> er usb upload mode
  • [04:24:27] <jkridner|work> you a former TI employee?
  • [04:24:30] <geist> figured it'd be fun to hack some code on it
  • [04:24:35] <geist> nah, but I am a Texan :)
  • [04:24:47] <geist> have dealt with TI a lot over the years
  • [04:24:55] <jkridner|work> in the Dallas area then?
  • [04:25:02] <geist> shipped a product using TI cpus and radios in a past life
  • [04:25:08] <geist> nah, SF bay area
  • [04:25:18] <geist> but i've been to the TI campus a few times
  • [04:25:25] <geist> the massive HQ building
  • [04:28:35] <geist> ah, it's a TIUSB3410. looks like an 8052 microcontroller
  • [04:30:50] * prpplague is now known as prpplague_zzz
  • [04:57:36] * shoragan_ (n=shoragan@sicherheitsschwankung.de) has joined #beagle
  • [04:57:43] * shoragan (n=shoragan@debian/developer/shoragan) Quit (Read error: 104 (Connection reset by peer))
  • [05:01:33] <ds2> geist: you are in the bay area too?
  • [05:05:15] <NishanthMenon> ds2: ping
  • [05:05:22] <ds2> NishanthMenon: pong
  • [05:05:35] <NishanthMenon> ds2: was wondering about ur s-video patch
  • [05:05:53] <ds2> did I break something?
  • [05:06:15] <NishanthMenon> well.. as I unfortunately discovered a couple of days back.. kernel has become incompatible with the patch anymore :(
  • [05:06:28] <ds2> oh sigh
  • [05:06:33] <NishanthMenon> they pushed includes all over... etc..
  • [05:06:40] <NishanthMenon> i kinda re-did ur patch a bit
  • [05:06:51] <NishanthMenon> but i kinda seem to see crashes in my kernel
  • [05:06:58] <ds2> got a trace?
  • [05:07:16] <NishanthMenon> yeah had posted it to the channel a few days back.. but i can generate it now..
  • [05:07:45] <ds2> Hmmm must have missed it, sorry.
  • [05:08:00] <NishanthMenon> hell no.. i think it must be something i royally screwed up
  • [05:08:01] <NishanthMenon> :(
  • [05:08:20] <ds2> I mean missed the trace you posted to the channel
  • [05:08:30] * Viral_Sachde (n=Viral_Sa@122.167.139.3) has joined #beagle
  • [05:09:02] <NishanthMenon> ds2: http://pastie.org/267961
  • [05:09:14] <ds2> looking
  • [05:09:54] * NishanthMenon pulling latest git
  • [05:10:10] <ds2> are you changing anything in sysfs during bootup?
  • [05:10:38] <NishanthMenon> nope.. i just pulled in angstrom fs in mmc..
  • [05:10:52] <NishanthMenon> and is a vannila defconfig from master branch in l-o kernel
  • [05:11:43] <NishanthMenon> with 2007q3 codesourcery compiler..
  • [05:11:47] <ds2> memory managment is unhappy with something; but there isn't anything out of the ordinary done with my patch
  • [05:12:12] <NishanthMenon> one question - venc.h
  • [05:13:28] <NishanthMenon> VENC_DAC_ENABLE would go to VENC_CONTROL register if I am not mistaken.. in which case 0xD will configure it in Composite mode.. not s-video mode..
  • [05:13:50] <NishanthMenon> wondering if your patch worked in composite mode/s-video mode for a tv plugged in..
  • [05:14:10] <NishanthMenon> if i am not mistaken, it should be 0x5 for s-video..
  • [05:15:11] <ds2> to answer that would mean I have to figure out what my S-Video to Composite adapter actually does
  • [05:15:13] * NishanthMenon rebuilding git yet again :(
  • [05:15:32] <ds2> from using it on consumer electronic devices, it seems to really take S-Video in and spit out composite
  • [05:15:43] <NishanthMenon> oh.. ok..
  • [05:16:17] <ds2> let me pull a tree and see if there is any obvious changes
  • [05:16:20] <NishanthMenon> i have a convertor which I think has that capacitor b/w luma-chorma lines - works with my old dell laptops
  • [05:16:37] <ds2> sounds like what I am using
  • [05:17:06] <NishanthMenon> ds2: what filesystem did u use? angstrom?
  • [05:17:24] <ds2> NishanthMenon: no, a stripped down ramdisk
  • [05:17:37] <NishanthMenon> i recollect hearing from someone in irc that udev version is mismatched and that was causign some issues..
  • [05:17:52] <NishanthMenon> ds2: thanks.. will switch to ti busybox
  • [05:17:52] <ds2> fwiw, I do not use udev
  • [05:18:26] <ds2> I am not very discriminating about my userland so I am happy with something that gives me a shell, be it init=/bin/sh shell or a real one I login in to
  • [05:18:34] <NishanthMenon> :)
  • [05:19:05] <ds2> it is not a good sign if something in the userland can screw up fork() which is where your trace is bombing
  • [05:19:36] <NishanthMenon> okie.. thanks for pointing it out.. will switch to a simpler fs and try yet again.. :)
  • [05:20:14] <ds2> hmmm they changed the io mapping stuff around :(
  • [05:25:52] <ds2> nothing obvious comes up... the io_p2v changes shouldn't affect things
  • [05:28:27] <NishanthMenon> coool..
  • [05:28:28] <NishanthMenon> :)
  • [05:28:47] <NishanthMenon> using ti july 24th ramdisk fs and latest uImage, i dont have a crash :)
  • [05:29:20] <ds2> I really don't like how userspace can do this :(
  • [05:29:27] <NishanthMenon> http://pastie.org/267968
  • [05:29:55] <ds2> but then I am also using an ARMv6 userspace to avoid stuff
  • [05:30:13] <NishanthMenon> oh
  • [05:30:37] <NishanthMenon> i should really be troubling koen abt a new fs ;)
  • [05:30:39] <ds2> I guess one thing that is useful to try is to see if the other userspace can get further without udev
  • [05:31:17] <ds2> one uses ARMv6 userspace when the toolchain folks are messing with the ARMv7 stuff at the same time you are trying to get the kernel going :)
  • [05:31:49] <NishanthMenon> hmmm
  • [05:32:52] * NishanthMenon switching to s-video branch
  • [05:39:34] <NishanthMenon> drat.. probably it should be 0xD instead of 0x5.. i see the lil penguin running arround the screen
  • [05:45:30] <NishanthMenon> ok the 0xD works.. (puzzlled..)
  • [05:45:53] <NishanthMenon> noisy penguin though.. hoping ds2 got a better tv out than I have..
  • [05:48:22] <ds2> mine is fuzzy as well
  • [05:49:15] <ds2> when I find time, I'll put the signal on a scope and try to figure out where the noise is coming from. I am hoping it is not just H-sync jitter :/
  • [05:51:47] <NishanthMenon> no.. just generally noisy..
  • [05:52:06] <NishanthMenon> i am using a headmounted display.. which works fine with my ps3 and dvd player
  • [05:52:16] <NishanthMenon> so i suppose it is something to do with beagle output..
  • [05:52:35] <NishanthMenon> i tried the diag u-boot which is put up in code.google.com -> and voila.. noise there too..
  • [05:52:57] <NishanthMenon> ds2: will send out the patch for latest kernel
  • [05:54:22] <ds2> cool thanks
  • [05:54:51] <ds2> I'll be putting up a web page to host the patches
  • [05:55:26] <NishanthMenon> that would really be great :)
  • [05:55:41] <NishanthMenon> might be useful to keep them in sync with l-o kernel
  • [05:59:01] <ds2> I am hoping/waiting for more stuff to go into mainline so the changes won't be as drastic
  • [05:59:58] <NishanthMenon> yep..
  • [06:00:06] <NishanthMenon> the display code is really cranky
  • [06:00:23] <NishanthMenon> it would be great to have a uniform architecture in mainline kernel too
  • [06:03:11] <ds2> that might be a large change, the mainline stuff seems to be broken up all over... fb, v4l2, etc
  • [06:04:16] * khilman (n=khilman@deeprooted.net) has left #beagle
  • [06:06:17] <NishanthMenon> weird.. tv shuts off after a while..
  • [06:06:59] <NishanthMenon> hmm.. might be useful to get angstrom up on this kernel.. poor s-video display limited folks finally can see what the rest of the blokes are raving about :D
  • [06:06:59] <ds2> must be the screen blanking code
  • [06:07:06] <NishanthMenon> aah
  • [06:07:41] <NishanthMenon> ok.. looks like the /sys/power/fb_timeout_value is not available in l-o kernel
  • [06:08:16] <chakie_work> what is required to get the s-video output working?
  • [06:08:38] <ds2> hmmm
  • [06:08:50] <chakie_work> so far i've seen only either the vertical test stripes and nowadays nothing
  • [06:08:51] <NishanthMenon> chakie_work: well.. a bit of hackign that ds2 had kindly done
  • [06:09:12] <NishanthMenon> i kind of pushed files around for the latest kernel..
  • [06:09:28] <NishanthMenon> and i see my penguin now..(kernel boot logo)
  • [06:09:37] <chakie_work> ok, or is the hdmi a better thing to use? my screen happens to have PiP and s-video, so it would be handy
  • [06:09:56] <NishanthMenon> dvi and not hdmi chakie_work :)
  • [06:10:06] <ds2> try 'echo < /dev/fb0' and see if that will wake it up
  • [06:10:07] <NishanthMenon> yeah dvi image quality is way better than s-video
  • [06:10:20] * geraint (n=gnorth@tu008.demon.co.uk) has joined #beagle
  • [06:10:22] <chakie_work> obviously
  • [06:10:46] <NishanthMenon> but s-video is not without it's fans (like me :D)
  • [06:10:59] <chakie_work> just for testing it's fine
  • [06:11:05] <ds2> or try replacing omap_fb.c:omap24xxfb_blank() so all it does is "return 0;"
  • [06:11:21] <chakie_work> especially if you don' have the space for a dvi enabled second screen
  • [06:11:25] <ds2> it is in drivers/video/omap
  • [06:11:58] <chakie_work> i will test once i get home, now i'm in my cubicle of suffering in the salt mine
  • [06:11:59] <ds2> omap24xxfb_blank should be where things get shutdown
  • [06:12:24] <NishanthMenon> ds2: hmm... the echo returned a blank line
  • [06:12:58] <NishanthMenon> will try angstrom distrib one final time before zonking off
  • [06:13:00] <ds2> yeah, th blank line is fine... just doing a open/close...that usually will clear the idle timer for at least one interval
  • [06:13:21] <NishanthMenon> ds2: thanks.. hmmm
  • [06:13:30] <NishanthMenon> let me wait for the guy to go off...
  • [06:13:42] * artyomt (n=artyomt@198.78.191.90.dyn.estpak.ee) has left #beagle
  • [06:13:54] <NishanthMenon> by the way.. can u point me to where in code are we touching VENC_CONTROL reg?
  • [06:14:16] <ds2> I believe arch/arm/plat-omap/display.c
  • [06:14:19] <NishanthMenon> i found VENC_DAC_TEST reg is the same offset as the CONTROL reg
  • [06:14:25] <NishanthMenon> which was kind of weird
  • [06:14:37] <NishanthMenon> (ref venc.h)
  • [06:15:31] <ds2> I wonder if the setterm stuff will change the idle timeout
  • [06:19:03] <NishanthMenon> ds2: i think ur echo trick did the job..
  • [06:19:42] <ds2> if you want to do it in a script, use 'echo -n < /dev/fb0'... that ought to prevent the output
  • [06:20:24] <NishanthMenon> yep.. my aim though is to get angstrom show some useful thingy out
  • [06:20:34] <NishanthMenon> but i guess i am bit away from it yet
  • [06:21:14] <ds2> judging from the U-boot color bars, a careful selection of colors might minimize the noise in the video
  • [06:21:34] <NishanthMenon> ds2: it should not. I work with SDP3430 and there is no noise on it
  • [06:21:41] <NishanthMenon> i wonder what is so different here..
  • [06:22:06] <NishanthMenon> mebbe i need to take my s-video convertor to desk soemtime this week and test it out with ssdp3430
  • [06:22:16] <ds2> Hmmm
  • [06:22:32] <NishanthMenon> there is a inv bit which switches luma/chroma
  • [06:22:40] <NishanthMenon> dunno if that affects
  • [06:22:46] <ds2> out of guesses, got to get it on a scope
  • [06:23:31] <ds2> probally need to get 2-3 lines
  • [06:25:13] <NishanthMenon> drat!! ok.. looks like angstrom does in fact hate the l-o kernel!!
  • [06:25:28] <NishanthMenon> probably we need a 2.6.27-rc5 angstrom distrib!
  • [06:25:39] <ds2> step through the userspace bit by bit
  • [06:26:10] <NishanthMenon> yep.. gotta get up at 5 in the morning
  • [06:26:11] <NishanthMenon> :(
  • [06:26:18] <ds2> oh
  • [06:26:34] <NishanthMenon> i have to attend some orientation at 7:30.. Dallas DART is painfull for early morning travel :(
  • [06:27:45] <NishanthMenon> http://pastie.org/267981 -> linux-omap kernel freshly pulled + s-video patch crash with angstrom distrib fs,mlo,u-boot
  • [06:28:20] <NishanthMenon> ds2: thanks for the help.. catch up with you later..
  • [06:28:22] <NishanthMenon> gnite all..
  • [06:28:42] * NishanthMenon (n=Nishanth@cpe-24-27-74-89.tx.res.rr.com) Quit ("Aloha")
  • [06:34:02] * shoragan_ is now known as shoragan
  • [07:24:53] <koen> Crofton: good news for USRP: iso and high bandwidth support for MUSB :)
  • [07:36:59] * fraz__ (n=fraz@host143186050011.borland.com) Quit (Read error: 101 (Network is unreachable))
  • [07:43:19] * geraint (n=gnorth@tu008.demon.co.uk) Quit ()
  • [07:58:17] * guillaum1 (n=gl@AMontsouris-153-1-70-69.w90-2.abo.wanadoo.fr) Quit ("Leaving.")
  • [07:58:57] * guillaum1 (n=gzba4143@AMontsouris-153-1-70-69.w90-2.abo.wanadoo.fr) has joined #beagle
  • [08:52:20] * geraint (n=gnorth@217.207.128.219) has joined #beagle
  • [08:58:26] * koen wonders what's up with all the TI folk using nohz=off
  • [09:39:51] * Olipro_ (n=Olipro@uncyclopedia/Olipro) has joined #beagle
  • [09:57:06] * Olipro (n=Olipro@uncyclopedia/Olipro) Quit (Read error: 110 (Connection timed out))
  • [10:44:47] * feig (n=ejf3@c-76-118-153-30.hsd1.ma.comcast.net) Quit ("Konversation terminated!")
  • [10:51:41] * [-ip-] (n=ts@mnhm-590f529d.pool.einsundeins.de) has joined #beagle
  • [10:54:14] * felipec (i=c0647cdb@gateway/web/ajax/mibbit.com/x-6b505d58a95242ca) has joined #beagle
  • [11:05:43] <dcramer> morning
  • [11:06:02] <dcramer> so anyone else having problems with usb serial dongles through a hub ?
  • [11:06:35] <ahu> I've seen that
  • [11:06:40] <ahu> not beagle specific though
  • [11:06:48] * vitaly (n=chatzill@adsl-75-36-227-123.dsl.pltn13.sbcglobal.net) has joined #beagle
  • [11:06:57] <dcramer> ahu: any resolution ?
  • [11:08:27] <DJWillis> dcramer: powered or unpowered hub, I have seen it often with unpowered hubs that give little more then 100mA
  • [11:08:33] <dcramer> powered
  • [11:08:44] <dcramer> here's what I know
  • [11:08:49] <DJWillis> Chipset? Serial I/C that is
  • [11:08:56] <dcramer> prolific
  • [11:09:03] <dcramer> works alone on the hub
  • [11:09:14] <dcramer> doesn't work with a linksys ethernet dongle on the hub
  • [11:09:27] <dcramer> it can be found and the driver loaded
  • [11:09:36] <dcramer> after that there is no output
  • [11:09:37] <DJWillis> Hmmmm, sounds like a crappy hub ;)
  • [11:09:42] <dcramer> tried two of them
  • [11:09:44] <dcramer> same deal
  • [11:09:55] <dcramer> two different ones
  • [11:09:59] <DJWillis> same hubs?
  • [11:10:15] <dcramer> no different ones
  • [11:11:06] <DJWillis> Odd, I have seen issues common to a brand/model before (design features common to all of them etc.) but that is a little odd.
  • [11:11:39] <ahu> dcramer: other hub
  • [11:12:06] <dcramer> DJWillis: I enabled debugfs and usbmon
  • [11:12:25] <dcramer> when I write to /dev/ttyUSB0 there is no trace info at all
  • [11:12:41] <dcramer> when it does work of course there is trace info
  • [11:14:08] <DJWillis> Odd, I would have to suspect the hub(s) as that seems to be the common one if it works direct and on it's own, or just some issue with the Linksys dongle, tried another USB device to see if it is that?
  • [11:14:45] <dcramer> good idea
  • [11:14:51] <dcramer> I have a few other usb devices
  • [11:15:02] <dcramer> I wouldn's suspect the linksys since it is working
  • [11:15:08] <dcramer> with two things plugged in
  • [11:16:16] <DJWillis> Well that's flawed, suspect everything until you know it plays nice ;)
  • [11:16:39] <vitaly> Prolific has odd endpoints scheme, maybe that's the problem?
  • [11:18:21] <vitaly> Never used it with a hub though, may try as well...
  • [11:24:29] <vitaly> Just brought it up with hub, along with flash memory stick. Works. Mine is prolific pl2303
  • [11:24:32] * jrmuizel (n=jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) has joined #beagle
  • [11:24:49] * jrmuizel (n=jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) Quit (Client Quit)
  • [11:26:08] <Crofton|work> koen, configure: error: Internationalization tools missing.
  • [11:26:30] <Crofton|work> from ggz-client-libs when build demo-image
  • [11:26:44] <Crofton|work> I'd wipe tmp, but I need to dork with boost ...
  • [11:31:20] <koen> Crofton|work: intltool(-native) is built?
  • [11:31:52] <Crofton|work> arm version is
  • [11:32:11] <Crofton|work> and native
  • [11:32:42] * vitaly is now known as Warhead
  • [11:33:17] <Crofton|work> do you know of a good tutorial for adding arm asm to gcc?
  • [11:33:45] * Warhead is now known as Vit_SFBA
  • [11:35:55] <Vit_SFBA> Who could tell, what would be good config to recompile codesourcery for beagle?
  • [11:36:04] <geraint> Not sure how up to date it is, but http://www.milw0rm.com/papers/128 is something I've used in the past.
  • [11:41:24] <geraint> Having recompiled the beagle kernel from a snapshot from MRU, it doesn't looks as if my framebuffer is working. The CONFIG_FB flag was set, but I don't see a /dev/fb0 or /dev/fb/0 when I boot the new kernel. Any ideas?
  • [11:42:15] <koen> geraint: wrong dma size, wrong bootargs?
  • [11:43:29] <Crofton|work> how do I know what version arm instructions are available inside a c program
  • [11:43:39] <Crofton|work> ie what defines can I count on
  • [11:43:45] <keesj> file myfile
  • [11:46:42] <koen> Crofton|work: SUBTARGET_CPU_DEFAULT TARGET_CPU_arm9tdmi ?
  • [11:47:11] <koen> (from unbreak-armv4t.patch)
  • [11:47:14] <Crofton|work> koen, where do I find these things
  • [11:47:17] <Crofton|work> ah
  • [11:47:42] <Crofton|work> i actually need the instruction set
  • [11:47:48] <Crofton|work> not the cpu
  • [11:48:00] <koen> isn't that tied to the core?
  • [11:49:39] <koen> but I get your point :)
  • [11:49:46] <Crofton|work> basically, the ldrex instruction is armv6 and above
  • [11:50:09] <Crofton|work> so I want to check for that, not have to add cores all the time
  • [11:51:08] <geraint> Crofton: You can see gcc's predefined macros with something like arm-none-linux-gnueabi-g++ -dM -E - < /dev/null | sort
  • [11:51:28] <geraint> Crofton: You could try and very -march or -mcpu and see if that gives you any clues.
  • [11:51:47] <Crofton|work> you would think there would be a web page .....
  • [11:54:41] <Crofton|work> #define __ARM_ARCH_6__ 1
  • [11:54:56] <geraint> Crofton - I couldn't find one. Running with a -mcpu=cortex-a8 shows that __ARM_ARCH_7A__ etc seem to be the way to do it.
  • [11:55:51] <geraint> koen: Could you remind me of the framebuffer bootargs? I had them on a web page somewhere, but I can't find them any longer.
  • [11:56:33] <geraint> koen: Also, what's 'wrong DMA size'?
  • [12:01:03] <Crofton|work> thanks geraint
  • [12:02:03] <geraint> Crofton: There's also a __VFP_FP__ that might come in handy.
  • [12:03:18] <koen> geraint: http://www.angstrom-distribution.org/demo/beagleboard/README.txt
  • [12:04:49] <geraint> koen: Interesting - the prebuilt angstrom image that I had been using didn't need those bootargs. I'll try 'em with my own kernel (which is suspiciously about 50% the size of the Angstrom image, too)
  • [12:09:16] <koen> geraint: those bootargs are needed if you want the overlay to work
  • [12:09:45] * JuanG (n=Juan@nat/ti/x-50cee3abeb9fc0c1) has joined #beagle
  • [12:10:09] * JuanG (n=Juan@nat/ti/x-50cee3abeb9fc0c1) has left #beagle
  • [12:10:17] <Vit_SFBA> koen: could you please recommend gcc version and spec to compile it for beagleboard to run natively?
  • [12:11:21] <geraint> koen: I just tried it, and the rubbish on the screen looked slightly prettier, but no joy. I'll see if Mans' tree has any beagle-specific docs in it.
  • [12:14:31] <geraint> Is there more than needs copying across than just the uImage - I'm still using the prebuilt Angstrom root fs - I copied uImage into the boot partition, created a /lib/modules/2.6.27-rc3-omap1 and ran a depmod (don't think I needed to copy any modules across - the .config wasn't set to build many) - did I miss something?
  • [12:15:46] * methril|gone is now known as methril
  • [12:20:29] <koen> Vit_SFBA: use OE :)
  • [12:20:57] <koen> geraint: did you instruct uboot to fish the uImage out of /boot?
  • [12:21:20] * rsalveti (n=salveti@189.70.219.182) Quit (Read error: 110 (Connection timed out))
  • [12:21:25] <geraint> koen: No, but I put the image in the boot partition, so it definitely got picked up.
  • [12:21:41] <koen> ah right
  • [12:21:54] <koen> I read 'partition' as 'directory'
  • [12:23:18] * RogerMonk (n=a0740758@nat/ti/x-e65018db59651e3e) has joined #beagle
  • [12:23:21] <geraint> Does the Angstrom distro use the Mans tree? I'd like to try and reconstruct the same kernel from source, as a starting point.
  • [12:23:59] <Vit_SFBA> koen: I'm new to arm and to beagle in particular, what's OE?
  • [12:25:37] <geraint> Vit_SFBA: I started here: http://elinux.org/BeagleBoard#OpenEmbedded
  • [12:25:48] <Vit_SFBA> Ah!
  • [12:26:18] <geraint> Vit_SFBA: Basically, you download the current release of OE, tell it you have a beagle board, and then tell it what you want (kernels, native tools, cross-compilers) etc. , and it goes and downloads and builds them for you.
  • [12:26:52] <Vit_SFBA> Got it, thanks geraint!
  • [12:26:55] <geraint> Vit_SFBA: It achieves this by downloading the entire internet.
  • [12:27:30] * prpplague_zzz (n=dave123_@ppp-70-244-162-73.dsl.rcsntx.swbell.net) Quit ()
  • [12:27:56] <Vit_SFBA> geraint: I've got a good link and 750GB disk :)
  • [12:30:02] * BThompson (n=BThompso@nat/ti/x-4eca85f7795d2b9c) has joined #beagle
  • [12:32:41] * rsalveti (n=salveti@200.184.118.132) has joined #beagle
  • [12:33:27] * koen gives in and does 'alias arm-linux-gcc=${TARGET_PREFIX}gcc
  • [12:33:28] <koen> '
  • [12:33:36] <koen> instead of fixing all the makefiles
  • [12:41:52] * rsalveti (n=salveti@200.184.118.132) Quit (Remote closed the connection)
  • [12:42:55] * rsalveti (n=salveti@200.184.118.136) has joined #beagle
  • [12:51:45] <Crofton> p;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  • [12:59:50] <koen> cat on keyboard alert
  • [13:01:35] * robclark (n=robclark@nat/ti/x-0f4da166bd738499) has joined #beagle
  • [13:11:37] <geraint> koen: So, the top of Mans tree (http://git.mansr.com/?p=linux-omap;a=tags) has a defconfig with CONFIG_DISPLAY_SUPPORT disabled. There has been a patch from you to enable it (http://article.gmane.org/gmane.comp.handhelds.openembedded.scm/3588) - is it possible that this didn't make it into Mans' tree?
  • [13:12:00] * Crofton (n=balister@66-207-66-26.black.dmt.ntelos.net) Quit (Read error: 113 (No route to host))
  • [13:12:46] * koen doesn't know about m??ns' tree
  • [13:13:14] * prpplague (n=dave@mail.americanmicrosystems.com) has joined #beagle
  • [13:14:02] <geraint> Ah, do you have a suggestion other than http://www.beagleboard.org/irclogs/index.php?date=2008-09-04#T15:29:17 , then? I don't need sound, but I do need framebuffer.
  • [13:16:33] <koen> what's wrong with the OE kernel?
  • [13:16:52] <koen> that has a working FB
  • [13:18:39] <geraint> koen: I wanted the one most likely to have all the current fixes for board instability, such as the 32k timer and NEON cache-flush problems. My question the other week was to find out which branch was most likely to contain all these things, as I'm seeing some strange board timer issues and wanted to make sure that I wasn't chasing something that had already been fixed.
  • [13:19:01] <koen> the kernel OE builds has all those fixes
  • [13:19:14] <koen> all git trees are up to .27rc, which is quite broken
  • [13:20:06] <geraint> Great - that's fine for me then, thanks.
  • [13:22:00] * artyomt (n=artyomt@198.78.191.90.dyn.estpak.ee) has joined #beagle
  • [13:22:54] <artyomt> got my beagleboard. looks like rev b5 ?!
  • [13:23:17] <koen> b5 has the timer fix (c70 removed)
  • [13:30:45] <artyomt> ahh... its just home page link references rev4
  • [13:31:17] * jkridner_ (n=jason@c-76-31-18-64.hsd1.tx.comcast.net) has joined #beagle
  • [13:32:13] <koen> jkridner|work: good morning!
  • [13:32:23] * jkridner|work1 (n=a0321898@nat/ti/x-e449e29216df9d17) has joined #beagle
  • [13:32:35] <jkridner|work1> good morning.
  • [13:32:49] <koen> artyomt: http://beagleboard.org/hardware links to the b4 HRM
  • [13:32:51] <koen> ehm
  • [13:32:52] <koen> b5
  • [13:32:54] <jkridner|work1> net connection went down temporarily.
  • [13:33:55] <DJWillis> koen: how bad is Linux-OMAP head at the moment? I was going to look at pulling in recent stuff but if stability has gone to shit I think I will hold ;)
  • [13:33:58] <jkridner|work1> I didn't realize you could trigger the bug with the ALSA (old) driver.
  • [13:34:56] <koen> DJWillis: musb is broken for one
  • [13:35:08] <koen> "Capacitor C70 was removed to improve the 32KHz clock rise and fall time. This
  • [13:35:09] <koen> fixes the GPT1 timer issue. This change can be easily made by the board owner
  • [13:35:09] <koen> using a soldering iron."
  • [13:35:13] <artyomt> koen, yes, but http://beagleboard.org/ link to b4
  • [13:35:14] * koen use a nailclipper
  • [13:35:20] <artyomt> links *
  • [13:36:17] <DJWillis> koen: i'll keep my clone where it is then ;)
  • [13:36:51] * jkridner|work (n=a0321898@nat/ti/x-88ea410af12b01b7) Quit (Remote closed the connection)
  • [13:36:59] * jkridner|work1 starts to fix the link on the home page.
  • [13:38:47] <jkridner_> home page now points to B5 manual.
  • [13:38:52] <jkridner_> thanks!
  • [13:38:54] <koen> DJWillis: I decided to ignore .27rc for the time being
  • [13:45:48] * jkridner (n=jason@c-76-31-18-64.hsd1.tx.comcast.net) Quit (Read error: 110 (Connection timed out))
  • [13:46:22] <DJWillis> koen: seems like a plan, I don't want to battle with kernel stability when trying to do the last bits of validation on the H/W.
  • [13:47:35] * [-ip-] (n=ts@mnhm-590f529d.pool.einsundeins.de) has left #beagle
  • [13:49:04] * Openfree (n=df@218.82.119.176) has joined #beagle
  • [13:49:15] * shiv (n=root@59.160.172.220) Quit ("Leaving.")
  • [13:53:40] * shiv (n=root@59.160.172.220) has joined #beagle
  • [13:54:14] * dcramer (n=davec@dcdsl.ebox.com) Quit (Read error: 104 (Connection reset by peer))
  • [13:55:00] <koen> DJWillis: the only annoyance with .26 are the usb disconnects, which seem to be solved in .27rc (once you patch musb to work again)
  • [14:03:36] * dcramer (n=davec@dcdsl.ebox.com) has joined #beagle
  • [14:04:43] <DJWillis> koen: thanks for that
  • [14:20:40] <Crofton|work> koen, tofl
  • [14:20:53] <Crofton|work> er rofl, he ended up suspending the laptop
  • [14:20:59] <Crofton|work> which is bad
  • [14:23:37] * Crofton (n=balister@66-207-66-26.black.dmt.ntelos.net) has joined #beagle
  • [14:40:26] * Olipro_ is now known as Olipro
  • [14:40:56] * odesus (n=OMAR@148.223.106.43) has joined #beagle
  • [14:41:42] * odesus (n=OMAR@148.223.106.43) has left #beagle
  • [14:41:57] * t_s_o (n=tso@148.84-49-135.nextgentel.com) has joined #beagle
  • [14:42:01] * shiv (n=root@59.160.172.220) Quit ("Leaving.")
  • [14:43:12] * shiv (n=root@59.160.172.220) has joined #beagle
  • [14:43:37] * jkridner|work1 (n=a0321898@nat/ti/x-e449e29216df9d17) Quit (Remote closed the connection)
  • [14:55:18] * nabax (n=nabax@89.129.96.71) has joined #beagle
  • [14:55:26] <nabax> hi all!
  • [14:55:56] <nabax> i finally got my serial cable :D
  • [14:56:04] <nabax> gonna start right away
  • [14:58:43] <dsp4us> quit
  • [14:58:53] <dsp4us> exit
  • [14:58:55] * dsp4us (n=mbuyanin@216.0.106.116) has left #beagle
  • [14:59:51] * nabax (n=nabax@89.129.96.71) Quit (Remote closed the connection)
  • [15:02:08] <artyomt> is it ok to use gparted for SD formatting. just not hardcore enough ?
  • [15:03:09] * nabax (n=nabax@89.129.96.71) has joined #beagle
  • [15:03:09] * Viral_Sachde (n=Viral_Sa@122.167.139.3) has left #beagle
  • [15:04:36] <nabax> could you please help me a bit? i'm quite lost here
  • [15:06:21] <prpplague> nabax: ask your questions, if someone knows the answer and has time, they will be happy to help
  • [15:07:01] <nabax> well i just got my serial cable and dunno what to do now
  • [15:07:07] <DJWillis> artyomt: I have used it but it has not been totally consistent.
  • [15:07:17] <nabax> my goal is to have a linux running there
  • [15:09:12] <nabax> so far i know i need minicom, so i'm gonna compile it right away
  • [15:11:17] <chakie> nabax: don't you use a distro where minicom is packaged already?
  • [15:11:29] <nabax> not in this pc
  • [15:11:33] <nabax> i'm in vectorlinux
  • [15:12:05] <chakie> any perticular reason why you make it extra hard to get stuff running? :)
  • [15:12:23] <nabax> hahaha
  • [15:12:32] <nabax> i like it hard ;) lol
  • [15:12:42] <nabax> well, got minicom compiled now
  • [15:12:48] * piller (n=piller@160.91.233.77) has joined #beagle
  • [15:13:24] <nabax> i'm there, but really, i couldn't find any "begin here" guide
  • [15:13:29] <nabax> so i'm totally lost here
  • [15:13:54] <nabax> anybody know a beginner's guide which i could use?
  • [15:14:24] <chakie> http://code.google.com/p/beagleboard/wiki/outofthebox
  • [15:14:39] <koen> this is scary
  • [15:14:50] <koen> ioquake3 needed only 3 env vars to crosscompile
  • [15:15:02] <Crofton|work> what is scary is me writing assembly
  • [15:15:09] <chakie> heh
  • [15:15:45] <chakie> what is today the best route for playing video using a beagle? fb or x.org? i only need 480p so far
  • [15:16:46] <chakie> is the omapfbplayer (or similar) app simply a demo or something that can be really used?
  • [15:17:35] <koen> it can be used, but it doesn't have sound
  • [15:17:56] <nabax> thanks chakie!
  • [15:18:10] <chakie> koen: sound is overrated :)
  • [15:18:38] <chakie> so mplayer or something else based on ffmpeg then
  • [15:19:21] <koen> the problem is that only omapfbplay knows how to drive the overlays properly
  • [15:20:07] <artyomt> what is ETA for 3d (even proprietary) drivers are published
  • [15:20:56] <koen> "end of the year"
  • [15:22:23] <piller> Hi, I just received my new beagle board!
  • [15:22:43] <piller> Now I need to connect it up and get started.
  • [15:23:06] <jkridner|beagle> great. what do you plan to try to run first?
  • [15:23:25] <jkridner|beagle> diagnostics are what I recommend, just to know the board functionality...
  • [15:23:34] <jkridner|beagle> then I'd recommend taking a look at the Angstrom demo.
  • [15:23:46] <chakie> hm, always when in try to flash xload/uboot to nand it all stops at "Texas Instruments X-Loader 1.41sms"
  • [15:23:50] <piller> I just wanted to get it running first, connect it to my computer
  • [15:24:01] <piller> or even better use it as a computer
  • [15:24:10] <piller> Is there a getting started howto?
  • [15:24:10] * jrmuizel (n=jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) has joined #beagle
  • [15:24:12] <artyomt> got my board too, but im not in office and I dont have monitor here. so Im out of luck yet
  • [15:24:41] <Crofton|work> hmm, how do I specify a label in gcc asm
  • [15:24:57] <jkridner|beagle> there is an "outofthebox" on the code.google.com site: http://code.google.com/p/beagleboard/outofthebox (I think)
  • [15:25:16] <artyomt> only positive side - I have SD reader in my laptop
  • [15:25:30] <BThompson> http://code.google.com/p/beagleboard/wiki/outofthebox
  • [15:25:40] <jkridner|beagle> you running Linux on that laptop?
  • [15:25:46] <jkridner|beagle> Thanks Bernie!
  • [15:26:20] <chakie> i've actually never got it to boot from nand
  • [15:26:22] <artyomt> yes,
  • [15:27:10] <chakie> perhaps the demo image xload/uboot can't be used for nand?
  • [15:27:37] <artyomt> jkrinder|beagle: ubuntu 8.04 here
  • [15:27:45] <nabax> anyone know why minicom doesn't connect to my board?
  • [15:28:00] <nabax> CTRL-A Z for help |115200 8N1 | NOR | Minicom 2.2 | VT102 | Offline
  • [15:28:01] <jkridner|beagle> nabax: can you give a bit more info?
  • [15:28:06] <nabax> sure :)
  • [15:28:09] <jkridner|beagle> does your minicom connect to anything?
  • [15:28:22] <nabax> nope, it says Offline
  • [15:28:42] <nabax> is Port /dev/ttyS1 alright?
  • [15:28:47] * methril is now known as methril|gone
  • [15:28:53] <piller> How do I connect to the rs232 connector? Do I hack up a cable?
  • [15:29:17] <kulve> buy one
  • [15:29:31] <nabax> i got one from an old computer
  • [15:29:32] <kulve> or hack. I soldered my version since I didn't have a proper one at hand..
  • [15:29:40] <nabax> plus the male-male cable which i got from a switch
  • [15:30:08] <jkridner|beagle> port depends on your computer.
  • [15:30:31] <jkridner|beagle> what is the wiring of your male-male cable?
  • [15:30:39] <jkridner|beagle> is it a null-modem or straight-through?
  • [15:30:56] <jkridner|beagle> Beagle is typically used with a null-modem cable.
  • [15:30:56] <kulve> jkridner|beagle: doesn't all computers have the same port..?
  • [15:31:13] <kulve> all computers as in PCs..
  • [15:31:18] <chakie> oh, *now* a flashed xload suddenly worked...
  • [15:31:22] <chakie> strange :)
  • [15:31:28] <jkridner|beagle> computers, yes, but target boards sometimes use the modem side, which allows straight-through cables.
  • [15:31:36] <jkridner|beagle> oh...
  • [15:31:39] <jkridner|beagle> you mean the port #.
  • [15:31:41] <jkridner|beagle> no.
  • [15:31:59] <jkridner|beagle> you could have multiple serial ports. I must be confused by your question.
  • [15:33:59] <nabax> jkridner|beagle it's a straight-through one
  • [15:34:05] <nabax> won't it work?
  • [15:34:45] <jkridner|beagle> not with the wiring recommended.
  • [15:34:48] <nabax> isn't there a command to check if the beagleboard is being detected in the COM port?
  • [15:34:52] <jkridner|beagle> did you build your own adapter cable?
  • [15:34:58] <sakoman_> koen: during the demo image boot I see a message "Checking for built-in Bluetooth: no"
  • [15:34:58] <nabax> like and lsusb or lsusb or stuff
  • [15:35:06] <nabax> nope, i got it from a switch
  • [15:35:14] <jkridner|beagle> when beagle boots, it will print some content out the serial port.
  • [15:35:24] <nabax> ah wait
  • [15:35:31] <sakoman_> Do you know which package is printing this, and how I tell it that there *is* built in bluetooth?
  • [15:35:41] <nabax> it was already turned on when i started minicom, is that a problem?
  • [15:36:02] <jkridner|beagle> try power cycling the board to see if you get any output.
  • [15:36:31] <nabax> u mean using the reset button?
  • [15:36:53] <jkridner|beagle> http://www.linuxjunkies.org/html/Remote-Serial-Console-HOWTO.html seems to have some good starter info
  • [15:37:10] <jkridner|beagle> reset button is fine too.
  • [15:37:20] <jkridner|beagle> power cycling is removing power and then reasserting it.
  • [15:38:15] <nabax> none of them worked :(
  • [15:38:38] <nabax> i guess it doesn't matter how am I powering the board, does it?
  • [15:38:57] <jkridner|beagle> can you read that web page and then come back with more questions?
  • [15:39:11] <jkridner|beagle> you just need to give the right power to the board.
  • [15:39:18] <jkridner|beagle> do you get 4 LEDs on?
  • [15:39:20] <nabax> sure thanks:)
  • [15:39:23] <nabax> yep
  • [15:39:38] <nabax> 4 leds, yeah
  • [15:43:25] * Olipro_ (n=Olipro@uncyclopedia/Olipro) has joined #beagle
  • [15:43:54] <nabax> ok, when minicom starts some leds blink
  • [15:44:01] <nabax> but then there's no output whatsoever
  • [15:44:02] * Olipro (n=Olipro@uncyclopedia/Olipro) Quit (Nick collision from services.)
  • [15:44:03] * Olipro_ is now known as Olipro
  • [15:44:31] <nabax> ah nono, they don't blink
  • [15:44:38] <jkridner|beagle> when minicom starts? on the beagle?
  • [15:44:39] <nabax> it was my imagination :-$
  • [15:44:49] <jkridner|beagle> ok, that would have been odd.
  • [15:44:51] <nabax> lol forget it i'm going nuts already
  • [15:44:58] <nabax> i cannot change the port in minicom
  • [15:45:06] <jkridner|beagle> how many lights are on the Beagle?
  • [15:45:12] <jkridner|beagle> 2? 4?
  • [15:45:19] <nabax> i tried to set ttyS0 but it keeps trying ttyS1
  • [15:45:26] <nabax> there are 4 leds lighted up
  • [15:45:31] <nabax> turned on sorry x'D
  • [15:45:33] <jkridner|beagle> are you running minicom as root?
  • [15:45:37] <nabax> yep..
  • [15:46:09] <jkridner|beagle> there are some debug steps on the faq: http://elinux.org/BeagleBoardFAQ
  • [15:46:46] <nabax> ok thanks :)
  • [15:48:09] * shiv (n=root@59.160.172.220) Quit ("Leaving.")
  • [15:48:14] * keesj is seriously thinking of creating a beagle polyclinic in amstedam (for all your diagnostics)
  • [15:48:53] <prpplague> keesj: hehe
  • [15:49:08] <nabax> keesj you should consider creating a polyclinic for new users too
  • [15:49:22] <prpplague> keesj: i'd never heard the term polyclinic before living outside of the US for a few years
  • [15:49:25] <nabax> with psychological help and so on
  • [15:49:59] <nabax> jkridner|beagle: i think it might be the com cable
  • [15:50:18] <nabax> i'll get a null-modem adapter this afternoon and check what happens...
  • [15:50:24] <nabax> thanks a lot for ur help :)
  • [15:50:27] <nabax> much appreciated
  • [15:51:38] <nabax> damn it!
  • [15:51:41] <nabax> IT WORKS NOW!
  • [15:53:25] <keesj> prpplague: where do you live now?
  • [15:54:03] <prpplague> keesj: Dallas, Texas, however i've lived in several former british colonies
  • [15:54:49] <nabax> it was the serial port, I had to use ttyS0 instead of 1
  • [15:55:35] <Crofton> mmmmmmmmmmjjjjjjjjjjjju888888888888888888888888888.llllllllllllllllllll+_+++++++++++++++++++++++++++++++++++++++++""""""""""""""""++++++++++++++++++++++++"""+++++++++++++++++++++++""+++++++++++++++++++++++++++++++++++++++++""""""""+++++++++++++++++++++++++++++++++++++++""""""""""""""""""""""""""""""""""""""""""""+""""""""++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  • [15:55:35] <Crofton> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  • [15:55:39] <Crofton> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  • [15:55:44] <Crofton> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  • [15:55:49] <Crofton> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  • [15:55:55] <prpplague> bad Crofton
  • [15:55:59] <nabax> aha
  • [15:56:11] <koen> sakoman_: yes, that's blueprobe probing for funky serial port bluetooth stuff
  • [15:56:12] <nabax> i forgot my morse knowledge, sorry
  • [15:56:40] <nabax> can you repeat using the latin alphabet please? x'D
  • [15:56:50] <nabax> U-Boot 1.3.3 (Jul 10 2008 - 16:33:09)
  • [15:56:50] <nabax>
  • [15:56:50] <nabax> OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
  • [15:56:50] <nabax> OMAP3 Beagle Board + LPDDR/NAND
  • [15:56:50] <nabax> DRAM: 128 MB
  • [15:56:51] <nabax> NAND: 256 MiB
  • [15:56:53] <nabax> In: serial
  • [15:56:55] <nabax> Out: serial
  • [15:56:57] <nabax> Err: serial
  • [15:56:59] <nabax> Audio Tone on Speakers ... complete
  • [15:57:03] <nabax> OMAP3 beagleboard.org #
  • [15:57:05] <nabax> so i got this now
  • [15:57:05] <sakoman_> koen: thanks, I'll take a look and see if I can teach it that there is a module on ttyS1
  • [15:57:07] <nabax> is this one a normal linux shell?
  • [15:57:17] <jkridner|beagle> that is a u-boot prompt
  • [15:57:35] <kulve> nabax: u-boot being the boot loader that's supposed to load the kernel..
  • [15:57:37] <nabax> sorry i don't know what's that...
  • [15:57:39] <jkridner|beagle> you use that to boot linux
  • [15:57:44] <nabax> ok
  • [15:57:45] <nabax> got it
  • [15:57:53] <nabax> and which commands are used here?
  • [15:57:59] <jkridner|beagle> it is a shell that allows you to program the flash, etc.
  • [15:58:03] <kulve> nabax: "help" :)
  • [15:58:04] <koen> sakoman_: http://projects.linuxtogo.org/plugins/scmsvn/viewcvs.php/trunk/base/blueprobe/?root=gpe
  • [15:58:08] <nabax> haha thanks kulve
  • [15:58:09] <nabax> obvious
  • [15:58:17] <chakie> a default "mplayer foo.avi" oopses the kernel
  • [15:58:18] <jkridner|beagle> you can look up u-boot on the web. 'help' is useful too. :)
  • [15:58:33] <jkridner|beagle> there are a few commands on the outofthebox wiki page.
  • [15:58:41] <kulve> nabax: probably you want to init the mmc, load the kernel from the mmc, and boot the kernel
  • [15:58:52] <prpplague> keesj: polyclinic is not a term you normally hear in the states
  • [15:58:53] <nabax> OMAP3 beagleboard.org # help
  • [15:58:58] <nabax> it doesn't give any output
  • [15:59:00] <kulve> and maybe set the kernel boot args to e.g. mount a rootfs from a right place
  • [15:59:20] <BThompson> printenv and setenv ar the two commands youll probably use most
  • [15:59:32] <kulve> and maybe saveenv? :)
  • [15:59:47] <koen> "die, uboot, die" is another
  • [16:00:19] <nabax> ok thanks a lot
  • [16:00:26] * jkridner|beagle has gotten lazy and just started using Beagle for web browsing and IRC, but really needs to get a clock on my Beagle destkop that is accurate.
  • [16:00:35] <nabax> i get no answer from the board but anyway, i got quite far today
  • [16:00:42] <nabax> i never thought i'd get to here lol
  • [16:00:46] * jkridner|beagle better yet, I should get a desktop machine setup.
  • [16:00:51] <nabax> i'll go on later :)
  • [16:00:52] <nabax> thanks all!
  • [16:01:05] <nabax> cu!
  • [16:01:21] * nabax (n=nabax@89.129.96.71) Quit (Remote closed the connection)
  • [16:12:38] <artyomt> http://code.google.com/p/beagleboard/wiki/BeagleBoardDiagnostics
  • [16:12:38] <artyomt> do I need to copy all of these into FAT32 partition or part to ext3 one ?
  • [16:15:31] <artyomt> I'm asking since http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat educates to create two partitions
  • [16:17:36] <Openfree> artyomt, Fat for kernel image, ext3 for boot system, i guess
  • [16:18:23] <Openfree> s/boot/root/
  • [16:18:26] <jkridner|beagle> for all of those, it would be to the FAT partition.
  • [16:18:48] <jkridner|beagle> the stuff on Diagnostics includes a ramdisk file system only.
  • [16:19:08] <Openfree> i would be wrong.. sorry
  • [16:19:20] <jkridner|beagle> you wouldn't use the ext3 partition until you had a persistent file system.
  • [16:19:32] <geraint> Lots of people getting started today, and my new beagleboards arrived today also - must have been a busy day at DigiKey on Friday!
  • [16:19:42] <jkridner|beagle> must have!
  • [16:20:10] <jkridner|beagle> btw, I'm using Pidgin from a Beagle board now using the Angstrom demo.
  • [16:21:04] <jkridner|beagle> if you have a partitioned SD card, going the Angstrom demo route can be rather rewarding in all the apps you get running.
  • [16:21:23] <jkridner|beagle> problem is there is no step-by-step for the Angstrom demo if you are new to embedded Linux.
  • [16:21:54] <jkridner|beagle> so, your best starting point depends on your level of experience and what you hope to learn/do.
  • [16:22:20] <BThompson> if they can get the sd card formatted (documented on the wiki) than getting the angstrom going is easy
  • [16:22:47] <BThompson> its just copying files on to the card and updating U-Boot arguments iirc
  • [16:22:55] <Openfree> jkrider|beagle, i would like to know is the Angstrom base on openembedded
  • [16:23:12] <jkridner|beagle> u-boot might not be familar to all Linux people though, since they might be new to embedded.
  • [16:23:19] <jkridner|beagle> openfree: yes.
  • [16:23:41] <Openfree> using the pre-build system would be simple
  • [16:24:01] <Openfree> u-boot is quiet easy-configurable
  • [16:24:26] <jkridner|beagle> there are also steps for setting up Debian or Ubuntu, but OE gives the most optimized binaries today.
  • [16:24:32] <Openfree> Great, so we can easy build our own system base on OE.
  • [16:24:37] <artyomt> some readmo for angstrom on partitioned SD is appreciated
  • [16:25:02] <artyomt> I beleive lots of folks want write software and not kernel itself for beagle :)
  • [16:25:43] <jkridner|beagle> readme is at the same place as the download. scrolling back....
  • [16:26:05] <Openfree> OE is quite stand-alone , any HOST would be fine, I'm using gentoo, and is said using FreeBSD is also ok
  • [16:26:14] <keesj> I guess it would be good to have an Angstrom based SDK/release
  • [16:26:15] <kulve> artyomt: http://www.angstrom-distribution.org/beagleboard-demo-image-available
  • [16:26:20] <jkridner|beagle> http://elinux.org/BeagleBoard#OpenEmbedded is one reference.
  • [16:26:57] <keesj> wispers a little like mamona tries to be
  • [16:27:10] <jkridner|beagle> thanks kulve
  • [16:27:35] <jkridner|beagle> my browser was down because I'm trying to install fennec.
  • [16:28:42] <geraint> Is firefox/epihany supposed to work out of the box with the Angstrom images? I'm not able to launch it.
  • [16:29:03] <geraint> Get some warnings about the throbber, and some Glib-GObject warnings about GaProtocol.
  • [16:29:39] <jkridner|beagle> firefox must be installed for it to run ('opkg update; opkg install firefox')
  • [16:30:02] <jkridner|beagle> Epiphany should be installed in the demo. how did you try to launch it?
  • [16:30:22] <geraint> "epiphany" from an xterm.
  • [16:30:35] <jkridner|beagle> did you try the icon?
  • [16:30:57] <jkridner|beagle> the icon says firefox, but it is actually epiphany.
  • [16:31:17] <jkridner|beagle> anyone know how to invoke fennec?
  • [16:31:20] <geraint> Yeah - I get the same behaviour.
  • [16:32:21] * jkridner|work (n=a0321898@nat/ti/x-d7757602003576b3) has joined #beagle
  • [16:32:25] <jkridner|beagle> odd. maybe something worth giving keon a ping.
  • [16:32:48] * jkridner|beagle finally boots the laptop to use Outlook.
  • [16:32:50] <jkridner|beagle> :(
  • [16:33:20] <geraint> I'll try and re-image onto another SD card first - I have been installing some weird things on it.
  • [16:33:35] <geraint> Thanks
  • [16:35:04] <koen> geraint: are you up to date with the feeds?
  • [16:35:19] <koen> geraint: e.g. 'opkg update ; opkg upgrade -force-overwrite' ?
  • [16:36:53] <geraint> Ah no - an okpg update segfaults me. :-(
  • [16:36:58] <geraint> upgrade, sorry.
  • [16:37:37] * Olipro_ (n=Olipro@uncyclopedia/Olipro) has joined #beagle
  • [16:37:51] <koen> jkridner|beagle: the last 2 fennec versions have a .desktop, so it should show up in your menus
  • [16:38:26] <geraint> Like this: http://pastebin.com/m32e782ad - don't worry too much - I'll re-image it tomorrow when I get some more SD cards.
  • [16:40:30] * Olipro (n=Olipro@uncyclopedia/Olipro) Quit (Nick collision from services.)
  • [16:40:31] * Olipro_ is now known as Olipro
  • [16:42:57] <artyomt> is it possible to create fileset for automatic boot from SD ?
  • [16:43:28] <jkridner|beagle> ugh. fennec sucks up 101MB!
  • [16:43:37] * jrmuizel (n=jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) Quit (Remote closed the connection)
  • [16:43:49] <jkridner|beagle> that doesn't seem right.
  • [16:44:22] * jrmuizel (n=jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) has joined #beagle
  • [16:45:05] <jkridner|beagle> I cannot find the proxy config in fennec.
  • [16:46:40] <jkridner|beagle> no scroll-bars and no cursor. guess it is meant for multi-touch?
  • [16:53:30] <koen> jkridner|beagle: add user_pref("browser.ui.cursor", true); to ~/.mozilla/fennec/*-default/prefs.js
  • [16:57:49] * fraz_ (n=fraz@host143186050011.borland.com) has joined #beagle
  • [16:58:11] * fraz_ (n=fraz@host143186050011.borland.com) has left #beagle
  • [16:59:03] <sakoman_> koen: epiphany always crashes at launch. is this just my bad beagle karma or is it common?
  • [17:00:16] <jkridner|beagle> sakoman_: that makes 2 of us. I just updated it to be sure I didn't have a stale copy.
  • [17:00:43] <sakoman_> I think I will stick with Midori, it at least works :-)
  • [17:01:39] <koen> jkridner|beagle: http://scap.linuxtogo.org/files/4adbae4c8eafce7b39504e7deb6a13aa.png
  • [17:02:04] <koen> sakoman_: epiphany works like a charm here, provided you stay up to date with the feeds
  • [17:02:23] <sakoman_> koen: I'm building from scratch
  • [17:02:32] <sakoman_> so it is as up to date as the recipe
  • [17:03:01] <sakoman_> gnome-games never builds for me
  • [17:03:21] <sakoman_> so I guess I will just remove epiphany and gnome-games
  • [17:03:26] <sakoman_> and use midori
  • [17:04:54] <sakoman_> koen: my build has epiphany-2.22.2-r1, is that the same as you?
  • [17:05:56] <sakoman_> i did a pull yesterday, but epiphany has been broke at launch for me basically forever
  • [17:05:57] <koen> yes
  • [17:06:09] <koen> any backtrace on the fault?
  • [17:06:14] <jkridner|beagle> epiphany *used* to work for me.
  • [17:06:24] * Openfree (n=df@218.82.119.176) Quit (Remote closed the connection)
  • [17:06:48] <jkridner|beagle> I think there could be something that stomped it, but -force-reinstall and -force-overwrite didn't help.
  • [17:07:07] <geraint> I have 2.22.1-r0 and that crashes on launch for me.
  • [17:07:33] <koen> it used to crash, till I rebuilt against latest webkit
  • [17:07:36] <koen> hence the r1
  • [17:08:24] <koen> something more that "crashes at startup" would help pointing out the problem
  • [17:08:32] <koen> s/that/than/
  • [17:08:34] <sakoman_> koen: "An exit code of 1 was returned from epiphany ."
  • [17:08:42] <sakoman_> How's that for helpful :-)
  • [17:08:52] <sakoman_> That's all you get in the error log
  • [17:09:04] <geraint> You get a bit more if you launch from the command line - hang on, I'll pastebin it.
  • [17:09:07] <sakoman_> nothing in dmesg
  • [17:09:17] <koen> strace, gdb?
  • [17:09:21] <koen> catchsegv?
  • [17:10:16] <sakoman_> sadly won't have time for that till this evening. need to get a mfg test image ready.
  • [17:10:36] <sakoman_> perhaps geraint's output will be helpful in the meantime
  • [17:11:43] <sakoman_> koen: just looked at your Fennec image. cool!
  • [17:12:03] <koen> sakoman_: slooooooooooooooooooooooooooooow is more descriptive for ff3 and fennec
  • [17:12:09] <koen> but vlad_ is working on it :)
  • [17:12:20] <sakoman_> koen: which package gives you the cool graphical system info there in the background?
  • [17:12:32] <koen> sakoman_: gnome-system-monitor
  • [17:12:55] <sakoman_> very neat, I could use that :-)
  • [17:12:57] <koen> sakoman_: those graph are vectors and need xrender, so reduce the update frequency or the sysmon with suck op 100% cpu
  • [17:13:18] <koen> should be lean & fast once imgtec released 3d drivers for X ;)
  • [17:13:43] <jkridner|beagle> I get no trace on the crash. the log is useless ("returned 1").
  • [17:13:53] <sakoman_> heh, I guess it isn't too useful if it totally distorts what you are trying to measure!
  • [17:14:00] <jkridner|beagle> I'm told to install a GNOME bug-buddy app. not sure where to find that.
  • [17:14:19] <sakoman_> jkridner|beagle: same here
  • [17:14:58] <koen> bug-buddy would be pretty useless, since we strip the debugging symbols it needs :)
  • [17:15:16] <koen> and bug-buddy would file a report at gnome bugzilla, which also wouldn't be very helpfull to us :)
  • [17:15:43] <koen> bug-buddy basically attached gdb, gets a backtrace and attaches it to bugzilla
  • [17:15:47] <koen> very neat
  • [17:17:21] * jrmuizel_ (n=jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) has joined #beagle
  • [17:17:21] <sakoman_> koen: what is the "proper" way to override the angstrom feed url's? I think you don't want thousands of Overo customers slamming your repo?
  • [17:18:06] <koen> more people using those repos would actually be nice
  • [17:18:14] <koen> that's the whole point of them being there :)
  • [17:18:34] <jkridner|beagle> is there a mirror system?
  • [17:18:51] <koen> sakoman_: the override way is still the same as you did for gumstix svn
  • [17:19:09] <sakoman_> OK, just checking :-)
  • [17:19:33] <koen> this is annoying, I can't locate my q3 cd I legally bought
  • [17:21:23] <jkridner|beagle> user_pref("network.proxy.autoconfig_url", "TI proxy URL"); doesn't seem to work in Fennec.
  • [17:22:47] <sakoman_> koen: another issue is that if Angstrom repo goes down, Gumstix has no control over how fast it comes back up
  • [17:23:19] <koen> that's true
  • [17:23:28] <koen> hence the need for a mirroring system :)
  • [17:23:36] <sakoman_> yup
  • [17:23:45] <koen> for openzaurus we used to have a apache based mirroring system
  • [17:23:46] <sakoman_> is it on the Angstrom "to do" list?
  • [17:27:24] <jkridner|beagle> this is also a TI care-about. don't like to have customers down trying to install packages.
  • [17:29:55] <geraint> OK, got a seg in epiphany - fairly useless debug info at http://pastebin.com/m27ee5c28
  • [17:30:17] <sakoman_> hmm . . .maybe there is a business in providing a guaranteed uptime OE repo
  • [17:30:40] <sakoman_> heh, I doubt companies would attach enough value to that to fund it
  • [17:30:41] <ds2> try enabling verbose user crashes in the kernel?
  • [17:31:03] <Crofton|work> sakoman_, figuring out how to fund that would be helpful though
  • [17:31:52] <geraint> From the strace, looks like it was around the time of a clone().
  • [17:32:14] <geraint> ds2: I'm not familiar with that - how does one do it, and what does it provide?
  • [17:32:45] <sakoman_> Crofton|work: I bet it would take a person close to full time + bandwidth expense
  • [17:32:54] <ds2> geraint: it is a kernel config option + kernel run time parameter to enable it; it gives you a trace for ANY segfault/exception that kills a process
  • [17:33:28] * jrmuizel (n=jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) Quit (Read error: 110 (Connection timed out))
  • [17:33:29] <ds2> geraint: the lack of throbber animation seem like a bad thing (in your trace)
  • [17:36:24] <jkridner|beagle> anyone here played with the matrix build system from Movial?
  • [17:37:48] <koen> ds2: I get the same message, and no segfault
  • [17:38:41] <Crofton|work> http://rafb.net/p/2ovCPl36.html
  • [17:38:51] <Crofton|work> please laugh and comment on my assembly
  • [17:39:09] <prpplague> jkridner|beagle: btw, who did you say i needed to contact about the SPRU739 document?
  • [17:40:16] <prpplague> Crofton|work: can we settle for just laughing about you in general?
  • [17:40:16] <jkridner|beagle> prpplague: I believe I just suggested making a post to community.ti.com.
  • [17:40:28] <Crofton|work> always
  • [17:40:29] <mru> Crofton|work: that won't work...
  • [17:40:46] <Crofton|work> why not?
  • [17:40:50] <prpplague> jkridner|beagle: ahh ok, thought i'd sent myself an email, must have forgotten last night
  • [17:40:57] <mru> because it's all wrong
  • [17:41:13] * Crofton|work points out he hasn't done this in a long time :)
  • [17:41:23] <Crofton|work> however all wrong depresses him
  • [17:41:27] <koen> there must be a comma in the right spot somewhere ;)
  • [17:42:55] * Stargazers (i=stargaze@xob.kapsi.fi) has joined #beagle
  • [17:43:02] <mru> Crofton|work: what are you trying to implement? atomic increment 1?
  • [17:43:11] <Stargazers> Uh, wrong channel ->
  • [17:43:12] * Stargazers (i=stargaze@xob.kapsi.fi) has left #beagle
  • [17:43:15] <mru> no return value?
  • [17:44:13] <geraint> You probably want to drop something into r1 before you strex.
  • [17:45:00] <mru> addq?
  • [17:45:06] <koen> and aren't all those armv6 instructions?
  • [17:45:31] <mru> yes, they're armv6
  • [17:45:37] <ds2> BAD ti for using rm04 link wrapping
  • [17:45:39] <Crofton|work> mru basicaly yes
  • [17:45:51] <mru> thumb variant from armv6t2 onward
  • [17:46:05] <geraint> Crofron: See http://chandlerc.net/llvm_atomics.html
  • [17:46:22] <geraint> Sorry, Crofton.
  • [17:46:26] <geraint> In the llvm.atomic.las section
  • [17:46:42] <geraint> ; r0 = result
  • [17:46:42] <geraint> ; r1 = ptr
  • [17:46:42] <geraint> ; r2 = delta
  • [17:46:42] <geraint> spin:
  • [17:46:43] <geraint> ldrex r0,[r1]
  • [17:46:43] <geraint> add r3,r0,r2
  • [17:46:45] <geraint> strex r4,r3,[r1]
  • [17:46:47] <geraint> cmp r4,0
  • [17:46:49] <geraint> b.ne spin
  • [17:49:24] <geist> looks decent
  • [17:49:31] <Crofton|work> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204h/Bcfjicfj.html
  • [17:50:12] <geraint> That's taken me to the NEON/VFP section - was that your intent?
  • [17:50:25] <Crofton|work> proabaly not
  • [17:50:28] <Crofton|work> stupid frames
  • [17:50:47] <Crofton|work> I'm looking at the LDREX exampel
  • [17:50:55] <geraint> Gotcha
  • [17:51:06] <geist> ldrex is precisely the same as ldr, usage wise
  • [17:51:14] <geraint> That's a grab the lock operation, not an atomic increment.
  • [17:51:16] <geist> it's strex that has the special propery
  • [17:51:20] <Crofton|work> right
  • [17:51:34] * TAK2004 (n=Administ@dslb-088-072-103-172.pools.arcor-ip.net) has joined #beagle
  • [17:51:49] <Crofton|work> will the %0 from the paraemter work, or ddoes that need to go into a register first?
  • [17:53:25] <geraint> In all cases involving inline ASM, I try it and see what the compiler planted. :-)
  • [17:53:37] <geist> your inline asm has a couple of issues
  • [17:53:46] <geist> clobbers r1, r0, doesn't declare that it does
  • [17:53:51] <geist> doesn't put memory in the clobber list
  • [17:53:59] <prpplague> jkridner|beagle: i registered for the forums, now it won't take me to the forum pages, never had so much trouble with the TI website
  • [17:54:17] <geist> not sure what the (&value) is all about after the "0"
  • [17:54:31] <geist> and the 'loop' label is sort of unsafe, could collide with other labels
  • [17:55:26] <Crofton|work> yeah I was thinking I had to output in the input register, but the output goes into the memory pointed to by the inupt
  • [17:55:35] <Crofton|work> so there are no output registers
  • [17:55:58] <mru> here you go: http://pastebin.com/m3ec30ccd
  • [17:56:02] <mru> the madman's version
  • [17:56:02] <geist> and r1 is busted
  • [17:56:12] <Crofton|work> yes
  • [17:56:19] <geist> mru: that's even more bisted
  • [17:56:29] <mru> how so?
  • [17:56:34] <ds2> community.ti.com sees AFU at the moment
  • [17:56:35] <geist> since it trashes a lot of registers and doesn't declare them as clobber
  • [17:56:50] <geist> oh wait. ugh
  • [17:56:51] <mru> mine doesn't trash anything not assigned by the compiler
  • [17:56:53] <geist> never mind I was dumb
  • [17:57:06] <mru> and why use a cmp instruction when you can avoid it ;-)
  • [17:57:06] <geist> was reading the %0 as r0 for some reason
  • [17:57:18] <mru> x86 poisoned mind?
  • [17:57:21] <geraint> I'd stick a volatile next to that asm, too.
  • [17:57:36] <geist> mru: use cmp. that sub pc will take a huge cycle penalty
  • [17:57:39] <mru> yes, volatile is probably good
  • [17:57:47] <mru> why?
  • [17:57:50] * geraint notices the sub pc
  • [17:57:52] <geist> because it's a branch
  • [17:58:06] <mru> and the bne following the cmp is also a branch
  • [17:58:09] <mru> both are predicted
  • [17:58:27] <geist> not the sub. it can't predict those
  • [17:58:32] <mru> it does
  • [17:58:34] <geist> it can only try to predict static branches
  • [17:58:42] <geist> anyway, just put the cmp in there, it's much more clean
  • [17:58:45] <mru> "ADD pc, r0, r1, LSL #2 is predicted"
  • [17:58:50] <mru> that's what the manual says
  • [17:58:53] <mru> as an example
  • [17:59:02] <mru> but not as fun ;-)
  • [17:59:07] * Olipro (n=Olipro@uncyclopedia/Olipro) Quit (Connection timed out)
  • [17:59:07] <geist> either way you are taking a branch every time now, as opposed to taking it only if you have to loop
  • [18:00:05] * robclark (n=robclark@nat/ti/x-0f4da166bd738499) Quit (Remote closed the connection)
  • [18:00:11] <mru> taking or not isn't the issue
  • [18:00:13] <ds2> arrrg x86 damange... PC is not the program counter in this case right?
  • [18:00:24] <geraint> Yes, it is.
  • [18:00:26] <mru> a misprediction always costs cycles
  • [18:00:40] * robclark (n=robclark@nat/ti/x-a730a9e863de4ac7) has joined #beagle
  • [18:00:45] <mru> a correctly predicted branch takes one cycle
  • [18:00:51] <mru> on cortex-a8
  • [18:00:55] <mru> arm11 was different
  • [18:01:01] <geist> hence the correctly predicted part
  • [18:01:18] <geist> i fail to see how it can possibly predict that branch with no penalty
  • [18:01:28] * geraint wonders if he could use the Report Abuse link next to mru's post to complain to ARM about wasting a perfectly good general-purpose register.
  • [18:01:39] <geist> but anyway, all that aside it's just a clever trick that confuses people
  • [18:01:55] <prpplague> Crofton|work: login on community.ti.com appears to be down
  • [18:02:00] <mru> geraint: what did I waste?
  • [18:02:07] <geist> oh and there's no way it'll compile thumb2
  • [18:02:15] <geraint> mru: Not you, ARM. :-)
  • [18:02:40] * felipec (i=c0647cdb@gateway/web/ajax/mibbit.com/x-6b505d58a95242ca) Quit ("http://www.mibbit.com ajax IRC Client")
  • [18:02:53] <mru> for the requirement that Rd != Rt?
  • [18:03:04] * denix is back (gone 65:55:33)
  • [18:03:46] <jkridner|work> prpplague: need a hand with the forums?
  • [18:04:06] <prpplague> jkridner|work: yea, something ain't right
  • [18:04:33] <prpplague> jkridner|work: i registered, but its not allowing me to login to the forums, it gives me an error
  • [18:04:58] <geraint> mru: I'm just generally offended by the ARM architecture having PC aliased with a GPR, in the same way as I am offended by the MIPS branch delay slot (and don't get me talking about the SPARC branch delay slot).
  • [18:05:24] <mru> the mips branch delay can be quite useful
  • [18:05:52] <mru> unless the compiler fucks it up
  • [18:05:54] <mru> seen that happen
  • [18:05:57] <ds2> jkridner: the community.ti.com site is broken right now
  • [18:06:02] <mru> took a week to track it down
  • [18:06:07] <geist> oh wow no, I love how the PC is a gpr
  • [18:06:17] <geraint> mru: Quite. And I write compilers for a living. :-)
  • [18:06:18] <geist> though it causes a lot of headaches for emulators...
  • [18:06:42] <mru> geraint: pray you didn't write the green hills mips compiler
  • [18:06:50] <geist> i'm more offended that thumb takes away a lot of the joys of hacking ARM
  • [18:06:52] <mru> or I'll unleash my fury upon you
  • [18:06:52] <ds2> but isn't aliasing the program counter with a GPR a standard risc thing?
  • [18:06:58] <prpplague> jkridner|work: they must be doing some weird things with cookies and such, had to close the browser and clear the temp data
  • [18:07:03] <mru> ds2: only arm does that afaik
  • [18:07:07] <geist> ds2: not that i know of. pdp-11 did it
  • [18:07:11] <mru> mips certainly doesn't
  • [18:07:17] <ds2> ppc I think does that too
  • [18:07:28] <geist> nope, pc isn't visible as a gpr
  • [18:07:38] <geist> on ppc
  • [18:07:48] <prpplague> jkridner|work: ahh theres a note on the main page, they changed out the service last friday
  • [18:07:48] <mru> mips "wastes" a register for constant zero
  • [18:08:09] <geraint> mru: Is that INTEGRITY? That screwed us all over the place, I feel your pain. :-)
  • [18:08:11] <geist> yeah, ppc kind of does. it has a nasty hack that if you use r0 as an offset in a load/store it means zero
  • [18:08:15] <ds2> eh... too lazy to dig out the manuals but I seem to recall it does or at least you can treat it as if it was a GPR with side effects
  • [18:08:38] <mru> geraint: I'm not sure what the marketing name of that compiler is
  • [18:09:02] <mru> but it saw fit to use the branch delay slot on return from a function to load the return value from the stack
  • [18:09:07] <ds2> prpplague: where is that note? cuz that is really screwed up. They sent out a marketing mail this morning about stuff on there and telling people to join
  • [18:09:08] <mru> BELOW the stack pointer, of course
  • [18:09:18] <mru> now think interrupt...
  • [18:10:00] <geraint> :-) PPC Defines a "red zone" in the ABI that you're allowed to write below for just that reason, I think.
  • [18:10:09] <mru> of course it only did it in mips16e code, and only when compiling without debugging symbols
  • [18:10:20] <mru> x86-64 has a red zone
  • [18:10:21] <geraint> :-)
  • [18:10:41] <mru> and none of the tools available could disassemble mips16e
  • [18:11:07] <prpplague> ds2: https://community.ti.com/Default.aspx
  • [18:11:18] <prpplague> ds2: "NOTICE: Please excuse our dust! On Friday, September 5th, we made some changes to our architecture and we are still updating files. Thanks for your patience!"
  • [18:11:21] <geist> ah yeah. pdp11 definitely did it. r0-r7, r6 and r7 are sp and pc
  • [18:11:31] <geist> betcha that's what the arm guys were thinking about when they designed it
  • [18:11:55] <ds2> prpplague: heh.. that shows up as an error message for me "Sorry, there was a problem with your last request!"
  • [18:12:06] <geraint> I know the guy who designed the ARM ISA, so I could actually ask him. :-)
  • [18:12:10] <prpplague> ds2: interesting
  • [18:12:17] <prpplague> ds2: might have to login to view it
  • [18:12:25] <geist> geraint: yeah, that'd be neat
  • [18:12:27] <ds2> prplague: guess the marketing guys to not talk to the admins of the site
  • [18:12:48] <geist> I love hacking ARM much more so than any other arch. sadly it seems to be going the way of the dodo. thumb2 :(
  • [18:13:08] <mru> geist: ?
  • [18:13:12] <prpplague> ds2: indeed
  • [18:13:30] <geist> well, it's pretty clear that arm intends for thumb2 to be the new thing. not now, but eventually
  • [18:13:39] <geraint> ARM is pretty nice - especially the conditional bits in the instructions - not many other architectures have something like that (although compilers can rarely use them)
  • [18:13:44] <ds2> prpplague: you would think they won't send out a mail inviting people to join a (new?) community on that site the very day it is down!
  • [18:13:50] <geist> and my general experience has been that it does indeed work better for most code
  • [18:14:06] <prpplague> ds2: nothing about marketing surprises me anymore
  • [18:14:10] * dirk2 (n=dirk@F307d.f.strato-dslnet.de) has joined #beagle
  • [18:14:20] <prpplague> dirk2: greetings
  • [18:14:23] <geist> geraint: yeah, and the barrel shifter goodness
  • [18:14:29] <mru> geraint: ime compilers use conditional instructions quite often
  • [18:14:31] <geraint> gtg now guys - catch you later.
  • [18:14:36] <geist> yeah me too
  • [18:14:45] <bjdooks> geist: iirc, arm's arm patents are running ut and therefore they need new ones
  • [18:14:52] <mru> free shift with every instruction is nice
  • [18:15:23] <geist> bjdooks: yeah, and thumb2 does really give the best of both worlds: better code density, so less hit on the instruction cache, and now you can do all the stuff you couldn't do in thumbv1
  • [18:15:48] <bjdooks> thumb v1 sucked dinkey
  • [18:15:52] <geist> yeah, but it's fast
  • [18:15:56] <geist> if you dont have piles of L2
  • [18:16:14] <dirk2> prpplague: hi. read in the logs that you made some jtag progress :) But sounds that still some work is needed.
  • [18:16:36] <geist> in my previous couple of companies we would bench it and usually thumb came out a winner for that regular code that makes up the bulk of most systems
  • [18:16:54] <geist> L2 probably changes the picture ab it, but without it ARM cpus tend to be completely cache starved
  • [18:18:34] <prpplague> dirk2: yea, i was able to manually set up the TAP router
  • [18:22:07] <prpplague> dirk2: i've started adding a flag for openocd to bypass the init checks and start with programming the TAP
  • [18:23:12] * gadiyar (n=Smash@122.167.68.63) has joined #beagle
  • [18:24:31] <prpplague> dirk2: after that appears to be working i'll look at what we need to do for a cortex-a8 support
  • [18:24:57] <prpplague> dirk2: openocd already has the armv7 support so it should be a simple item to create a arch file using it
  • [18:25:12] <prpplague> dirk2: you can look at how the cortex-m3 board is using the armv7 support
  • [18:25:18] * felipec (i=c0647cdb@gateway/web/ajax/mibbit.com/x-eb78bfa6a0185885) has joined #beagle
  • [18:25:44] <felipec> is this ok?
  • [18:25:45] <felipec> Console: switching to mono frame buffer device 128x48
  • [18:25:51] <koen> it is
  • [18:26:09] <felipec> I don't see anything on the screen
  • [18:27:00] * sakoman_ (n=sakoman@static-74-41-60-154.dsl1.pco.ca.frontiernet.net) Quit ("Ex-Chat")
  • [18:28:43] <dirk2> prpplague: k, thanks. Hmm, maybe it enough to have keesj, Nishanth and you looking into JTAG for the moment ;)
  • [18:29:17] * rsalveti_ (n=salveti@200.184.118.132) has joined #beagle
  • [18:30:23] * sakoman (n=sakoman@static-74-41-60-154.dsl1.pco.ca.frontiernet.net) has joined #beagle
  • [18:32:17] <prpplague> dirk2: np, just curious though
  • [18:32:30] * geraint (n=gnorth@217.207.128.219) Quit (Read error: 113 (No route to host))
  • [18:32:33] <prpplague> dirk2: are you mainly wanting jtag for flashing the device or for debugging?
  • [18:33:04] <dirk2> sakoman: Read the mail from Peter Meerwald about sound Null pointer and interrupts. What do you think about it?
  • [18:33:23] <felipec> coherent allocation too big (requested 0x400000 mask 0xffffffff)
  • [18:33:31] <felipec> if I set video=omapfb:vram:2M,vram:4M
  • [18:34:24] * gadiyar (n=Smash@122.167.68.63) has left #beagle
  • [18:34:54] <ds2> felipec: there is a kernel config for the max size of coherent allocations, maybeyou need to bump that
  • [18:35:27] <mru> btw, my ugly pc hack is slightly slower than a normal branch
  • [18:35:36] <mru> damn, it was such a neat hack
  • [18:35:49] <dirk2> prpplague: I think I mainly want JTAG for (a) having nice cheap open source JTAG and play with it (b) use it to ease e.g. low level bootloader/uboot debugging or e.g. dpll programming. Just writing a register with JTAG and check what happens is faster & easier than printf & compile & download cycle
  • [18:36:04] * rsalveti_ (n=salveti@200.184.118.132) Quit (Remote closed the connection)
  • [18:36:22] <prpplague> dirk2: ahh ok, sounds more for debugging then
  • [18:36:55] <dirk2> prpplague: yes. Flashing works fine with U-Boot or USB download
  • [18:37:00] * rsalveti_ (n=salveti@200.184.118.136) has joined #beagle
  • [18:37:21] <felipec> ds2: where is that?
  • [18:38:01] <felipec> ah, ONFIG_FB_OMAP_CONSISTENT_DMA_SIZE ?
  • [18:38:27] * Xenion (n=robert@p579FCA60.dip.t-dialin.net) has joined #beagle
  • [18:38:39] <dirk2> prpplague: Once it's JTAG basically work I have to test your ordering system for europe shipment ;)
  • [18:39:03] <keesj> :p
  • [18:39:03] <prpplague> dirk2: hehe, use the USPS shipping, it's really cheap and pretty fast
  • [18:39:05] * rsalveti (n=salveti@200.184.118.136) Quit (Read error: 104 (Connection reset by peer))
  • [18:39:27] * rsalveti_ is now known as rsalveti
  • [18:39:32] <prpplague> dirk2: based on my work this weekend i hope to have some early working stuff next week
  • [18:39:46] * Beagle7 (n=Beagle7@207.138.148.220) has joined #beagle
  • [18:42:01] <Crofton|work> mru, the "=&r" basically say to uses a a register? you had to create vars to go with them
  • [18:42:13] <Crofton|work> does that storage really get allocated?
  • [18:42:22] <dirk2> prpplague: Do I have to care about the "Out of stock" for Beagle adapters http://tincantools.com/product.php?productid=16144 ?
  • [18:42:34] <mru> Crofton|work: here's a proper version: http://pastebin.com/m5f00bf69
  • [18:42:46] <prpplague> dirk2: its my understanding that the armv7 core debugging is pretty standardized, so even though the m3 is different than the a8, the debugging of armv7 should be the same
  • [18:42:49] <mru> the r constraint means register, yes
  • [18:42:54] <ds2> felipec: yes
  • [18:42:57] <mru> = means it will be written
  • [18:43:04] <Crofton|work> so the variable works out to be a dummy var?
  • [18:43:06] <prpplague> dirk2: we have them marked as out of stock until we have openocd working with the board
  • [18:43:12] <Crofton|work> I like the compare better :)
  • [18:43:14] <mru> & means it will be used more than once, more or less
  • [18:43:16] <prpplague> dirk2: we have plenty in stock
  • [18:43:29] <dirk2> prpplague: k :)
  • [18:43:37] <mru> the variables are not allocated any stack space, if that's what you mean
  • [18:43:45] <Crofton|work> exactly
  • [18:43:49] <mru> it's generally better to let the compiler manage the register allocation
  • [18:43:55] <Crofton|work> yes
  • [18:43:55] * ds2 sends an army of ninjas to the TCT warehouse to fix that ;)
  • [18:44:33] <prpplague> dirk2: if you really want a set prior to the release, we can arange that, just with the understanding that openocd support is a work in progress
  • [18:44:48] <Crofton|work> mru, how is the label scoped?
  • [18:45:16] <mru> it's a local label
  • [18:45:26] <mru> the gnu assembler documentation has more details on those
  • [18:45:30] <Crofton|work> within the asm section
  • [18:45:56] * RogerMonk (n=a0740758@nat/ti/x-e65018db59651e3e) has left #beagle
  • [18:46:09] <mru> wider than that
  • [18:46:38] <mru> the code in an asm statement gets pasted verbatim into the code the compiler sends to the assembler
  • [18:46:46] <mru> after %N expansion
  • [18:47:24] <prpplague> dirk2: we'll have to make some changes for the difference between armv7m and armv7a
  • [18:47:35] <Crofton|work> http://rafb.net/p/I8pfsF95.html
  • [18:47:40] * guillaum1 (n=gzba4143@AMontsouris-153-1-70-69.w90-2.abo.wanadoo.fr) Quit ("Leaving.")
  • [18:47:43] <mru> no
  • [18:47:47] <Beagle7> Hello, I'm looking for informations about delivery time of beagleboard, at digikey there is no stock available, any information?
  • [18:48:01] <mru> Crofton|work: use the numerical labels
  • [18:48:12] <sakoman> dirk2: I saw the email. he doesn't give any of the interesting details, like which interrupt routine -- I'm assuming it is mcbsp
  • [18:48:38] <sakoman> Lots of discussion about mcbsp on the linux-omap mailing list right now
  • [18:48:58] <dirk2> Beagle7: http://elinux.org/BeagleBoardFAQ#DigiKey_out_of_stock
  • [18:49:13] <sakoman> He also doesn't say what kernel he is using
  • [18:49:39] <sakoman> In any event, don't have time to look at that today. have a looming deadline!
  • [18:50:00] <Crofton|work> I assume the b is a hint which direction the branch goes?
  • [18:50:11] <dirk2> sakoman: k. Any U-Boot NAND news?
  • [18:50:47] <sakoman> dirk2: I think I found the issue -- it was hw
  • [18:50:53] <mru> Crofton|work: no, 1b means the first 1 label going backwards
  • [18:51:03] <sakoman> waiting for a rework to be done to confirm the theory
  • [18:51:04] <mru> 1f would mean the first 1 label going forwards
  • [18:51:37] <mru> Crofton|work: http://sourceware.org/binutils/docs/as/Symbol-Names.html
  • [18:52:36] <dirk2> sakoman: :( regarding hw, :) that's no sw issue ;)
  • [18:53:03] <Crofton|work> someone needs to have their head examined ....
  • [18:53:12] <sakoman> dirk2: I end up worrying about both
  • [18:58:24] * hli (i=chatzill@vig91-2-82-232-97-149.fbx.proxad.net) has joined #beagle
  • [19:00:21] <felipec> has anyone tried gstreamer's fbdevsink on the beagleboard?
  • [19:00:40] <mru> I doubt it can use the overlay
  • [19:01:44] <felipec> mru: why?
  • [19:03:28] <mru> afaik the overlay doesn't work on omap3 without kernel patches
  • [19:03:36] <prpplague> anyone know off hand home much a dv355 board is?
  • [19:03:42] <mru> and certainly my patches make it work better
  • [19:05:26] <felipec> mru: but if I apply your patches?
  • [19:05:42] <mru> do you think gstreamer has omap-specific code?
  • [19:06:07] <ds2> prpplague: you looking for an official board or the cheapest?
  • [19:06:23] <felipec> mru: ah, so you mean mplayer's patches?
  • [19:06:28] <prpplague> ds2: i just need something i can use as a reference board for doing some jtag work
  • [19:06:48] <mru> I'm not aware of any mplayer patches for omapfb
  • [19:07:30] <mru> but why debate when we can simply check the source code?
  • [19:07:44] <prpplague> ds/join #davinci
  • [19:07:46] <prpplague> oops
  • [19:08:27] <ds2> one source has it for ~$600ish
  • [19:08:29] <prpplague> ds2: davinci seems to have the same icepick features as the omap3 stuff
  • [19:08:35] <prpplague> ds2: url?
  • [19:09:35] <ds2> http://www.spectrumdigital.com/index_orig.php?cPath=103&osCsid=bdd69db3484e76a9df95622f6f99687a
  • [19:09:41] * prpplague looks
  • [19:09:43] <ds2> there is a EVM board there
  • [19:09:58] <BThompson> also http://focus.ti.com/docs/toolsw/folders/print/tmdsevm355.html $495
  • [19:10:13] * prpplague wonders if the 5912 also has icepick
  • [19:10:16] <prpplague> BThompson: thanks
  • [19:11:36] <felipec> mru: check which sourcecode? afaik the fb is just an area of memory where you write, that's it, so any code using the fb should just work, including gstreamer... if the fb is implemented correctly
  • [19:12:12] <mru> the overlay uses omap-specific ioctls
  • [19:13:04] <ds2> mru: I am somewhat surprise it uses the fb1 interface. the TI original code has a v4l2 output device for overlays
  • [19:13:48] <mru> ds2: have you ever tried using v4l2?
  • [19:14:05] <ds2> mru: not me personally but I know someone who has
  • [19:14:16] <mru> I have, and it wasn't fun
  • [19:14:29] <ds2> =)
  • [19:14:38] <ds2> can't be worse then the camera interface }:-)
  • [19:14:51] <felipec> mru: so you mean it's not a standard fb?
  • [19:15:05] <mru> does standard fb have overlays?
  • [19:15:25] <ds2> AFAIK, each fb driver has its own way of doing it
  • [19:15:39] <felipec> mru: I don't know, I just want to output video
  • [19:15:40] <ds2> the PXA's have overlays and does use a second fb device but I think the ioctls are unique
  • [19:15:51] <mru> exactly
  • [19:17:53] <mru> I found the gstreamer source, and the fbdev output does demands rgb data
  • [19:18:07] <felipec> so FBIOGET_FSCREENINFO and FBIOGET_VSCREENINFO won't work?
  • [19:18:24] <ds2> those are standard ioctls
  • [19:18:39] <mru> they work, but they can't deal with overlays
  • [19:18:58] <felipec> mru: but I don't care about overlays, I just want to output video
  • [19:19:10] <mru> you need the overlay to get decent performance
  • [19:19:31] <felipec> mru: you mean the overlays accept yuv data?
  • [19:19:36] <mru> yes
  • [19:19:42] <mru> and it can do scaling
  • [19:19:50] <felipec> mru: that's cool, but first I would like to get something working
  • [19:20:02] <mru> omapfbplay works fine ;-)
  • [19:20:16] <felipec> mru: that uses the dspbridge
  • [19:20:24] <mru> no
  • [19:20:29] <mru> it uses the overlay
  • [19:20:38] <ds2> and neon
  • [19:20:38] <mru> I should know; I wrote it
  • [19:20:39] <felipec> mru: I would like to get something working that uses the dspbridge
  • [19:20:51] <mru> oh, why didn't you say so
  • [19:21:09] <mru> the you really don't want to use fbdev
  • [19:21:34] <felipec> mru: why not? I'm getting yuv data from the dsp
  • [19:21:50] <mru> well, you can use fbdev to configure the planes
  • [19:22:06] <mru> but you should have the dsp decode directly into the framebuffer
  • [19:22:49] <Crofton|work> | ./boost/detail/atomic_count_sync.hpp:40: error: invalid type argument of 'unary *'
  • [19:22:51] <felipec> mru: yeah. gstreamer handles that
  • [19:22:55] <Crofton|work> where line 41 is
  • [19:23:12] <Crofton|work> : "=&r" (v1), "+m"(value_), "=&r"(tmp)
  • [19:23:31] <Crofton|work> and value_ is mutable long value_;
  • [19:23:32] <mru> Crofton|work: need more context
  • [19:24:00] <felipec> mru: ah, apparently not, it's marked as todo
  • [19:24:07] <felipec> mru: but I can hack it
  • [19:25:35] <felipec> so /dev/fb0 and fb1 are not panes?
  • [19:25:50] <mru> fb0 is the main graphics plane
  • [19:25:53] <mru> fb1 is the first overlay
  • [19:26:11] <ds2> though a more appropiate name is fb0.1 ;)
  • [19:26:25] <mru> ds2: yes, but that's not how it is
  • [19:26:27] <felipec> mru: I see, so I need to configure fb1 to set the right size and yuv format?
  • [19:26:33] <mru> yes
  • [19:26:35] <ds2> mru: I know
  • [19:26:49] <mru> omapfbplay does all that
  • [19:26:50] <ds2> it would just be a mess if say I wanted to add another display via I2C
  • [19:26:57] <ds2> or use the second LCD Interface on the chip
  • [19:27:04] <mru> maybe you can hack it to use the codec engine instead of ffmpeg
  • [19:27:09] <felipec> mru: what is omapfbplay? isn't it a hacked mplayer?
  • [19:27:30] <mru> it's a minimal video player I wrote to show off ffmpeg on the beagle
  • [19:28:17] <felipec> mru: I guess I can check the sourcecode to see how to call the ioctrls
  • [19:28:59] <felipec> but first would like to see something on the screen (I don't even know if the fb is working)
  • [19:29:04] <ds2> mru: do you know if the ioctls are the same between the l-o kernel's fb driver and the reference kernel's fb driver?
  • [19:29:06] <felipec> cab I just echo something to /dev/fb?
  • [19:29:32] <felipec> ds2: by reference you mean omapzoom?
  • [19:29:55] <ds2> felipec: donno what the zoom folks are using at the moment
  • [19:30:34] <felipec> ds2: they have their own kernel repo... I guess they are using v4l2 sink there
  • [19:30:47] <ds2> felipec: got the url for the repo?
  • [19:31:05] <felipec> ds2: http://git.omapzoom.org/
  • [19:31:27] <ds2> the last time I looked at zoom, it was still a tarball download
  • [19:32:15] <ds2> felipec: yep, that's the reference driver
  • [19:32:22] <vlad_> I should really get our zoom(s) working
  • [19:32:41] <felipec> ds2: yeah, we've ben pusing them to put that... a few weeks ago they still didn't have the post update hooks for http
  • [19:32:45] <ds2> good luck, and god speed ;)
  • [19:33:07] <felipec> ah! I saw a pengiun on the screen for a fraction of a second... I think
  • [19:33:09] <vlad_> beagle was just much easier, given that I just stuck everything on a SDHC card, plugged it in, and it just worked
  • [19:33:25] <ds2> felipec: IMO, this is stupid... combine efforts with the l-o tree
  • [19:33:57] <felipec> ds2: yeap... I hope they will learn... eventually
  • [19:34:20] <felipec> ds2: at least it's not hidden in some internal clearcase repo
  • [19:34:36] <mru> don't say the cc word
  • [19:34:50] <ds2> hahahah
  • [19:34:59] <ahu> clearcase!
  • [19:35:01] <ds2> it is a very rational thing to say ;)
  • [19:35:05] <mru> haha
  • [19:35:30] <mru> people who design systems with exponential complexity should be shot
  • [19:35:39] <mru> (and exponential cost)
  • [19:35:42] <felipec> mru: word that
  • [19:36:03] <koen> jkridner|work: check http://scap.linuxtogo.org/
  • [19:36:04] <mru> clearcase is nothing but a glorified rcs
  • [19:37:10] <ds2> hey! stop insulting RCS!
  • [19:37:27] <artyomt> koen: nice
  • [19:37:37] * sakoman (n=sakoman@static-74-41-60-154.dsl1.pco.ca.frontiernet.net) Quit ("Ex-Chat")
  • [19:38:23] <koen> artyomt: 1 frame per minute :)
  • [19:38:47] <felipec> maybe a monster that started as a bad mutation of rcs
  • [19:39:22] * dirk2 (n=dirk@F307d.f.strato-dslnet.de) has left #beagle
  • [19:40:00] <felipec> mru: so do you know how can I quickly test that the fb is working?
  • [19:40:10] <mru> use omapfbplay
  • [19:40:55] <koen> it's included in the angstrom demo
  • [19:41:05] <artyomt> heh... during last year I completely migrated to laptop setups (with dock / monitor in office); but that's poses a problem now :) I can't do anything (yet) at home with beagle board (chuckle)
  • [19:41:08] <koen> its source lives at http://git.mansr.com/?p=omapfbplay;a=summary
  • [19:41:45] <koen> artyomt: some people accidentally bought new screens :)
  • [19:41:59] <vlad_> artyomt: Xvnc :)
  • [19:42:21] <artyomt> koen, its hard to compete with samsung 245T in office ;)
  • [19:42:50] <artyomt> vlad, is it already in angstrom ?
  • [19:43:05] <Crofton|work> mru, looks line I need to use "+m"(value_) as value_ is a local var
  • [19:43:19] <Crofton|work> but that leads to: Error: offset must be zero in ARM encoding -- `ldrex r3,[r0,#16]'
  • [19:43:28] <mru> Crofton|work: can you post the entire function?
  • [19:43:28] <Crofton|work> for strex also
  • [19:43:40] <Crofton|work> it is c++ :)
  • [19:43:53] <koen> worse, it's boost
  • [19:43:58] <felipec> btw, I haven't been able to boot most of Angstrom images (and I've really tried)
  • [19:44:15] <Crofton|work> http://rafb.net/p/PRb7h799.html
  • [19:44:31] <felipec> mru: if I try to use omafbplay I guess I should compile ffmpeg and omapfbplay
  • [19:44:32] <vlad_> artyomt: hrm, I dunno, it's pretty easy to build
  • [19:44:36] <Crofton|work> the +V is an attempt to stomp the offset
  • [19:45:39] <mru> yes, it needs to be +V
  • [19:45:46] <mru> my bad
  • [19:45:53] <mru> and &value_
  • [19:45:58] <felipec> koen: I haven't been able to boot your images
  • [19:46:01] <mru> no, scratch that
  • [19:46:12] <felipec> koen: just the beagle diagnostics
  • [19:46:25] <Crofton|work> I think the m stuff knows to do the &
  • [19:46:38] <Crofton|work> the +V doesn't help with the ofset
  • [19:47:26] <mru> weird
  • [19:47:31] <Crofton|work> no
  • [19:47:38] <Crofton|work> Rt must be an even numbered register, and not r14
  • [19:47:48] <Crofton|work> we can't let it auto pick registers
  • [19:48:06] <Crofton|work> unless we can constrain to even numbered register
  • [19:48:52] <mru> where do you read that?
  • [19:48:58] <mru> my manual says nothing of the kind
  • [19:50:03] <Crofton|work> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204h/Cihbghef.html
  • [19:50:04] <Crofton|work> maybe
  • [19:50:08] <Crofton|work> stupid frame
  • [19:50:56] * sakoman (n=sakoman@static-74-41-60-154.dsl1.pco.ca.frontiernet.net) has joined #beagle
  • [19:51:24] <felipec> gst-launch-0.10 videotestsrc num-buffers=1 ! filesink location=/dev/fb0
  • [19:52:42] <felipec> nothing =/
  • [19:53:05] <mru> Crofton|work: try +Q
  • [19:54:38] * RogerMonk (n=a0740758@nat/ti/x-35b64c06548f3e95) has joined #beagle
  • [19:55:41] <mru> the must be even requirement is only for ldrexd
  • [19:56:18] <Crofton|work> ah
  • [19:56:30] <mru> the web page is confusing
  • [19:56:48] <Crofton|work> no poop
  • [19:57:11] <Crofton|work> compiled
  • [19:58:04] <felipec> mru: is the format yuy2?
  • [19:58:18] <mru> yes
  • [19:58:33] <mru> any packed yuv4:2:2 format
  • [19:58:55] <mru> sadly, planar 4:2:0 isn't supported
  • [20:05:16] <Crofton|work> mru, can you look at the operator long() const real quick
  • [20:05:35] <mru> yes, what of it?
  • [20:05:53] <Crofton|work> why would they use the __sync operation there?
  • [20:06:03] <mru> no reason
  • [20:06:03] <Crofton|work> why not return value_
  • [20:06:24] <mru> unless you're on some nasty hardware with 16-bit memory bus, and no bus locking
  • [20:06:37] <mru> there are to my knowledge no such arm devices
  • [20:06:47] <Crofton|work> nor will there ever be?
  • [20:06:49] <felipec> mru: sinfo.yres = FFMIN(sinfo_p0.xres, st->codec->height) & ~15; <- shouldn't it be yres?
  • [20:07:04] <Crofton|work> ah so it may be necessary for x86?
  • [20:07:36] <mru> felipec: yes, good catch
  • [20:07:40] <mru> damn copy&paste
  • [20:11:26] <vlad_> koen: ping
  • [20:12:14] * bazbell (n=a0192809@nat/ti/x-72f6a8f6f478df9c) Quit ("Leaving.")
  • [20:13:09] <koen> vlad_: pong
  • [20:13:46] <vlad_> koen: for the fennec build, no patches are needed other than the jsautocfg patch?
  • [20:13:57] <vlad_> I thougt you had problems with nss as well
  • [20:14:48] <koen> vlad_: sed
  • [20:14:52] <koen> check the recipe
  • [20:15:15] <vlad_> oh there
  • [20:15:16] <vlad_> ok
  • [20:15:24] <vlad_> also, how can I set things up so that I can build without bitbake?
  • [20:15:43] <vlad_> that is, I want the PATH/env and configure command that's run.. just so that I can test changes more easily
  • [20:16:01] <koen> check work/armv7.../fennec-0.7-r3/temp/ for files called 'run*'
  • [20:16:38] <vlad_> ah great
  • [20:16:55] <Crofton|work> gnuradio detects boost ....
  • [20:19:27] <koen> vlad_: I updated the m-c revision this morning
  • [20:19:50] <vlad_> koen: I've already got rev=tip :)
  • [20:24:07] <vlad_> koen: so I don't know autoconf enough to put in the size checks in configure.in; so I'm thinking just a --with-jsautocfg=filename.h to configure.in
  • [20:24:15] <vlad_> does that sound reasonable?
  • [20:24:34] <koen> it's a start
  • [20:25:00] <vlad_> or if you want to point me at examples of autoconf type size checks :)
  • [20:25:30] <mru> vlad_: stdint.h
  • [20:25:34] <felipec> mru: http://gist.github.com/9528
  • [20:25:44] <vlad_> no, stdint.h is not an example of autoconf type size checks
  • [20:25:47] <vlad_> :p
  • [20:25:50] <felipec> nothing shows, so I guess it's not working
  • [20:26:34] <prpplague> jkridner|beagle: ping
  • [20:29:43] <felipec> vlad_: configure.in is old, you should use configure.ac
  • [20:29:45] <vlad_> koen: well, there's AC_CHECK_SIZEOF, but that's nost going to work
  • [20:29:50] <mru> vlad_: stdint.h is the reason why size checks are unnecessary
  • [20:31:08] <vlad_> mru: it's not to figure out which types to use, it's to figure out the size of the types
  • [20:31:12] <mru> felipec: does it print the correct size?
  • [20:31:13] <ds2> do not use autoconf!
  • [20:31:24] <mru> vlad_: why do you need to know the size?
  • [20:31:37] <mru> if you need a specific size, use [u]intXX_t
  • [20:31:40] <vlad_> mru: it's so that things like (offset * JS_BITS_PER_BYTE) / (JS_BITS_PER_DOUBLE + 1) can work
  • [20:31:53] <mru> bits per bytes is *always* 8
  • [20:31:57] <vlad_> or things like 1 << (JS_BITS_PER_WORD-1)
  • [20:31:59] <mru> except on old PDP machines
  • [20:32:06] <vlad_> sure, but it's cleaner than having an '8' in the code
  • [20:32:11] <felipec> mru: x=1024 y=768 mem_len=2097152
  • [20:32:16] <mru> there's also CHAR_BIT you can use
  • [20:32:19] <vlad_> regardless
  • [20:32:33] <vlad_> using stdint.h is not a problem that I want to solve
  • [20:32:37] <mru> and what's wrong with sizeof(double)?
  • [20:32:40] <vlad_> because using it doesn't solve the problem
  • [20:32:47] <vlad_> and I don't want to rewrite large chunks of js code that work
  • [20:33:01] <mru> js code that works.. hahahahaha
  • [20:33:13] * vlad_ rolls his eyes
  • [20:34:07] <mru> a recent starter at work had his first serious exposure to the js engine last week
  • [20:34:30] <mru> he was shocked to say the least
  • [20:34:39] <vlad_> by what?
  • [20:34:43] <vlad_> it's dense code
  • [20:34:47] <vlad_> but it's tightly owned and policed
  • [20:34:57] <mru> the UGLY code
  • [20:35:05] <vlad_> in his opinion, I guess
  • [20:35:06] <mru> the author may have been dense
  • [20:35:14] <mru> I share his opinion
  • [20:35:17] * koen gets popcorn
  • [20:35:30] <vlad_> koen: nah, no need for popcorn, this is a pointless discussion :)
  • [20:35:59] <mru> I've been working with that code on and off for over 3 years, and I still haven't figured out how it works
  • [20:36:01] <mru> if it works
  • [20:36:32] <vlad_> i'm confused, with spidermonkey?
  • [20:36:36] <mru> yes
  • [20:36:38] <koen> mru: think of it this way: speeding up js means speeding up the codec-engine buildsystem
  • [20:36:45] <vlad_> doing what?
  • [20:36:45] <mru> lol
  • [20:37:02] <mru> making sure it runs on the targets
  • [20:37:22] <mru> did you know that js_interpret() uses 1.5kB stack space on sh4?
  • [20:37:27] <mru> crap compiler
  • [20:37:33] <vlad_> but not actually getting involved in the community to try to fix/bring up/etc. the problems?
  • [20:37:47] <felipec> well, maybe I'll get fb working another day... time to go home
  • [20:37:52] * felipec (i=c0647cdb@gateway/web/ajax/mibbit.com/x-eb78bfa6a0185885) Quit ("http://www.mibbit.com ajax IRC Client")
  • [20:38:07] <mru> vlad_: no point, the bosses won't allow any major updates of our code anyway
  • [20:38:30] <mru> it's usually a case of chasing down the right fix in the mozilla cvs and backporting it
  • [20:38:54] <mru> or in the case of arm floating point endianness, not finding the fix
  • [20:39:40] <mru> btw, super-h has the same mixed endian doubles as fpa
  • [20:40:30] * hli (i=chatzill@vig91-2-82-232-97-149.fbx.proxad.net) Quit ("ChatZilla 0.9.83 [Firefox 3.0.1/2008070208]")
  • [20:43:41] * jkridner (n=jason@c-76-31-18-64.hsd1.tx.comcast.net) has joined #beagle
  • [20:46:46] <vlad_> mru: that's.. kinda shitty =/
  • [20:46:57] <vlad_> (not the fp issue, the no update thing)
  • [20:47:04] <vlad_> (though the fp issue is also crappy)
  • [20:49:24] * guillaum1 (n=Guillaum@AMontsouris-153-1-70-69.w90-2.abo.wanadoo.fr) has joined #beagle
  • [20:50:01] <koen> hmmm
  • [20:50:08] <koen> gtk 2.14 seems snappier than 2.12
  • [20:51:43] <mru> now compare with 1.x
  • [20:52:02] <mru> ever tried running a gtk2 app over a slow network connection?
  • [20:52:11] <koen> yes
  • [20:52:40] <koen> everytime someone screws up a commit 'meld' comes up
  • [20:52:55] <mru> did you notice the draw, clear, draw, clear, draw cycles it likes to do?
  • [20:53:21] <koen> no, I go out for coffee everytime that happens :)
  • [20:56:34] <vlad_> bah, I was hoping I could use this usb ethernet adapter without a powered hub
  • [20:57:50] * RogerMon1 (n=a0740758@nat/ti/x-90eb82229c4a03c3) has joined #beagle
  • [21:01:05] <Xenion> Gute Nacht alle miteinander ! :-) pennt jut und tr??umt was nettes !
  • [21:01:06] * jkridner_ (n=jason@c-76-31-18-64.hsd1.tx.comcast.net) Quit (Connection timed out)
  • [21:05:27] * RogerMonk (n=a0740758@nat/ti/x-35b64c06548f3e95) Quit (Remote closed the connection)
  • [21:07:44] <Crofton|work> koen, gnuradio trunk builds
  • [21:08:03] <Crofton|work> tomorrow I may ask you some questions about the QA errors
  • [21:08:08] <koen> heh
  • [21:08:18] <koen> "How do I disable the QA checks?"
  • [21:08:26] <Crofton|work> heh
  • [21:08:37] <Crofton|work> well, the pkgcondfig paths are bad
  • [21:08:45] <koen> sed
  • [21:08:48] <Crofton|work> and some symlinks to .so
  • [21:08:52] * Xenion (n=robert@p579FCA60.dip.t-dialin.net) Quit ("Verlassend")
  • [21:08:54] <koen> see the gmyth recipe
  • [21:08:59] * Crofton|work hears an echo
  • [21:09:35] <koen> do_compile_append() {
  • [21:09:35] <koen> sed -i -e s:${STAGING_DIR_TARGET}::g \
  • [21:09:35] <koen> -e s:/${TARGET_SYS}::g \
  • [21:09:35] <koen> gmyth.pc
  • [21:09:43] <koen> like that :)
  • [21:10:02] <koen> it needs to be in do_compile since you don't want to ship a broken .pc file in -dev packages
  • [21:10:40] <Crofton|work> damn, you were reading my mind
  • [21:12:45] <Crofton|work> I made a note about gmyth
  • [21:12:52] <Crofton|work> I'm going to ride my bike
  • [21:12:58] <Crofton|work> even though it is hot
  • [21:13:23] * geraint (n=gnorth@tu008.demon.co.uk) has joined #beagle
  • [21:17:11] * geraint_ (n=gnorth@tu008.demon.co.uk) has joined #beagle
  • [21:17:42] * BThompson (n=BThompso@nat/ti/x-4eca85f7795d2b9c) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [21:18:56] * Beagle7 (n=Beagle7@207.138.148.220) Quit ()
  • [21:35:41] * geraint (n=gnorth@tu008.demon.co.uk) Quit (Read error: 110 (Connection timed out))
  • [21:45:15] * TAK2004 (n=Administ@dslb-088-072-103-172.pools.arcor-ip.net) Quit (Read error: 104 (Connection reset by peer))
  • [21:48:53] * feig (n=ejf3@c-76-118-153-30.hsd1.ma.comcast.net) has joined #beagle
  • [22:09:48] <jkridner|beagle> I cannot believe we are *already* back at 0 boards available.
  • [22:10:22] <jkridner|beagle> boards are still arriving every week at Digi-Key, so I hope people aren't discouraged from buying.
  • [22:11:11] <jkridner|beagle> it is odd, because there were something like 180 on Friday (my math is probably bad).
  • [22:13:43] * prpplague (n=dave@mail.americanmicrosystems.com) Quit ("Leaving")
  • [22:20:28] * RogerMonk (n=a0740758@nat/ti/x-33e3b01cd98a4248) has joined #beagle
  • [22:23:59] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) has joined #beagle
  • [22:25:38] * prpplague (n=dave123_@ppp-70-244-162-73.dsl.rcsntx.swbell.net) has joined #beagle
  • [22:29:42] * RogerMon1 (n=a0740758@nat/ti/x-90eb82229c4a03c3) Quit (Remote closed the connection)
  • [22:34:33] * geraint_ (n=gnorth@tu008.demon.co.uk) Quit ()
  • [22:45:36] * t_s_o (n=tso@148.84-49-135.nextgentel.com) Quit ("Konversation terminated!")
  • [22:49:09] * jkridner|beagle (n=jason@nat/ti/x-5f614e041ca4acd1) Quit ("Powered by OE: www.openembedded.org")
  • [22:53:36] * robclark (n=robclark@nat/ti/x-a730a9e863de4ac7) Quit ()
  • [22:57:11] * chase_ (n=chase@d75-152-103-96.abhsia.telus.net) has joined #beagle
  • [22:59:23] <chase_> So.. anything I can do with a beagleboard that doesn't post anything to the screen, and doesn't really send anything over serial other than 40T and then some garbage?
  • [22:59:47] <chase_> NAND or SD
  • [22:59:57] <mru> 40T is a good sign
  • [23:00:13] <mru> it means the board is live and well, and is trying to find something to boot
  • [23:00:20] <chase_> I did have a glimmer of hope with the 40T
  • [23:01:02] <chase_> I've tried a few SD cards.. anything else I can do?
  • [23:02:14] <BThompson> so you say 40T is followed by garbage?
  • [23:02:24] <chase_> yup..
  • [23:02:43] <BThompson> if that is the case id double check your terminal settings, if you dont have the right UART settings on your terminal it will look like junk
  • [23:02:52] <chase_> just random ascii..
  • [23:02:54] <BThompson> the fact that stuff is coming across is a good sign
  • [23:03:03] <mru> a few random-looking characters is normal
  • [23:04:08] <chase_> occasionally get part of something... for example !_NET_WM_WINDOW_TYPE_DH#/
  • [23:04:19] <mru> that looks wrong
  • [23:07:49] <chase_> just guessing it's some random bits from memory..
  • [23:08:14] <chase_> nothing relevant
  • [23:08:26] * RogerMonk (n=a0740758@nat/ti/x-33e3b01cd98a4248) has left #beagle
  • [23:08:49] * Openfree (n=df@218.82.119.176) has joined #beagle
  • [23:11:54] <chase_> apparently the MLO_restore bootloader just doesn't want to boot...
  • [23:12:00] <chase_> err.. xloader
  • [23:16:42] <chase_> I'm not sure what it is.. but when something doesn't work.. it always just seems to help to show up on irc and ask.. then it will seem to start working
  • [23:25:25] <chase_> well it gets as far as Starting OS Bootloader...
  • [23:29:47] <chase_> any known issues with the xloader not being able a u-boot image
  • [23:29:51] <chase_> ?
  • [23:30:10] <mru> is this from SD?
  • [23:30:30] <chase_> ya
  • [23:31:43] <chase_> possibly a filesystem error with mkfs.msdos or something?
  • [23:36:58] * jkridner|work (n=a0321898@nat/ti/x-d7757602003576b3) Quit ("Leaving.")
  • [23:45:36] * bazbell (n=a0192809@nat/ti/x-ea1243afd235455e) has joined #beagle