• [00:48:02] * BThompson (n=BThompso@cpe-76-185-66-252.tx.res.rr.com) has joined #beagle
  • [01:10:29] * BThompson (n=BThompso@cpe-76-185-66-252.tx.res.rr.com) Quit (Read error: 110 (Connection timed out))
  • [01:32:58] * JoeBorn_ (n=jborn@adsl-75-3-12-92.dsl.chcgil.sbcglobal.net) Quit (Read error: 104 (Connection reset by peer))
  • [01:36:23] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) has joined #beagle
  • [02:04:14] * bazbell (n=a0192809@nat/ti/x-4dd85b8360325aae) Quit (Remote closed the connection)
  • [02:26:17] * bazbell (n=a0192809@nat/ti/x-485d05c5a5ce9774) has joined #beagle
  • [03:09:24] * JoeBorn (n=jborn@cpe-66-1-5-91.il.sprintbbd.net) has joined #beagle
  • [03:50:42] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [04:40:23] * khasim (n=a0393720@192.163.20.231) has joined #beagle
  • [10:47:58] <Crofton> what is liboil again?
  • [10:48:02] * Crofton google
  • [10:49:17] <koen> Optimized Inner Loops
  • [10:49:35] <koen> optimized version of commonly used functions
  • [10:51:00] <Crofton> yeah
  • [10:51:13] <Crofton> google works as well as asking on irc
  • [10:51:24] <Crofton> You mentioned it earlier
  • [10:51:37] <Crofton> have they added neon support
  • [10:51:40] * Crofton wonders
  • [10:51:54] <Crofton> this sounds like something I should know more about
  • [10:53:24] <koen> http://gitweb.freedesktop.org/?p=liboil.git;a=tree;h=f208ba3e996486b229b0ac0cc47051557d2be842;hb=486e63504ffc558be68effcfffb315d18a0cfb82;f=liboil/arm
  • [10:53:30] <koen> looks like they only have vfp
  • [11:07:35] <ldesnogu-> what software makes use of liboil?
  • [11:07:55] <Crofton> I think codec engine does
  • [11:08:04] <Crofton> I saw a reference on the DV lis
  • [11:08:06] <Crofton> list
  • [11:08:14] <Crofton> koen has also mentioned it here
  • [11:08:33] <ldesnogu-> is that all?
  • [11:08:59] * ldesnogu- is getting crazy about all these small mostly unused libraries
  • [11:09:21] <Crofton> I need to look at it
  • [11:09:39] <Crofton> I'm curious how big it is
  • [11:10:04] <Crofton> if it really provides reasoanbly good vector ops across platforms, I may have a use for it
  • [11:10:59] <ldesnogu-> yeah and then look at framewave, ipp, ffmpeg core routines, openmax
  • [11:11:27] <ldesnogu-> things need to settly or else we'll never get anything reasonnably optimized accross many architectures :(
  • [11:11:34] <ldesnogu-> s/settly/settle/
  • [11:11:56] <Crofton> That sounds like a good project for a grad student
  • [11:12:12] <Crofton> of course they are almost useless
  • [11:13:32] <Crofton> but you are right, many people are solving the same problem
  • [11:13:54] <ldesnogu-> the problem with basic bricks is that for them to be usable by many sw they have to be small
  • [11:14:13] <ldesnogu-> and if they are small one would better do it for its own purpose to get top speed
  • [11:14:17] <ldesnogu-> s/its/his/
  • [11:17:07] <koen> Crofton: http://lists.freedesktop.org/archives/liboil/2008-March/000185.html
  • [11:17:49] <koen> ldesnogu-: gstreamer and pixman (the xserver and cairo) use liboil
  • [11:18:16] <ldesnogu-> gstreamer also does openmax, doesn't it?
  • [11:21:33] <koen> gstreamer can use openmax, yes
  • [11:22:42] <ldesnogu-> so why use one instead of the other? :)
  • [11:23:02] <koen> gstopenmax didn't exist 3 years ago
  • [11:23:18] <koen> and liboil works also for mmx, altivec, sse2, sse3, etc
  • [11:26:01] <ldesnogu-> openmax could also be ported for x86 if intel didn't have contradicting goals :)
  • [11:27:26] <Crofton> the other problem is openmax is a paid membership organization ....
  • [11:27:49] <Crofton> I would guess you have .com interests conflicting with project goals
  • [11:30:36] <ldesnogu-> don't tell me intel can't pay $10k for conformance testing? :)
  • [11:32:27] <suihkulokki> I think the question is why the community should care about openmax?
  • [11:33:12] <Crofton> suihkulokki, exactly :)
  • [11:33:24] <ldesnogu-> doesn't the community need some well optimized usable API for multimedia? or should we reinvent the wheel every time?
  • [11:33:29] * Crofton is an open source guy :)
  • [11:33:31] <ldesnogu-> I don't say openmax is the answer :)
  • [11:33:44] <Crofton> ldesnogu-, I agree completely
  • [11:34:00] <Crofton> this would be a good panel for something like FOSDEM
  • [11:34:18] <ldesnogu-> what I am sure of for instance is that TI or Nokia specific stuff is even less interesting than openmax
  • [11:34:31] <Crofton> I'm interested in the lower level stuff for signal processing
  • [11:34:38] <ldesnogu-> until TI open sources that is ;)
  • [11:34:39] <Crofton> without the multi-media layer
  • [11:34:57] <suihkulokki> How is openmax more usable and optimized than say gstreamer?
  • [11:35:30] <ldesnogu-> ARM openmax implementation has neon support for instance
  • [11:35:35] <ldesnogu-> does gstreamer have it?
  • [11:37:13] <suihkulokki> now you are talking about implemantation, not API
  • [11:43:54] <ldesnogu-> you talked about optimization :)
  • [11:44:09] <ldesnogu-> I really don't have any preference at all.
  • [11:44:20] <suihkulokki> :P
  • [11:44:45] <ldesnogu-> In fact I am looking at what open source libraries exist and how useful they are for existing software
  • [11:44:55] <suihkulokki> And I was responding to "14:33 < ldesnogu-> doesn't the community need some well optimized usable API for multimedia?"
  • [11:44:58] <ldesnogu-> and then I write some optimize code for them
  • [11:45:20] <ldesnogu-> suihkulokki, that certainly was bad on my side :D
  • [11:47:15] <suihkulokki> openmax doesn't look bad, I'm just interested if there is some known reasons why it's considered technically better
  • [11:47:41] <suihkulokki> IE it would be hard to do what ARM did for openmax in gstreamer
  • [11:48:08] <suihkulokki> thou if I read correctly, openmax DL would compare more to liboil than to gstreamer
  • [11:51:32] <ldesnogu-> gstreamer and openmax are not exclusive
  • [11:52:05] <suihkulokki> but having too many layers make things complicated
  • [11:56:49] <suihkulokki> Like this :P http://freedesktop.org/wiki/GstOpenMAX
  • [11:58:55] <ldesnogu-> gstreamer wraps things it does not implement them
  • [11:59:04] <ldesnogu-> (at least that's my understanding)
  • [11:59:23] <ldesnogu-> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/chapter-motivation.html: "Attempts have been made to create libraries for handling various media types. Because they focus on a very specific media type (avifile, libmpeg2, ...), significant work is needed to integrate them due to a lack of a common API. GStreamer allows you to wrap these libraries with a common API, which significantly simplifies integration and reuse."
  • [12:11:00] <koen> there you have your API :)
  • [12:42:22] * BThompson (n=BThompso@nat/ti/x-a2d4f2766e79fc62) has joined #beagle
  • [13:08:49] * khasi1 (n=a0393720@192.163.20.231) has joined #beagle
  • [13:08:49] * khasim (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [13:15:15] * khasi1 (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [13:25:02] * Crofton (n=balister@66-207-66-26.black.dmt.ntelos.net) Quit (Read error: 104 (Connection reset by peer))
  • [13:32:12] * prpplague (n=dave@mail.americanmicrosystems.com) has joined #beagle
  • [13:40:42] <koen> any news on the mux stuff?
  • [13:40:49] <koen> did more people test dirks u-bot?
  • [13:43:02] * Crofton (n=balister@66-207-66-26.black.dmt.ntelos.net) has joined #beagle
  • [13:48:37] * prpplague^2 (n=dave@mail.americanmicrosystems.com) has joined #beagle
  • [13:50:11] * prpplague (n=dave@mail.americanmicrosystems.com) Quit (Nick collision from services.)
  • [13:50:11] * prpplague^2 is now known as prpplague
  • [13:52:41] <sakoman> koen: I've been using it.
  • [13:53:22] <sakoman> I haven't been doing too much with USB, I've been debugging NAND support
  • [13:54:06] <sakoman> Stability overall is terrible though -- I get usable boots maybe one time in 4
  • [13:54:56] <sakoman> most of the time I get a fault in the fb code
  • [13:55:39] <prpplague> sakoman: uboot code issues? or something related to hardware?
  • [13:56:16] <sakoman> prpplague: I haven't tried to debug it
  • [13:56:26] <sakoman> one thing at a time
  • [13:56:45] <sakoman> last night I just turned off the fb to reduce the annoyance factor
  • [13:57:08] <sakoman> I'll turn it back on after I get the NAND stuff working properly
  • [13:58:38] <prpplague> sakoman: ahh i think i miss read your statement
  • [13:58:56] <prpplague> sakoman: what kind of nand problems are you having?
  • [13:59:54] <sakoman> well, a series of issues. knocking them down one at a time
  • [14:00:15] * NishanthMenon (n=gnat@nat/ti/x-c501bf580e53997f) has joined #beagle
  • [14:00:27] <prpplague> ahh ok
  • [14:00:51] <prpplague> i'd love to add cortex-a8 support to openocd, but i simply don't have the time right now
  • [14:01:04] <sakoman> most recent was a fault in the gpmc wait function
  • [14:01:58] <sakoman> Nishant sent me a clue on how to fix that, now I've progressed to having the driver load successfully, but the partition map isn't being set up properly
  • [14:19:21] * bazbel1 (n=a0192809@nat/ti/x-6f894e1f4bf430ea) has joined #beagle
  • [14:23:23] * bazbell (n=a0192809@nat/ti/x-485d05c5a5ce9774) Quit (Remote closed the connection)
  • [14:27:52] * bazbel1 (n=a0192809@nat/ti/x-6f894e1f4bf430ea) Quit ("Leaving.")
  • [14:30:34] <koen> sakoman: do you have CONFIG_OMAP_MUX turned on?
  • [14:31:14] <prpplague> jkridner: ping
  • [14:31:27] <sakoman> koen: I've tried it both ways
  • [14:32:44] <koen> sakoman: do you see an improvement with mux turned on?
  • [14:33:07] <sakoman> not that I noticed
  • [14:41:35] <koen> I suspect tony well merge 2.6.26rc4 today ot tomorrow
  • [14:44:52] <koen> hopefully we can get patches in right after that
  • [14:46:58] <DJWillis> koen: how good is Tony with patches? Never sent to linux-omap before but is he good at pushing them to RMK and upwards if he takes them into his GIT?
  • [14:47:41] <koen> not sure about the -> rmk route
  • [14:48:03] <koen> I keep meaning to ask tony about his schedule for pushing stuff to RMK
  • [14:48:30] <koen> http://www.google.nl/search?hl=nl&q=pi+usd+-%3E+euro&btnG=Zoeken&meta=
  • [14:48:38] <Crofton> they try
  • [14:48:44] <koen> yesterday pi USD was exactly 2 euros :)
  • [14:48:54] <DJWillis> koen: still, thinking about the Pandora stuff, if I got that in a state to push to Linux-OMAP that would be "the right thing to do(tm)"?
  • [14:49:03] <koen> I suspect omap3 as a whole isn't in a good shape to go to rmk
  • [14:49:06] <Crofton> a sign of the apocalypse
  • [14:49:18] <koen> DJWillis: certainly
  • [14:49:32] <Crofton> linux-omap is active enough and does follow upstream
  • [14:51:44] <koen> and it's "the place to be" for omap kernel code
  • [14:52:41] * koen needs to find out how to make a kernel that allows MUSB host and client
  • [14:53:24] <Crofton> in other words, all the right people are contributing to linux-omap :)
  • [14:56:01] <sakoman> koen: just enable the OTG stuff using menuconfig
  • [14:56:36] <sakoman> I forget the exact spot in drivers/usb, but it is fairly obvious
  • [14:57:27] <koen> sakoman: I suspect as much
  • [14:57:44] <koen> sakoman: but I want the multi endpoint stuff working
  • [15:04:29] <koen> it should be possible to enable host + multiple gadgets
  • [15:04:39] <koen> (provided you have one of those usb Y cables)
  • [16:33:13] <koen> sakoman: you said partition map is wrong, but does flash access work with your driver?
  • [16:33:57] <sakoman> depends on what you mean :-)
  • [16:35:20] <sakoman> koen: I haven't tried to read & write, but the driver can talk to the chip:
  • [16:35:21] <sakoman> omap2-nand driver initializing
  • [16:35:21] <sakoman> NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V 16-bit)
  • [16:35:21] <sakoman> omap2-nand: parsing partitions
  • [16:35:21] <sakoman> mtd: Giving out device 0 to omap2-nand
  • [16:41:13] <koen> nice
  • [16:42:09] <koen> does the gpmc tweak only apply to nand, or does it improve other things as well?
  • [16:42:21] <sakoman> just nand
  • [17:05:14] * JoeBorn (n=jborn@cpe-66-1-5-91.il.sprintbbd.net) Quit ("out for a bit")
  • [17:12:07] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) has joined #beagle
  • [17:15:52] * ldesnogu (n=ldesnogu@ven06-2-82-247-86-183.fbx.proxad.net) has joined #beagle
  • [17:24:27] * koen tries otg running as otg now
  • [17:27:27] <sakoman> koen: do you get "Warning: unable to open an initial console." with you beagle OE builds?
  • [17:28:00] <sakoman> I've been ignoring it up to now, but I'm curious whether it is just me
  • [17:28:45] <koen> I don't have that warning
  • [17:29:00] <koen> do you have a /dev/console node in your rootfs?
  • [17:29:06] <koen> (before udev starts, that is)
  • [17:29:32] <sakoman> only if my x11-image puts it there! I'll have to check
  • [17:29:57] <sakoman> yup, it is there
  • [17:30:51] <sakoman> I'll have to make sure it is there on the mmc too though -- I just checked tmp/rootfs
  • [17:33:18] <koen> sweet, otg works
  • [17:34:48] <koen> as in: it works as expected
  • [17:35:12] <koen> put in client cable: workstation sees usb0
  • [17:35:23] <koen> put in host cable: beagle sees bluetooth, keyboard and audio
  • [17:40:06] <DJWillis> koen: really, awesome :D
  • [17:40:40] <koen> even more awesome is that I got the mini-usb to host cable donated :)
  • [17:40:59] <koen> for people with a armv7 cpu: http://amethyst.openembedded.net/~koen/beagleboard/Angstrom-console-image-glibc-ipk-2008.1-test-20080527-beagleboard.rootfs.tar.bz2
  • [17:44:01] <DJWillis> koen: ;-), you sir, rule (as previously noted)
  • [17:44:45] <DJWillis> koen: the host lead is something I need to get made up, we (I understand) are looking to get them made to go with the Pandora if it's reliable.
  • [17:45:21] <koen> the pandora will only have OTG?
  • [17:45:52] <DJWillis> No, both, it's just nice to be able to offer a lot of flexability.
  • [17:47:15] <DJWillis> plus, if I understand the specs correctly OTG will host a USB 1 low/full speed device without the need for a hub, can you try that?
  • [17:48:07] <koen> eth0: register 'asix' at usb-musb_hdrc.0-1.3, ASIX AX8817x USB 2.0 Ethernet, 00:10:60:84:4f:26
  • [17:48:10] <koen> eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
  • [17:49:33] <koen> hmmm
  • [17:49:43] <koen> I think my otg port is unpowered
  • [17:50:00] <koen> the light on my bt dongle doesn't light up
  • [17:50:38] <kulve> do you have support in the kernel for it?
  • [17:50:43] <DJWillis> I thought it was rated for a tiny MAh, that could be a fatal flaw.
  • [17:51:31] <koen> kulve: for otg or power?
  • [17:51:36] <kulve> for bt
  • [17:52:04] <koen> yes
  • [17:52:09] <koen> it works through a hub
  • [17:52:13] <kulve> ok
  • [17:55:04] <sakoman> koen: you are running off external supply right?
  • [17:56:39] <sakoman> I'm not sure if the rev A boards did anything to disable OTG power due to the power in mixup
  • [18:05:36] <koen> external power, yes
  • [18:12:50] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) Quit ()
  • [19:00:14] * PibbRelay (n=supybot@nat/janrain/x-8e0f4e62fcd862a1) Quit (SendQ exceeded)
  • [19:02:26] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) has joined #beagle
  • [19:11:14] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) Quit ()
  • [19:11:19] <koen> argh
  • [19:11:26] <koen> the armv7a images seem to be busted
  • [19:11:39] <koen> the ones compiled with gcc-csl, that is
  • [19:17:05] <Crofton> heh
  • [19:18:53] <DJWillis> koen: 7/q3 or 8/q1?
  • [19:49:48] <sakoman> woo hoo!
  • [19:49:51] <sakoman> omap2-nand driver initializing
  • [19:49:51] <sakoman> NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V 16-bit)
  • [19:49:51] <sakoman> Creating 5 MTD partitions on "omap2-nand":
  • [19:51:31] <sakoman> Now I need to test it, clean it up & submit patches
  • [19:52:22] <sakoman> I find it hard to believe that the omap2 nand driver ever worked
  • [19:59:26] <ldesnogu> good job :)
  • [20:01:37] <DJWillis> sakoman: in fairness, did it ever work? It would not be the 1st time code has crept in without much in the way of peer testing.
  • [20:03:44] <sakoman> My main problem was assuming that it worked, so I spent too much time looking at my code trying to figure out what I was doing wrong.
  • [20:04:04] <DJWillis> :(
  • [20:05:18] <sakoman> Once Nishant let me know he knew of at least one issue (and even provided a close to working patch) I started looking closely at the driver code and found the other issues.
  • [20:08:02] <DJWillis> Great work but a really shitty starting point
  • [20:08:24] * jkridner_ (n=jason@c-76-31-18-64.hsd1.tx.comcast.net) has joined #beagle
  • [20:09:06] * jkridner (n=jason@c-76-31-18-64.hsd1.tx.comcast.net) Quit (Read error: 104 (Connection reset by peer))
  • [20:09:14] <sakoman> I started it as a diversion from the alsa SoC driver. Figured snatching some low hanging fruit would fire me up to finish the audio driver :-)
  • [20:09:25] <sakoman> Little did I know :-)
  • [20:11:49] <DJWillis> How do things look with the mcbsp stuff?
  • [20:12:59] <sakoman> don't know yet -- I was just starting to actually wire in the real functionality when I took a break to do the nand driver
  • [20:13:11] <sakoman> hopefully will get back to it in a day or two
  • [20:14:16] <sakoman> after I get a batch of patches submitted
  • [20:15:40] <DJWillis> Cool, the current situation is a pain but it's not your job to fix it like some one man Linux churner ;-)
  • [20:36:13] <ldesnogu> gn
  • [20:36:15] * ldesnogu (n=ldesnogu@ven06-2-82-247-86-183.fbx.proxad.net) has left #beagle
  • [20:39:13] <koen> DJWillis: 2007q3
  • [20:39:37] <koen> DJWillis: it might be something mundane like lacking NEON support in the kernel or something like that
  • [20:39:40] <DJWillis> koen: that's a bummer :(
  • [20:40:26] <koen> I'm going to switch back to gcc 4.2.2 in armv6 mode for the time being
  • [20:41:28] * koen notices that gcc 4.2.4 has been released
  • [20:53:49] <DJWillis> The whole ARMV7 is a bit to the edge at the moment I guess.
  • [20:58:39] <sakoman> does anyone know if the x-loader at http://beagleboard.googlecode.com/files/x-load.bin is suitable for use in nand?
  • [20:58:50] <sakoman> Or do I need to build a special version?
  • [21:09:07] <koen> try it and see :)
  • [21:09:20] <sakoman> I already did -- it didn't work
  • [21:09:32] <sakoman> was just wondering whether it *should* work
  • [21:10:06] <sakoman> the bits I write come back correctly when I load them from flash
  • [21:10:24] <sakoman> so the write/read process seems to work
  • [21:10:40] <koen> I suspect x-loader is tailored for mmc atm
  • [21:11:02] <koen> jkridner_ should know :)
  • [21:11:28] <sakoman> I think he is on vacation this week :-(
  • [21:14:04] <koen> wasn't that last week?
  • [21:14:52] <koen> anyway, we should be able to put kernel and rootfs in nand now
  • [21:15:05] <koen> even if x-loader and u-boot are on sd
  • [21:15:48] <sakoman> sure, I want it all though!
  • [21:16:33] <koen> I'm pretty happy with my 'progress' on OTG :)
  • [21:16:59] <sakoman> yeah, I just needed to enable it in defconfig
  • [21:17:07] <koen> indeed
  • [21:21:36] * BThompson (n=BThompso@nat/ti/x-a2d4f2766e79fc62) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [21:26:07] <sakoman> Is it just me or does the partition map at http://beagleboard.org/flashing make no sense?
  • [21:26:53] <sakoman> it reserves 256k for u-boot, but the current u-boot is 700K+
  • [21:27:52] <sakoman> it reserves twice that much for xloader, but xloader is only 16k
  • [21:34:19] <sakoman> yeah, comparing it to the EVM partition map, things just aren't right
  • [21:34:58] <sakoman> bummer, more work :-(
  • [21:35:52] <sakoman> have to build a new u-boot that saves its environment in a reasonable spot
  • [21:36:33] <sakoman> time for a break!
  • [21:48:39] * Crofton just fell off hist bike
  • [21:55:42] <jkridner_> what should I know?
  • [21:55:46] * jkridner_ is now known as jkridner
  • [21:55:52] <jkridner> I just got back.
  • [21:55:56] <jkridner> back to work tomorrow.
  • [21:56:22] <jkridner> there are 2 x-loader versions...
  • [21:56:35] <jkridner> there should be one floating around tailored for NAND booting.
  • [21:57:02] <jkridner> the one up on code.google.com today is indeed targeting MMC/SD boot.
  • [21:57:07] <Crofton> wb
  • [21:58:10] <Crofton> do you mind if I use some slides from ti presentarions in a presentation i will do next week
  • [21:59:15] <jkridner> i don't mind. could be nice to get a copy of what you do.
  • [22:00:35] * jkridner is listening to moronic cable company machine.
  • [22:06:36] <jkridner> beagleboard.org/flashing was for a previous BeagleBoard based on OneNAND. There were only 5 made.
  • [22:07:01] <jkridner> Rev. A switched to NAND and moved the serial port to ttyS2, rather than ttyS0.
  • [22:10:26] <sakoman> jkridner: where can I find the x-loader suitable for nand?
  • [22:12:11] <sakoman> is the xloader source code available intended for nand or mmc?
  • [22:12:31] <sakoman> I know I can find out by reading the code, but I'm lazy :-)
  • [22:13:59] <jkridner> what is on code.google.com is for MMC.
  • [22:14:23] <jkridner> It seems to me that the NAND code was floated at some time.
  • [22:14:31] <sakoman> any pointers?
  • [22:14:35] <jkridner> Nishanth.
  • [22:14:48] <jkridner> Hi NishanthMenon...
  • [22:15:04] <jkridner> do you have x-loader for NAND for Beagle Rev. A or B?
  • [22:15:39] <sakoman> jkdridner: was the u-boot for rev A really that much smaller?
  • [22:15:52] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) has joined #beagle
  • [22:15:56] <sakoman> < 256K vs 700K today?
  • [22:17:25] <jkridner> has it really grown to ~700K?
  • [22:17:35] <jkridner> I know that the # of commands built in has changed.
  • [22:17:57] <jkridner> the defconfig pulls in a lot more now, but I am very surprised it would grow that much...
  • [22:18:40] <jkridner> FAT/MMC code is new since that rev.0 flashmap.
  • [22:19:00] <jkridner> assuming you are talking about rev.0, not rev.A.
  • [22:19:50] <sakoman> e$ ls -l ~/Desktop/u-boot.bin
  • [22:19:50] <sakoman> -rw-r--r-- 1 sakoman sakoman 717948 2008-05-27 15:19 /home/sakoman/Desktop/u-boot.bin
  • [22:20:17] <sakoman> It is the one from http://code.google.com/p/beagleboard/wiki/BeagleSourceCode
  • [22:20:57] <sakoman> fat/mmc shouldn't make it that big -- IIRC the one for gumstix is ~ 140K
  • [22:22:51] <jkridner> my only quick guess is that it is building in more commands with the defconfig.
  • [22:23:03] <jkridner> I haven't kept track of the image size growth.
  • [22:34:54] * aggieben (n=bc@dhcp7-57.geusnet.com) has joined #beagle
  • [22:35:02] * aggieben (n=bc@dhcp7-57.geusnet.com) has left #beagle
  • [22:36:38] * prpplague (n=dave@mail.americanmicrosystems.com) Quit ("Leaving")
  • [22:38:43] <sakoman> well, I have to build a fresh u-boot in order to put the environment in a reasonable spot. Doesn't matter when u-boot is launched from mmc, but the way it is now it would be overwriting itself when you do a saveenv
  • [22:39:58] <sakoman> x-loader is the bigger challenge, since I need to get my hands on a nand binary or else the right source code (and figure out how to sign the resulting binary)
  • [22:41:44] <jkridner> the "signing" is a very easy process.
  • [22:42:32] <jkridner> since these are general purpose and not secure devices, the "signature" is trivial.
  • [22:42:49] <sakoman> Good! Guess I'll worry about it once I hear from Nishanth.
  • [22:43:52] <sakoman> In the meantime I'll work on re-doing the partition layout and putting together a recipe for u-boot so I can incorporate the needed mods
  • [22:44:16] <sakoman> So much for nand support being "low hanging fruit" ;-)
  • [23:22:00] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) has joined #beagle
  • [23:44:26] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) Quit ()
  • [23:46:53] * JoeBorn (n=jborn@dsl017-022-252.chi1.dsl.speakeasy.net) has joined #beagle