• [01:00:04] * esden`aw` (n=esden@repl.esden.net) has joined #beagle
  • [01:02:15] * bazbell (n=a0192809@nat/ti/x-c0da236d7ba58428) Quit ("Leaving.")
  • [01:07:15] * esden`away (n=esden@repl.esden.net) Quit (Read error: 110 (Connection timed out))
  • [01:28:38] * khasim (n=a0393720@192.163.20.231) has joined #beagle
  • [02:11:03] <jkridner> good morning khasim
  • [02:59:33] * khasim (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [03:16:34] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [04:10:24] * Olipro_ (i=Olipro@unaffiliated/olipro) has joined #beagle
  • [04:24:51] * Olipro (i=Olipro@unaffiliated/olipro) Quit (Nick collision from services.)
  • [04:24:54] * Olipro_ is now known as Olipro
  • [04:28:23] * rsalveti (n=salveti@189.70.140.74) Quit (Read error: 110 (Connection timed out))
  • [05:06:20] * khasim (n=a0393720@192.163.20.231) has joined #beagle
  • [06:32:34] <koen> good morning all
  • [06:39:23] <ldesnogu> hi koen
  • [07:56:08] <khasim> Good Morning Koen
  • [07:57:40] <khasim> jkridner: I am sorry, I always miss replying your wishes... I am still not getting used to opening IRC to start with.. may be I have start with IRC first...
  • [08:06:24] <koen> ah, Paul Walmsley now has a beagle board :)
  • [08:19:37] <mru> morning
  • [08:28:58] <ldesnogu> hi mru
  • [08:29:12] <ldesnogu> so is the manual useful? or is it too cryptic? :)
  • [08:30:11] <mru> it's roughly what I expected
  • [08:31:09] <ldesnogu> BTW is oprofile stable for you now?
  • [08:31:32] <mru> I haven't had more crashes with it than without lately
  • [08:31:39] <mru> maybe it was never to blame
  • [09:09:33] * ali_as_ (n=ali_as@ambix.plus.com) has joined #beagle
  • [09:14:46] * ali_as (n=ali_as@ambix.plus.com) Quit (Read error: 110 (Connection timed out))
  • [09:49:13] * lardman|gone is now known as lardman
  • [10:22:36] * Blackhold (n=Blackhol@203.Red-80-34-166.staticIP.rima-tde.net) has joined #beagle
  • [10:22:39] <Blackhold> hello
  • [10:26:31] * RogerMonk (n=a0740758@nat/ti/x-af0eebf084234d72) has joined #beagle
  • [11:02:59] <koen> there, some progress on link and CE
  • [11:03:14] <koen> http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=commitdiff;h=010bc5e0f30741d04029f00d3379fe74227f86dc
  • [11:03:19] <koen> http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=commitdiff;h=3cb3a99522e2151c2003a573fdb3f89bb4c3ff31
  • [11:13:24] <koen> Crofton|work: new project or the usrp: http://www.pagetable.com/?p=32 ?
  • [11:18:53] * Beagle2 (n=Beagle2@port80.ds1-abc.adsl.cybercity.dk) has joined #beagle
  • [11:20:02] * Beagle2 (n=Beagle2@port80.ds1-abc.adsl.cybercity.dk) Quit (Client Quit)
  • [11:30:22] <Crofton|work> koen, no need for usrp, you can get enough samples with stock sound card
  • [11:30:32] <Crofton|work> but the signal processing would be fun
  • [11:34:29] <RogerMonk> Koen : re: http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=commitdiff;h=010bc5e0f30741d04029f00d3379fe74227f86dc
  • [11:34:34] * rsalveti (n=salveti@189.70.140.74) has joined #beagle
  • [11:34:48] <koen> RogerMonk: yes?
  • [11:34:48] <RogerMonk> Nice work - we need to be careful though just blindly copying the libraries
  • [11:35:07] <RogerMonk> The library name will be auto-gen'd as part of the configuration step
  • [11:35:15] <koen> RogerMonk: I'm using the neuros config script as guideline
  • [11:35:27] <koen> RogerMonk: you mean the X5854MGGH stuff?
  • [11:35:28] <RogerMonk> (yep, but maybe that needs reviewing)
  • [11:36:23] <koen> I get the impression that currently I have the best knowledge of CE and link compared to the neuros people I talk to :(
  • [11:36:38] <koen> I my knowledge is virtually zero
  • [11:36:50] <RogerMonk> when the xdc tools run to configure the app, the individual packages will respond back with the relevant library names, based on target architecture/os/app config params/ etc
  • [11:37:12] <RogerMonk> Do you have an example from neuros that I could look at - I want to see what they are doing
  • [11:38:15] <koen> RogerMonk: this is the script from neuros that vlc is using: http://rafb.net/p/g50X7T36.txt
  • [11:38:48] <koen> the neuros makefile only builds the kernel modules (cmemk and dsplinkk)
  • [11:39:04] <RogerMonk> ok - let's chat with neuros to figure this out...
  • [11:39:41] <RogerMonk> Have you been able to build the CE 'copy' examples yet?
  • [11:40:01] <RogerMonk> ti/sdo/ce/examples
  • [11:40:25] <RogerMonk> This will tell us if the CE examples are ok with OE gcc, etc
  • [11:42:21] <koen> hmmm
  • [11:42:40] <koen> the CE dirstructure seems to be designed by Escher
  • [11:43:24] <koen> ok, I'm now in codec_engine_2_10_01/examples/ti/sdo/ce/examples
  • [11:43:40] <RogerMonk> which target are you on?
  • [11:43:49] <RogerMonk> 6446?
  • [11:44:06] <RogerMonk> 2.10 is 6446, 2.05 is OMAP/Beagle
  • [11:45:10] <koen> DM320, that should have 6446
  • [11:45:25] <koen> ../../../../../xdcpaths.mak:152: *** CE_INSTALL_DIR is set to "_your_CE_installation_directory_/codec_engine_2_10_01", which is invalid (could not find file "_your_CE_installation_directory_/codec_engine_2_10_01/packages/ti/sdo/ce/package.xdc"). Set this in <codec engine examples>/xdcpaths.mak! See the build documentation to correct this error.. Stop.
  • [11:45:28] <RogerMonk> nope - DM320 is different again
  • [11:46:00] <RogerMonk> yep, you need to follow the instructions in the release notes at the top of the install
  • [11:46:06] <koen> Machine: Neuros OSD 644x Revision A
  • [11:46:23] <RogerMonk> Ok, not DM320, DM6446
  • [11:46:26] <RogerMonk> good
  • [11:47:23] <RogerMonk> (sorry in 'examples/build_instructions.html')
  • [11:48:28] <RogerMonk> basically need to fill out xdcpaths.mak to point to BIOS install package, XDC install package and CE install package
  • [11:48:29] <koen> hmmm
  • [11:48:42] * koen fires up lynx
  • [11:49:21] <RogerMonk> and user.bld to point to the toolchains for ARM/DSP
  • [11:49:33] <RogerMonk> (cgtoolsRootDir)
  • [11:51:55] <koen> hmmm, more files to edit
  • [11:52:14] <RogerMonk> yep, for these examples
  • [11:52:25] <RogerMonk> should be pretty quick though for test
  • [11:53:07] * koen mutters some more
  • [11:53:21] <koen> I'll save the examples for after lunch
  • [11:53:25] <koen> bbl
  • [11:53:30] <RogerMonk> Have you already unpacked BIOS/XDC/DSPCGTOOLS inside OE tools area?
  • [11:53:36] <RogerMonk> Ok - lemme know
  • [12:17:13] * BThompson (n=BThompso@nat/ti/x-b58f6fffc5bca361) has joined #beagle
  • [12:19:48] * lardman is now known as lardman|lunch
  • [12:38:37] <jkridner> koen, RogerMonk: need any help on LRL demos?
  • [12:38:46] <jkridner> are we all set?
  • [12:49:32] * rsalveti (n=salveti@189.70.140.74) Quit (Read error: 110 (Connection timed out))
  • [12:50:55] <koen> jkridner: I'd like to test the 3d demos ahead of time
  • [12:51:16] <koen> jkridner: but RogerMonk got stuck in meetings yesterday so he couldn't upload the demos
  • [12:51:26] <jkridner> khasim: you there?
  • [12:51:38] <jkridner> koen: are you planning to use the same kernel to avoid rebooting?
  • [12:52:22] <jkridner> are you going to move both demos to the 2.6.24 kernel?
  • [12:53:09] <koen> jkridner: the plan was to use WTBU for the 3d demos
  • [12:53:26] <jkridner> only the 3D demos?
  • [12:53:58] <koen> jkridner: I suspect mru will use his own kernel for the movie stuff, since it needs patches to work (resolution, frequency control, etc)
  • [12:54:41] <koen> I'd like to test the demos ahead of time
  • [12:54:56] <koen> I hope I'll have some time on friday when I'm at the TI office
  • [12:55:01] <jkridner> certainly. it is crazy to not test them ahead of time.
  • [12:55:18] <Crofton|work> what? You guys test demos?
  • [12:55:45] <koen> what? we test anything at all?
  • [12:57:07] <jkridner> k, so you need the 3D demos. I guess you have the demo for the movie stuff all ready to go?
  • [12:57:14] <jkridner> are you planning to read uImage off of SD cards?
  • [12:57:51] <koen> yes, AIUI xload and uboot are in nand
  • [12:58:16] <jkridner> The 3D demos I have aren't well automated. You have to invoke each demo and I don't know how to kill them once they start (well, I know I can SSH in and kill -9 them).
  • [12:58:41] <koen> jkridner: mru has to select a resolution we're going to use for the demos (at least the video one)
  • [12:59:08] <koen> for desktop like demo's I'd like to use the native resolution of the screen (or a fraction of it) to avoid blurring
  • [12:59:10] <jkridner> k. so, you are going non-windowed for the video?
  • [12:59:36] <koen> the video demos write directly to the overlay and use the full width
  • [12:59:56] <koen> so you'd get a video in the center and noise on the sides
  • [13:00:43] <koen> maybe mru can code a small x wrapper to draws a window around that area or something
  • [13:03:35] <sakoman__> good morning
  • [13:04:10] * dschaeffer (n=daniel@timesys-gw0.cust.expedient.net) has joined #beagle
  • [13:05:47] <koen> hey sakoman__
  • [13:06:01] <koen> jkridner: iirc we have 3 screens + beagles
  • [13:06:22] <koen> jkridner: so we could use one screen exclusively for demoing 720p video
  • [13:06:22] <sakoman__> koen: sadly serialfix.diff doesn't fix the serial hang
  • [13:06:27] <jkridner> k.
  • [13:06:32] <koen> sakoman__: I noticed :(
  • [13:07:08] <koen> jkridner: mru has an uboot that clocks the beagle at 600MHz, that would be neat for the demos
  • [13:07:15] <sakoman__> Interestingly though, it seems all terminal input has gone wonky
  • [13:07:43] <sakoman__> USB keyboard input to a xterm window doesn't work either
  • [13:07:55] <sakoman__> The mouse however still functions
  • [13:08:02] <jkridner> the 2.6.24 (wtbu) kernel supports, I believe, going up to 600MHz at run-time, but you have to prod it to do so.
  • [13:08:11] * BThompson (n=BThompso@nat/ti/x-b58f6fffc5bca361) Quit (Remote closed the connection)
  • [13:08:31] <sakoman__> Using the mouse with xkb also won't get you terminal input
  • [13:08:34] <jkridner> that is the way we normally run the processor (idle/500MHz/600MHz-under-high-load).
  • [13:11:03] * rsalveti (n=salveti@200.184.118.132) has joined #beagle
  • [13:13:17] <sakoman__> koen: can't build beagleboard-demo-image :-( gst-ffmpeg fails: http://www.sakoman.net:8000/public/logs/136405.txt
  • [13:13:42] <sakoman__> clean build from oe.dev
  • [13:15:18] <koen> lets see it it builds here
  • [13:15:42] * BThompson (n=BThompso@nat/ti/x-3b16a36fb82fbbee) has joined #beagle
  • [13:16:20] <Crofton|work> crap, I always type ipkg, then remember it is supposed to be opkg
  • [13:17:03] <koen> sakoman__: http://thread.gmane.org/gmane.linux.ports.arm.omap/9278/focus=9445
  • [13:20:40] * ted616 (i=ted@207.236.18.82) has joined #beagle
  • [13:25:06] <Crofton|work> crap 1 euro = 1.60 usd
  • [13:25:16] * Crofton|work cries
  • [13:27:26] <bjdooks> 1 ukp = 2.0 USD
  • [13:27:40] <bjdooks> which is great for me buying PCBs, but crap when trying to sell anything to the US
  • [13:28:00] <Crofton> beagle boards are getting cheaper .....
  • [13:29:22] <koen> yeah, sub ???100 now
  • [13:30:12] * ldesnogu (n=ldesnogu@fw-tnat.cambridge.arm.com) Quit ("Leaving")
  • [13:32:36] * ldesnogu (n=ldesnogu@fw-tnat.cambridge.arm.com) has joined #beagle
  • [13:38:23] * prpplague (n=dave@mail.americanmicrosystems.com) has joined #beagle
  • [13:41:48] <koen> sakoman__: I get the same error as well now
  • [13:43:09] * koen scratches head
  • [13:48:10] <koen> sakoman__: I think I fixed the problem you were seeing
  • [13:49:36] * lardman|lunch is now known as lardman
  • [13:57:14] <koen> RogerMonk: xdctools are part of dspbios, right?
  • [13:57:27] <RogerMonk> they are, but you shouldnt use that version
  • [13:57:34] <koen> ah
  • [13:57:46] <RogerMonk> I'll send u link
  • [13:58:33] <koen> If I figure out how to build all this I could make a shitload of money explaining to other people ;)
  • [13:59:24] <RogerMonk> ... it's not that bad... I'll help
  • [13:59:43] <RogerMonk> (as long as I get a cut of the profits :)
  • [14:00:14] <koen> I'm so used to OE where you'd just say "bitbake codec-engine" and on the device do "opkg install codec-engine" to get everything working
  • [14:00:40] <RogerMonk> I know, and hopefully we can get there here too
  • [14:02:49] <RogerMonk> (man... I wish you were coming to the UK a few days earlier so we could flush this out together...)
  • [14:05:19] <sakoman__> koen: thanks for looking at gst-ffmpeg! I'll try your fix
  • [14:06:11] <sakoman__> koen: it always seems really hard to get people to part with those shitloads of money!
  • [14:06:32] <DJWillis> sakoman__: Amen to that.
  • [14:06:38] <sakoman__> open source means it ought to be free
  • [14:07:05] <sakoman__> so you should do it for the sheer joy of it
  • [14:10:47] <koen> opensource != free software :)
  • [14:10:54] <koen> (both meanings of free)
  • [14:11:19] <sakoman__> FWIW, since setting the i2c-1 data rate to 400 I have had zero broken boots
  • [14:12:33] <sakoman__> Not sure whether there are any significant downsides to slowing communications with the twl4030. Perhaps one of the TI experts can comment on any likely side effects
  • [14:12:59] <Crofton> free as in freedom, and not that we work from soup kitchens :)
  • [14:15:55] <sakoman__> I suspect a rate somewhere between 400 and 2600 is possible. It would be good for someone at TI to probe the i2c comm signals and recommend a rate that is safe based on signal quality
  • [14:15:59] * bjdooks is considering whether to visit the LugRadio think at the weekend
  • [14:16:16] <bjdooks> s/think/thing/g
  • [14:17:25] <suihkulokki> isn't that the last one they'll do?
  • [14:18:33] * gadiyar (n=a0393673@192.163.20.231) has joined #beagle
  • [14:20:38] * RogerMonk is running 3d graphics on beagle.... looks sweet!
  • [14:25:28] * jkridner_ (n=jason@c-76-31-18-64.hsd1.tx.comcast.net) has joined #beagle
  • [14:28:30] <koen> RogerMonk: btw: serial adaptors for the beagle, do you any we can use at LRL?
  • [14:29:14] <koen> my db25 -> db25 -> db9 soldered abomination wouldn't survive transport I'm affraid
  • [14:29:50] <koen> I do have usb-> db9 male that works
  • [14:32:06] * jkridner (n=jason@c-76-31-18-64.hsd1.tx.comcast.net) Quit (Read error: 110 (Connection timed out))
  • [14:33:12] * jkridner_ (n=jason@c-76-31-18-64.hsd1.tx.comcast.net) Quit ()
  • [14:36:48] <koen> sakoman__: 400kHz should be plenty fast to run i2s, right?
  • [14:40:34] * gadiyar (n=a0393673@192.163.20.231) has left #beagle
  • [14:43:10] <ted616> hello all, I am using the angstrom-demo rootfs on my zoom mdk
  • [14:43:35] <ted616> after a long time boot, I can see the login on the serial console
  • [14:44:10] <ted616> but I didn't see any GUI on the LCD on the zoom mdk and also no screen on the external LCD connected by the DVI-VGA
  • [14:44:30] <koen> does the zoom have a standard framebuffer?
  • [14:44:33] <koen> e.g. /dev/fb0?
  • [14:44:55] <ted616> yes, because I can see the angstrom booting image on the ZOOM MDK
  • [14:45:17] <ted616> but after the LCD trunes to green after I see the log in on the serial console
  • [14:45:48] <ted616> also the external LCD connected by the DVI-VGA was never on
  • [14:45:53] <koen> what's the resolution of /dev/fb0?
  • [14:46:09] <koen> it could be that kdrive doesn't know the resolution and bails out
  • [14:46:25] <koen> (yes, that is braindead behaviour, blame keith packard)
  • [14:46:25] <ted616> I am not sure if I can use the DVI-VGA to my VGA LCD monitor?
  • [14:46:45] <ted616> by using fbset I can see it as 640x480
  • [14:47:03] <koen> hmmm, 640x480 should work
  • [14:47:17] <koen> what happens if you type 'Xfbdev &' on the serial console?
  • [14:47:22] <ted616> koen: the default display is on board LCD or the external monitor?
  • [14:47:46] <koen> no idea
  • [14:47:50] <koen> I don't have a zoom :)
  • [14:48:09] <ted616> haven't try that yet. I'll try that at home after the work
  • [14:48:22] <koen> i2c_omap i2c_omap.1: bus 1 rev3.12 at 400 kHz
  • [14:48:22] <koen> i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz
  • [14:48:22] <koen> i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz
  • [14:48:24] <koen> there we go
  • [14:49:47] <ted616> thanks koen. I think the problem is the setting of the fb0
  • [14:49:59] <sakoman__> koen: let me know how it works for you!
  • [14:50:27] <sakoman__> Doesn't seem to have any adverse affect on audio functions
  • [14:50:39] <sakoman__> but those aren't super time critical
  • [14:51:25] <Blackhold> hello
  • [14:51:40] <Blackhold> could someone give me some help on beagle on web format?
  • [14:52:43] * ted616 (i=ted@207.236.18.82) Quit ()
  • [14:57:26] * khasim (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [15:03:09] * jkridner|work (n=a0321898@nat/ti/x-0fe5280158ff5dc5) has joined #beagle
  • [15:04:18] <koen> sakoman__: no noticable changes with running i2c at 400kHz :(
  • [15:05:00] <Crofton> Blackhold, see topic?
  • [15:05:36] <sakoman__> koen: bummer! I still haven't gotten any i2c-1 errors. I wonder what is going on here?
  • [15:06:04] <sakoman__> koen: so you still get boots where i2c-1 is wonky?
  • [15:08:04] <Blackhold> ok sorry
  • [15:11:47] * Blackhold (n=Blackhol@203.Red-80-34-166.staticIP.rima-tde.net) has left #beagle
  • [15:15:36] * BThompson (n=BThompso@nat/ti/x-3b16a36fb82fbbee) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [15:16:09] * BThompson (n=BThompso@nat/ti/x-5e1c138bf2a21eb1) has joined #beagle
  • [15:25:12] * BThompson (n=BThompso@nat/ti/x-5e1c138bf2a21eb1) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [15:25:18] * trickie is now known as trickie|away
  • [15:25:36] * BThompson (n=BThompso@nat/ti/x-8a475a4a17ecbc30) has joined #beagle
  • [15:29:34] <koen> sakoman__: still i2c errors in u-boot, about the boot now continues, still oopses when trying to play sound over twl
  • [15:29:56] <koen> s/about/but/
  • [15:32:13] <sakoman__> koen: you get i2c errors in u-boot?
  • [15:32:28] <sakoman__> what do they look like? I've *never* seen that!
  • [15:33:16] <koen> timed out in wait_for_pin: I2C_STAT=0
  • [15:33:16] <koen> I2C read: I/O error
  • [15:33:49] <sakoman__> Which version of u-boot are you using?
  • [15:34:03] <koen> yours, r7 iirc
  • [15:34:10] <sakoman__> u-boot uses an extremely conservative data rate of 100 Khz
  • [15:34:12] <koen> the one where you did stuff with the pullups
  • [15:35:21] <sakoman__> That just affects i2c-2. U-boot only uses i2c-1 IIRC
  • [15:35:50] <koen> a cold reset gets rid of the erros
  • [15:35:53] <koen> +r
  • [15:36:00] <sakoman__> I wonder if we are looking at multiple issues
  • [15:37:07] <sakoman__> If you have a boot with no u-boot errors, do you see i2c-1 errors from linux (@400Khz)?
  • [15:38:47] <sakoman__> I never got a u-boot i2c error but would get very frequent linux i2c-1 errors that would be solved by a reboot. Those linux errors are the ones that went away for me.
  • [15:41:11] <koen> i2c-1 errors always came together with audio troubles for me
  • [15:42:24] <sakoman__> koen: understandable, audio setup requires a flurry of i2c transactions to complete successfully
  • [15:42:44] <sakoman__> If i2c is hosed bad things will happen
  • [15:44:03] <sakoman__> If you are getting i2c errors in u-boot it seems that something really fundamental is broken
  • [15:44:51] <koen> i'm not getting them all the time
  • [15:45:00] <sakoman__> maybe reset issues, or maybe some register isn't getting initialized properly
  • [15:45:05] <koen> but I do need to remove power to get rid of them
  • [15:45:09] <banderson> sakoman: just got this error (with i2c.1 at 400 on evm) i2c_omap i2c_omap.1: controller timed out
  • [15:45:20] <banderson> twl4030_rtc: twl4030_i2c_read error
  • [15:45:29] <banderson> twl4030_rtc twl4030_rtc: hctosys: unable to read the hardware clock
  • [15:45:34] <banderson> then boot halted
  • [15:46:26] <sakoman__> sounds like we really need to look at u-boot setup for i2c
  • [15:46:30] <banderson> going to do quick sanity check to make sure I am seting it up right.
  • [15:47:34] <koen> sakoman__: if all else fails we can just blame the mask-rom ;)
  • [15:48:41] <koen> RogerMonk: could you put the 3d stuff on ftp?
  • [15:49:20] <sakoman__> koen: it would be really interesting to look at the i2c signals on your board during one of the bad power ups
  • [15:49:46] <sakoman__> too bad you don't know any EE's
  • [15:49:49] <sakoman__> ;-)
  • [15:50:05] <koen> *cough*
  • [15:50:24] * lardman is now known as lardman|gone
  • [15:53:58] <banderson> Hey I think I have a i2c protocol analyzer somewhere....think it is called the beagle...:)
  • [15:54:05] <banderson> http://www.totalphase.com/products/beagle_ism/?gclid=CPKaq4agwpQCFSgtagodbw3WEw
  • [15:54:40] <sakoman__> banderson: that is funny!
  • [15:56:02] <sakoman__> I've got one too (not a beagle). I've just got so many things on my to do list that I'm afraid of going down that path for fear it would suck up to much time
  • [15:56:25] <sakoman__> s/to/too/
  • [15:56:40] <sakoman__> I've been really bad with my oo's lately
  • [15:59:16] * walter (n=walter@host121.natpool.mwn.de) has joined #beagle
  • [16:02:49] <koen> google is funny: http://maps.google.com/maps?f=d&hl=nl&geocode=14019794172810323999,52.238300,-0.907100&saddr=52.2383,+-0.9071&daddr=800+Pavilion+Drive,NN4+7YL+,+northampton+,+United+kingdom&mra=cc&dirflg=r&sll=52.229797,-0.884228&sspn=0.042372,0.099049&ie=UTF8&z=13
  • [16:06:40] * RogerMonk (n=a0740758@nat/ti/x-af0eebf084234d72) Quit (Remote closed the connection)
  • [16:08:49] <sakoman__> banderson: are i2c-1 errors common on your evm?
  • [16:09:04] <sakoman__> They are extremely rare on mine
  • [16:14:24] * dirk2 (n=dirk@F32d8.f.strato-dslnet.de) has joined #beagle
  • [16:14:31] <dirk2> koen: ping
  • [16:15:08] <koen> pong
  • [16:15:36] <dirk2> have only some minutes today, but read in logs about uboot i2c timeout issue
  • [16:15:59] <dirk2> I saw these, too. But depending on compiler.
  • [16:16:46] <dirk2> Building uboot with CSL2008 I have these issues, with 2007 (q3?) not
  • [16:16:56] <KeyserSoze> anyone know max or nominal power consumption of the beagle board? I didn't see it in the hardware manual or wiki page
  • [16:17:14] <koen> dirk2: building with the wrong compiler will get you those errors all the time
  • [16:17:20] <koen> dirk2: I get them sometimes
  • [16:17:23] <banderson> sakoman: it feels like they are common on evm
  • [16:17:47] <koen> KeyserSoze: it's powered from usb, so max power is 0.5A times 5 volt
  • [16:17:54] <banderson> sakoman: not every time but 1 in 5 maybe (boots) and once I get them only hard reboot works
  • [16:17:56] <dirk2> koen: with 2007q3?
  • [16:18:09] <KeyserSoze> yeah, i assumed it wouldn't draw more than USB can provide
  • [16:18:29] <KeyserSoze> just curious if it's actual max is lower
  • [16:18:30] <koen> dirk2: no gcc 4.3.1
  • [16:18:57] <sakoman__> dirk2: I am building the same way koen is and I don't get those errors
  • [16:19:35] <dirk2> I thought uboot I2C errors are only compiler dependent.
  • [16:20:40] <dirk2> koen, sakoman: Maybe you can exchange uboot binaries and cross check? If interested I can send a 2007q3 uboot.bin the next days for test.
  • [16:20:54] <koen> I'm using the uboot sakoman built :)
  • [16:21:05] <dirk2> okay ;)
  • [16:21:52] <koen> oooooh, new beagle youtube vinds
  • [16:22:05] <koen> -n
  • [16:22:16] <sakoman__> KeyserSoze: my bench supply reads 370ma at the login prompt. that is with a 1G mmc card installed
  • [16:23:11] <koen> hmm, 25mA more than before
  • [16:23:29] <KeyserSoze> sakoman__: is that at full clock speed? or does it dynamically reduce clock speed when idle?
  • [16:23:29] <koen> does twl audio draw that much?
  • [16:23:54] <sakoman__> dirk2: I recall fixing u-boot in a couple of places to remove infinite loops that were compiler dependent
  • [16:24:22] <sakoman__> koen: I doubt that it affects power too much
  • [16:24:47] <sakoman__> KeyserSoze: that figure is without cpuidle enabled
  • [16:24:54] <koen> I'm curious how much power will be when omap goes into idle
  • [16:24:57] <KeyserSoze> sakoman__: thanks
  • [16:26:38] <dirk2> sakoman__: And I think to remember that Nishant mentioned that I2C code of uboot v1 is, well, 'unclean' :(
  • [16:26:41] <sakoman__> koen: back when cpuidle patches worked I seem to recall it being in the 10's of ma range
  • [16:27:01] <ds2> is there a test point where I2C-1 can be probed?
  • [16:27:23] <dirk2> btw: Does anybody have mru's 600MHz uboot changes in source?
  • [16:27:35] <ds2> if so, maybe someone can record the bus on the beagle with a beagle I2C analyzer to make sure everything is sane
  • [16:27:39] <bjdooks> i'll be suprised if you get a lot, unless the cpu-idle is taking the sdram interface into idle... my own measurements only show gains in power by slowing the memory interface down, the arm-core itself will consume little power when idling
  • [16:27:48] <sakoman__> ds2: on beagle r11 and r12
  • [16:28:05] <sakoman__> ds2: sadly there are no silk screen legends for those resistors
  • [16:28:17] <sakoman__> many resistors seem to be missing silk screen legends
  • [16:28:32] <ds2> sakoman__: you have a I2C analyzer?
  • [16:28:54] <sakoman__> I have a logic analyzer that has an i2c mode
  • [16:29:19] <sakoman__> and a scope ;-)
  • [16:29:21] <ds2> can it record a lot of stuff?
  • [16:29:40] <sakoman__> Yeah, it can record a fairly large number of transactions
  • [16:29:45] <banderson> verified I am running i2c.1 at 400...still get halt on ic2.1
  • [16:29:59] <ds2> be interesting to compare a trace at 2600 and one at 400
  • [16:30:26] <sakoman__> ds2: koen is getting errors at 100!
  • [16:30:34] <ds2> should probally verify that the 400 setting does result in a 400KHz clock; just in case the multipliers are set right
  • [16:30:37] <sakoman__> banderson is getting them at 400
  • [16:31:00] <ds2> sakoman__: it could be the 400 does not mean 400KHz due to a clock problem elsewhere so it would be good to eliminate this
  • [16:31:02] <sakoman__> And I got them at 2600 but no longer get them at 400
  • [16:31:18] <sakoman__> ds2: you are correct of course
  • [16:31:43] <ds2> sakoman__: if your scope is a DSO, that should be a trivial exercise
  • [16:32:03] <sakoman__> once I find the proper point to probe ;-)
  • [16:32:08] <ds2> hahah
  • [16:32:19] <ds2> beagle vs beagle : http://www.totalphase.com/products/beagle_ism/
  • [16:32:21] <sakoman__> tougher with no ss legends :-(
  • [16:32:29] * dirk2 (n=dirk@F32d8.f.strato-dslnet.de) has left #beagle
  • [16:34:11] <banderson> Has anyone sucessfully built meta-toolchain recently in oe (for beagle or evm?)
  • [16:34:27] <koen> no, gcc-cross-sdk 4.3.1 doesn't work
  • [16:34:39] <koen> building it kills your staging include dir as well
  • [16:34:49] <banderson> I see ...thats probably why it fails :)
  • [16:34:57] <koen> gcc runs their fix-includes script on every header in the includepath
  • [16:35:30] <banderson> any options as far as producing a sdk?
  • [16:35:32] <koen> when looking at the logs I went "hmmm, libavcodec.h doesn't like like a gcc header..."
  • [16:35:45] <koen> banderson: not at the moment, just use OE :)
  • [16:35:51] <banderson> ok
  • [16:36:56] <koen> the openmoko people are funny
  • [16:37:03] <koen> first they go "we need an sdk!!!"
  • [16:37:22] <koen> then they go "packaging is hard!!!"
  • [16:39:06] <bjdooks> koen: i've given up trying to track what they do, unless they explicitly ask me to review something i'm leaving them to play in their own little sandpit
  • [16:39:21] <banderson> So now that I tried building it should I rm tmp? (assuming that killing my staging include dir is bad...)
  • [16:39:52] <koen> bjdooks: every new employee says "you need to do <foo> different!!!" and management agrees
  • [16:40:35] <koen> bjdooks: they hired a qt guy -> switch to qt, hire an efl guy -> efl stuff, hire fedora guy -> talk about using fedora on the phone, etc
  • [16:41:17] <bjdooks> it is difficult to find the right tool for the job...
  • [16:41:29] <koen> it's difficult to grow a spine
  • [16:41:49] <koen> I dread what would happen if they would hire HURD or BSD advocates ;)
  • [16:42:11] <bjdooks> then again, finding a distribution that doesn't suck is difficult
  • [16:42:27] <bjdooks> debian is ok if you have a nice amount of storage (ie, can afford to stick a rotating hd in it)
  • [16:43:10] <sakoman__> jkridner|work: would it be possible for you to identify R11 and R12 on the Beagle layout so we can attempt to look at the i2c-1 signals?
  • [16:43:40] <sakoman__> Seems that not all R's have SS legends
  • [16:43:48] <bjdooks> hmm, other than seeing a beagle irl, the LRL hasn't got a lot interesting for me...
  • [16:44:26] <sakoman__> jkridner|work: and after much searching I think R11 and R12 are among them
  • [16:44:51] <bjdooks> hearing Matt Garret's latest views on power management might be interesting, everything else isn't very interesting to a kernel dev
  • [16:46:35] <bjdooks> how many of you lot will be there on Sunday?
  • [16:51:43] <sakoman__> ds2: the signals for i2c-2 on beagle are easily accessible on the expansion connector
  • [16:52:09] <sakoman__> The clock seems to be set right -- my dso says it is 384Khz
  • [16:55:19] <sakoman__> a second try with the resolution set higher yields 403Khz, so I think the clock setup is OK, at least for i2c-2
  • [16:56:11] * walter (n=walter@host121.natpool.mwn.de) Quit (Remote closed the connection)
  • [16:56:45] <sakoman__> Once I get a pointer to the probe points for i2c-1 from jkridner I'll verify those signals at 100, 400, 2600
  • [17:00:10] <sakoman__> rise & fall times are in the range of 200ns for 10%-90%
  • [17:01:35] <sakoman__> so this channel would definitely not function at 2600
  • [17:04:05] <sakoman__> but I believe the high speed channel doesn't rely completely on the external pull up -- IIRC correctly it provides some active "help"
  • [17:05:24] <bjdooks> sakoman__: current sources are what is required
  • [17:05:33] <sakoman__> OK, back to working on stuff that falls in the "billable hour" category. kitty needs kibble :-)
  • [17:15:31] * khasim (n=a0393720@192.163.20.231) has joined #beagle
  • [17:23:06] * khasi1 (n=a0393720@192.163.20.231) has joined #beagle
  • [17:25:35] <Crofton|work> you need a video of the beagle playing the demo video on youtube!
  • [17:28:14] * jkridner (n=jason@c-76-31-18-64.hsd1.tx.comcast.net) has joined #beagle
  • [17:29:27] <jkridner> khasim: ping
  • [17:33:17] * khasim (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [17:34:12] * koen taps foot while TI-C6x-CGT-v6.1.2.3.bin downloads
  • [17:34:22] <Crofton|work> heh
  • [17:35:03] <Crofton|work> koen, are you thinking of building dsp binaries from within?
  • [17:35:08] <koen> no
  • [17:35:26] <koen> I'm downloading everything I can get my hands on
  • [17:35:27] <Crofton> within OE
  • [17:35:29] <Crofton> heh
  • [17:35:44] <koen> I want to build the CE demos
  • [17:35:45] <Crofton> populating the image with the dsp side stuff would be cool
  • [17:35:50] <koen> which seems to need lots of stuff
  • [17:35:56] <Crofton> but first we need to figure out what we are doing :)
  • [17:36:00] <Crofton> yeah
  • [17:36:25] <koen> I'd be content with knowing the right incantations to build it without understanding what it does
  • [17:36:33] <Crofton> heh
  • [17:36:42] <sakoman__> jkridner: I think khasim is avoiding you ;-)
  • [17:37:00] <Crofton> I want to get the dsplink examples going, then create some actual dsp code
  • [17:37:27] <jkridner> he's probably knows I
  • [17:37:35] <jkridner> he probably knows I'd just waste his time.
  • [17:37:55] <koen> the c64x installer is sloppy
  • [17:38:02] <koen> it asks for a path, but ends with:
  • [17:38:04] <koen> C6X_C_DIR=<pathtoTICG>/include/;<pathtoTICG>/lib;
  • [17:39:23] * Crofton is depressed at the resources his ex-research group is wasting
  • [17:39:32] <Crofton> heh
  • [17:39:34] <Crofton> ""
  • [17:40:13] * calculus was disappointed by the lack of demos at the US LRL
  • [17:40:25] <calculus> things seem to have come much further along now
  • [17:41:03] <Crofton> lots of small steps add up with time
  • [17:41:35] <calculus> as Newton has said
  • [17:47:11] <ds2> heh
  • [17:58:19] * jkridner|work (n=a0321898@nat/ti/x-0fe5280158ff5dc5) Quit ("Leaving.")
  • [17:58:26] <sakoman__> jkridner: not sure if you read the logs, but if you could help me find R11 and and R12 I would be most grateful!
  • [18:01:14] <koen> R11 is for OTG
  • [18:01:28] <koen> you want R12 (HFCLKOUT)
  • [18:01:41] <koen> wait
  • [18:01:51] <koen> am I confusing ballnames and resistors again?
  • [18:03:46] <ds2> how odd, I found R10 and R14 but not the 2 of interest
  • [18:05:49] <mru> hi guys
  • [18:06:40] * Crofton wonders if he should add c6x/bin to his path
  • [18:08:20] <ds2> I wonder if they are 2 two unlabeled ones north of C78
  • [18:11:09] <mru> someone was asking for my 600MHz u-boot
  • [18:11:15] <mru> http://git.mansr.com/?p=u-boot;a=commit;h=76dca3e5bd0f9eff901b225717acb9eeb9214444
  • [18:12:38] <ds2> isn't that acheiveable via cpufreq?
  • [18:12:52] <mru> probably
  • [18:12:59] <mru> this was simpler
  • [18:13:15] <ds2> it is 1 echo to add to the rc.local script :P
  • [18:13:36] <mru> I didn't know cpufreq was working at all
  • [18:14:01] <mru> it's bad enough on x86
  • [18:14:13] <mru> but maybe that's because x86 is such a beast
  • [18:14:48] <sakoman__> koen: yeah, you are confusing ball numbers and resistors :-)
  • [18:15:06] <sakoman__> ball number wouldn't do me any good since I can't probe the balls
  • [18:16:28] <sakoman__> ds2: possibly could be those two, but I really don't want to guess
  • [18:18:28] <banderson> whohoo new quad core pc just showed up...no more *work* from me for rest of day!!!
  • [18:18:47] <mru> quad core is nice
  • [18:19:18] <mru> distcc on quad+dual core is also nice
  • [18:19:32] <mru> builds a kernel in about a minute
  • [18:21:12] <koen> ds2: no cpufreq yet in omap git
  • [18:21:56] <koen> quad core is indeed nice
  • [18:22:27] <ds2> koen: ah... btw, any reactions to the omapfb driver?
  • [18:22:42] <ds2> x86 blows too much power
  • [18:22:51] <mru> my instinctive reaction was "ugh"
  • [18:23:01] <mru> that wasn't so much a diff as a dump
  • [18:23:48] <koen> ds2: which driver?
  • [18:23:55] <koen> ds2: the s-video one?
  • [18:23:59] <ds2> koen: yeah
  • [18:24:00] <mru> the one that was posted to the mailing list, I assume
  • [18:24:15] <koen> I haven't looked at it yet
  • [18:24:42] <mru> at a glance, a lot of code looks similar to what's in git
  • [18:24:56] <mru> but files have different names, and things have moved around
  • [18:25:03] <koen> or rather, I haven't found a webfrontend that will give me a file that patch and handle :)
  • [18:25:23] <ds2> koen: would you like it in a different form? say from a ftp server?
  • [18:33:09] * jkridner|work (n=a0321898@nat/ti/x-6ccc2d77b59fc054) has joined #beagle
  • [18:48:30] * khasi1 (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [18:58:48] <Crofton> js: "./latency.tcf", line 84: Failed to generate config files.
  • [18:59:04] <Crofton> while trying to build dsp bios examples
  • [19:01:45] <koen> Crofton: for sffsdr?
  • [19:02:32] <Crofton> heh
  • [19:02:34] <Crofton> for anything
  • [19:03:36] <koen> try to make an OE recipe for it :)
  • [19:05:45] <Crofton> heh
  • [19:05:59] <Crofton> it looks like bios unpacks as read-only everything
  • [19:06:09] <Crofton> so it tries to create a file and dies
  • [19:06:30] <Crofton> I suspect we will need a ti dsp class to inherit
  • [19:06:43] * mru thinks evil things about commercial packages
  • [19:25:02] <koen> hmmm
  • [19:25:08] <koen> nice patch on linux-omap ml
  • [19:28:50] <Crofton> make a rw copy of a read nly directory tree
  • [19:28:54] * Crofton is feeling stupid
  • [19:29:30] <mru> chmod -R +w
  • [19:32:13] <Crofton> mru, thanks for confirming I am stupid
  • [19:32:46] <mru> you might want to make that u+w
  • [19:33:07] <Crofton> umask is ok
  • [19:33:08] <mru> I'm not sure how chmod handles umask and such things
  • [19:33:22] <Crofton> I think it applied agaisnt umask
  • [19:33:40] <Crofton> now I need to point at the tools
  • [19:35:09] <koen> Crofton: dspbios examples or dsplink examples?
  • [19:35:43] <Crofton> dpsbios
  • [19:36:14] <Crofton> not as useful as the link ones, but I am trying to get inside the TI mindset
  • [19:36:37] <Crofton> btw, we watched "Black Book" er "Zwartboek"
  • [19:36:39] <Crofton> last night
  • [19:37:57] * docelic (n=docelic@78.134.196.59) has joined #beagle
  • [19:41:25] <koen> pointless nude scenes with nazis to fill up the time between them
  • [19:41:32] <koen> that one?
  • [19:42:55] <Crofton> exactly :)
  • [19:43:34] <Crofton> very different from the "American" movies he did
  • [19:43:48] <koen> like showgirls?
  • [19:43:57] <Crofton> Robo Cop
  • [19:44:05] <Crofton> I didn't see show girls :)
  • [19:44:19] * koen always confuses jan de bont and paul verhoeven
  • [19:45:36] * koen checks wikipedio
  • [19:46:02] <koen> ah, jan did speed and tombraider
  • [19:46:09] <koen> paul did showgirls, robocop and total recall
  • [19:46:19] <Crofton> yeah
  • [19:48:52] * koen boots a kernel with the i2c fix
  • [19:50:06] * Crofton has built the dsp bios examples
  • [19:50:14] <Crofton> not that he knows what he did .....
  • [19:55:00] <koen> sakoman__: an unscientific test seems to show that pauls i2c race fix makes the audio driver a bit more stable
  • [19:58:55] * BThompson (n=BThompso@nat/ti/x-8a475a4a17ecbc30) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [20:00:16] <Crofton> hmmm
  • [20:00:34] * GeneralAntilles (n=GeneralA@pdpc/supporter/active/generalantilles) Quit ()
  • [20:13:47] <sakoman__> koen: does it eliminate all i2c-1 errors?
  • [20:14:15] <koen> I just got the pcm_open oops again
  • [20:14:31] <koen> but sysrq still worked, which is a change
  • [20:15:20] <koen> it doesn't magically solve all out problems
  • [20:23:46] <Crofton> I am not motivated
  • [20:24:01] <Crofton> but I am close to getting the dsplink dsp side of the examples built
  • [20:40:47] <koen> cool
  • [20:40:54] <koen> saves me sone anguish tomorrow
  • [20:42:24] * prpplague^2 (n=dave@mail.americanmicrosystems.com) has joined #beagle
  • [20:51:29] <Crofton> koen, basically edit makefiles
  • [20:51:58] <koen> yeah
  • [20:52:22] <koen> roger said I also needed a different version of xdctools that what's shipped with dspbios
  • [20:52:37] * prpplague (n=dave@mail.americanmicrosystems.com) Quit (Nick collision from services.)
  • [20:52:41] * prpplague^2 is now known as prpplague
  • [20:52:52] <koen> Crofton: could you add your notes to the recipe so I convert it to sed tomorrow?
  • [20:53:31] <Crofton> it is messy
  • [20:53:49] <Crofton> I can see adding dsp stuff to recipes
  • [20:54:06] <Crofton> but we will need to decide how to install tools//dsp bios
  • [20:54:35] <koen> MAGIC_VAR_THAT_POINTS_TO_BIOS ?= /OE/TI/bios
  • [20:54:42] <koen> and let the user override it
  • [20:54:43] <Crofton> and tools
  • [20:54:46] <Crofton> yeah
  • [20:55:13] <Crofton> in dsplnk there is BASE_INSTALL
  • [20:55:20] * koen hugs mount --bind /very/long/path/to/where/oe/is/installed /OE
  • [20:58:04] * docelic (n=docelic@78.134.196.59) Quit ("http://www.spinlocksolutions.com/")
  • [21:06:42] * Crofton curses trailing spaces
  • [21:07:06] <Crofton> ok, I need to figure out how to communicate my work to you
  • [21:07:13] <Crofton> I was editing stuff in work :)
  • [21:09:05] <koen> diff -Nurd file1 edited-file1
  • [21:09:27] <Crofton> I didn't save originals
  • [21:09:34] <Crofton> trouble with the samples
  • [21:09:37] <mru> Crofton: use git
  • [21:09:40] <mru> for everything
  • [21:09:41] <Crofton> I can figure something out
  • [21:09:52] <koen> extract it again in a different dir
  • [21:10:01] <mru> at work I keep everything in git
  • [21:10:16] <koen> mru: I've been tempted to check the gazillion different versions of codec-engine into git to see the diffs
  • [21:12:00] <Crofton> http://rafb.net/p/6hyix486.html
  • [21:21:26] <Crofton> jkridner, ping
  • [21:27:50] <Crofton> [balister@localhost samples]$ ls ../../BUILD/EXPORT/RELEASE/
  • [21:27:50] <Crofton> dsplink.lib dsplinkpool.lib hal.lib mpcsxfer.out
  • [21:27:50] <Crofton> dsplinkmpcs.lib dsplinkringio.lib ips.lib ringio.map
  • [21:27:50] <Crofton> dsplinknotify.lib gen.lib mpcsxfer.map ringio.out
  • [21:28:07] <Crofton> I think ringio.out is what is loaded onto the dsp?
  • [21:30:49] <koen> iirc the .x64P is loaded into the dsp
  • [21:31:36] <koen> Crofton: http://rafb.net/p/7jtufs92.txt
  • [21:31:48] <koen> Crofton: the .out should be the demo
  • [21:38:26] * dschaeffer (n=daniel@timesys-gw0.cust.expedient.net) Quit ("Leaving.")
  • [21:50:26] * RogerMonk (n=a0740758@nat/ti/x-40e9fbedd82cf4a1) has joined #beagle
  • [21:54:56] <Crofton> ok, let's copy the .out over and see what happens
  • [21:55:17] <RogerMonk> .out.... sounds like dsp stuff!
  • [21:55:40] <Crofton> yeah, I have the dsplink dsp side "built"
  • [21:56:09] <Crofton> what do the samples do?
  • [21:57:06] <RogerMonk> various things - mainly ripple data through the dsp and back to verify correct data passing
  • [21:57:21] <RogerMonk> different examples use different LINK constucts
  • [21:57:43] <RogerMonk> which example have you built?
  • [21:58:07] <Crofton> ringio and mpcsxfer
  • [21:58:16] <Crofton> Failure: Status:[0x80008000] File:[0x206] Line:[438]
  • [21:58:17] <Crofton> Leaving RingIO_delete () status [0x80008000]
  • [21:58:17] <Crofton> Entered RingIO_delete ()
  • [21:58:17] <Crofton> name [0x271c8]
  • [21:58:22] <RogerMonk> ok
  • [21:58:43] <RogerMonk> can you dump complete log?
  • [21:59:12] <RogerMonk> did you reserve memory for the dsp using mem-
  • [21:59:15] <RogerMonk> mem=
  • [21:59:24] <Crofton> http://rafb.net/p/HyjY4Q10.html
  • [21:59:26] <Crofton> hmmm
  • [21:59:40] * koen loves the osd2 for having 256 ram
  • [21:59:42] <Crofton> mem=96m
  • [21:59:54] <koen> dsplink driver open: /dev/dsplink: No such file or directory
  • [21:59:59] <Crofton> yeah
  • [22:00:01] <RogerMonk> yep, you need to make the node
  • [22:00:13] <Crofton> stupid udevd
  • [22:00:14] <RogerMonk> mknod /dev/dsplink c 230 0 (IIRC)
  • [22:00:18] <koen> Crofton: cmemk hooks into uevent so udev works
  • [22:00:27] <RogerMonk> no udev with dsplink
  • [22:00:34] <koen> Crofton: dsplink doesn't hook into that and needs manual intervention
  • [22:00:49] <koen> I suspect it would be a one-liner to the dsplink source to fix that
  • [22:01:52] <Crofton> how confident are you with the mknod?
  • [22:01:58] <RogerMonk> mknod /dev/dsplink c `awk "\\$2==\"dsplink\" {print \\$1}" /proc/devices` 0
  • [22:02:24] <RogerMonk> (off the top of my head :))
  • [22:02:28] <Crofton> heh
  • [22:02:31] <Crofton> I looked by hanf
  • [22:02:50] <koen> it's int he script OE doesn't package :)
  • [22:03:06] <koen> I wanted to do it using modutils :)
  • [22:03:12] <RogerMonk> bad boy Koen!
  • [22:04:10] <Crofton> lots more text
  • [22:04:17] <RogerMonk> paste?
  • [22:05:52] <Crofton|work> http://rafb.net/p/r87bHo22.html
  • [22:05:58] <Crofton|work> http://rafb.net/p/6iK5d066.html\
  • [22:06:49] <Crofton|work> there are failures at the end of both
  • [22:07:58] <koen> I hope Crofton|work gets it all into OE before I start packing tomorrow :)
  • [22:08:21] <RogerMonk> what target are we running on? beagle?
  • [22:08:37] <koen> Crofton is using sffsdr
  • [22:08:48] <Crofton> Davinci
  • [22:08:51] <mru> koen: speaking of packing, what's your schedule for the weekend?
  • [22:09:15] <koen> mru: I arrived on thursday, visit TI on friday and leave on monday
  • [22:09:53] <koen> -d somewhere
  • [22:09:55] <Crofton> Where is TI?
  • [22:10:01] <mru> northampton
  • [22:10:02] <koen> northampton
  • [22:10:09] * mru is in southampton
  • [22:10:24] <koen> southampton is a bit further away
  • [22:10:31] <mru> koen: when do you suppose you'll be in wolverhampton?
  • [22:10:52] <Crofton> just up the road from where I was born
  • [22:10:56] <Crofton> sort off
  • [22:11:03] <RogerMonk> Crofton|work - what mem= have you got set
  • [22:11:12] <Crofton> mem=96m
  • [22:11:23] <RogerMonk> and your board has 256M?
  • [22:11:24] <koen> mru: thursday evening till monday minus friday :)
  • [22:11:38] <Crofton> 128M
  • [22:11:42] <RogerMonk> ah-ha
  • [22:11:55] <RogerMonk> you need to rebuild the examples if you have less that 256M
  • [22:11:57] <mru> koen: I won't be there until friday evening some time
  • [22:12:09] <Crofton> arm or dsp?
  • [22:12:12] <mru> I'll have to see how early I can escape work
  • [22:12:14] <koen> mru: RogerMonk should drop off me + lcds round that time
  • [22:13:03] <RogerMonk> mru - come and visit us in the office :) on Friday - business meeting?
  • [22:13:29] <Crofton> RogerMonk, what do i need to change and rebuild ....
  • [22:13:34] <RogerMonk> 2 secs
  • [22:13:37] <Crofton> k
  • [22:13:51] <koen> RogerMonk: the TI office is next to the golf course?
  • [22:14:20] <mru> RogerMonk: I'm afraid I can't get away from work
  • [22:16:09] <RogerMonk> mru - no probs - another time.
  • [22:16:13] <RogerMonk> koen - yep
  • [22:17:01] <mru> maybe I can catch you in wolverhampton
  • [22:17:10] <mru> what time do you reckon you'll be there?
  • [22:17:54] <RogerMonk> Crofton - config/all/CFG_Davinci.c
  • [22:18:08] * prpplague (n=dave@mail.americanmicrosystems.com) Quit ("Leaving")
  • [22:18:25] <ds2> is this like in married with child where one of the uptoms are in perpetual darkness? ;)
  • [22:18:37] * koen looks at RogerMonk
  • [22:19:13] <Crofton> this is 1.50
  • [22:19:29] <Crofton> CFG_Davinci_DM6446.c
  • [22:19:30] <koen> Crofton: we should get you 1.51
  • [22:19:53] * koen should get some sleep
  • [22:19:55] <koen> 'night all
  • [22:19:58] <RogerMonk> gn
  • [22:20:00] <Crofton> well, I am using 50, becuase some other peple might want to use this
  • [22:20:02] <Crofton> gn
  • [22:20:14] <Crofton> I'll send you diffs, or files so you can diff
  • [22:20:14] <RogerMonk> mru - not sure what time we'll be there - probably 7.30ish?
  • [22:20:39] <RogerMonk> Crofton- suggest we try this on DavinciEVM first with 256M
  • [22:20:46] <RogerMonk> you'll need to change dsp side too
  • [22:21:02] <Crofton> I only have he sffsdr board .....
  • [22:21:05] <mru> RogerMonk: I should be there around that time too
  • [22:21:15] <RogerMonk> mru - sounds good - see you in the bar
  • [22:22:00] <Crofton> RogerMonk, let me extract some diffs for koen
  • [22:22:14] <Crofton> so he can see what I have done
  • [22:22:21] <Crofton> then we can look at this tomorrow
  • [22:22:28] <RogerMonk> do you have an OE recipe for this?
  • [22:22:37] <Crofton> only the GPP side
  • [22:22:44] <RogerMonk> what about the dsp side?
  • [22:22:48] <Crofton> not yet
  • [22:22:51] <RogerMonk> built by hand?
  • [22:22:55] <Crofton> yeah
  • [22:23:14] <Crofton> but, I built it :)
  • [22:23:33] <RogerMonk> ok - can you send me a rootfs and kernel binary that I can use on my davinci evm to test?
  • [22:23:41] <Crofton> I'll extract my changes and maybe koen can make a recipe when he gets up
  • [22:24:03] <RogerMonk> a binary would be ok for now for me?
  • [22:24:27] <Crofton> I'll do a build for the evm
  • [22:24:32] <RogerMonk> (great)
  • [22:24:35] <Crofton> it should go quickly
  • [22:24:39] <RogerMonk> thanks
  • [22:24:46] <Crofton> and upload to amethyst
  • [22:24:55] <Crofton> the last upload was early May
  • [22:25:10] <RogerMonk> can you also tar up your kernel sources so I can build dsplink against it
  • [22:25:31] <Crofton> the build should include dsplink
  • [22:25:48] <Crofton> ok, let me work though a few things
  • [22:25:52] <RogerMonk> yep, but I may need to rebuild
  • [22:25:59] <Crofton> I need to extract my changes
  • [22:26:27] <Crofton> the kernel soources will be a git rev and defconfig that are in oe
  • [22:26:50] <Crofton> my wife will be home soon and it will be hard to get anything done ..
  • [22:27:07] <RogerMonk> I'd rather a tar of the source tree if possible? else it'll take me ages to build all the OE bits to go with it (I think)
  • [22:27:22] <Crofton> I can try
  • [22:27:36] <Crofton> do a git checkout of the rev in the OE recipe
  • [22:27:42] <Crofton> and copy in the defconfig
  • [22:28:01] <Crofton> let me get started
  • [22:31:52] * rsalveti (n=salveti@200.184.118.132) Quit (Read error: 113 (No route to host))
  • [22:43:57] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) has joined #beagle
  • [22:44:43] * rsalveti (n=salveti@189.70.140.74) has joined #beagle
  • [23:30:33] * jkridner|work (n=a0321898@nat/ti/x-6ccc2d77b59fc054) Quit ("Leaving.")
  • [23:34:22] * intu (n=intu@ubr1-201-91.ubr.tartu.stv.ee) has joined #beagle