00:00:03 | kugel | no |
00:00:54 | kugel | I also can't explain that. The only time I noticed a that slow UI on other targets was with caches disabled on my fuze, but you said they're definitely on |
00:02:12 | | Join elinenbe [0] (n=elinenbe@pool-173-77-17-158.nycmny.east.verizon.net) |
00:02:23 | * | TheSeven experiencing PLL corruption |
00:03:05 | TheSeven | CLKCON and PLL0PMS seem to be garbled up sometimes during boosting |
00:03:12 | kugel | maybe you can implement led() (so that the disk access icon appears in the statusbar) to exclude excessive storage accesses |
00:03:17 | TheSeven | maybe we need to ramp Vcore a little? :-P |
00:03:18 | | Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) |
00:04:00 | | Join elinenbe__ [0] (n=elinenbe@207-237-212-81.c3-0.80w-ubr4.nyr-80w.ny.cable.rcn.com) |
00:04:08 | | Quit elinenbe_ (Read error: 113 (No route to host)) |
00:04:09 | | Nick elinenbe__ is now known as elinenbe_ (n=elinenbe@207-237-212-81.c3-0.80w-ubr4.nyr-80w.ny.cable.rcn.com) |
00:05:32 | JdGordon| | TheSeven: slow ui scrolling could be slow lcd driver? or slow disk if it has to keep swapping out font glyphs? |
00:06:18 | TheSeven | JdGordon|: LCD is ~80-100FPS fullscreen RGB |
00:06:26 | TheSeven | quarter screen was around 300 |
00:06:39 | JdGordon| | its not that then :) |
00:06:51 | kugel | the font idea is good one, in fact that was another time I noticed slowish UI (I forget, some versions of the anti-aliased font patch caused huge slowdowns) |
00:06:53 | TheSeven | how big is that glyph cache? |
00:07:01 | TheSeven | storage is really a bottleneck on that one |
00:07:04 | JdGordon| | 100K i tinhk |
00:07:20 | JdGordon| | shuold be plenty big enough if your filenes are all english |
00:07:26 | JdGordon| | dircache enabled? |
00:07:37 | TheSeven | dircache doesn't seem to make any difference |
00:07:53 | TheSeven | (at least in the file browser) |
00:08:03 | TheSeven | but the plugin menu behaved very weird with dircache |
00:08:38 | | Quit bmbl ("Bye!") |
00:13:50 | kugel | still? |
00:16:16 | TheSeven | in fact the dircache slowed scrolling down as soon as i scrolled to regions where i hadn't been before |
00:16:23 | TheSeven | with dircache disabled, it's all fast |
00:16:42 | TheSeven | (well, as fast as the file browser at least) |
00:17:05 | kugel | I didn't have dirache on when I played around |
00:17:45 | TheSeven | well, with dircache on it was like half a second for every scrolling step |
00:18:10 | kugel | uh, that's really bad |
00:18:36 | kugel | it seems accessing ram is slow |
00:19:45 | TheSeven | no, accessing flash |
00:20:05 | kugel | well, you don't access flash if you have dircache on |
00:20:07 | TheSeven | or maybe non-builtin strings |
00:20:25 | TheSeven | all the builtin menus are just fine |
00:20:47 | kugel | dircache contains every entry (file and dirs), and is build during boot |
00:20:58 | * | kugel still suspects some cache problem |
00:21:01 | | Join Sean [0] (n=63046afd@giant.haxx.se) |
00:21:29 | TheSeven | yes, i saw some splashf flash very briefly during boot |
00:21:29 | Sean | hello? |
00:21:30 | | Nick Sean is now known as Guest24033 (n=63046afd@giant.haxx.se) |
00:21:31 | TheSeven | flash read is at ~1MB/s, which is quite bad, but sufficient |
00:21:40 | | Join jdii [0] (n=none@cpe-66-69-20-107.satx.res.rr.com) |
00:22:23 | TheSeven | so it's non-builtin strings? how can that happen? |
00:22:33 | kugel | so unless you actually access the content of files, you never actually hit the storage |
00:23:38 | kugel | i really recommend implementing the disk access indicator |
00:23:55 | TheSeven | how do i do that from the storage side? |
00:24:35 | | Quit elinenbe (Read error: 113 (No route to host)) |
00:24:45 | TheSeven | hmm there is a weird stub |
00:24:51 | TheSeven | void nand_led(bool onoff) { led(onoff); } |
00:25:03 | pixelma | Guest24033: just ask your question (if it is Rockbox related) |
00:25:08 | * | TheSeven wonders what nand_led is good for then |
00:26:06 | | Quit Utchybann ("I like core dumps") |
00:26:26 | TheSeven | hmm that thing is just unused crap. no idea where it comes from. |
00:28:11 | | Join datty [0] (n=datty@ip68-8-46-165.sd.sd.cox.net) |
00:28:21 | datty | rock that box |
00:28:30 | datty | rock it!@ |
00:29:37 | Torne | yeah we'll get right on that |
00:30:14 | TheSeven | kugel: ok, found something interesting |
00:30:50 | TheSeven | the database top-level menu, where the submenus "Artist", "Album", "Genre", ... are, is also sluggish, but not other builtin menus like the main menu |
00:30:54 | | Join nugged [0] (n=4e98a142@giant.haxx.se) |
00:31:41 | | Quit sbhsu (Read error: 110 (Connection timed out)) |
00:31:41 | TheSeven | and that sluggishness is hardly related to the size of the list to scroll |
00:33:40 | Guest24033 | I got one question about the v2 AMS series sansa, it says no usb support for it, does that mean i won't be able to sync music to it through usb or something else? |
00:33:41 | datty | i would like to get into this dev stuff for my Fuze |
00:33:49 | TheSeven | neither does the length of the text nor the type of the line selector have any influence |
00:33:58 | datty | I have some experience with AVR/PIC stuff, is it pretty similar with ARM? |
00:34:28 | TheSeven | datty: ARM is more like a desktop CPU compared to those microcontrollers, but of course, the basics are the same |
00:34:37 | Torne | datty: a little. Almost all of rockbox is written in C, though, so the low level details of architecture are not too important for most things |
00:34:52 | datty | i do prefer C over asm anyday |
00:35:30 | Torne | if you can program in C and are familiar with concepts like memory mapped devices that's more or less all you need |
00:35:47 | TheSeven | kugel: interesting... runtime-generated debug menu contents aren't sluggish either |
00:35:53 | Torne | actually knowing arm/m68k/coldfire is not important unless you end up in very specific parts of the code |
00:35:54 | | Quit nugged ("CGI:IRC (Ping timeout)") |
00:36:05 | datty | interesting |
00:36:06 | | Quit Guest24033 ("CGI:IRC (EOF)") |
00:36:07 | gevaerts | Guest24033: it means you have to reboot to the original firmware for USB |
00:36:40 | datty | i am used to AVR Studio and MPLAB, is there something similar with this? |
00:37:12 | Torne | No |
00:37:15 | datty | I see "get the source, build, and change (patch)" |
00:37:28 | Torne | Yes. You can use any editor/IDE you like.. |
00:37:56 | Torne | but a fully integrated system like AVR Studio is not really possible on platforms like DAPs where you have no code download or debug facilities |
00:37:59 | datty | i guess i mean more for in circuit debugging, is this even possible? |
00:38:03 | TheSeven | datty: but of course the funny part is that there is no proper on-target debugging functionality :-) |
00:38:10 | Torne | No, we basically have no on-target debugging |
00:38:12 | datty | oooh |
00:38:18 | Torne | A few platforms have a JTAG port, if you rip them open |
00:38:26 | Torne | and solder stuff tot he right place. |
00:38:27 | datty | then that makes things more difficult ;) |
00:38:30 | Torne | but most don't. |
00:38:39 | TheSeven | well, we have basic things like a log ring buffer, but nothing you could really call a debugger |
00:38:59 | Torne | datty: there's various ways of logging debug messages, either to a buffer or over serial/usb, depending on hardware |
00:39:06 | Torne | but that's basically all you get. no ICE/ICD |
00:39:28 | datty | hm |
00:39:39 | TheSeven | if we had ICD and proper datasheets, all those targets would be implemented in no time :-) |
00:39:43 | datty | I'm interested in somehow interfacing directly with the ARM, has anyone tried that |
00:39:50 | Torne | define "interfacing directly" |
00:39:56 | datty | TheSeven: yeah thats why I got interested ! |
00:39:58 | Torne | you mean with your mind, or what? :) |
00:40:09 | datty | i was thinkin man whats takin so long :) |
00:40:20 | datty | but yea its much harder |
00:40:25 | datty | interfacing directly with the pins |
00:40:32 | Torne | datty: yeah, all our porting is done based on what little docs are published, and on reverse engineering the orignal firmware, and general guessing :) |
00:40:36 | Torne | datty: er, to do what? |
00:40:44 | Torne | We're already running code on the chip |
00:40:49 | Torne | you can't really get more direct than that |
00:41:14 | datty | yea but i'm sure that ARM has a program for in circuit debugging, no? |
00:41:29 | datty | maybe my questions don't make sense, i've never worked on a device like this |
00:41:32 | Torne | ARMs are not sepearate chips |
00:41:34 | datty | so keep that in mind |
00:41:42 | Torne | They are synthesized into the middle of a system-on-chip |
00:41:46 | Torne | with peripherals and so on on the same die. |
00:41:57 | Torne | If the JTAG pins are not brought out onto the SoC's pins there's nothing you can do |
00:42:06 | TheSeven | datty: ARM maybe has, but this doesn't mean it's accessible anywhere on the board or even SOC package, and sometimes those things are even fused out during production |
00:42:07 | Torne | or equally, if they are brought out but not connected to tracks |
00:42:19 | Torne | and yes, sometimes they get disabled in the factory with efuses |
00:42:25 | datty | i see |
00:42:40 | datty | but ARM922TDMI is a separate chip right |
00:42:42 | Torne | No |
00:42:46 | Torne | There is no such thing as an ARM chip |
00:42:56 | Torne | They haven't made physical ARm processors for over a decade |
00:43:06 | TheSeven | Torne: or that funny thing we found on the nano2g, that the data bus shuts down until reset with the first jtag clock edge to prevent you from dumping the bootrom :-) |
00:43:26 | TheSeven | i bet there is a secret way to bypass this, but only apple knows how. |
00:43:35 | datty | apple?? |
00:43:43 | datty | o nano |
00:43:56 | Torne | datty: All ARM processors on hardware made since the mid-90s are just a macrocell inside a larger ASIC |
00:43:59 | TheSeven | well, probably apple, arm and samsung, in fact |
00:44:07 | Torne | datty: look up System-on-Chip on wikipedia :) |
00:44:14 | Torne | TheSeven: ARM are unlkely to know :) |
00:44:28 | Torne | they stay out of SoC vendors' business :) |
00:44:42 | datty | Torne: Ahhhh |
00:44:45 | datty | wikipedia is your friend |
00:45:13 | datty | so the SOC on the Fuze is proprietary SanDisk stuff? |
00:45:25 | Torne | No, it's a SoC mad by Austria Micro Systems |
00:45:32 | Torne | Hence AMS Sansa |
00:45:41 | datty | k |
00:45:41 | Torne | The DAP manufacturers don't generally design their own SoCs |
00:45:51 | Torne | but there are a dozen or more ARM SoC vendors |
00:46:02 | TheSeven | well, besides apple which seems to never have used a stock soc :-) |
00:46:07 | Torne | ARM only sell the intellectual property |
00:46:20 | Torne | (and their build/debug/simulation tools) |
00:46:25 | | Quit LambdaCalculus37 (Read error: 145 (Connection timed out)) |
00:46:51 | datty | so i assume it's been looked into all methods of interfacing with the SOC besides the normal USB use? |
00:47:12 | Torne | People have generally looked for anything that's plausibly a JTAG port on our targets, yes |
00:47:16 | Torne | there's not really any method other than JTAG :) |
00:47:29 | Torne | there are a few with a known or suspected JTAG port. |
00:47:30 | datty | im curious how old are you people |
00:48:10 | Torne | 26, but if you wanna hang out and chat go to #rockbox-community :) |
00:48:12 | TheSeven | well, how old are you? I'm 19 years... |
00:48:28 | datty | i'm still a senior in undergrad so i have some exposure to this stuff but very limited |
00:48:49 | datty | oh ha not for a social reason just to get an idea of your knowledge-to-age ratio of sorts |
00:49:11 | datty | for example JTAG to me reminds me of the cable we used to program a Xilinx FPGA in one of my classes |
00:49:30 | Torne | datty: #rockbox is logged for people to review/search later, so we try to keep it to on-topic technical discussion |
00:49:32 | TheSeven | ...which isn't really rockbox-related, hence the link to #rockbox-community |
00:50:01 | datty | o ok sorry bout that |
00:50:04 | | Quit gevaerts (Read error: 60 (Operation timed out)) |
00:51:09 | TheSeven | kugel: still around? |
00:51:11 | *** | Saving seen data "./dancer.seen" |
00:51:20 | TheSeven | or anybody else who knows how UI drawing works? |
00:51:26 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
00:51:48 | * | JdGordon| is |
00:52:17 | datty | so is a JTAG "port" for the Fuze the equivalent to the Xilinx EDK/ISE I used to interface using JTAG to the FPGA? |
00:52:33 | datty | nm i'm in the other room |
00:52:37 | | Part datty |
00:52:39 | TheSeven | do you have any explanation as to why scrolling in the top-level database menu where you can select "artist", "album" etc. could be far slower than e.g. the main menu? |
00:53:12 | | Part toffe82 |
00:54:05 | JdGordon| | you mean verticle scrolling right? |
00:54:36 | JdGordon| | hang on... is the top level one any slower than going into any of the sub items? |
00:54:50 | kugel | TheSeven: all menu use the same code basis |
00:55:04 | JdGordon| | the database is not the menu :) |
00:55:21 | JdGordon| | it uses tagtree which i have no idea how it popuilates the list |
00:55:25 | TheSeven | no, it seems to be everything that contains runtime-generated strings, but for some reason also the database top-level menu |
00:55:48 | JdGordon| | runtime generated meaning translated? or? |
00:56:14 | TheSeven | things like the main or debug menu are fast, things like the file browser are slow |
00:56:19 | TheSeven | (but not accessing the disk) |
00:56:58 | | Join uflops [0] (n=yogurt@90-231-195-226-no112.tbcn.telia.com) |
00:57:32 | JdGordon| | what about inside settings? like the volume selection list? |
00:57:39 | TheSeven | these are all fine |
00:57:51 | * | TheSeven suspects it's scrollable vs. nonscrollable in face |
00:57:53 | TheSeven | fact* |
00:58:07 | JdGordon| | ? |
00:58:16 | TheSeven | (scrollable in terms of horizontal here) |
00:58:37 | JdGordon| | is there something wrong with your thread switching code maybe? |
00:58:54 | TheSeven | i don't think so, that's generic arm code, but of course it causes icache misses |
00:59:54 | JdGordon| | very curious indeed :p |
01:00 |
01:00:02 | TheSeven | hmm, no, there are horizontally scrolling menus, too, which are also fast |
01:01:15 | JdGordon| | the problem is slow resposne going up and down though? no problems if you arnt moving the selection? |
01:01:53 | TheSeven | well, if i aren't moving the selection there's nothing to judge on |
01:02:26 | TheSeven | but if you mean that i stay inside the visible range so that it doesn't need to scroll, that doesn't help |
01:02:44 | TheSeven | it even happens with menus that don't have enough entries to scroll at all, but in theory could have more |
01:03:32 | | Quit StealthyXIIGer (Read error: 110 (Connection timed out)) |
01:03:46 | | Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) |
01:04:22 | JdGordon| | yeah, I have no idea... I was going to suggest that the button driver is sending too many scroll events, but that doesnt make sense either |
01:05:34 | | Quit GeekShadow (Read error: 104 (Connection reset by peer)) |
01:10:44 | | Join adiroiban [0] (n=adiroiba@h194-54-129-79.teleson.ro) |
01:11:22 | | Quit mikroflops (Read error: 110 (Connection timed out)) |
01:13:35 | | Join faemir [0] (n=faemir@78.33.109.163) |
01:17:19 | | Quit jdii (Read error: 110 (Connection timed out)) |
01:18:25 | | Join sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) |
01:18:45 | kugel | TheSeven: the top level database menu is also generated at runtime, it can be customized using a tagnavi.config file |
01:19:17 | kugel | well, everything is generated at runtime, due to localization, but this seems to be different it seems |
01:19:38 | | Join DerPapst [0] (n=DerPapst@p4FE8F220.dip.t-dialin.net) |
01:19:59 | TheSeven | localization seems to be done through some language database behind the id-based strings |
01:20:06 | TheSeven | the pointer-based strings seem to be the issue |
01:21:18 | kugel | you could try if the "Load to RAM" option in the database settings makes things better or worse |
01:21:32 | TheSeven | doesn't seem to change anything |
01:29:26 | | Quit robin0800 (Read error: 110 (Connection timed out)) |
01:31:17 | TheSeven | bertrik: I have absolutely click-free sound now without pcmbuf changes :-) |
01:43:29 | kugel | how? :) |
01:43:50 | | Join Sajber^ [0] (n=Sajber@c-d73471d5.012-155-73746f22.cust.bredbandsbolaget.se) |
01:44:12 | TheSeven | kugel: by splitting the pcmbuf's packets into smaller ones again |
01:44:29 | TheSeven | and an extremely streamlined FIQ handler |
01:44:41 | | Quit Sajber^ (Read error: 104 (Connection reset by peer)) |
01:44:47 | kugel | sounds good |
01:45:53 | | Join Sajber^ [0] (n=Sajber@c-d73471d5.012-155-73746f22.cust.bredbandsbolaget.se) |
01:47:40 | CIA-85 | New commit by theseven (r23324): Finally a click, pop and other distortion free PCM driver for that fishy bufferless S5L870x I2S controller. |
01:48:18 | TheSeven | this one took far too long. I should have went into that direction from the start |
01:50:34 | CIA-85 | New commit by theseven (r23325): Implement iPod Nano 2G storage active indicator |
01:50:56 | bertrik | TheSeven, looks quite hacky .... |
01:51:11 | | Quit bertrik ("zZz") |
01:52:02 | TheSeven | yes, it *IS* hacky, but it at least works finally |
01:52:20 | TheSeven | I guess I'll need to spend a few more comments there... |
01:53:52 | TheSeven | WTF, why does the bootloader link PCM!? |
01:54:36 | TheSeven | oh, funny way how these references sneaked in |
01:58:09 | | Quit Sajber^ ("Leaving.") |
01:58:55 | CIA-85 | New commit by theseven (r23326): Fix red |
02:00 |
02:00:28 | TheSeven | does anybody have an idea how to get rid of that yellow? |
02:00:58 | TheSeven | it's just a "warning: ‘dma_callback’ defined but not used", which is in fact used from ASM |
02:05:15 | CIA-85 | New commit by theseven (r23327): Hide yellow |
02:06:18 | | Join Sajber^ [0] (n=Sajber@c-d73471d5.012-155-73746f22.cust.bredbandsbolaget.se) |
02:08:10 | kugel | TheSeven: (void)dma_callback? |
02:08:22 | TheSeven | it's a function |
02:08:35 | TheSeven | but __attribute__((unused)) did the trick |
02:09:01 | kugel | you can also un-static it |
02:09:24 | TheSeven | well, it's local to that file, and has an ambiguous name in other contexts |
02:09:35 | kugel | interesting that gcc doesn't see it |
02:09:47 | TheSeven | gcc can't see it, as it's inline ASM |
02:09:51 | kugel | TheSeven: ______dma__callback then :D |
02:10:31 | TheSeven | ok, nice and green again |
02:11:18 | kugel | __attribute__((unused)) is probably the best way. in fact, I would like to see that used more instead of (void)foo all over the place |
02:11:50 | TheSeven | even though it's a little misleading, as it is in fact used :-) |
02:12:29 | TheSeven | ok, that was the last issue stopping us from boosting! |
02:14:13 | kugel | you could've also passed dma_callback as "parameter" the inline asm right? |
02:14:30 | TheSeven | my nano is just playing fine with an average ADC reading of 16mA, which is probably too high, as both the ADC and CPU are consuming more power than usual while the measurements are being done |
02:14:43 | | Quit killan (Read error: 104 (Connection reset by peer)) |
02:14:48 | TheSeven | kugel: yes, I could have voided it in there :-) |
02:16:17 | TheSeven | so we probably already exceed apple's battery life! |
02:16:55 | TheSeven | I'll drop a patch for that into flyspray and then go to bed |
02:17:43 | kugel | I mean like "ldrne r0, %[p]"...: [p]"r"(dma_callback)", but anyway |
02:18:06 | kugel | TheSeven: what do you mean by boosting, weren't you running at 192 already all the time? |
02:19:50 | | Join killan [0] (n=nnscript@c-0efa70d5.06-397-67626721.cust.bredbandsbolaget.se) |
02:20:55 | TheSeven | i mean going down to 47923200 and boosting only when neccessary |
02:21:03 | TheSeven | gets us 8mA! |
02:21:17 | | Join peter__b [0] (n=peter_b@93.133.196.22) |
02:21:19 | | Join Blue_Dude [0] (n=chatzill@rockbox/developer/Blue-Dude) |
02:21:52 | Blue_Dude | TheSeven: you got it to work? Awesome! What did the trick? |
02:22:05 | TheSeven | splitting down the buffers even further |
02:22:21 | TheSeven | i couldn't use your idea because the PCM api in between wouldn't have let me |
02:22:34 | TheSeven | we always forget that there are also other audio sources than pcmbuf :-) |
02:22:54 | Blue_Dude | Whatever works. That's great. |
02:23:16 | TheSeven | right now, if i get passed a buffer that's at least 2048 bytes, i'll split off the last 1024 bytes |
02:23:28 | | Join Feanor_ [0] (n=Feanor_@84.164.49.126) |
02:23:36 | Blue_Dude | It's probably also a lot cleaner than hacking up pcmbuf for a single target. |
02:23:59 | TheSeven | this buffer will be requested while the last 1024 bytes of the buffer before are playing, and it will be started as soon as these are done |
02:24:25 | TheSeven | when the next DMA int comes in, i still have 1024 bytes which i can throw into the dma, while requesting the next one, and so on |
02:24:34 | Blue_Dude | So you roll your own prebuffer while callback is running. That's nifty. |
02:24:42 | TheSeven | and i doubt any codec will ever be able to overwrite these 1024 bytes fast enough... |
02:25:24 | TheSeven | (and even if it would, this would just end up in dcache and not hurt the DMA) |
02:26:37 | TheSeven | and of course the other part of that trick is an ASM FIQ handler that will setup the next DMA transfer within 4 instructions no matter what's going on |
02:27:19 | Blue_Dude | I dug some more into the low level pcm drivers this afternoon and I think it might have been possible to hack pcmbuf, but it wouldn't have been pretty. Doing it within your own black box is better though. |
02:27:47 | TheSeven | the only case that can hurt is if there are chunks < 2048 bytes, as these will be directly used as the "tail buffers", so the next one will be requested immediately, which may lead to codecs overwriting them ahead of time again, but this could possibly still be caught by dcache |
02:28:11 | | Quit DerPapst ("Leaving.") |
02:28:14 | TheSeven | (which is 4KB on that target) |
02:28:37 | Blue_Dude | What happens when the codec stops feeding data at the end of the playlist? You will get the tail end then. However, the codec won't be overwriting either. |
02:29:55 | | Quit peter-b (Read error: 145 (Connection timed out)) |
02:30:02 | TheSeven | this will just mean that the pcmbuf can't supply data while I'm playing the tail, so it will not schedule a new buffer for pushing to the dma, and as soon as the DMA of the tail finishes, it will realize there is nothing more to do and call that stop callback |
02:31:07 | TheSeven | linuxstb: we seem to have reached apple's battery runtime with some tricks :-) |
02:31:07 | Blue_Dude | OK, just so long as your prebuffer doesn't choke on a smaller than expected payload. That's just details though. Congratulations. |
02:31:27 | linuxstb | TheSeven: Nice. Is battery_bench working now? |
02:31:44 | TheSeven | linuxstb: it's failing every night because of a new reason |
02:32:06 | TheSeven | Blue_Dude: it shouldn't choke on that, as it's able to chain tails directly if they're too small to split them |
02:33:00 | Blue_Dude | TheSeven: that's excellent. |
02:33:06 | TheSeven | this ranges from FTL problems to stack overflows to whatever |
02:33:24 | TheSeven | I won't do it tonight because my battery isn't really full right now |
02:33:42 | TheSeven | but i'll post the patch to flyspray right away |
02:43:22 | TheSeven | FS #10714 |
02:44:33 | TheSeven | Blue_Dude: BTW I spotted two things that look like bugs in pcmbuf: |
02:45:37 | TheSeven | line 1029: The actual buffer usage is higher than that, as some date (which isn't included in that value) may still be playing |
02:45:48 | Blue_Dude | TheSeven: that doesn't surprise me at all. |
02:46:08 | TheSeven | and line 1041: I don't see what this is supposed to do. Looks like someone copy-pasted something in the wrong place. |
02:46:31 | TheSeven | why for heaven's sake does it divide a percentage value by pcmbuf_unplayed_bytes? |
02:47:00 | TheSeven | shouldn't that be pcmbuf_size? |
02:47:01 | Blue_Dude | re line 1029: that's pretty approximate because it doesn't include pcm_unplayed_bytes or whatever it is from pcm.c |
02:48:49 | Blue_Dude | re line 1041: you're probably right. I'm not 100% sure where those functions are called from, but they smell like debug screen info to me |
02:49:14 | | Quit Rondom (Nick collision from services.) |
02:49:25 | | Join Rondom [0] (n=Rondom@dslb-084-057-142-148.pools.arcor-ip.net) |
02:51:12 | *** | Saving seen data "./dancer.seen" |
02:53:42 | Blue_Dude | re line 1029: the problem is that pcmbuf_unplayed_bytes is decremented as soon as the chunk is sent to the DMA, not when it's played. If you want to be really accurate, you'd have to keep add last_chunksize to pcmbuf_unplayed_bytes. That assumes that the entire chunk is off limits whether part of it has been played or not, which is safest. |
02:54:22 | TheSeven | depends on what this function is good for |
02:54:52 | TheSeven | this could either be space used in terms of allocated/locked, or in terms of data being in the buffer ready to be retrieved |
02:54:59 | Blue_Dude | As I said, it smells like howgozit info vs. operational necessity. |
02:55:37 | Blue_Dude | If you're looking for free buffer space, you have to assume that the currently playing chunk is not free though. |
02:55:37 | TheSeven | btw, that pcmbuf_mix_free is only used by pcmbuf itself |
02:55:52 | Blue_Dude | Figures. |
02:56:26 | TheSeven | the same is true for the other one |
02:56:43 | TheSeven | and it's both on line 882 |
02:56:57 | TheSeven | "A get-it-to-work-for-now hack" :-) |
02:57:05 | Blue_Dude | I have been poking around in pcmbuf and playback for a few weeks with an eye towards tightening them up. |
02:57:15 | Blue_Dude | Yeah, that's right. :) |
02:57:34 | Blue_Dude | So some of this stuff may not last the winter. |
02:58:09 | | Quit liar (Read error: 148 (No route to host)) |
02:58:45 | * | TheSeven will go to bed now and continue to poke on this "sluggish UI" issue tomorrow |
02:59:14 | Blue_Dude | It's not just you. The UI really started to drag a few weeks back. |
02:59:45 | Blue_Dude | I've got to go pack. Back next week. Enjoy! |
03:00 |
03:00:50 | Blue_Dude | Oh yeah. Line 882: voice buffer stuff. That will be broken out. |
03:02:49 | | Quit Sajber^ (Read error: 104 (Connection reset by peer)) |
03:03:37 | | Quit uflops (Remote closed the connection) |
03:03:45 | | Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]") |
03:04:30 | | Quit froggyman () |
03:05:36 | | Quit amiconn (Nick collision from services.) |
03:05:39 | | Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) |
03:05:58 | | Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) |
03:07:31 | | Join mikroflops [0] (n=yogurt@90-231-195-226-no112.tbcn.telia.com) |
03:08:05 | | Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) |
03:08:05 | | Quit pixelma (Nick collision from services.) |
03:08:24 | | Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) |
03:09:58 | | Quit mikroflops (Remote closed the connection) |
03:10:33 | | Join mikroflops [0] (n=yogurt@90-231-195-226-no112.tbcn.telia.com) |
03:14:08 | | Quit Feanor_ (Remote closed the connection) |
03:17:39 | | Quit mikroflops (Remote closed the connection) |
03:22:18 | | Join mikroflops [0] (n=yogurt@90-231-195-226-no112.tbcn.telia.com) |
03:23:15 | | Join Guest61935 [0] (n=petur@ip67-152-80-229.z80-152-67.customer.algx.net) |
03:23:15 | | Quit Guest61935 (Client Quit) |
03:28:48 | | Join uflops [0] (n=yogurt@90-231-195-226-no112.tbcn.telia.com) |
03:30:18 | | Quit mikroflops (Read error: 54 (Connection reset by peer)) |
03:32:50 | | Join petur [50] (n=petur@rockbox/developer/petur) |
03:44:40 | | Quit petur ("later") |
04:00 |
04:02:56 | | Join Hillshum [0] (n=hillshum@75-165-234-241.slkc.qwest.net) |
04:13:22 | | Quit TheSeven (Nick collision from services.) |
04:13:43 | | Join The_Seven [0] (n=theseven@rockbox/developer/TheSeven) |
04:13:55 | | Nick The_Seven is now known as TheSeven (n=theseven@rockbox/developer/TheSeven) |
04:18:46 | | Quit kugel (Remote closed the connection) |
04:23:08 | | Quit adiroiban (Read error: 110 (Connection timed out)) |
04:28:27 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
04:33:00 | Unhelpful | kugel: i was using target="arm-elf-eabi" in rockboxdev.sh. i also had added support for building binutils snapshots. here's a completely untested update. you will need to provide the gcc patch yourself. :) |
04:33:06 | Unhelpful | http://pastie.org/667620 <- grr. |
04:43:45 | | Join froggyman [0] (n=4845dcc2@giant.haxx.se) |
04:51:13 | *** | Saving seen data "./dancer.seen" |
04:54:40 | | Quit Strife89 (Read error: 104 (Connection reset by peer)) |
04:55:02 | | Join Strife89 [0] (n=michael@adsl-81-160-168.mcn.bellsouth.net) |
05:00 |
05:01:10 | | Quit panni_ (Read error: 104 (Connection reset by peer)) |
05:04:19 | | Quit froggyman ("CGI:IRC") |
05:29:13 | | Quit MethoS- (Remote closed the connection) |
05:29:16 | | Join jdii [0] (n=none@cpe-66-69-20-107.satx.res.rr.com) |
05:37:25 | | Join Strife1989 [0] (n=michael@adsl-220-102-158.mcn.bellsouth.net) |
05:52:51 | | Quit Strife89 (Read error: 113 (No route to host)) |
05:57:25 | | Quit TheSeven (Nick collision from services.) |
05:57:46 | | Join The_Seven [0] (n=theseven@rockbox/developer/TheSeven) |
05:57:58 | | Nick The_Seven is now known as TheSeven (n=theseven@rockbox/developer/TheSeven) |
06:00 |
06:07:12 | | Join lifeless_ [0] (n=lifeless@94.51.253.19) |
06:17:14 | | Quit SUSaiyan (Read error: 54 (Connection reset by peer)) |
06:21:26 | | Quit TheSeven (Nick collision from services.) |
06:21:47 | | Join The_Seven [0] (n=theseven@rockbox/developer/TheSeven) |
06:21:59 | | Nick The_Seven is now known as TheSeven (n=theseven@rockbox/developer/TheSeven) |
06:22:57 | | Join SUSaiyan [0] (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) |
06:24:36 | | Join tomers [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) |
06:25:27 | | Quit lifeless__ (Read error: 113 (No route to host)) |
06:30:50 | | Quit tomers ("ChatZilla 0.9.85 [Firefox 3.0.14/2009090216]") |
06:51:13 | | Quit Strife1989 ("My number of files is OVER 9000!") |
06:51:14 | *** | Saving seen data "./dancer.seen" |
07:00 |
07:04:29 | | Join Riku [0] (n=Lss@cm46.delta91.maxonline.com.sg) |
07:07:06 | | Quit Riku (Read error: 104 (Connection reset by peer)) |
07:16:50 | CIA-85 | New commit by tomers (r23328): Minor Hebrew translation fixes |
07:18:00 | | Join tomers [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) |
07:18:10 | tomers | Does anyone knows if it possible to cross-compile rbutil to Win32 from Linux? |
07:23:39 | | Quit Lss (Read error: 110 (Connection timed out)) |
07:29:52 | | Quit jdii (Read error: 110 (Connection timed out)) |
07:33:57 | | Join Horschti [0] (n=Horscht2@xbmc/user/horscht) |
07:40:48 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
07:46:10 | | Join adiroiban [0] (n=adiroiba@h194-54-129-79.teleson.ro) |
07:52:29 | | Quit Horscht (Read error: 110 (Connection timed out)) |
07:56:15 | | Quit adiroiban ("Leaving.") |
07:56:32 | | Join adiroiban [0] (n=adiroiba@h194-54-129-79.teleson.ro) |
07:56:45 | | Part scp1 |
07:56:57 | | Quit FOAD (Read error: 110 (Connection timed out)) |
07:56:57 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
07:58:54 | | Join AJ707 [0] (n=AJ707@S0106001310779db4.vs.shawcable.net) |
08:00 |
08:10:33 | | Part AJ707 |
08:19:53 | | Quit adiroiban (Read error: 110 (Connection timed out)) |
08:20:56 | | Quit StealthyXIIGer (Read error: 110 (Connection timed out)) |
08:27:20 | | Join robin0800 [0] (n=quassel@149.254.200.216) |
08:30:54 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
08:39:55 | | Join Horscht86 [0] (n=Horscht2@p4FD4DE7A.dip.t-dialin.net) |
08:47:56 | | Join Rob2222 [0] (n=Miranda@p4FDCEE8C.dip.t-dialin.net) |
08:51:17 | *** | Saving seen data "./dancer.seen" |
09:00 |
09:04:19 | | Quit Horschti (Read error: 110 (Connection timed out)) |
09:04:46 | | Quit Hillshum ("Ex-Chat") |
09:06:06 | | Quit Rob2223 (Read error: 110 (Connection timed out)) |
09:06:17 | | Quit BHSPitLappy ("Ex-Chat") |
09:07:09 | | Join FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) |
09:30:29 | | Quit JdGordon| (Read error: 110 (Connection timed out)) |
09:32:54 | | Join stoffel [0] (n=quassel@p57B4FB09.dip.t-dialin.net) |
09:37:52 | | Quit tomers ("ChatZilla 0.9.85 [Firefox 3.0.14/2009090216]") |
09:42:35 | | Nick uflops is now known as mikroflops (n=yogurt@90-231-195-226-no112.tbcn.telia.com) |
09:47:56 | | Join Rob2223 [0] (n=Miranda@p4FDCDAB4.dip.t-dialin.net) |
09:49:58 | | Join esperegu [0] (n=quassel@145.116.15.244) |
09:51:45 | | Quit n1s (Read error: 110 (Connection timed out)) |
09:56:26 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
09:56:27 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
10:00 |
10:03:06 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
10:09:36 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
10:21:32 | | Quit evilnick (Read error: 113 (No route to host)) |
10:22:10 | | Nick Horscht86 is now known as Horscht (n=Horscht2@p4FD4DE7A.dip.t-dialin.net) |
10:22:32 | | Quit phanboy4 ("Leaving") |
10:45:08 | | Quit faemir ("Leaving") |
10:48:34 | | Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) |
10:51:21 | *** | Saving seen data "./dancer.seen" |
11:00 |
11:13:12 | | Join GeekShado_ [0] (n=Antoine@45.168.204-77.rev.gaoland.net) |
11:14:25 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
11:21:06 | | Join gtkspert [0] (n=gtkspert@203-59-174-171.dyn.iinet.net.au) |
11:24:20 | | Join pamaury [0] (n=pamaury@91-164-185-13.rev.libertysurf.net) |
11:29:27 | | Quit GeekShadow (Read error: 113 (No route to host)) |
11:36:23 | | Quit gtkspert_ (Read error: 101 (Network is unreachable)) |
11:36:58 | * | TheSeven is confused by a build that worked flawlessly yesterday, and today it doesn't even boot any more |
11:48:13 | | Quit linuxstb (Remote closed the connection) |
11:52:50 | | Join flydutch [0] (n=flydutch@host81-212-dynamic.15-87-r.retail.telecomitalia.it) |
11:53:22 | | Join Paprica [0] (n=a@93-173-177-190.bb.netvision.net.il) |
11:55:43 | Paprica | hi, i first time compile in linux (i use the guide in the docs) and i have a problem |
11:55:56 | Paprica | my "making" look like that |
11:55:57 | Paprica | http://pastebin.com/d5e5cfe2a |
11:56:10 | Paprica | what i need to do? |
11:57:21 | n1s | configure should turn that warning off, it's basically harmless; are you using a recomended compiler version? |
11:59:12 | Paprica | good question i dont know the answer XD i just follow the instructions here http://www.rockbox.org/wiki/LinuxSimpleGuideToCompiling |
11:59:26 | n1s | or did you run configure without the compiler in the path maybe? if so rerun configure |
12:00 |
12:00:21 | Paprica | i did conigure |
12:01:41 | n1s | configure should tell you if it can't find the compiler |
12:02:05 | TheSeven | n1s: this looks like there is another arm-elf-gcc it found that isn't ours |
12:02:25 | Paprica | TheSeven what should i do? |
12:02:39 | TheSeven | put the right one to the path |
12:02:57 | TheSeven | what does a "which arm-elf-gcc" result in? |
12:04:09 | Paprica | ./usr/local/arm-elf/bin/arm-elf-gcc |
12:04:34 | TheSeven | looks sane |
12:04:59 | Paprica | so? :\ |
12:05:05 | TheSeven | arm-elf-gcc −−version |
12:05:35 | | Join tomers [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) |
12:06:05 | n1s | TheSeven: yeah |
12:06:08 | n1s | it can also happen if you un confgure without the right crosscompiler in the path as it then can't determine the version and make the choices about disabling warnings etc. |
12:06:23 | TheSeven | and another thing you can check: ls -l /usr/local/arm-elf/bin/arm-elf-gcc |
12:06:33 | TheSeven | does that show the date you ran rockboxdev.sh? |
12:07:15 | Paprica | arm-elf-gcc (GCC) 4.0.3 |
12:07:15 | Paprica | Copyright (C) 2006 Free Software Foundation, Inc. |
12:07:15 | Paprica | This is free software; see the source for copying conditions. There is NO |
12:07:15 | DBUG | Enqueued KICK Paprica |
12:07:15 | Paprica | warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. |
12:07:35 | TheSeven | looks sane, too |
12:08:17 | TheSeven | now check that date, and if that looks sane, too, run "make reconf && make" and see if those warnings still show up |
12:08:37 | tomers | zagor, badger: ping |
12:09:09 | Paprica | TheSeven, -rwxr-xr-x 2 root root 154957 2009-10-24 11:20 /usr/local/arm-elf/bin/arm-elf-gcc |
12:09:44 | TheSeven | ok, so the right compiler is in the path |
12:10:28 | Paprica | seem to be ok :) |
12:10:31 | Paprica | thank you :P |
12:11:57 | TheSeven | ok, so the first quess was right: [11:58]<n1s>or did you run configure without the compiler in the path maybe? if so rerun configure |
12:12:58 | n1s | TheSeven: the fun thing is that configure prints a big warning when you run it without the compiler in the PATH... |
12:13:44 | n1s | also, slightly related; i wonder if it would make sense to fix those pointer signedness mismatches |
12:14:38 | TheSeven | yes, I wondered about that, too |
12:15:01 | TheSeven | while most of them probably can't, some of them may be potentially harmful |
12:15:40 | TheSeven | and I don't really like a "disconnect the light" strategy either |
12:16:27 | n1s | nah, it's just that they all showed up with the last gcc upgrade |
12:21:25 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
12:21:25 | * | TheSeven wonders why pointers should ever be signed |
12:21:26 | Paprica | another question about linux, which editor do you use? |
12:22:06 | | Join Utchybann [0] (n=lolo@ede67-1-81-56-102-26.fbx.proxad.net) |
12:24:29 | | Quit pamaury (Read error: 113 (No route to host)) |
12:27:49 | * | TheSeven wonders what an #ifdef CPU_PP inside an #if defined(CPU_PP) is good for |
12:28:16 | Utchybann | TheSeven: mpegplayer seems to play video (and sound) way too fast with r23328. |
12:28:30 | TheSeven | when did this start to happen? |
12:30:03 | TheSeven | can somebody else have a look at config.h:775 and see if I'm just blind or this is really just confusing nonsense that's being done there? |
12:30:32 | Utchybann | I just compile r23328 and try to play elephantdream video (from rockbox site). |
12:31:18 | TheSeven | how does the sound behave? squirrel mode? or just skipping? |
12:32:41 | Utchybann | squirrel mode? It is like play the video at 100fps. |
12:33:54 | Utchybann | a timer/clock change? |
12:37:04 | | Join DerPapst [0] (n=DerPapst@p4FE8F712.dip.t-dialin.net) |
12:37:18 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
12:37:20 | n1s | TheSeven: yeah that #ifdef mess in config.h looks rather odd |
12:38:17 | | Quit lifeless_ (Remote closed the connection) |
12:41:42 | Utchybann | TheSeven: mp3/ogg are playing fine without click/pop. The problem seems limited to mpegplayer. metronome runs fine. |
12:43:00 | | Quit kugel (Remote closed the connection) |
12:44:30 | n1s | hmm, this also means that all pp targets use the SW_CORELOCK workaround for the broken swap instruction... I wonder if that's correct |
12:45:24 | amiconn | it is |
12:45:35 | amiconn | (iirc - search the log for details) |
12:46:03 | amiconn | jhMikeS worked on this |
12:46:32 | Bob_C | The endif comments certainly don't match the #if blocks |
12:47:12 | n1s | amiconn: just the #ifdef logic that's a bit weird then |
12:47:38 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
12:48:26 | Bob_C | Would it be considered bad style to indent #if blocks to make the nesting clearer? |
12:48:28 | amiconn | Indeed. |
12:48:59 | amiconn | Checking the history of config.h will probably help figuring things out properly |
12:49:40 | amiconn | Bob_C: Imho preprocessor statements should never be indented |
12:50:05 | Bob_C | Why not? |
12:50:28 | amiconn | I looks all wrong to me... no technical reason |
12:50:37 | * | TheSeven already found a place where they *are* already indented, but I can't remember where that was |
12:50:39 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
12:50:52 | bertrik | I like to see the original condition repeated in the #endif if the #ifdef / #endif is very long or highly nested |
12:51:01 | TheSeven | in files that just consist of preprocessor statements, it may in fact make sense to indent them |
12:51:26 | *** | Saving seen data "./dancer.seen" |
12:51:33 | amiconn | bertrik: That's usually the case, just in the mentioned case it's all broken |
12:51:37 | bertrik | (I mean an inline comment added to the #endif) |
12:51:44 | TheSeven | bertrik: #else /* ... */ is also a mess |
12:52:02 | TheSeven | sometimes the original conditions are in there, sometimes the condition on which the else block is used |
12:59:43 | TheSeven | line 808 also looks very weird to me |
13:00 |
13:00:11 | | Join funman [0] (n=fun@rockbox/developer/funman) |
13:00:28 | TheSeven | if this should ever be reached, it will clash with line 786 |
13:01:28 | * | TheSeven also just realized that mutexes aren't interrupt-safe |
13:03:06 | bertrik | no, I think you can't use a mutex at all in interrupt context |
13:03:36 | TheSeven | but they are being used in an interrupt context |
13:03:43 | bertrik | you can post a message in a queue, but that's basically the only kernel primitive you can call, I think |
13:03:58 | TheSeven | ...and hopefully wakeups |
13:04:08 | bertrik | yeah, those too :) |
13:04:43 | funman | mutexes are used in interrupt context ? |
13:04:45 | amiconn | You can't block on a mutex in interrupt context, that would cause a freeze if it actually blocks |
13:05:14 | TheSeven | of course, and I'm currently trying to track down a place where this happens |
13:05:35 | bertrik | We should have some way to panic on that I think |
13:05:37 | amiconn | This is obvious - the thread holding the mutex can't let it go because it won't execute unless the isr returns, which it can't do because of the block |
13:05:44 | amiconn | This is by design |
13:06:09 | funman | bertrik: how we know if we're in an isr is platform dependant |
13:06:34 | amiconn | Why would we need a panic for this? |
13:06:35 | bertrik | great, so we can implement it for some platforms :) |
13:07:03 | kugel | the comment makes me wonder why NOCACHEBSS_ATTR is only defined for PP |
13:07:08 | funman | well we can check the cpsr for interrupt state |
13:07:29 | amiconn | funman: Coldfire, SH1, MIPS, ... |
13:07:43 | funman | TheSeven: what about printing the current stack if such a thing happen and look for addresses ? |
13:07:55 | funman | amiconn: yeah it's platform dependant, but this could help TheSeven on nano2g |
13:08:16 | TheSeven | I think I already know what's going on, but need to double-check that |
13:08:18 | | Join evilnick [0] (n=evilnick@ool-4571af51.dyn.optonline.net) |
13:08:26 | bertrik | amiconn, it's an obvious bug if this happens, so I think it's better to show this as clearly as possible |
13:08:28 | | Join kugel_ [0] (n=kugel@e178088216.adsl.alicedsl.de) |
13:08:40 | | Quit kugel (Nick collision from services.) |
13:08:44 | | Nick kugel_ is now known as kugel (n=kugel@e178088216.adsl.alicedsl.de) |
13:09:12 | | Quit tomers (Read error: 60 (Operation timed out)) |
13:10:10 | bertrik | maybe only panic when the kernel is compiled in some kind of debugging mode to avoid slowdowns for code that already does things correctly |
13:10:36 | amiconn | hmmmm |
13:10:39 | TheSeven | bertrik: there already is a flag for that, but it's barely used |
13:11:04 | funman | DEBUG ? |
13:11:11 | amiconn | I guess it depends on how expensive that check is |
13:11:32 | TheSeven | funman: no, there's something specific for the kernel |
13:12:11 | bertrik | DEBUG enables KERNEL_OBJECT_CHECKS |
13:15:02 | bertrik | amiconn, what do you think? Would you approve of extra checking in the kernel (#ifdef DEBUG or similar) that verify if a call is made in the right context? |
13:17:54 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
13:18:34 | | Quit togetic (Read error: 110 (Connection timed out)) |
13:24:34 | | Quit Utchybann (Read error: 113 (No route to host)) |
13:24:34 | bertrik | funman, I think you had a patch for more verbose panic for the ams sansas, right? Or is it already in? |
13:25:42 | funman | i have posted a patch to get the address causing the fault from cp15 register |
13:26:02 | funman | it's not in because we need to check every CPU which implement this (FAR = Fault Address Register) |
13:26:23 | funman | it only gives you more details on Data Aborts |
13:28:45 | bertrik | so basically you just need a list of possible targets where we could use this and have people test it? |
13:29:03 | funman | no, we would know from the documentation |
13:29:13 | | Quit robin0800 ("http://quassel-irc.org - Chat comfortably. Anywhere.") |
13:29:36 | | Join robin0800 [0] (n=quassel@general-ld-216.t-mobile.co.uk) |
13:29:49 | | Quit robin0800 (Client Quit) |
13:30:13 | funman | Torne explained it on FS #10296 : it's available on ARM CPUs with MMU or MPU. The ARM7TDMI (PP) do not |
13:30:22 | | Join robin0800 [0] (n=quassel@149.254.200.216) |
13:32:39 | kugel | amiconn: have you seen my experiments with using the F/X lcd_bitmap_transparent_part() asm optimization for other arm targets? |
13:32:46 | bertrik | funman, so what's stopping you from implementing it? |
13:33:36 | funman | bertrik: lack of usefulness, I have used this patch for my own needs but right now i don't need an extended data abort handler |
13:34:06 | | Quit robin0800 (Client Quit) |
13:34:30 | funman | I think it would require adding yet another feature like #define HAVE_ARM_AND_MMU_OR_MPU |
13:35:45 | TheSeven | someone around who wants to play a little with nano2g undervolting? |
13:35:55 | | Quit BHSPitLappy (Remote closed the connection) |
13:36:50 | | Join robin0800 [0] (n=quassel@general-ld-216.t-mobile.co.uk) |
13:38:48 | kugel | TheSeven: does the datasheet give any recommendations? |
13:39:09 | TheSeven | which datasheet, and recommendations for what? |
13:39:28 | kugel | about voltages |
13:39:45 | TheSeven | if what the DS says is right, apple is already undervolting it |
13:39:58 | | Quit yosafbridge ("Coyote finally caught me") |
13:40:00 | kugel | yea, the sandisk Of also does it |
13:40:07 | | Join yosafbridge [0] (n=yosafbri@li14-39.members.linode.com) |
13:40:25 | TheSeven | they're doing 1075mV while samsung recommends 1100-1300 |
13:40:43 | TheSeven | i'm doing 1000 at 200MHz and 900 at 50MHz and it's running fine |
13:41:03 | kugel | I probably wouldn't go below applies setting otherwise it may fail on some devices |
13:41:08 | kugel | apples* |
13:41:16 | bertrik | It could be of course that 1 in 10 players can not go that low reliably |
13:41:32 | TheSeven | yes, and that's why i want people to test this |
13:41:56 | | Join tomers [0] (n=chatzill@89.138.244.209) |
13:42:04 | TheSeven | in fact i could even go to 975 (200MHz) and 800 (50MHz) from the CPU side |
13:42:11 | TheSeven | but the quartz osc doesn't seem to like the 800 |
13:45:33 | | Quit BHSPitMonkey (Read error: 113 (No route to host)) |
13:46:31 | | Quit JackWinter (Remote closed the connection) |
13:47:40 | bertrik | TheSeven, having more data and knowing where the limits are, is always good of course :) |
13:48:06 | | Join JackWinter [0] (n=jack@vodsl-10804.vo.lu) |
13:48:08 | TheSeven | that's why there is FS #10714 |
13:58:19 | | Join MethoS- [0] (n=clemens@134.102.106.250) |
14:00 |
14:05:03 | | Quit antil33t (Read error: 54 (Connection reset by peer)) |
14:05:09 | | Join antil33t [0] (n=Mudkips@119.224.12.185) |
14:07:12 | | Quit flydutch ("/* empty */") |
14:16:13 | | Quit MethoS- (Remote closed the connection) |
14:17:16 | | Nick YPSY is now known as Ypsy (n=ypsy@87.106.45.183) |
14:22:05 | | Join efyx_ [0] (n=efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
14:26:45 | | Quit funman ("free(random());") |
14:26:50 | | Join Crackerizer [0] (n=7d1a9726@giant.haxx.se) |
14:27:05 | Crackerizer | Hello, |
14:27:44 | Crackerizer | I just finished diacritic patch and need reviews. |
14:43:12 | | Join kyle6513 [0] (n=kyle@58.174.128.189) |
14:44:19 | | Quit kyle6513 (Client Quit) |
14:51:28 | *** | Saving seen data "./dancer.seen" |
14:57:54 | | Join gtkspert_ [0] (n=gtkspert@124-169-4-102.dyn.iinet.net.au) |
15:00 |
15:00:42 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
15:02:16 | | Join dfkt_ [0] (i=dfkt@unaffiliated/dfkt) |
15:05:10 | | Nick chaos is now known as chaos_ (n=ch4os@gentoo/user/ch4os) |
15:05:37 | | Quit dfkt (Nick collision from services.) |
15:05:40 | | Nick dfkt_ is now known as dfkt (i=dfkt@unaffiliated/dfkt) |
15:05:42 | | Nick chaos_ is now known as chaos (n=ch4os@gentoo/user/ch4os) |
15:10:07 | bertrik | I made some very limited progress on the meizu m6 sp display last night |
15:10:33 | bertrik | now I can also get random vertical stripes on the screen and not just horizontal |
15:10:58 | bertrik | it looks like the screen is refreshed from left to right instead of top to bottom |
15:12:01 | bertrik | Also I realised that reading an LCD is basically impossible because the SPI interface towards the LCD lacks a MISO pin (at least if the schematic I have is representative for my player) |
15:12:40 | bertrik | The OF seems to decide at runtime between two drivers, based on the LCD id read back from the LCD |
15:13:41 | | Quit gtkspert (Read error: 101 (Network is unreachable)) |
15:13:56 | | Join bertrik_ [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
15:14:00 | | Quit bertrik ("Leaving") |
15:14:11 | | Nick bertrik_ is now known as bertrik (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
15:17:18 | | Quit meermanr (Remote closed the connection) |
15:19:28 | | Join dfkt_ [0] (i=dfkt@unaffiliated/dfkt) |
15:19:45 | | Quit dfkt (Nick collision from services.) |
15:19:48 | | Nick dfkt_ is now known as dfkt (i=dfkt@unaffiliated/dfkt) |
15:26:42 | amiconn | bertrik: Many lcd controllers allow to change the update direction |
15:28:11 | amiconn | If the meizu m6sp lcd doesn't allow this, or for some reason it's unedesirable, it will profit from kkurbjun's vertical 16 bit driver |
15:33:25 | kugel | amiconn: have you seen my experiments with using the F/X lcd_bitmap_transparent_part() asm optimization for other arm targets? |
15:37:50 | | Quit tomers ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]") |
15:38:05 | | Quit Horscht ("Verlassend") |
15:40:07 | | Quit JackWinter (Read error: 104 (Connection reset by peer)) |
15:41:04 | | Join JackWinter [0] (n=jack@vodsl-10804.vo.lu) |
15:42:31 | | Join dfkt_ [0] (i=dfkt@unaffiliated/dfkt) |
15:46:11 | | Quit JackWinter (Remote closed the connection) |
15:47:05 | | Join JackWinter [0] (n=jack@vodsl-10804.vo.lu) |
15:47:30 | | Quit T44 (Read error: 110 (Connection timed out)) |
15:53:20 | | Quit dfkt (Nick collision from services.) |
15:53:23 | | Nick dfkt_ is now known as dfkt (i=dfkt@unaffiliated/dfkt) |
15:55:45 | | Quit JackWinter (Remote closed the connection) |
15:56:28 | | Join JackWinter [0] (n=jack@vodsl-10804.vo.lu) |
15:59:07 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
16:00 |
16:00:02 | | Join pamaury [0] (n=pamaury@91-164-185-13.rev.libertysurf.net) |
16:03:41 | | Join tomers [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) |
16:05:10 | | Quit Horscht ("Verlassend") |
16:09:44 | | Quit JackWinter (Remote closed the connection) |
16:15:20 | | Join JackWinter [0] (n=jack@vodsl-10804.vo.lu) |
16:21:21 | | Quit pamaury ("exit(*(int *)0 / 0);") |
16:25:02 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
16:26:38 | linuxstb | kugel: Where are those experiments? |
16:30:54 | | Quit Paprica (Read error: 110 (Connection timed out)) |
16:31:03 | | Join Paprica [0] (n=a@93-173-61-132.bb.netvision.net.il) |
16:31:46 | kugel | http://www.rockbox.org/irc/log-20091020#01:55:13 |
16:32:16 | kugel | basically, the F/X optimization is quite generic and can be used on all color display arm targets |
16:37:36 | | Join Strife89 [0] (n=michael@adsl-220-102-158.mcn.bellsouth.net) |
16:39:13 | | Quit TheSeven (Read error: 145 (Connection timed out)) |
16:42:18 | | Quit esperegu (Read error: 104 (Connection reset by peer)) |
16:43:48 | | Quit tomers (Read error: 113 (No route to host)) |
16:46:54 | | Join dfkt_ [0] (i=dfkt@unaffiliated/dfkt) |
16:48:43 | | Quit dfkt (Nick collision from services.) |
16:48:46 | | Nick dfkt_ is now known as dfkt (i=dfkt@unaffiliated/dfkt) |
16:51:14 | | Join dfkt_ [0] (n=dfkt@unaffiliated/dfkt) |
16:51:31 | *** | Saving seen data "./dancer.seen" |
16:52:35 | | Quit dfkt (Nick collision from services.) |
16:52:38 | | Nick dfkt_ is now known as dfkt (n=dfkt@unaffiliated/dfkt) |
16:59:36 | | Join esperegu [0] (n=quassel@145.116.11.103) |
17:00 |
17:09:10 | Torne | bertrik: I was gonna go ahead and write a better abort handler at some point, and make it conditional on the right things.. there's a few things beyond what funman's patch does you can print, and it doesn't handle armv6 fully |
17:09:19 | Torne | bertrik: if you think it's useful i can bump it up the list ;) |
17:13:13 | | Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) |
17:16:42 | | Quit krazykit ("2.6.31") |
17:18:58 | | Join krazykit [0] (n=kkit@24.218.166.241) |
17:27:40 | | Quit dfkt (Read error: 110 (Connection timed out)) |
17:45:12 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
17:47:16 | | Quit DerPapst ("Leaving.") |
17:50:26 | | Join Ubuntuxer [0] (n=johannes@dslb-188-101-009-019.pools.arcor-ip.net) |
17:54:38 | | Join tvelocity [0] (n=tony@adsl12-166.her.forthnet.gr) |
17:55:37 | | Quit StealthyXIIGer (Read error: 104 (Connection reset by peer)) |
17:55:57 | | Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) |
18:00 |
18:01:35 | | Join tomers [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) |
18:01:55 | CIA-85 | New commit by kugel (r23329): Speed up lcd_update_rect by ~2.5% by counting towards 0 in the loop. |
18:03:12 | | Join toffe82 [0] (n=chatzill@adsl-70-235-225-254.dsl.frs2ca.sbcglobal.net) |
18:05:19 | tomers | zagor, badger: ping |
18:08:17 | | Join panni_ [0] (i=hannes@ip-95-222-21-143.unitymediagroup.de) |
18:12:05 | | Quit Ubuntuxer (Read error: 110 (Connection timed out)) |
18:13:36 | | Join adiroiban [0] (n=adiroiba@194.54.129.79) |
18:18:12 | | Join dfkt_ [0] (n=dfkt@unaffiliated/dfkt) |
18:18:20 | CIA-85 | New commit by tomers (r23330): scramble: Make function static |
18:19:03 | | Join togetic [0] (n=togetic@unaffiliated/ibuffy) |
18:20:29 | | Quit dfkt (Nick collision from services.) |
18:20:34 | | Nick dfkt_ is now known as dfkt (n=dfkt@unaffiliated/dfkt) |
18:23:27 | | Quit JackWinter (Read error: 104 (Connection reset by peer)) |
18:25:26 | | Join JackWinter [0] (n=jack@vodsl-10804.vo.lu) |
18:31:43 | | Join NoGare [0] (i=NoGare@216.8.143.102) |
18:42:26 | CIA-85 | New commit by FlynDice (r23331): Add #ifdef HAVE_MULTIDRIVE to HS timings switch for uSD cards. ... |
18:44:18 | | Join Topy44 [0] (n=Topy44@g228153081.adsl.alicedsl.de) |
18:45:32 | | Join bertrik_ [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
18:45:43 | | Quit bertrik (Read error: 113 (No route to host)) |
18:51:32 | *** | Saving seen data "./dancer.seen" |
18:54:44 | | Join Sir_Konrad [0] (n=Sir_Konr@dpclt034064.direcpc.com) |
18:58:24 | | Quit NoGare (Client Quit) |
18:58:31 | Sir_Konrad | iPod shuffle? |
19:00 |
19:00:15 | | Quit robin0800 (Remote closed the connection) |
19:03:04 | krazykit | Sir_Konrad, what about it? |
19:03:11 | AlexP | Sir_Konrad: Not supported |
19:03:18 | Sir_Konrad | ok. |
19:03:24 | Sir_Konrad | that's all I needed to know. ;P |
19:03:38 | Sir_Konrad | kthxbye AlexP. |
19:03:41 | | Part Sir_Konrad ("Leaving") |
19:08:52 | | Quit esperegu (Read error: 60 (Operation timed out)) |
19:09:32 | | Join esperegu [0] (n=quassel@145.116.15.244) |
19:09:35 | | Join flydutch [0] (n=flydutch@host81-212-dynamic.15-87-r.retail.telecomitalia.it) |
19:17:48 | | Join liar [0] (n=liar@83.175.83.185) |
19:20:31 | | Join funman [0] (n=fun@rockbox/developer/funman) |
19:20:48 | | Quit Crackerizer ("CGI:IRC") |
19:21:33 | | Quit stoffel (Remote closed the connection) |
19:23:22 | | Join TheSeven [0] (n=theseven@rockbox/developer/TheSeven) |
19:27:06 | | Join petur [50] (n=petur@rockbox/developer/petur) |
19:32:11 | | Quit Llorean ("Leaving.") |
19:42:45 | n1s | kugel: re r23329 i wonder if gcc will not do a similar optimization at higher optimization levels |
19:47:13 | | Join Lss [0] (n=Lss@cm46.delta91.maxonline.com.sg) |
19:49:12 | | Join MethoS- [0] (n=clemens@134.102.106.250) |
19:50:42 | kugel | n1s: we use -O2 already IIRC |
19:52:42 | | Join Vitor1001 [0] (n=vitor@216.239.45.19) |
19:53:29 | Vitor1001 | anybody at google mentor summit? |
19:53:48 | kugel | petur and scorche |
19:54:08 | | Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) |
19:54:15 | scorche|sh | Vitor1001: hi |
19:54:44 | gevaerts | at least they said so. We have no idea if they're actually there. They might be partying somewhere else for all wek know |
19:54:48 | Vitor1001 | scorche|sh: Hi |
19:55:04 | Vitor1001 | scorche|sh: Ronald and me booked a room to discuss multimedia |
19:55:18 | scorche|sh | Vitor1001: today? |
19:55:22 | Vitor1001 | and not reusing code between ffmpeg and other projects |
19:55:42 | Vitor1001 | Yes, let me just look at the board which room |
19:55:51 | scorche|sh | Vitor1001: i will check the board shortly |
19:56:03 | scorche|sh | also, there is #mentorsummit here on freenode if you wish |
19:56:12 | * | gevaerts pretends to misunderstand |
19:56:19 | gevaerts | What's wrong with reusing code? |
19:56:50 | funman | gevaerts: keeping forked branches up to date with each other is difficult and time consuming |
19:56:57 | Vitor1001 | it's not wrong. It is so right we want to discuss how to do it best ;) |
19:57:27 | Vitor1001 | el-golea room |
19:57:43 | * | petur waves (or tries to if fennec works) |
19:57:48 | scorche|sh | i will make petur record for the benefit of the more codec-oriented people ;) |
19:57:54 | n1s | kugel: nope, core is compiled with -O for all arm targets and Os for sh and coldfire |
19:59:35 | gevaerts | Vitor1001: that's not what you said! You wanted to talk about "not reusing code between ffmpeg and other projects"! |
20:00 |
20:00:14 | Vitor1001 | gevaerts: Well, was what I understand from what ronald say |
20:00:48 | Vitor1001 | The spirit is the same |
20:01:01 | Vitor1001 | It is not a "use our libraries, they are cool" session |
20:01:48 | Vitor1001 | I think rockbox fixed point wma decoder particularly interesting |
20:02:05 | Vitor1001 | We'll, we are there already, so if you want to discuss it live, you can just drop in |
20:04:30 | saratoga | we can't use ffmpeg directly because ffmpeg doesn't do fixed point |
20:05:20 | funman | will you talk about possible integration of rockbox modifications into ffmpeg svn ? |
20:05:24 | n1s | and we don't do floating point :) |
20:11:09 | | Quit sinthetek (Read error: 110 (Connection timed out)) |
20:11:09 | | Nick bertrik_ is now known as bertrik (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
20:11:12 | | Join DerPapst [0] (n=DerPapst@p4FE8F712.dip.t-dialin.net) |
20:11:18 | | Join polobricolo [0] (n=polobric@AGrenoble-257-1-8-190.w86-193.abo.wanadoo.fr) |
20:15:13 | | Quit jfc^3 (Read error: 54 (Connection reset by peer)) |
20:16:24 | | Join jfc^3 [0] (n=john@66.82.208.2) |
20:17:02 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
20:17:28 | | Quit JackWinter (Read error: 104 (Connection reset by peer)) |
20:17:28 | | Join uflops [0] (n=yogurt@90-231-195-226-no112.tbcn.telia.com) |
20:17:31 | scorche|sh | saratoga: around? |
20:17:43 | | Quit mikroflops (Read error: 60 (Operation timed out)) |
20:18:24 | | Quit MethoS- (Remote closed the connection) |
20:19:54 | scorche|sh | linuxstb: you as well? ;) |
20:22:17 | * | linuxstb is here |
20:22:21 | | Join JackWinter [0] (n=jack@vodsl-10804.vo.lu) |
20:22:26 | | Join Buschel [0] (n=ab@p54A3EE1F.dip.t-dialin.net) |
20:23:30 | | Join BBB [0] (n=rbultje@216.239.45.19) |
20:23:54 | saratoga | scorche|sh: i'm back |
20:24:58 | petur | linuxstb, saratoga: the ffmpeg guys have some questions, hold on |
20:25:05 | | Quit JackWinter (Remote closed the connection) |
20:26:25 | | Join JackWinter [0] (n=jack@vodsl-10804.vo.lu) |
20:27:00 | | Join j-b [0] (n=jb@videolan/developer/j-b) |
20:27:15 | BBB | saratoga, how diff is wmafixed from wmafloat/ffmpeg? |
20:27:38 | saratoga | most of the basic functions are similar, and it has been back ported to ffmpeg based projects |
20:27:55 | funman | some tables/functions are given section attributes to be put in faster memory |
20:28:57 | saratoga | we use a different mdct now, and the decode_superframe function has been split into a function that works on smaller pieces (the original wma codec could operate on enormous blocks of memory at one time IIRC) |
20:29:56 | saratoga | we also don't use the ffmpeg parser |
20:29:59 | saratoga | asf parser |
20:30:06 | BBB | saratoga, can you submit the superframe decode function split? that would help |
20:30:09 | BBB | it's a big ugly function |
20:30:10 | BBB | :) |
20:30:22 | BBB | the fact tha tyou don't use asfdec shouldn't matter much right? |
20:30:50 | saratoga | linuxstb wrote it originally IIRC, but I think it shouldn't be too hard to port |
20:31:02 | saratoga | although i'm not sure if the ffmpeg API would be ok with it |
20:33:28 | saratoga | i'd have to review the change, but I suppose wma_decode_superframe could be replaced with wma_decode_superframe_frame (e.g. the version that returns exactly 2048 samples) and be made to call wma_decode_superframe_init everytime it finished a superframe |
20:35:06 | BBB | could you submit patches for that? |
20:36:37 | saratoga | eventually, but i have little time during the semester |
20:36:52 | saratoga | why the new interest in our wma changes? |
20:37:33 | saratoga | funman: unrelated question, what does it mean when the clip crashes by simply powering down, and reboots on any button press at all (not just power)? |
20:38:00 | funman | I'd say panic |
20:38:12 | funman | panicf() will reboot on any button press |
20:39:06 | saratoga | shouldn't that print an error? |
20:39:36 | | Quit Vitor1001 (Read error: 110 (Connection timed out)) |
20:40:13 | petur | it should print stuff and reboot if you hit a key in that screen |
20:41:33 | funman | saratoga: i've seen unexplained reboots already, how can i reproduce this one ? |
20:42:24 | saratoga | funman: I get them pretty easily with this patched clip build: http://duke.edu/~mgg6/rockbox/rockbox_move_handle_v1.7z |
20:42:41 | saratoga | takes maybe 1-2 tracks before it randomly happens while playing |
20:42:50 | saratoga | its just the latest buffering patch |
20:42:54 | saratoga | i'm a little confused whats happening |
20:42:58 | funman | do you have lcd always on |
20:42:59 | kugel | saratoga: is the display off so that you can't read the screen? |
20:43:20 | saratoga | kugel: theres a click sound like the DAC powered off, but its possible the rest of the SOC is still on |
20:44:10 | kugel | it sounds like a panicf to me too, you of course need the display on in order to read it |
20:45:45 | funman | if kugel and me agree it surely must be the Truth ;)) |
20:46:21 | saratoga | i'll disable the backlight timer and try again |
20:47:33 | | Quit phanboy4 (Read error: 104 (Connection reset by peer)) |
20:48:40 | BBB | saratoga, it'd be nice to integrate it back |
20:48:43 | BBB | (sorry for replying slow) |
20:49:39 | | Quit liar (Remote closed the connection) |
20:50:04 | saratoga | BBB: ok i've got a few ffmpeg optimizations on my todo list |
20:50:09 | saratoga | i'll try and get to them eventually |
20:50:47 | saratoga | TheSeven: did you enable USB disk mode for the nano2g yet? |
20:51:35 | *** | Saving seen data "./dancer.seen" |
20:52:53 | | Quit jfc^3 (Read error: 131 (Connection reset by peer)) |
20:54:50 | CIA-85 | New commit by Ubuntuxer (r23332): FS #10497 - New game codebuster, which is a clone of the classic game mastermind. It just runs on color LCD. Thank you to the author Clément ... |
20:55:06 | TheSeven | saratoga: I can't remember enabling it explicitly, but it seems to be enabled in SVN |
20:55:20 | saratoga | ok was confused about people talking about it in the forums |
20:55:23 | TheSeven | might have been done by someone else or sneaked in somehow |
20:55:33 | TheSeven | let me blame it |
20:56:07 | | Join Ubuntuxer [0] (n=johannes@94.221.94.63) |
20:56:27 | | Quit funman ("free(random());") |
20:56:42 | linuxstb | Ubuntuxer: Why the change to brickmania.tex in that commit? |
20:56:54 | Ubuntuxer | just the id |
20:57:00 | TheSeven | saratoga: eek, it sneaked in in r23308 as a unrelated change |
20:57:32 | BBB | saratoga, cool, thnx |
20:57:43 | linuxstb | Ubuntuxer: Yes, but why as part of a completely unrelated commit? |
20:57:44 | Ubuntuxer | actually I want to make seperately |
20:57:55 | Ubuntuxer | sorry |
20:58:47 | saratoga | TheSeven: http://forums.rockbox.org/index.php?topic=23004 |
20:58:55 | saratoga | any idea why USB HID makes a difference here? |
20:58:57 | | Quit JackWinter (Read error: 104 (Connection reset by peer)) |
21:00 |
21:00:31 | | Join JackWinter [0] (n=jack@85.93.208.52) |
21:04:32 | | Quit flydutch ("/* empty */") |
21:08:12 | | Quit StealthyXIIGer (Read error: 104 (Connection reset by peer)) |
21:08:31 | | Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) |
21:08:54 | | Join MethoS- [0] (n=clemens@134.102.106.250) |
21:10:19 | TheSeven | saratoga: I can't imagine what's causing that. But what annoys me far more than the HID stuff is that the FTL seems to be bugging again. |
21:10:38 | saratoga | ok so long as you're aware that someone is having trouble with it |
21:16:29 | saratoga | funman: MT said he got a Clip+, any idea how difficult it will be to get a bootloader running on it? |
21:16:34 | | Quit Ubuntuxer ("Leaving.") |
21:19:01 | Torne | linuxstb: decryption failed, checksum error. but at least it doesn't die horribly. |
21:20:06 | Torne | http://pastebin.com/m29f736ea |
21:20:38 | | Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) |
21:23:10 | linuxstb | Torne: Yes, I've got an image of a 5.5g I can test with, and it dies with the same error. (and it's trying the same key) |
21:23:54 | Torne | only the 3g aupd seems to ahve the flash image table in it |
21:24:13 | Torne | the others don't have the hslf-type strings in at all |
21:24:20 | Torne | though they are decrypted fine because i can disassemble them |
21:24:34 | Torne | so it looks like this might be excessively annoying regardless. |
21:29:33 | CIA-85 | New commit by alex (r23333): Improve English in the codebuster manual entry. |
21:29:45 | AlexP | Now to correct spelling/punctuation in the plugin itself :) |
21:29:50 | | Quit MethoS- (Remote closed the connection) |
21:30:03 | | Join MethoS- [0] (n=clemens@134.102.106.250) |
21:32:10 | | Quit BBB ("This computer has gone to sleep") |
21:33:08 | Dhraakellian | ooh |
21:33:10 | Dhraakellian | mastermind |
21:33:29 | * | Dhraakellian updates |
21:34:49 | linuxstb | Dhraakellian: No, it's nothing like mastermind. Completely different... No relation at all... |
21:35:01 | Dhraakellian | sorry, clone of mastermind |
21:35:12 | linuxstb | No, it's nothing like mastermind. Completely different... No relation at all... |
21:35:30 | Dhraakellian | I'll just have to see what the differences are, then. :D |
21:40:46 | CIA-85 | New commit by alex (r23334): Correct spelling and punctuation in Codebuster menus. |
21:40:48 | | Join Strife1989 [0] (n=michael@adsl-220-102-158.mcn.bellsouth.net) |
21:42:07 | saratoga | funman: it was a data abort with the light off |
21:43:07 | | Quit MethoS- (Remote closed the connection) |
21:45:28 | saratoga | huh somewhere in buffering, but nothing thats in the .map file |
21:46:35 | | Quit Paprica () |
21:47:21 | | Join MethoS- [0] (n=clemens@134.102.106.250) |
21:48:22 | | Quit MethoS- (Remote closed the connection) |
21:49:01 | | Quit Strife89 (Connection timed out) |
21:54:25 | AlexP | What is going on with the Gigabeat S red in the current build? |
21:54:40 | AlexP | I don't think my change caused that :) |
21:55:34 | | Join pamaury [0] (n=pamaury@91-164-185-13.rev.libertysurf.net) |
22:00 |
22:00:03 | | Quit Buschel () |
22:00:49 | | Join BBB [0] (n=rbultje@216.239.45.19) |
22:08:45 | * | bertrik sees something resembling a rockbox logo on his meizu m6 sp \o/ |
22:09:11 | GeekShado_ | bertrik, awesome :) |
22:11:03 | AlexP | bertrik: Congrats :) |
22:11:13 | n1s | \o/ |
22:12:02 | bertrik | it doesn't need a 24-bit framebuffer as I originally thought, it can work with 16-bit (RGB565) too |
22:13:02 | gevaerts | \☺/ |
22:13:26 | bertrik | GeekShado_, AlexP, n1s, gevaerts, thanks for the support! :P BTW, seeing a correct logo now (even the colors are right) :P |
22:13:55 | GeekShado_ | sweet :) |
22:14:27 | kugel | bertrik: cool |
22:14:39 | GeekShado_ | I hope your work willl work on M3 hardware too |
22:15:22 | bertrik | GeekShado_, the meizu m3 already has a working display, the m3 probably benefits most from the things that TheSeven is currently doing |
22:15:38 | GeekShado_ | oh cool |
22:17:34 | TheSeven | my nano has a current leak o.O |
22:18:06 | AlexP | TheSeven: At least it isn't a currant leak :) |
22:18:23 | TheSeven | as soon as i disable the USB controller once (and disable it again), power consumption more than doubles |
22:18:44 | TheSeven | I checked the USB powerdown code, and it seems to be right (and clocks are properly getting masked etc.) |
22:19:34 | bertrik | it's a really useful feature to have an adc for measuring current consumption :) |
22:19:48 | | Part j-b |
22:20:05 | TheSeven | measuring it with a multimeter would in fact be better, but I can't reach the battery in that thing without destroying it |
22:20:52 | TheSeven | but yes, this *would* be pretty useful for things like battery runtime estimation code, if rockbox would support it :-/ |
22:21:36 | kugel | you can make rockbox support it! :) |
22:21:56 | bertrik | oh I thought rockbox already did have a battery_current function or something similar |
22:22:12 | TheSeven | yes, but it's quite hardwired to |
22:22:12 | bertrik | (and using it for battery estimation) |
22:22:21 | TheSeven | *estimating* the current rather than measuring it |
22:22:43 | kugel | I think the estimation is actually taking the current into account, it's just that most/all assume a (compile-time) constant value |
22:23:50 | n1s | likely many older targets couldn't measure the current so rockbox never got the ability to support esimation based on measurment |
22:24:29 | kugel | that's a reasonable assumption ;p |
22:28:02 | bertrik | the meizu m6 sp display is currently in portrait mode, rather than landscape as it's used in the OF. I hope to find out more about the LCD to change this. |
22:28:30 | | Part BBB ("Leaving") |
22:28:33 | GeekShado_ | I remember I got a question |
22:28:43 | GeekShado_ | in which langage are coded RockBox plugins ? |
22:28:48 | n1s | C |
22:29:03 | TheSeven | ...or LUA |
22:29:27 | TheSeven | (whatever that is) |
22:29:58 | n1s | yeah, i don't think any pugins have been coded in lua yet but it's possible |
22:30:29 | TheSeven | n1s: afair there is that viewport test plugin :-) |
22:31:27 | n1s | ah, ok, that sounds useful :) |
22:31:42 | CIA-85 | New commit by theseven (r23335): Plumb an iPod Nano 2G battery leak that started spilling as soon as USB was used at least once until a reboot. |
22:32:26 | n1s | Real Men (tm) use C anyway ;) |
22:34:08 | n1s | or RealvWomen |
22:34:12 | n1s | i suppose |
22:34:20 | n1s | e /s/v/ / |
22:38:46 | | Join Davide [0] (n=chatzill@user-12ld9nk.cable.mindspring.com) |
22:40:02 | | Part Davide |
22:40:06 | | Join Davide [0] (n=chatzill@user-12ld9nk.cable.mindspring.com) |
22:40:10 | | Quit Davide (Client Quit) |
22:40:21 | | Join Davide-NYC [0] (n=chatzill@user-12ld9nk.cable.mindspring.com) |
22:41:19 | Davide-NYC | Hello all. I'm having big problems with a recent RB upgrade. |
22:41:40 | saratoga | TheSeven: should be farely easy to make runtime estimation use the current meter on the 2G |
22:42:05 | saratoga | but i wonder how useful it'll really be, at least with a compile time value we know the value chosen is an average over an entire battery bench |
22:42:05 | Davide-NYC | On my H120-RTC-CFMod target I get codec and encoder errors as well as incompatible version. I've done clean installs (deleting .rockbox prior to unpack) |
22:42:11 | Davide-NYC | any ideas? |
22:42:23 | saratoga | i think if you watch it in real time you may get a lot of jumping around as the bit rate changes and such |
22:42:53 | saratoga | though i suppose with a long enough running average it might work pretty well |
22:42:55 | Davide-NYC | Compiling in cygwin. reproduced problem on two different (although similarly modded) units. |
22:46:37 | TheSeven | how can modifying system_exception_wait make it crash on boot, reproducibly? |
22:48:20 | TheSeven | ok, what should i fix/break next? :-) |
22:50:47 | n1s | Davide-NYC: you don't runa rockbox from flash, do you? |
22:50:47 | * | TheSeven is about to file a flyspray bug regarding flyspray being unable to search for all bugs affecting a certain target |
22:50:48 | Davide-NYC | Doh! I think I figured it out. I forgot to flash my RAM/ROM |
22:50:53 | n1s | run, even |
22:51:25 | Davide-NYC | n1s: exactly my prblem, but I just formatted my CF and am compiling my code (again) so in a minute we'll see. |
22:51:39 | *** | Saving seen data "./dancer.seen" |
22:51:48 | saratoga | running from flash if you have a CF card probably isn't worth the hassel |
22:51:50 | n1s | that is likely the problem |
22:51:54 | Davide-NYC | I just forgot the flashing step so everything on the CF itself was truly incompatible |
22:52:54 | Davide-NYC | saratoga: I'm not sure booting from CF is supported by bootloader v7pre4 |
22:54:14 | n1s | Davide-NYC: there is some kind of way to boot from the hd with that bootloader that you need to use anyway if you want to flash IIRC |
22:54:37 | n1s | but i think that is new enough to have the cf fixes |
22:55:44 | Davide-NYC | any news on a final V7 release for that bootloader? |
22:56:49 | * | TheSeven wonders if it's worth a try to dig into all that UI stuff to track down what's going on with nano2g scrolling |
22:57:09 | | Join bluebrother [0] (n=dom@g224236141.adsl.alicedsl.de) |
22:58:39 | | Quit bluebroth3r (Read error: 60 (Operation timed out)) |
22:59:48 | | Quit pamaury ("exit(*(int *)0 / 0);") |
23:00 |
23:00:08 | Davide-NYC | saratoga: booting from CF (HD) works perfectly. |
23:03:10 | saratoga | anyone feel like trying out a clip build and letting me know the abort address when it crashes? |
23:04:54 | * | amiconn returns |
23:05:43 | amiconn | kugel: At the time you linked to you only said that you experimented a bit, but there are no results given |
23:05:58 | amiconn | Did you measure the potential speedup meanwhile? |
23:06:23 | kugel | amiconn: well, I asked you if you saw it. if you said no I would've shown you some results |
23:06:33 | * | amiconn also wonders whether it'd matter in real-world figures at all |
23:07:27 | bertrik | amiconn, I'm reading a datasheet right now that indicates that it should indeed be possible to change the portrait/landscape mode for some targets, I'll try that now (bit 3 in R03h - Entry mode) |
23:07:33 | kugel | http://www.rockbox.org/irc/log-20091020#01:55:13 - basically 10% speedup on my fuze, <5% on my e200 |
23:07:49 | kugel | the results are further down |
23:08:09 | kugel | starting at 2:45 |
23:10:15 | amiconn | hmm |
23:10:46 | amiconn | I still wonder how important it is. The usb screen is one of the rare cases that uses transparent bitmap drawing for a large bitmap, isn't it? |
23:11:00 | amiconn | Also, is the asm function smaller or larger than the C equivalent? |
23:12:52 | kugel | I didn't messure binsize if you mean that |
23:13:11 | bertrik | aw, the landscape/portrait swap didn't work .. |
23:13:36 | amiconn | I do mean that |
23:13:57 | amiconn | The place where this function resides currently is odd. |
23:14:03 | | Quit polobricolo (Read error: 110 (Connection timed out)) |
23:14:05 | kugel | the inline assembly is only 15 lines, it doesn't make a difference anyway |
23:14:28 | kugel | if we have it already we can use it for all (applicable) targets IMO |
23:15:09 | | Quit tomers (Read error: 60 (Operation timed out)) |
23:15:10 | * | amiconn thinks this could be sped up even further, at least on ARMv6 (beast) |
23:15:52 | | Join dockimble [0] (n=dockimbl@77.227.1.24) |
23:17:28 | | Quit n1s ("Lämnar") |
23:17:35 | kugel | it has a tad bit different clipping and doesn't calculate dst_end, I wonder what code to keep (apart from the asm) |
23:19:00 | | Join faemir [0] (n=faemir@78.33.109.163) |
23:21:01 | amiconn | The C code needs to stay anyway, for the sims and the other archs |
23:21:08 | kugel | sure |
23:21:27 | kugel | I mean the code outside the loop |
23:24:19 | Davide-NYC | Comment about iRiver bootloader v7pre4: On CFModded H1x0 targets USB disk mode does not work for all CFCards. Neither does booting from CFCard (for probably the same as of yet unknown reason). |
23:24:56 | amiconn | The C code isn't very efficient |
23:25:33 | * | amiconn guesses that if the inner loop in the C code is optimised, it will be as fast as the asm, with the added benefit that it'd also speed up things on the other archs |
23:27:07 | amiconn | In fact I guess that if this gets optimised, the compiled arm code will look very similar, if not identical, to the asm version |
23:29:09 | kugel | that wouldn't surprise me |
23:29:26 | | Join dmb [0] (n=Dmb@unaffiliated/dmb) |
23:29:41 | | Quit dmb (Read error: 104 (Connection reset by peer)) |
23:31:33 | | Join dmb [0] (n=Dmb@unaffiliated/dmb) |
23:32:01 | | Join reydarz [0] (n=44fea580@giant.haxx.se) |
23:33:17 | kugel | amiconn: so what now? |
23:33:55 | amiconn | Imo optimising the C would be the best solution |
23:34:31 | amiconn | Less ifdef,s and more targets benefit from that |
23:35:52 | kugel | I don't think I'm able to optimize it to be as fast, I could try the count-towards zero thing (but that might actually be sufficient already) but I don't see much more |
23:36:35 | amiconn | The inner loop is a for loop atm. That's not the best choice speed wise |
23:36:42 | Davide-NYC | I just compiled a patched bootloader from FS #9642, I'm expecting a file called "bootloader.iriver" but instead I have a bootloader.bin file. Are these the same file? |
23:36:48 | * | amiconn might have a shot at it tomorrow |
23:37:35 | Davide-NYC | Guys, I'm going to be flashing my bootloader and do not want to brink my beloved H1120+mods. Am I doing this correctly? |
23:38:23 | AlexP | I wouldn't be flashing an untested H100 bootloader if it were me |
23:38:44 | Davide-NYC | AlexP: can you take a look at FS #9642? |
23:39:15 | Davide-NYC | I mean, I've gotten a lot of good use out of RB and *somebody* has to test this patch. |
23:39:38 | AlexP | Davide-NYC: I'm not testing any H100 bootloader patches |
23:39:53 | AlexP | Davide-NYC: I have no way of recovering if it is not good |
23:40:25 | * | TheSeven wonders how that bootloader was developed then |
23:40:27 | saratoga | someone with a BDM cable should test it so that they can unbrick if needed |
23:40:34 | AlexP | yep |
23:40:51 | AlexP | TheSeven: By linusn who has a BDM wiggler |
23:40:51 | Davide-NYC | No, I'm willing to do it, since I have a spare unit. I was just asking that you look at the patch since I'm not very good at coding and there is a persistent bug in the BL as is. |
23:41:08 | AlexP | Davide-NYC: I'm not the person to be commenting on the code :) |
23:41:18 | Davide-NYC | OK |
23:41:36 | AlexP | I could, but it'd be meaningless :) |
23:42:37 | Davide-NYC | Question remains: Is bootloader.bin == bootloader.iriver? (presuming I've configured correctly? |
23:43:08 | AlexP | TheSeven: The H100 and H300 bootloaders are a bit of a bugger - they need thorough testing by someone who can recover in the event of problems before release, and this person is LinusN (who is busy and not around much these days). That means that they don't tend to get updated |
23:43:41 | AlexP | Davide-NYC: One mo |
23:46:47 | | Quit dmb ("Leaving") |
23:48:52 | AlexP | Davide-NYC: Sorry, not sure. I was looking something up but couldn't find it |
23:49:39 | Davide-NYC | me neither :( |
23:51:42 | Davide-NYC | I just tried to flash the bootloader.bin file and the iriverflash utility gave an "unkown filetype" error. |
23:51:48 | TheSeven | guessing from the name, it may need to be run though scramble, but honestly I have no idea about that target |
23:51:54 | | Join mt2 [0] (n=mtee@41.233.153.188) |
23:52:13 | | Nick mt2 is now known as mt (n=mtee@41.233.153.188) |
23:53:11 | | Join dmb [0] (n=Dmb@unaffiliated/dmb) |
23:53:56 | Davide-NYC | petur: ping |
23:54:24 | Slasheri | Davide-NYC: NO, bootloader.bin is not bootloader.iriver |
23:54:33 | Slasheri | rockbox.iriver is the bootloader.iriver |
23:54:39 | Slasheri | (when compiling bootloader) |
23:54:41 | Davide-NYC | How do I "make" that? |
23:54:54 | Slasheri | you should already have it, if you compiled the bootloader |
23:55:09 | saratoga | how trustworthy are data abort addresses on AMS? |
23:55:35 | Slasheri | but in order to flash it, you need to override safety mechanism from iriver_flash.c utility (or add then checksum of the new file there) |
23:55:35 | Davide-NYC | Slasheri: Got it. |
23:55:43 | * | TheSeven tries to get grip on the GUI code and terribly fails... |
23:56:34 | saratoga | if i have the address can I disassemble and find the exact line or is it only approximate? |