| 00:02:29 | amiconn | Coldfire can do 16MB dma transfer (24 bit). PP does no DMA at all, it uses the arm FIQ and cpu transfers |
| 00:02:36 | domonoky | and about 16k samples is probably too less to hear any sound.. |
| 00:03:01 | gevaerts | That's 0.3 seconds or so. I'd think you'd hear that |
| 00:03:20 | domonoky | the dma controller has only 11bit for the transfer size.. |
| 00:03:30 | amiconn | Only if you have a track that doesn't start with silence |
| 00:03:41 | amiconn | (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:39 | bertrik | can we trigger an interrupt at the end of the dma transfer to setup the next dma? |
| 00:04:45 | amiconn | That I don't think... the whole tock is quite short |
| 00:05:36 | domonoky | bertrik: yes, there is a interrupt at the end of dma transfer, thats how we wakup the sd-code after a dma-tranfer. |
| 00:05:44 | gevaerts | domonoky: are you sure it tries to play? metronome has its issues |
| 00:06:03 | domonoky | and how i know that dma ends before the fifo says its empty.. |
| 00:06:42 | bertrik | I thought there were half-full and almost-empty interrupts |
| 00:06:47 | domonoky | gevaerts: yes, i put a "play_tock()" at the beginning... and i am debuging the/my pcm code, so i know its called. |
| 00:07:06 | domonoky | bertrik: i2sout also has interrupts.. |
| 00:07:37 | domonoky | i check the i2sout interrupts to see if it really transfers something... and it does now :-) |
| 00:12:50 | | Quit massiveH ("Leaving") |
| 00:14:15 | domonoky | maybe 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:04 | gevaerts | amiconn: http://pastebin.ca/1269807 |
| 00:25:49 | | Quit bimbel ("Woah!") |
| 00:26:05 | gevaerts | I rechecked the r19248 c1000 result as well, and it is correct |
| 00:26:12 | amiconn | So this is indeed faster, even more than I thought... |
| 00:26:30 | amiconn | Did you check whether it actually sounds correct? |
| 00:26:57 | gevaerts | no. I'll do that now |
| 00:26:58 | amiconn | Bugs 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:08 | amiconn | Caching 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:31 | amiconn | oh? |
| 00:34:45 | * | amiconn should test that code on the beast... |
| 00:35:05 | pixelma | gevaerts: do you hear something with other codecs, remember reading something in the d2 port thread |
| 00:35:16 | gevaerts | pixelma: trying that now |
| 00:35:41 | pixelma | http://forums.rockbox.org/index.php?topic=10164.msg139842#msg139842 |
| 00:38:22 | * | gevaerts tries that |
| 00:41:04 | gevaerts | That helps |
| 00:41:37 | gevaerts | amiconn: it sounds correct at all compression levels (although -c4000 and -c5000 obviously skip a bit) |
| 00:41:54 | amiconn | thanks for testing |
| 00:42:15 | | Join DB42 [0] (n=qwqw@bzq-79-178-64-198.red.bezeqint.net) |
| 00:42:23 | DB42 | http://linuxoniphone.blogspot.com/2008/11/linux-on-iphone.html <−− when do we see rockbox for iphone ? |
| 00:42:36 | gevaerts | Are you working on it? |
| 00:42:47 | DB42 | on what ? |
| 00:42:50 | DB42 | check this http://www.vimeo.com/2373142 |
| 00:43:01 | gevaerts | Ports only happen when people work on them |
| 00:45:02 | linuxstb | DB42: Why would you want Rockbox on an iphone? |
| 00:45:20 | DB42 | why not ? |
| 00:45:38 | linuxstb | Do you know what Rockbox is? |
| 00:45:44 | * | gevaerts wants rockbox on his bicycle |
| 00:47:46 | agaffney | I assume he means ipod touch instead of iphone |
| 00:48:05 | BigBambi | gevaerts: Have you disassembled and scanned said bicycle? |
| 00:48:39 | gevaerts | Working 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:15 | Frosty | hello, i am having some trouble creating a background picture |
| 01:28:20 | Frosty | can anyone out there help me? |
| 01:28:28 | Frosty | i have a picture that is in jpeg format |
| 01:28:32 | | Part DB42 |
| 01:28:39 | Frosty | hello??? |
| 01:29:25 | advcomp2019 | Frosty, have you read the manual? |
| 01:29:47 | Frosty | yes i have |
| 01:30:07 | Frosty | i 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:17 | Frosty | therefore not being able to play them on my sansa e250 |
| 01:30:39 | shatness | so anyone have the new Archos 7? |
| 01:31:09 | shatness | ive cracked it to an extent, but the bootloader is a pain |
| 01:31:31 | Frosty | advcomp2019, ya there? |
| 01:31:34 | Frosty | is anyone there? |
| 01:31:36 | | Join Strife89 [0] (n=michael@204.116.245.152) |
| 01:31:38 | advcomp2019 | if i remember right, backdrops need to be bmp files and did you convert the videos right? |
| 01:31:53 | Frosty | i used the sansa video converter |
| 01:31:55 | Frosty | was i supposed to? |
| 01:31:57 | Llorean | No. |
| 01:32:06 | advcomp2019 | shatness, there is no rockbox for the archos 7 |
| 01:32:25 | shatness | can u point me in the right direction for archos people |
| 01:32:27 | Strife89 | advcomp2019: They also have to be the size of the display. |
| 01:32:35 | shatness | i need some help and thought this was part of it |
| 01:32:40 | Llorean | shatness: What exactly are you asking? |
| 01:32:40 | shatness | my mistake |
| 01:32:45 | advcomp2019 | Frosty, so you have not read the manual then |
| 01:32:47 | Strife89 | Frosty: Try WinFF, works like a charm. |
| 01:32:50 | Llorean | shatness: Are you trying to port Rockobx? |
| 01:33:01 | Frosty | yes i have |
| 01:33:03 | Unhelpful | shatness: if you're looking to help develop rockbox for the archos 7, you're in the right place... |
| 01:33:06 | Frosty | what is WinFF |
| 01:33:14 | shatness | I 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:23 | Unhelpful | if you're looking for rockbox for archos 7, ready to use, we don't have it. |
| 01:33:27 | advcomp2019 | Frosty, if you have, the video info is there to |
| 01:33:33 | Strife89 | Frosty: http://code.google.com/p/winff/ |
| 01:34:12 | shatness | so does anyone know of a good irc chan for archos fans |
| 01:34:23 | Frosty | i have AVI videos and WMP videos |
| 01:34:34 | Frosty | both dont show up when i go to the file that theyre supposed to be in |
| 01:34:46 | Llorean | Frosty: 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:07 | Unhelpful | Frosty: you *must* convert them to mpeg1/2 format to play them on rockbox |
| 01:36:06 | Frosty | are there any converters out there? |
| 01:36:14 | Frosty | can you give me a link or two? |
| 01:36:16 | Frosty | tnks.... |
| 01:36:24 | Llorean | Frosty: The PluginMpegplayer page on the Rockbox wiki has all the information you need |
| 01:36:28 | Llorean | Seriously, try reading the stuff we point you to. |
| 01:36:29 | | Part shatness |
| 01:36:43 | advcomp2019 | Frosty, the wiki page like Llorean said |
| 01:37:08 | pixelma | the 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:35 | spartan | sup playas |
| 01:53:43 | | Quit esthar ("KVIrc 3.4.0 Virgo http://www.kvirc.net/") |
| 01:54:12 | spartan | cant get ma backdrop to stay everytime i restart my sansa e280 |
| 01:54:21 | spartan | i put it in the backdrop file |
| 01:54:28 | spartan | but it does nothing |
| 01:55:04 | spartan | hola??????? |
| 01:55:23 | advcomp2019 | spartan, just hold on |
| 01:56:44 | spartan | i think my friend, frostbyte was havin the same problem as i wuz |
| 01:56:56 | spartan | you should help him if he's stal un |
| 01:57:16 | Llorean | spartan: We did help him. |
| 01:57:18 | | Quit tyfoo2 ("Carpe diem") |
| 01:57:24 | spartan | cool |
| 01:57:33 | Llorean | In fact, since you're on the same computer he was, he can tell you what we told him. |
| 01:57:42 | spartan | give me a sec |
| 01:58:10 | spartan | he has the backdrop working |
| 01:58:17 | spartan | but doesnt remember how he got it to work |
| 01:58:25 | Llorean | We told him to read the manual. |
| 01:58:28 | Llorean | You might try that too. |
| 01:58:34 | spartan | what manual? |
| 01:58:48 | spartan | nvm |
| 01:59:03 | Llorean | Please, try to use real English in here, as per the channel guidelines, and not things like "nvm" or "sup" |
| 01:59:10 | spartan | k |
| 01:59:13 | spartan | sorry |
| 01:59:17 | Llorean | That includes "k" |
| 01:59:27 | spartan | alright, the video problem is still there |
| 01:59:50 | spartan | im going to give the computer over to my brother |
| 01:59:57 | Unhelpful | yes, it will be until you convert your videos. you were even linked to a windows utility for that. |
| 02:00 |
| 02:00:12 | spartan | alright.....this is frostbyte, the video problem is still out there |
| 02:00:27 | Llorean | spartan: Try reading the wiki page you were referenced to by several of us. |
| 02:00:35 | advcomp2019 | did you use the wiki page? |
| 02:00:44 | spartan | my brother just got on dude |
| 02:01:02 | spartan | yes, i did |
| 02:01:05 | spartan | no help |
| 02:01:15 | saratoga | has anyone tried the changes in FS #9570 - Sansa e200v1: Increased runtime by ~20% on an Ipod ? |
| 02:01:15 | Llorean | spartan: Which method on the wiki page did you use? |
| 02:01:30 | saratoga | i bet you'd get some improvement in battery life on those too |
| 02:01:43 | spartan | cant remember |
| 02:01:44 | spartan | sorry |
| 02:01:56 | | Part pixelma |
| 02:01:57 | Llorean | saratoga: Wasn't part of it committed? |
| 02:02:11 | Llorean | spartan: Well, we can't help you if you don't know what you've done and what you haven't. |
| 02:02:16 | spartan | ok, so how do i get the backdrop to work |
| 02:02:21 | saratoga | Llorean: yeah I commited the Sansa specific stuff, but not the PP PLL changes |
| 02:02:29 | Llorean | spartan: Okay, stop asking the same questions over and over. |
| 02:02:31 | spartan | thats all im really trying to do |
| 02:02:58 | Llorean | spartan: 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:00 | spartan | i have read the manual twice now |
| 02:03:01 | Llorean | Don't try to guess what to do. |
| 02:03:09 | saratoga | i didn't realize Toni had SVN access, so i'm just going to let him commit whenever he likes |
| 02:03:10 | spartan | this is what i have done |
| 02:03:27 | saratoga | spartan: well you certainly haven't told us what you did |
| 02:03:33 | saratoga | so i wouldn't say you've done that |
| 02:03:35 | spartan | 1)put BMP file in backdrop file |
| 02:03:39 | Llorean | saratoga: Ah. How much power does the PLL alone save? |
| 02:03:53 | spartan | 2) "set as backdrop" |
| 02:03:58 | saratoga | Llorean: Toni says 2mA on his Sansa |
| 02:04:07 | spartan | except i cannot find the file that is in the "backdrop" file |
| 02:04:15 | spartan | so i use a copy of the picture |
| 02:04:23 | spartan | in the "photo" file |
| 02:04:26 | Llorean | Well that's why it's not saving. |
| 02:04:36 | spartan | so how do i find the "backdrop" fonder |
| 02:04:41 | spartan | folder* |
| 02:04:46 | Llorean | Change the file view mode to show all files, then browse to it. |
| 02:04:58 | spartan | how |
| 02:05:01 | Llorean | In the manual. |
| 02:05:32 | kugel | saratoga: I believe someone reported ~16% (wasn't a proper battery bench though) |
| 02:05:39 | spartan | thank you |
| 02:05:44 | spartan | now to the video problem |
| 02:06:23 | | Quit miepchen^schlaf () |
| 02:06:37 | saratoga | Llorean: 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:39 | Llorean | saratoga: 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:52 | saratoga | yeah probably |
| 02:07:13 | saratoga | i 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:29 | saratoga | they somehow found an mp3 player as slow as ours |
| 02:07:33 | Llorean | With MP3 we certainly are. |
| 02:07:43 | saratoga | mp3 decoder rather |
| 02:08:04 | Llorean | Since we were about on-par with the OF when MP3 was single-core. |
| 02:08:17 | saratoga | yeah |
| 02:08:34 | saratoga | if Toni is right I guess we're probably around 26+ hours on the Sansa with a new battery at least |
| 02:08:48 | Llorean | Wow. |
| 02:08:54 | * | Llorean should order up a new battery |
| 02:09:09 | saratoga | though thats with the PLL changes |
| 02:09:09 | Llorean | I assume the V2s use the same battery as the V1s, is this a safe assumption? |
| 02:09:16 | spartan | Llorean, 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:22 | saratoga | LLorean: yeah I think so |
| 02:09:28 | saratoga | spartan: no |
| 02:09:40 | Llorean | spartan: 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:48 | saratoga | go 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:54 | spartan | so it needs to be a mpeg conversion |
| 02:11:17 | spartan | am i right? |
| 02:11:33 | Llorean | spartan: It says this in no uncertain terms on the wiki page, so yes. |
| 02:12:10 | saratoga | kugel: [for the logs] I've noticed booting on the Fuze seems to fail on some bootloader builds for no obvious reason |
| 02:12:15 | saratoga | i wonder if you've noticed this |
| 02:12:20 | spartan | can you give me the "wiki" page |
| 02:12:21 | kugel | heh |
| 02:12:24 | spartan | thanks |
| 02:12:31 | saratoga | oh didn't expect you to be up at this hour |
| 02:12:53 | kugel | 2AM, not too late for weekend :p |
| 02:12:57 | saratoga | anyway 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:20 | spartan | are there any other formats than mpeg that the video can be played in |
| 02:13:30 | saratoga | nope |
| 02:13:40 | spartan | wow |
| 02:13:41 | spartan | k |
| 02:13:45 | kugel | saratoga: I use a pre-r19234 svn bootloader, which is pretty stable |
| 02:13:57 | saratoga | kugel: also did funman ever mention what he thought the Clip V2 used as the CPU? |
| 02:14:46 | spartan | anyone out there? |
| 02:14:52 | kugel | No. 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:55 | spartan | are you still there? |
| 02:15:07 | saratoga | spartan: theres like a hundred people here |
| 02:15:11 | Llorean | spartan: You've been told the name of the wiki page several times, and it's even linked to in the manual. |
| 02:15:28 | saratoga | kugel: I thought someone mentioned it was based on a slightly different AMS part |
| 02:15:35 | Llorean | spartan: At this point, we're finding it somewhat unbelievable that you've even *tried* reading the manual. |
| 02:15:36 | saratoga | though i could be wrong |
| 02:15:39 | spartan | i was just making a reference to portal |
| 02:15:44 | kugel | I could be wrong as well |
| 02:15:51 | spartan | guess no one on here plays games |
| 02:15:57 | saratoga | ugh |
| 02:16:05 | Llorean | spartan: This is an on-topic channel. That means "please be quiet unless you're developing Rockbox or asking support questions." |
| 02:16:47 | Llorean | there 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:03 | saratoga | kugel: ah found something by funman speculating it might be AS3530 based |
| 02:17:35 | saratoga | which 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:39 | spartan | quick question that isnt in the manual |
| 02:18:00 | spartan | are there any websites that support rockbox and have any games? |
| 02:18:23 | Llorean | You 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:36 | Llorean | And no, we don't know of any sites like that. |
| 02:18:46 | kugel | saratoga: 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:20 | Llorean | kugel: They upgraded the m200 to a SoC much more powerful than it needs too, didn't they? |
| 02:19:32 | kugel | I thought they just gave it more ram (like 8MB) since the firmware filesize is also 15MB like for the fuze/e200v2 |
| 02:20:04 | saratoga | kugel: maybe they're moving everything over to the new chips? |
| 02:20:21 | spartan | thanks and peace out everyone |
| 02:20:21 | saratoga | kind of like when they introduced the V2 Sansas even though the old ones worked just as well |
| 02:20:22 | spartan | 4 |
| 02:20:22 | spartan | 4 |
| 02:20:22 | DBUG | Sent KICK spartan to server |
| 02:20:22 | spartan | 4 |
| 02:20:23 | *** | Alert Mode level 1 |
| 02:20:23 | DBUG | sent MODE #rockbox +b *!*n=0c684f*@*.contactor.se/x-64d94b2bbd0bba13 |
| 02:20:23 | *** | Alert Mode level 2 |
| 02:20:23 | spartan | 4 |
| 02:20:23 | Kick | (#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:23 | Mode | "#rockbox +b *!*n=0c684f*@*.contactor.se/x-64d94b2bbd0bba13 " by logbot (n=bjst@gateway/web/cgi-irc/labb.contactor.se/x-a4cf5f5668b5c9f2) |
| 02:20:25 | kugel | Llorean: I don't know about the performance about the tcc chips, so possibly yes. I haven't said it's very unlikely |
| 02:21:15 | kugel | saratoga: the v2s are a new product line though, which replaced a 2year old one, the clipv2 isn't |
| 02:21:21 | saratoga | the 3530 would be good for a View style player, so maybe we'll get a View V2 soon |
| 02:21:31 | saratoga | the e200V2 wasn't a new product line |
| 02:21:44 | kugel | well, e200v2 is a refresh indeed, but I think that's mainly a ams one because they can share manufactoring etc |
| 02:21:55 | saratoga | it was basically the same as what they did with the Clipv2 |
| 02:21:57 | saratoga | and the c200v2 |
| 02:22:01 | | Quit XavierGr (Read error: 131 (Connection reset by peer)) |
| 02:22:02 | saratoga | and the m200v4 |
| 02:22:27 | Llorean | They 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:32 | kugel | uhm, as I sad, I could be wrong as well :) |
| 02:22:37 | Llorean | Maybe we'll see e200/c200v3 soon. |
| 02:22:45 | Llorean | Actually, I doubt it. |
| 02:22:53 | Llorean | It kinda looks like they're on the verge of cutting them off completely |
| 02:22:58 | kugel | a fuzev2 is more likely I think |
| 02:22:58 | saratoga | yeah they'll probably just cancel them |
| 02:24:28 | Llorean | Their page suggests the only Sansas they care about now are the Fuze, View, Clip and the "slotMusic" player thingy |
| 02:25:45 | saratoga | so are we hoping on having album art resizing for 3.1? |
| 02:27:15 | Llorean | I was hoping on having it for 3.0, personally. |
| 02:27:51 | Llorean | But 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:24 | saratoga | memory use seems way down, but i wonder if its low enough for everyone's taste? |
| 02:28:39 | Unhelpful | i 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:49 | Llorean | saratoga: Well, we all accept there's gonna be *some* memory hit. |
| 02:28:49 | Bensawsome | Llorean rockbox gonna stop support for the e200? :( |
| 02:28:58 | Llorean | Bensawsome: No. Sandisk is probably going to. |
| 02:29:07 | saratoga | i think sandisk already did |
| 02:29:13 | Bensawsome | oh thank goodness :) i couldnt live without rockbox |
| 02:29:16 | saratoga | Unhelpful: so how close is it to ready? |
| 02:29:24 | Llorean | saratoga: 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:19 | saratoga | it'd be really nice if we could get it in for 3.1 |
| 02:30:24 | *** | Alert Mode OFF |
| 02:30:38 | saratoga | might motivate people to start working on a JPEG decoder, which if resizing is any indication, should take about 3 years or so |
| 02:30:46 | saratoga | we'll have it ready in time for 3.17 |
| 02:31:22 | | Join esthar [0] (n=esthar@student166-183.hampshire.edu) |
| 02:31:54 | Unhelpful | saratoga: 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:14 | saratoga | Unhelpful: whats the memory hit like on the BW targets? negligable right? |
| 02:32:36 | Llorean | I can't imagine we'd be using it on true B&W (non-Grayscale) targets, would we? |
| 02:33:03 | saratoga | probably not, but theres still the framework and buffering stuff which probably adds some memory |
| 02:33:06 | Unhelpful | Llorean: no, but there are changes to the bmp reader core as well, and there will be some change on mono targets |
| 02:33:44 | saratoga | obviously its important that mono targets have as small an effect as possible, since many of them are extremely memory limited |
| 02:33:45 | Llorean | The 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:15 | saratoga | the X5 too is probably important since I think thats only got 16GB and of course a color target |
| 02:34:29 | saratoga | sorry 16MB |
| 02:34:56 | Llorean | We have a few 16MB Grayscale targets too. |
| 02:35:15 | Llorean | But isn't the whole memory hit less than 15k? |
| 02:35:37 | Unhelpful | Llorean: 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:09 | Llorean | Unhelpful: Is there an ifdef for album art? |
| 02:36:21 | Llorean | Is it possible to use the old code if album art isn't enabled? |
| 02:39:51 | Unhelpful | at 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:40 | Unhelpful | right 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:20 | saratoga | Unhelpful: 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:56 | saratoga | and anyway it might be handy if we ever get a seriously memory limited grayscale target or something |
| 02:42:42 | kugel | saratoga: did you already try a pre-r19234 bootloader? |
| 02:42:48 | Unhelpful | should 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:01 | saratoga | kugel: yeah I already had an older SVN checkout handy, using the current one doesn't work at all |
| 02:45:12 | Unhelpful | saratoga: if i'm understanding correctly, you think there will be people who demand the scaler on mono? |
| 02:45:35 | saratoga | UNhelpful: no i think there will be people who think the memory use isn't justified and want to reclaim it |
| 02:45:46 | saratoga | or as much of it as possible at any rate |
| 02:46:22 | saratoga | i guess these people should just get nearest neighbor or even a truncated bmp |
| 02:46:38 | Unhelpful | saratoga: 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:48 | saratoga | i'm sure thats fine |
| 02:47:11 | saratoga | but 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:40 | Unhelpful | i didn't think i was using so much? let me check again. |
| 02:48:34 | saratoga | oh maybe i'm remembering an old version of the patch |
| 02:50:20 | kugel | saratoga: Then funman really broke it with his commit |
| 02:50:37 | Unhelpful | saratoga: 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:10 | saratoga | thats not bad |
| 02:51:14 | Unhelpful | the 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:32 | kugel | what happened to partial line processing? |
| 02:52:20 | Unhelpful | kugel: 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:49 | Unhelpful | the input buffer is 8 * uint8_rgb, and is on the stack |
| 02:53:18 | kugel | Unhelpful: can't you use the buffer that was always there for output? |
| 02:53:50 | kugel | the old read_bmp allocated the amount needed, afairc |
| 02:54:47 | kugel | if there's a new output buffer, what happened to the old one? |
| 02:54:48 | Unhelpful | kugel: not really, unless the reader is passed a buffer that is guaranteed to have more space than needed for the final output |
| 02:56:22 | kugel | Unhelpful: I think there was two function, the 1 returned the buffer size needed, the other did the reading |
| 02:57:49 | Unhelpful | kugel: 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:54 | kugel | Unhelpful: 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:07 | kugel | but well, 5KiB ain't bad, so |
| 03:02:39 | Unhelpful | kugel: that's on a color target, with a 240px wide screen. mono targets and grey targets get no new static buffers. |
| 03:02:40 | kugel | and it'll be less on targets with lowmem since they have generally not 240px wide screens |
| 03:03:15 | Unhelpful | i'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:55 | kugel | Unhelpful: get one, it's for free :) |
| 03:08:37 | Unhelpful | kugel: i don't have any reason to keep one installed ;P |
| 03:19:33 | saratoga | kugel: does the button code in button-fuze.c work? |
| 03:20:16 | | Quit toffe82 (Read error: 60 (Operation timed out)) |
| 03:24:58 | kugel | saratoga: only in the bootloader |
| 03:27:26 | kugel | cu all |
| 03:27:31 | | Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.4/2008111318]") |
| 03:34:56 | Unhelpful | hrm, 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:02 | Unhelpful | latest 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:12 | saratoga | ah 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:39 | hillshum | Are the e200v2 bootloaders building well for all? |
| 05:00 |
| 05:02:34 | saratoga | hillshum: the fuze one is broken right now, so maybe not |
| 05:03:11 | hillshum | okay so its not my cygwin |
| 05:03:22 | | Quit hillshum ("Leaving") |
| 05:07:48 | saratoga | hmm I can't figure out how to read the stupid DBOP pins |
| 05:07:58 | saratoga | will 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:39 | Unhelpful | hrm, 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:43 | amiconn_ | 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:18 | Unhelpful | amiconn: 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:07 | amiconn | The 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:17 | Unhelpful | amiconn: the full rockbox-info.txt for each target, vanilla and patched, are concatenated into a text file on FS #9458 |
| 09:57:19 | amiconn | It 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:19 | Unhelpful | maybe it would be wise to split it out into a bmp-simple.c? |
| 10:02:01 | Unhelpful | there'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:21 | amiconn | If 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:13 | Unhelpful | amiconn: 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:41 | amiconn | The Clip port isn't finished, but it's an arm target with only 2MB RAM |
| 10:10:58 | amiconn | The 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:12 | Unhelpful | i 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:34 | amiconn | There is no monochrome coldfire target |
| 10:16:25 | pixelma | what about the Iriver remotes? |
| 10:16:59 | pixelma | although they don't display album art or sliding_puzzle... |
| 10:17:32 | Unhelpful | amiconn: 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:06 | Unhelpful | pixelma: no, but mono remotes use the same loader, including the scaler, on targets that have a grayscale or color display |
| 10:18:23 | Unhelpful | the inside loop of it has a switch for the output type |
| 10:20:17 | pixelma | but that is additional to the main screen (colour or greyscale) so won't give helpful numbers |
| 10:22:16 | n1s | Unhelpful: just as a nit, that bitmap resize patch has some (very) long lines, our max is 80 cols :) |
| 10:24:13 | Unhelpful | n1s: 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:42 | n1s | yes |
| 10:25:29 | Unhelpful | ... do C statements need a \ for line continuation? |
| 10:25:53 | linuxstb | No |
| 10:28:16 | * | amiconn thought a bit about the dualcore split of the ape decoder |
| 10:28:30 | amiconn | It seems some infrastructural rework in libdemac is needed for that |
| 10:29:56 | Unhelpful | ugh, yes, grep and wc tell me i've much to do in resize.c for <=80cols |
| 10:30:39 | amiconn | A 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:33 | amiconn | They also need the old context info, and chunk length |
| 10:32:55 | amiconn | I'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:00 | Unhelpful | i suppose next you'll be wanting comments that explain how this works? ;) |
| 10:39:35 | pixelma | n1s: 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:58 | pixelma | but I don't want to hide it away |
| 10:51:16 | Unhelpful | hrm, 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:27 | amiconn | The m5 remote does have a different pixel format than the main lcd |
| 10:57:16 | | Quit Darksair ("Use the Force, Luke!") |
| 10:57:50 | Unhelpful | amiconn: 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:14 | Unhelpful | preprocessed 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:59 | n1s | preglow: ping |
| 11:51:26 | pixelma | n1s: shall I hit enter or do you have a better idea? ;) |
| 11:51:54 | n1s | pixelma: i didn't quite understand what you said earlier |
| 11:52:14 | n1s | are all action macros moved to keymaps now? |
| 11:53:43 | *** | Saving seen data "./dancer.seen" |
| 11:53:51 | pixelma | yes. 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:19 | n1s | aha, i think that's fine |
| 11:56:45 | n1s | Unrelated, 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:21 | Unhelpful | sample 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:46 | n1s | Unhelpful: right, but would sample doubling at 44.1kHz sound worse than playing at 22kHz? |
| 12:02:20 | Unhelpful | n1s: we have that as an option? i thought rockbox didn't handle output frequency switching? |
| 12:03:05 | n1s | Unhelpful: some players can do 22kHz out, but not all, however our playback system can not deal with frequencies other than 44.1kHz |
| 12:03:56 | n1s | so 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:01 | Unhelpful | but if a plugin stops codec playback, it can change the playback rate of the hardware? |
| 12:04:07 | n1s | yes |
| 12:04:28 | n1s | if it's implemented in that players' dac driver |
| 12:05:34 | n1s | the define HW_SAMPR_CAPS in firmware/export/config-*.h tells which samplerates are supported on which target if you are interested |
| 12:05:35 | Unhelpful | i 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:00 | bertrik | I hope the USB problem on PP is not caused by a bug in the hardware with an unpublished work-around |
| 12:32:00 | Unhelpful | could 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:29 | bertrik | yeah, 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:38 | gevaerts | That 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:39 | LosNir | Hi 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:59 | linuxstb | One analyser between PC and hub, another between hub and PP? |
| 13:05:33 | gevaerts | Or one expensive two-port analyser? |
| 13:06:01 | | Join zhufeng [0] (n=da4c53ef@gateway/web/cgi-irc/labb.contactor.se/x-208ec7f0da6b6f23) |
| 13:06:07 | zhufeng | hi |
| 13:06:18 | zhufeng | any developers here ? |
| 13:06:41 | | Quit zhufeng (Client Quit) |
| 13:06:49 | linuxstb | Bye |
| 13:06:53 | | Join zhufeng [0] (n=da4c53ef@gateway/web/cgi-irc/labb.contactor.se/x-7b54dc9ebfd8b21f) |
| 13:07:20 | linuxstb | zhufeng: Yes, there are many - just ask your question. |
| 13:07:52 | zhufeng | I wanna ask about the status of the Meizu port |
| 13:09:03 | zhufeng | anybody 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:22 | linuxstb | zhufeng: Just be patient, and wait until someone that knows the answer reads your question... |
| 13:12:23 | zhufeng | I know markun ,but it seems that he is not online now |
| 13:13:36 | BigBambi | There are others too - as linuxstb says, people read the logs - wait until someone that knows reads your question and answers |
| 13:14:25 | gevaerts | The forum thread is up to date as far as I know |
| 13:14:46 | zhufeng | but I didn't find any information here |
| 13:15:02 | zhufeng | is 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:23 | markun | hi zhufeng :) |
| 13:17:29 | zhufeng | hi |
| 13:17:37 | zhufeng | why 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:49 | amiconn | gevaerts: 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:01 | amiconn | It's tested on Mini G2 |
| 13:30:04 | gevaerts | 404 again |
| 13:31:06 | amiconn | Sorry, amiconn.dyndns.org/~jens/pp502x_60mhz.diff">http://amiconn.dyndns.org/~jens/pp502x_60mhz.diff |
| 13:32:29 | gevaerts | Thanks |
| 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:30 | bertrik | I 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:39 | bertrik | I'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:45 | bertrik | to get a discharge curve |
| 14:42:45 | * | amiconn wonders what's up with his c200 build :\ |
| 14:43:22 | amiconn | It shows the logo, then powers off |
| 14:44:43 | bertrik | r19206 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:04 | pinkstring_ | hello people, I have a question... Can I use Rockbox with Ipod Classic generation 6 ??? |
| 14:48:32 | BigBambi_ | no, as www.rockbox.org says |
| 14:49:46 | | Join {phoenix} [0] (n=dirk@p54B46130.dip.t-dialin.net) |
| 14:52:02 | pinkstring_ | BigBambi_, in the future, it will be possible?? |
| 14:52:19 | BigBambi_ | unlikely, but who knows |
| 14:52:52 | BigBambi_ | encrypted firmware, plus new undocumented hardware, plus nobody working on it = not likely |
| 14:53:29 | pinkstring_ | ok thanks you for help |
| 14:53:36 | pinkstring_ | bye |
| 14:53:41 | BigBambi_ | 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:48 | gevaerts | amiconn: 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:09 | funman | domonoky: i read you made some progress on i2sout yesterday? |
| 15:31:11 | domonoky | funman: yes, a little bit. we forgot the CGU_AUDIO (i2sout_mclock). Now my i2sout fifo fills and emptys with dma.. |
| 15:31:55 | domonoky | but 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:16 | funman | we 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:56 | domonoky | funman: or use the LLI feature of the dmac. |
| 15:34:50 | funman | how bigger is the requested size? |
| 15:35:29 | | Quit _lifeless (Read error: 110 (Connection timed out)) |
| 15:35:33 | funman | I 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:33 | domonoky | what comes from the metronome, seem to fit into 2 dma tansfers. but i am not sure what the maximum is. |
| 15:38:51 | funman | 0x7ff * dstwidth * dstsize |
| 15:39:38 | domonoky | first request from mentrome is 46080 bytes. |
| 15:40:29 | funman | fifo pop error .. |
| 15:41:25 | domonoky | you get a fifo pop error, when the fifo is run out of data. try put a panic into the dma_interrupt handler... |
| 15:41:52 | domonoky | you will probably see, that the dma-terminal interrupt comes before the fifo pop-error. |
| 15:42:45 | domonoky | you 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:35 | funman | for me it seems the fifo is never filled |
| 15:50:46 | funman | perhaps the lcd operation in the isr is too slow |
| 15:51:48 | domonoky | funman: you could compare to my changes: http://pastebin.com/m419f43f9 |
| 15:52:29 | funman | hm i didn't modify the metronome |
| 15:52:55 | domonoky | that 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:46 | domonoky | hm, 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:44 | funman | I wonder if we should manually start transfers at each i2sout interrupt on status fifo * empty |
| 16:04:36 | domonoky | funman: you mean transfer data without the dma ? |
| 16:04:59 | funman | no i meant with it |
| 16:05:21 | funman | I don't understand how the DMAC knows about the status of i2sout's fifo |
| 16:05:22 | domonoky | ah, setup a new transfer on fifo-empty ? could work.. |
| 16:05:49 | funman | but if i understand well the fifo is 4 * 32 bits word |
| 16:05:53 | funman | so no need to use dma :/ |
| 16:06:04 | domonoky | funman: the i2sout fifo requests dma-transfers via the dma_request line, when the fifo runs empty.. |
| 16:06:45 | funman | ah ok |
| 16:07:05 | funman | i'll try transfers without dma so at least we know when i2sout / audio settings are ok ;) |
| 16:08:11 | domonoky | yes, manula transfers might be a good way to get this running. i think ipods also dont use dma. |
| 16:09:03 | domonoky | i 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:23 | funman | i did the same, let's try again with the i2so_mclk clock running |
| 16:10:48 | domonoky | i 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:16 | bertrik | page 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:25 | domonoky | so its running way to fast for me.. |
| 16:14:52 | funman | OF uses 5644800 Hz (not sure if it's variable yet) |
| 16:15:05 | bertrik | it's 128 times the desired sample rate |
| 16:15:47 | funman | that would be plla/68 |
| 16:15:55 | domonoky | oki, 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:07 | domonoky | its 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:33 | funman | domonoky: great ! I can't reproduce without DMA, I'll keep trying :) |
| 16:37:12 | domonoky | this 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:47 | funman | domonoky: look in the simulator for the reference tick |
| 16:39:32 | domonoky | or one of my other targets :-) |
| 16:40:23 | | Join Bensawsome [0] (n=Bensawso@unaffiliated/bensawsome) |
| 16:40:50 | kugel | does metronome sound qualify for the gentlemen mail? I hope not :) |
| 16:42:22 | | Quit moos (Read error: 110 (Connection timed out)) |
| 16:42:59 | funman | domonoky: i can hear the tick but it doesn't sound like in the simulator |
| 16:43:14 | domonoky | its 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:31 | funman | and by the way the diff to metronome is not needed (except the keymap of course) |
| 16:44:40 | kugel | linuxstb: ping |
| 16:44:55 | funman | domonoky: does your m200 deadlock on shutting down like my clip ? |
| 16:46:16 | domonoky | funman: i dont really know, it think i always get the hard-power off.. |
| 16:46:39 | kugel | linuxstb: I thinke the "/* TODO: The OF calls some other functions here, but maybe not important */" isn't unimportant at all |
| 16:46:40 | domonoky | but i get spurious reboots sometimes, so there is still much todo :-) |
| 16:46:58 | funman | domonoky: oh, i can see the 'shutting down' screen |
| 16:47:02 | funman | yeah i get reboots as well ;) |
| 16:48:01 | Llorean | How's the install process? Is it likely to be something that can go into RButil? |
| 16:48:22 | domonoky | ah, 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:00 | domonoky | Llorean: a bit like on the hxx0 players.. patch a of firmware for the bootloader.. so no problem for rbutil. |
| 16:49:01 | funman | perhaps the timing needs to be adjusted to be shorter |
| 16:50:13 | bertrik | hmm, I always get the shutting down text when powering off |
| 16:51:41 | kugel | same |
| 16:53:13 | * | domonoky thinks he now need another test-plugin to test longer sounds... :-) |
| 16:54:52 | Llorean | The wiki pages make it sound like the m200v4 Rockbox is less advanced than the m200v1-3 |
| 16:57:22 | Llorean | Do 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:50 | funman | no way, except using the safe mkamsboot :) |
| 16:58:14 | Llorean | I'm not sure I understand that sentence. |
| 16:58:47 | funman | there's no recovery mode, but mkamsboot is deemed safe enough to not need recovery |
| 16:58:50 | domonoky | a failed flash would always brick those targets, it like with the hxx0 players. You can also brick them with a faild flashing.. |
| 16:59:52 | domonoky | but 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:13 | Llorean | domonoky: I didn't mean to suggest they were unsafe. Just brickable. |
| 17:00:46 | domonoky | and i just wanted to say, that iriver h1xx are even more brickable :-) |
| 17:00:50 | funman | the recovery mode for e200v2 isn't exactly user friendly, so they should all be considered brickable |
| 17:01:28 | Llorean | domonoky: Do we checksum the bootloader file after it's copied to the device in RButil, or just after they're merged? |
| 17:01:44 | funman | we checksum the original firmware |
| 17:01:58 | funman | oh sorry, i was talking about mkamsboot, not rbutil |
| 17:02:09 | domonoky | Llorean: before and after the merge for irivers, the copiing is not checked. |
| 17:02:11 | Llorean | funman: And mkamsboot doesn't copy it to the device anyway, does it? |
| 17:02:30 | | Quit kachna|lappy ("Konversation terminated!") |
| 17:02:31 | Llorean | domonoky: Maybe we should check after the copy too, just to be safe. |
| 17:02:39 | domonoky | only if you point mkamsboot to the device :-) |
| 17:02:45 | funman | no it doesn't, just generate a file to be copied |
| 17:03:12 | domonoky | Llorean: i think there is another checksum, checked by the OF before flashing, so a failed copy should be detected. |
| 17:03:38 | Llorean | domonoky: On the H100? |
| 17:03:58 | domonoky | yes. it wont flash a invaild firmware... |
| 17:04:01 | Llorean | Okay. |
| 17:04:05 | funman | domonoky: are we sure of the endianess to use for audio samples ? |
| 17:04:12 | domonoky | funman: nope. |
| 17:04:13 | Llorean | As 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:12 | domonoky | funman: 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:13 | funman | oh right |
| 17:08:55 | * | domonoky wants to find out why codecs dont run.. :-/ |
| 17:09:05 | funman | same :( |
| 17:09:51 | | Join sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) |
| 17:11:54 | bertrik | the 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:37 | bertrik | I 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:38 | domonoky | bertrik: 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:51 | funman | the 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:56 | funman | the size of all LLIs is incorrect in fact |
| 17:21:19 | domonoky | ups :-) |
| 17:22:20 | | Quit {phoenix} (Remote closed the connection) |
| 17:24:43 | funman | hm |
| 17:24:56 | funman | nwords = DMA_S4 != 4 |
| 17:25:52 | | Join m0f0x [0] (n=m0f0x@189-47-42-178.dsl.telesp.net.br) |
| 17:28:21 | funman | domonoky: I'd prefer if we setup a new transfer each time the previous one has finished |
| 17:28:39 | funman | rather than using LLIs I mean |
| 17:29:55 | domonoky | funman: sure, why not.. i was just experimenting with it. |
| 17:30:36 | funman | i 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:15 | domonoky | hm, correcting the nwords in the src calculation makes the "tick" vanish again... |
| 17:33:33 | funman | i noticed :/ |
| 17:33:43 | funman | at least that means the LLI setup worked ;) |
| 17:33:47 | domonoky | registering 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:05 | kugel | amiconn: quick arm question: what's done if ORR has only 2 operands? |
| 17:41:26 | kugel | I 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:22 | domonoky | it 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:33 | domonoky | so its r0=r0|r6 |
| 17:45:39 | kugel | I'd guess the 3rd operand is considered as 0, so r0 = r6 |
| 17:46:05 | kugel | domonoky: 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:28 | kugel | domonoky: but maybe you're right, since it's thumb code |
| 17:48:41 | | Join pondlife [50] (n=Steve@rockbox/developer/pondlife) |
| 17:49:21 | kugel | domonoky: yep, you're right. In thumb code it only has 2 operands |
| 17:49:46 | domonoky | :-) |
| 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:18 | funman | domonoky: how did you put a panic in mpa.c ? lcd_puts+while(1) ? |
| 18:40:50 | domonoky | funman: i added panicf to the codec api (apps/codecs.c/h ) :-) |
| 18:41:02 | funman | ok ^^ |
| 18:41:12 | domonoky | the i can use ci->panicf in codecs... but they never get loaded at moment... |
| 18:41:36 | funman | I have setup the dma callback but I hear an horrible sound instead of the nice tick |
| 18:41:43 | funman | I want to use longer pcms |
| 18:42:58 | | Quit Nico_P (Remote closed the connection) |
| 18:43:14 | domonoky | at least we hear any sound :-) i am now debuuging why codecs dont load... (with lots of panics) :-) |
| 18:44:55 | funman | perhaps test_codec is a good way to debug |
| 18:47:01 | funman | hmm 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:39 | funman | I thought it would adapt to small buffers |
| 18:47:49 | funman | I'll check the linker script |
| 18:48:24 | domonoky | yes, 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:20 | funman | is the codec loaded into the audio buffeR? |
| 18:56:49 | funman | I think the buffer are badly defined |
| 18:58:40 | domonoky | codecs 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:24 | funman | test_codec gives me reboots, undefined instructions; so I think its code is being overwritten |
| 19:00 |
| 19:07:24 | kugel | funman, 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:09 | funman | domonoky: 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:56 | funman | kugel: thanks, bookmarking ^^ |
| 19:09:17 | kugel | that disables buffering alltogether, and reads data from flash directly |
| 19:09:55 | funman | codecs load at 1MB , plugins at 1.5MB |
| 19:10:26 | domonoky | waring this patch is outdated.. :-) |
| 19:11:33 | kugel | funman, 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:13 | domonoky | kugel: it may work, but its outdated and needs manual fixing.. |
| 19:14:57 | funman | I think test_codec is not adapted to work on lowmem targets |
| 19:15:57 | funman | domonoky: can you point me to where codecs are loaded into memory ? |
| 19:16:10 | kugel | domonoky: you tried to apply? Ony sources could fail, easy fix |
| 19:16:40 | domonoky | kugel: yes, i tried, and there is no more EVENT_HANDLE_FINISHED, i can not find it in the sources.. |
| 19:16:58 | kugel | ah, then ask Nico_P :P |
| 19:17:36 | domonoky | funman: you mean the memory position, or the code which loads them ? |
| 19:18:01 | funman | code which loads them (the position is defined in the app.lds linker script) |
| 19:18:31 | domonoky | i tracked codec/audio loading to playback.c audio_load_track(), where the bufopen() (from buffering.c ) fails.. |
| 19:19:51 | domonoky | playback.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:21 | kugel | funman: svn bootloader is broken? |
| 20:13:50 | funman | kugel: I am running r19240 as bootloader |
| 20:14:25 | kugel | funman: so? |
| 20:14:34 | funman | so r19240 is not broken |
| 20:14:41 | | Quit tyfoo2 (No route to host) |
| 20:14:44 | kugel | if the bootloader is considered finished, it shouldn't be broken |
| 20:14:59 | funman | is it ? |
| 20:15:02 | funman | (broken) |
| 20:15:12 | kugel | yes |
| 20:15:43 | | Join MethoS [0] (n=clemens@host-091-097-242-082.ewe-ip-backbone.de) |
| 20:15:47 | funman | which revision? |
| 20:16:09 | kugel | latest ;; |
| 20:16:25 | funman | then 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:11 | domonoky | kugel: and what means broken ? what happens ? |
| 20:17:49 | funman | last (r19262) works fine for me |
| 20:17:56 | kugel | it starts with a white screen |
| 20:18:25 | funman | perhaps change of pclk broke it, did you try reverting that change ? (I remember discussing that with you already) |
| 20:20:11 | funman | and 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:56 | kugel | funman: I don't understand why you wait until such changes are tested on other ams sansas |
| 20:23:13 | funman | domonoky: "Not enough space for required allocations" in buffering.c |
| 20:23:46 | funman | kugel: i believed the same hardware requires the same conditions, didn't think about different lcd controllers |
| 20:24:41 | kugel | and you don't intend to revert, I guess? Since you don't care about targets you don't own? |
| 20:25:04 | funman | for sure i will not revert anything if you don't tell me that reverting this change fix your problem |
| 20:25:46 | funman | not working on specific code for other models doesn't mean i want to break them |
| 20:25:51 | domonoky | funman: 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:59 | funman | and insulting me will not help |
| 20:26:27 | kugel | I didn't insult |
| 20:26:37 | kugel | just asked |
| 20:26:44 | domonoky | kugel: please stay friendly, funman is doing great work... we can not make sure we dont break other new targets we dont own... |
| 20:26:46 | funman | That's how I understood it |
| 20:26:52 | kugel | then I'm sorry |
| 20:27:07 | * | funman gives a peaceful hand to kugel |
| 20:27:23 | kugel | domonoky: sure he's doing great work. This wouldn't be possible at all without him. |
| 20:27:49 | domonoky | the only way is, that owners of the other ams-sanas tell us, when we break somehing.. then we can try and fix... :-) |
| 20:28:07 | kugel | but 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:55 | kugel | funman: indeed, reverting to r19234 helped |
| 20:29:56 | funman | kugel: 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:16 | funman | please use latest revision with only this change, set_cpufrequency() shouldn't harm |
| 20:30:35 | kugel | funman: I only reverted system-as3525.c |
| 20:32:05 | | Quit JdGordon|zzz (Remote closed the connection) |
| 20:32:10 | funman | yes, but there is 2 diffs in this commit |
| 20:32:30 | | Join JdGordon|zzz [0] (n=jonno@rockbox/developer/JdGordon) |
| 20:33:35 | kugel | funman: yea. the other is guarded with #ifndef BOOTLOADER though ;) |
| 20:33:42 | funman | ah right |
| 20:34:08 | funman | so, can you check the lowest pclk frequency you can use ? (this commit was intended to reduce power consumption) |
| 20:34:21 | domonoky | /me suspects it timings in the fuze-lcd code. so the right fix would be, to make them frquency independent.. |
| 20:34:50 | funman | 5<<2 is the plla (|0x01) divider - 1, so 384/(5+1) == 64; and now we use 24 |
| 20:35:06 | funman | but of course it's better if you lower the delays in fuze driver |
| 20:35:26 | kugel | domonoky: there's a simple lcd_delay function. If it's clocked lower, you mean I should lower the delay as well? |
| 20:35:39 | kugel | let me try. The delay is too high anyway |
| 20:36:21 | domonoky | kugel: 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:16 | kugel | I think there's a dbop clock, I think I'll have a look at that |
| 20:38:33 | domonoky | is someone with knowlegde about rockboxs buffering code here ?? |
| 20:39:01 | funman | I thought about something else by the way |
| 20:39:12 | funman | we should disable dma/sd/dbop/gpio clocks when we don't use them |
| 20:39:31 | funman | for 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:43 | kugel | division ratio => div = 1/(dbop_prediv_sel + 1) |
| 20:40:59 | kugel | as of now it's 1/3 |
| 20:41:01 | domonoky | yes, disabling not used units would probably save a good bit of battery.. but that also can come later. |
| 20:41:48 | domonoky | kugel: if changing the delay, doesnt help. you could also experiment with CGU_DBOP to see if this helps.. |
| 20:41:57 | funman | kugel: you can set the clock source also, i guess now it's pclk, try lowering the divider to 1/2 ? |
| 20:43:04 | kugel | lowering? Doesn't that mean it'll clock higher? |
| 20:43:27 | funman | yes. |
| 20:43:29 | | Join MethoS- [0] (n=clemens@host-091-096-213-140.ewe-ip-backbone.de) |
| 20:43:33 | domonoky | kugel: yes, but you have problems when we lower the main clock, so thats intended.. |
| 20:43:35 | funman | your problem is that pclk was 64MHz and now is 24MHz |
| 20:44:00 | funman | 64/3 == 21, 24/3 == 8MHz , so you want to higher from 8 to 21 until you got lcd display |
| 20:46:07 | kugel | err |
| 20:46:15 | kugel | it's 1/(3+1) as of now |
| 20:46:40 | funman | so, 16. try 24/(1+1) = 12 |
| 20:47:03 | kugel | 1/1+1 worked |
| 20:47:26 | funman | and /(2+1) ? (lower clock == more battery) |
| 20:47:28 | kugel | oops, 1/2+1 I mean |
| 20:47:48 | kugel | (I thought I tried 1, but I did in fact use 2) |
| 20:47:57 | domonoky | and does 1/2+1 also work at 64Mhz ? |
| 20:48:15 | funman | no, the reference clock is 24MHz, so 1/(2+1) => 8MHz |
| 20:48:30 | funman | oh sorry.. I didn't understand what you meant |
| 20:48:54 | funman | but 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:13 | domonoky | it would be good to find a setting which works on wide range of cpu frequencys, remember we want the boost feature later :-) |
| 20:49:14 | amiconn | kugel: ARM mode ORR always has 3 operands. If you see a 2 operand form, it's thumb code |
| 20:49:35 | kugel | amiconn: yea, we already found that out :) |
| 20:49:44 | domonoky | ah, pclock is seperate from the cpu clock of course... |
| 20:51:02 | funman | kugel: thanks for fixing this fuze-specific bug in fuze-specific code </sarcasm> |
| 20:51:43 | kugel | funman: Don't call to early. I'm having problems in the main now |
| 20:52:07 | funman | the same problems, or the kind you have while messing with button code? |
| 20:52:19 | kugel | other problems |
| 20:52:32 | kugel | lcd_update is VERY slow and it doesn't get to the main build |
| 20:52:52 | kugel | I already lowered the delay in lcd_delay from (x*1024) to (x*64) |
| 20:53:05 | funman | try with other peripheral clock dividers then |
| 20:53:09 | kugel | main menu I mean |
| 20:53:28 | funman | if 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:23 | kugel | funman: 1/1 isn't enough |
| 20:55:42 | kugel | lcd_update still noticeably slow, and I still don't get to the main menu |
| 20:55:57 | funman | then use plla source (|0x1 instead of |0x0) |
| 20:56:58 | kugel | funman: ? |
| 20:57:40 | funman | ah you can't set the clock source for cgu_dbop sorry .. |
| 20:57:47 | kugel | yea |
| 20:58:11 | funman | try highering pclk then |
| 20:58:50 | funman | by the way, is 1/1 = 1/(0+1) aka bits 2:0 set to 0 ? |
| 20:59:16 | funman | because 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:05 | kugel | f(clk_dbop) = f(PCLKDBOP) * div; |
| 21:01:34 | funman | sure, but "div = 1/(dbop_prediv_sel +1)" |
| 21:01:37 | | Quit karashata ("G'bye everyone!") |
| 21:02:03 | kugel | how much is PCLKDBOP? |
| 21:02:09 | funman | PCLK i suppose |
| 21:02:33 | funman | 24MHz now, 64MHz last time you had display working in svn |
| 21:04:30 | funman | domonoky: 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:59 | domonoky | hm, that doesnt look good, a negativ buffer cant hold much data :-) |
| 21:07:02 | funman | with panicf() I see a call to buffering_reset(?, -367552) |
| 21:08:44 | * | funman wants a backtrace :( |
| 21:09:29 | funman | by 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:41 | domonoky | which comes from playback.c audio_reset_buffer().. |
| 21:09:43 | funman | and prints the stack pointer, so we can debug offline |
| 21:10:18 | domonoky | funman: sounds like a good debugging method.. |
| 21:10:21 | funman | pcmbuf_init() is called with a pointer to 0x30100000 (1MB of SDRAM) so that part looks correct |
| 21:13:28 | domonoky | hm, 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:42 | bertrik | will we be able to fit everything in 2 MB +300k at all? maybe we need some of the rockbox veterans for advice |
| 21:16:44 | bertrik | (thinking of the clip) |
| 21:17:02 | funman | bertrik: yeah, the clip is the most important, who cares about m200 ? :) |
| 21:17:16 | domonoky | :-) |
| 21:17:31 | funman | note, if the c200 is monochrome, it may have the same amount of RAM |
| 21:18:08 | bertrik | domonoky, 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:40 | saratoga | i saw comments about memory usage |
| 21:18:49 | domonoky | and if i can fit it into the m200v4s memory, also the other targets wont be a problem :-) |
| 21:18:51 | saratoga | if you think you need more, you should shrink the codec buffer to 512KB |
| 21:19:06 | funman | it's already 512KB |
| 21:19:27 | saratoga | oh didn't realize it was already halved |
| 21:19:29 | funman | atm there is 512KB for codecs, 512KB for plugins, ~625KB for rockbox binary |
| 21:19:44 | saratoga | you could probably shrink both it and the plugin buffers quite a lot as well without breaking much |
| 21:20:20 | saratoga | have you enabled IRAM as well? |
| 21:20:21 | gevaerts | If 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:28 | bertrik | funman, does the 625 KB already include the code + variables + stacks? |
| 21:20:41 | gevaerts | Once everything works you can increase them again |
| 21:20:42 | saratoga | i bet MP3 works with 128KB buffer + IRAM |
| 21:20:47 | funman | IRAM is used but only for icode/idata etc segments |
| 21:20:49 | domonoky | hm, pcm_buf init returns that it needs 545k + 32k guard buffers.. :-/ |
| 21:21:08 | funman | shouldn't a check go here? |
| 21:21:16 | kugel | funman: Why don't you try to fix the flash buffering patch? |
| 21:21:18 | domonoky | so we surely have the RAM problem :-) |
| 21:21:21 | funman | I think yes (since it's an init function it's not time critical) |
| 21:21:29 | funman | kugel: because i don't know the code |
| 21:21:42 | kugel | hm, sounds reasonable |
| 21:21:43 | saratoga | kugel: I don't think trying that patch makes much sense now |
| 21:22:06 | saratoga | a port should be working well before you go and change the playback code |
| 21:22:08 | gevaerts | That's buffering. This is pcm_*. I would expect those to be unrelated |
| 21:22:09 | kugel | saratoga: they're running out of memory while buffering. That patch disables buffering |
| 21:22:36 | saratoga | i 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:42 | domonoky | kugel: 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:51 | saratoga | and anyway 2MB of RAM is enough for the current system |
| 21:23:09 | kugel | if plugin buffer is futher reduced yes |
| 21:23:15 | kugel | like the other 2MB targets do |
| 21:23:23 | domonoky | if we really need ~512k only for the pcm buffers we get problems... :-) |
| 21:23:54 | gevaerts | Of course, but do you want to fix that without a working reference? |
| 21:24:14 | funman | what do you think of http://paste.ubuntu.com/78129/ ? |
| 21:24:23 | * | domonoky tries to reduce the plugin buffer... |
| 21:24:43 | kugel | funman: Am I correct? That clock change commit was only for the bootloader? |
| 21:25:08 | funman | kugel: only the bootloader sets it, the main binary doesn't change it |
| 21:25:24 | * | gevaerts likes the "insert meaningful message" :) |
| 21:25:25 | domonoky | funman: :-) would be a good check for svn... programmers never check memory allocations. :-) |
| 21:25:25 | kugel | ok, I thought both do |
| 21:26:26 | saratoga | while I'm here, is anyone that familar with the DBOP control registers? |
| 21:26:29 | funman | I'll try with 256kb plugin & buffer (512kb more for pcm) |
| 21:26:33 | * | bertrik wouldn't mind more assertion checks in rockbox |
| 21:26:38 | funman | *plugin & codec buffer |
| 21:27:04 | funman | gevaerts: well I'm not sure what are the allocations made here, so I guess someone should "insert a meaningful message" ;) |
| 21:28:15 | funman | hum I still get a panic .. let's make clean to be sure the new config has been used |
| 21:28:23 | gevaerts | funman: "Not enough memory for pcmbuf_init()" ? |
| 21:28:50 | saratoga | in 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:08 | saratoga | since the datasheet says write enable is pin 16, but the code sets pin 14 |
| 21:29:08 | kugel | funman: CGU_PERI |= (15<<2)|0x1; /* pclk = PLLA / 6 = 64 MHz works |
| 21:29:10 | domonoky | even better: "Not enough memory for pcmbuf_init() %x %x", requested_size,buffer_size) |
| 21:29:55 | funman | kugel: 384/(15+1) = 24, .. something is definitely wrong here |
| 21:29:56 | gevaerts | I'd write that as "Not enough memory for pcmbuf_init() %x>%x" |
| 21:30:16 | kugel | saratoga: yea, I stumbled up that too. And I did what the data sheet says, and it did not work |
| 21:30:40 | kugel | saratoga: also, the lcd-driver is purely based on disassembly. So I assume it's what the of does |
| 21:30:43 | bertrik | the DRAM segment is only 1MB in the map file, is that correct? |
| 21:31:09 | funman | bertrik: minus plugin & codec buffers, right |
| 21:31:30 | kugel | funman: the difference is that PCLK_SEL is set |
| 21:31:41 | Unhelpful | amiconn: 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:43 | kugel | when I removed that, I had problems |
| 21:31:51 | funman | kugel: I don't understand what you mean |
| 21:32:24 | kugel | funman: the |0x1; part sets PCLK_SEL to plla_fout |
| 21:32:27 | saratoga | kugel: 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:06 | funman | kugel: please calculate what is the resulting pclk frequency with your diff |
| 21:33:10 | kugel | saratoga: maybe the comment is just missleading |
| 21:33:33 | bertrik | audiobuf 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:41 | kugel | funman: you just did? |
| 21:33:58 | kugel | " 384/(15+1) = 24" |
| 21:34:09 | funman | kugel: i just did and it's exactly the same frequency used in svn now. So I may be wrong in my calculus |
| 21:35:00 | kugel | funman: I already told you. SVN doesn't alter PCLK_SEL to plla_fout, but leaves it as clk_main |
| 21:35:14 | kugel | p107, last row in the data sheet |
| 21:35:32 | funman | kugel: sure, clk_main == 24MHz, so PCLK == 24MHz in svn |
| 21:35:40 | funman | same frequency than with your diff |
| 21:35:58 | kugel | no idea then. It just works |
| 21:38:13 | | Quit Zarggg () |
| 21:38:14 | kugel | saratoga: are you a bit disassembly skilled? I have disassembled the OF a bit. It does much more in dbop_init |
| 21:38:38 | kugel | saratoga: 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:31 | kugel | funman: CGU_PERI |= 0x1 rendered my fuze unbootable |
| 21:42:23 | funman | of course, and feel lucky you if didn't brick it |
| 21:42:35 | funman | datasheet mention not using pclk higher than 65MHz |
| 21:42:57 | kugel | funman: it's working |
| 21:43:05 | funman | then feel lucky :) |
| 21:43:14 | | Nick Bensawsome is now known as NinJew (n=Bensawso@unaffiliated/bensawsome) |
| 21:44:01 | kugel | funman: 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:43 | kugel | and the time it needs until then is rather long |
| 21:47:00 | domonoky | kugel: what do you want to enable with this CGU_PERI thing ? |
| 21:47:26 | kugel | !? |
| 21:48:02 | domonoky | ah i missed the pclock devider.. |
| 21:48:08 | kugel | not 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:42 | funman | I 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:51 | funman | and 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:18 | your | sup ladies??? |
| 21:52:32 | your | hu |
| 21:52:51 | | Quit your (Client Quit) |
| 21:53:37 | kugel | funman: 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:31 | funman | kugel: why don't you use no divider in as3525_dbop_init() ? |
| 21:54:39 | kugel | http://pastebin.ca/1270531 |
| 21:54:55 | kugel | funman: I do. 1/1+1 |
| 21:55:05 | funman | What about 1/1+0 ? |
| 21:55:44 | kugel | funman: should work too |
| 21:56:10 | funman | I 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:50 | kugel | funman: lower pclk? 1/16 is lowest |
| 21:58:05 | funman | anyway, please open a FS entry with all the settings you tried |
| 22:00 |
| 22:00:04 | kugel | funman: lowering dbop more isn't good (I have tried), the lcd_update gets noticeable |
| 22:00:34 | funman | write that into the FS entry |
| 22:04:04 | kugel | funman: http://www.rockbox.org/tracker/task/9588 |
| 22:07:35 | domonoky | funman: the reboot seems to happen in codec_load_file() (apps/codecs.c) between the codec_get_full_path and the read call... |
| 22:08:41 | kugel | funman: haha! That happens if you have a "bl-fix-fuze.diff" and "fuze-fix-bl.diff" in the same dir |
| 22:09:25 | funman | domonoky: does open() succeed? |
| 22:09:33 | kugel | domonoky: maybe 256KB is too low? |
| 22:09:34 | domonoky | testing now.. |
| 22:10:17 | domonoky | i have set my plugin buffer to 128 and let the codec buffer be 512k... -> ~32k buffer left after pcm_init |
| 22:10:31 | kugel | hm |
| 22:10:55 | amiconn | A codec buffer of 128KB should be enough for a number of codecs |
| 22:11:17 | amiconn | That'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:54 | domonoky | it seems the reboot happens in the open call.. |
| 22:12:04 | gevaerts | Doesn't that change a bit with the codec buffer/malloc buffer merge, or am I totally wrong? |
| 22:12:33 | | Quit XavierGr () |
| 22:12:47 | funman | domonoky: http://paste.ubuntu.com/78144/ to put the codec buffer into iram |
| 22:12:59 | saratoga | kugel: have you annotated your fuze disassembly at all? |
| 22:13:10 | saratoga | I can take a look at teh function in question |
| 22:13:17 | amiconn | Unhelpful: 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:22 | kugel | saratoga: yea, want to have it? |
| 22:13:39 | kugel | saratoga: I have also linuxstb's, I'll just give you both. |
| 22:14:02 | amiconn | gevaerts: Perhaps, but then only for codecs which use malloc |
| 22:14:11 | Unhelpful | amiconn: 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:36 | amiconn | Does it do scaling for mono output? Dithering? |
| 22:15:00 | funman | it seems rb->sleep() in test_codec sleeps forever |
| 22:15:20 | amiconn | Perhaps we shouldn't say mono == no scaling etc, but rather differentiate by ram amount |
| 22:16:45 | Unhelpful | amiconn: 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:50 | funman | how can sleep(int ticks) mesure elapsed ticks if interrupts are disabled ? |
| 22:18:26 | amiconn | It can't |
| 22:18:36 | amiconn | Interrupt must not be disabled for extended times |
| 22:18:43 | amiconn | *Interrupts |
| 22:19:16 | funman | sleep_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:39 | kugel | funman: comment added |
| 22:23:26 | funman | kugel: 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:32 | kugel | funman: zing |
| 22:29:58 | | Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) |
| 22:30:15 | domonoky | maybe its caused by that this open doesnt come from the main thread.. *speculating* |
| 22:30:47 | funman | this 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:29 | domonoky | you mean the wake_up thing ? |
| 22:31:45 | funman | nope, I understood this part ;) |
| 22:31:58 | funman | I meant sd_thread() |
| 22:32:16 | kugel | funman: I tried various DBOP clock divider without modifying CGU_PERI. all resulted in unacceptable slowness. |
| 22:32:50 | kugel | Plus: I didn't get into the main menu most of the times, e.g. it looped at the (main builds) bootlogo |
| 22:33:11 | funman | kugel: please write that on the patch entry, with the list of frequencies you tried |
| 22:33:37 | funman | and if you didn't get to the main menu, write the result for each frequency you tried |
| 22:34:07 | funman | so at least we can figure which range of frequencies bring which result |
| 22:34:38 | funman | in short: put all the info you have |
| 22:34:55 | domonoky | funman: 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:12 | kugel | funman: did. I listed all clock divider I tried |
| 22:35:23 | domonoky | but also those occasional reboots we get before, seemed to be related to sd-access. |
| 22:35:42 | kugel | funman: *all* divider I tried failed |
| 22:35:45 | funman | do you know in which occasions the CPU can call the reset vector ? |
| 22:35:57 | bertrik | are we sure the thread isn't running out of stack space? |
| 22:35:59 | kugel | including the fastest |
| 22:36:09 | domonoky | nope, i will check the data sheet :-) |
| 22:37:44 | domonoky | does the watchdog run ? |
| 22:39:48 | funman | no |
| 22:39:55 | funman | bertrik: how can we be sure? |
| 22:40:45 | kugel | funman: I answered |
| 22:41:56 | bertrik | funman, 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:07 | funman | for 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:31 | bertrik | The 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:44 | funman | I think so |
| 22:44:55 | kugel | funman: 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:18 | amiconn | hmpf! |
| 22:45:24 | kugel | Also, 1/(15+1) is the lowest divider you can get for pclk |
| 22:45:30 | funman | kugel: you're not very clear. |
| 22:45:34 | * | amiconn doesn't understand why his own c200 build doesn't werk |
| 22:45:43 | funman | I don't know what "modifying CGU_PERI" means for instance |
| 22:46:07 | amiconn | The latest current build is working fine... |
| 22:46:10 | funman | If you said "setting pclk to X MHz" it'd be much more understandable |
| 22:46:13 | kugel | funman: you used that phrase yourself: "without modifying CGU_PERI " |
| 22:46:36 | bertrik | amiconn, maybe run configure and make clean again |
| 22:46:39 | funman | "_without_ modifying" means "use current setting" |
| 22:46:48 | amiconn | I already did that 2 times... |
| 22:46:52 | funman | hm I read with instead of without |
| 22:46:56 | kugel | you said "without modifying CGU_PERI" first, and I throught it refers to past-r19234 |
| 22:46:58 | amiconn | All other builds work, just c200 doesn't |
| 22:47:44 | funman | kugel: 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:08 | kugel | funman: yes |
| 22:48:28 | funman | and 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:01 | funman | to sum it up, I want a table of pclk frequencies and dbop clock frequencies, associated with the state of the lcd driver |
| 22:49:17 | kugel | funman: that's with having the CGU_PERI line removed, isn't it? |
| 22:49:49 | funman | no .. |
| 22:49:55 | kugel | funman: then you mean r19233 I guess? |
| 22:50:11 | funman | yes |
| 22:50:12 | kugel | since 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:09 | kugel | funman: One question though: Why testing all that stuff? We cannot get lower pclk |
| 22:51:31 | funman | to understand what we change |
| 22:51:56 | funman | and not blindly commit the first line which 'just works' |
| 22:52:54 | funman | we 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:51 | funman | perhaps the PLLA setting is wrong, like what I saw in the OF suggested |
| 22:54:04 | kugel | funman: haha not again you mean? :) |
| 22:54:12 | funman | what again? |
| 22:54:40 | kugel | nevermind |
| 22:55:13 | bertrik | funman, maybe it has to do with the cpu/apb synchronisation setting |
| 22:55:36 | funman | in 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:06 | funman | bertrik: you mean asynchronous clock setting in cp15 config register? |
| 22:56:38 | | Quit saratoga ("CGI:IRC (EOF)") |
| 22:56:41 | bertrik | yes |
| 23:00 |
| 23:04:09 | kugel | funman: comment added |
| 23:06:14 | funman | in 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:14 | kugel | I 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:06 | funman | domonoky: of course since high scores reading/writing in games works |
| 23:08:29 | funman | perhaps the hardware itself causes the reset? |
| 23:08:58 | domonoky | funman: normal plugins dont use threads, and run in the main-thread... |
| 23:09:04 | funman | ah ok |
| 23:11:01 | funman | damned |
| 23:11:21 | funman | the datasheet uses a different bit order : OD0=x OD1=y |
| 23:13:12 | funman | still, I get a value 2 times lower than what the OF lists |
| 23:13:27 | funman | (now it's consistent for all the values listed at least) |
| 23:14:05 | kugel | funman: different bit order? endianess? |
| 23:14:59 | funman | endianess is about byte order |
| 23:15:17 | kugel | yea, and 8bits are 1byte :P |
| 23:15:18 | funman | they just use a not logical bit order to display the information |
| 23:15:28 | funman | and I read too quickly without noticing this |
| 23:15:47 | kugel | good you noticed now I suppose |
| 23:18:08 | funman | now that I fixed another bug in my code, the settings I find in the OF are correct |
| 23:18:41 | funman | These 2 bugs cancelled each other, and the plla frequency remains correct (384MHz) |
| 23:19:15 | funman | BUT the setting is incorrect according to the datasheet (fvco > 400MHz) |
| 23:23:04 | kugel | funman: what to do about the CGU_PERI line? |
| 23:23:11 | kugel | (just read your answer) |
| 23:23:52 | funman | modify it, note results |
| 23:23:58 | | Quit BigBambi_ (Read error: 54 (Connection reset by peer)) |
| 23:24:26 | kugel | funman: and (15<<2) still gives 24MHz? |
| 23:24:26 | | Quit Self-Perfection (Read error: 104 (Connection reset by peer)) |
| 23:24:37 | funman | now clip bootloader fails (no display) with CGU_PLLA = 0x2630 :/ |
| 23:24:38 | kugel | I suppose yes |
| 23:25:03 | funman | kugel: (15<<2) = 60 |
| 23:25:35 | kugel | funman: I mean as divider |
| 23:25:45 | kugel | as in 1/(15+1) |
| 23:25:55 | funman | kugel: be explicit, i'm not reading your mind ! |
| 23:26:23 | kugel | I thought it was obvious that I was referring to the CGU_PERI line, sorry |
| 23:26:36 | funman | the 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:37 | amiconn | haha |
| 23:31:15 | kugel | funman: yea, I wondered about that too |
| 23:31:42 | funman | kugel: 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:00 | kugel | funman: I guess that line should move after the #else |
| 23:33:41 | funman | at the end of the function is fine, and boosting the CPU in the bootloader is fine too |
| 23:35:30 | funman | hm it's useless, SD is slowed down by the peripheral clock onyl |
| 23:36:19 | kugel | funman: does your clip boot now with the changed CGU_PLLA ? |
| 23:36:23 | funman | no |
| 23:36:36 | funman | like I mentioned at 23:24 |
| 23:36:41 | domonoky | funman: something is strange. i can not shutdown my m200v4 anymore, it just starts up again.. :-) |
| 23:36:51 | kugel | funman: yea, I just thought you might have resolved that already |
| 23:36:52 | funman | domonoky: hm even with hardware power off? |
| 23:37:10 | domonoky | yes.. :-) |
| 23:37:12 | kugel | domonoky: somthing which I also noticed a few times |
| 23:37:19 | kugel | uh, not that |
| 23:38:39 | kugel | funman: white display here |
| 23:39:51 | kugel | funman: oops wait |
| 23:42:06 | kugel | funman: I see the bootlogo. The logo is fine, but not the text which states the revision. And it hangs at the bootloader |
| 23:42:20 | kugel | (the text is rather poxel garbage) |
| 23:42:34 | funman | on my side I can boot with a cpu at 215MHz, but not with a cpu at 220MHz |
| 23:42:46 | kugel | now 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:05 | kugel | funman: What do I need to change? |
| 23:44:14 | funman | kugel: ? |
| 23:44:19 | kugel | I see CGU_PROC is already at the lowest divider |
| 23:44:33 | kugel | what do I need to change to test that too |
| 23:44:34 | funman | you seem to forget there is 2 dividers in cgu_proc |
| 23:44:39 | skiy | Hi 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:40 | kugel | sorry, the sentence got cut :/ |
| 23:44:50 | funman | just read the datasheet, i have no more information than you on this topic |
| 23:45:02 | kugel | funman: ah right, postdiv and prediv |
| 23:46:37 | skiy | I 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:26 | scorche|sh | "starting to give out"? |
| 23:47:47 | kugel | funman: how did you get to 220? |
| 23:48:08 | kugel | 384*7/8*1/(1+1) is already lower |
| 23:48:20 | funman | 352MHz plla |
| 23:49:38 | skiy | hi scorche|sh I think this indicates hardware problems :( :- FAT: Corrupted directory (i_pos 1104557790) |
| 23:50:25 | kugel | funman: which GGU_PLLA= did you use? I don't get what do put there by reading the datasheet |
| 23:50:48 | domonoky | skiy: run a checkdisk or fsch.vat on you player, and see what it finds.. |
| 23:51:10 | domonoky | s/fsch.vat/fsck.vfat/ |
| 23:51:19 | skiy | thank you domonoky I will let you know what it finds |
| 23:52:00 | amiconn | Hmm, 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:03 | funman | kugel: look page 103 |
| 23:52:22 | amiconn | *after displaying the logo |
| 23:52:34 | kugel | funman: ah lol, I only scrolled back to page 1004 |
| 23:52:36 | kugel | 104 |
| 23:52:42 | funman | I use http://paste.ubuntu.com/78168/ to verify settings |
| 23:53:21 | funman | good night sweet princes |
| 23:53:23 | | Quit funman ("leaving") |
| 23:54:02 | *** | Saving seen data "./dancer.seen" |
| 23:55:03 | kugel | err, 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:20 | kugel | lol, I have it! Sucking pastebins insert CRLFs |
| 23:57:24 | | Join tical2k [0] (n=lihduebl@97.81.214.168) |
icon identifies that the person is a core developer (has commit access).