| 00:01:20 | MelaGo | so i'm able to run the complete tutorial to get it to FAT32. But when I try to install after that using the program, i get the RW-error...When i replug the ipod, itunes gives a message to restore it, which is good i guess, since it is in fat32-structure. However, even after this replug and the shutting down of itunes, i get the same RW-error |
| 00:01:49 | linuxstb | Going back a step, after you converted it to fat32, does the ipod work as normal? i.e. does the apple firmware still work? |
| 00:02:11 | MelaGo | no, when i unplug it |
| 00:02:16 | MelaGo | it says to connect it to a pc |
| 00:02:25 | MelaGo | and then gives me the instruction to restore it, which i ofcourse don't do |
| 00:03:05 | linuxstb | That's the first problem you have to solve |
| 00:03:34 | linuxstb | Are you sure it's a "5g", and not the "5.5g" ? |
| 00:03:37 | | Quit mcuelenaere () |
| 00:04:01 | | Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) |
| 00:04:09 | | Quit HBK (Read error: 110 (Connection timed out)) |
| 00:04:25 | MelaGo | pretty sure yeah. No search function, and 512 byte sector |
| 00:05:12 | linuxstb | OK, 512-byte sectors is the important point. |
| 00:09:14 | | Quit bluebrother ("leaving") |
| 00:14:49 | amiconn | Argh! |
| 00:14:54 | amiconn | Any manual expert around? |
| 00:15:38 | MelaGo | So, linuxstb, when i get it to fat32, my apple firmware should still be working? |
| 00:16:11 | linuxstb | MelaGo: Yes |
| 00:21:32 | MelaGo | not working...Keep on auto-getting it in disk mode and itunes telling me to restore it... |
| 00:22:50 | | Quit jhulst (Read error: 110 (Connection timed out)) |
| 00:24:12 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
| 00:24:45 | | Join markun [50] (n=markun@rockbox/developer/markun) |
| 00:24:49 | linuxstb | MelaGo: And after you restore with itunes, it works normally? |
| 00:24:55 | MelaGo | yes |
| 00:25:46 | linuxstb | Can you describe the steps you are doing? Copy and paste any commands you're typing. |
| 00:27:26 | MelaGo | ok |
| 00:27:58 | MelaGo | i download the |
| 00:27:58 | MelaGo | 30GB Video (512-byte sectors) mbr-video30gb.bin file and put it on my desktop |
| 00:28:06 | MelaGo | open up terminal |
| 00:28:13 | MelaGo | and disk utility |
| 00:28:52 | MelaGo | check the disk-info in disk utility for the ipod, which is: disk2s3 |
| 00:29:03 | MelaGo | deactivate the ipod in disk utility |
| 00:29:31 | | Quit Nibbl (Read error: 113 (No route to host)) |
| 00:30:41 | MelaGo | type in terminal: dd if=/Users/<myname>/Desktop/mbr-video30gb.bin of=/dev/disk2 |
| 00:30:55 | MelaGo | then i get: 1+0 records in |
| 00:30:55 | MelaGo | 1+0 records out |
| 00:30:55 | MelaGo | 512 bytes transferred in 2.509447 secs (204 bytes/sec) |
| 00:31:33 | MelaGo | then type: newfs_msdos -F32 -v iPod /dev/rdisk2s2 to get it in fat32 |
| 00:31:51 | linuxstb | Do you remove the ipod between the those two steps? |
| 00:31:58 | MelaGo | no |
| 00:32:06 | MelaGo | I tried it once |
| 00:32:11 | MelaGo | gave the same thing |
| 00:32:14 | MelaGo | should i remove it? |
| 00:33:06 | linuxstb | I can't remember - it seems other people have changed those instructions since I first wrote them. |
| 00:33:59 | MelaGo | alright, so now when i go to disk utility |
| 00:34:12 | linuxstb | No, it doesn't seem to be required to remove and reattach. |
| 00:34:19 | MelaGo | i got my ipod with the name "disk2s2" still on deactivated mode |
| 00:34:31 | MelaGo | structure is: MS-DOS (FAT32) |
| 00:34:47 | MelaGo | now, in order to install rockbox with the program, I have to activate it |
| 00:35:18 | linuxstb | I've no idea what that means - I never had to do anything else. |
| 00:35:36 | linuxstb | If you now eject your ipod, does the Apple firmware work (do nothing else after the newfs_msdos command) |
| 00:35:39 | MelaGo | well, when I'd go to rockbox utilty now, it wouldn't find the ipod |
| 00:35:43 | MelaGo | since it's deactivated... |
| 00:35:56 | MelaGo | it gives me an error...So I have to activate to get the program to locate it |
| 00:36:08 | MelaGo | sec, i'll eject |
| 00:36:20 | MelaGo | haven't run rockbox yet btw |
| 00:36:43 | linuxstb | Yes, I know - you need to confirm you have a working winpod first. |
| 00:36:49 | MelaGo | when i eject, it reboots and |
| 00:36:55 | MelaGo | YES, it works on apple firmware |
| 00:36:57 | MelaGo | normally |
| 00:37:16 | MelaGo | when connecting it to itunes, it asks me to name it and all that... |
| 00:37:45 | MelaGo | wow, and it got a windows structure too |
| 00:37:48 | MelaGo | first time i see this |
| 00:37:51 | MelaGo | alright, so what's next? |
| 00:38:26 | MelaGo | now i have to run rockbox utility right? |
| 00:38:28 | linuxstb | Simply run rockbox utility - it should work now. |
| 00:39:53 | | Quit Tetracomm (Read error: 110 (Connection timed out)) |
| 00:40:21 | | Join Tetracomm [0] (n=nicholas@72.252.29.2) |
| 00:43:38 | | Quit bughunter2 ("bye") |
| 00:43:44 | | Quit ender` (" Theorem: a cat has nine tails. Proof: No cat has eight tails. A cat has one tail more than no cat. Therefore, a cat") |
| 00:45:17 | | Quit havien ("Konversation terminated!") |
| 00:47:32 | * | sarixe skdjf |
| 00:48:24 | | Join havien [0] (n=none@68-189-143-101.dhcp.wlwl.wa.charter.com) |
| 00:48:24 | * | sarixe dies |
| 00:49:31 | | Quit kharo (Read error: 60 (Operation timed out)) |
| 00:51:57 | * | sarixe hi |
| 00:52:36 | MelaGo | alright, so i got a succesfull install of Rockbox, but another problem arises :p...When rebooting Rockbox, i get a "Can't load rockbox.ipod" on my screen... |
| 00:54:35 | | Quit Schmogel (Read error: 104 (Connection reset by peer)) |
| 00:57:29 | linuxstb | So it wasn't a successful install... |
| 00:57:47 | linuxstb | Did you install both the bootloader and Rockbox itself? |
| 00:57:58 | | Join kharo [0] (n=teemu@a88-114-245-92.elisa-laajakaista.fi) |
| 00:58:08 | pixelma | in the Rockbox Utility which option did you use? I've heard that there unfortunately are still problems with the "Complete installation" from the "Quick start" tab on MacOS... |
| 00:59:23 | MelaGo | used complete installation |
| 00:59:26 | | Quit einhirn (Read error: 104 (Connection reset by peer)) |
| 00:59:43 | MelaGo | so i'll manually install the bootloader and rockbox individually? |
| 01:00 |
| 01:00:19 | | Join Munkie [0] (n=Alex@dsl-245-168-10.telkomadsl.co.za) |
| 01:00:45 | Munkie | where can i download plugins? |
| 01:00:46 | | Join syn4pse [0] (n=chatzill@c-68-59-8-200.hsd1.sc.comcast.net) |
| 01:01:07 | linuxstb | MelaGo: It looks like the bootloader install worked - you just need to install Rockbox itself. |
| 01:01:24 | linuxstb | Munkie: All plugins are included with Rockbox. |
| 01:01:40 | syn4pse | rockboxdev.sh is failing for me in 64bit ubuntu, any ideas? |
| 01:01:46 | pixelma | MelaGo: no, bootloader is already installed now (that's the one that put "Can't load..." on the screen). You should be able to just install the Rockbox build from the "Installation" tab in the utility (second option) |
| 01:01:48 | Munkie | i want to get the Gameboy emulator. it is not included |
| 01:01:58 | *** | Saving seen data "./dancer.seen" |
| 01:02:18 | linuxstb | Munkie: Yes it is - please read in the manual about how to use it (and also about "viewer" plugins) |
| 01:02:24 | pixelma | Munkie: the emulator itself is incuded |
| 01:02:27 | syn4pse | specifically it won't compile the gcc cross compiler (arm), there is an error in the number of arguments in the script. |
| 01:02:29 | MelaGo | k, i manually installed rockbox (second option in the utility), still get the same error... |
| 01:02:31 | pixelma | *included too |
| 01:02:37 | Munkie | thank you |
| 01:02:38 | linuxstb | Munkie: Although what mp3 player are you using Rockbox on? |
| 01:02:48 | MelaGo | "can't load rockbox.ipod |
| 01:02:50 | MelaGo | file not found" |
| 01:02:58 | Munkie | ipod video 30gig |
| 01:03:07 | MelaGo | even though install went perfect |
| 01:03:08 | linuxstb | Munkie: Then yes, it's included. |
| 01:03:55 | linuxstb | MelaGo: Maybe your ipod wasn't mounted - sometimes I experienced OS X leaving ghost "/Volumes/[ipod name]/" folders |
| 01:04:01 | Munkie | oh and is sound supported in doom? |
| 01:04:32 | linuxstb | There are sound effects, but no background music. |
| 01:04:38 | Munkie | ok cool |
| 01:05:35 | MelaGo | It says it's activated/mounted. Got it running in disk mode now right now |
| 01:05:54 | MelaGo | However, when opening the ipod in Finder, I got no Rockbox directory, don't know if that's ok... |
| 01:05:55 | | Quit culture (Connection timed out) |
| 01:07:00 | linuxstb | MelaGo: It's ".rockbox" (note the dot) - which is hidden by default in Finder. You can check in the terminal by typing: ls -al "/Volumes/ipod name/" |
| 01:07:40 | MelaGo | I know it's hidden |
| 01:07:46 | MelaGo | I can see Hidden Files |
| 01:07:50 | MelaGo | defaults write com.apple.finder AppleShowAllFiles TRUE |
| 01:07:51 | MelaGo | killall Finder |
| 01:08:02 | MelaGo | no Rockbox though... |
| 01:08:42 | amiconn | I've rewritten the archos flashing manual chapter. It would be nice if a native english speaker could have a look at it... |
| 01:09:59 | linuxstb | MelaGo: OK. You could just install the rockbox.zip manually - download it from the website, and type "unzip rockbox.zip -d "/Volumes/ipod name/" |
| 01:10:03 | linuxstb | amiconn: Sure |
| 01:11:31 | | Join evilnick [0] (i=60e8ce0d@gateway/web/ajax/mibbit.com/x-af43661a2407ddc4) |
| 01:11:50 | amiconn | The relevant chapter is "Advanced Topics->Rockbox in Flash" in http://www.jens-arnold.net/Rockbox/rockbox-player-r18829M-081019.pdf http://www.jens-arnold.net/Rockbox/rockbox-recorder-r18829M-081019.pdf and http://www.jens-ondiofmarnold.net/Rockbox/rockbox−−r18829M-081019.pdf |
| 01:13:01 | | Quit linuxstb (Remote closed the connection) |
| 01:13:16 | amiconn | They're slightly different. There are also http://www.jens-arnold.net/Rockbox/rockbox-ondiosp-r18829M-081019.pdf and http://www.jens-arnold.net/Rockbox/rockbox-fmrecorder-r18829M-081019.pdf , but there are only there for completeness. They only contain the same text blocks as the first 3, just in partially different combinations |
| 01:14:32 | amiconn | Err, the Ondio FM link should be http://www.jens-arnold.net/Rockbox/rockbox-ondiofm-r18829M-081019.pdf of course |
| 01:17:26 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 01:18:18 | amiconn | Here's the diff as well: http://www.jens-arnold.net/Rockbox/archos_flashing.diff . Practically everything has changed though... |
| 01:18:42 | linuxstb | OK, I think I'll just look at the PDFs... |
| 01:22:32 | | Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 01:22:59 | | Quit MelaGo () |
| 01:25:23 | | Quit Thundercloud (Remote closed the connection) |
| 01:25:48 | | Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) |
| 01:26:33 | | Quit Thundercloud (Remote closed the connection) |
| 01:26:41 | | Quit Nico_P (Remote closed the connection) |
| 01:28:27 | linuxstb | amiconn: I would write "three to five" instead of "3..5", (I was always taught that digits less than 10 should be written as words). Also, you say "several", but then only list two reasons. You could rephrase it to say something like "The main reason to change this is to increase the startup time of your player. The Archos bootloader is rather slow, and by putting Rockbox in flash you can decrease the startup time to around three to f |
| 01:28:27 | linuxstb | ive seconds. Furthermore, you..." |
| 01:28:41 | | Join gartral [0] (n=Gareth@adsl-75-33-82-140.dsl.bcvloh.sbcglobal.net) |
| 01:28:45 | linuxstb | (it also says "2 files" later on) |
| 01:28:54 | amiconn | There are 3 reasons when rombox is available, hence "several" |
| 01:29:03 | gartral | good evening everyone |
| 01:29:08 | amiconn | (Player, Ondio SP) |
| 01:29:17 | | Quit MethoS-- (Read error: 104 (Connection reset by peer)) |
| 01:29:24 | amiconn | I'll change the small numbers to works |
| 01:30:15 | | Quit Munkie ("Leaving") |
| 01:30:32 | linuxstb | amiconn: OK, but the manual I'm reading only lists two... (ondiofm) |
| 01:30:33 | gartral | has anyone built and released an updated rbutil? my build system has a dead hard drive atm |
| 01:31:21 | amiconn | linuxstb: Yes, two or three, depending on the availability of rombox. |
| 01:31:38 | linuxstb | "it’s gonna program" -> "it is going to program" |
| 01:31:43 | | Join nuonguy [0] (n=john@c-71-198-1-139.hsd1.ca.comcast.net) |
| 01:31:54 | | Quit syn4pse ("ChatZilla 0.9.83 [Firefox 3.0.3/2008101315]") |
| 01:32:13 | amiconn | That was laziness... (reusing parts of the old text) thanks. |
| 01:32:34 | gartral | has anyone built and released an updated rbutil? my build system has a dead hard drive at the moment |
| 01:35:09 | amiconn | linuxstb: Hmm, *increase* startup time? That would be a reason against changing it ;) |
| 01:35:29 | linuxstb | amiconn: Just testing that you're still awake... |
| 01:35:35 | amiconn | hehe |
| 01:35:47 | linuxstb | (i'm obviously not) |
| 01:36:55 | gartral | lol, nvm me, i was blind and wasnt reading the "b" above the 1.0 entry in the rbutil page |
| 01:37:17 | gartral | (gives everyone a fresh hot cup of coffee) |
| 01:37:59 | saratoga | linuxstb: how did you calculate the codec memory usage for flac? |
| 01:38:11 | saratoga | just dig through the map looking for the largest addresses? |
| 01:38:13 | linuxstb | saratoga: I just manually looked at the .map |
| 01:39:06 | linuxstb | amiconn: No more comments on the ondiofm manual - it reads fine to me. |
| 01:41:27 | | Nick JdGordon|zzz is now known as JdGordon (n=jonno@rockbox/developer/JdGordon) |
| 01:41:28 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 01:41:36 | linuxstb | amiconn: Recorder manual seems fine. |
| 01:43:25 | linuxstb | amiconn: Player seems fine as well. |
| 01:43:46 | * | amiconn found a grammar mistake in the extra Ondio warning for Ondio SP |
| 01:44:13 | | Part gartral |
| 01:45:07 | linuxstb | amiconn: "These versions..." ? |
| 01:45:14 | amiconn | yep |
| 01:45:44 | amiconn | I had a mini-\opt there, but this was obviously not enough |
| 01:45:48 | linuxstb | And "they are" in the next sentence. |
| 01:46:26 | amiconn | yup |
| 01:46:35 | linuxstb | Is it possible to detect Archos fw versions? Maybe with a crc? |
| 01:46:49 | amiconn | You mean in RoLo? |
| 01:47:08 | linuxstb | I guess I do... |
| 01:49:42 | amiconn | Doesn't look like it |
| 01:49:47 | saratoga | is there a "no plugins" make option ? It'd be nice to not have to wait for them to build and then copy over |
| 01:50:14 | amiconn | Well, a crc might work, but then the rockbox binary would need to know these "bad" CRCs |
| 01:50:36 | amiconn | saratoga: 'make bin' |
| 01:50:36 | linuxstb | saratoga: "make bin" |
| 01:50:53 | * | linuxstb lost by a microsecond... |
| 01:50:55 | pixelma | amiconn won ;) |
| 01:51:10 | * | pixelma loses |
| 01:51:22 | linuxstb | saratoga: "make help" should show you the options |
| 01:51:45 | saratoga | ok thanks |
| 01:52:06 | saratoga | faad only mallocs 36KB for me on a 3 minute AAC-LC file |
| 01:52:27 | amiconn | linuxstb: If rockbox wouldn't have grown so big, we could have used the size. The flash-update archos firmwares are significantly larger than the normal on-disk firmware files. But rockbox is now closer in size to the bad ones... |
| 01:52:27 | linuxstb | faad or the mp4 parser? |
| 01:52:32 | JdGordon | linuxstb: any idea how much of that e200v2 code works? does it build a working bin at all? |
| 01:53:13 | linuxstb | JdGordon: It compiles.. But it's still very incomplete - someone (maybe me...) needs to finish reading an OF disassembly and implementing the funcitons. |
| 01:53:37 | amiconn | The CRC method may be an idea for the RoLo rework |
| 01:53:40 | * | amiconn sighs |
| 01:53:53 | saratoga | linuxstb: 36KB is as large as the mem_ptr in the malloc buffer gets |
| 01:54:24 | saratoga | i just edited the malloc,calloc,realloc functions to print the mem_ptr whenever they're called and started playing files |
| 01:55:46 | | Join [i][B][e][n] [0] (n=Bensawso@unaffiliated/bensawsome) |
| 01:56:13 | linuxstb | I wouldn't call 36KB "only" - it should grow linearly with the size of the mp4 file. So a 30-minute file would be 360KB, and a 2-hour file would be trouble... |
| 01:58:29 | saratoga | i still don't understand why such large seek tables are needed for MP4 |
| 01:59:04 | saratoga | i started looking through the mp4 specs, but the format is surprisingly complicated |
| 02:00 |
| 02:00:29 | linuxstb | You're surprised an MPEG standard is complex? ;) |
| 02:01:43 | amiconn | linuxstb: I've now committed the reworked flashing chapter. Thanks for checking! |
| 02:01:54 | linuxstb | You're welcome. |
| 02:02:00 | JdGordon | are these mallocs used for the life of the track? |
| 02:02:34 | * | amiconn will commit it (with an extra remark regarding the 8MB mod) to the 3.0 branch tomorrow, for building the 3.0.1 manuals |
| 02:03:03 | linuxstb | JdGordon: Yes, I'm pretty sure they all will be. |
| 02:03:08 | saratoga | JdGordon: most of them are seek tables which could be needed whenever someone seeks, the rest are maybe 16KB or so of internal decoder buffers |
| 02:03:47 | saratoga | does ogg not malloc? |
| 02:04:50 | JdGordon | if the seektables arnt available it can stll seek? it just has to do alot of extra work? |
| 02:05:26 | saratoga | ah Ogg duplicates the codeclib malloc functions |
| 02:05:34 | saratoga | how handy |
| 02:06:28 | amiconn | Well, ogg does this for a reason, iirc |
| 02:06:31 | | Quit kharo (Read error: 110 (Connection timed out)) |
| 02:06:51 | amiconn | tomal implemented a malloc in the codec ram for ogg, in order to make it work on the iFP |
| 02:07:08 | amiconn | The iFP doesn't have enough ram for the extra malloc buffer |
| 02:07:18 | saratoga | JdGordon: I've been trying to figure that out |
| 02:07:27 | * | amiconn guesses that with today's change, no codec would work anymore on the iFP |
| 02:08:34 | | Join kharo [0] (n=teemu@a88-114-245-92.elisa-laajakaista.fi) |
| 02:09:09 | | Quit sarixe (Read error: 110 (Connection timed out)) |
| 02:11:59 | | Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) |
| 02:13:29 | linuxstb | amiconn: Today's commit was a synced version of a patch by tomal |
| 02:13:52 | amiconn | I doubt he increased the codec buffer to 1MB though |
| 02:14:14 | linuxstb | No, but the point is that it's now a unified buffer - that's what tomal wanted. |
| 02:14:49 | amiconn | Yes, but 1MB would be too big for the iFP, the same way as 512KB codec buffer + 512KB malloc buffer are too big |
| 02:15:09 | linuxstb | Yes, but I'm sure it's not 1MB there |
| 02:16:00 | linuxstb | Prior to today's commit, the codec malloc function only used the 512KB malloc buffer - as far as I could see, the unused part of the codec buffer was never used. |
| 02:16:47 | linuxstb | Tomal's patch means that malloc uses the codec buffer - which we increased (for now) to 1MB on the large-mem targets, and got rid of the malloc buffer. |
| 02:20:57 | | Join axionix_ [0] (n=axion@cpe-67-242-94-6.nycap.res.rr.com) |
| 02:25:12 | linuxstb | saratoga: IIRC, the information about the duration and sizes of frames is stored in the STTS chunk. Looking at the ALAC codec (alac.c), the decode_frame() function doesn't return a "bytes_consumed" value - that's taken from the STTS chunk. AAC also uses the STTS chunk values when decoding frames. |
| 02:25:20 | linuxstb | So there are two issues - 1) Can the decoding happen without the info in the STTS chunk; 2) How do we seek without it? |
| 02:25:37 | | Join webguest21 [0] (n=18aaaecf@gateway/web/cgi-irc/labb.contactor.se/x-a9b5e3a6cf35043b) |
| 02:27:26 | saratoga | linuxstb: its hard to imagine they require you to have a huge lookup table to seek through an audio file |
| 02:27:35 | saratoga | perhaps some of the atoms in the stream have time stamps or something similar |
| 02:28:36 | | Quit webguest21 (Client Quit) |
| 02:30:31 | | Join webguest44 [0] (n=18aaaecf@gateway/web/cgi-irc/labb.contactor.se/x-98012389bc7dbf8a) |
| 02:31:09 | | Quit webguest44 (Client Quit) |
| 02:31:48 | | Quit axionix (Read error: 110 (Connection timed out)) |
| 02:32:28 | | Quit kachna (Read error: 113 (No route to host)) |
| 02:44:34 | amiconn | linuxstb: Actually an .ajz file has both its size and a checksum (no real crc, just a sum) in the header |
| 02:45:51 | amiconn | So checking both should be sufficient for detecting the bad archos firmwares. Problem is how to detect whether rockbox is flashed or not... |
| 02:51:44 | | Quit Tetracomm (Read error: 104 (Connection reset by peer)) |
| 02:52:53 | linuxstb | amiconn: That makes that part easy - and I see those values are already read by rolo... |
| 02:53:29 | | Join Tetracomm [0] (n=nicholas@72.252.29.2) |
| 02:55:57 | | Part pixelma |
| 02:56:22 | | Join pixelma2 [0] (n=marianne@rockbox/staff/pixelma) |
| 03:00 |
| 03:02:01 | *** | Saving seen data "./dancer.seen" |
| 03:09:56 | | Join sarixe [0] (n=sarixe@ool-435407e9.dyn.optonline.net) |
| 03:17:50 | | Quit [i][B][e][n] (Read error: 104 (Connection reset by peer)) |
| 03:17:51 | | Join Bensawesome [0] (n=Bensawso@unaffiliated/bensawsome) |
| 03:18:56 | | Quit saratoga ("CGI:IRC (EOF)") |
| 03:20:23 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 03:20:39 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-b61d1122c4de7d6f) |
| 03:21:00 | | Join reacocard [0] (n=reacocar@134.173.59.155) |
| 03:25:26 | | Quit Bensawesome (Read error: 104 (Connection reset by peer)) |
| 03:25:58 | | Join Bensawesome [0] (n=Bensawso@unaffiliated/bensawsome) |
| 03:30:40 | | Quit soap (Remote closed the connection) |
| 03:40:11 | | Quit intrados (Connection timed out) |
| 03:40:17 | | Join soap [50] (n=soap@rockbox/staff/soap) |
| 03:41:42 | | Nick Bensawesome is now known as [i][B][e][n] (n=Bensawso@unaffiliated/bensawsome) |
| 03:42:26 | | Quit axionix_ (Read error: 104 (Connection reset by peer)) |
| 03:44:51 | | Quit Tetracomm ("Visit: www.kompulsa.com") |
| 03:46:54 | | Join EspeonEefi [0] (i=espeonee@STRATTON-SIXTY-EIGHT.MIT.EDU) |
| 03:49:39 | | Quit [i][B][e][n] ("t3h 1337 h4X0R sT4t80t h42 QuiT") |
| 03:51:49 | | Quit DerDome (Nick collision from services.) |
| 03:51:50 | | Join DerDome1 [0] (n=DerDome@dslb-082-083-247-154.pools.arcor-ip.net) |
| 03:52:02 | | Nick DerDome1 is now known as DerDome (n=DerDome@dslb-082-083-247-154.pools.arcor-ip.net) |
| 03:52:18 | | Quit Strife89 ("Leaving") |
| 03:59:18 | | Join cool_walking_ [0] (i=cb3b81c3@gateway/web/ajax/mibbit.com/x-5298bca6f9389c0f) |
| 04:00 |
| 04:19:49 | | Nick HBK- is now known as HBK (i=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
| 04:20:47 | | Join blkhawk- [0] (i=HydraIRC@g227066226.adsl.alicedsl.de) |
| 04:23:46 | | Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) |
| 04:29:06 | | Join kharo1 [0] (n=teemu@a88-114-245-92.elisa-laajakaista.fi) |
| 04:29:35 | | Join miepchen^schlaf [0] (n=miepchen@p579ECEC0.dip.t-dialin.net) |
| 04:30:22 | | Quit Kopfgeldjaeger (Read error: 104 (Connection reset by peer)) |
| 04:35:19 | | Quit miepchen^schlaf_ (Connection timed out) |
| 04:36:24 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 04:38:10 | | Quit blkhawk (Read error: 110 (Connection timed out)) |
| 04:41:05 | | Quit kharo (Read error: 110 (Connection timed out)) |
| 04:49:08 | | Quit obo ("bye") |
| 04:57:31 | | Join gkffjcs [0] (n=john-cha@131.156.249.167) |
| 04:57:43 | | Quit JdGordon ("Konversation terminated!") |
| 04:59:01 | gkffjcs | If I make a playlist on my ipod, under rock box, how do I save it? I get to the nameing dialog, and then give it a name, but then I cannot save it, there is no option to save, and all the buttons just return me to the previous menus. |
| 04:59:54 | | Join JdGordon [0] (n=Miranda@c211-28-145-137.smelb2.vic.optusnet.com.au) |
| 05:00 |
| 05:00:36 | scorche | the manual should go into this... |
| 05:00:45 | | Quit mc2739 () |
| 05:02:05 | *** | Saving seen data "./dancer.seen" |
| 05:04:08 | | Join rocky_ba [0] (i=74e1722a@gateway/web/ajax/mibbit.com/x-7aa91f46b227afa4) |
| 05:04:10 | | Join mc2739 [0] (n=mc2739@cpe-67-10-238-175.satx.res.rr.com) |
| 05:10:28 | cool_walking_ | gkffjcs: PLAY/PAUSE confirms those naming dialogs. |
| 05:10:32 | | Join Tetracomm [0] (n=nicholas@72.252.29.2) |
| 05:12:04 | | Part toffe82 |
| 05:12:14 | | Part mc2739 |
| 05:12:49 | | Join mc2739 [0] (n=mc2739@cpe-67-10-238-175.satx.res.rr.com) |
| 05:13:06 | | Join someone972 [0] (n=someone9@VDSL-151-118-8-114.DNVR.QWEST.NET) |
| 05:13:49 | | Quit mc2739 () |
| 05:14:22 | | Quit someone972 (Client Quit) |
| 05:17:54 | | Part rocky_ba |
| 05:18:11 | | Quit Tetracomm (Read error: 104 (Connection reset by peer)) |
| 05:24:19 | | Join devslashnull [0] (n=delvslas@pool-71-104-116-13.lsanca.dsl-w.verizon.net) |
| 05:25:38 | | Quit devslashnull (Client Quit) |
| 05:25:56 | | Join devslashnull [0] (n=delvslas@pool-71-104-116-13.lsanca.dsl-w.verizon.net) |
| 05:26:08 | gkffjcs | thank you cool_walking_ |
| 05:28:59 | cool_walking_ | gkffjcs: More info: http://download.rockbox.org/manual/rockbox-ipodvideo/rockbox-buildch4.html#x7-430004.1.3 |
| 05:29:03 | | Nick blkhawk- is now known as blkhawk (i=HydraIRC@g227066226.adsl.alicedsl.de) |
| 05:29:21 | | Quit devslashnull (Client Quit) |
| 05:35:33 | | Quit HBK () |
| 05:35:39 | | Join HBK [0] (i=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
| 05:40:18 | XavierGr | JdGordon: ping |
| 05:46:46 | JdGordon | hey |
| 05:50:02 | XavierGr | Just updated the scroll padding patch |
| 05:50:12 | XavierGr | wow I feel stupid that I didn't think of prefix/suffix |
| 05:50:44 | | Quit Horscht ("User was distributing pornography on server; system seized by FBI") |
| 05:50:53 | XavierGr | after hours fighting to handle properly quotes and strings the solution was much more simple |
| 05:50:54 | XavierGr | thanks |
| 05:51:44 | JdGordon | hehe, sorry i didnt tihnk of it sooner also :p |
| 05:52:15 | XavierGr | also about the length of the padding. 10-20 can be quite small for large screens with small fonts |
| 05:52:26 | XavierGr | that's why I ended up on LCD_WIDTH / 4 |
| 05:53:01 | XavierGr | also it muches the logic of scroll_engine.h (before the patch) |
| 05:53:02 | JdGordon | yeah, but if they are all spaces then its very obvious where the line ends anyway |
| 05:53:18 | XavierGr | muches = matches |
| 05:54:20 | XavierGr | SCROLL_LINE_SIZE is defined by LCD_WIDTH even if the array holds characters and not pixels |
| 05:54:36 | XavierGr | by the way why is this array so big, I didn't have to change it and the padding still fits |
| 05:57:56 | XavierGr | my logic is that on a huge screen (say ipod 5.5) LCD_WIDTH / 4 is 60 characters, which on all fonts will cover the extreme preferrence of one whole screen of padding. |
| 05:58:31 | XavierGr | of course hardcoding to 60 characters won't make sense for ondio which will need quite fewer characters to fill in the screen |
| 05:58:47 | JdGordon | which array is that? |
| 05:58:55 | JdGordon | SCROLL_LINE_SIZE..? |
| 05:59:14 | XavierGr | in scroll_engine.h scroll_info.line |
| 05:59:41 | JdGordon | thats not the array to hold the full text of the line being scrolled is it? |
| 06:00 |
| 06:00:42 | XavierGr | yes that's it |
| 06:01:05 | XavierGr | that array is then put on the screen with a different offset (scrolling mechanism) |
| 06:01:07 | JdGordon | then it needs to be at least MAX_PATH long |
| 06:01:39 | XavierGr | yeah and it needs another half screen for the next append of the string |
| 06:01:40 | JdGordon | oh, or it is the subpart of the string being displayed? |
| 06:01:53 | XavierGr | the part I don't get is the 3*LCD_WIDTH/2 |
| 06:01:58 | XavierGr | and without the /2 for the player |
| 06:02:09 | * | JdGordon doesnt know this code much |
| 06:02:10 | XavierGr | JdGordon: AFAIU is the whole string |
| 06:02:24 | | Quit Seed ("cu, Andre") |
| 06:02:31 | JdGordon | ... im also in windows atm so dont even have the code here |
| 06:02:34 | JdGordon | lemme reboot.... |
| 06:02:46 | | Quit JdGordon (Read error: 54 (Connection reset by peer)) |
| 06:05:17 | | Join JdGordon [0] (n=jonno@c211-28-145-137.smelb2.vic.optusnet.com.au) |
| 06:05:20 | | Quit HellDragon (Client Quit) |
| 06:05:25 | XavierGr | the scrolling mechanism takes that string and types it to the screen with an offset (and that is how scrolling is achieved) |
| 06:06:21 | XavierGr | JdGordon: so it is the full string plus half of the screen which some part of the string is reappended to make scrolling look normal |
| 06:06:36 | * | JdGordon wonders if scrolling could be redone with viewports so we could use a pixel spacing between start and end |
| 06:11:38 | ameyer | speaking of : |
| 06:11:41 | ameyer | ern |
| 06:11:49 | ameyer | darn keyboard |
| 06:11:56 | ameyer | anyway... |
| 06:14:25 | XavierGr | JdGordon: the first version of the patch pads spaces calculated from pixels/font width |
| 06:14:49 | XavierGr | but then some people said that the best would be for the user to select its own padding string |
| 06:15:08 | JdGordon | yeah, I sort of followed the discussoin |
| 06:15:28 | | Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) |
| 06:16:18 | XavierGr | so what do you think, is it commitable? Any more comments? |
| 06:18:23 | JdGordon | ... by overkill I meant that its wasting too much space... imo adding any more than half a dozen spaces doesnt make it any *more* readable... so having such a high limit is a waste |
| 06:19:32 | XavierGr | Well, I for one, like at least half the screen with spaces. So I took as base the extreme of one screen (beyond that it isn't visible) |
| 06:19:35 | JdGordon | but apart from that it looks ok |
| 06:22:14 | XavierGr | okay then if you think it is good to go and you are comfortable with commiting it I would be glad. Right now though I have to go to sleep. Thanks for the tip again. :) |
| 06:25:29 | | Quit Zarggg () |
| 06:28:12 | | Quit XavierGr () |
| 06:29:05 | | Join intrados [0] (n=intrados@rdrt-164-107-204-170.resnet.ohio-state.edu) |
| 06:36:34 | | Join kushal_12_27_200 [0] (n=kushal@12.169.180.178) |
| 06:41:00 | | Join Tetracomm [0] (n=nicholas@72.252.29.2) |
| 07:00 |
| 07:02:09 | *** | Saving seen data "./dancer.seen" |
| 07:28:57 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 07:36:17 | | Quit BHSPitMonkey (Remote closed the connection) |
| 07:38:31 | | Quit nelek ("shutdown -h 0") |
| 07:43:59 | | Quit n17ikh|Lappy () |
| 07:44:37 | | Join HBK- [0] (i=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
| 07:46:18 | | Quit Tetracomm ("Visit: www.kompulsa.com") |
| 07:52:00 | | Join num1 [0] (n=brian@unaffiliated/num1) |
| 07:53:19 | | Quit miepchen^schlaf () |
| 07:57:22 | | Nick num1 is now known as num1_ (n=brian@unaffiliated/num1) |
| 08:00 |
| 08:01:54 | | Quit HBK (Read error: 110 (Connection timed out)) |
| 08:03:27 | | Quit kushal_12_27_200 ("Leaving") |
| 08:03:47 | | Quit DerDome ("Leaving.") |
| 08:05:29 | | Quit BigBambi (Remote closed the connection) |
| 08:06:50 | | Join goffa [0] (n=goffa@216.220.23.105) |
| 08:07:48 | | Quit agaffney (Read error: 104 (Connection reset by peer)) |
| 08:13:47 | | Quit joe2371 (Remote closed the connection) |
| 08:14:02 | | Join joe2371 [0] (n=joe@c-69-138-250-166.hsd1.md.comcast.net) |
| 08:14:16 | | Quit bmbl (Read error: 104 (Connection reset by peer)) |
| 08:15:18 | | Join Zagor [0] (n=bjorn@82.99.7.155) |
| 08:16:09 | | Join agaffney [0] (n=agaffney@gentoo/developer/pdpc.active.agaffney) |
| 08:19:34 | | Quit goffa_ (Read error: 110 (Connection timed out)) |
| 08:27:41 | | Quit jhulst (Remote closed the connection) |
| 08:29:00 | | Join Rob2223 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) |
| 08:34:35 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 08:44:21 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
| 08:47:44 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
| 08:48:55 | | Quit GodEater ("http://www.mibbit.com ajax IRC Client") |
| 08:56:16 | | Join Bagderr [241] (n=daniel@rockbox/developer/bagder) |
| 08:56:39 | | Nick Bagderr is now known as B4gder (n=daniel@rockbox/developer/bagder) |
| 08:57:56 | | Quit advcomp2019 (Read error: 104 (Connection reset by peer)) |
| 08:58:47 | | Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) |
| 09:00 |
| 09:02:14 | *** | Saving seen data "./dancer.seen" |
| 09:02:49 | | Join reacocard_ [0] (n=reacocar@WL-48.CINE.HMC.Edu) |
| 09:06:39 | | Join lasser [0] (n=chatzill@W92b1.w.pppool.de) |
| 09:06:58 | | Join petur [50] (n=petur@rockbox/developer/petur) |
| 09:08:32 | | Quit reacocard (Read error: 110 (Connection timed out)) |
| 09:14:56 | | Nick reacocard_ is now known as reacocard (n=reacocar@WL-48.CINE.HMC.Edu) |
| 09:23:03 | | Quit Bagder (Read error: 110 (Connection timed out)) |
| 09:23:48 | | Join kachna [0] (n=kachna@r4ax178.net.upc.cz) |
| 09:26:50 | | Quit pixelma2 ("-") |
| 09:26:56 | | Join pixelma [50] (i=pixelma@rockbox/staff/pixelma) |
| 09:29:47 | | Quit joe2371 ("Lost terminal") |
| 09:32:15 | | Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) |
| 09:46:36 | | Join Nibbl [0] (n=Nibbler@e181108183.adsl.alicedsl.de) |
| 09:50:26 | | Quit JdGordon ("Konversation terminated!") |
| 09:53:40 | | Quit kachna (Read error: 113 (No route to host)) |
| 10:00 |
| 10:07:47 | | Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) |
| 10:11:32 | | Join MethoS [0] (n=clemens@dyndsl-085-016-164-116.ewe-ip-backbone.de) |
| 10:13:24 | | Join Slack_ [0] (n=brett@12-218-63-169.client.mchsi.com) |
| 10:22:32 | | Quit MethoS (Read error: 104 (Connection reset by peer)) |
| 10:27:54 | | Quit Thundercloud (Remote closed the connection) |
| 10:44:17 | | Join GodEater [0] (i=c2cbc962@gateway/web/ajax/mibbit.com/x-01e46139ed5493ac) |
| 10:51:06 | | Quit reacocard (Read error: 104 (Connection reset by peer)) |
| 10:52:13 | | Join kachna [0] (n=kachna@r3g248.net.upc.cz) |
| 10:52:24 | | Quit cool_walking_ ("http://www.mibbit.com ajax IRC Client") |
| 10:52:34 | | Quit nuonguy ("This computer has gone to sleep") |
| 10:54:56 | | Quit Slack_ ("Ex-Chat") |
| 11:00 |
| 11:02:15 | *** | Saving seen data "./dancer.seen" |
| 11:11:21 | B4gder | with _some_ targets getting a 3.0.1 the download/release page gets a bit tricky |
| 11:11:29 | B4gder | I mean, how to write on it to describe the situation |
| 11:12:44 | Zagor | do we even have to? |
| 11:13:05 | | Quit culture (Connection timed out) |
| 11:13:26 | B4gder | I think so, since the users who experienced problems with 3.0 might want to know that it is now 3.0.1 |
| 11:14:56 | linuxstb | Probably too late to suggest this, but couldn't we just bump every target to 3.0.1 and have a changelog showing what changed - i.e. that it is only different to 3.0 for certain devices. |
| 11:15:20 | B4gder | we can still do that, if that's what we really want |
| 11:15:28 | Zagor | "UPDATE: An update, version 3.0.1, has been released to fix problems with xxx and yy on targets zzz and nnn." |
| 11:15:43 | Zagor | uh double update looks a bit silly, but you get the idea |
| 11:16:04 | scorche | i would rather have that than "why havent you guys released 3.0.1 for my ipod yet? I dont want to be behind!" |
| 11:16:08 | GodEater | I think that's the best plan |
| 11:16:34 | Zagor | scorche: well the other side of that coin is "what is the difference between 3.0 and 3.0.1?" |
| 11:16:53 | linuxstb | Zagor: The answer is a link to the changelog |
| 11:16:54 | scorche | Zagor: and the changelog or notice should take care of that |
| 11:16:59 | Zagor | or worse: "3.0.1 sounds much worse than 3.0 on my ipod. can I have 3.0 back please?" |
| 11:17:04 | B4gder | haha |
| 11:17:17 | GodEater | can't wait to get one of those ;) |
| 11:22:21 | | Quit kachna (Read error: 110 (Connection timed out)) |
| 11:23:08 | | Join kharo [0] (n=teemu@a88-114-245-92.elisa-laajakaista.fi) |
| 11:24:50 | | Quit kharo1 (Read error: 110 (Connection timed out)) |
| 11:24:51 | pixelma | both sound like a BoS anyways... |
| 11:29:11 | B4gder | http://daniel.haxx.se/blog/2007/10/01/rockbox-on-dell-digital-jukebox/#comment-1016 |
| 11:29:30 | B4gder | some people also obviously believe in secret development somewhere not publicly visible... |
| 11:31:23 | Llorean | B4gder: As can be seen by how many people thought 3.0, the first time, was gonna have a bunch of new features. |
| 11:31:32 | B4gder | yeah |
| 11:31:57 | B4gder | I guess I just never really learn to expect this |
| 11:37:43 | Llorean | Well, I think part of it is that people expect it to be similar to some other softwares (take GCC) where you have the 3.x and the 4.x branches. |
| 11:38:06 | Llorean | So when we did Rockbox 3.0 they expected all the previous versions had been on the 2.5 branch, and maybe they just didn't know where to get 3.x test builds. |
| 11:38:45 | linuxstb | Lots of projects do that though - have a "new features" branch. |
| 11:38:51 | B4gder | yeah |
| 11:39:24 | linuxstb | Maybe we should call "trunk" the "3.1" branch to make it clearer. |
| 11:40:31 | | Join vitja_ [0] (n=vitja@79.120.98.174) |
| 11:53:56 | | Join balou_ [0] (i=balou@cl-1844.ham-01.de.sixxs.net) |
| 11:53:59 | balou_ | hi |
| 11:55:21 | balou_ | is there a hw platform that is currently sold which is supported by rockbox? |
| 11:55:54 | balou_ | ipods don't work anymore, i dunno when iriver quit producing its players, and many other players seem to only work in older releases... |
| 11:56:00 | B4gder | nope :( |
| 11:56:16 | B4gder | but there is work in progress on several current models |
| 11:56:18 | Zagor | balou_: only used/refurbished ones |
| 11:57:42 | Zagor | balou_: if you're in the US, you can get rockbox-compatible sansas from ... uh what are they called again? |
| 11:58:06 | scorche | froobi |
| 11:58:07 | amiconn | balou_: What do you mean, only seem to work in older releases? |
| 11:58:10 | balou_ | yeah.. but ipod videos are getting scarcer and scarcer |
| 11:58:13 | Zagor | scorche: ah, thanks |
| 11:58:21 | balou_ | amiconn, old hardware revisions |
| 11:58:31 | balou_ | btw, I'm not in the us |
| 11:58:32 | linuxstb | balou_: There are many better devices for Rockbox than the ipod video |
| 11:59:18 | balou_ | what would you suggest? |
| 11:59:33 | B4gder | rockbox.org/wiki/BuyersGuide perhaps? |
| 11:59:36 | linuxstb | If you want a hard-disk player, then the Gigabeat F is very good value. |
| 12:00 |
| 12:01:11 | balou_ | B4gder, good link :) |
| 12:01:40 | * | Zagor removes the "available" column |
| 12:02:27 | balou_ | It's a pity... I think there _would_ be a market for dap with flac support and for example digital output |
| 12:02:50 | markun | I just update unifont: "As of 20 June 2008 (by coincidence the Summer Solstice), the GNU Unifont has a glyph for every printable code point in the Unicode Basic Multilingual Plane (BMP)" |
| 12:02:51 | balou_ | it just seems that no manufacturer got that yet... |
| 12:03:36 | markun | balou_: the iriver h1xx has digital out |
| 12:04:53 | markun | and with rockbox it plays back flac of course |
| 12:05:08 | balou_ | I know, but that player has been out of production for a few years now |
| 12:05:38 | linuxstb | That shouldn't stop you buying it if it has the features you want. |
| 12:07:10 | markun | balou_: and if you want to do some DIY work you could probably make a digital-out for the Gigabeat F dock connector :) (it has the I2S signal) |
| 12:08:17 | balou_ | sure, but I'd still like a brand new digital-out sporting rockbox-by-default hires display player more than an old player bought off ebay |
| 12:08:20 | balou_ | ;) |
| 12:08:58 | GodEater | sadly no such thing exists - so you have to compromise |
| 12:10:18 | balou_ | ...or petition a big dap manufacturer |
| 12:10:36 | scorche | petitions dont work |
| 12:10:36 | GodEater | good luck with that |
| 12:11:00 | B4gder | I'm sure they just hadn't thought about it so a quick call will fix it |
| 12:11:32 | linuxstb | balou_: Have you found such a device at all? i.e. one without Rockbox support? |
| 12:12:09 | | Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) |
| 12:12:38 | balou_ | linuxstb, no, except if you count portable dvd players with digital out |
| 12:12:41 | | Join DerPapst [0] (n=DerPapst@dhcp-25-203.fh-friedberg.de) |
| 12:12:59 | markun | linuxstb: according to this the Cowon Q5 will http://www.head-fi.org/forums/f15/portable-sources-w-digital-output-listing-255819/ |
| 12:13:03 | GodEater | we don't count them |
| 12:13:38 | | Join moos [0] (i=moos@81-66-141-133.rev.numericable.fr) |
| 12:14:49 | linuxstb | markun: Hmm, a 5" LCD makes it hard to think of it as a portable audio player... |
| 12:14:57 | balou_ | wow... a new dap that will actually have digital out |
| 12:15:04 | B4gder | 5"! |
| 12:15:14 | linuxstb | http://www.purelygadgets.co.uk/showproduct.php?prodid=14963&wysiwyg=10 |
| 12:15:42 | linuxstb | Anyone know what an "Alchemy" processor is? |
| 12:15:53 | amiconn | markun: That was a bad commit... |
| 12:16:05 | markun | amiconn: what happened? |
| 12:16:07 | * | linuxstb googles and sees it's a MIPS based CPU |
| 12:16:08 | | Join BigBambi [0] (i=86ceaf40@rockbox/staff/BigBambi) |
| 12:16:09 | balou_ | okay... a bit big.. |
| 12:16:28 | amiconn | markun: Check the revision log: http://svn.rockbox.org/viewvc.cgi/trunk/fonts/16-GNU-Unifont.bdf?view=log r18342... |
| 12:16:34 | | Join M0rtus [0] (n=chatzill@87-194-163-210.bethere.co.uk) |
| 12:16:55 | amiconn | Unifont *was* already updated to 20080820, but with the unnecessary junk stripped, which you now re-added |
| 12:16:59 | B4gder | funny how the MIPS arch seems to still survive |
| 12:17:15 | markun | amiconn: oops, sorry :( |
| 12:17:35 | markun | I'll revert at once |
| 12:17:36 | B4gder | Q5 is claimed to run windwos CE too |
| 12:17:51 | linuxstb | So it's a tablet computer... |
| 12:18:28 | B4gder | yes, with wifi and all |
| 12:18:29 | balou_ | ugh... |
| 12:19:01 | B4gder | quite an n810 competitor I'd say |
| 12:19:17 | * | linuxstb wonders if we'll ever see hard-disk based portable _audio_ players again... |
| 12:19:38 | markun | amiconn: I just noticed that it had more glyps. I'll be more careful next time. |
| 12:21:10 | M0rtus | hello all |
| 12:21:12 | amiconn | Sure it had more glyphs than our version... but only ones which you'll never get to see for any valid unicode text. I took 20080820 and stripped those, using a perl script |
| 12:24:29 | M0rtus | guys im a right in thinking that the USB does nothing on the sansa still? |
| 12:24:48 | BigBambi | It should restart to the Sansa firmware |
| 12:24:52 | BigBambi | And then connect |
| 12:26:09 | ameyer | emphasis on "should" |
| 12:26:33 | * | ameyer glares at whatever build server is screwing up portalplayer builds |
| 12:28:44 | M0rtus | last time i tried rockbox it did just that........... and then would go back to rockbox without a reinstall :( |
| 12:28:56 | BigBambi | eh? |
| 12:29:04 | pixelma | ameyer: what do you mean? |
| 12:29:32 | BigBambi | M0rtus: It should reboot to the Sansa firmware to let you copy files, then when you restart, start Rockbox like normal |
| 12:30:21 | M0rtus | might give it another try............ last time it would restart to sansa f/w then copy files......... reboot and sansa firmware still. |
| 12:30:37 | BigBambi | That shouldn't happen |
| 12:31:01 | BigBambi | Another way is to boot to the Sansa firmware, then insert USB (manual tells you how to dual boot), or plug in USB from off |
| 12:31:18 | pixelma | there's a bug with the automatic reboot though that appears in one build and vanishes in the next, but you can always get the OF for USB by either plugging from off state or start the OF manually |
| 12:31:30 | ameyer | I mean some official builds freeze on usb connect but I've never had a build I built myself that didn't restart to OF on usb connect |
| 12:32:13 | BigBambi | And you have verified that all the non-working ones come from the same build server? |
| 12:32:22 | ameyer | I |
| 12:32:24 | ameyer | erm |
| 12:32:37 | ameyer | I'm not entirely sure how I'd do that |
| 12:32:52 | BigBambi | On the build details page you can see which server built which build |
| 12:32:59 | BigBambi | Otherwise it is pure speculation |
| 12:33:21 | BigBambi | ameyer: http://build.rockbox.org/dev.cgi |
| 12:36:42 | markun | amiconn: git really doesn't like these big file commits :( |
| 12:39:35 | ameyer | the current mini2g build seems to have the issue |
| 12:39:56 | ameyer | assuming the ipod reboot failure is the same as the sansa reboot failure |
| 12:40:11 | BigBambi | OK, so note down which build server and then try the next few as well to see if it correlates |
| 12:40:20 | linuxstb | ameyer: Can you compile that same mini2g build yourself, and test that? |
| 12:40:30 | soap | Front page still needs fixed to explicitly mention that Rockbox does not work on the 4th gen Nano. |
| 12:40:30 | pixelma | I've experienced myself that using a downloaded build had the problem while compiling my own from the same revision did not. I didn't think it's a buildserver's fault, more like memory alignment or what's it called |
| 12:40:50 | ameyer | linuxstb: sure |
| 12:41:26 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
| 12:41:28 | linuxstb | pixelma: But you've also experienced the problem with builds you've compiled yourself? i.e. some of your own builds work, some don't? |
| 12:41:46 | pixelma | reason: I have the problem on my c200 with self-compiled... yes |
| 12:44:26 | ameyer | erm, false alarm on the mini2g, it works right now |
| 12:44:46 | preglow | hmm |
| 12:44:55 | preglow | what's the reason for the codec memory rearrangement? |
| 12:45:41 | linuxstb | preglow: IMO it's cleaner, and hopefully will mean we can reduce the combined size. |
| 12:45:46 | | Part M0rtus |
| 12:46:10 | linuxstb | IIUC, prior to that commit, the unused part of the main codec buffer remained unused. |
| 12:48:36 | ameyer | is it in any way possible the sansa charging patch could fix the mystery sansa usb reboot issue? |
| 12:49:05 | ameyer | (and adds a nasty 100% reproducible stkov) |
| 12:49:28 | preglow | linuxstb: but the total amount, which is the same, still remaions unused... |
| 12:49:32 | | Join J-23 [0] (n=kvirc@a105.net128.okay.pl) |
| 12:49:40 | preglow | well, not unused |
| 12:49:42 | preglow | but occupied |
| 12:50:00 | preglow | i hate that malloc buffer, so few codecs now need it |
| 12:50:10 | ameyer | because that could also explain why my builds always seem to work |
| 12:50:29 | ameyer | erm, seem to always work |
| 12:53:04 | linuxstb | preglow: I agree - but technically there is now no longer a malloc buffer, just the unused part of the codec buffer. So if we can reduce the amount of malloc'ing the guilty codecs do, we can easily reduce that buffer size. |
| 12:53:31 | linuxstb | i.e. this is just the first step to reducing the memory usage of codecs |
| 12:54:00 | linuxstb | preglow: I have started a wiki page on this topic here if you have time to contribute - http://www.rockbox.org/twiki/bin/view/Main/CodecMemoryUsage |
| 12:54:49 | | Quit DerPapst (Read error: 104 (Connection reset by peer)) |
| 12:54:57 | linuxstb | ameyer: Ah, so you run patched builds? |
| 12:57:20 | ameyer | just the sansa charging patch |
| 12:58:23 | ameyer | though, that shouldn't affect the mini2g builds, and I *think* that I've seen official builds work and my build not work on the same revision |
| 12:58:28 | preglow | linuxstb: ah, i actually collected some data on this, i'll try to update it today |
| 12:58:57 | linuxstb | B4gder: Would you be interested in writing a script to analyse the codec .map files and output the memory usage (code, rodata, bss, icode, irodata, ibss) ? I'm guessing (hoping) it's similar to what you've done for the main builds... |
| 13:00 |
| 13:00:16 | | Join kachna [0] (n=kachna@r3g248.net.upc.cz) |
| 13:01:14 | preglow | yeah, that would be awesome, the wiki data would be out of date really fast... |
| 13:01:59 | B4gder | that's a good idea, I'll look into it |
| 13:02:20 | *** | Saving seen data "./dancer.seen" |
| 13:04:04 | linuxstb | preglow: What are the problem codecs? IIUC, mp4 codecs have problems with the seektable info, and Tremor needs to allocate (and init) some large lookup tables, especially for floor0 files. Are there any others? |
| 13:05:01 | * | ameyer wonders how well flake -12 files would work on rockbox |
| 13:05:50 | * | scorche didnt know we had a codec for flake |
| 13:05:52 | linuxstb | ameyer: The Rockbox flac decoder only supports the "flac subset" - I've no idea what "flake -12" produces. The main issue is the maximum frame size is something like 4608 samples. |
| 13:06:11 | linuxstb | scorche: It's a third-party flac encoder |
| 13:06:32 | ameyer | maximum frame size could be an issue |
| 13:06:35 | scorche | oh... |
| 13:09:47 | preglow | linuxstb: vorbis is the major one, afaik |
| 13:09:56 | preglow | linuxstb: and it's hard to work around, the codec has very few hard limits |
| 13:10:07 | ameyer | apparently at higher compression levels it uses 16k blocks, whatever that means. |
| 13:10:16 | preglow | but of course, only way to handle it is to find the common limits used in encoders and hard code for that |
| 13:10:41 | preglow | bah |
| 13:10:52 | preglow | even the flac author himself says higher block sizes seldom matters |
| 13:11:13 | linuxstb | ameyer: That's probably not going to work then - it increases the memory requirements for decoding, meaning those buffers could no longer be in the fast IRAM |
| 13:11:26 | linuxstb | (which is why Rockbox limits to the subset) |
| 13:11:57 | ameyer | makes sense |
| 13:12:52 | preglow | and i really don't think we should fix that |
| 13:12:56 | linuxstb | I can't recall anyone ever complaining either, which would seem to prove that non-subset files are very rare in reality. |
| 13:13:07 | preglow | codec authors should be aware that there are limits, if they want portable playback |
| 13:13:31 | preglow | s/codec authors/encoder authors/ |
| 13:14:27 | ameyer | linuxstb: and lossless/lossless transcoding isn't as big of a deal as lossy/lossy |
| 13:14:39 | linuxstb | ameyer: Indeed. |
| 13:15:11 | ameyer | afaik, Trent Reznor is the only person who actually uses flake |
| 13:15:43 | linuxstb | It could be interesting to port it to Rockbox - I'm sure it's far more understandable than libFLAC... |
| 13:16:00 | linuxstb | But IIRC, it uses floating point... |
| 13:16:53 | preglow | well, so does flac, for lpc afaik |
| 13:17:04 | linuxstb | Hmm, variable block size encoding sounds interesting... (reading the flake hompage...) |
| 13:18:14 | preglow | sounds like a weird lossless encoder feature |
| 13:18:40 | preglow | hard to imagine why you would want to use shorter blocks, unless there is some kind of switchable mode |
| 13:19:55 | preglow | linuxstb: i'll update the wiki with my malloc findings right now, some of it might be inaccurate (don't think it is, tho...), but it beats nothing |
| 13:20:07 | crwl | flake seems to use block size of 4608 in all of its presets (at least −−help of flake 0.11 indicates that) |
| 13:20:24 | crwl | er, 4608 or lower |
| 13:23:02 | preglow | linuxstb: didn't ape use to malloc a seek table? |
| 13:24:41 | ameyer | erm, what I said about Trent Reznor apparently isn't true |
| 13:24:50 | ameyer | anyway... |
| 13:26:48 | linuxstb | preglow: Ah yes, it does... |
| 13:26:55 | ameyer | I have 0.10 and flake claims to onlu use up to 4608 |
| 13:28:00 | preglow | does? i couldn't find it :/ |
| 13:28:04 | linuxstb | preglow: I don't remember the details, but I expect that can be changed to a sensible sized static buffer, similar to FLAC. I'll investigate. |
| 13:28:18 | linuxstb | It's in apps/codecs/demac/libdemac/ |
| 13:28:43 | preglow | oh, there's another dir in there... |
| 13:28:58 | preglow | btw, is it "malloc free" or "malloc-free"? as in free of mallocs |
| 13:29:40 | linuxstb | I meant to say it there is no use of malloc or free. |
| 13:30:10 | ameyer | preglow: flake -h shows a table with equivalent command lines for -0 through -12 |
| 13:30:12 | preglow | oh, i meant which of the two alternatives are correct english :P |
| 13:30:53 | linuxstb | preglow: Probably best to just say "Does not use malloc"... |
| 13:31:12 | | Join LambdaCalculus37 [0] (n=LambdaCa@nmd.sbx09467.newyony.wayport.net) |
| 13:31:14 | preglow | yeah, but i'm curious now :) |
| 13:31:29 | linuxstb | I would use a hyphen, but I don't know if that's correct. |
| 13:35:54 | | Quit kachna (Read error: 110 (Connection timed out)) |
| 13:36:25 | preglow | linuxstb: i'll just put in entries for all the codecs that don't use malloc. they'll have to be added anyway |
| 13:41:04 | linuxstb | preglow: So AAC itself uses malloc, in addition to the mp4 parser? |
| 13:41:23 | preglow | linuxstb: it allocates buffers all over the place |
| 13:41:32 | preglow | linuxstb: asf doesn't touch any malloc, no? |
| 13:41:44 | linuxstb | As far as I can remember, no. |
| 13:42:22 | preglow | faad mallocs a lot in ifdef places, and i can't really see which we use |
| 13:42:29 | preglow | needs to be clarified anyway |
| 13:42:37 | linuxstb | Do speex and vorbis share an ogg parser? |
| 13:42:46 | preglow | don't think so |
| 13:43:03 | preglow | ogg can be handled free of mallocs, but i think it requires some api changes |
| 13:43:14 | preglow | libogg2 is supposed to deal with that |
| 13:43:25 | linuxstb | Does that exist? |
| 13:44:16 | | Join legendsohai [0] (n=legendso@219.93.152.34) |
| 13:44:18 | preglow | in some form, yeah |
| 13:44:26 | preglow | i believe tremor uses an early version of it |
| 13:44:30 | | Quit moos ("Rockbox rules the DAP world") |
| 13:44:53 | | Join pvbcharon [0] (n=charon@62.225.173.228) |
| 13:45:37 | linuxstb | The whole Ogg thing seems such a mess... |
| 13:45:49 | preglow | yeah... |
| 13:49:10 | preglow | what codecs use libm4a? aac? alac? |
| 13:49:38 | | Join nplus [0] (n=nplus@141.25.Globcom.Net) |
| 13:50:00 | preglow | how do i make subheadings? how do i link to one? don't have much time, or i'd read up... |
| 13:51:29 | linuxstb | More "+" signs for subheadings |
| 13:51:47 | linuxstb | Yes, aac and alac are the only mp4/m4a codecs |
| 13:53:00 | | Quit LambdaCalculus37 ("Ka-chunka") |
| 13:53:45 | | Quit Nibbl (Read error: 110 (Connection timed out)) |
| 13:56:44 | | Join HBK [0] (i=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
| 13:57:17 | B4gder | http://pastebin.com/m15a0ec79 |
| 13:57:23 | B4gder | my first codec size overview |
| 13:57:30 | B4gder | from an X5 build |
| 13:58:16 | | Part legendsohai |
| 13:58:45 | preglow | bah, can't make anchors work |
| 13:59:12 | preglow | B4gder: looks sweet |
| 13:59:38 | linuxstb | B4gder: Interesting - looks like nothing is anywhere near the 512KB limit... |
| 13:59:46 | B4gder | indeed |
| 13:59:49 | preglow | malloc use hides a bit |
| 14:00 |
| 14:00:05 | preglow | a fair bit, in the case of vorbis and aac |
| 14:00:40 | | Quit HBK- (Read error: 60 (Operation timed out)) |
| 14:00:47 | linuxstb | Yes, but that's always been in the separate malloc buffer. |
| 14:01:17 | preglow | oh yeah, just meant to say it isn't a good way to see what memory the codecs do need |
| 14:02:06 | * | linuxstb wonders how that info can be presented for the various architectures in a useful way... |
| 14:02:25 | B4gder | there's a lot of numbers... |
| 14:02:33 | linuxstb | B4gder: Is const data included anywhere in those numbers? |
| 14:02:57 | preglow | argh, isn't using anchors just going like [[#AnchorName][link here] and then putting #AnchorName in the spot you want to link to? |
| 14:03:08 | B4gder | const would be rodata won't it? |
| 14:03:21 | preglow | yea |
| 14:03:50 | preglow | linuxstb: each codec entry would probably just have a bunch of links to files that get updated per target per build? |
| 14:04:13 | B4gder | right, rodata is part of the Text size in that table I believe |
| 14:04:14 | preglow | only way i can see it work and still be updated automatically |
| 14:04:54 | linuxstb | Maybe the whole page needs to be generated dynamically, and include some kind of figure (or textual description) for malloc usage (taken from a static file) |
| 14:05:51 | amiconn | linuxstb: Do all malloc()s in question never free() before the codec exits? |
| 14:06:14 | linuxstb | I think the entire malloc buffer is reset after each track. |
| 14:06:17 | preglow | amiconn: we purge the malloc buffer after each track |
| 14:06:19 | linuxstb | i.e. there's no free() |
| 14:06:23 | preglow | so it doesn't matter |
| 14:06:23 | amiconn | If there are some free() calls, it _might_ help to implement a proper free() |
| 14:06:42 | amiconn | ...e.g. dbestfit or whatever that's called |
| 14:06:50 | preglow | it _might_ help to implement a proper "malloc" too, but let's just remove the mallocs instead shall we? :) |
| 14:07:16 | * | B4gder is on the remove-them train |
| 14:07:34 | * | linuxstb lives on no-malloc street |
| 14:07:36 | amiconn | That would be much preferred. The question is whether it's possible without a major rewriet of the codecs in question. |
| 14:08:17 | B4gder | true |
| 14:08:25 | preglow | i think it would be very possible |
| 14:08:38 | preglow | i do not believe the codecs to malloc/free on a per frame basis, it's all init/deinit |
| 14:08:57 | preglow | so we purely need to find the static limits that would work, for some codecs this is easy (aac), for some it is hard (vorbis) |
| 14:10:26 | | Join LambdaCalculus37 [0] (i=44a04303@gateway/web/ajax/mibbit.com/x-3ebcce34ffe45c91) |
| 14:10:44 | | Join Schmogel [0] (n=Miranda@p3EE21CBB.dip0.t-ipconnect.de) |
| 14:11:43 | B4gder | I committed tools/codecscan.pl now |
| 14:13:04 | preglow | \o/ |
| 14:13:54 | | Nick GodEater is now known as Goodie_Godeater (i=c2cbc962@gateway/web/ajax/mibbit.com/x-01e46139ed5493ac) |
| 14:14:18 | | Nick Goodie_Godeater is now known as GodEater (i=c2cbc962@gateway/web/ajax/mibbit.com/x-01e46139ed5493ac) |
| 14:15:20 | linuxstb | If anyone is interested - results for an ipod build (minus the encoders) - http://pastebin.com/mbe902de |
| 14:16:21 | LambdaCalculus37 | We should have a wiki page for that information. |
| 14:17:08 | linuxstb | LambdaCalculus37: It would be better to generate it from the builds, rather than put it statically in the wiki. But see http://www.rockbox.org/twiki/bin/view/Main/CodecMemoryUsage |
| 14:17:40 | LambdaCalculus37 | linuxstb: Are your results for iPods in general, or any specific iPod? |
| 14:18:03 | linuxstb | It's the ipod color build. I don't know if the codecs make use of the extra iram on nano/video... |
| 14:18:05 | * | GodEater guesses for the photo |
| 14:18:24 | * | LambdaCalculus37 will get some results later on |
| 14:18:31 | preglow | i was about to ask about that, should we create them for all builds, or just find which targets share the same? |
| 14:18:39 | preglow | i guess the last would require maintainance, but be preferable |
| 14:19:18 | linuxstb | preglow: Is there a reason speex uses very little IRAM? it looks like lots of code could go there (if it helps...) |
| 14:19:52 | linuxstb | Also, it seems like the entire wavpack codec (code and bss) could fit in IRAM... |
| 14:20:33 | B4gder | in general iram usage seem somewhat low |
| 14:20:56 | preglow | linuxstb: speex just doesn't need much working ram, and yeah, speex is a work in progress |
| 14:21:12 | linuxstb | preglow: I was thinking of icode |
| 14:21:22 | preglow | i know, just saying that's the reason it uses little iram |
| 14:21:42 | preglow | stuffing code in iram is always good, and can come up with some candidates for stuffing |
| 14:21:43 | linuxstb | OK - I was just wondering if you had tested and found it to not be useful. |
| 14:21:46 | preglow | but need to go soon |
| 14:22:01 | | Join bluebrother [0] (n=dom@rockbox/staff/bluebrother) |
| 14:22:09 | | Quit amiconn (Nick collision from services.) |
| 14:22:15 | | Join amiconn [50] (n=jens@rockbox/developer/amiconn) |
| 14:22:21 | preglow | speex too will probably fit nicely (at least the parts that matter) in iram |
| 14:23:55 | * | linuxstb wonders what causes wma to use so much bss |
| 14:24:20 | LambdaCalculus37 | linuxstb: But SPC uses even more BSS. |
| 14:24:56 | LambdaCalculus37 | 338784 for SPC versus 149056 for WMA... those are the highest two in terms of BSS usage. |
| 14:24:57 | linuxstb | Isn't that an emulator format though? Meaning it's probably the RAM of the target device? |
| 14:25:38 | LambdaCalculus37 | linuxstb: Yes, it's an emulation of the SPC700 chip in the Super NES. |
| 14:26:17 | LambdaCalculus37 | http://snesmusic.org/files/spc_file_format.txt |
| 14:41:22 | | Join tvelocity [0] (n=tony@gw1.mycosmos.gr) |
| 15:00 |
| 15:02:24 | *** | Saving seen data "./dancer.seen" |
| 15:06:32 | | Join pierre- [0] (n=pierre@89.179.94.138) |
| 15:10:45 | | Quit Schmogel (Read error: 104 (Connection reset by peer)) |
| 15:11:08 | | Join Schmogel [0] (n=Miranda@p3EE21CBB.dip0.t-ipconnect.de) |
| 15:11:09 | Schmogel | ^^ |
| 15:12:00 | B4gder | does that mean anything? |
| 15:12:38 | | Join Yskyflyer [0] (n=chatzill@ool-435787e5.dyn.optonline.net) |
| 15:13:10 | | Quit Yskyflyer (Client Quit) |
| 15:15:15 | | Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) |
| 15:15:16 | | Join evilnick_ [0] (i=0c140464@gateway/web/ajax/mibbit.com/x-6791dfff6c639fd3) |
| 15:22:02 | | Join lol3izer [0] (n=lol3izer@72.2.63.189) |
| 15:24:54 | | Join Kopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) |
| 15:45:55 | | Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) |
| 15:53:33 | B4gder | the d2 manual isn't working yet is it? |
| 15:53:36 | | Join Nibbl [0] (n=Nibbler@e181103125.adsl.alicedsl.de) |
| 15:54:27 | * | B4gder read the dev ML post |
| 15:54:56 | LambdaCalculus37 | B4gder: I don't think there's any reference or any work done on a D2 manual. |
| 15:55:39 | * | B4gder tries it |
| 15:55:53 | B4gder | File `platform/cowond2.tex' not found. |
| 15:56:01 | LambdaCalculus37 | Aha! |
| 16:00 |
| 16:04:24 | | Join hogeh- [0] (n=chatzill@ku38.opt2.point.ne.jp) |
| 16:08:00 | bluebrother | the d2 isn't released yet too, right? |
| 16:08:24 | * | bluebrother checks |
| 16:08:46 | B4gder | it's not "supported" at all, no |
| 16:09:19 | linuxstb | The m3 is missing a manual too... |
| 16:09:45 | bluebrother | yep. IIRC there was still this issue with the m3 not having a main remote |
| 16:10:08 | * | bluebrother spots that this "don't show metadata lines without info" has a read bin delta :( |
| 16:10:11 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
| 16:10:22 | linuxstb | So less is more... |
| 16:10:46 | bluebrother | :( |
| 16:11:10 | bluebrother | me never was annoyed by those empty lines |
| 16:12:16 | bluebrother | thus I never saw a point in removing those |
| 16:12:55 | linuxstb | Isn't it also useful to know what you're missing? |
| 16:13:31 | bluebrother | well, my files are usually well tagged, but for some fields I have no use. Still it's useful to see those fields IMO |
| 16:13:45 | pixelma | where have you been yesterday? ;) |
| 16:14:10 | * | bluebrother scratches head |
| 16:15:24 | bluebrother | I have no too strong feelings about showing or hiding empty fields (though it smells kinda like dynamic menus, and we don't want those ...) but if it's a red bin delta I kinda dislike hiding them |
| 16:15:28 | * | linuxstb reads the logs... |
| 16:15:44 | linuxstb | pixelma: I was there, but missed it. JdGordon kept the discussion brief... |
| 16:17:11 | linuxstb | I almost never use that screen anyway,, so don't really mind. But IMO the desired behaviour is debatable, so should have been debated... |
| 16:17:31 | pixelma | well, I didn't have too strong arguments and time to discuss (was shortly before lunch break) |
| 16:18:15 | | Quit vitja_ (Remote closed the connection) |
| 16:20:12 | * | bluebrother agrees with linuxstb |
| 16:20:30 | | Quit blahrus (Read error: 104 (Connection reset by peer)) |
| 16:23:08 | | Quit Seed ("cu, Andre") |
| 16:26:11 | | Join blahrus [0] (n=blahrus@75.150.209.185) |
| 16:28:05 | | Quit EspeonEefi ("さよなら") |
| 16:29:17 | XavierGr | bluebrother: what's your preffered "fixed" length about 9455? Because as I see it, it would need a big value to please all habits. |
| 16:29:36 | | Quit pvbcharon () |
| 16:30:15 | XavierGr | and as I comment, 32 bytes is not something that large-screen targets miss. |
| 16:34:20 | bluebrother | XavierGr: well, to have a "good" spacing, especially if you use something different than spaces, 5 would be enough IMO −− something like the "+++" winamp uses is the usual thing I could think about |
| 16:34:55 | bluebrother | and for spaces, well ... if you have 5 user characters and add a space in front and after them you can get to up to 7 spaces. Shouldn't that be enough? |
| 16:36:04 | XavierGr | bluebrother: but thats why this became an issue. Some need a larger padding string. |
| 16:36:39 | XavierGr | I am ok for a fixed value as long it is big to please all, but then small screens will just waste memory |
| 16:36:54 | bluebrother | one could argue about 7 user defineable characters. But everything else is quite special-case IMO. And we can't care for every special case like people wanting the complete line as padding |
| 16:37:40 | bluebrother | IMO the number of characters doesn't make much of a difference for the screen size −− on small screens you usually will use a much smaller font, so the number of characters isn't too different |
| 16:38:33 | bluebrother | people repeatedly complained about rockfont on larger screens, so anyone using small fonts on a large screen can be considered a special case. IMHO :) |
| 16:38:58 | XavierGr | of course that's why I am still arguing about it, array[30] from array[LCD_WIDTH / 4] is not more complex but still you get something more for only some bytes |
| 16:39:35 | XavierGr | or save something more for smaller screens |
| 16:39:56 | | Quit Nibbl (Read error: 113 (No route to host)) |
| 16:39:58 | bluebrother | well, I don't see a point why larger screens should require more *characters*. |
| 16:40:06 | XavierGr | because if it is done as a setting to only increase the space from 3 - 7 then it is a waste |
| 16:40:24 | | Join PaulJam [0] (i=PaulJam_@vpn-3096.gwdg.de) |
| 16:40:44 | bluebrother | well, with that setting you can include other characters, so this definitely makes things more flexible |
| 16:41:20 | bluebrother | with that arguing you could consider the whole thing a waste on players with small targets if LCD_WIDTH / 4 comes around as something like 7 ... |
| 16:42:03 | bluebrother | hmm, while thinking about it ... how making it part of the wps? I.e. define the scrolling line including the padding? |
| 16:42:31 | bluebrother | that way one could even use different padding strings depending on tag / subline / whatever |
| 16:42:35 | XavierGr | my idea first, was to achieve something like iriver scrolling which shows an empty screen at the end of scrolling, using a large pad and a big step size I get this. At the expense of 30-40 bytes |
| 16:42:57 | | Join Nibbl [0] (n=Nibbler@e181103125.adsl.alicedsl.de) |
| 16:43:12 | XavierGr | bluebrother: it is working on wps too, or do you mean as a tag? |
| 16:43:19 | bluebrother | I mean as tag. |
| 16:43:35 | bluebrother | something like %scroll(%artist +++ ) |
| 16:43:45 | bluebrother | sorry for the pseudo-wps-code ... |
| 16:44:02 | XavierGr | but what about the file browser? or you mean haveing both? |
| 16:44:17 | bluebrother | never thought of lists −− is it really that of an issue there? |
| 16:44:28 | XavierGr | but having both could be confusing |
| 16:44:31 | XavierGr | hmm |
| 16:44:32 | bluebrother | I might use such a feature in the wps but definitely not in lists |
| 16:44:36 | linuxstb | Does FS #9455 currently affect all scrolling - i.e. in list (file) browser and WPS? |
| 16:44:45 | XavierGr | yes |
| 16:45:56 | linuxstb | And the binsize increase is still almost 1KB? (I see 848 bytes quoted for an earlier version of the patch on h300) |
| 16:46:02 | * | bluebrother points out that he usually uses settings sane enough to rarely require scrolling −− slow lcds make scrolling a pain |
| 16:46:16 | XavierGr | linuxstb: nope it should be rather small now |
| 16:46:19 | XavierGr | I should check |
| 16:46:29 | * | XavierGr checks |
| 16:46:37 | lol3izer | why are you guys so obsessed with binsize? |
| 16:47:06 | bluebrother | lol3izer: because more RAM for buffering means less disc spinups. Less disc spinups mean longer battery runtime |
| 16:47:27 | lol3izer | but a few K |
| 16:47:29 | lol3izer | is nothing |
| 16:47:30 | bluebrother | and if we didn't care about it the binary would explode rather quickly. |
| 16:47:39 | lol3izer | ah |
| 16:47:43 | LambdaCalculus37 | lol3izer: Every single K counts. |
| 16:47:43 | bluebrother | I've seen this at work ... |
| 16:47:53 | | Quit Zagor ("Client exiting") |
| 16:48:12 | bluebrother | every byte counts ;-) |
| 16:48:19 | linuxstb | lol3izer: Various reasons. Avoid inefficient code, avoid overly-complicated code, avoid feature bloat |
| 16:48:43 | bluebrother | now consider some of the old targets (archos) and never targets have not much RAM, 1MB or even less |
| 16:49:19 | bluebrother | that's not much given the fact that we need codecs, filesytem access, a customizable UI, ... |
| 16:49:37 | LambdaCalculus37 | The Archos targets have only 2MB of RAM; some like the iFP-7xx, Clip, m200 and others have even less. |
| 16:49:39 | bluebrother | and we do want to use RAM for buffering ... |
| 16:50:07 | bluebrother | ah, right, the archos were 2MB. Still not much |
| 16:50:39 | PaulJam | Hi, it looks like test_codec is broken in current SVN. (probably related to the changes in r18834) |
| 16:50:54 | LambdaCalculus37 | PaulJam: Which target did you try it on? |
| 16:51:00 | PaulJam | H300 |
| 16:51:10 | PaulJam | it doesn't compile |
| 16:52:01 | PaulJam | test_codec.c:430: error: structure has no member named `get_codec_memory' |
| 16:52:16 | | Join {phoenix} [0] (n=dirk@p54B474BF.dip.t-dialin.net) |
| 16:52:50 | XavierGr | linuxstb: it dropped to 700 for H300. I hoped for something more |
| 16:53:26 | * | bluebrother starts to kinda like the idea of padding in the wps tags |
| 16:54:35 | XavierGr | strnage... since you were the father of the previous idea |
| 16:54:37 | pixelma | why? You can just add your "padding string" as plain text in the WPS |
| 16:55:04 | XavierGr | hmm indeed |
| 16:55:24 | bluebrother | XavierGr: why? I just expanded that idea ;-) |
| 16:56:13 | XavierGr | hehe. But indeed in wps you can alter the scrolling line with any text string you like |
| 16:56:27 | linuxstb | PaulJam: I expect you just need to rename it to codec_get_buffer() |
| 16:56:34 | XavierGr | the line in general though, not the "scrolling" per se |
| 16:56:36 | bluebrother | is this already possible? Not really sure about that |
| 16:57:03 | linuxstb | PaulJam: I'll test and commit, thanks for reporting. |
| 16:57:06 | XavierGr | bluebrother: yeah you can insert any text you like before and after, though it will appear even if the line isn't scrolling |
| 16:57:29 | PaulJam | linuxstb: ok, thanks. i wasn't sure, because the commit message sounded as if there were functional changes too. |
| 16:57:35 | bluebrother | well, then this isn't what I've thought. |
| 16:59:53 | XavierGr | it is quite similar though |
| 17:00 |
| 17:00:41 | bluebrother | true |
| 17:02:26 | *** | Saving seen data "./dancer.seen" |
| 17:04:39 | | Part hogeh- |
| 17:06:05 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
| 17:10:45 | linuxstb | PaulJam: A quick fix is possible, but I think test_codec needs more changes to accurately emulate the new way codecs use memory. So I'll leave it for now... |
| 17:11:01 | linuxstb | PaulJam: But if you need to use it, the search/replace I suggested should work. |
| 17:12:39 | PaulJam | linuxstb: i don't need test_codec. i just had it enabled in my build, so i noticed it. |
| 17:19:07 | | Join Arathis [0] (n=doerk@p508A3AA3.dip.t-dialin.net) |
| 17:19:57 | | Join bughunter2 [0] (n=Jelle@77.164.66.126) |
| 17:21:01 | | Quit bughunter2 (Client Quit) |
| 17:21:47 | | Join bughunter2 [0] (n=Jelle@77.164.66.126) |
| 17:24:33 | | Join n1s [0] (n=nils@rockbox/developer/n1s) |
| 17:24:50 | | Part johwil |
| 17:25:47 | | Quit sarixe (Remote closed the connection) |
| 17:26:21 | | Join sarixe [0] (n=sarixe@ool-435407e9.dyn.optonline.net) |
| 17:28:55 | | Join kachna [0] (n=kachna@r4ax178.net.upc.cz) |
| 17:42:18 | | Join Hillshum [0] (n=chatzill@75-165-224-4.slkc.qwest.net) |
| 17:42:43 | | Quit BigBambi ("http://www.mibbit.com ajax IRC Client") |
| 17:52:46 | | Quit evilnick_ ("http://www.mibbit.com ajax IRC Client") |
| 18:00 |
| 18:00:18 | | Quit Rob2223 (Read error: 104 (Connection reset by peer)) |
| 18:07:12 | | Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) |
| 18:09:12 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 18:09:43 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
| 18:10:22 | | Quit domonoky (Client Quit) |
| 18:10:50 | | Quit petur ("work->home") |
| 18:11:44 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 18:12:47 | | Join nuonguy [0] (n=john@c-71-198-1-139.hsd1.ca.comcast.net) |
| 18:12:51 | | Part B4gder |
| 18:14:45 | | Quit robin0800 (Remote closed the connection) |
| 18:15:25 | | Join funman [0] (n=fun@86.219.29.237) |
| 18:18:49 | | Join BigBambi [0] (n=Alex@rockbox/staff/BigBambi) |
| 18:20:57 | funman | isn't this test run automatically on each commit (on the builders) ? |
| 18:21:46 | | Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) |
| 18:23:43 | | Join Tetracomm [0] (n=nicholas@72.252.29.2) |
| 18:24:12 | | Quit rvvs89 (Read error: 60 (Operation timed out)) |
| 18:25:23 | | Join lol3izer_ [0] (n=lol3izer@72.2.63.189) |
| 18:25:35 | | Quit Arathis ("Bye, bye") |
| 18:25:45 | | Join rvvs89 [0] (n=rvvs89@martello.ucc.gu.uwa.edu.au) |
| 18:26:05 | pixelma | test_codec is a plugin which is not part of the downloadable builds (hence not tested if it still builds) |
| 18:29:36 | funman | ah I thought it was a kind of test suite runnable on the build host |
| 18:30:28 | | Join miepchen^schlaf [0] (n=miepchen@p579ECEC0.dip.t-dialin.net) |
| 18:30:51 | domonoky | test_codec is a plugin to test codecs (especially decoding speed) on target.. |
| 18:31:42 | | Join Bagder_ [0] (n=daniel@1-1-5-26a.hud.sth.bostream.se) |
| 18:32:07 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
| 18:32:40 | | Nick Bagder_ is now known as Bagder (n=daniel@1-1-5-26a.hud.sth.bostream.se) |
| 18:32:46 | funman | excuse me I never used rockbox ;) |
| 18:33:08 | LambdaCalculus37 | funman: You're excused. :) |
| 18:36:38 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 18:41:35 | | Join stoffel_ [0] (n=sfr@p57B4E535.dip.t-dialin.net) |
| 18:42:55 | | Quit lol3izer_ () |
| 18:43:32 | | Quit lol3izer (Connection timed out) |
| 18:46:14 | funman | is the m200v2 supposed to embed SDRAM ? |
| 18:46:31 | funman | the memory setup routines are 100% identical between Clip & M200 |
| 18:47:18 | | Quit miepchen^schlaf () |
| 18:47:32 | funman | and read timings from uninitialized stack apparently :'( |
| 18:48:37 | | Join miepchen^schlaf [0] (n=miepchen@p579ECEC0.dip.t-dialin.net) |
| 18:50:13 | J-23 | What are the video pins on Sansa e200 USB connector? |
| 18:51:44 | linuxstb | J-23: I think there's a wiki page describing the Sansa connector |
| 18:52:45 | | Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) |
| 18:52:56 | linuxstb | funman: I've no idea. What about the e200v2? I couldn't see any RAM chips on the photos linked from the wiki. |
| 18:53:11 | funman | and the e200 routine is 99.9% identical (one setting has another value) |
| 18:53:32 | vitja | I've mounted iaudio7!! |
| 18:53:45 | funman | vitja: great \o/ |
| 18:54:21 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
| 18:54:29 | vitja | yeah but a bit hacky wo interrupts for tx |
| 18:55:24 | | Quit Schmogel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 18:59:21 | | Join mf0102 [0] (n=michi@e181132181.adsl.alicedsl.de) |
| 19:00 |
| 19:01:47 | funman | I found still the same code in Clipv2 OF |
| 19:01:51 | linuxstb | vitja: Congratulations |
| 19:02:06 | vitja | thanks |
| 19:02:15 | gevaerts | well done! |
| 19:02:24 | vitja | still isn't done ;) |
| 19:02:27 | *** | Saving seen data "./dancer.seen" |
| 19:02:56 | vitja | I'll commit workaround soon, so you can test it |
| 19:05:39 | | Quit Exorcist- (Read error: 110 (Connection timed out)) |
| 19:07:44 | | Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) |
| 19:08:13 | | Join karashata [0] (n=kimi@69.41.192.215) |
| 19:11:02 | | Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) |
| 19:11:46 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 19:13:23 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
| 19:13:31 | | Quit Seed ("cu, Andre") |
| 19:13:57 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
| 19:14:55 | | Join hannesd [0] (n=light@p5B1638EA.dip0.t-ipconnect.de) |
| 19:15:04 | | Join kharo1 [0] (n=teemu@a88-114-245-92.elisa-laajakaista.fi) |
| 19:16:05 | | Quit kharo (Read error: 110 (Connection timed out)) |
| 19:21:22 | | Join domonoky1 [0] (n=Domonoky@g229101240.adsl.alicedsl.de) |
| 19:21:26 | | Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) |
| 19:22:17 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
| 19:22:57 | | Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) |
| 19:23:16 | | Quit Seed ("cu, Andre") |
| 19:24:02 | | Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) |
| 19:24:09 | | Quit karashata (Read error: 113 (No route to host)) |
| 19:24:17 | | Join karashata [0] (n=kimi@69.41.192.215) |
| 19:30:17 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
| 19:30:28 | | Quit karashata (Read error: 113 (No route to host)) |
| 19:30:54 | | Join karashata [0] (n=kimi@69.41.192.215) |
| 19:33:20 | | Quit sarixe ("Ex-Chat") |
| 19:37:36 | | Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) |
| 19:40:16 | | Quit domonoky (Read error: 110 (Connection timed out)) |
| 19:40:52 | amiconn | Hmm |
| 19:41:24 | amiconn | Regarding the test plugins - maybe we should have a 'developer build' option in configure, which will enable all the test stuff? |
| 19:42:07 | amiconn | (perhaps a sub-option for advanced builds) |
| 19:42:22 | gevaerts | good idea |
| 19:42:39 | amiconn | Then the build system could produce such builds, and we would see whether the test stuff still compiles |
| 19:42:54 | LambdaCalculus37 | amiconn: Good call. |
| 19:43:09 | amiconn | It would mean that the master would need to strip the test stuff from the .zip files before putting them into the download folder |
| 19:43:48 | amiconn | Hmm, or perhaps just build them, but don't include them in the .zip? Saves some upload time (build server -> master) as well |
| 19:45:07 | amiconn | The exclusion could be part of the standard 'make zip', 'make 7zip' etc. There could be a special 'make devzip' which includes them |
| 19:46:24 | * | LambdaCalculus37 opts to have a developer option added to configure, alongside normal, debug, et. al. |
| 19:46:56 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
| 19:47:52 | gevaerts | They could get a separate category. That would make it trivial to exclude them |
| 19:47:59 | | Quit stoffel_ (Read error: 113 (No route to host)) |
| 19:48:30 | amiconn | Well, there are 3 cases. (1) A user who wants to build his own rockbox (perhaps with a few patches). The test_* plugins should neither be built nor zipped. (2) A dev who wants the test_* plugins. In this case they should be built and zipped. (3) The build system. Here the test_* plugins should be built but _not_ ziiped |
| 19:49:46 | amiconn | My suggestion is to make building of the test_* plugins a configure option, and zipping them a separate make target |
| 19:50:34 | linuxstb | What's the point in not building them? They're all tiny compared to the rest of the plugins needed to be built. |
| 19:51:00 | | Join stoffel_ [0] (n=sfr@p57B4E535.dip.t-dialin.net) |
| 19:51:02 | amiconn | Build time |
| 19:51:11 | * | linuxstb thinks the build system is complicated enough already... |
| 19:52:17 | gevaerts | How big would the build time difference be in practice? |
| 19:52:49 | | Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) |
| 19:53:44 | amiconn | I didn't measure. I usually do build all test plugins, even on cygwin |
| 19:55:27 | amiconn | Actually I don't. I only build 6 of them |
| 19:55:28 | | Join nanok [0] (n=nanok@194.145.183.75) |
| 19:55:38 | * | gevaerts now has a dump of the DAX nand flash |
| 19:55:52 | linuxstb | gevaerts: Cool... The whole 1GB? |
| 19:55:56 | | Join tessarakt [0] (n=jens@e180067134.adsl.alicedsl.de) |
| 19:56:08 | gevaerts | yes. As correct as the current tcc nand driver allows |
| 19:56:17 | * | nanok salutes respectfully |
| 19:56:19 | linuxstb | How long did that take? |
| 19:56:34 | gevaerts | 303.998 seconds |
| 19:56:43 | domonoky1 | :-) |
| 19:57:00 | | Join Siku [0] (n=Siku@e212-246-214-27.elisa-laajakaista.fi) |
| 19:57:03 | * | domonoky1 loves exact statements.. |
| 19:57:49 | gevaerts | Speaking of exact, this is actually exactly 10^30 bytes :) |
| 19:58:07 | gevaerts | vitja: usb seems to work on the dax |
| 19:58:38 | | Quit stoffel_ ("Reconnecting") |
| 19:58:48 | | Join stoffel_ [0] (n=sfr@p57B4E535.dip.t-dialin.net) |
| 19:59:13 | linuxstb | gevaerts: That will make a nice recovery tool, assuming you can do the reverse... |
| 19:59:54 | | Join peerlessdeepak [0] (n=peerless@122.164.224.187) |
| 19:59:54 | bluebrother | gevaerts: so it's 1GB ;-) |
| 20:00 |
| 20:00:15 | gevaerts | linuxstb: indeed. I |
| 20:00:18 | vitja | gevaerts: problem was TX fails on big(>512) packets, RX will not work now for packets >512 |
| 20:00:31 | gevaerts | I'm not trying to writr yet though |
| 20:00:38 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
| 20:00:59 | vitja | hope that can help with TNFL |
| 20:01:07 | gevaerts | vitja: >512 byte transfers I guess. Packets are always 512-bytes max |
| 20:01:46 | vitja | yes, but some times they are fragmented |
| 20:02:13 | vitja | e.g. when host asks for 2 blocks usb_drv_send is called with len 1024 |
| 20:02:14 | linuxstb | vitja: shotofadds was here recently, sounding confident about breakthroughs with the NAND. Hopefully this will help him too. |
| 20:02:56 | gevaerts | Yes. usb_drv_send is for an entire transfer |
| 20:03:14 | vitja | so entrie transfer sometimes fails |
| 20:03:15 | | Quit Thundercloud (Read error: 104 (Connection reset by peer)) |
| 20:04:16 | | Join jgarvey [0] (n=jgarvey@cpe-098-026-069-229.nc.res.rr.com) |
| 20:04:34 | | Quit peerlessdeepak (Remote closed the connection) |
| 20:05:36 | vitja | linuxstb: nice |
| 20:07:01 | denes_ | btw how did somebody find out how the telechips_nand works? reverse engineering? |
| 20:07:35 | linuxstb | denes_: Yes - I think work started almost a year ago... |
| 20:07:47 | linuxstb | But only one person has really been working on it afaik |
| 20:08:15 | * | gevaerts tries to find a FAT header in the dump |
| 20:08:18 | denes_ | i see. the meizu m3 does something funky too (different from the tcc7XX) |
| 20:11:10 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 20:11:15 | | Quit stoffel_ ("leaving") |
| 20:12:04 | | Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") |
| 20:12:57 | | Join Hillshum [0] (n=chatzill@75-165-224-4.slkc.qwest.net) |
| 20:14:56 | denes_ | so on the ipod nano there is some kinf of an ata-nand bridge? |
| 20:15:12 | | Quit Rob2222 (Success) |
| 20:15:16 | LambdaCalculus37 | denes_: Which generation of nano? |
| 20:15:36 | denes_ | LambdaCalculus37: only one generation is supported, that generation |
| 20:15:37 | linuxstb | denes_: Yes - for the Nano Rockbox supports. |
| 20:16:04 | | Quit GodEater_ (Remote closed the connection) |
| 20:16:05 | LambdaCalculus37 | denes): Ahh, you mean first. I thought you were asking about other generations. |
| 20:16:05 | Hillshum | ist |
| 20:16:08 | denes_ | linuxstb: interesting. |
| 20:16:13 | * | LambdaCalculus37 slaps his tab key |
| 20:16:16 | Hillshum | *1st |
| 20:16:33 | | Join Schmogel [0] (n=Miranda@p3EE21CBB.dip0.t-ipconnect.de) |
| 20:16:56 | | Quit bmbl ("Woah!") |
| 20:17:04 | denes_ | LambdaCalculus37: yes, sorry I realize I was a bit vague |
| 20:18:36 | | Quit homielowe () |
| 20:19:00 | linuxstb | Looking at the 5g resource files with readelf, it just says "Machine: <unknown>: 0x5f" |
| 20:20:40 | bertrik | does anyone know how the oled brightness on the clip is varied? |
| 20:21:01 | | Join anselm [0] (n=anselm@e178034038.adsl.alicedsl.de) |
| 20:22:33 | funman | linuxstb: what about using OSX's readelf ? |
| 20:22:58 | funman | bertrik: the command should be defined and used in the init routine |
| 20:23:00 | | Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) |
| 20:23:32 | bertrik | I do have a clue and I'm about to try it out now |
| 20:23:34 | Hillshum | who admins flyspray? |
| 20:24:06 | BigBambi | The Swedes |
| 20:24:16 | BigBambi | Shout at Bagder :) |
| 20:24:20 | n1s | So about the crypto on newer ipods (like nano 2g) i find it interesting that there seems to be no reports of people trying to brute force it... IMHO it seems it could be worthwhile to try brute forcing the RC4 crypto as: |
| 20:24:26 | * | Bagder covers ears |
| 20:24:28 | funman | how many people are 'the Swedes' ? |
| 20:25:30 | BigBambi | funman: Three |
| 20:25:35 | funman | Bagder: shouldn't rockbox website / flyspray specify unicode character set ? |
| 20:25:40 | BigBambi | Bagder, LinusN and Zagor |
| 20:25:50 | domonoky1 | our 3 swedes are: Bagder, Zagor and LinusN, hooray to them.. :-) |
| 20:25:52 | Bagder | funman: yes, "should" being the keyword there |
| 20:26:13 | Bagder | we are more dev swedes than us though |
| 20:26:15 | BigBambi | domonoky1: There are only three Swedes as far as I am concerned :) |
| 20:26:28 | funman | is the website static? in svn? |
| 20:26:41 | Bagder | most is static and in svn, yes |
| 20:26:56 | BigBambi | (apologies to the other Swedish people here ) :) |
| 20:27:07 | * | funman is going to flame webmaster@rockbox.o |
| 20:27:23 | n1s | 1) Apple used it on ipod flash images before, 2) (AFAIK) noone else that uses the same SoC has encrypted firmware which suggests that apple did it themselves 3) analysis supports the theory that it is a stream cipher 4) if the key is short it should be doable (32 bits used on earlier flash images) reports of up to 48 bti keys brute forced in less than two weeks on distributed systems |
| 20:27:41 | Hillshum | so flyspray seems to request unicode, rb home doesn't |
| 20:28:07 | Bagder | funman: feel free, that address gets lot of crap ;-) |
| 20:28:07 | funman | n1s: as long as you know the stream cipher algorithm |
| 20:28:08 | bertrik | any idea where the key is hidden? |
| 20:28:40 | funman | or maybe bruteforce all algorithms you know until you can grep 'Apple' ;) |
| 20:29:18 | Bagder | bertrik: if it's an asymetric algorithm the generating key isn't to be found, only the decrypt one |
| 20:29:41 | Bagder | well, until you brute-force that too |
| 20:30:17 | n1s | funman: i would suggest starting with rc4 at least and also there should be no problem to find unique strings to search for... |
| 20:30:26 | | Quit Rob2222 (Read error: 60 (Operation timed out)) |
| 20:30:40 | bertrik | asymmetric sounds a bit unrealistic (and perhaps quite slow?). I assume they want to protect the firmware from being decrypted, not from being encrypted. |
| 20:31:08 | * | Hillshum seconds bertrik |
| 20:31:10 | n1s | bertrik: if we can't encrypt we probably can't run any code so... |
| 20:31:39 | * | n1s Votes for Mr Someone to try brute forcing the thing :) |
| 20:31:56 | | Quit J-23 (Remote closed the connection) |
| 20:32:23 | n1s | Or if someone sends me a new ipod and a _really_fast computer i promise i'll try it :) |
| 20:33:35 | funman | Bagder: unless you want to replace the code by yours |
| 20:33:45 | | Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) |
| 20:34:02 | * | funman gives some quarks to n1s |
| 20:34:31 | * | shotofadds 's ears are burning |
| 20:34:39 | n1s | hmm quarks tastes funny... |
| 20:34:48 | * | Hillshum has access to a 3g nano... |
| 20:36:42 | funman | hm I'm looking at the Clipv2 again |
| 20:37:04 | funman | It setups stacks past 0x50000 (more than 320kB) |
| 20:37:20 | Hillshum | how different from v1? |
| 20:38:16 | funman | the v1 uses stack (and everything) below 0x50000 |
| 20:38:29 | funman | but I just read that you can remap external memory (up to 4MB) at address 0 |
| 20:38:56 | funman | that means that when booting the external memory is mapped at 0 (not the Embedded 1T-RAM of 320kB) |
| 20:39:13 | shotofadds | gevaerts: about the tcc nand driver, I've a better understanding of how the various 0x13,0x15 and 0x17 block types fit together now (I'll add this info to the wiki at some point), but unfortunately the results from my "super improved" driver weren't quite as good as expected. |
| 20:39:23 | shotofadds | I'll produce a patch for you to try later, though |
| 20:40:13 | gevaerts | Ok. My current dump doesn't make much sense |
| 20:40:24 | bertrik | ok, it seems clip oled brightness is not controlled by the dcdc15 voltage as it is on the c200v1 and e200v1 |
| 20:41:30 | funman | bertrik: brightness != contrast ? |
| 20:41:54 | domonoky1 | funman: would this mean the external memory is already mapped when we branch to rockbox ? |
| 20:41:55 | | Join n17ikh|Lappy [0] (n=n17ikh@130-127-73-84.lightsey.resnet.clemson.edu) |
| 20:42:14 | funman | domonoky1: Yes, but I'm talking about Clipv2 here, not v1 |
| 20:42:26 | domonoky1 | ah, different clips.. :-) |
| 20:47:38 | gevaerts | linuxstb: I'd send you the compressed dump, but after dd-ing /dev/zero to a file via the OF and making a new dump, bzip2 compresses it to 7300 bytes so I'm pretty sure that this isn't very useful |
| 20:47:51 | | Quit kharo1 (Read error: 60 (Operation timed out)) |
| 20:48:31 | | Join kharo [0] (n=teemu@a88-114-245-92.elisa-laajakaista.fi) |
| 20:50:26 | | Quit pierre- (Read error: 110 (Connection timed out)) |
| 20:50:34 | | Join fml [0] (n=4fd3cefa@gateway/web/cgi-irc/labb.contactor.se/x-f49c295fe2440629) |
| 20:51:07 | fml | XavierGr: ping. Want to talk about FS #9455? |
| 20:53:18 | | Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) |
| 20:53:48 | | Join Exorcist- [0] (n=mrtilde@cpe-66-108-229-28.nyc.res.rr.com) |
| 20:54:46 | amiconn | linuxstb: Afaics it's neither mips, nor arm, sh or m68k |
| 20:56:09 | n1s | amiconn: is the flashing chapter in the manual in a reasonable state now? (i.e. can FS #5953 be closed?) |
| 20:56:50 | linuxstb | gevaerts: That sounds odd - the nand flash should contain the firmware. |
| 20:57:16 | gevaerts | linuxstb: I blame the FTL in svn |
| 20:57:27 | gevaerts | Let's see what happens with shotofadds' new version |
| 20:58:00 | | Join homielowe [0] (n=homielow@d206-116-134-81.bchsia.telus.net) |
| 20:58:19 | | Join DerDome [0] (n=DerDome@dslb-082-083-247-154.pools.arcor-ip.net) |
| 20:58:49 | fml | bluebrother: you here? Have you seen my last comment in FS #9455? Do you agree with all points? |
| 20:58:57 | linuxstb | gevaerts: Ah, I thought you were dumping the raw NAND pages? |
| 20:59:05 | funman | bertrik: IntBootSel (xpc[0]) selects ROM or external memory on the AS3525 |
| 20:59:13 | shotofadds | gevaerts, linuxstb: if your dump is from the rockbox driver it won't contain the firmware. that's in a separate, non exposed, area |
| 20:59:17 | | Join MarcGuay [0] (n=chatzill@ip216-239-67-64.vif.net) |
| 20:59:20 | amiconn | n1s: Yes. The wiki pages still need to be updated. I'll remove the basic flashing instructions as they are covered by the manual now, and collect technical background and faq-like stuff there |
| 20:59:36 | shotofadds | dump that raw NAND would be useful, though |
| 20:59:44 | shotofadds | *dumping |
| 20:59:47 | n1s | amiconn: great, I'll close that bug then |
| 21:00 |
| 21:01:27 | bertrik | funman, what do you mean to say with that? Maybe if clip v2 references "external memory" that may actually be extra RAM inside the chip, it would also allow us to boot from that RAM? |
| 21:01:51 | gevaerts | shotofadds: sure, how? |
| 21:02:23 | funman | bertrik: no, see page 188 of the AS3525 datasheet, this setting determines what is mapped at address 0 |
| 21:02:28 | *** | Saving seen data "./dancer.seen" |
| 21:03:21 | shotofadds | gevaerts: I would guess some combination of nand_read_raw() and black magic ;) |
| 21:03:35 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
| 21:04:16 | MarcGuay | TargetStatus could use some love from people in-the-know on the Meizu, m:robe500, GoGear HDD, and Elio. Also wondering if a "Boots Rockbox" column is needed... |
| 21:04:28 | | Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) |
| 21:05:02 | BigBambi | MarcGuay: Only if you define what boots Rockbox means |
| 21:06:00 | bluebrother | fml: well, I don't see a reason why someone would want to stick the first letter to the last, so why no automatic space? |
| 21:06:14 | funman | I have a problem I can't solve |
| 21:06:27 | | Join Rob2223 [0] (n=Miranda@p4FDCE09D.dip.t-dialin.net) |
| 21:07:08 | funman | AS3525 ships with a ARM922T CPU, which is in the armv4 family. the BLX instruction appeared in armv5T family. The Clipv2 uses the BLX instruction. |
| 21:07:24 | linuxstb | MarcGuay: The phrase "currently built by the Rockbox build system" isn't true for all of those targets. See http://build.rockbox.org/dev.cgi - maybe that should be a column as well. |
| 21:07:47 | linuxstb | MarcGuay: Plus the DAX can dual-boot, and the hardware can't charge, so the charging column should be "N/A" |
| 21:07:58 | linuxstb | Similarly for the m200v1 |
| 21:08:23 | bluebrother | does gcc allow creating arrays with a variable as size when putting them on the stack? |
| 21:08:25 | bertrik | nooooo, sandisk must have sensed we were about to port rockbox to a clip so they quickly started working to make it obsolete! |
| 21:08:42 | linuxstb | bluebrother: alloca? |
| 21:09:24 | funman | yes |
| 21:09:26 | bluebrother | linuxstb: I'm referring to 2. of fml's last comment in FS #9455 |
| 21:09:42 | funman | linuxstb: no, char mystring[i]; |
| 21:10:06 | linuxstb | funman: afaik, you can't do that. |
| 21:10:17 | funman | just try |
| 21:10:22 | linuxstb | Which is why I suggested alloca. But I may very well be wrong... |
| 21:10:33 | linuxstb | When/where is i defined? |
| 21:10:45 | funman | before |
| 21:11:27 | | Join dany_21a_ [0] (n=dan@84-119-1-28.dynamic.xdsl-line.inode.at) |
| 21:12:00 | | Join AndyIL [0] (i=AndyI@212.14.205.32) |
| 21:12:01 | amiconn | bluebrother: http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Variable-Length.html#Variable-Length |
| 21:13:09 | fml | bluebrother: because it makes more things possible at less cost (the code becomes simpler) |
| 21:13:55 | gevaerts | n1s: FS #9380 was masked on arm by the crash bug I guess |
| 21:14:08 | n1s | gevaerts: very likely |
| 21:15:16 | * | linuxstb should probably read a book about the other things invented by C99.... |
| 21:16:09 | MarcGuay | linuxstb: Does the m200 run off of AA batteries? Or did you mean that it can dual-boot? |
| 21:16:18 | funman | linuxstb: I think there is a (shorter than the standard) document which lists those |
| 21:16:34 | bluebrother | amiconn: thanks. |
| 21:16:51 | funman | MarcGuay: can you recharge the AA batteries with USB ? |
| 21:17:21 | bluebrother | MarcGuay: it uses AAA batteries |
| 21:17:34 | MarcGuay | funman: Not as far as I know. bluebrother: Thanks. |
| 21:17:37 | funman | let's make a deal on A* |
| 21:17:45 | gevaerts | shotofadds: you could actually make a special mode that exposes the translated device as LUN 0 and the raw nand blocks as LUN 1 |
| 21:18:32 | * | bluebrother is not sure if he likes this C99 feature in gcc |
| 21:18:55 | linuxstb | MarcGuay: Both (well, AAA). I'm pretty sure the m200 can't charge them. |
| 21:19:29 | LambdaCalculus37 | The m200 can't charge the batteries. |
| 21:19:31 | MarcGuay | Things get confusing with the m200.. The v1 (NAND) can dual-boot but the v? (HARP) can't? |
| 21:20:50 | linuxstb | MarcGuay: dual-boot really (IMO) refers to being able to load the OF. They should all be able to do that, as the bootloader is patched into the OF image, and then that modified image is flashed using the normal firmware upgrade facility in the OF |
| 21:20:51 | LambdaCalculus37 | MarcGuay: The v3 (HARP)? I'm not even sure if it can; I haven't tried. |
| 21:21:23 | linuxstb | MarcGuay: Being able to load Rockbox is obviously dependent on a NAND driver - and you have a separate column for that. |
| 21:21:55 | | Quit Exorcist- () |
| 21:23:12 | MarcGuay | And we can't refer to the first three types as v1,v2,v3 without confusing them... Okay, I see what you're saying... |
| 21:23:27 | | Quit AndyI (Read error: 110 (Connection timed out)) |
| 21:25:15 | | Join Strife89 [0] (n=michael@204.116.245.152) |
| 21:25:30 | LambdaCalculus37 | Speaking of the bootloader patched into the OF image, is it possible to do this already with the m200/c100 bootloaders? Or is there something still missing for that to happen? |
| 21:26:54 | | Quit markun ("leaving") |
| 21:27:03 | | Quit Rob2222 (Connection timed out) |
| 21:27:10 | | Quit nplus (Remote closed the connection) |
| 21:28:16 | | Join m0f0x [0] (n=m0f0x@189-47-11-46.dsl.telesp.net.br) |
| 21:31:50 | linuxstb | LambdaCalculus37: Yes, I think it's possible. You need to #define TCCBOOT to build a dual-boot bootloader, and then patch an OF with tools/mktccboot. But I'm not 100% sure if crt0.S has the correct dual-boot button check for the m200... |
| 21:33:46 | funman | In Clipv1 OF external memory is initialized just after NAND, and just before LCD |
| 21:35:06 | funman | I have figured part of the settings, but I have trouble understanding how the remaining ones are read from the stack .. |
| 21:35:46 | shotofadds | MarcGuay: the v3 (HARP) doesn't really have a port of its own right now. it really needs a new configure target, and someone to work on the SD interface |
| 21:36:22 | shotofadds | gevaerts: yes, something like that might work, and shouldn't take too long to implement. shame I'm in the middle of something else right now... |
| 21:37:33 | | Join midkay__ [0] (n=midkay@216-160-120-20.tukw.qwest.net) |
| 21:38:09 | | Quit gevaerts (Read error: 113 (No route to host)) |
| 21:38:37 | LambdaCalculus37 | shotofadds: HARP is similar to the e200/c200 way of accessing the flash, isn't it? |
| 21:38:58 | | Quit shodanX (Read error: 60 (Operation timed out)) |
| 21:39:03 | | Join shodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de) |
| 21:39:37 | | Quit fml ("CGI:IRC") |
| 21:39:39 | shotofadds | LambdaCalculus37: yes, it's that SD/NAND bridge. preglow's SD driver should work just fine, if and when he gets it working |
| 21:40:07 | * | LambdaCalculus37 looks in preglow's direction |
| 21:40:15 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 21:40:22 | | Quit karashata ("I go, only to return again some time...") |
| 21:41:09 | n1s | funman: regarding your blx question, the AMS3530 uses a ARMv5TEJ core, maybe they switched to that? |
| 21:41:47 | n1s | s/M// |
| 21:41:51 | shotofadds | LambdaCalculus37: "someone" will still have to port that SD driver to tcc77x |
| 21:42:02 | shotofadds | my "should work just fine" was probably a bit hasty ;) |
| 21:42:05 | funman | could be, the OF still mentions "AS3525_2_0.cr_5_0_develop." |
| 21:42:20 | linuxstb | gevaerts: Does this mean that logf-over-usb-serial is close to reality on the telechips targets? |
| 21:42:28 | funman | could be the AS3525 devkit with a different -mcpu option for gcc |
| 21:42:47 | funman | but then AS3525 an 3530 have to be VERY similar |
| 21:42:58 | | Quit midkay_ (Read error: 60 (Operation timed out)) |
| 21:43:11 | gevaerts | linuxstb: I think so, yes. Let me try :) |
| 21:43:56 | linuxstb | Do we know the exact markings on the AMS chips inside each device? |
| 21:45:31 | funman | no, on the Clip the chip reads 'SanDisk' not AMS |
| 21:45:32 | bertrik | I haven't seen any scans or photos of v2 clips |
| 21:45:54 | | Join markun [50] (n=markun@rockbox/developer/markun) |
| 21:47:08 | | Quit Hillshum (Read error: 104 (Connection reset by peer)) |
| 21:49:26 | | Quit bughunter2 ("bye") |
| 21:50:03 | | Join bughunter2 [0] (n=Jelle@77.164.66.126) |
| 21:51:48 | | Quit shotofadds ("Leaving") |
| 21:56:57 | | Quit kharo (Read error: 110 (Connection timed out)) |
| 21:57:25 | | Quit funman ("leaving") |
| 21:58:59 | | Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") |
| 21:59:23 | | Join kharo [0] (n=teemu@a88-114-245-92.elisa-laajakaista.fi) |
| 22:00 |
| 22:00:38 | | Join shotofadds [0] (n=rob@80-44-101-12.dynamic.dsl.as9105.com) |
| 22:01:52 | | Quit MarcGuay ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") |
| 22:02:36 | | Quit massiveH ("Leaving") |
| 22:04:08 | | Join petur [50] (n=petur@rockbox/developer/petur) |
| 22:04:21 | | Join funman [0] (n=fun@86.219.29.237) |
| 22:04:42 | funman | just wanted to tell you I can write at 0x30000000 which is the Clip SDRAM (going to verify its size) |
| 22:07:48 | funman | my incomplete code was correct, just forgot to use system_init() in the bootloader >< |
| 22:08:37 | | Join Acky [0] (n=omgwtfbb@cpc2-stok5-0-0-cust754.bagu.cable.ntl.com) |
| 22:11:00 | funman | hmm the memory is quite slow in my opinion, may need tweaking |
| 22:11:36 | linuxstb | Nice work. Is the cache enabled? |
| 22:11:44 | funman | the what ? >< |
| 22:11:57 | | Quit Acksaw (Read error: 60 (Operation timed out)) |
| 22:12:48 | XavierGr | which is faster? memcpy or strncpy? |
| 22:13:10 | funman | memcpy obviously (no \0 check) |
| 22:14:18 | XavierGr | and if I make sure that the string has \0, what is more suitable strcpy or memcpy on the whole array? |
| 22:14:41 | funman | memcpy() with a nice comment why you don't use str*cpy ;) |
| 22:15:33 | XavierGr | I used strncpy with the 3rd parameter strlen(string) + 1 in order to avoid writing the whole array |
| 22:15:38 | XavierGr | but I was told it is not so good |
| 22:15:55 | linuxstb | If there is no trailing 0, what will strlen return? |
| 22:16:06 | XavierGr | then yeah you will have a problem |
| 22:16:15 | Unhelpful | linuxstb: don't do that. ;) |
| 22:16:24 | Bagder | and if you do a strlen, you can just as well use memcpy afterwards |
| 22:16:36 | funman | hmm according to my test there is more than 8MB of RAM in the Clip (didn't found the upper limit yet) |
| 22:17:00 | bertrik | oh nice, but did you check for aliases? |
| 22:17:11 | gevaerts | Are you sure it's not just wrapping around? |
| 22:17:21 | funman | no |
| 22:17:22 | linuxstb | funman: Any idea what the extra 10MB of clipv2 firmware contains? |
| 22:17:35 | XavierGr | Bagder: imagine a char array of 10 characters, but the string in question might be less e.g 5. Shouldn't be more efficient to just call strcpy? |
| 22:17:35 | funman | I use the alias for MPMC Bank 4 |
| 22:17:56 | funman | linuxstb: code, the firmware block is > 320kB and so it has to be in external RAM (which is mapped at 0) |
| 22:17:57 | Bagder | XavierGr: yes |
| 22:17:59 | XavierGr | Bagder: instead of memcpy or strncpy on the whole array? |
| 22:18:13 | funman | but that doesn't explain the large overhead with no new features advertised |
| 22:18:18 | funman | maybe it's a debug build ;) |
| 22:18:45 | XavierGr | I see, so strcpy would be better if I make sure that the \0 always exists |
| 22:19:51 | | Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) |
| 22:20:01 | linuxstb | If the array is only 10 bytes, don't worry about speed - just write something that's safe and clear (e.g. strncpy) |
| 22:20:32 | XavierGr | linuxstb: it can be as much as 60 butes actually (but lower too on other targets) |
| 22:21:34 | XavierGr | linuxstb: can you please check #9455 in scroll_engine.c and display_menu.c, I was told by fml that strncpy with strlen is bad |
| 22:22:28 | XavierGr | or does he mean that if you call strncpy the check for \0 is done internally so the third argument needs only to be sizeof the arrya? |
| 22:22:33 | XavierGr | array too |
| 22:23:24 | * | linuxstb isn't sure he wants to get involved with 9455 |
| 22:23:42 | n1s | XavierGr: using the array size is safer since strlen will keep counting until \0 so if the string wouldn't be terminated it would stop in some random place but if you use the array size it will at least stop there |
| 22:24:03 | XavierGr | n1s: yup now it is more clear thanks |
| 22:25:25 | * | domonoky1 thinks you should use strncpy(dest,source,sizeof(dest)); dest[sizeof(dest)-1] = '\0' to be always safe .. :-) |
| 22:26:10 | Bagder | if 'dest' is reasonably small I'd do it similar to that too |
| 22:26:20 | * | linuxstb was about to suggest what domonoky1 suggested, but would write it "= 0", not ='\0' |
| 22:26:38 | domonoky1 | (if source is longer then dest, dest isnt null-terminated) |
| 22:27:04 | XavierGr | domonoky1: in my case it can't be |
| 22:27:27 | funman | weird I used a magic to check memory wrapping and I'm already past 4MB |
| 22:27:45 | domonoky1 | XavierGr: its always better to be safe, than sorry. you dont know what future modifications will do.. |
| 22:27:49 | | Quit {phoenix} (Remote closed the connection) |
| 22:27:50 | funman | maybe if the timings are wrong the data isn't correct |
| 22:28:39 | | Quit kharo (Read error: 110 (Connection timed out)) |
| 22:29:47 | | Join kharo [0] (n=teemu@a88-114-245-92.elisa-laajakaista.fi) |
| 22:29:47 | bertrik | funman, you could just write each SDRAM location with it's own address, then check all locations again |
| 22:30:22 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 22:30:25 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-ae49ccc1f38767f3) |
| 22:30:58 | XavierGr | domonoky1: sure, it is just that source points to an array which is the same length as destination (and they should be like that in any modification), but I understand your point |
| 22:31:06 | funman | bertrik: thanks |
| 22:32:58 | * | bluebrother was thinking to simply memset(dest, 0, sizeof(dest); memcpy(dest, src, sizeof(dest) - 1); |
| 22:37:32 | Bagder | that's slower though |
| 22:37:49 | XavierGr | but that would write the whole array two times |
| 22:38:28 | Bagder | remember that strncpy() zero-pads as well |
| 22:41:41 | bluebrother | true. But what happens if src is shorter than dest and dest has an old value in it? |
| 22:41:56 | bluebrother | argh, overlooked that it's a local array. Ok, scrap that |
| 22:42:15 | funman | if I read continuously a word in memory, its value stays valid |
| 22:42:33 | funman | if I loop over a bigger part, the values disappear :/ |
| 22:42:40 | | Quit anselm ("Ex-Chat") |
| 22:42:54 | bertrik | bus capacitance maybe? |
| 22:43:17 | funman | I don't know what you are talking about |
| 22:43:34 | funman | I'll try to understand what I'm doing, but tomorrow ;) |
| 22:44:02 | Bagder | sounds like bad memory refresh or similar |
| 22:44:53 | | Quit funman ("leaving") |
| 22:46:26 | bertrik | if you read very quickly after writing, the data value can be remembered by the capacitance of the data wires, so the data bus itself can act as a kind of memory (for just 1 word of data...) |
| 22:47:23 | domonoky1 | bertrik: but if it the bus, it should only work for 1 word. even 2 would destroy it.. |
| 22:47:41 | Bagder | but if the value stays "if I read continuously" it is something else |
| 22:48:00 | Bagder | to me it sounds exactly like bad memory refresh |
| 22:48:03 | bertrik | ok, agreed |
| 22:51:10 | | Join sarixe [0] (n=sarixe@ool-435407e9.dyn.optonline.net) |
| 22:56:30 | | Quit m0f0x () |
| 22:58:43 | | Quit domonoky1 (Read error: 104 (Connection reset by peer)) |
| 23:00 |
| 23:01:44 | | Quit massiveH ("Leaving") |
| 23:02:31 | *** | Saving seen data "./dancer.seen" |
| 23:04:54 | | Part dany_21a_ |
| 23:05:27 | | Quit mf0102 (Remote closed the connection) |
| 23:05:33 | | Join dany_21a_ [0] (n=dan@84-119-1-28.dynamic.xdsl-line.inode.at) |
| 23:06:45 | denes_ | shotofadds: so you wrote the telechips nand ftl stuff right? you "simply" reverse engineered the OF? how long did it take? |
| 23:10:37 | shotofadds | denes_: no, the tcc nand driver was initially written by examining raw nand blocks and trying to piece them together into contiguous data. Since then I've been trying to understand the OF code for almost a year now. Hope that doesn't put you off ;) |
| 23:10:58 | | Part dany_21a_ |
| 23:11:35 | denes_ | shotofadds: ;) well... I looked at the meizu raw nand blocks, and couldn't yet make any sense of it. |
| 23:12:37 | denes_ | and which device uses firmware/drivers/ata_flash? because that's a similar idea |
| 23:12:43 | shotofadds | I hope the meizu has a larger screen than the d2. maybe you can display a whole sector at a time :) |
| 23:13:11 | gevaerts | denes_: that's iriver ifp7xx |
| 23:13:16 | denes_ | shotofadds: yeah right :) I only cared about the additional few (64) bytes in the flash page |
| 23:13:42 | gevaerts | shotofadds: it should be the same usb driver as the tcc ones |
| 23:15:05 | shotofadds | denes_: check if any of the 'spare' bytes are the same in all sectors of a physical block. if so it's possibly a logical block number. |
| 23:15:20 | shotofadds | you can also try searching the physical blocks for known data |
| 23:16:04 | | Quit bluebrother ("leaving") |
| 23:16:09 | shotofadds | the fun starts when you find multiple physical blocks with the same logical block number ;) |
| 23:16:45 | | Join lostnfound [0] (n=a81087b3@gateway/web/cgi-irc/labb.contactor.se/x-a9a3b925d56a0836) |
| 23:16:51 | | Join Slack [0] (n=brett@12-218-63-169.client.mchsi.com) |
| 23:16:51 | lostnfound | hello |
| 23:17:15 | denes_ | shotofadds: yes, I have found the first logical block. it's the 22016. page ;) |
| 23:17:17 | lostnfound | I found an iPod today, and it had this operating system on it |
| 23:17:38 | lostnfound | is there anyway it has information on the person that used it |
| 23:17:45 | shotofadds | gevaerts: yes, usb should be a rather significant help too! any idea what I'd have to do to get logf-over-usb working (either on m200 or d2)? |
| 23:18:05 | shotofadds | denes_: but is it always in the same physical location? I suspect not. |
| 23:18:15 | denes_ | shotofadds: probably not |
| 23:18:18 | Bagder | lostlogic: connect it to a computer and investigate the files on it |
| 23:18:27 | lostnfound | There are a few pictures |
| 23:18:28 | Bagder | lostnfound: even |
| 23:18:34 | lostnfound | but the OS is hard to get used to |
| 23:18:59 | Bagder | lostnfound: I think some of us may disagree with that |
| 23:19:11 | lostnfound | I didn't want to plug it in to my computer and have it sync to the foreign iPod instead of mine |
| 23:19:24 | gevaerts | shotofadds: I'm now trying to get it to work on DAX |
| 23:19:37 | Bagder | lostnfound: what, it syncs without you asking it to? |
| 23:20:19 | | Join webguest64 [0] (n=1824bd5b@gateway/web/cgi-irc/labb.contactor.se/x-8efb12a830083d1d) |
| 23:20:32 | webguest64 | hi |
| 23:20:36 | webguest64 | is anyone there? |
| 23:20:51 | lostnfound | I'm not sure |
| 23:20:57 | webguest64 | great |
| 23:21:01 | lostnfound | That is why I haven't connected it to the computer |
| 23:21:12 | shotofadds | gevaerts: excellent work! hopefully we can find a way to spit binary data through "logf" too |
| 23:21:19 | lostnfound | for fear of it syncing with my computer and giving me more work to do |
| 23:21:24 | webguest64 | Do you think rockbox is going to work on the v2 versions of the sansa e200? |
| 23:21:27 | gevaerts | shotofadds: I |
| 23:21:38 | gevaerts | I'd really go for the mass-storage way for that |
| 23:21:48 | webguest64 | I tried that |
| 23:21:48 | webguest64 | yeah I know |
| 23:21:51 | Bagder | webguest64: yes, we have great hopes of that it eventually will |
| 23:22:04 | webguest64 | great that is just what I wanted to hear |
| 23:22:19 | webguest64 | if you could estimate how long do you think it would take? |
| 23:22:21 | lostnfound | its an interesting OS concept |
| 23:22:29 | lostnfound | but it won't work on my touch |
| 23:22:35 | Bagder | webguest64: if we could estimate we would, but we can't |
| 23:22:44 | webguest64 | ok thanks |
| 23:22:57 | shotofadds | gevaerts: yes, that sounds sensible. a quick hack to allow that should take all of 30 seconds if mass storage works |
| 23:23:10 | webguest64 | No mass storage doesn't work |
| 23:23:15 | | Join BigBambi_ [0] (n=Alex@rockbox/staff/BigBambi) |
| 23:23:23 | Bagder | lostnfound: true, but it runs on some 28 other music players |
| 23:23:24 | webguest64 | it detects it then when you try to install it thinks it isn't there |
| 23:23:27 | | Quit BigBambi (Nick collision from services.) |
| 23:23:34 | gevaerts | shotofadds: I can post a patch that uses a block of RAM instead of the ata_* layer if you like |
| 23:23:34 | | Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-17fecfa36061c207) |
| 23:23:35 | | Nick BigBambi_ is now known as BigBambi (n=Alex@rockbox/staff/BigBambi) |
| 23:23:46 | webguest64 | Auto-detect finds it but when you try to install it thinks it isn't there |
| 23:23:53 | Bagder | webguest64: that discussion has nothing to do with your v2 question |
| 23:24:07 | Bagder | there are 140 persons here and there are more than one conversation at once at times |
| 23:24:09 | webguest64 | o |
| 23:24:17 | webguest64 | that makes sence |
| 23:24:20 | webguest64 | I think |
| 23:24:32 | Bagder | Rockbox does not work on the sansa v2 at this point in time, so tryign to install it is pointless |
| 23:24:33 | soap | blubrother (for logs) - I can get you a H10 with "battery issues" for $15 + shipping. |
| 23:24:33 | | Quit webguest64 (Client Quit) |
| 23:24:41 | soap | bluebrother even |
| 23:24:44 | shotofadds | gevaerts: if mass storage "works" currently, I'll just tweak the ata_read_sectors to return raw data instead for now |
| 23:24:51 | | Join Munkie [0] (n=Alex@dsl-245-168-10.telkomadsl.co.za) |
| 23:25:01 | lostnfound | Guess I'll sell this bitch |
| 23:25:18 | gevaerts | shotofadds: it works on tcc77x anyway |
| 23:25:19 | | Join hd [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) |
| 23:25:26 | lostnfound | dunno |
| 23:25:49 | saratoga | linuxstb: the high WMA DRAM ussage is almost all look up tables |
| 23:25:56 | Munkie | If any of you are in need of a laugh, go to the apple forums and search for rockbox. |
| 23:25:59 | saratoga | the format needs a very large number of look up tables |
| 23:26:04 | lostnfound | I haven't looked but is there a walkthrough on how to uninstall |
| 23:26:04 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 23:26:13 | gevaerts | shotofadds: I didn't get it to run last time I tried on the D2, but you probably know that one better |
| 23:26:29 | gevaerts | lostnfound: easiest way is to let itunes do a restore |
| 23:26:31 | saratoga | the LSP feature needed for files less then 16kbps uses a 32KB lookup table for one function |
| 23:26:43 | | Quit Schmogel (Read error: 104 (Connection reset by peer)) |
| 23:26:44 | shotofadds | gevaerts: I have my m200 here ready to try, but it'll probably have to wait til tomorrow. Time is a bit scarce at the moment :/ |
| 23:26:53 | saratoga | this could be paired down, but I haven't due to a poor understanding of how some of the codec's features work |
| 23:26:53 | lostnfound | Alright, as long as it wont sync automatically. |
| 23:27:01 | | Quit HellDragon (Read error: 104 (Connection reset by peer)) |
| 23:27:21 | linuxstb | saratoga: But in bss? So they're calculated at init time? |
| 23:27:42 | saratoga | linuxstb: oh I didn't realize BSS was all runtime |
| 23:27:45 | saratoga | a lot are, but not all |
| 23:28:16 | saratoga | text is predefined tables and code then? |
| 23:28:17 | linuxstb | Yes, "BSS" is zero-initialized data. |
| 23:28:32 | linuxstb | Yes, text is code and const data |
| 23:29:07 | saratoga | then its probably the huffman tables, various trig tables, etc |
| 23:29:25 | saratoga | due to an odd detail about how the MDCT works in WMA, each trig table is roughly 2x as big as most other MDCT codecs |
| 23:33:57 | | Quit lostnfound ("CGI:IRC (EOF)") |
| 23:35:50 | | Quit fyre^OS (Remote closed the connection) |
| 23:36:06 | | Join fyrestorm [0] (n=nnscript@cpe-68-173-234-148.nyc.res.rr.com) |
| 23:42:44 | | Quit ender` (Read error: 104 (Connection reset by peer)) |
| 23:43:19 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
| 23:46:31 | linuxstb | Bagder: Can you remember enough about the V1 Sansas to think of what could be the issue here? http://forums.rockbox.org/index.php?topic=19091.0 |
| 23:46:46 | shotofadds | gevaerts: could you post that UMS-from-RAM patch? I'll try it out when I get a chance tomorrow |
| 23:46:50 | | Quit Siku () |
| 23:46:56 | gevaerts | shotofadds: actually I' |
| 23:47:03 | gevaerts | shotofadds: actually I'm thinking of just committing it |
| 23:47:12 | | Quit Munkie ("Leaving") |
| 23:47:13 | shotofadds | or that :p |
| 23:48:12 | Bagder | linuxstb: the only hint is his read-mode comment, which usually implies file system breakage |
| 23:50:06 | | Quit lasser (Remote closed the connection) |
| 23:51:38 | gevaerts | shotofadds: committed. The size near the top is in sectors |
| 23:52:58 | | Quit hd (Remote closed the connection) |
| 23:53:25 | | Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) |
| 23:55:52 | | Quit ender` (" A computer program will always do what you tell it to, and seldom what you want it to.") |
| 23:58:08 | | Quit bughunter2 ("bye") |
icon identifies that the person is a core developer (has commit access).