| 00:00:47 | LinusN | 3) The i2c drivers were developed when there were no recorders |
| 00:02:23 | amiconn | To (1): If this is old code, I'll try to move the mas_reset() into the startup code (only), and try if the dsp reset/ codec reset bits in MAS_CONTROL are of any use. |
| 00:02:50 | LinusN | do so |
| 00:03:08 | LinusN | funny though, i have had the opposite experience |
| 00:03:29 | amiconn | In what respect? |
| 00:03:44 | LinusN | i had to go to the recording screen, back to playback and then back to recording |
| 00:04:12 | amiconn | Did you read my bug description at the bottom of the RomBox wiki page? |
| 00:04:15 | LinusN | if i just went to the rec screen, it would record 30 bytes |
| 00:05:10 | LinusN | just read it now |
| 00:06:51 | amiconn | Btw: I'm just doing a long-term test recording - 24 hours at q=7, 44.1 kHz stereo. Will check that for frame errors |
| 00:07:31 | amiconn | Next will be a frequent time-split recording (several hours in 1 minute chunks) |
| 00:10:07 | LinusN | how big are your FAT clusters? |
| 00:11:36 | LinusN | amiconn: bad news from Paul on the mailing list |
| 00:13:47 | amiconn | LinusN: fat_cluster_size == 32768 (80 GB drive) |
| 00:14:03 | amiconn | What bad news? :( |
| 00:14:25 | LinusN | big clusters == better recording performance |
| 00:14:34 | LinusN | so you should try smaller clusters |
| 00:15:03 | LinusN | bad news == Paul's recording problems went away when he tried the non-optimized ATA version |
| 00:15:53 | amiconn | Iirc 32 KB is the default size for fat32 for partitions >32 GB. I can't choose the cluster size with Win98, and WinXP doesn't even let me format such a large fat32 partition... |
| 00:17:17 | amiconn | Concerning the ATA problem: Did he also try versions with only fast reading/ fast writing disabled? Disk model? hd firmware? hw mask? Archos model? |
| 00:18:04 | LinusN | no more info yet |
| 00:18:52 | amiconn | To (2): Did you do logic analyses of the i2c drivers? If yes, do you have them still available? |
| 00:19:22 | LinusN | yes i did, but i didn't keep them |
| 00:19:34 | LinusN | i can do new ones, i have my kit with me |
| 00:20:14 | amiconn | If this doesn't cause too much hassle, it could be interesting. I still have the viewer installed... |
| 00:21:06 | amiconn | As it gets to logic analyzing: Do you think this may shed some light on the recording init problem after mas_reset() too? |
| 00:21:27 | LinusN | not sure |
| 00:22:28 | amiconn | Remember that I even managed to trigger the bug once when running from ram. Others did also report that this 30-byte free happens occasionally... |
| 00:22:37 | amiconn | s/free/freeze/ |
| 00:23:09 | LinusN | i got it a few times when running with gdb |
| 00:24:23 | LinusN | your latest stack fix, was that to munge the entire stack with DEADBEEF? |
| 00:25:21 | amiconn | Yes, because otherwise the main thread panics with stov after using "create directory" |
| 00:25:31 | amiconn | s/stov/stkov/ |
| 00:25:46 | LinusN | ok, but you didn't reply to the bug report |
| 00:26:38 | amiconn | Sorry, I didn't realise that there was one. Two users reported it to me on the channel |
| 00:26:45 | LinusN | i'm replying now |
| 00:26:57 | LinusN | nice catch, btw! |
| 00:27:16 | amiconn | I didn't manage to get this myself, because my stack area was a little larger due to using my geek bitswap, so my .iram is smaller |
| 00:27:43 | amiconn | However, I got very high stack usage readings after trying that (96..97%) |
| 00:28:05 | LinusN | badness |
| 00:28:45 | amiconn | I wonder why you changed the linker script in the first place... |
| 00:29:28 | LinusN | there is a bug in older binutils versions that allows sections to overlap |
| 00:29:46 | LinusN | it is now fixed, so i changed the script to comply with that |
| 00:30:53 | LinusN | from the CVS commit log: "Major fixes to please newer versions of the linker" |
| 00:30:55 | amiconn | Ah ok. So my fix was "intuitively" right. I also tried defining the start position of the .stack section differently, so that it overlaps with .iram. This worked for me too... |
| 00:32:21 | amiconn | Strangely, I once tried to compile gcc 3.4.1 and current binutils under cygwin (successfully) and then built rockbox with that. This did work too, even without your linker script fixes... |
| 00:33:07 | LinusN | which binutils version? |
| 00:33:57 | amiconn | 2.15 |
| 00:34:04 | LinusN | weird |
| 00:37:05 | amiconn | For fixing (3): Should there be an additional config define, HAVE_MAS_ENABLE or such? |
| 00:38:14 | LinusN | nah, move the code somewhere else, with #ifdef HAVE_MAS3507D |
| 00:38:47 | LinusN | it'll break the neo, but frankly, i don't care |
| 00:39:03 | LinusN | but yes, your approach is cleaner |
| 00:39:38 | amiconn | Iirc the neo is broken anyway (still builds without warning, but most probably won't run) |
| 00:42:12 | LinusN | and that's why i don't care... :-) |
| 00:42:51 | *** | Saving seen data "./dancer.seen" |
| 00:43:56 | | Quit zeekoe ("quit...") |
| 00:44:17 | amiconn | The latest bug in the tracker looks like another "classic" rld case... |
| 00:44:44 | LinusN | not really |
| 00:45:16 | LinusN | well,maybe it is... |
| 00:47:02 | amiconn | A propos CVS commit log: is there a way to show older entries than those listed on the web page, in chronological order? |
| 00:47:48 | LinusN | "cvs log" |
| 00:48:22 | amiconn | And a completely different thing: Why http://rockbox.haxx.se/docs/contributing.html says "Also, avoid using 'const'." |
| 00:48:35 | LinusN | yes |
| 00:49:34 | amiconn | ? |
| 00:49:35 | LinusN | can you guess why it says so? |
| 00:49:42 | amiconn | No |
| 00:50:13 | LinusN | because life is a lot easier if you don't care |
| 00:51:36 | amiconn | Imho using 'const' helps to write cleaner code: if you intend to have a read-only variable, declare it 'const', and then later on assign something to it, the compiler will warn you. |
| 00:53:09 | LinusN | i mostly use #define for constants |
| 00:53:11 | amiconn | Other than that, it does have no effect unless the code is running from rom... |
| 00:53:39 | LinusN | ...and rockbox was never intended to run from rom |
| 00:55:12 | amiconn | ...at the time it was designed. As you said some time ago, thorough checking for proper 'const' use may help in case rockbox gets ported to some other hardware some day |
| 00:55:55 | LinusN | yes, and back then we didn't intend to port rockbox to another platform |
| 00:56:07 | amiconn | ...and using 'const' instead of #define may save some memory in case the compiler doesn't do proper constant folding |
| 00:57:21 | amiconn | So my point is not knowing why the document said so in the past, but why it _still_ does. |
| 00:57:44 | LinusN | because we haven't bothered changing them |
| 00:59:09 | amiconn | Perhaps this sentence should be taken out then |
| 01:00 |
| 01:01:11 | LinusN | one main problem with "const" is that C++ programmers think that const works the same way in C as well |
| 01:01:30 | LinusN | (i just removed the sentence) |
| 01:06:02 | | Join sethians [0] (~jirc@200.87.77.112) |
| 01:12:59 | | Join Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de) |
| 01:17:42 | | Quit sethians ("Leaving") |
| 01:20:48 | amiconn | LinusN: (i2c timing) Both mas' want at least 1250 ns SCL high according to the specs. When running from ram, the current implementation of i2c_outb() holds SCL high for only 270 ns (recorders)/ 250 ns (players) [possibly 360 ns/ 333 ns due to pipeline contention] |
| 01:38:59 | LinusN | ic |
| 01:40:53 | ze | ok so there's no iptables rules, hosts.allow and hosts.deny are set to allow my network, the services are started, the network's up, the box is pingable, nmap accross the network to the box's network ip shows a handful of open ports, nmap on the local box to the box's network ip show all the ports that should be open, all the important services (web, samba, ssh) are set to bind to the box's network ip and are available on the local box |
| 01:41:57 | LinusN | ze: wrong channel |
| 01:42:27 | ze | well whats the right one |
| 01:42:29 | ze | heh |
| 01:42:39 | ze | this is the only active one with linux people i'm in |
| 01:42:57 | ze | if you got no idea thats ok, but if you do don't just say wrong channel hehe |
| 01:45:27 | LinusN | ze: so what's your problem? |
| 01:45:45 | ze | can't connect to web/ssh/samba from accross the network |
| 01:46:50 | LinusN | what happens if you do telnet to port 80? |
| 01:47:21 | ze | hmm |
| 01:47:26 | ze | well it was giving me connection refused |
| 01:47:31 | ze | and now it's spontaneously decided to work |
| 01:47:57 | ze | both ssh and web gave me connection refused every time i tried |
| 01:48:15 | ze | is there something that'd cause that to be like that for some period of time and then after a while it'd kick in? heh |
| 01:48:33 | ze | i dunno, it's weird |
| 01:49:01 | amiconn | LinusN: My 24 h recording finished - bad news :( |
| 01:49:28 | ze | after the box boots up, the only open ports are 135, 139, 445, 1025 (as reported by nmap) ... but nmap'ing locally, or now after whatever spontaneously happened, i get 22, 80, 111, 139, 445, 6543, and 6544 as i should |
| 01:50:24 | LinusN | ze: weird indeed |
| 01:50:31 | LinusN | amiconn: corrupt frames? |
| 01:51:42 | amiconn | Mp3utility reports a sync error a little above 3 minutes in the 24h file, and right at the beginning of the file started after the 24 h split. Unfortunately it stops analyzing after encountering the first error |
| 01:53:04 | amiconn | Vbrfixer tells me there are 4 mpeg version changes in the short file (this is only 314 KB !). It is unable to analyze the big one: runtime error - out of memory |
| 01:53:11 | ze | err scratch 6534 and 6544.. those only show up locally, which is probably right, but the rest is as i said |
| 01:53:30 | ze | it's like it doesn't start working till the uptime reaches 10 or 15 minutes |
| 01:53:30 | ze | heh |
| 01:55:02 | LinusN | amiconn: could be disk related problems |
| 01:55:29 | ze | er! it's doing it again |
| 01:55:34 | ze | Read from remote host pvr: Connection reset by peer |
| 01:55:34 | ze | Connection to pvr closed. |
| 01:55:44 | * | ze checks the crontab |
| 01:58:20 | LinusN | amiconn: gotta sleep now |
| 01:58:39 | amiconn | nite LinusN |
| 01:59:12 | ze | hmm i bet it's this 'shaper' crap whatever it is |
| 01:59:16 | amiconn | (Just checking with mp3fixer, although I know that the windows version isn't always reliable) |
| 01:59:25 | ze | seems to run every 10 minutes and is something about traffic control |
| 02:00 |
| 02:00:06 | ze | and all i had to do was wait 20 minutes |
| 02:00:06 | ze | :p |
| 02:00:32 | ze | if thats actually it |
| 02:00:47 | LinusN | ok, nite all |
| 02:00:50 | | Part LinusN |
| 02:01:25 | ze | er doh... well if you see the longs, Thanks and goodnight heh |
| 02:01:31 | ze | s/longs/logs/ |
| 02:12:13 | ze | haha it might not be though, apparently i'm using an ip address thats already in use :p |
| 02:17:58 | ze | teehee that was it... how stupid |
| 02:18:17 | ze | that'll teach me to leave out an /etc/hosts entry for a new system |
| 02:24:38 | amiconn | nite all |
| 02:25:26 | | Part amiconn |
| 02:42:54 | *** | Saving seen data "./dancer.seen" |
| 02:45:24 | | Quit AciD (Read error: 104 (Connection reset by peer)) |
| 02:46:01 | | Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 03:00 |
| 03:05:45 | | Quit Nibbler (Read error: 104 (Connection reset by peer)) |
| 03:24:35 | | Join Heil_Eri1 [0] (~centericq@p508B3B13.dip.t-dialin.net) |
| 03:42:22 | | Quit Heil_Eris (Read error: 110 (Connection timed out)) |
| 04:00 |
| 04:42:58 | *** | Saving seen data "./dancer.seen" |
| 04:46:08 | | Join edx{code} [0] (edx@pD9EAB9F0.dip.t-dialin.net) |
| 04:46:44 | | Join Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de) |
| 04:57:41 | | Quit edx{code} () |
| 05:00 |
| 05:02:23 | | Quit edx (Read error: 110 (Connection timed out)) |
| 05:03:55 | | Quit Hadaka (Read error: 110 (Connection timed out)) |
| 05:19:01 | | Quit Nibbler (Read error: 54 (Connection reset by peer)) |
| 06:00 |
| 06:42:59 | *** | Saving seen data "./dancer.seen" |
| 06:59:28 | | Join Naked [0] (naked@naked.iki.fi) |
| 06:59:49 | | Nick Naked is now known as Hadaka (naked@naked.iki.fi) |
| 07:00 |
| 07:04:33 | | Join Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de) |
| 07:35:24 | | Quit AciD (Read error: 54 (Connection reset by peer)) |
| 07:35:24 | | Quit Nibbler (Read error: 54 (Connection reset by peer)) |
| 08:00 |
| 08:23:31 | | Join Madman [0] (~madmangor@69.107.248.21) |
| 08:24:29 | Madman | cool, you fixed the stkov error when making a dir in the new build |
| 08:24:58 | Madman | i was talking to amiconn and midk about it |
| 08:30:45 | | Quit Madman () |
| 08:43:02 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 09:00:29 | | Join Bagder [241] (~dast@labb.contactor.se) |
| 09:00:40 | Bagder | ok amp let me out |
| 09:01:07 | Bagder | hello good people |
| 09:05:23 | | Join Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de) |
| 09:07:49 | | Join amiconn [0] (~jens@pD95D1D06.dip.t-dialin.net) |
| 09:30:04 | dwihno | Hello, fellow Bagder. The amp won't let you go \o/ |
| 09:30:05 | | Quit Nibbler (Read error: 104 (Connection reset by peer)) |
| 09:38:51 | | Join Zagor [242] (~bjst@labb.contactor.se) |
| 09:41:19 | | Join edx [0] (edx@pD9EAB9F0.dip.t-dialin.net) |
| 09:44:23 | Bagder | http://www.opengroup.org/publications/graphics/n900cov.jpg |
| 09:44:33 | Bagder | now, can I have that on my car? ;-) |
| 09:45:14 | Zagor | :) |
| 09:45:37 | Zagor | i would guess both UNIX and LINUX are taken already |
| 09:45:44 | Bagder | yeps |
| 09:46:19 | Zagor | probably not CURL though ;) |
| 09:46:38 | Bagder | its just a bit too expensive to be worth it, imho |
| 09:46:52 | Zagor | how much is it? |
| 09:47:07 | Bagder | it used to be 5000 SEK |
| 09:47:15 | Bagder | for a few years only |
| 09:47:25 | Bagder | but I know they talked about raising the fee |
| 09:47:26 | Zagor | it's time limited? |
| 09:47:28 | Bagder | yes |
| 09:47:32 | Zagor | weird |
| 09:47:51 | Zagor | deduct it as a marketing expense ;) |
| 09:48:00 | Bagder | :-) |
| 09:49:24 | Bagder | that plate is available as a mug too ;-) |
| 09:49:30 | * | Bagder considers buying one |
| 09:49:42 | Zagor | :) |
| 09:51:38 | Bagder | http://www.opengroup.org/bookstore/catalog/n901.htm |
| 09:51:44 | Bagder | also a fun product |
| 09:52:02 | Bagder | "don't leave home without it" ;-) |
| 09:52:36 | Zagor | business card cdroms are always fun. rather useless content though |
| 09:53:20 | Bagder | the SUSV3! ;-) |
| 09:53:36 | Bagder | when you buy that in hardcopy, is 11kg! |
| 09:54:45 | Zagor | haha |
| 09:54:51 | Zagor | ...as we all do |
| 09:55:06 | Bagder | stupid google refused my app due to "bad postal address" |
| 09:57:27 | Bagder | but the mail was in swedish |
| 09:57:42 | Bagder | and they didn't say what was bad with it |
| 09:59:43 | Zagor | maybe it was in their pyramid scheme blacklist |
| 10:00 |
| 10:00:32 | Bagder | and then proceeded and said, if you want to fix it, fill in a new application with a DIFFERENT email adress since this one is now connected to the failed application |
| 10:00:42 | dwihno | hmm |
| 10:01:07 | Zagor | haha, and that failed application can never be fixed? |
| 10:01:12 | Bagder | yeps |
| 10:01:13 | dwihno | since you guys are ninjas when it comes to virtually anything, do you know what might cause a crc checksum failure with large packets? I'm testing a midlet ssh client which is driving me nuts :) |
| 10:01:22 | Bagder | and since I don't know what the problem was, I'm deemed to repeat it |
| 10:01:22 | Zagor | cute system |
| 10:01:44 | Zagor | there must be a contact address somewhere |
| 10:01:48 | Bagder | yes |
| 10:01:52 | Bagder | I mailed them |
| 10:02:10 | Bagder | dwihno: you're talking about crc problems on the network? |
| 10:03:14 | dwihno | Bagder: Not really... Larger packets seem to trigger the crc failure |
| 10:03:25 | dwihno | as long as the packets are small, it runs so smoothly! |
| 10:03:33 | Bagder | so the ssh client is what detects the checksum problems? |
| 10:03:43 | dwihno | yup |
| 10:04:07 | dwihno | there must be a problem in the client since the Z1010 is the only phone with this specific problem |
| 10:04:26 | Bagder | yes |
| 10:04:38 | Bagder | the traffic is checksumed already on the TCP layer |
| 10:04:54 | Bagder | it can't be bad when the app receives it, unless the server sent bad data |
| 10:04:59 | dwihno | yeah |
| 10:05:27 | dwihno | A couple of larger packets just trigger the internal crc failure |
| 10:05:48 | Bagder | it sounds like a good old application bug |
| 10:06:13 | dwihno | Rather strange it only occurs on my phon.e |
| 10:08:25 | dwihno | Well. I've contacted the author with my findings. Perhaps he has any ideas. |
| 10:33:33 | dwihno | Using the telnet-only version of the client, the same problems arise. I wonder what might be wrong |
| 10:43:05 | *** | Saving seen data "./dancer.seen" |
| 10:45:28 | Bagder | possibly because you have an usual MTU? |
| 10:49:40 | dwihno | MTU? |
| 10:50:00 | dwihno | Telia felia lingonbär \o/ :) |
| 10:50:06 | Zagor | maximum transmission unit |
| 10:51:40 | dwihno | Changeable? |
| 10:53:40 | dwihno | Fixable? :) |
| 10:53:42 | dwihno | Repairable? |
| 10:54:23 | Zagor | MTU is the maximum block size your device sends. it can be changed, but generally you don't want to do that since it will affect retransmissions etc. |
| 10:54:54 | dwihno | Okay |
| 10:55:15 | dwihno | It is the receiving that breaks, afaik |
| 10:55:20 | dwihno | Perhaps MTU affects both? |
| 10:56:42 | Zagor | yes |
| 10:59:02 | Bagder | I'm just suggesting that the app might have some assumptions in the code that your situation breaks |
| 11:00 |
| 11:01:44 | dwihno | the application assumes larger buffers than the phone has to offer? (otherwise, it should work, huh?) |
| 11:02:32 | Bagder | well, I refrain from guessing exact details, but since it complains on bad checksums and it really shouldn't be any checksum errors... |
| 11:04:01 | dwihno | It isn't just the checksum |
| 11:04:15 | dwihno | I've tried the plain telnet version of the software and it still bangs |
| 11:05:45 | dwihno | So if I was to fix the telnet version, the same fix could most likely be applied on the ssh software |
| 11:07:01 | Bagder | perhaps the bug is in code used independent of the actual transport (ssh or plain telnet) |
| 11:08:17 | dwihno | could be |
| 11:08:28 | dwihno | might be |
| 11:08:29 | | Join Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de) |
| 11:08:32 | dwihno | must be |
| 11:08:33 | dwihno | :-) |
| 11:49:50 | | Quit Nibbler (Read error: 104 (Connection reset by peer)) |
| 11:53:58 | webmind | morning |
| 12:00 |
| 12:10:03 | webmind | anyone here know if linux mass storage driver can take 2 disks on 1 usb-ata controller ? |
| 12:13:15 | amiconn | webmind: I guess this depends on the implementation of the usb-ata bridge. Usb mass storage uses the scsi protocol, so the os driver shouldn't be the limiting factor |
| 12:13:46 | webmind | hmm |
| 12:14:00 | webmind | any idea if it would work on the chip ? |
| 12:36:59 | Zagor | i guess it will work, since the ata bus handles two devices and thus the chip does not have to do anything special to support it |
| 12:39:03 | Zagor | have you checked the data sheet? |
| 12:42:10 | webmind | just did.. chip claims to be fully ata/atapi compliant.. |
| 12:42:14 | webmind | so should be no problem |
| 12:43:09 | *** | Saving seen data "./dancer.seen" |
| 12:43:10 | Zagor | are you going to mount dual flash cards, or what is your plan? |
| 12:44:42 | webmind | my HD on my laptop is dying... |
| 12:44:56 | webmind | so i'm thinking of making a portable raid system |
| 12:45:17 | webmind | raid I can do in software.. so just need 2 disks |
| 12:46:02 | Zagor | aha. battery powered or just movable? |
| 12:46:10 | webmind | battery powered |
| 12:46:16 | Zagor | neat |
| 12:46:21 | webmind | uhuh |
| 12:46:59 | webmind | especially since I will probably will be able to combine it with my pda |
| 12:48:33 | Zagor | a zaurus? or does anyone else have usb host ports these days? |
| 12:57:21 | webmind | uhuh |
| 12:57:26 | webmind | zaurus sl-6000L |
| 13:00 |
| 13:09:26 | | Join Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de) |
| 13:49:25 | | Quit Nibbler (Read error: 104 (Connection reset by peer)) |
| 14:00 |
| 14:43:11 | *** | Saving seen data "./dancer.seen" |
| 14:49:16 | | Part Zagor |
| 14:49:27 | | Join Zagor [242] (~bjst@labb.contactor.se) |
| 15:00 |
| 15:09:13 | | Quit gromit`` (Remote closed the connection) |
| 15:22:33 | | Join Ericgoh [0] (~kapipo@p29150-adsau12honb7-acca.tokyo.ocn.ne.jp) |
| 15:22:52 | Ericgoh | is Zagor here? |
| 15:23:24 | Bagder | Zagor: BOOO |
| 15:23:41 | Ericgoh | ah... |
| 15:23:50 | Ericgoh | got something wanna ask him |
| 15:23:55 | * | Bagder tries to scare him awake |
| 15:24:59 | Ericgoh | i am trying to find the datasheets for portalplayer IC, heard that Zagor has it |
| 15:25:14 | Ericgoh | wonder is anyone here has the datasheet too? |
| 15:25:23 | Bagder | he doesn't have that |
| 15:25:27 | Ericgoh | ?? |
| 15:25:29 | Bagder | I don't think anyone has |
| 15:25:40 | Bagder | unless they chop off an arm and a leg |
| 15:26:03 | Ericgoh | coz i saw the irc log in rockbox homepage saying that he got it from someone else |
| 15:26:20 | Bagder | then I'm wrong |
| 15:26:33 | Bagder | but I don't think I am |
| 15:26:50 | Zagor | i'm here |
| 15:26:58 | * | Bagder jumps |
| 15:27:06 | Bagder | don't scare us like that |
| 15:27:09 | Zagor | bagder is right, i don't have the sheets. |
| 15:27:15 | Ericgoh | ohh |
| 15:27:32 | Zagor | i got an agreement to sign that required me to be their eternal soul slave and sign off my firstborn. |
| 15:27:32 | Ericgoh | maybe i misunderstood |
| 15:27:43 | Ericgoh | haha |
| 15:29:45 | Ericgoh | the stupid portalplayer keep their IC so secret that nobody knows wtf they doing |
| 15:30:18 | Bagder | the question is why companies buy it |
| 15:31:17 | Ericgoh | ?? |
| 15:31:54 | Ericgoh | do you mean LSI Logic? |
| 15:32:01 | Bagder | why do companies build players based on portalplayer |
| 15:32:34 | Bagder | maybe this shows why I don't run a company that does that ;-) |
| 15:33:03 | | Join Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de) |
| 15:33:22 | Ericgoh | oh... |
| 15:33:51 | Ericgoh | but portalplayer eating the battery power like hell |
| 15:34:22 | Ericgoh | also the reason why player based on portalplayer sucks on their playtime |
| 15:34:46 | Zagor | i'm guessing the portalplayer chip is part of an attractive package with nearly complete firmware and so on. |
| 15:35:04 | Ericgoh | <−−agree |
| 15:35:04 | Bagder | most likely, yes |
| 15:35:12 | Zagor | which means less work for the manufacturer == less risk == easier to calculate for the bean counters |
| 15:35:19 | Ericgoh | portalplayer actually selling their solution but not IC |
| 15:35:26 | Zagor | right |
| 15:35:41 | Bagder | jumping off a cliff is cheap too ;-) |
| 15:36:01 | Zagor | :) |
| 15:36:23 | Ericgoh | yap, hope ipod jumping off the cliff one day |
| 15:36:28 | Ericgoh | really hate ipod |
| 15:37:35 | Ericgoh | <−−anti-apple |
| 15:37:45 | Zagor | i can't say i hate ipod. i more dislike uncritical consumers |
| 15:38:47 | dwihno | \o/ |
| 15:39:04 | dwihno | Regular hard disk players with NORMAL batteries si teh bestest! :) |
| 15:39:24 | Bagder | they will be history soon |
| 15:39:56 | Ericgoh | hope such day comes as early as possible |
| 15:41:54 | dwihno | Bagder: hush! don't say that! |
| 15:42:25 | Ericgoh | ipod is now trying to do like microsoft to monopolize the market |
| 15:43:22 | Bagder | every company would want to do that |
| 15:43:46 | Bagder | but as Zagor said, its the consumers that let them |
| 15:44:06 | dwihno | That reminds me. Any of you guys have a cheap 512 meg memorystick duo for sale? ) |
| 15:44:10 | dwihno | :) |
| 15:44:30 | Ericgoh | so consumers should think wise before they buy, not just buying through advertisements |
| 15:44:48 | Ericgoh | ??MS DUO |
| 15:44:57 | Ericgoh | you want that for what? |
| 15:45:11 | Ericgoh | you never get MS for cheap |
| 15:46:29 | dwihno | My cell phone |
| 15:46:34 | dwihno | I want to keep some music in it. |
| 15:46:40 | dwihno | 256 meg chips are affordable |
| 15:47:18 | Bagder | when talking about not buying crappy products, memorystick sure is a good thing to mention ;-) |
| 15:47:23 | Zagor | does your phone use memorystick? is it a sony? |
| 15:47:25 | Ericgoh | that's rare |
| 15:47:45 | Ericgoh | haha, what else other than sony use MS |
| 15:47:47 | dwihno | Zagor: yep. and the chip is 100% covered as well |
| 15:47:55 | dwihno | Ericgoh: Behave :) |
| 15:48:34 | Ericgoh | MS license almost double of SD Card, only rich company afford to use that |
| 15:48:36 | Zagor | rule #1: never buy sony hardware |
| 15:48:51 | dwihno | Zagor: how come? |
| 15:49:18 | Bagder | proprietary crap |
| 15:49:20 | Zagor | they always use crappy proprietary things like memory stick to force you to buy everything else from sony too |
| 15:49:20 | Ericgoh | Sony is throwing all the useless rubbish into MS causing it to be so much bigger than SD |
| 15:49:45 | Ericgoh | also increasing the development cost for MS |
| 15:59:39 | dwihno | Zagor: well, I'm really satisfied with my phone anyhow :) |
| 15:59:55 | Zagor | which model is it? |
| 16:00 |
| 16:01:04 | dwihno | z1010 |
| 16:02:31 | Ericgoh | how many hours of music can you play with it? |
| 16:02:41 | dwihno | Dunno really... |
| 16:02:55 | dwihno | I only fit 4 tracks on the chip :) |
| 16:03:38 | Ericgoh | haha...wonder what happened to the phone when you find out battery ends becoz of playing music |
| 16:03:52 | dwihno | :-) |
| 16:03:56 | dwihno | I can live with that |
| 16:05:20 | Ericgoh | ??then what the purpose of getting a cell phone? |
| 16:05:40 | Bagder | Ericgoh: so your phone never runs out of batteries? |
| 16:06:16 | dwihno | Ericgoh: I charge my phone regularly |
| 16:07:15 | Ericgoh | my phone can stand for more than 1week |
| 16:07:32 | Ericgoh | even i talk frequently, it can still stands for 2-3days |
| 16:08:24 | Ericgoh | actually i bought a very stupid phone, |
| 16:08:43 | Ericgoh | but the battery life is very long |
| 16:09:24 | dwihno | Well, people should do as they see fit :) |
| 16:09:37 | dwihno | And not critisize everyone everytime they think differently |
| 16:09:42 | dwihno | Perhaps I should run for president |
| 16:09:45 | dwihno | ;) |
| 16:09:50 | * | Bagder votes for dwihno |
| 16:10:22 | dwihno | Yay! |
| 16:10:27 | Ericgoh | thats not critisize, i am just giving opinion |
| 16:10:30 | dwihno | Watch out Kerry - here I come! :) |
| 16:10:57 | Ericgoh | coz already got lots of customer complaining about the battery life while playing music on cell phone |
| 16:11:31 | Ericgoh | even though they already know how long they can play the music on their cell phone |
| 16:11:31 | dwihno | Keeping the phone charged and doubling it as a mp3 player works for me |
| 16:12:00 | Ericgoh | everyone thinks like that then we wont get any complain, haha... |
| 16:14:05 | dwihno | :-) |
| 16:22:28 | Bagder | time to go swimming! |
| 16:22:30 | | Part Bagder |
| 16:30:43 | | Part Zagor |
| 16:34:05 | | Join dstar5 [0] (Lee@ACC2BA2C.ipt.aol.com) |
| 16:43:15 | *** | Saving seen data "./dancer.seen" |
| 16:58:54 | | Quit Nibbler (Read error: 104 (Connection reset by peer)) |
| 17:00 |
| 17:20:42 | | Quit dstar5 (Read error: 104 (Connection reset by peer)) |
| 17:21:19 | | Join dstar5 [0] (Lee@ACC2E45A.ipt.aol.com) |
| 17:36:14 | | Join sethians [0] (~jirc@200.87.78.53) |
| 17:54:42 | | Quit Ericgoh () |
| 18:00 |
| 18:22:54 | | Quit sethians ("Leaving") |
| 18:34:43 | | Join Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de) |
| 18:43:16 | *** | Saving seen data "./dancer.seen" |
| 19:00 |
| 19:17:26 | | Join nevs [0] (nevs@ACBD5A76.ipt.aol.com) |
| 19:20:10 | nevs | hi |
| 19:26:29 | | Quit nevs () |
| 19:26:45 | | Quit dstar5 ("Leaving") |
| 19:44:25 | | Quit Nibbler (Read error: 104 (Connection reset by peer)) |
| 20:00 |
| 20:43:20 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:17:54 | | Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
| 21:17:55 | | Quit scott666 (Read error: 54 (Connection reset by peer)) |
| 21:18:00 | | Nick scott666_ is now known as scott666 (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
| 21:27:26 | | Join Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de) |
| 21:44:08 | | Join jakesir [0] (solaris@pool-70-16-28-73.balt.east.verizon.net) |
| 21:44:26 | | Quit jakesir (Client Quit) |
| 21:50:51 | | Join dstar5 [0] (Lee@ACC478EA.ipt.aol.com) |
| 21:55:16 | | Join [IDC]Dragon [0] (~d90a3255@reladm.kharkov.net) |
| 21:57:28 | amiconn | hi Jörg |
| 21:57:39 | [IDC]Dragon | Hello Jens |
| 21:58:41 | [IDC]Dragon | I'm looking for Jake, he only sticked his head in here and left |
| 22:00 |
| 22:00:04 | amiconn | Hmm. |
| 22:00:27 | amiconn | Didn't he have some problems with his box? |
| 22:00:50 | [IDC]Dragon | yes, he shipped it to me |
| 22:01:44 | amiconn | Interesting. Isn't this rather expensive (I assume he lives in the states) |
| 22:01:48 | amiconn | ? |
| 22:01:49 | dstar5 | what was the problem with his box? |
| 22:01:57 | [IDC]Dragon | he suspected a bad flash, but it turns out to be a bus problem or so |
| 22:02:26 | [IDC]Dragon | I've hooked it up to uart_boot, the flash reads OK |
| 22:03:25 | [IDC]Dragon | but when dumping ROM+flash from revived Rockbox, the files have a stuck 0 bit every 8 KB |
| 22:03:47 | amiconn | Hmm. Do you already have an idea what could cause this? |
| 22:04:03 | [IDC]Dragon | I ran out of them |
| 22:04:33 | amiconn | Exactly _one_ zero every 8 KB? |
| 22:04:40 | [IDC]Dragon | first I thought it's a RAM error, I made a test to uart_boot, but this went OK |
| 22:05:07 | [IDC]Dragon | yes, bit 1 on every 8 KB |
| 22:05:23 | amiconn | One bit only?? Really strange |
| 22:05:45 | [IDC]Dragon | the address has to end on FF8 |
| 22:06:00 | dstar5 | well... if you can't fix it... i have a good CPU board he could use it does not have a flashable chip though |
| 22:06:08 | [IDC]Dragon | so, on 0FF8, 2FF8, 4FF8, and so on |
| 22:06:32 | [IDC]Dragon | it's a V2 |
| 22:06:49 | [IDC]Dragon | but CPU boards are welcome! |
| 22:06:54 | dstar5 | ohh |
| 22:07:04 | [IDC]Dragon | does it have USB2? |
| 22:07:09 | dstar5 | yes |
| 22:07:11 | amiconn | [IDC]Dragon: Did you try a ram check from within rockbox? |
| 22:07:43 | [IDC]Dragon | dssar5: the box of my gf could need such an upgrade |
| 22:08:08 | [IDC]Dragon | amiconn: no, I didn't went through that effort |
| 22:08:53 | dstar5 | [IDC]Dragon: i could send it to you |
| 22:09:07 | [IDC]Dragon | dstar5: where are you? |
| 22:09:32 | amiconn | [IDC]Dragon: I suppose rockbox crashes every now and then with that error. Does it boot into rockbox from flash, or do you need to load rockbox via uart? |
| 22:09:45 | dstar5 | [IDC]Dragon: US (oregon), but he board is so small, it would not cost much at all to ship |
| 22:10:23 | [IDC]Dragon | amiconn: the box starts very unreliable recently, but from flash |
| 22:11:08 | [IDC]Dragon | dstar5: the wreck of Jake is from the US, too, I had to pick it up at customs |
| 22:11:37 | dstar5 | [IDC]Dragon: at customs? why is that? |
| 22:11:56 | amiconn | [IDC]Dragon: I wonder how this works... The bootloader has to uncompress the ucl image. Doesn't ucl incorporate a checksum? |
| 22:12:47 | [IDC]Dragon | dstar5: probably they suspected it could be valuable |
| 22:13:17 | [IDC]Dragon | amiconn: ucl has a checksum, but this is not verfied on decompression |
| 22:13:25 | dstar5 | ahh well that sorta is... heh |
| 22:13:26 | amiconn | Ah |
| 22:13:55 | [IDC]Dragon | everything with a checksum fails on that box: RoLo, firmware_flash.rock |
| 22:14:55 | amiconn | So the problem also exists for the ram... or for the ram _only_?? |
| 22:15:50 | [IDC]Dragon | I'm puzzled, because my RAM test went OK |
| 22:16:18 | [IDC]Dragon | then I suspected the RAM on the HD, changed the disk, but same result |
| 22:16:57 | amiconn | It could well be the ram - one bit cell may be flaky, unable to maintain it's state between refreshes |
| 22:17:42 | [IDC]Dragon | but I wrote a RAM test... |
| 22:18:04 | amiconn | Iirc the refresh cycle is programmable, perhaps the boot loader sets a different value than rockbox? |
| 22:18:13 | [IDC]Dragon | I filled the whole with 0x55, verified, filled with 0xAA, verified again |
| 22:19:02 | [IDC]Dragon | then I filles with 0x00 and wrote a marching 0xFF, verified that this stays, then reverse values |
| 22:19:15 | [IDC]Dragon | s/filles/filled |
| 22:19:30 | dstar5 | [IDC]Dragon: if you want the board, email me dstar5 at gmail _D0T_ com |
| 22:19:36 | [IDC]Dragon | (to catch address errors) |
| 22:19:37 | dstar5 | see you later :) |
| 22:19:48 | [IDC]Dragon | dstar5: thanks, yes |
| 22:19:58 | | Quit dstar5 ("Leaving") |
| 22:23:12 | [IDC]Dragon | afk |
| 22:32:33 | amiconn | [IDC]Dragon: (1) From which memory region the ram test executed? IRAM? (2) The bootloader starts with RAS up mode and burst mode disabled. Rockbox does enable both... |
| 22:36:41 | amiconn | (RAS down and burst) |
| 22:43:23 | *** | Saving seen data "./dancer.seen" |
| 22:47:29 | | Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) |
| 22:49:48 | | Join undefinedassasin [0] (~Aggressor@undefinedassasin.registered) |
| 22:49:51 | undefinedassasin | h3y |
| 22:49:53 | undefinedassasin | where is midk |
| 22:52:51 | [IDC]Dragon | back again |
| 22:53:30 | undefinedassasin | Wher3 is midk? |
| 22:53:34 | [IDC]Dragon | amiconn: the test is using minimon in IRAM, bootloader DRAM init |
| 22:54:06 | [IDC]Dragon | in an act of despair, I have just exchanged the DRAM of Jake's box |
| 22:54:15 | amiconn | [IDC]Dragon: You could try setting burst & RAS down mode in your RAM test, then try again... |
| 22:54:43 | [IDC]Dragon | I'll try the other RAM when I get back home |
| 22:54:58 | undefinedassasin | Please help me |
| 22:55:00 | undefinedassasin | midk is gone |
| 22:55:05 | undefinedassasin | and someone is asking me for him |
| 22:55:10 | undefinedassasin | but I can't help |
| 22:55:12 | amiconn | [IDC]Dragon: Still at work? |
| 22:55:29 | [IDC]Dragon | amiconn: only for the solder tools |
| 22:55:35 | [IDC]Dragon | leaving now |
| 22:55:46 | amiconn | Ahh |
| 22:56:06 | | Part undefinedassasin ("X-Chat [2.0.10c] Quit.") |
| 22:56:25 | [IDC]Dragon | ehatch the sky, we have the Perseides at max now |
| 22:56:32 | [IDC]Dragon | whatch |
| 22:57:00 | [IDC]Dragon | (meteor storm) |
| 22:57:39 | amiconn | watch even :) |
| 22:57:48 | * | [IDC]Dragon leaves for falling star gazing |
| 22:58:15 | [IDC]Dragon | yes, watch out for my reckless typing |
| 22:58:41 | | Quit [IDC]Dragon ("no fate but what we make") |
| 23:00 |
| 23:54:36 | | Join [IDC]Dragon [0] (~idc-drago@pD9E34A79.dip.t-dialin.net) |
| 23:55:40 | [IDC]Dragon | Just for the record: the behavior of Jake's box is the same with the new RAM chip. :-( |
| 23:56:38 | amiconn | Did you try your RAM test with burst & RAS down enabled? |
| 23:57:12 | [IDC]Dragon | why should I? there's a different RAM chip in in now. |
| 23:58:02 | [IDC]Dragon | in it |
icon identifies that the person is a core developer (has commit access).