Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2008-11-29

00:02:29amiconnColdfire can do 16MB dma transfer (24 bit). PP does no DMA at all, it uses the arm FIQ and cpu transfers
00:02:36domonokyand about 16k samples is probably too less to hear any sound..
00:03:01gevaertsThat's 0.3 seconds or so. I'd think you'd hear that
00:03:20domonokythe dma controller has only 11bit for the transfer size..
00:03:30amiconnOnly if you have a track that doesn't start with silence
00:03:41amiconn(or near-silence)
00:04:22*domonoky test at moment with metronome (other problems with codes exists).. and a metronome tock probably starts with silence :-)
00:04:39bertrikcan we trigger an interrupt at the end of the dma transfer to setup the next dma?
00:04:45amiconnThat I don't think... the whole tock is quite short
00:05:36domonokybertrik: yes, there is a interrupt at the end of dma transfer, thats how we wakup the sd-code after a dma-tranfer.
00:05:44gevaertsdomonoky: are you sure it tries to play? metronome has its issues
00:06:03domonokyand how i know that dma ends before the fifo says its empty..
00:06:42bertrikI thought there were half-full and almost-empty interrupts
00:06:47domonokygevaerts: yes, i put a "play_tock()" at the beginning... and i am debuging the/my pcm code, so i know its called.
00:07:06domonokybertrik: i2sout also has interrupts..
00:07:37domonokyi check the i2sout interrupts to see if it really transfers something... and it does now :-)
00:12:50 Quit massiveH ("Leaving")
00:14:15domonokymaybe we should use the scatter/gather feature of the dma controller, then we would have to provide a linked-list of prepared dmac registers, but we would probably have unlimited transfer size.
00:14:45*bertrik spots a wiki edit by funman, where he claims charging support for sansa v2
00:25:04gevaertsamiconn: http://pastebin.ca/1269807
00:25:49 Quit bimbel ("Woah!")
00:26:05gevaertsI rechecked the r19248 c1000 result as well, and it is correct
00:26:12amiconnSo this is indeed faster, even more than I thought...
00:26:30amiconnDid you check whether it actually sounds correct?
00:26:57gevaertsno. I'll do that now
00:26:58amiconnBugs in this code are usually easy to notice - one little mistake, and all you get is white noise...
00:27:48*amiconn wonders why the -c1000 speed changes though
00:28:08amiconnCaching effects, perhaps
00:34:13*gevaerts doesn't hear anything at all...
00:34:18 Quit domonoky (Read error: 104 (Connection reset by peer))
00:34:31amiconnoh?
00:34:45*amiconn should test that code on the beast...
00:35:05pixelmagevaerts: do you hear something with other codecs, remember reading something in the d2 port thread
00:35:16gevaertspixelma: trying that now
00:35:41pixelmahttp://forums.rockbox.org/index.php?topic=10164.msg139842#msg139842
00:38:22*gevaerts tries that
00:41:04gevaertsThat helps
00:41:37gevaertsamiconn: it sounds correct at all compression levels (although -c4000 and -c5000 obviously skip a bit)
00:41:54amiconnthanks for testing
00:42:15 Join DB42 [0] (n=qwqw@bzq-79-178-64-198.red.bezeqint.net)
00:42:23DB42http://linuxoniphone.blogspot.com/2008/11/linux-on-iphone.html <−− when do we see rockbox for iphone ?
00:42:36gevaertsAre you working on it?
00:42:47DB42on what ?
00:42:50DB42check this http://www.vimeo.com/2373142
00:43:01gevaertsPorts only happen when people work on them
00:45:02linuxstbDB42: Why would you want Rockbox on an iphone?
00:45:20DB42why not ?
00:45:38linuxstbDo you know what Rockbox is?
00:45:44*gevaerts wants rockbox on his bicycle
00:47:46agaffneyI assume he means ipod touch instead of iphone
00:48:05BigBambigevaerts: Have you disassembled and scanned said bicycle?
00:48:39gevaertsWorking on it :)
00:59:07 Join reacocard_ [0] (n=reacocar@WL-135.CINE.HMC.Edu)
00:59:25 Quit reacocard (Nick collision from services.)
00:59:35 Nick reacocard_ is now known as reacocard (n=reacocar@WL-135.CINE.HMC.Edu)
01:00
01:00:11 Quit blithe (Broken pipe)
01:00:13 Join blithe [0] (n=blithe@li35-144.members.linode.com)
01:07:08 Quit n1s ()
01:13:23 Quit ender` (" Connection Reset by Gypsies with Wire Cutters")
01:15:07 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk)
01:24:10 Quit Schmogel (Read error: 104 (Connection reset by peer))
01:27:57 Join Frosty [0] (n=0c684f57@gateway/web/cgi-irc/labb.contactor.se/x-8b68677b45976323)
01:28:15Frostyhello, i am having some trouble creating a background picture
01:28:20Frostycan anyone out there help me?
01:28:28Frostyi have a picture that is in jpeg format
01:28:32 Part DB42
01:28:39Frostyhello???
01:29:25advcomp2019Frosty, have you read the manual?
01:29:47Frostyyes i have
01:30:07Frostyi also want to know why i cannot see my videos
01:30:09 Join shatness [0] (n=shat@c-67-161-135-156.hsd1.co.comcast.net)
01:30:17Frostytherefore not being able to play them on my sansa e250
01:30:39shatnessso anyone have the new Archos 7?
01:31:09shatnessive cracked it to an extent, but the bootloader is a pain
01:31:31Frostyadvcomp2019, ya there?
01:31:34Frostyis anyone there?
01:31:36 Join Strife89 [0] (n=michael@204.116.245.152)
01:31:38advcomp2019if i remember right, backdrops need to be bmp files and did you convert the videos right?
01:31:53Frostyi used the sansa video converter
01:31:55Frostywas i supposed to?
01:31:57LloreanNo.
01:32:06advcomp2019shatness, there is no rockbox for the archos 7
01:32:25shatnesscan u point me in the right direction for archos people
01:32:27Strife89advcomp2019: They also have to be the size of the display.
01:32:35shatnessi need some help and thought this was part of it
01:32:40Lloreanshatness: What exactly are you asking?
01:32:40shatnessmy mistake
01:32:45advcomp2019Frosty, so you have not read the manual then
01:32:47Strife89Frosty: Try WinFF, works like a charm.
01:32:50Lloreanshatness: Are you trying to port Rockobx?
01:33:01Frostyyes i have
01:33:03Unhelpfulshatness: if you're looking to help develop rockbox for the archos 7, you're in the right place...
01:33:06Frostywhat is WinFF
01:33:14shatnessI am seeing if anyone has had any experience with cracking the bootloader for an Archos but i think im in the wrong place
01:33:23Unhelpfulif you're looking for rockbox for archos 7, ready to use, we don't have it.
01:33:27advcomp2019Frosty, if you have, the video info is there to
01:33:33Strife89Frosty: http://code.google.com/p/winff/
01:34:12shatnessso does anyone know of a good irc chan for archos fans
01:34:23Frostyi have AVI videos and WMP videos
01:34:34Frostyboth dont show up when i go to the file that theyre supposed to be in
01:34:46LloreanFrosty: You need to convert them. The PluginMpegplayer page on the Rockbox wiki gives more information if the info in the manual isn't enough.
01:34:51 Quit bertrik ("Leaving")
01:35:07UnhelpfulFrosty: you *must* convert them to mpeg1/2 format to play them on rockbox
01:36:06Frostyare there any converters out there?
01:36:14Frostycan you give me a link or two?
01:36:16Frostytnks....
01:36:24LloreanFrosty: The PluginMpegplayer page on the Rockbox wiki has all the information you need
01:36:28LloreanSeriously, try reading the stuff we point you to.
01:36:29 Part shatness
01:36:43advcomp2019Frosty, the wiki page like Llorean said
01:37:08pixelmathe wiki page is also linked from the manual
01:37:16*Llorean thought it was.
01:38:52 Quit Frosty ("CGI:IRC")
01:39:21 Quit lasser (Read error: 60 (Operation timed out))
01:44:42 Join pabs_ [0] (n=pabs@xor.pablotron.org)
01:44:55 Quit pabs (Nick collision from services.)
01:45:03 Nick pabs_ is now known as pabs (n=pabs@xor.pablotron.org)
01:47:22 Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-57426eff3179f38a)
01:53:30 Join spartan [0] (n=0c684f57@gateway/web/cgi-irc/labb.contactor.se/x-64d94b2bbd0bba13)
01:53:32***Saving seen data "./dancer.seen"
01:53:35spartansup playas
01:53:43 Quit esthar ("KVIrc 3.4.0 Virgo http://www.kvirc.net/")
01:54:12spartancant get ma backdrop to stay everytime i restart my sansa e280
01:54:21spartani put it in the backdrop file
01:54:28spartanbut it does nothing
01:55:04spartanhola???????
01:55:23advcomp2019spartan, just hold on
01:56:44spartani think my friend, frostbyte was havin the same problem as i wuz
01:56:56spartanyou should help him if he's stal un
01:57:16Lloreanspartan: We did help him.
01:57:18 Quit tyfoo2 ("Carpe diem")
01:57:24spartancool
01:57:33LloreanIn fact, since you're on the same computer he was, he can tell you what we told him.
01:57:42spartangive me a sec
01:58:10spartanhe has the backdrop working
01:58:17spartanbut doesnt remember how he got it to work
01:58:25LloreanWe told him to read the manual.
01:58:28LloreanYou might try that too.
01:58:34spartanwhat manual?
01:58:48spartannvm
01:59:03LloreanPlease, try to use real English in here, as per the channel guidelines, and not things like "nvm" or "sup"
01:59:10spartank
01:59:13spartansorry
01:59:17LloreanThat includes "k"
01:59:27spartanalright, the video problem is still there
01:59:50spartanim going to give the computer over to my brother
01:59:57Unhelpfulyes, it will be until you convert your videos. you were even linked to a windows utility for that.
02:00
02:00:12spartanalright.....this is frostbyte, the video problem is still out there
02:00:27Lloreanspartan: Try reading the wiki page you were referenced to by several of us.
02:00:35advcomp2019did you use the wiki page?
02:00:44spartanmy brother just got on dude
02:01:02spartanyes, i did
02:01:05spartanno help
02:01:15saratogahas anyone tried the changes in FS #9570 - Sansa e200v1: Increased runtime by ~20% on an Ipod ?
02:01:15Lloreanspartan: Which method on the wiki page did you use?
02:01:30saratogai bet you'd get some improvement in battery life on those too
02:01:43spartancant remember
02:01:44spartansorry
02:01:56 Part pixelma
02:01:57Lloreansaratoga: Wasn't part of it committed?
02:02:11Lloreanspartan: Well, we can't help you if you don't know what you've done and what you haven't.
02:02:16spartanok, so how do i get the backdrop to work
02:02:21saratogaLlorean: yeah I commited the Sansa specific stuff, but not the PP PLL changes
02:02:29Lloreanspartan: Okay, stop asking the same questions over and over.
02:02:31spartanthats all im really trying to do
02:02:58Lloreanspartan: Read the documentation, and do what it says. When you run into a problem, tell us at what step in the instructions you're at, and what error you're encountering.
02:03:00spartani have read the manual twice now
02:03:01LloreanDon't try to guess what to do.
02:03:09saratogai didn't realize Toni had SVN access, so i'm just going to let him commit whenever he likes
02:03:10spartanthis is what i have done
02:03:27saratogaspartan: well you certainly haven't told us what you did
02:03:33saratogaso i wouldn't say you've done that
02:03:35spartan1)put BMP file in backdrop file
02:03:39Lloreansaratoga: Ah. How much power does the PLL alone save?
02:03:53spartan2) "set as backdrop"
02:03:58saratogaLlorean: Toni says 2mA on his Sansa
02:04:07spartanexcept i cannot find the file that is in the "backdrop" file
02:04:15spartanso i use a copy of the picture
02:04:23spartanin the "photo" file
02:04:26LloreanWell that's why it's not saving.
02:04:36spartanso how do i find the "backdrop" fonder
02:04:41spartanfolder*
02:04:46LloreanChange the file view mode to show all files, then browse to it.
02:04:58spartanhow
02:05:01LloreanIn the manual.
02:05:32kugelsaratoga: I believe someone reported ~16% (wasn't a proper battery bench though)
02:05:39spartanthank you
02:05:44spartannow to the video problem
02:06:23 Quit miepchen^schlaf ()
02:06:37saratogaLlorean: also, Toni made the patch for PP5022 and 5024 only, but it might also work on the PP5020, so its probably worth pulling out that ifdef and seeing if it works on those targets
02:06:39 Join miepchen^schlaf [0] (n=miepel@p579ECA54.dip.t-dialin.net)
02:06:39Lloreansaratoga: If that's true on all applicable PP targets, it should push us to fairly consistently match/pass the OF on them with that?
02:06:39 Quit herrwaldo ("Konversation terminated!")
02:06:52saratogayeah probably
02:07:13saratogai think we're probably already way past what the OF on the Sansa gets, though thats mostly because they seemed to have wasted a lot of power
02:07:29saratogathey somehow found an mp3 player as slow as ours
02:07:33LloreanWith MP3 we certainly are.
02:07:43saratogamp3 decoder rather
02:08:04LloreanSince we were about on-par with the OF when MP3 was single-core.
02:08:17saratogayeah
02:08:34saratogaif Toni is right I guess we're probably around 26+ hours on the Sansa with a new battery at least
02:08:48LloreanWow.
02:08:54*Llorean should order up a new battery
02:09:09saratogathough thats with the PLL changes
02:09:09LloreanI assume the V2s use the same battery as the V1s, is this a safe assumption?
02:09:16spartanLlorean, can you walk me through how to "convert" and "play" videos without telling me to go read a section in the manual that will not help me
02:09:22saratogaLLorean: yeah I think so
02:09:28saratogaspartan: no
02:09:40Lloreanspartan: How about you go and try to do it, and if you get stuck, ask us questions about the part you're stuck on.
02:09:48saratogago read it and stop asking the same questions over and over again you're getting annoying
02:09:51 Quit havien (Read error: 104 (Connection reset by peer))
02:10:18 Join esthar [0] (n=esthar@student166-183.hampshire.edu)
02:10:54spartanso it needs to be a mpeg conversion
02:11:17spartanam i right?
02:11:33Lloreanspartan: It says this in no uncertain terms on the wiki page, so yes.
02:12:10saratogakugel: [for the logs] I've noticed booting on the Fuze seems to fail on some bootloader builds for no obvious reason
02:12:15saratogai wonder if you've noticed this
02:12:20spartancan you give me the "wiki" page
02:12:21kugelheh
02:12:24spartanthanks
02:12:31saratogaoh didn't expect you to be up at this hour
02:12:53kugel2AM, not too late for weekend :p
02:12:57saratogaanyway sometimes I'll add a printf or whatever and that will cause the fuze to not boot anymore, then i'll add something slightly different and it will work
02:13:20spartanare there any other formats than mpeg that the video can be played in
02:13:30saratoganope
02:13:40spartanwow
02:13:41spartank
02:13:45kugelsaratoga: I use a pre-r19234 svn bootloader, which is pretty stable
02:13:57saratogakugel: also did funman ever mention what he thought the Clip V2 used as the CPU?
02:14:46spartananyone out there?
02:14:52kugelNo. I think we still assume the same as3525 soc, due to many many similarities in the OF (he took a look at it)
02:14:55spartanare you still there?
02:15:07saratogaspartan: theres like a hundred people here
02:15:11Lloreanspartan: You've been told the name of the wiki page several times, and it's even linked to in the manual.
02:15:28saratogakugel: I thought someone mentioned it was based on a slightly different AMS part
02:15:35Lloreanspartan: At this point, we're finding it somewhat unbelievable that you've even *tried* reading the manual.
02:15:36saratogathough i could be wrong
02:15:39spartani was just making a reference to portal
02:15:44kugelI could be wrong as well
02:15:51spartanguess no one on here plays games
02:15:57saratogaugh
02:16:05Lloreanspartan: This is an on-topic channel. That means "please be quiet unless you're developing Rockbox or asking support questions."
02:16:47Lloreanthere are channel guidelines that are linked to in the channel topic. Please, be aware that you're expected to follow them whether or not you had the courtesy to actually read them.
02:17:03saratogakugel: ah found something by funman speculating it might be AS3530 based
02:17:35saratogawhich would be cool, since its got ARMv5, more IRAM and I think its die shrunk since the power consumption looks a good bit lower too
02:17:39spartanquick question that isnt in the manual
02:18:00spartanare there any websites that support rockbox and have any games?
02:18:23LloreanYou can't really provide games without providing whole versions of Rockbox.
02:18:35 Quit esthar ("KVIrc 3.4.0 Virgo http://www.kvirc.net/")
02:18:36LloreanAnd no, we don't know of any sites like that.
02:18:46kugelsaratoga: possibly, but the clip is a top seller, I wonder why they should go for a more powerful design, given that the display and other features iirc did't change
02:19:20Lloreankugel: They upgraded the m200 to a SoC much more powerful than it needs too, didn't they?
02:19:32kugelI thought they just gave it more ram (like 8MB) since the firmware filesize is also 15MB like for the fuze/e200v2
02:20:04saratogakugel: maybe they're moving everything over to the new chips?
02:20:21spartanthanks and peace out everyone
02:20:21saratogakind of like when they introduced the V2 Sansas even though the old ones worked just as well
02:20:22spartan4
02:20:22spartan4
02:20:22DBUGSent KICK spartan to server
02:20:22spartan4
02:20:23***Alert Mode level 1
02:20:23DBUGsent MODE #rockbox +b *!*n=0c684f*@*.contactor.se/x-64d94b2bbd0bba13
02:20:23***Alert Mode level 2
02:20:23spartan4
02:20:23Kick(#rockbox spartan :No flooding!) by logbot!n=bjst@gateway/web/cgi-irc/labb.contactor.se/x-a4cf5f5668b5c9f2
02:20:23***Alert Mode level 3
02:20:23Mode"#rockbox +b *!*n=0c684f*@*.contactor.se/x-64d94b2bbd0bba13 " by logbot (n=bjst@gateway/web/cgi-irc/labb.contactor.se/x-a4cf5f5668b5c9f2)
02:20:25kugelLlorean: I don't know about the performance about the tcc chips, so possibly yes. I haven't said it's very unlikely
02:21:15kugelsaratoga: the v2s are a new product line though, which replaced a 2year old one, the clipv2 isn't
02:21:21saratogathe 3530 would be good for a View style player, so maybe we'll get a View V2 soon
02:21:31saratogathe e200V2 wasn't a new product line
02:21:44kugelwell, e200v2 is a refresh indeed, but I think that's mainly a ams one because they can share manufactoring etc
02:21:55saratogait was basically the same as what they did with the Clipv2
02:21:57saratogaand the c200v2
02:22:01 Quit XavierGr (Read error: 131 (Connection reset by peer))
02:22:02saratogaand the m200v4
02:22:27LloreanThey clearly seem to have a preference for trying to streamline the CPU choice, at least.
02:22:28 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr)
02:22:32kugeluhm, as I sad, I could be wrong as well :)
02:22:37LloreanMaybe we'll see e200/c200v3 soon.
02:22:45LloreanActually, I doubt it.
02:22:53LloreanIt kinda looks like they're on the verge of cutting them off completely
02:22:58kugela fuzev2 is more likely I think
02:22:58saratogayeah they'll probably just cancel them
02:24:28LloreanTheir page suggests the only Sansas they care about now are the Fuze, View, Clip and the "slotMusic" player thingy
02:25:45saratogaso are we hoping on having album art resizing for 3.1?
02:27:15LloreanI was hoping on having it for 3.0, personally.
02:27:51LloreanBut if we are gonna have it, it'd be nice to get it in during the next week or so, so it has a little shakedown time before the freeze.
02:28:24saratogamemory use seems way down, but i wonder if its low enough for everyone's taste?
02:28:39Unhelpfuli just addressed the last bug idak found. i'm not sure how it never hit me, i think larger target sizes made the off-by-one error i found round away
02:28:49Lloreansaratoga: Well, we all accept there's gonna be *some* memory hit.
02:28:49BensawsomeLlorean rockbox gonna stop support for the e200? :(
02:28:58LloreanBensawsome: No. Sandisk is probably going to.
02:29:07saratogai think sandisk already did
02:29:13Bensawsomeoh thank goodness :) i couldnt live without rockbox
02:29:16saratogaUnhelpful: so how close is it to ready?
02:29:24Lloreansaratoga: And as long as the framework is in place, we can probably swap out scaling algorithms if we really feel the size is an issue.
02:30:19saratogait'd be really nice if we could get it in for 3.1
02:30:24***Alert Mode OFF
02:30:38saratogamight motivate people to start working on a JPEG decoder, which if resizing is any indication, should take about 3 years or so
02:30:46saratogawe'll have it ready in time for 3.17
02:31:22 Join esthar [0] (n=esthar@student166-183.hampshire.edu)
02:31:54Unhelpfulsaratoga: the only "readiness" question i have left is binsize, and the biggest binsize and ram hit is on the color targets, since the b/w targets use only the nearest-neighbor scaler.
02:32:14saratogaUnhelpful: whats the memory hit like on the BW targets? negligable right?
02:32:36LloreanI can't imagine we'd be using it on true B&W (non-Grayscale) targets, would we?
02:33:03saratogaprobably not, but theres still the framework and buffering stuff which probably adds some memory
02:33:06UnhelpfulLlorean: no, but there are changes to the bmp reader core as well, and there will be some change on mono targets
02:33:44saratogaobviously its important that mono targets have as small an effect as possible, since many of them are extremely memory limited
02:33:45LloreanThe important question is, how small of an impact can you make it have on the true mono targets since those are the ones where RAM is really, really essential for battery life.
02:34:15saratogathe X5 too is probably important since I think thats only got 16GB and of course a color target
02:34:29saratogasorry 16MB
02:34:56LloreanWe have a few 16MB Grayscale targets too.
02:35:15LloreanBut isn't the whole memory hit less than 15k?
02:35:37UnhelpfulLlorean: only the color scaler adds any new static buffers. everything else goes on stack... so the hit on a mono target is roughly the cost of the code complexity in the chunked reader.
02:36:09LloreanUnhelpful: Is there an ifdef for album art?
02:36:21LloreanIs it possible to use the old code if album art isn't enabled?
02:39:51Unhelpfulat present, no, there isn't. the chunked reader itself is quite likely not a good idea to try to ifdef, since we'd have to maintain two copies of the bmp reader. i could certainly add the direct-output code back, and have it ifdef'd for selection if album art is disabled.
02:40:40Unhelpfulright now, *all* bmp reads on greyscale go through the NN scaler. mono targets get direct output in bmp.c, because there's no scaler built for them, and color does because its scaler is full of multiplies.
02:41:20saratogaUnhelpful: I think people will complain if we try to commit resizing without a define in the target config files that allows one to get the mono target case
02:41:56saratogaand anyway it might be handy if we ever get a seriously memory limited grayscale target or something
02:42:42kugelsaratoga: did you already try a pre-r19234 bootloader?
02:42:48Unhelpfulshould it be ifdef'd for album art, though, or a new ifdef for the scaler itself? right now, anything that wants to ask for scaled bitmaps can.
02:43:44 Quit MethoS (Remote closed the connection)
02:44:07 Quit Strife89 ("Bye, guys!")
02:44:57 Nick krazykit` is now known as krazykit (n=kkit@76.251.247.179)
02:45:01saratogakugel: yeah I already had an older SVN checkout handy, using the current one doesn't work at all
02:45:12Unhelpfulsaratoga: if i'm understanding correctly, you think there will be people who demand the scaler on mono?
02:45:35saratogaUNhelpful: no i think there will be people who think the memory use isn't justified and want to reclaim it
02:45:46saratogaor as much of it as possible at any rate
02:46:22saratogai guess these people should just get nearest neighbor or even a truncated bmp
02:46:38Unhelpfulsaratoga: mono targets get a minimally-adapted direct-output case. the only memory hit is a few more lines of code to test if the chunk buffer is empty, and call to refill it.
02:46:48saratogai'm sure thats fine
02:47:11saratogabut someone will complain that 15KB is too much on some color target, so there should be a way to reclaim most of that
02:47:40Unhelpfuli didn't think i was using so much? let me check again.
02:48:34saratogaoh maybe i'm remembering an old version of the patch
02:50:20kugelsaratoga: Then funman really broke it with his commit
02:50:37Unhelpfulsaratoga: the old version of the patch had an unscaled bmp line cache. that is gone. what we have now are two screen-width static buffers of uint32_rgb, so about 5KiB of static buffer increase on 240px-wide displays
02:51:10saratogathats not bad
02:51:14Unhelpfulthe line buffers will need to go from LCD_WIDTH to MAX(LCD_WIDTH,LCD_HEIGHT) if we ever need to handle a rotated format
02:51:32kugelwhat happened to partial line processing?
02:52:20Unhelpfulkugel: that is there, but that's only on input. the scalers require whole-line buffers in the output size. i've yet to find a reasonable way around it, unless they are allowed to seek arbitrarily in the input file.
02:52:49Unhelpfulthe input buffer is 8 * uint8_rgb, and is on the stack
02:53:18kugelUnhelpful: can't you use the buffer that was always there for output?
02:53:50kugelthe old read_bmp allocated the amount needed, afairc
02:54:47kugelif there's a new output buffer, what happened to the old one?
02:54:48Unhelpfulkugel: not really, unless the reader is passed a buffer that is guaranteed to have more space than needed for the final output
02:56:22kugelUnhelpful: I think there was two function, the 1 returned the buffer size needed, the other did the reading
02:57:49Unhelpfulkugel: i could do that, certainly... but if the scaler *is* to be used outside of a plugin or AA context, where does that buffer come from?
03:00
03:00:54kugelUnhelpful: well, one that's smaller then the one you made. It'll not be needed for big stuff. If it's not enough, I think it's reasonable to steal from audio buffer (with stopping playback if necessarily)
03:02:07kugelbut well, 5KiB ain't bad, so
03:02:39Unhelpfulkugel: that's on a color target, with a 240px wide screen. mono targets and grey targets get no new static buffers.
03:02:40kugeland it'll be less on targets with lowmem since they have generally not 240px wide screens
03:03:15Unhelpfuli'm running some builds on mrobe now to see what the binsizes look like on a mono target (i don't have a coldfire toolchain)
03:07:55kugelUnhelpful: get one, it's for free :)
03:08:37Unhelpfulkugel: i don't have any reason to keep one installed ;P
03:19:33saratogakugel: does the button code in button-fuze.c work?
03:20:16 Quit toffe82 (Read error: 60 (Operation timed out))
03:24:58kugelsaratoga: only in the bootloader
03:27:26kugelcu all
03:27:31 Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.4/2008111318]")
03:34:56Unhelpfulhrm, i had a good deal more cruft i could strip on mono targets.
03:46:04 Join Darksair [0] (n=user@118.227.0.5)
03:53:37***Saving seen data "./dancer.seen"
03:57:46 Quit SoapWork ("CGI:IRC")
03:57:58 Quit daurn ("Cyas later...")
04:00
04:10:12 Join blkhawk- [0] (n=blkhawk@g228069065.adsl.alicedsl.de)
04:11:53 Quit esthar ("KVIrc 3.4.0 Virgo http://www.kvirc.net/")
04:17:29 Quit Thundercloud (Remote closed the connection)
04:22:47 Quit whj (Remote closed the connection)
04:24:19 Join jhulst [0] (n=jhulst@unaffiliated/jhulst)
04:26:28 Quit blkhawk (Read error: 110 (Connection timed out))
04:27:11 Nick blkhawk- is now known as blkhawk (n=blkhawk@g228069065.adsl.alicedsl.de)
04:34:02Unhelpfullatest is on #9458, along with rockbox-info.txt for svn trunk, old resize, and new resize, for m:robe 100, e200, and ipod 4g. the hit looks to be ~1.7KiB on m:robe 100, 4.1KiB on iPod 4G, and 12.7KiB on e200, in terms of total bin+ram size increase.
04:41:12saratogaah the as3525 has an extra 4 pins dedicated to the DBOP that aren't shared with the GPIO, i bet thats where the wheel connects
04:48:38 Quit faemir (Read error: 104 (Connection reset by peer))
04:48:51 Quit Darksair ("(define (add-1 n) (lambda (f) (lambda (x) (f ((n f) x)))))")
04:56:02 Join hillshum [0] (n=hillshum@75-165-228-146.slkc.qwest.net)
04:58:39hillshumAre the e200v2 bootloaders building well for all?
05:00
05:02:34saratogahillshum: the fuze one is broken right now, so maybe not
05:03:11hillshumokay so its not my cygwin
05:03:22 Quit hillshum ("Leaving")
05:07:48saratogahmm I can't figure out how to read the stupid DBOP pins
05:07:58saratogawill try again tomorrow
05:08:14 Quit miepchen^schlaf (Read error: 110 (Connection timed out))
05:10:44 Quit saratoga ("CGI:IRC (EOF)")
05:16:59 Join advcomp2019_ [0] (n=advcomp2@unaffiliated/advcomp2019)
05:17:39 Quit advcomp2019 (Read error: 54 (Connection reset by peer))
05:20:52 Nick advcomp2019_ is now known as advcomp2019 (n=advcomp2@unaffiliated/advcomp2019)
05:42:52 Quit reacocard (Read error: 145 (Connection timed out))
05:53:38***Saving seen data "./dancer.seen"
05:58:32 Quit aarcane ("Leaving")
06:00
06:02:35 Join reacocard [0] (n=reacocar@WL-135.CINE.HMC.Edu)
06:07:13 Quit HellDragon (Read error: 104 (Connection reset by peer))
06:07:50 Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca)
06:07:55 Quit amiconn (Nick collision from services.)
06:08:00 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn)
06:08:12 Quit pixelma2 (Nick collision from services.)
06:08:21 Join pixelma2_ [0] (n=marianne@rockbox/staff/pixelma)
06:08:23 Nick pixelma2_ is now known as pixelma2 (n=marianne@rockbox/staff/pixelma)
06:09:24 Quit HellDragon (Read error: 104 (Connection reset by peer))
06:09:28 Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca)
06:24:32 Join daurnimator [0] (n=fake@unaffiliated/daurnimator)
06:27:21 Join kronflux [0] (n=kronflux@blk-138-78-15.eastlink.ca)
06:27:28 Quit kronflux (Client Quit)
06:33:39Unhelpfulhrm, regarding the AlbumArt wiki page, there's a %?Cn conditional mentioned for testing if the next album has cover art... is it possible to display next-album cover art? if not, what's the intended use of the conditional?
06:34:14 Quit tchan ("WeeChat 0.2.7-dev")
06:34:33 Quit reacocard (".")
06:36:20 Join tchan [0] (n=tchan@c-24-12-190-140.hsd1.il.comcast.net)
06:38:34 Quit tchan (Client Quit)
06:40:47 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey)
06:42:23 Join reacocard [0] (n=reacocar@WL-135.CINE.HMC.Edu)
06:48:32 Join tchan [0] (n=tchan@c-24-12-190-140.hsd1.il.comcast.net)
06:53:24 Join reacocard_ [0] (n=reacocar@134.173.63.19)
06:54:22 Quit reacocard (Read error: 60 (Operation timed out))
07:00
07:02:48 Quit tchan ("WeeChat 0.2.7-dev")
07:06:03 Quit Bensawsome ("The awsome is gone :(")
07:08:11 Quit Zarggg (Excess Flood)
07:08:41 Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com)
07:14:12 Join tchan [0] (n=tchan@c-24-12-190-140.hsd1.il.comcast.net)
07:21:35 Quit XavierGr ()
07:37:02 Quit tchan ("WeeChat 0.2.7-dev")
07:38:07 Join Darksair [0] (n=user@118.227.1.116)
07:39:22 Join tchan [0] (n=tchan@c-24-12-190-140.hsd1.il.comcast.net)
07:45:01 Quit BHSPitLappy (Remote closed the connection)
07:46:43 Nick reacocard_ is now known as reacocard (n=reacocar@134.173.63.19)
07:49:14 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr)
07:49:36 Quit Darksair ("To Arch or Gentoo? That is the question...")
07:53:41***Saving seen data "./dancer.seen"
08:00
08:15:21 Quit jhulst (Read error: 60 (Operation timed out))
08:26:48 Join Darksair [0] (n=user@118.227.2.173)
08:27:20 Join _Auron_ [0] (n=DarkAuro@ppp-70-244-161-118.dsl.rcsntx.swbell.net)
08:50:58 Join Rob2223 [0] (n=Miranda@p4FDCC758.dip.t-dialin.net)
08:59:48 Join lasser [0] (n=chatzill@Wb48a.w.pppool.de)
09:00
09:09:08 Quit Rob2222 (Read error: 110 (Connection timed out))
09:22:51 Join DC1 [0] (n=dc1@70.107.141.199)
09:31:08 Join reacocard_ [0] (n=reacocar@134.173.63.19)
09:31:18 Quit reacocard (Read error: 104 (Connection reset by peer))
09:32:01 Quit Darksair ("People who are zhuangbility want to show their niubility but only reflect their shability.")
09:44:09 Join bmbl [0] (n=Miranda@unaffiliated/bmbl)
09:53:42***Saving seen data "./dancer.seen"
09:53:43amiconn_Unhelpful: m:robe100 should see no binsize hit, and neither should other monochrome targets...
09:54:06 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn)
09:55:18Unhelpfulamiconn: there will be some change, because the chunked bitmap reader is used, even when the scaler is not. i'm still trying to figure out where 1.7KiB is going, though. :/
09:55:52 Quit beast__ (Read error: 60 (Operation timed out))
09:56:00 Join beast__ [0] (n=jude@a82-95-176-205.adsl.xs4all.nl)
09:56:07amiconnThe comnbined numbers don't tell much. Stating the bin & ram delta separately would be more helpful
09:56:51 Quit pixelma2 ("-")
09:57:08 Join pixelma [50] (i=pixelma@rockbox/staff/pixelma)
09:57:17Unhelpfulamiconn: the full rockbox-info.txt for each target, vanilla and patched, are concatenated into a text file on FS #9458
09:57:19amiconnIt would be nice to keep the simple bmp reader for plain monochrome targets, as those are generally the most memory constrained ones (not the m:robe 100, but many others)
09:58:04 Join Darksair [0] (n=user@118.227.3.120)
10:00
10:00:19Unhelpfulmaybe it would be wise to split it out into a bmp-simple.c?
10:02:01Unhelpfulthere's something funny going on with the greyscale targets, also. i can load scaled images in sliding_puzzle just fine, but they're being mangled in album art. :/
10:07:21amiconnIf you want to compare binsizes for memory constrained monochrome targets, try e.g. Archos Recorder, or Sansa Clip
10:08:21 Join n1s [0] (n=nils@rockbox/developer/n1s)
10:09:13Unhelpfulamiconn: i was selecting from DeviceChart, which doesn't mention the clip. m:robe 100 is the only mono target on there that i already have a toolchain to build for.
10:09:17 Quit DC1 ("If Obi-wan ain't home then I don't know what the fsck we're gonna do. I ain't got no other connections on Tattooine.")
10:10:41amiconnThe Clip port isn't finished, but it's an arm target with only 2MB RAM
10:10:58amiconnThe archoses also have only 2MB RAM
10:11:47*amiconn has all 4 toolchains installed, even though he wouldn't need the mips toolchain at all atm
10:13:12Unhelpfuli do most of my dev work, most of my computing in general, on a laptop that never seems to have enough space. i'll try to find room for at least coldfire this weekend, and see if i can find a way to get the mono targets back to previous usage.
10:14:34amiconnThere is no monochrome coldfire target
10:16:25pixelmawhat about the Iriver remotes?
10:16:59pixelmaalthough they don't display album art or sliding_puzzle...
10:17:32Unhelpfulamiconn: i see that. that was more to have a wider range of grey targets to get stats on. i'll try the clip for now, and i guess i'll need an sh toolchain if i want to build archos firmwares
10:18:06Unhelpfulpixelma: no, but mono remotes use the same loader, including the scaler, on targets that have a grayscale or color display
10:18:23Unhelpfulthe inside loop of it has a switch for the output type
10:20:17pixelmabut that is additional to the main screen (colour or greyscale) so won't give helpful numbers
10:22:16n1sUnhelpful: just as a nit, that bitmap resize patch has some (very) long lines, our max is 80 cols :)
10:24:13Unhelpfuln1s: i've been trying to work on that. the longer #if conditions might also be more readable if split into a case per line
10:24:42n1syes
10:25:29Unhelpful... do C statements need a \ for line continuation?
10:25:53linuxstbNo
10:28:16*amiconn thought a bit about the dualcore split of the ape decoder
10:28:30amiconnIt seems some infrastructural rework in libdemac is needed for that
10:29:56Unhelpfulugh, yes, grep and wc tell me i've much to do in resize.c for <=80cols
10:30:39amiconnA frame is decoded in several chunks, and the various decoding stages need to be initialized at the start of a frame. But for dualcore, the filter and predictor are delayed, so they must not be reinitialized immediately
10:31:33amiconnThey also need the old context info, and chunk length
10:32:55amiconnI'm not sure whether the simple semaphore approach might work here (need to read up on semaphores), as the communication between the threads needs some more details than just flags
10:34:00Unhelpfuli suppose next you'll be wanting comments that explain how this works? ;)
10:39:35pixelman1s: I have the platform > keymap split almost ready for commit, went with naming the new files keymap-*.tex but it's a bit weird as it is a block within the other platform files. I guess I could commit anyways and someone who has a better idea can move it later... comments welcome
10:42:21 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
10:44:58pixelmabut I don't want to hide it away
10:51:16Unhelpfulhrm, there's something very funny happening on the m5 remote. makes me wonder if it's getting its bitmaps formatted wrong, since it's a different greyscale from the main display.
10:54:27amiconnThe m5 remote does have a different pixel format than the main lcd
10:57:16 Quit Darksair ("Use the Force, Luke!")
10:57:50Unhelpfulamiconn: i know. there's a "for the remote" flag passed to the scaler, which gets passed to the NN scaler, where there are switches for the main or remote case for each target.
10:59:09 Quit reacocard_ (Read error: 104 (Connection reset by peer))
11:00
11:00:01 Join miepchen^schlaf [0] (n=miepel@p579EC63B.dip.t-dialin.net)
11:11:07 Join reacocard [0] (n=reacocar@134.173.63.19)
11:14:14Unhelpfulpreprocessed source shows that the switches are set up right for the target, remote==0 gets the vertical-packed format, remote==1 gets the vertical-interleaved... and the VI case works fine on the m3
11:25:03 Join ender` [0] (i=krneki@foo.eternallybored.org)
11:26:21 Quit avis (Remote closed the connection)
11:26:26 Quit reacocard (Read error: 104 (Connection reset by peer))
11:27:58 Join reacocard [0] (n=reacocar@134.173.63.19)
11:37:41 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon)
11:45:43 Quit JdGordon (Remote closed the connection)
11:46:59n1spreglow: ping
11:51:26pixelman1s: shall I hit enter or do you have a better idea? ;)
11:51:54n1spixelma: i didn't quite understand what you said earlier
11:52:14n1sare all action macros moved to keymaps now?
11:53:43***Saving seen data "./dancer.seen"
11:53:51pixelmayes. I meant the naming of the new files. Since all are named keymap-something.tex they appear between ipodvideo.tex and m5.tex if you view the content of the platform folder
11:54:07 Join Lynx_ [0] (n=till@xdsl-87-78-183-138.netcologne.de)
11:54:19n1saha, i think that's fine
11:56:45n1sUnrelated, i was thinking that on players that need to use 44.1kHz in the midi player we could use sample doubling to gain some speed or some crude interpolation maybe, would this sound worse than playing at 22kHz?
11:58:21Unhelpfulsample doubling is bad. linear interpolation wouldn't cost much more, and i'd expect it to sound a fair amount better.
11:58:30 Join RichterSkala [0] (n=para@e178021030.adsl.alicedsl.de)
12:00
12:01:46n1sUnhelpful: right, but would sample doubling at 44.1kHz sound worse than playing at 22kHz?
12:02:20Unhelpfuln1s: we have that as an option? i thought rockbox didn't handle output frequency switching?
12:03:05n1sUnhelpful: some players can do 22kHz out, but not all, however our playback system can not deal with frequencies other than 44.1kHz
12:03:56n1sso the players that can, use 22kHz in the midi plugin, it sounds a bit worse but gives enough speed gain to have more instruments playing...
12:04:01Unhelpfulbut if a plugin stops codec playback, it can change the playback rate of the hardware?
12:04:07n1syes
12:04:28n1sif it's implemented in that players' dac driver
12:05:34n1sthe define HW_SAMPR_CAPS in firmware/export/config-*.h tells which samplerates are supported on which target if you are interested
12:05:35Unhelpfuli understand now... i'd expect that zero-order-hold filtering the 22KHz up to 44.1KHz would be worse than playing at 22KHz, but i suspect you'll need to try it to find out.
12:06:19 Quit Horscht ("IRC is just multiplayer notepad")
12:12:48 Join stoffel_ [0] (n=sfr@p57B4E1E8.dip.t-dialin.net)
12:23:00 Join Horscht [0] (n=Horscht@xbmc/user/horscht)
12:29:39 Quit synergist (Remote closed the connection)
12:31:00bertrikI hope the USB problem on PP is not caused by a bug in the hardware with an unpublished work-around
12:32:00Unhelpfulcould be forever poking around OF disassemblies to figure out what it might be, then?
12:33:05 Join synergist [0] (i=christop@cant.be-arsed.co.uk)
12:34:29bertrikyeah, the only way to figure it out is to look at the OF and look for weird magic stuff, but it may not be immediately obvious
12:36:38gevaertsThat or looking at all sorts of register settings with jtag
12:37:07 Quit synergist (Remote closed the connection)
12:37:34 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon)
12:39:28 Quit stoffel_ ("leaving")
12:39:41 Join synergist [0] (i=christop@cant.be-arsed.co.uk)
12:41:56 Join faemir [0] (n=faemir@88-106-186-147.dynamic.dsl.as9105.com)
12:42:13 Join LosNir [0] (n=nirazuel@bzq-82-81-147-125.red.bezeqint.net)
12:42:39LosNirHi guys
12:45:49 Join herrwaldo [0] (n=waldo@ip-81-11-221-32.dsl.scarlet.be)
12:51:13 Join Darksair [0] (n=user@118.227.1.63)
12:54:27 Quit LosNir ()
12:54:51*gevaerts wonders where he should splice in the analyser when tracing a multi-hub setup (to make the PP issue more visible)
13:00
13:02:59linuxstbOne analyser between PC and hub, another between hub and PP?
13:05:33gevaertsOr one expensive two-port analyser?
13:06:01 Join zhufeng [0] (n=da4c53ef@gateway/web/cgi-irc/labb.contactor.se/x-208ec7f0da6b6f23)
13:06:07zhufenghi
13:06:18zhufengany developers here ?
13:06:41 Quit zhufeng (Client Quit)
13:06:49linuxstbBye
13:06:53 Join zhufeng [0] (n=da4c53ef@gateway/web/cgi-irc/labb.contactor.se/x-7b54dc9ebfd8b21f)
13:07:20linuxstbzhufeng: Yes, there are many - just ask your question.
13:07:52zhufengI wanna ask about the status of the Meizu port
13:09:03zhufenganybody else here ?
13:10:10 Quit zhufeng (Client Quit)
13:10:19 Join zhufeng [0] (n=da4c53ef@gateway/web/cgi-irc/labb.contactor.se/x-cf870915b45c5787)
13:11:22linuxstbzhufeng: Just be patient, and wait until someone that knows the answer reads your question...
13:12:23zhufengI know markun ,but it seems that he is not online now
13:13:36BigBambiThere are others too - as linuxstb says, people read the logs - wait until someone that knows reads your question and answers
13:14:25gevaertsThe forum thread is up to date as far as I know
13:14:46zhufengbut I didn't find any information here
13:15:02zhufengis there a port based on sigmatel 3710?
13:15:02 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky)
13:15:27 Join pixelma_ [50] (i=pixelma@rockbox/staff/pixelma)
13:17:23markunhi zhufeng :)
13:17:29zhufenghi
13:17:37zhufengwhy not in QQ ?
13:20:28 Join moos [0] (i=moos@81-66-158-133.rev.numericable.fr)
13:21:55 Quit pixelma (Nick collision from services.)
13:21:56 Nick pixelma_ is now known as pixelma (i=pixelma@rockbox/staff/pixelma)
13:22:35 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk)
13:24:40 Join mofux [0] (n=quassel@dslb-092-078-059-185.pools.arcor-ip.net)
13:24:41 Quit zhufeng ("CGI:IRC (EOF)")
13:28:49amiconngevaerts: amiconn.dyndns.org/pp502x_60mhz.diff">http://amiconn.dyndns.org/pp502x_60mhz.diff This lowers CPUFREQ_MAX to 60MHz - should be sufficient for experiments.
13:29:01amiconnIt's tested on Mini G2
13:30:04gevaerts404 again
13:31:06amiconnSorry, amiconn.dyndns.org/~jens/pp502x_60mhz.diff">http://amiconn.dyndns.org/~jens/pp502x_60mhz.diff
13:32:29gevaertsThanks
13:33:32 Join troy__ [0] (n=toppy@89.240.58.194)
13:34:02 Quit mofux (Remote closed the connection)
13:35:57 Join einhirn [0] (i=Miranda@p5B031B6E.dip0.t-ipconnect.de)
13:36:22 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net)
13:38:03 Quit Darksair ("Emacs = ESC-Meta-Alt-Ctrl-Shift")
13:44:34 Quit jhMikeS (Nick collision from services.)
13:44:40 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS)
13:50:57 Quit troy__ ()
13:53:47***Saving seen data "./dancer.seen"
13:56:59 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk)
14:00
14:09:23 Quit Lynx_ ("Konversation terminated!")
14:10:02 Join AndyI [0] (i=AndyI@212.14.205.32)
14:10:56 Quit mark726 (Remote closed the connection)
14:14:10 Quit Thundercloud (Remote closed the connection)
14:14:51 Quit daurnimator ("Cyas later...")
14:19:50 Join tyfoo [0] (n=tyfoo@dyndsl-095-033-110-209.ewe-ip-backbone.de)
14:23:26 Join kugel [0] (n=chatzill@unaffiliated/kugel)
14:23:57 Join daurnimator [0] (n=daurn@ppp118-208-145-18.lns10.mel4.internode.on.net)
14:24:27 Join daurn [0] (n=daurnima@unaffiliated/daurnimator)
14:28:33 Join miepchen^schla [0] (n=miepel@p579EC192.dip.t-dialin.net)
14:33:06 Join dotch [0] (n=opera@212.49.92.67)
14:34:27 Part pixelma
14:34:41 Join pixelma2 [0] (n=marianne@rockbox/staff/pixelma)
14:35:27 Part dotch
14:35:30bertrikI think I'll try to run a battery bench on my clip today
14:39:04 Join BigBambi_ [0] (n=Alex@rockbox/staff/BigBambi)
14:39:31 Quit BigBambi (Read error: 104 (Connection reset by peer))
14:40:39bertrikI'll just let the OF charge it, then boot rockbox, start the battery bench, turn the CPU frequency up and disable the idle poweroff
14:40:57 Quit miepchen^schlaf (Read error: 110 (Connection timed out))
14:41:03 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca)
14:41:09*amiconn wonders what this will be good for
14:41:45bertrikto get a discharge curve
14:42:45*amiconn wonders what's up with his c200 build :\
14:43:22amiconnIt shows the logo, then powers off
14:44:43bertrikr19206 works fine here on my c200
14:46:56 Join pinkstring_ [0] (n=pinkstri@ANancy-257-1-114-56.w90-40.abo.wanadoo.fr)
14:48:02 Join Darksair [0] (n=user@118.227.1.122)
14:48:04pinkstring_hello people, I have a question... Can I use Rockbox with Ipod Classic generation 6 ???
14:48:32BigBambi_no, as www.rockbox.org says
14:49:46 Join {phoenix} [0] (n=dirk@p54B46130.dip.t-dialin.net)
14:52:02pinkstring_BigBambi_, in the future, it will be possible??
14:52:19BigBambi_unlikely, but who knows
14:52:52BigBambi_encrypted firmware, plus new undocumented hardware, plus nobody working on it = not likely
14:53:29pinkstring_ok thanks you for help
14:53:36pinkstring_bye
14:53:41BigBambi_cheerio
14:53:57 Part pinkstring_ ("Quitte")
14:54:28 Join gabe565 [0] (n=chatzill@ip68-12-96-57.ok.ok.cox.net)
14:56:22 Quit sbhsu (Read error: 110 (Connection timed out))
14:56:48gevaertsamiconn: running at 60MHz gives more resets
14:59:34*gevaerts is confused now. Trying again seems to have changed the behaviour...
15:00
15:04:30 Quit tyfoo ("Carpe diem")
15:15:20 Join Nico_P [0] (n=nicolas@rob92-6-82-231-243-63.fbx.proxad.net)
15:16:51 Quit gabe565 ("ChatZilla 0.9.83 [Firefox 3.0.4/2008102920]")
15:19:07 Quit Horscht ("electromagnetic radiation from satellite debris")
15:20:16 Join __lifeless [0] (n=lifeless@89.20.119.53)
15:21:35 Join Horscht [0] (n=Horscht@xbmc/user/horscht)
15:26:25 Join tyfoo [0] (n=tyfoo@dyndsl-095-033-110-209.ewe-ip-backbone.de)
15:26:35 Join funman [0] (n=fun@AToulouse-158-1-73-52.w90-50.abo.wanadoo.fr)
15:30:09funmandomonoky: i read you made some progress on i2sout yesterday?
15:31:11domonokyfunman: yes, a little bit. we forgot the CGU_AUDIO (i2sout_mclock). Now my i2sout fifo fills and emptys with dma..
15:31:55domonokybut i still have no sound, and i detected another problem: pcm_play_dma_start requests bigger sizes then we can set in the dmac..
15:32:16funmanwe should split into smaller transfers, like for SD
15:32:47 Nick JdGordon is now known as JdGordon|zzz (n=jonno@rockbox/developer/JdGordon)
15:33:56domonokyfunman: or use the LLI feature of the dmac.
15:34:50funmanhow bigger is the requested size?
15:35:29 Quit _lifeless (Read error: 110 (Connection timed out))
15:35:33funmanI notice we can transfer a bit less than 32kB at once
15:36:29 Join crope` [0] (n=crope@dyn3-82-128-188-248.psoas.suomi.net)
15:36:38 Quit crope` (Client Quit)
15:37:33domonokywhat comes from the metronome, seem to fit into 2 dma tansfers. but i am not sure what the maximum is.
15:38:51funman0x7ff * dstwidth * dstsize
15:39:38domonokyfirst request from mentrome is 46080 bytes.
15:40:29funmanfifo pop error ..
15:41:25domonokyyou get a fifo pop error, when the fifo is run out of data. try put a panic into the dma_interrupt handler...
15:41:52domonokyyou will probably see, that the dma-terminal interrupt comes before the fifo pop-error.
15:42:45domonokyyou may also get a pop-error in the bigging of the transfer, when the m_clock is enabled, before we have written to the fifo.
15:49:35funmanfor me it seems the fifo is never filled
15:50:46funmanperhaps the lcd operation in the isr is too slow
15:51:48domonokyfunman: you could compare to my changes: http://pastebin.com/m419f43f9
15:52:29funmanhm i didn't modify the metronome
15:52:55domonokythat doesnt matter, as long as you are sure, pcm_play_dma_start is called..
15:53:50***Saving seen data "./dancer.seen"
15:59:12 Quit SUSaiyan ()
16:00
16:02:46domonokyhm, also without the CGU_AUDIO the fifo should fill-up till "fifo-halffull" or atleast "fifo_almost empty" but without the mclock it will stay there and give you many,many,many interrupts :-)
16:03:44funmanI wonder if we should manually start transfers at each i2sout interrupt on status fifo * empty
16:04:36domonokyfunman: you mean transfer data without the dma ?
16:04:59funmanno i meant with it
16:05:21funmanI don't understand how the DMAC knows about the status of i2sout's fifo
16:05:22domonokyah, setup a new transfer on fifo-empty ? could work..
16:05:49funmanbut if i understand well the fifo is 4 * 32 bits word
16:05:53funmanso no need to use dma :/
16:06:04domonokyfunman: the i2sout fifo requests dma-transfers via the dma_request line, when the fifo runs empty..
16:06:45funmanah ok
16:07:05funmani'll try transfers without dma so at least we know when i2sout / audio settings are ok ;)
16:08:11domonokyyes, manula transfers might be a good way to get this running. i think ipods also dont use dma.
16:09:03domonokyi also made a short attempt with manual transfers, but i could not get the fifo to fill up, while dma seemd to work for me.. (that was before i found the CGU_AUDIO thing).
16:09:23funmani did the same, let's try again with the i2so_mclk clock running
16:10:48domonokyi am also not sure, how fast we should set the is2_out m_clock, there is a mention of 30mhz max, and it might also have something todo with this oversampling setting..
16:11:15*funman looks again at OF
16:12:16bertrikpage 112 of the DS shows an mclk of about 5.6 MHz for 44100 kHz playback
16:12:24 Quit faemir (Remote closed the connection)
16:14:25domonokyso its running way to fast for me..
16:14:52funmanOF uses 5644800 Hz (not sure if it's variable yet)
16:15:05bertrikit's 128 times the desired sample rate
16:15:47funmanthat would be plla/68
16:15:55domonokyoki, so the oversampling in i2sout should be 128 and the m_clock set to 5,6Mhz (24mhz clock, divider 16)..
16:18:33*domonoky hears some ticking...
16:20:07domonokyits surely not the correct sound, but there is some ticking in the headphone !! :-)
16:24:50 Quit Darksair ("(define zero (lambda (f) (lambda (x) x)))")
16:26:33funmandomonoky: great ! I can't reproduce without DMA, I'll keep trying :)
16:37:12domonokythis patch: http://pastebin.com/m14b8a251 now gives me reliably one "tick" per play_tock() in metronome. I dont know how the metronome tock should sound, but it gives a pretty nice "tick" on my m200v4 !!
16:38:47funmandomonoky: look in the simulator for the reference tick
16:39:32domonokyor one of my other targets :-)
16:40:23 Join Bensawsome [0] (n=Bensawso@unaffiliated/bensawsome)
16:40:50kugeldoes metronome sound qualify for the gentlemen mail? I hope not :)
16:42:22 Quit moos (Read error: 110 (Connection timed out))
16:42:59funmandomonoky: i can hear the tick but it doesn't sound like in the simulator
16:43:14domonokyits not ready for the gentlemen mail... i hear either only the beginning of the tick on ams-sansa, or its just very low volume.
16:44:31funmanand by the way the diff to metronome is not needed (except the keymap of course)
16:44:40kugellinuxstb: ping
16:44:55funmandomonoky: does your m200 deadlock on shutting down like my clip ?
16:46:16domonokyfunman: i dont really know, it think i always get the hard-power off..
16:46:39kugellinuxstb: I thinke the "/* TODO: The OF calls some other functions here, but maybe not important */" isn't unimportant at all
16:46:40domonokybut i get spurious reboots sometimes, so there is still much todo :-)
16:46:58funmandomonoky: oh, i can see the 'shutting down' screen
16:47:02funmanyeah i get reboots as well ;)
16:48:01LloreanHow's the install process? Is it likely to be something that can go into RButil?
16:48:22domonokyah, now i also get the "shutting down" message.. it delicate timing on this button :-) (short press, long press, very long press, and very very long press ) :
16:49:00domonokyLlorean: a bit like on the hxx0 players.. patch a of firmware for the bootloader.. so no problem for rbutil.
16:49:01funmanperhaps the timing needs to be adjusted to be shorter
16:50:13bertrikhmm, I always get the shutting down text when powering off
16:51:41kugelsame
16:53:13*domonoky thinks he now need another test-plugin to test longer sounds... :-)
16:54:52LloreanThe wiki pages make it sound like the m200v4 Rockbox is less advanced than the m200v1-3
16:57:22LloreanDo we still not have a way to recover any but the e200v2? That would more or less make this our first brickable set of targets in quite some time.
16:57:50funmanno way, except using the safe mkamsboot :)
16:58:14LloreanI'm not sure I understand that sentence.
16:58:47funmanthere's no recovery mode, but mkamsboot is deemed safe enough to not need recovery
16:58:50domonokya failed flash would always brick those targets, it like with the hxx0 players. You can also brick them with a faild flashing..
16:59:52domonokybut the ams-sansas are even safer then the hxx0 players, as we have the criticall dual-boot code seperate, so we can even recover a bad bootloader.
17:00
17:00:13Lloreandomonoky: I didn't mean to suggest they were unsafe. Just brickable.
17:00:46domonokyand i just wanted to say, that iriver h1xx are even more brickable :-)
17:00:50funmanthe recovery mode for e200v2 isn't exactly user friendly, so they should all be considered brickable
17:01:28Lloreandomonoky: Do we checksum the bootloader file after it's copied to the device in RButil, or just after they're merged?
17:01:44funmanwe checksum the original firmware
17:01:58funmanoh sorry, i was talking about mkamsboot, not rbutil
17:02:09domonokyLlorean: before and after the merge for irivers, the copiing is not checked.
17:02:11Lloreanfunman: And mkamsboot doesn't copy it to the device anyway, does it?
17:02:30 Quit kachna|lappy ("Konversation terminated!")
17:02:31Lloreandomonoky: Maybe we should check after the copy too, just to be safe.
17:02:39domonokyonly if you point mkamsboot to the device :-)
17:02:45funmanno it doesn't, just generate a file to be copied
17:03:12domonokyLlorean: i think there is another checksum, checked by the OF before flashing, so a failed copy should be detected.
17:03:38Lloreandomonoky: On the H100?
17:03:58domonokyyes. it wont flash a invaild firmware...
17:04:01LloreanOkay.
17:04:05funmandomonoky: are we sure of the endianess to use for audio samples ?
17:04:12domonokyfunman: nope.
17:04:13LloreanAs long as they all have their own checksums, nevermind me.
17:05:32 Join kachna|lappy [0] (n=kachna@r4ax178.net.upc.cz)
17:06:12domonokyfunman: i also dont know if my DMA LLI code works, so we might also only hear the beginning of the metronome tock.
17:06:25 Quit jhMikeS (Nick collision from services.)
17:06:31 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS)
17:07:13funmanoh right
17:08:55*domonoky wants to find out why codecs dont run.. :-/
17:09:05funmansame :(
17:09:51 Join sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw)
17:11:54bertrikthe metronome tock on the clip doesn't sound so bad, it sounds a little brighter on my c200 though
17:15:19 Quit herrwaldo ("Konversation terminated!")
17:15:37bertrikI think I'm not hearing the complete tock, just part of it. Endianness may already be correct, because it would be more of a cracking sound if it wasn't IMO
17:16:38domonokybertrik: that might me be true, my LLI code for longer DMA transfers is very rough, and might not work correctly :-)
17:17:03 Quit n1s ()
17:18:19 Join herrwaldo [0] (n=waldo@ip-81-11-224-139.dsl.scarlet.be)
17:18:23*funman found 2 bugs already in lli
17:18:32*domonoky puts a panic into the start of mpa.c and detects that codecs are not started. maybe there are loading problems ?
17:18:51funmanthe size of the 1st transfer should be 0x7ff and only the last LLI should trigger terminal count interrupt
17:19:28 Quit einhirn (Read error: 104 (Connection reset by peer))
17:20:56funmanthe size of all LLIs is incorrect in fact
17:21:19domonokyups :-)
17:22:20 Quit {phoenix} (Remote closed the connection)
17:24:43funmanhm
17:24:56funmannwords = DMA_S4 != 4
17:25:52 Join m0f0x [0] (n=m0f0x@189-47-42-178.dsl.telesp.net.br)
17:28:21funmandomonoky: I'd prefer if we setup a new transfer each time the previous one has finished
17:28:39funmanrather than using LLIs I mean
17:29:55domonokyfunman: sure, why not.. i was just experimenting with it.
17:30:36funmani don't think we can block in pcm_play_dma_start() though, perhaps register a handler with dma_enable_channel() and call it from the INT_DMAC ?
17:33:15domonokyhm, correcting the nwords in the src calculation makes the "tick" vanish again...
17:33:33funmani noticed :/
17:33:43funmanat least that means the LLI setup worked ;)
17:33:47domonokyregistering a handler woudnt be bad i think..
17:33:50 Join {phoenix} [0] (n=dirk@p54B46130.dip.t-dialin.net)
17:34:02 Quit funman ("leaving")
17:35:26 Join tyfoo2 [0] (n=tyfoo@dyndsl-095-033-110-146.ewe-ip-backbone.de)
17:35:52 Join Schmogel [0] (n=Miranda@p3EE21E61.dip0.t-ipconnect.de)
17:36:46 Quit tyfoo2 (Client Quit)
17:37:13 Join tyfoo2 [0] (n=tyfoo@dyndsl-095-033-110-146.ewe-ip-backbone.de)
17:40:05kugelamiconn: quick arm question: what's done if ORR has only 2 operands?
17:41:26kugelI can only find orr <dest>, <op1>, <op2>, but in the disassembly of the of I find orr r0,r6
17:44:18 Quit HBK (Read error: 110 (Connection timed out))
17:44:22domonokyit probably writes back to the first operand..
17:45:00 Join BigBambi [0] (n=Alex@rockbox/staff/BigBambi)
17:45:09 Quit Schmogel (Read error: 104 (Connection reset by peer))
17:45:26 Join Schmogel [0] (n=Miranda@p3EE21E61.dip0.t-ipconnect.de)
17:45:33domonokyso its r0=r0|r6
17:45:39kugelI'd guess the 3rd operand is considered as 0, so r0 = r6
17:46:05kugeldomonoky: I can find examples where for such thing orr r0,r0,r6 is used
17:47:09 Quit Schmogel (Read error: 104 (Connection reset by peer))
17:48:28kugeldomonoky: but maybe you're right, since it's thumb code
17:48:41 Join pondlife [50] (n=Steve@rockbox/developer/pondlife)
17:49:21kugeldomonoky: yep, you're right. In thumb code it only has 2 operands
17:49:46domonoky:-)
17:50:01 Quit tyfoo (Success)
17:52:53 Join toffe82 [0] (n=chatzill@adsl-76-240-237-5.dsl.frs2ca.sbcglobal.net)
17:53:54***Saving seen data "./dancer.seen"
17:58:20 Quit pondlife ("Leaving.")
17:58:40 Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net)
17:59:47 Quit XavierGr ()
18:00
18:04:41 Quit stripwax (Read error: 104 (Connection reset by peer))
18:07:07 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk)
18:10:07 Join funman [0] (n=fun@AToulouse-158-1-73-52.w90-50.abo.wanadoo.fr)
18:14:43 Quit JdGordon|zzz (Read error: 54 (Connection reset by peer))
18:16:12 Join JdGordon|zzz [0] (n=jonno@rockbox/developer/JdGordon)
18:20:01 Join karashata [0] (n=karashat@69.41.192.215)
18:25:30 Join dalgarath [0] (n=karashat@69.41.192.215)
18:25:36 Quit dalgarath (Read error: 104 (Connection reset by peer))
18:28:10 Join Rondom [0] (n=Rondom@dslb-084-057-177-101.pools.arcor-ip.net)
18:28:16 Quit Rondom (Read error: 104 (Connection reset by peer))
18:38:45 Quit stripwax (Read error: 104 (Connection reset by peer))
18:40:18funmandomonoky: how did you put a panic in mpa.c ? lcd_puts+while(1) ?
18:40:50domonokyfunman: i added panicf to the codec api (apps/codecs.c/h ) :-)
18:41:02funmanok ^^
18:41:12domonokythe i can use ci->panicf in codecs... but they never get loaded at moment...
18:41:36funmanI have setup the dma callback but I hear an horrible sound instead of the nice tick
18:41:43funmanI want to use longer pcms
18:42:58 Quit Nico_P (Remote closed the connection)
18:43:14domonokyat least we hear any sound :-) i am now debuuging why codecs dont load... (with lots of panics) :-)
18:44:55funmanperhaps test_codec is a good way to debug
18:47:01funmanhmm test_codec reboots the clip ..
18:47:19*domonoky gets a panic "Buffer is full for now" in audio_load_track, playback.c so we surly have problems with our 2Mb ram..
18:47:39funmanI thought it would adapt to small buffers
18:47:49funmanI'll check the linker script
18:48:24domonokyyes, the buffering should adapt to smaller mem-sizes.. but it may have problems if it gets too low.
18:49:17 Join DerDome [0] (n=DerDome@dslb-082-083-242-085.pools.arcor-ip.net)
18:53:20 Quit karashata ("G'bye everyone!")
18:56:17 Join karashata [0] (n=karashat@69.41.192.215)
18:56:20funmanis the codec loaded into the audio buffeR?
18:56:49funmanI think the buffer are badly defined
18:58:40domonokycodecs have their own buffer, like plugins. but i think the buffering system pre-loads them into the audio-buffer, and copy the codec into to the codec buffer at start of playback, but i am not sure..
18:59:24funmantest_codec gives me reboots, undefined instructions; so I think its code is being overwritten
19:00
19:07:24kugelfunman, domonoky: Try to apply if you run out of memory http://www.rockbox.org/tracker/task/9332?string=&project=1&type[0]=&sev[0]=&pri[0]=&due[0]=&reported[0]=&cat[0]=&status[0]=open&percent[0]=&opened=nicolas_p&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=
19:08:09funmandomonoky: it's right .. in test_codec test_track() audiobuf points to 0x3014E994, inside plugin buffer
19:08:09 Join Schmogel [0] (n=Miranda@p3EE21E61.dip0.t-ipconnect.de)
19:08:56funmankugel: thanks, bookmarking ^^
19:09:17kugelthat disables buffering alltogether, and reads data from flash directly
19:09:55funmancodecs load at 1MB , plugins at 1.5MB
19:10:26domonokywaring this patch is outdated.. :-)
19:11:33kugelfunman, domonoky: I have tested this patch, it definitely works on my e200
19:12:01 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk)
19:14:13domonokykugel: it may work, but its outdated and needs manual fixing..
19:14:57funmanI think test_codec is not adapted to work on lowmem targets
19:15:57funmandomonoky: can you point me to where codecs are loaded into memory ?
19:16:10kugeldomonoky: you tried to apply? Ony sources could fail, easy fix
19:16:40domonokykugel: yes, i tried, and there is no more EVENT_HANDLE_FINISHED, i can not find it in the sources..
19:16:58kugelah, then ask Nico_P :P
19:17:36domonokyfunman: you mean the memory position, or the code which loads them ?
19:18:01funmancode which loads them (the position is defined in the app.lds linker script)
19:18:31domonokyi tracked codec/audio loading to playback.c audio_load_track(), where the bufopen() (from buffering.c ) fails..
19:19:51domonokyplayback.c ~line 1698 has the failing bufopen() call. next step would be to trace why this fails, in buffering.c
19:26:30 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net)
19:32:52 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net)
19:35:07 Quit JdGordon|zzz (Remote closed the connection)
19:35:32 Join JdGordon|zzz [0] (n=jonno@rockbox/developer/JdGordon)
19:36:40 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr)
19:38:26 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey)
19:50:53*gevaerts had usb resets while talking to EDM
19:53:55***Saving seen data "./dancer.seen"
20:00
20:07:16 Join funman_ [0] (n=fun@AToulouse-158-1-73-52.w90-50.abo.wanadoo.fr)
20:07:38 Quit funman (Nick collision from services.)
20:07:40 Nick funman_ is now known as funman (n=fun@AToulouse-158-1-73-52.w90-50.abo.wanadoo.fr)
20:11:12 Quit XavierGr ()
20:11:36 Quit JdGordon|zzz (Remote closed the connection)
20:12:12 Join JdGordon|zzz [0] (n=jonno@rockbox/developer/JdGordon)
20:13:21kugelfunman: svn bootloader is broken?
20:13:50funmankugel: I am running r19240 as bootloader
20:14:25kugelfunman: so?
20:14:34funmanso r19240 is not broken
20:14:41 Quit tyfoo2 (No route to host)
20:14:44kugelif the bootloader is considered finished, it shouldn't be broken
20:14:59funmanis it ?
20:15:02funman(broken)
20:15:12kugelyes
20:15:43 Join MethoS [0] (n=clemens@host-091-097-242-082.ewe-ip-backbone.de)
20:15:47funmanwhich revision?
20:16:09kugellatest ;;
20:16:25funmanthen bissect to find last revision which worked
20:16:36 Quit kachna|lappy (Read error: 104 (Connection reset by peer))
20:16:40 Join MrDuck [0] (n=kachna@r4ax178.net.upc.cz)
20:17:05 Quit toffe82 (Read error: 110 (Connection timed out))
20:17:11domonokykugel: and what means broken ? what happens ?
20:17:49funmanlast (r19262) works fine for me
20:17:56kugelit starts with a white screen
20:18:25funmanperhaps change of pclk broke it, did you try reverting that change ? (I remember discussing that with you already)
20:20:11funmanand by the way this is a problem in the lcd driver, not in the bootloader (which functions is to load and boot)
20:22:32 Quit BlakeJohnson86 ("Leaving.")
20:22:56kugelfunman: I don't understand why you wait until such changes are tested on other ams sansas
20:23:13funmandomonoky: "Not enough space for required allocations" in buffering.c
20:23:46funmankugel: i believed the same hardware requires the same conditions, didn't think about different lcd controllers
20:24:41kugeland you don't intend to revert, I guess? Since you don't care about targets you don't own?
20:25:04funmanfor sure i will not revert anything if you don't tell me that reverting this change fix your problem
20:25:46funmannot working on specific code for other models doesn't mean i want to break them
20:25:51domonokyfunman: yes, i also found this, but i dont really understand what this means... the requested data_size is only 1224 bytes, which surely should fit into our 214k buffer...
20:25:59funmanand insulting me will not help
20:26:27kugelI didn't insult
20:26:37kugeljust asked
20:26:44domonokykugel: please stay friendly, funman is doing great work... we can not make sure we dont break other new targets we dont own...
20:26:46funmanThat's how I understood it
20:26:52kugelthen I'm sorry
20:27:07*funman gives a peaceful hand to kugel
20:27:23kugeldomonoky: sure he's doing great work. This wouldn't be possible at all without him.
20:27:49domonokythe only way is, that owners of the other ams-sanas tell us, when we break somehing.. then we can try and fix... :-)
20:28:07kugelbut I still think, since the port is about a variety of targets at once, commits should be tested more
20:28:50*kugel handshakes with funman
20:28:56*domonoky doesnt agree... all this ams-sansa ports are in a very early state.. so it doesnt matter if they break sometimes, if we get important new features..
20:29:55kugelfunman: indeed, reverting to r19234 helped
20:29:56funmankugel: so let's go back on topic, if you add CGU_PERI |= (5<<2)|0x01; /* pclk = PLLA / 6 = 64 MHz */ after sdram_init() in system-as3525.c (r19234) , does it fix your white screen problem?
20:30:16funmanplease use latest revision with only this change, set_cpufrequency() shouldn't harm
20:30:35kugelfunman: I only reverted system-as3525.c
20:32:05 Quit JdGordon|zzz (Remote closed the connection)
20:32:10funmanyes, but there is 2 diffs in this commit
20:32:30 Join JdGordon|zzz [0] (n=jonno@rockbox/developer/JdGordon)
20:33:35kugelfunman: yea. the other is guarded with #ifndef BOOTLOADER though ;)
20:33:42funmanah right
20:34:08funmanso, can you check the lowest pclk frequency you can use ? (this commit was intended to reduce power consumption)
20:34:21domonoky /me suspects it timings in the fuze-lcd code. so the right fix would be, to make them frquency independent..
20:34:50funman5<<2 is the plla (|0x01) divider - 1, so 384/(5+1) == 64; and now we use 24
20:35:06funmanbut of course it's better if you lower the delays in fuze driver
20:35:26kugeldomonoky: there's a simple lcd_delay function. If it's clocked lower, you mean I should lower the delay as well?
20:35:39kugellet me try. The delay is too high anyway
20:36:21domonokykugel: yes, some experiments would be good. or else it will break again at the next frequency change :-)
20:37:34 Join EspeonEefi [0] (i=eefi@SYDNEYPACIFIC-SEVEN-O-ONE.MIT.EDU)
20:38:16kugelI think there's a dbop clock, I think I'll have a look at that
20:38:33domonokyis someone with knowlegde about rockboxs buffering code here ??
20:39:01funmanI thought about something else by the way
20:39:12funmanwe should disable dma/sd/dbop/gpio clocks when we don't use them
20:39:31funmanfor dma we should write 2 functions to inc/dec rease a reference count since there is 2 channels
20:40:17 Join gromit`` [0] (n=gromit@ALagny-154-1-67-109.w86-203.abo.wanadoo.fr)
20:40:43kugeldivision ratio => div = 1/(dbop_prediv_sel + 1)
20:40:59kugelas of now it's 1/3
20:41:01domonokyyes, disabling not used units would probably save a good bit of battery.. but that also can come later.
20:41:48domonokykugel: if changing the delay, doesnt help. you could also experiment with CGU_DBOP to see if this helps..
20:41:57funmankugel: you can set the clock source also, i guess now it's pclk, try lowering the divider to 1/2 ?
20:43:04kugellowering? Doesn't that mean it'll clock higher?
20:43:27funmanyes.
20:43:29 Join MethoS- [0] (n=clemens@host-091-096-213-140.ewe-ip-backbone.de)
20:43:33domonokykugel: yes, but you have problems when we lower the main clock, so thats intended..
20:43:35funmanyour problem is that pclk was 64MHz and now is 24MHz
20:44:00funman64/3 == 21, 24/3 == 8MHz , so you want to higher from 8 to 21 until you got lcd display
20:46:07kugelerr
20:46:15kugelit's 1/(3+1) as of now
20:46:40funmanso, 16. try 24/(1+1) = 12
20:47:03kugel1/1+1 worked
20:47:26funmanand /(2+1) ? (lower clock == more battery)
20:47:28kugeloops, 1/2+1 I mean
20:47:48kugel(I thought I tried 1, but I did in fact use 2)
20:47:57domonokyand does 1/2+1 also work at 64Mhz ?
20:48:15funmanno, the reference clock is 24MHz, so 1/(2+1) => 8MHz
20:48:30funmanoh sorry.. I didn't understand what you meant
20:48:54funmanbut I think we don't need to use an higher freq for pclk, only touch the cpu clock (fclk)
20:49:09 Quit gromit` (Read error: 110 (Connection timed out))
20:49:13domonokyit would be good to find a setting which works on wide range of cpu frequencys, remember we want the boost feature later :-)
20:49:14amiconnkugel: ARM mode ORR always has 3 operands. If you see a 2 operand form, it's thumb code
20:49:35kugelamiconn: yea, we already found that out :)
20:49:44domonokyah, pclock is seperate from the cpu clock of course...
20:51:02funmankugel: thanks for fixing this fuze-specific bug in fuze-specific code </sarcasm>
20:51:43kugelfunman: Don't call to early. I'm having problems in the main now
20:52:07funmanthe same problems, or the kind you have while messing with button code?
20:52:19kugelother problems
20:52:32kugellcd_update is VERY slow and it doesn't get to the main build
20:52:52kugelI already lowered the delay in lcd_delay from (x*1024) to (x*64)
20:53:05funmantry with other peripheral clock dividers then
20:53:09kugelmain menu I mean
20:53:28funmanif it doesn't work you can use the plla as a reference clock, with higher dividers though since it's at 384MHz and not 24MHz like the peripheral clock
20:55:23kugelfunman: 1/1 isn't enough
20:55:42kugellcd_update still noticeably slow, and I still don't get to the main menu
20:55:57funmanthen use plla source (|0x1 instead of |0x0)
20:56:58kugelfunman: ?
20:57:40funmanah you can't set the clock source for cgu_dbop sorry ..
20:57:47kugelyea
20:58:11funmantry highering pclk then
20:58:50funmanby the way, is 1/1 = 1/(0+1) aka bits 2:0 set to 0 ?
20:59:16funmanbecause that would be clk_dbop == 24MHz instead of the previously (working) 16MHz
21:00
21:00:13 Quit MethoS (Read error: 113 (No route to host))
21:01:05kugelf(clk_dbop) = f(PCLKDBOP) * div;
21:01:34funmansure, but "div = 1/(dbop_prediv_sel +1)"
21:01:37 Quit karashata ("G'bye everyone!")
21:02:03kugelhow much is PCLKDBOP?
21:02:09funmanPCLK i suppose
21:02:33funman24MHz now, 64MHz last time you had display working in svn
21:04:30funmandomonoky: buffer_len == -367520 doesn't sound right to me
21:04:57 Join petur [50] (n=petur@rockbox/developer/petur)
21:05:21 Join stoffel_ [0] (n=sfr@p57B4F145.dip.t-dialin.net)
21:06:59domonokyhm, that doesnt look good, a negativ buffer cant hold much data :-)
21:07:02funmanwith panicf() I see a call to buffering_reset(?, -367552)
21:08:44*funman wants a backtrace :(
21:09:29funmanby the way while walking I thought about how to debug the spurious resets: replace the reset vector by a func which dumps the whole RAM to disk
21:09:41domonokywhich comes from playback.c audio_reset_buffer()..
21:09:43funmanand prints the stack pointer, so we can debug offline
21:10:18domonokyfunman: sounds like a good debugging method..
21:10:21funmanpcmbuf_init() is called with a pointer to 0x30100000 (1MB of SDRAM) so that part looks correct
21:13:28domonokyhm, before the call to pcmbuf_init the filebuflen is still our ~216k. It seems like pcmbuf_init wants 512k ? as afterwards we have -367k
21:15:38 Join Self-Perfection [0] (n=self@95-24-27-158.broadband.corbina.ru)
21:15:42bertrikwill we be able to fit everything in 2 MB +300k at all? maybe we need some of the rockbox veterans for advice
21:16:44bertrik(thinking of the clip)
21:17:02funmanbertrik: yeah, the clip is the most important, who cares about m200 ? :)
21:17:16domonoky:-)
21:17:31funmannote, if the c200 is monochrome, it may have the same amount of RAM
21:18:08bertrikdomonoky, if we can fit it in the clip, the other ams sansa's should be no problem
21:18:30 Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-012f9b3aba29932d)
21:18:40saratogai saw comments about memory usage
21:18:49domonokyand if i can fit it into the m200v4s memory, also the other targets wont be a problem :-)
21:18:51saratogaif you think you need more, you should shrink the codec buffer to 512KB
21:19:06funmanit's already 512KB
21:19:27saratogaoh didn't realize it was already halved
21:19:29funmanatm there is 512KB for codecs, 512KB for plugins, ~625KB for rockbox binary
21:19:44saratogayou could probably shrink both it and the plugin buffers quite a lot as well without breaking much
21:20:20saratogahave you enabled IRAM as well?
21:20:21gevaertsIf you suspect that RAM is the blocker to get sound to work, I'd reduce either codec or plugin buffer to near-zero, depending on whether you use plugin sound or playback to test things
21:20:28bertrikfunman, does the 625 KB already include the code + variables + stacks?
21:20:41gevaertsOnce everything works you can increase them again
21:20:42saratogai bet MP3 works with 128KB buffer + IRAM
21:20:47funmanIRAM is used but only for icode/idata etc segments
21:20:49domonokyhm, pcm_buf init returns that it needs 545k + 32k guard buffers.. :-/
21:21:08funmanshouldn't a check go here?
21:21:16kugelfunman: Why don't you try to fix the flash buffering patch?
21:21:18domonokyso we surely have the RAM problem :-)
21:21:21funmanI think yes (since it's an init function it's not time critical)
21:21:29funmankugel: because i don't know the code
21:21:42kugelhm, sounds reasonable
21:21:43saratogakugel: I don't think trying that patch makes much sense now
21:22:06saratogaa port should be working well before you go and change the playback code
21:22:08gevaertsThat's buffering. This is pcm_*. I would expect those to be unrelated
21:22:09kugelsaratoga: they're running out of memory while buffering. That patch disables buffering
21:22:36saratogai know what it does but changing buffering will be a nightmare and its not something you're going to have much luck trouble shooting while drivers are incomplete
21:22:42domonokykugel: not really true. we already run out of mem at startup. as i found out now :-)
21:22:45*gevaerts would just reduce the plugin buffer to 64k or so for now
21:22:51saratogaand anyway 2MB of RAM is enough for the current system
21:23:09kugelif plugin buffer is futher reduced yes
21:23:15kugellike the other 2MB targets do
21:23:23domonokyif we really need ~512k only for the pcm buffers we get problems... :-)
21:23:54gevaertsOf course, but do you want to fix that without a working reference?
21:24:14funmanwhat do you think of http://paste.ubuntu.com/78129/ ?
21:24:23*domonoky tries to reduce the plugin buffer...
21:24:43kugelfunman: Am I correct? That clock change commit was only for the bootloader?
21:25:08funmankugel: only the bootloader sets it, the main binary doesn't change it
21:25:24*gevaerts likes the "insert meaningful message" :)
21:25:25domonokyfunman: :-) would be a good check for svn... programmers never check memory allocations. :-)
21:25:25kugelok, I thought both do
21:26:26saratogawhile I'm here, is anyone that familar with the DBOP control registers?
21:26:29funmanI'll try with 256kb plugin & buffer (512kb more for pcm)
21:26:33*bertrik wouldn't mind more assertion checks in rockbox
21:26:38funman*plugin & codec buffer
21:27:04funmangevaerts: well I'm not sure what are the allocations made here, so I guess someone should "insert a meaningful message" ;)
21:28:15funmanhum I still get a panic .. let's make clean to be sure the new config has been used
21:28:23gevaertsfunman: "Not enough memory for pcmbuf_init()" ?
21:28:50saratogain particular, this line in fuze-lcd.c doesn't make sense to me: http://paste.ubuntu.com/78130/
21:28:54 Quit Thundercloud (Remote closed the connection)
21:28:55*bertrik checks the map file
21:29:08saratogasince the datasheet says write enable is pin 16, but the code sets pin 14
21:29:08kugelfunman: CGU_PERI |= (15<<2)|0x1; /* pclk = PLLA / 6 = 64 MHz works
21:29:10domonokyeven better: "Not enough memory for pcmbuf_init() %x %x", requested_size,buffer_size)
21:29:55funmankugel: 384/(15+1) = 24, .. something is definitely wrong here
21:29:56gevaertsI'd write that as "Not enough memory for pcmbuf_init() %x>%x"
21:30:16kugelsaratoga: yea, I stumbled up that too. And I did what the data sheet says, and it did not work
21:30:40kugelsaratoga: also, the lcd-driver is purely based on disassembly. So I assume it's what the of does
21:30:43bertrikthe DRAM segment is only 1MB in the map file, is that correct?
21:31:09funmanbertrik: minus plugin & codec buffers, right
21:31:30kugelfunman: the difference is that PCLK_SEL is set
21:31:41Unhelpfulamiconn: for the mono targets, unless i find something that should be ifdef'd away and isn't, it looks like they will need to use the old bmp reader to avoid having a binsize change. would it be more acceptable to retain that reader in a bmp-mono.c, or to have two versions of bmp_read_fd in bmp.c, selected via ifdef?
21:31:43kugelwhen I removed that, I had problems
21:31:51funmankugel: I don't understand what you mean
21:32:24kugelfunman: the |0x1; part sets PCLK_SEL to plla_fout
21:32:27saratogakugel: well that might expalin why my attempts to use the DBOP write enable crashed the sansa
21:32:42 Join midkay [0] (n=midkay@rockbox/developer/midkay)
21:33:06funmankugel: please calculate what is the resulting pclk frequency with your diff
21:33:10kugelsaratoga: maybe the comment is just missleading
21:33:33bertrikaudiobuf starts at about 0x9c000 and ends at 0x100000 into the SDRAM, so thats about 400k. The codec buffer starts at 0x100000 and the plugin buffer starts at 0x180000
21:33:41kugelfunman: you just did?
21:33:58kugel" 384/(15+1) = 24"
21:34:09funmankugel: i just did and it's exactly the same frequency used in svn now. So I may be wrong in my calculus
21:35:00kugelfunman: I already told you. SVN doesn't alter PCLK_SEL to plla_fout, but leaves it as clk_main
21:35:14kugelp107, last row in the data sheet
21:35:32funmankugel: sure, clk_main == 24MHz, so PCLK == 24MHz in svn
21:35:40funmansame frequency than with your diff
21:35:58kugelno idea then. It just works
21:38:13 Quit Zarggg ()
21:38:14kugelsaratoga: are you a bit disassembly skilled? I have disassembled the OF a bit. It does much more in dbop_init
21:38:38kugelsaratoga: the lcd driver is very quirky so we probably miss something important
21:40:18 Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net)
21:40:39 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr)
21:41:31kugelfunman: CGU_PERI |= 0x1 rendered my fuze unbootable
21:42:23funmanof course, and feel lucky you if didn't brick it
21:42:35funmandatasheet mention not using pclk higher than 65MHz
21:42:57kugelfunman: it's working
21:43:05funmanthen feel lucky :)
21:43:14 Nick Bensawsome is now known as NinJew (n=Bensawso@unaffiliated/bensawsome)
21:44:01kugelfunman: CGU_PERI |= (15<<2); does neither work. it shows the bootlogo, but then I get checksum error
21:44:26 Quit MethoS- (Remote closed the connection)
21:44:32 Nick NinJew is now known as Bensawsome (n=Bensawso@unaffiliated/bensawsome)
21:44:43kugeland the time it needs until then is rather long
21:47:00domonokykugel: what do you want to enable with this CGU_PERI thing ?
21:47:26kugel!?
21:48:02domonokyah i missed the pclock devider..
21:48:08kugelnot enabling doesn't work for some reason, no matter which dbop clock / delay I take
21:50:15 Join RichterSkala^wl [0] (n=para@e178021030.adsl.alicedsl.de)
21:50:15 Quit RichterSkala (Read error: 104 (Connection reset by peer))
21:50:35 Quit RichterSkala^wl (Client Quit)
21:51:42funmanI have put a 256kb codec buffer into IRAM, and reduced a bit the plugin buffer, so now I have a bit more than 1MB for audio buffer
21:51:51funmanand the Clip resets as soon as I open a track
21:52:12 Join your [0] (n=4b082200@gateway/web/cgi-irc/labb.contactor.se/x-dcb85f300127f253)
21:52:18yoursup ladies???
21:52:32yourhu
21:52:51 Quit your (Client Quit)
21:53:37kugelfunman: http://pastebin.ca/1270530
21:53:59***Saving seen data "./dancer.seen"
21:54:21*domonoky gets the same as funman...
21:54:27 Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com)
21:54:31funmankugel: why don't you use no divider in as3525_dbop_init() ?
21:54:39kugelhttp://pastebin.ca/1270531
21:54:55kugelfunman: I do. 1/1+1
21:55:05funmanWhat about 1/1+0 ?
21:55:44kugelfunman: should work too
21:56:10funmanI mean use pclk (/(1+0)) and a lower pclk
21:56:37 Join davie_420 [0] (n=davie@cpe-98-150-48-47.bak.res.rr.com)
21:57:50kugelfunman: lower pclk? 1/16 is lowest
21:58:05funmananyway, please open a FS entry with all the settings you tried
22:00
22:00:04kugelfunman: lowering dbop more isn't good (I have tried), the lcd_update gets noticeable
22:00:34funmanwrite that into the FS entry
22:04:04kugelfunman: http://www.rockbox.org/tracker/task/9588
22:07:35domonokyfunman: the reboot seems to happen in codec_load_file() (apps/codecs.c) between the codec_get_full_path and the read call...
22:08:41kugelfunman: haha! That happens if you have a "bl-fix-fuze.diff" and "fuze-fix-bl.diff" in the same dir
22:09:25funmandomonoky: does open() succeed?
22:09:33kugeldomonoky: maybe 256KB is too low?
22:09:34domonokytesting now..
22:10:17domonokyi have set my plugin buffer to 128 and let the codec buffer be 512k... -> ~32k buffer left after pcm_init
22:10:31kugelhm
22:10:55amiconnA codec buffer of 128KB should be enough for a number of codecs
22:11:17amiconnThat's what tomal used in the iFP port, and iirc it played at least mp3 and vorbis
22:11:51*amiconn thinks the 320KB IRAM would probably make a nice codec ram area
22:11:54domonokyit seems the reboot happens in the open call..
22:12:04gevaertsDoesn't that change a bit with the codec buffer/malloc buffer merge, or am I totally wrong?
22:12:33 Quit XavierGr ()
22:12:47funmandomonoky: http://paste.ubuntu.com/78144/ to put the codec buffer into iram
22:12:59saratogakugel: have you annotated your fuze disassembly at all?
22:13:10saratogaI can take a look at teh function in question
22:13:17amiconnUnhelpful: It'd probably be better to keep them in separate files. What loader would be used for mono remotes on non-mono targets?
22:13:22kugelsaratoga: yea, want to have it?
22:13:39kugelsaratoga: I have also linuxstb's, I'll just give you both.
22:14:02amiconngevaerts: Perhaps, but then only for codecs which use malloc
22:14:11Unhelpfulamiconn: the "new" one, i'd think. it can handle mono, it's just that the chunk loading seems to make it a bit bigger
22:14:36amiconnDoes it do scaling for mono output? Dithering?
22:15:00funmanit seems rb->sleep() in test_codec sleeps forever
22:15:20amiconnPerhaps we shouldn't say mono == no scaling etc, but rather differentiate by ram amount
22:16:45Unhelpfulamiconn: it does, but it can be switched to a direct-output case inside bmp.c. i've thought about trying that, to see if the code size is smaller than adding a mono case inside scale_nearest, but since my changes got akio's attention, he's finding lots of bugs for me to fix.
22:17:50funmanhow can sleep(int ticks) mesure elapsed ticks if interrupts are disabled ?
22:18:26amiconnIt can't
22:18:36amiconnInterrupt must not be disabled for extended times
22:18:43amiconn*Interrupts
22:19:16funmansleep_thread(ticks) is called with interrupts disabled; and i don't feel like reading the whole thread api to figure how it sleeps
22:20:03 Join ibseo [0] (n=hd@p5B162231.dip0.t-ipconnect.de)
22:20:16 Quit stoffel_ (Read error: 113 (No route to host))
22:21:39kugelfunman: comment added
22:23:26funmankugel: same
22:27:07 Quit BlakeJohnson86 (Remote closed the connection)
22:27:28*domonoky thinks this reboot thing has something todo with our sd-driver...
22:27:55*funman blames who ever wrote this driver
22:28:32kugelfunman: zing
22:29:58 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com)
22:30:15domonokymaybe its caused by that this open doesnt come from the main thread.. *speculating*
22:30:47funmanthis may have to do with the threading code I copy-pasted without understanding it
22:31:06 Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net)
22:31:29domonokyyou mean the wake_up thing ?
22:31:45funmannope, I understood this part ;)
22:31:58funmanI meant sd_thread()
22:32:16kugelfunman: I tried various DBOP clock divider without modifying CGU_PERI. all resulted in unacceptable slowness.
22:32:50kugelPlus: I didn't get into the main menu most of the times, e.g. it looped at the (main builds) bootlogo
22:33:11funmankugel: please write that on the patch entry, with the list of frequencies you tried
22:33:37funmanand if you didn't get to the main menu, write the result for each frequency you tried
22:34:07funmanso at least we can figure which range of frequencies bring which result
22:34:38funmanin short: put all the info you have
22:34:55domonokyfunman: doesnt look like its related to the sd-thread. i let the thread terminate, and still get the reboots.
22:35:05 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr)
22:35:12kugelfunman: did. I listed all clock divider I tried
22:35:23domonokybut also those occasional reboots we get before, seemed to be related to sd-access.
22:35:42kugelfunman: *all* divider I tried failed
22:35:45funmando you know in which occasions the CPU can call the reset vector ?
22:35:57bertrikare we sure the thread isn't running out of stack space?
22:35:59kugelincluding the fastest
22:36:09domonokynope, i will check the data sheet :-)
22:37:44domonokydoes the watchdog run ?
22:39:48funmanno
22:39:55funmanbertrik: how can we be sure?
22:40:45kugelfunman: I answered
22:41:56bertrikfunman, it's indeed hard to be sure. If the problem goes away after using plenty of stack for that thread, it could be stack problems. We can also check stack usage in the debug menu.
22:43:35 Quit davie_420 ()
22:44:07funmanfor sleep(), switch_thread() will enable the interrupts again. The fact that sleep() never comes back must mean that another thread is not giving back the hand
22:44:31bertrikThe clip currently maps YES to the play button (for example in deletion confirmation). Wouldn't it make more sense to use the select button?
22:44:44funmanI think so
22:44:55kugelfunman: Are you tired? I don't know how often I need to say that even the fastest devider is unacceptable slow without modifying CGU_PERI
22:45:18amiconnhmpf!
22:45:24kugelAlso, 1/(15+1) is the lowest divider you can get for pclk
22:45:30funmankugel: you're not very clear.
22:45:34*amiconn doesn't understand why his own c200 build doesn't werk
22:45:43funmanI don't know what "modifying CGU_PERI" means for instance
22:46:07amiconnThe latest current build is working fine...
22:46:10funmanIf you said "setting pclk to X MHz" it'd be much more understandable
22:46:13kugelfunman: you used that phrase yourself: "without modifying CGU_PERI "
22:46:36bertrikamiconn, maybe run configure and make clean again
22:46:39funman"_without_ modifying" means "use current setting"
22:46:48amiconnI already did that 2 times...
22:46:52funmanhm I read with instead of without
22:46:56kugelyou said "without modifying CGU_PERI" first, and I throught it refers to past-r19234
22:46:58amiconnAll other builds work, just c200 doesn't
22:47:44funmankugel: well I read "without CGU_PERI" in the FS entry, did you mean "without modifying CGU_PERI" ?
22:48:03*domonoky made the codec sack much bigger. now it shuts off instead of reboot :-/
22:48:08kugelfunman: yes
22:48:28funmanand in my last comment I meant you to use the CGU_PERI setting of r19234
22:48:45 Quit robin0800 (Remote closed the connection)
22:49:01funmanto sum it up, I want a table of pclk frequencies and dbop clock frequencies, associated with the state of the lcd driver
22:49:17kugelfunman: that's with having the CGU_PERI line removed, isn't it?
22:49:49funmanno ..
22:49:55kugelfunman: then you mean r19233 I guess?
22:50:11funmanyes
22:50:12kugelsince r19234 removed that line
22:50:16 Quit Acksaw (Read error: 104 (Connection reset by peer))
22:50:39 Join Acksaw [0] (n=omgwtfbb@cpc2-stok5-0-0-cust754.bagu.cable.ntl.com)
22:51:09kugelfunman: One question though: Why testing all that stuff? We cannot get lower pclk
22:51:31funmanto understand what we change
22:51:56funmanand not blindly commit the first line which 'just works'
22:52:54funmanwe are obviously wrong somewhere since using a 24MHz pclk sourced from the crystal and using a 24MHz pclk sourced from the PLLA, and divided; have different results
22:53:51funmanperhaps the PLLA setting is wrong, like what I saw in the OF suggested
22:54:04kugelfunman: haha not again you mean? :)
22:54:12funmanwhat again?
22:54:40kugelnevermind
22:55:13bertrikfunman, maybe it has to do with the cpu/apb synchronisation setting
22:55:36funmanin the OF they use an array of a couple { frequency, cgu_plla register value }, and the value associated to 384MHz showed a setting of 96MHz
22:56:06funmanbertrik: you mean asynchronous clock setting in cp15 config register?
22:56:38 Quit saratoga ("CGI:IRC (EOF)")
22:56:41bertrikyes
23:00
23:04:09kugelfunman: comment added
23:06:14funmanin the list of cgu_pll* settings, I notice all the values are 4 times higher than the setting, except 2 which are 2 times higher
23:06:14kugelI think my findings make sense
23:06:52*funman will check his pll calculation algorithm
23:06:53*domonoky confirms that threading itself isnt the reboot-problem, i can successfully open a file in a thread created in a plugin...
23:08:06funmandomonoky: of course since high scores reading/writing in games works
23:08:29funmanperhaps the hardware itself causes the reset?
23:08:58domonokyfunman: normal plugins dont use threads, and run in the main-thread...
23:09:04funmanah ok
23:11:01funmandamned
23:11:21funmanthe datasheet uses a different bit order : OD0=x OD1=y
23:13:12funmanstill, I get a value 2 times lower than what the OF lists
23:13:27funman(now it's consistent for all the values listed at least)
23:14:05kugelfunman: different bit order? endianess?
23:14:59funmanendianess is about byte order
23:15:17kugelyea, and 8bits are 1byte :P
23:15:18funmanthey just use a not logical bit order to display the information
23:15:28funmanand I read too quickly without noticing this
23:15:47kugelgood you noticed now I suppose
23:18:08funmannow that I fixed another bug in my code, the settings I find in the OF are correct
23:18:41funmanThese 2 bugs cancelled each other, and the plla frequency remains correct (384MHz)
23:19:15funmanBUT the setting is incorrect according to the datasheet (fvco > 400MHz)
23:23:04kugelfunman: what to do about the CGU_PERI line?
23:23:11kugel(just read your answer)
23:23:52funmanmodify it, note results
23:23:58 Quit BigBambi_ (Read error: 54 (Connection reset by peer))
23:24:26kugelfunman: and (15<<2) still gives 24MHz?
23:24:26 Quit Self-Perfection (Read error: 104 (Connection reset by peer))
23:24:37funmannow clip bootloader fails (no display) with CGU_PLLA = 0x2630 :/
23:24:38kugelI suppose yes
23:25:03funmankugel: (15<<2) = 60
23:25:35kugelfunman: I mean as divider
23:25:45kugelas in 1/(15+1)
23:25:55funmankugel: be explicit, i'm not reading your mind !
23:26:23kugelI thought it was obvious that I was referring to the CGU_PERI line, sorry
23:26:36funmanthe plla is clocked at 384MHz with this setting, so the calculations don't change
23:29:14*funman notices a #ifndef BOOTLOADER block inside a #ifdef BOOTLOADER block
23:29:37amiconnhaha
23:31:15kugelfunman: yea, I wondered about that too
23:31:42funmankugel: my guess is that the previous pclk frequency we used we was "undetermined"
23:32:37*gevaerts suddenly realises that his e200 usb instability was with a 60MHz build
23:33:00kugelfunman: I guess that line should move after the #else
23:33:41funmanat the end of the function is fine, and boosting the CPU in the bootloader is fine too
23:35:30funmanhm it's useless, SD is slowed down by the peripheral clock onyl
23:36:19kugelfunman: does your clip boot now with the changed CGU_PLLA ?
23:36:23funmanno
23:36:36funmanlike I mentioned at 23:24
23:36:41domonokyfunman: something is strange. i can not shutdown my m200v4 anymore, it just starts up again.. :-)
23:36:51kugelfunman: yea, I just thought you might have resolved that already
23:36:52funmandomonoky: hm even with hardware power off?
23:37:10domonokyyes.. :-)
23:37:12kugeldomonoky: somthing which I also noticed a few times
23:37:19kugeluh, not that
23:38:39kugelfunman: white display here
23:39:51kugelfunman: oops wait
23:42:06kugelfunman: I see the bootlogo. The logo is fine, but not the text which states the revision. And it hangs at the bootloader
23:42:20kugel(the text is rather poxel garbage)
23:42:34funmanon my side I can boot with a cpu at 215MHz, but not with a cpu at 220MHz
23:42:46kugelnow it's fine. I still dont't boot into the main
23:43:01 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com)
23:44:00 Join skiy [0] (n=skiy@88-108-253-47.dynamic.dsl.as9105.com)
23:44:05kugelfunman: What do I need to change?
23:44:14funmankugel: ?
23:44:19kugelI see CGU_PROC is already at the lowest divider
23:44:33kugelwhat do I need to change to test that too
23:44:34funmanyou seem to forget there is 2 dividers in cgu_proc
23:44:39skiyHi folks! I've been using Rockbox successfully on a gigabeat F60 for many months - it is a truly awesome application and I wanted to thank everyone involved for their work on it.
23:44:40kugelsorry, the sentence got cut :/
23:44:50funmanjust read the datasheet, i have no more information than you on this topic
23:45:02kugelfunman: ah right, postdiv and prediv
23:46:37skiyI think the hardware is starting to give out though :(. Does anyone know if I patch up the bad sectors on the device if rockbox will continue to work?
23:47:26scorche|sh"starting to give out"?
23:47:47kugelfunman: how did you get to 220?
23:48:08kugel384*7/8*1/(1+1) is already lower
23:48:20funman352MHz plla
23:49:38skiyhi scorche|sh I think this indicates hardware problems :( :- FAT: Corrupted directory (i_pos 1104557790)
23:50:25kugelfunman: which GGU_PLLA= did you use? I don't get what do put there by reading the datasheet
23:50:48domonokyskiy: run a checkdisk or fsch.vat on you player, and see what it finds..
23:51:10domonokys/fsch.vat/fsck.vfat/
23:51:19skiythank you domonoky I will let you know what it finds
23:52:00amiconnHmm, really weird: If I build plain c200 SVN (from another working copy, but with the same toolchain), it works. A build from my main working copy shuts down after displaying the log, but there's a workaround for this: Pulling the microsd *and* holding "Right" during boot avoids that shutdown. Once booted, it works normally...
23:52:03funmankugel: look page 103
23:52:22amiconn*after displaying the logo
23:52:34kugelfunman: ah lol, I only scrolled back to page 1004
23:52:36kugel104
23:52:42funmanI use http://paste.ubuntu.com/78168/ to verify settings
23:53:21funmangood night sweet princes
23:53:23 Quit funman ("leaving")
23:54:02***Saving seen data "./dancer.seen"
23:55:03kugelerr, no python installed
23:56:34 Join llo7f [0] (n=llo@c-98-202-137-109.hsd1.ut.comcast.net)
23:57:19 Join skipper [0] (n=skipper@93-136-97-74.adsl.net.t-com.hr)
23:57:20kugellol, I have it! Sucking pastebins insert CRLFs
23:57:24 Join tical2k [0] (n=lihduebl@97.81.214.168)

Previous day | Next day