• [00:45:55] * NishanthMenon (n=gnat@nat/ti/x-c501bf580e53997f) Quit ("Copywight 2007 Elmer Fudd. All wights wesewved.")
  • [02:07:40] * DJWillis (i=djwillis@82-46-19-72.cable.ubr02.bath.blueyonder.co.uk) Quit (Read error: 104 (Connection reset by peer))
  • [03:32:10] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) Quit (Read error: 104 (Connection reset by peer))
  • [07:14:04] * koen (n=koen@s55917625.adsl.wanadoo.nl) Quit (kubrick.freenode.net irc.freenode.net)
  • [07:15:42] * koen (n=koen@s55917625.adsl.wanadoo.nl) has joined #beagle
  • [08:13:54] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) has joined #beagle
  • [08:48:00] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) Quit ()
  • [09:43:31] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) has joined #beagle
  • [10:02:27] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) Quit ()
  • [11:06:17] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) has joined #beagle
  • [11:28:14] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) Quit ()
  • [11:48:59] * jkridner|work (n=a0321898@nat/ti/x-1db2a69f5730bfe1) has joined #beagle
  • [12:05:44] <jkridner> sakoman: are you good with NAND code now?
  • [12:05:53] <jkridner> http://groups.google.com/group/beagleboard/browse_thread/thread/f7186c710d8b8986?hl=en#
  • [12:18:03] * Crofton notes linoil is 500K on his x86 machine
  • [12:28:44] <ldesnogu-> you meant liboil?
  • [12:29:02] <Crofton> yeah
  • [12:29:26] <Crofton> my typing is bad, right arm is really sore from falling off my bike
  • [12:29:39] <ldesnogu-> sport is so dangerous :)
  • [12:29:46] <koen> good morning all
  • [12:29:48] <Crofton> yeah
  • [12:29:49] <Crofton> gm
  • [12:29:51] <ldesnogu-> hi koen
  • [12:35:48] <Crofton> Can I build the dsp side of dsplink from Linux?
  • [12:36:40] * BThompson (n=BThompso@nat/ti/x-d3e4c33aca9acb20) has joined #beagle
  • [12:37:11] <Crofton> the instructions suggest it is possible, but I am wondering about C64 toolchains for Linux
  • [12:41:40] * richardw (n=richardw@nat/ti/x-0aed5b558653d484) has joined #beagle
  • [12:42:50] <koen> last I heard there's only a c54x toolchain for linux
  • [12:42:57] <koen> with missing headers
  • [12:43:14] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) has joined #beagle
  • [12:44:42] <BThompson> there is a C64x tool chain for Linux, it is just not included with the board
  • [12:49:28] <Crofton> the c^4 toolchain will work for OMAP3 and Davinci?
  • [12:49:30] * jkridner|work (n=a0321898@nat/ti/x-1db2a69f5730bfe1) Quit (Remote closed the connection)
  • [12:50:10] <Crofton> Since we have the gpp part of dsplink built, I guess I am getting interested in the DSP part
  • [12:50:31] <Crofton> this process is a whole lot easier when there are people to ask for help :)
  • [12:51:23] <BThompson> yea, the dsp core is essentially the same between the two, and the core is even backwards compatible with binary code from prior C6x processors
  • [12:51:39] <sakoman> jkridner: thanks for the pointer
  • [12:51:51] <BThompson> ive never built link though, and I am not sure it exists yet for OMAP
  • [12:51:57] <BThompson> well OMAP35x
  • [12:52:51] <sakoman> There are a couple of things I need to discuss with Khasim:
  • [12:53:48] <sakoman> 1. is that u-boot binary modified to avoid overwriting itself (and if so what does it assume for the environment partition)
  • [12:54:05] <sakoman> 2. The syntax for the last nand write seems wrong
  • [12:54:17] <sakoman> I'll reply to his email
  • [12:56:08] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) Quit ()
  • [13:00:05] <suihkulokki> sakoman: you may want ask about the alsa SoC driver on linux-omap list
  • [13:00:38] <sakoman> scratch my second comment -- obviously not enough coffe to do hex math in my head this early. the command is correct
  • [13:01:28] <sakoman> suihkulokki: I already pinged the list once about alsa SoC but got no responses
  • [13:01:43] <sakoman> or am I misunderstanding your question?
  • [13:02:15] <suihkulokki> do you have a link your ping?
  • [13:03:42] <sakoman> no - I use gmail so it is just sitting in my box. looks like I sent it on May 15
  • [13:05:00] <suihkulokki> This one, I presume: http://thread.gmane.org/gmane.linux.ports.arm.omap/8329
  • [13:05:29] <sakoman> yes
  • [13:06:45] <sakoman> There are about 4 pre-requisite mcbsp patches awaiting approval on linux-omap
  • [13:09:48] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) has joined #beagle
  • [13:09:50] <sakoman> I've got the basic structure of the alsa SoC driver completed to the point that alsa believes it to be a good driver. Next step is to glue in the appropriate twl4030 transactions to make the hardware work.
  • [13:10:27] <sakoman> Got sidetracked by beagle and nand support though :-)
  • [13:12:39] <ldesnogu-> Crofton, ftp://ftp.ti.com/pub/cs/linux_cgt500.tar.gz
  • [13:12:59] <ldesnogu-> this contains Linux executable with support for c64x+
  • [13:13:17] <ldesnogu-> it just lacks the code compressor, which results in failing compilations
  • [13:13:48] <ldesnogu-> just creating an empty shell for it is enough (unless of course you want code compression :))
  • [13:16:16] <koen> nah, we'll just sit down hard on the code ;)
  • [13:22:09] * prpplague (n=dave@mail.americanmicrosystems.com) has joined #beagle
  • [13:25:01] <Crofton> BThompson, I also have a dm6446 board I can practice dsplink on
  • [13:25:20] <Crofton> once dsplink appears for OMAP3, hopefully the build system
  • [13:25:30] <Crofton> 1) dos not change, so the existing bb file jsut works
  • [13:25:47] <Crofton> 2) the build system is sane and we can chang the bb file to be sane
  • [13:25:48] <Crofton> :)
  • [13:31:45] * jkridner|work (n=a0321898@nat/ti/x-60a40f3a2febed33) has joined #beagle
  • [13:42:01] <koen> ah, rc4 got merged
  • [13:50:37] * bazbell (n=a0192809@nat/ti/x-d6d09d7a1fd285c5) has joined #beagle
  • [14:04:28] <koen> heh
  • [14:04:50] <koen> it seems I reinvented the wheel with testlab.bbclass: http://alioth.debian.org/~fjp/debtree/index.html
  • [14:24:24] <sakoman> jkridner: I can confirm success with Khasim's binaries and procedure for xloader and uboot in nand
  • [14:25:27] <sakoman> I still need to check with him to make sure that saveenv target write offset is somewhere safe (and to then take that into account in the partition map)
  • [14:25:58] <sakoman> Next step is to try my kernel and rootfs in nand
  • [14:26:28] <Crofton> where does u-boot save the env?
  • [14:26:47] * bazbell (n=a0192809@nat/ti/x-d6d09d7a1fd285c5) Quit ("Leaving.")
  • [14:26:54] <sakoman> current sources save it at offset c0000
  • [14:27:35] <sakoman> uboot now resides at offset 80000 and is 160000 in length, so obviously c0000 will overwrite some u-boot code
  • [14:27:37] <jkridner|work> sakoman: thanks.
  • [14:28:07] <Crofton> my understanging of NAND is you send commands and read/write from a locations
  • [14:28:11] <jkridner|work> I'll update http://beagleboard.org/flashing to point to that e-mail. where did you find a link to that page?
  • [14:28:24] <Crofton> so it is byte serial?
  • [14:29:42] <sakoman> Crofton: with nand you read/write/erase blocks
  • [14:30:01] <Crofton> but data flow is byte serial?
  • [14:30:12] <Crofton> commnad data sort of things
  • [14:30:51] * bazbell (n=a0192809@nat/ti/x-a53d7d27a0a07942) has joined #beagle
  • [14:32:38] <sakoman> Crofton: I believe so -- I haven't had to dig into the lowest levels of the code, but I recall seeing comments about command and address latches :-)
  • [14:32:50] <Crofton> heh
  • [14:32:52] <Crofton> yeah
  • [14:33:46] <sakoman> jkridner: what link are you referring to?
  • [14:34:13] <sakoman> the flashing one?
  • [14:34:17] <jkridner|work> yes.
  • [14:34:25] <sakoman> if so, someone here (perhaps koen) posted it
  • [14:34:29] <jkridner|work> not sure where you found that link.
  • [14:34:30] <jkridner|work> k.
  • [14:34:49] <sakoman> I then refound it with google since I couldn't find a link to it
  • [14:34:58] <jkridner|work> there are a few pages I put up before we did Rev. A and never updated.
  • [14:35:01] <sakoman> So maybe it is an orphan
  • [14:35:14] <jkridner|work> I've replaced it with a link to the e-mail thread.
  • [14:35:44] <jkridner|work> It'll need to eventually get replaced with a proper memory map.
  • [14:53:01] <koen> wow
  • [14:53:09] <koen> uboot.bin: 947kiB
  • [14:53:35] * koen suspect the beagleboard logo is uncompressed inside the uboot blob
  • [14:53:55] <sakoman> koen: awe inspiring size, isn't it1
  • [14:54:11] <koen> I can build functional linux kernels smaller than that :)
  • [14:55:47] * koen has found out why the ???20 dremel clone is only ???20
  • [14:56:12] <Crofton> heh
  • [14:56:28] <sakoman> ah, you've rediscovered "you get what you pay for" :-)
  • [14:57:02] <jkridner|work> oh, right, the logo!
  • [14:57:18] <koen> it's great for model building according to my girlfriend :)
  • [14:57:31] <prpplague> average build for apex is about 16k
  • [14:58:16] <koen> jkridner|work: would building a uboot without the logo, audio warning and 3 second boot delay be hard?
  • [14:58:39] <koen> I think we can decrease the boot time by ~6 second by ditching the audiobeep and boot delay
  • [14:58:40] <jkridner|work> no, it wouldn't be hard.
  • [14:58:49] <jkridner|work> the logo is quite easy to remove.
  • [14:59:02] <koen> I like the logo, though
  • [14:59:10] <jkridner|work> I don't know as much about the audio tone, but I suspect that is easy.
  • [14:59:39] <jkridner|work> I've tried applying the patches against 1.3.3 and that went fine...
  • [14:59:49] <jkridner|work> just a few patches moved, but all still applied and worked.
  • [14:59:57] <koen> dirk can't get it to boot
  • [14:59:58] <sakoman> once khasim posts the source code I'll take a look at slimming it down a bit
  • [15:00:03] <koen> too many i2c errors
  • [15:00:05] <jkridner|work> I think you can pretty easily see the audio tone in the patches.
  • [15:00:42] <jkridner|work> removing bootdelay can be dangerous, but you can do it with 'setenv'.
  • [15:01:03] <koen> I know I can do it with 13.
  • [15:01:04] <koen> ehm
  • [15:01:15] <koen> 1.3.x, but 1.1.4 seems to lack the option
  • [15:01:16] <jkridner|work> By "dangerous", I mean that you may have to play tricks to switch bootargs.
  • [15:01:37] <koen> isn't that what the 'user' button does?
  • [15:02:32] <sakoman> kridner: now booting kernel from nand, will flash rootfs next
  • [15:03:54] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) Quit ()
  • [15:06:09] <koen> sakoman: don't update to 2.6.26rc4
  • [15:06:26] <sakoman> OK, I won't
  • [15:06:33] <sakoman> thanks for the warning!
  • [15:06:38] <sakoman> what breaks?
  • [15:06:43] <Crofton> my aem
  • [15:06:52] <sakoman> aem?
  • [15:06:56] <Crofton> arm that is
  • [15:07:03] <koen> the mcbsp patches needed for asoc
  • [15:07:06] <sakoman> from the bike fall?
  • [15:07:14] <Crofton> right arm is road rashed to heck from falling off bike last night :)
  • [15:07:28] <sakoman> ouch!
  • [15:07:32] <Crofton> yeah
  • [15:07:53] <Crofton> I can type, but it is sore, hard to use mouse
  • [15:08:06] <sakoman> koen: I hope Tony integrates those mcbsp patches soon
  • [15:08:19] <koen> sakoman: http://article.gmane.org/gmane.linux.ports.arm.omap/8570
  • [15:09:05] <koen> probably easy to fix, but annoying none the less
  • [15:09:39] <sakoman> I'm not sure why the delay in accepting the patches
  • [15:10:09] <koen> I suspect it conflicts with his multimachine kernel efforts
  • [15:10:15] <koen> but that's just a wild guess
  • [15:13:05] * NishanthMenon (n=nmenon@nat/ti/x-a91ff75c1a7a4588) has joined #beagle
  • [15:15:08] <jkridner|work> wrong bootargs. I'm meaning withing U-boot, not the pins.
  • [15:17:11] <sakoman> koen: time to add jffs2 to beagleboard machine.conf IMAGE_FSTYPES
  • [15:17:23] <koen> sakoman: :)
  • [15:18:20] <sakoman> crossing fingers that my last pull update doesn't force a big rebuild of x11 image
  • [15:18:33] <sakoman> all for jffs2 image
  • [15:20:05] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) has joined #beagle
  • [15:24:44] <koen> jffs2 image support added
  • [15:24:55] <koen> we might need to tweak the params, though
  • [15:35:23] <sakoman> wow, what is up with the initial bb file parsing?
  • [15:35:40] <sakoman> mines been going for about 10 minutes and is only 70% done!
  • [15:36:08] <sakoman> any big changes recently?
  • [15:37:23] <koen> RP fixes packaged-staging locking
  • [15:37:51] <koen> I have really slow disks, so any reparse takes eons over here
  • [15:39:00] <sakoman> up to 82% now
  • [15:39:54] <koen> and I think both gcc and glibc got updated
  • [15:40:06] <koen> bitbake -b console-image.bb might be a lot faster
  • [15:40:25] <sakoman> if only I'd known :-)
  • [15:41:47] * dirk2 (n=dirk@F3369.f.strato-dslnet.de) has joined #beagle
  • [15:42:32] <dirk2> smaller uboot without tone and logo (untested): http://groups.google.com/group/beagleboard/browse_thread/thread/310290747b00ea51
  • [15:44:32] <sakoman> dirk2: where does this u-boot save its env?
  • [15:44:39] <dirk2> jkridner|work: Thanks for improving eLinux page
  • [15:44:48] <sakoman> still c0000?
  • [15:45:34] <dirk2> sakoman: Don't know ;) It is the original TI 1.1.4 from code.google.com page + 500MHz + don't disable L2 for kernel.
  • [15:45:45] <dirk2> And now without tone and logo
  • [15:45:52] <sakoman> 260000 would be better
  • [15:46:14] <dirk2> Where to change this? Building takes ~1 min ;)
  • [15:47:57] <dirk2> Ah, have it:
  • [15:48:04] <dirk2> #define ONENAND_ENV_OFFSET 0xc0000 /* environment starts here */
  • [15:48:11] <dirk2> #define SMNAND_ENV_OFFSET 0xc0000 /* environment starts here */
  • [15:48:20] <sakoman> yes, you beat me to it :-)
  • [15:48:28] <dirk2> Shall I set both to 260000 and send you the result?
  • [15:48:36] <sakoman> yes, that would be great!
  • [15:50:01] <dirk2> rebuild (cause of config change) runs....
  • [15:51:44] <sakoman> koen: NOTE: Checking if staging package installed
  • [15:51:44] <sakoman> ERROR: function staging_helper failed
  • [15:52:02] <sakoman> does this mean a clean build is required?
  • [15:54:13] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) Quit ()
  • [15:55:04] <koen> sakoman: you'd have to ask RP
  • [15:55:35] <koen> sakoman: I've been doing builds from scratch a lot to test gcc versions :/
  • [15:55:48] <dirk2> sakoman: You should get a mail in some seconds
  • [15:55:52] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) has joined #beagle
  • [15:55:57] <sakoman> oh, the pain! I just need a jffs2 image of somehting that is already built :-(
  • [15:56:15] <sakoman> doing the bitbake -b fails too
  • [15:56:28] <koen> tony says: "Sounds like you need to #include <linux/io.h> from mcbsp.c.
  • [15:56:29] <koen> "
  • [15:59:50] <sakoman> koen: any chance you could post a j2ffs of console image?
  • [16:00:55] <sakoman> dirk2: got it. Thanks!
  • [16:12:34] <sakoman> dirk2: seems to work. boots my kernel without the L2 cache warning
  • [16:12:43] <sakoman> much smaller too :-)
  • [16:12:52] <koen> sakoman: sure
  • [16:13:23] <sakoman> dirk2: no audio tone, starts faster too :-)
  • [16:13:36] <sakoman> nice work!
  • [16:13:50] <dirk2> :)
  • [16:14:16] <sakoman> I have a feeling Khasim's u-boot from this morning still wrote the env at c0000 because your u-boot couldn't find the env
  • [16:15:06] <dirk2> Can you dump memory with uboot & NAND?
  • [16:16:15] <sakoman> yes, you can nand read to ram and then dump memory
  • [16:17:51] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) Quit ()
  • [16:18:57] <sakoman> dirk2: I used that technique to verify your u-boot was writing the env in the right place
  • [16:23:07] <sakoman> koen: no reply from RP, so I just kicked off a clean build
  • [16:23:19] <sakoman> shoots productivity for a few hours :-(
  • [16:23:53] <koen> sakoman: jffs2 upload ETA 50 seconds
  • [16:24:05] <sakoman> excellent! Thanks
  • [16:25:06] <koen> /OE/angstrom-tmp/work/beagleboard-angstrom-linux-gnueabi/console-image-1.0-r0/temp/log.do_rootfs.32129
  • [16:25:09] <koen> grrr
  • [16:25:15] <koen> http://amethyst.openembedded.net/~koen/beagleboard/Angstrom-console-image-glibc-ipk-2008.1-test-20080528-beagleboard.rootfs.jffs2
  • [16:25:45] <sakoman> koen: thanks
  • [16:26:06] <sakoman> btw, I've been meaning to mention I am having trouble with the fb on beagle:
  • [16:26:07] <sakoman> omapfb: configured for panel omap3beagle
  • [16:26:07] <sakoman> coherent allocation too big (requested 0x240000 mask 0xffffffff)
  • [16:26:07] <sakoman> omapfb omapfb: unable to allocate FB DMA memory
  • [16:26:17] <koen> the tar.bz2 is on its way as well
  • [16:26:24] <koen> sakoman: using the defconfig from OE?
  • [16:27:01] <koen> you need CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=4
  • [16:27:08] <koen> iirc the default is 2
  • [16:27:17] <sakoman> ah, OK
  • [16:28:16] <sakoman> I started with the git defconfig in preparation for submitting patches
  • [16:28:31] <sakoman> I'll fix that
  • [16:28:32] <koen> I suspected as much :)
  • [16:30:36] <jkridner|work> hooray, https://www-a.ti.com/extranet/cm/product/dspinfonet/dspinfoext/general/omap_power.shtml is live.
  • [16:31:06] <jkridner|work> hmmm.... may be internal only... may have jumped the gun there.
  • [16:31:08] * koen notes the pun
  • [16:34:12] <koen> jkridner|work: the "extranet" in the url is a bit of a giveaway ;)
  • [16:34:18] <jkridner|work> :(
  • [16:34:26] <jkridner|work> didn't read the e-mail right.
  • [16:35:07] <jkridner|work> "public" doesn't always have the same meaning to various people.
  • [16:35:29] <koen> heh
  • [16:35:43] <koen> just like "just works" or "soon"
  • [16:40:32] <koen> beagle stability is better when not using ehci
  • [16:42:50] * dirk2 (n=dirk@F3369.f.strato-dslnet.de) has left #beagle
  • [16:45:42] <koen> heh, the replies to my mail to linux-omap arrived before I received the original myself
  • [16:48:44] * GAN8001 (n=GAN8001@pdpc/supporter/active/generalantilles) has joined #beagle
  • [16:52:20] * DJWillis (n=djwillis@82-46-19-72.cable.ubr02.bath.blueyonder.co.uk) has joined #beagle
  • [17:03:28] <sakoman> jkridner: hmm . . . uboot won't let me erase anything past offset 800000
  • [17:04:24] <sakoman> Am I missing something? seems that is only the 8MB boundary. ought to be lots of space after that!
  • [17:04:42] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) has joined #beagle
  • [17:05:49] * koen is now runnng the latest dirk uboot
  • [17:05:57] <koen> ready for NAND goodness :)
  • [17:06:04] * koen heads to a meeting
  • [18:07:13] * bazbell (n=a0192809@nat/ti/x-a53d7d27a0a07942) Quit ("Leaving.")
  • [18:17:08] <koen> sakoman: did the nand rootfs work ok?
  • [18:17:28] * bazbell (n=a0192809@nat/ti/x-115b8bc998c83ad2) has joined #beagle
  • [18:21:16] <sakoman> no, I'm running into issues erase nand :-(
  • [18:21:20] <sakoman> erasing
  • [18:21:54] <DJWillis> sakoman: still got that 8meg boundry problem?
  • [18:22:14] <sakoman> something like that
  • [18:22:21] <sakoman> trying to narrow it down
  • [18:22:38] <sakoman> any experience with the uboot nand commands?
  • [18:22:54] <sakoman> they worked fine for xloader, u-boot, and uImage
  • [18:23:00] <DJWillis> sakoman: only when they work.
  • [18:23:43] <DJWillis> Is UBoot configured for the correct NAND size? I know it's an insluting question to ask ;-)
  • [18:23:50] <Crofton> I am pissed I didn't have the HRM on when I wrecked the bicycle
  • [18:24:55] <sakoman> DJWillis: I tried doing reads and writes at the top boundary and it acts as expected: I get an error when I try to go past 10000000
  • [18:25:13] <DJWillis> Crofton: HRM? Helmet? damm, you ok?
  • [18:25:26] <sakoman> But if I look in the header file it looks wrong
  • [18:25:43] <DJWillis> sakoman: hmmm, not just getting stuck in a loop is it?
  • [18:25:49] <sakoman> so maybe only the erase code checks?
  • [18:26:04] <sakoman> no, not a loop
  • [18:26:13] <Crofton> herat rate monitor
  • [18:26:14] <sakoman> just an error on the erase
  • [18:26:23] <Crofton> I'm ok, arm is sore, hard to get any real work done
  • [18:26:36] <Crofton> so looking into downloading from bike gps to PC via gpsbabel
  • [18:27:21] <DJWillis> Crofton: it takes a special type of person to smash themselves up then worry about the GPS data ;-)
  • [18:27:37] <sakoman> nand erase 680000 280000 gives OK
  • [18:27:53] <DJWillis> sakoman: got an example of the error? Just usual UBoot error?
  • [18:27:55] <Crofton> the heart data would be amusing
  • [18:28:00] <sakoman> nand erase 680000 300000 gives ERROR
  • [18:28:03] <Crofton> I want to see hwo fast I was going :)
  • [18:28:33] <sakoman> the precise error: NAND erase: device 0 offset 0x680000, size 0x300000 ERROR
  • [18:28:53] <DJWillis> And it is that exact offset?
  • [18:29:11] <sakoman> yes it is the exact desired offset
  • [18:29:39] <sakoman> so now it seems to fail when hitting 900000
  • [18:29:57] <sakoman> quite confusing
  • [18:30:05] <DJWillis> I meant, is it some range of offsets, well from the reply I guess it is.
  • [18:32:04] <DJWillis> sakoman: if it fails on a different offset everytime this sounds a lot like the timing issues we had with the old GP2X nand drivers (and the fact the code was horrid).
  • [18:33:48] <sakoman> if I try starting the erase at 780000 then it passes with a size of 180000 and fails with a size of 200000
  • [18:34:00] <sakoman> so it seems to be at 900000 consistently now
  • [18:34:33] <sakoman> maybe I did my mental math wrong earlier and it has always been at 900000
  • [18:34:56] <sakoman> My mental hex calculator has been know to make errors :-)
  • [18:35:10] <DJWillis> Not a 'real' bit of bad NAND is it? Tried poking around there and a little either side with small erases?
  • [18:35:36] <sakoman> will try that next
  • [18:37:06] <DJWillis> A real bad NAND and no way to neatly carve it up to get around it a'la the OpenMoko approch would suck
  • [18:37:36] <sakoman> ah, first bad block is at 940000!
  • [18:37:43] <sakoman> that explains the issue
  • [18:38:23] <DJWillis> How is your NAND driver looking after the BBT?
  • [18:38:29] <sakoman> better take a look at the openmoko approach
  • [18:38:48] <sakoman> BBT?
  • [18:38:51] <koen> ah, lcd4linux now autoloads on my beagle
  • [18:38:55] <koen> bad bloch table
  • [18:39:00] <koen> block*
  • [18:39:26] <sakoman> have no idea! it is the omap2 nand driver
  • [18:39:44] <sakoman> I'm diving into that code far more than I ever wanted to!
  • [18:39:52] <DJWillis> I think the Open Moko patch just overlays the concept of NAND partitions (that IIRC can be over more then one physical range).
  • [18:40:50] <sakoman> further study required! Didn't run into any of these issues with onenand
  • [18:41:52] <DJWillis> I think the base driver is a hell of a lot more solid, after being plagued with NAND issues in the past I am sort of glad we are sticking with OneNAND for the Pandora ;-)
  • [18:44:00] <koen> hmm
  • [18:44:10] <koen> my unix knowledge is rusty
  • [18:44:11] <koen> -rw------- 1 root root 22825 May 28 20:36 /etc/lcd4linux.conf
  • [18:44:16] <koen> what mode is that?
  • [18:45:51] <koen> 0440?
  • [18:46:06] <Crofton> 600?
  • [18:46:52] <koen> 600 indeed
  • [18:48:12] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) Quit ()
  • [19:42:57] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) has joined #beagle
  • [20:12:25] <sakoman> jkridner: has anyone at TI developed a strategy for dealing with bad blocks in nand?
  • [20:37:02] * bazbell (n=a0192809@nat/ti/x-115b8bc998c83ad2) Quit ("Leaving.")
  • [20:39:14] <jkridner|work> NAND bad block handling is in the roadmap...
  • [20:39:49] <jkridner|work> The latest internal release has bad block support for OneNAND...
  • [20:40:11] <jkridner|work> and it should be shared externally very soon.
  • [20:40:22] <jkridner|work> (day or two, I'd think)
  • [20:52:04] * RogerMonk (n=a0740758@nat/ti/x-9eb6970746c8894e) has joined #beagle
  • [21:09:20] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) Quit ()
  • [21:20:53] * BThompson (n=BThompso@nat/ti/x-d3e4c33aca9acb20) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [21:28:06] <richardw> sakoman: at which level are you having bad block issues. mask-rom has a duplication strategy. x-loader at one time did a skip bad block and assume next sector was logically next. U-boot can see them and uses kernel code on read. Write side in u-boot might be weak. You can put kernel in a JFFS2 partition and just have u-boot read and leave updating to the kernel which should be pretty good about write. Read-Disturb errors might be only
  • [21:28:06] <richardw> small problem in kernel but are pretty infrequent. Problems will be magnified when MLC NANDs start being common.
  • [21:29:38] <sakoman> richardw: it is the writing with uboot that is the issue -- the nand erase command fails when it encounters a bad block
  • [21:31:31] <sakoman> I assume that once I get it erased and use the nand write.jffs2 command to write the rootfs things should be OK
  • [21:31:37] <prpplague> richardw: hey hey
  • [21:32:29] <sakoman> Looks like I need to plan on putting the kernel in a jffs2 partition also in order to deal with bad blocks in that area
  • [21:32:58] <Crofton> koen, what's the best way to add the dsplink gpp side to images?
  • [21:33:47] <richardw> i've not used write.jffs2 for a long time. I don't recall if it worked with nand. It did with nor. Its been a couple years since I was serious with nand. JFFS2 on nand at that time was a read into a ram area, then parse it as if it were jffs2. This way nand and nor code was the same. The code has been long updated since then.
  • [21:34:42] <sakoman> richardw: I guess I should wait till TI makes their strategy public rather than start down some alternate path
  • [21:36:52] <richardw> strategy might be fragmented here. Different customers do different things at the loader level. It does get tied into a devices update strategy. there isn't great standardization there as far as I have seen.
  • [21:39:03] <prpplague> richardw: how goes the battle?
  • [21:40:13] <richardw> prpplague: ok I suppose. To many emails on to many different subjects.
  • [21:40:34] <sakoman> richardw: Guess I'll take a look at what gets released for onenand (hopefully in the next day or so) and take it from there
  • [21:41:23] <sakoman> It would be in TI's best interests to have some sort of "default" strategy in linux-omap git
  • [21:41:38] <sakoman> Sophisticated customers will always do their own thing
  • [21:41:43] <suihkulokki> I guess reading kernel from a UBI volume would be easier than from jffs2 ?
  • [21:41:44] <prpplague> richardw: hehe
  • [21:42:04] <prpplague> richardw: you still in the dfw area?
  • [21:42:25] <sakoman> suihkulokki: need to read up on UBI. any pointers?
  • [21:42:44] <sakoman> Does u-boot do UBI?
  • [21:43:21] <richardw> sakoman: yes, that is true. If you want to enable more than the biggest some reasonable default would be good.
  • [21:43:25] <suihkulokki> sakoman: http://www.linux-mtd.infradead.org/faq/ubi.html
  • [21:43:57] <richardw> prpplague: yep.
  • [21:44:07] <suihkulokki> sakoman: I don't think u-boot supports UBI (yet), but does it support jffs2 either?
  • [21:44:24] <prpplague> richardw: we'll have to get together sometime and let me buy you a beer, hehe
  • [21:44:25] <sakoman> yes, it does jffs2
  • [21:44:40] <suihkulokki> ew
  • [21:45:01] <sakoman> (if memory seerves me right)
  • [21:45:06] <suihkulokki> how fast is it to locate a kernel from a jffs2 partition?
  • [21:45:56] <richardw> used to be I used 2 jffs2 partitions one big enough for say 3 kernels and then a monster user one. This kept mount time issues down.
  • [21:45:58] <sakoman> not too terrible (recalling the old gumstix kernel in rootfs days)
  • [21:46:32] <sakoman> loading the kernel from its own partition was noticably faster though
  • [21:46:43] <suihkulokki> ah, static partitioning. suboptimal, but works.
  • [21:47:27] <richardw> you still can pass arguments to the kernel so its so so.
  • [21:49:00] * prpplague (n=dave@mail.americanmicrosystems.com) Quit ("Leaving")
  • [22:13:01] <koen> Crofton: MACHINE_EXTRA_RECOMMENDS = "dsplink-module" or something like that
  • [22:13:20] <Crofton> need the module and the gpp runtime
  • [22:13:38] <Crofton> hmm, wonders what that is
  • [22:13:44] <Crofton> maybe a samples
  • [22:14:08] <Crofton> crap I need to stop trying to work
  • [22:19:10] <koen> you mean dsplink.lib?
  • [22:22:16] <koen> sakoman: the 4MB dma bit got dropped from your patchset, do you want me to send a patch for that to tony?
  • [22:23:15] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) has joined #beagle
  • [22:24:37] <sakoman> koen: check my consolidated resubmission
  • [22:25:40] <sakoman> ah, I see. Tony already accepted the first group
  • [22:26:39] <sakoman> feel free to send a patch, otherwise I can send it with my next batch
  • [22:27:21] <koen> I'll send a patch for that in the morning
  • [22:27:25] <koen> (past midnight here)
  • [22:27:49] <koen> heck, I'll send one now :)
  • [22:28:21] <sakoman> OK, thanks! Sorry I missed that
  • [22:29:34] <sakoman> koen: sometime when you get a chance could you send me the output of "nand bad" typed at your beagleboard u-boot prompt?
  • [22:30:20] <sakoman> I'm curious what the bad block situation is on other beagleboards
  • [22:30:30] <sakoman> Crofton: could you do the same?
  • [22:30:42] <Crofton> ok
  • [22:30:53] <Crofton> can you remind me in the morning
  • [22:30:57] <Crofton> also which u-boot?
  • [22:30:58] <sakoman> sure
  • [22:35:33] <koen> Device 0 bad blocks: 03d20000 09440000 0c060000
  • [22:36:37] <koen> "only" 3
  • [22:45:24] <koen> sakoman: is that what you expected, 3 bad blocks?
  • [22:50:54] * richardw (n=richardw@nat/ti/x-0aed5b558653d484) Quit ("Leaving")
  • [22:53:12] * JoeBorn (n=jborn@dsl017-022-252.chi1.dsl.speakeasy.net) Quit (Read error: 110 (Connection timed out))
  • [22:53:42] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [22:56:48] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) has joined #beagle
  • [22:59:38] * atomicthumbs (n=atomicth@user-11fa3q5.dsl.mindspring.com) has joined #beagle
  • [22:59:59] <atomicthumbs> Does anybody have any idea when the new USB chip will be ready?
  • [23:00:59] <koen> has it already been decided that a new PHY will get used?
  • [23:01:11] <koen> last I heard TI was still debugging the SMSC one
  • [23:02:33] <koen> sakoman: Linux beagleboard 2.6.26-rc4-omap1 #1 Thu May 29 00:51:53 CEST 2008 armv7l unknown unknown GNU/Linux
  • [23:02:49] <koen> sakoman: #include <linux/io.h> indeed solved the compile problem
  • [23:04:56] <atomicthumbs> thought I read that it needed a new revision in the silicon
  • [23:05:06] <atomicthumbs> the Pandora project's waiting on it too :P
  • [23:08:48] * RogerMonk (n=a0740758@nat/ti/x-9eb6970746c8894e) Quit (Remote closed the connection)
  • [23:16:45] * atomicthumbs (n=atomicth@user-11fa3q5.dsl.mindspring.com) has left #beagle
  • [23:39:34] <GAN8001> Just stumbled onto the Beagle Board this morning. Bigtime maemo guy here, and I'm eagerly awaiting the opportunity to get my hands on one. A really awesome piece of hardware you guys've got!
  • [23:41:13] * calculus is in line too
  • [23:54:50] <Crofton> jkridner, any updates on when beagleboard.org will have a click to purchase button?