| 00:03:03 | | Quit petur (Quit: Leaving) |
| 00:14:50 | | Quit Rower (Ping timeout: 245 seconds) |
| 00:15:28 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 00:19:55 | | Quit prof_wolfff (Ping timeout: 252 seconds) |
| 00:25:40 | | Quit edhelas (Ping timeout: 245 seconds) |
| 00:31:46 | | Join prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com) |
| 00:43:13 | | Join alexweis_ [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) |
| 00:44:02 | | Quit alexweissman (Read error: Connection reset by peer) |
| 00:44:36 | | Join Senji [0] (~Senji@85.187.103.250) |
| 00:45:09 | | Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) |
| 00:47:59 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:04:19 | | Quit pamaury (Ping timeout: 248 seconds) |
| 01:05:57 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 01:08:33 | * | chrisjj can survive without Bilgus' Selective Backlight covering the power source change event that by default wakes the backlight on ZEN. :-) |
| 01:10:13 | | Join furrywolf [0] (~randyg@72-57-219-183.pools.spcsdns.net) |
| 01:11:26 | __builtin | chrisjj: ... and you want to do what exactly? |
| 01:16:06 | pamaury | dys: I found the encryption |
| 01:16:14 | dys | cool |
| 01:16:20 | dys | i found out 2B370C initializes the stack pointer. It's not called anywhere |
| 01:16:32 | dys | maybe it's the entry point |
| 01:16:59 | pamaury | pamaury/7165141c37d3d8e2aa14d59aa197e4e8">https://gist.github.com/pamaury/7165141c37d3d8e2aa14d59aa197e4e8 |
| 01:17:41 | pamaury | there is an extra 4 bytes at the end of the image which I haven't investigated, probably a checksum |
| 01:17:50 | pamaury | in fact it's a simple byte substitution |
| 01:18:06 | pamaury | I don't know if it's random or if there a formula |
| 01:18:34 | pamaury | there seems to be *some* logic but it doesn't matter in the end |
| 01:19:04 | pamaury | I found the table in the flash dump, just before "Erasing" string |
| 01:19:25 | dys | pamaury: I compared the sum at the end of the images, and they only differ in the last two or three bytes, so a sum sounds right |
| 01:19:44 | pamaury | I'm going to bed now |
| 01:27:50 | | Quit pamaury (Ping timeout: 260 seconds) |
| 01:41:50 | | Quit Senji (Ping timeout: 260 seconds) |
| 01:45:43 | | Quit Rower (Ping timeout: 252 seconds) |
| 01:46:29 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 02:00 |
| 02:04:29 | | Quit ender` (Quit: A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. — Douglas Adams) |
| 02:20:06 | | Part robertd1 |
| 02:31:55 | | Quit Rower (Ping timeout: 252 seconds) |
| 02:32:08 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 02:48:00 | *** | Saving seen data "./dancer.seen" |
| 02:50:55 | | Quit ZincAlloy (Quit: Leaving.) |
| 02:53:09 | | Quit xorly (Ping timeout: 264 seconds) |
| 02:57:45 | dunx | ok, my ipod got bricked. and the port for the headphone jack had all the pins and tracks taken out. |
| 02:58:22 | dunx | regarding the sony players though, perhaps a port to the E390 series would be feasible? |
| 02:59:05 | dunx | the firmware seems similar to the e380. |
| 02:59:15 | dunx | i'd have to get hold of one and examine it though |
| 03:00 |
| 03:17:30 | | Quit Rower (Ping timeout: 260 seconds) |
| 03:18:20 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 03:51:25 | | Quit TorC (Quit: Leaving.) |
| 04:00 |
| 04:48:02 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:03:23 | | Join Strife1989 [0] (~quassel@adsl-98-80-182-178.mcn.bellsouth.net) |
| 05:04:46 | | Quit Strife89 (Ping timeout: 256 seconds) |
| 05:18:57 | | Quit Rower (Ping timeout: 264 seconds) |
| 05:20:04 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 06:00 |
| 06:04:10 | | Quit Rower (Ping timeout: 240 seconds) |
| 06:05:00 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 06:09:18 | | Quit [7] (Disconnected by services) |
| 06:09:27 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 06:21:37 | | Nick Strife1989 is now known as Strife89 (~quassel@adsl-98-80-182-178.mcn.bellsouth.net) |
| 06:24:52 | | Join mutnai [0] (6db90a3e@gateway/web/freenode/ip.109.185.10.62) |
| 06:27:37 | | Join TorC [0] (~TorC@fsf/member/TorC) |
| 06:27:46 | | Quit TorC (Client Quit) |
| 06:28:01 | | Join TorC [0] (~TorC@fsf/member/TorC) |
| 06:37:40 | | Quit Jinx (Ping timeout: 272 seconds) |
| 06:42:35 | | Quit alexweis_ (Remote host closed the connection) |
| 06:43:31 | | Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) |
| 06:48:04 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:05:34 | | Quit Rower (Ping timeout: 258 seconds) |
| 07:06:17 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 07:25:11 | | Quit furrywolf (Read error: Connection reset by peer) |
| 08:00 |
| 08:17:36 | | Quit [Saint] (Disconnected by services) |
| 08:17:46 | | Join [Saint] [0] (~sinner@rockbox/staff/saint) |
| 08:23:13 | | Quit jhMikeS (Ping timeout: 240 seconds) |
| 08:36:47 | | Quit alexweissman (Remote host closed the connection) |
| 08:48:07 | *** | Saving seen data "./dancer.seen" |
| 08:51:57 | | Quit Rower (Ping timeout: 264 seconds) |
| 08:52:16 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 09:00 |
| 09:31:38 | | Join Senji [0] (~Senji@85.187.103.250) |
| 09:37:52 | | Quit Rower (Ping timeout: 276 seconds) |
| 09:38:40 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 09:47:21 | | Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) |
| 09:52:09 | | Quit alexweissman (Ping timeout: 255 seconds) |
| 09:53:16 | dys | pamaury: The least differences between update image and flash dump is with HAP90-b80.104, so that's probably the version running |
| 10:00 |
| 10:02:32 | dys | HAP90-b77.103 is a close second, all others have significiantly more differences |
| 10:03:54 | dys | they're only two weeks apart, so that's also an indication that most likely 104 is running |
| 10:07:07 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 10:07:29 | | Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr) |
| 10:07:39 | | Quit Rower (Ping timeout: 240 seconds) |
| 10:07:53 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 10:29:59 | | Join skapazzo [0] (~skapazzo@151.9.205.1) |
| 10:37:07 | | Quit mutnai (Quit: Page closed) |
| 10:41:40 | lebellium | gevaerts: do you confirm there is no dualboot on Gigabeat F40? |
| 10:48:08 | *** | Saving seen data "./dancer.seen" |
| 10:54:21 | | Quit Rower (Ping timeout: 264 seconds) |
| 10:54:51 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 11:00 |
| 11:06:00 | | Join edhelas [0] (~edhelas@145.133.43.230) |
| 11:13:54 | | Quit edhelas (Ping timeout: 248 seconds) |
| 11:17:16 | | Join edhelas [0] (~edhelas@145.133.43.230) |
| 11:25:33 | | Quit edhelas (Ping timeout: 264 seconds) |
| 11:28:57 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 11:32:00 | pamaury | dunx: the E390 is completely different from all other players inside |
| 11:50:21 | | Quit Moarc (Ping timeout: 258 seconds) |
| 11:52:41 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 12:00 |
| 12:08:47 | | Join Piece_Maker [0] (~Acou_Bass@host-89-242-214-2.as13285.net) |
| 12:09:57 | | Quit Acou_Bass (Ping timeout: 264 seconds) |
| 12:09:57 | | Nick Piece_Maker is now known as Acou_Bass (~Acou_Bass@host-89-242-214-2.as13285.net) |
| 12:15:48 | lebellium | pamaury: |
| 12:15:52 | lebellium | got the service manual!!! |
| 12:15:56 | lebellium | I'm so happy :D |
| 12:17:01 | lebellium | Sony can't cheat me |
| 12:17:18 | lebellium | https://docs.sony.com/release/MDSM/989632202_SM.pdf |
| 12:17:57 | | Quit fs-bluebot (Ping timeout: 258 seconds) |
| 12:18:48 | | Quit bluebrother (Ping timeout: 255 seconds) |
| 12:19:51 | pamaury | lebellium: link not working |
| 12:20:25 | lebellium | hum |
| 12:20:26 | lebellium | works for me |
| 12:20:34 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 12:22:23 | pamaury | I get 500 - Internal server error. |
| 12:24:02 | lebellium | It's strange. With http://www.urlitor.com/ I usually get only 200 or 404 but today I got many 500 errors. When I click on a link being said 500, sometimes it works, sometimes not |
| 12:24:25 | lebellium | but this one is said 200, not 404 or 500 |
| 12:24:33 | lebellium | can someone else try this link please? |
| 12:25:09 | | Quit Rower (Ping timeout: 240 seconds) |
| 12:25:37 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 12:26:26 | | Quit Senji (Ping timeout: 248 seconds) |
| 12:31:48 | | Join fs-bluebot [0] (~fs-bluebo@xd9baf127.dyn.telefonica.de) |
| 12:32:04 | lebellium | why do I get the "registration page" when I click on "Log in" on the wiki? |
| 12:34:43 | chrisjj | pamaury, I'd be interested to know why you deleted my Battery Calibration addition at https://www.rockbox.org/wiki/WebHome . |
| 12:42:37 | | Join edhelas [0] (~edhelas@145.133.43.230) |
| 12:43:27 | lebellium | we're all fed up with your useless edits on the wiki |
| 12:43:32 | lebellium | just stop from editing it |
| 12:44:35 | | Quit edhelas (Client Quit) |
| 12:48:12 | *** | Saving seen data "./dancer.seen" |
| 12:51:07 | | Join Senji [0] (~Senji@85.187.103.250) |
| 12:53:56 | | Join Senji_ [0] (~Senji@85.187.103.250) |
| 12:56:18 | | Quit Senji (Ping timeout: 248 seconds) |
| 13:00 |
| 13:02:05 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:4d1c:1750:ec78:602b) |
| 13:04:15 | | Quit idonob (Ping timeout: 255 seconds) |
| 13:06:08 | | Join idonob [0] (~Owner@S010610c37b922980.vs.shawcable.net) |
| 13:15:32 | | Quit idonob (Ping timeout: 255 seconds) |
| 13:25:24 | | Join idonob [0] (~Owner@S010610c37b922980.vs.shawcable.net) |
| 13:27:04 | pamaury | chrisjj: because this was not useful information |
| 13:27:21 | pamaury | lebellium: it looks you are right, the A30 is about as easy to disassemble as the WM1 :-/ |
| 13:28:02 | lebellium | yes, that was my conclusion too |
| 13:28:42 | chrisjj | pamaury, Admittedly that procedure had some faults. Have you any objection to me posting my own corrected procedure there? |
| 13:29:27 | lebellium | It's |
| 13:29:43 | lebellium | it's not about right or wrong procedure. It's about useful or useless information |
| 13:29:57 | lebellium | we just want you to stop edit the wiki. What don't you understand? |
| 13:30:50 | chrisjj | Battery bench calibration info is highly useful to anyone try to gather the data for battery bench calibration, and I don't see the procedure posted anywhere else on wiki or forum. |
| 13:30:51 | pamaury | chrisjj: no, it's because, it's not useful info |
| 13:31:54 | pamaury | chrisjj: the "procedure" is pure logic: start with battery at 100%, start playing track, run battery bench, it's doesn't require some wiki explanation |
| 13:32:33 | | Nick Guest99782 is now known as olspookishmagus (~pookie@snf-137798.vm.okeanos.grnet.gr) |
| 13:34:48 | chrisjj | You missed out the requirement to start a very long playlist in repeat all mode put a reasonable volume with headphone. |
| 13:35:16 | chrisjj | Also the charge part of the procedure is not pure logic. Even with your instructions, I haven't got it to work even once. |
| 13:35:45 | chrisjj | However, no matter. As you wish, I won't post my corrected version. |
| 13:38:19 | chrisjj | lebellium, do you have a complaint about my Installation instructions for the RBUtil-less ZEN port here https://www.rockbox.org/wiki/bin/viewauth/Main/CreativeZEN ? |
| 13:38:25 | pamaury | the test is supposed to reflect realistic condition: you don't listen to an hour album for 22h in a loop, you change, so you need to make sure that news songs are loading from disks regularly => very long playlist. As for the volume, don't you listen with headphone at the reasonable volume ? |
| 13:43:34 | chrisjj | Yup, I know the reasons and the requirements well. I did just think they might be more useful in the wiki than hidden in an IRC log. |
| 13:44:50 | lebellium | chrisjj: I didn't read all your edits but several of them and most of time it's useless. There may be sometimes an useful edit among them. So what should we do now? |
| 13:45:05 | chrisjj | Anyone find this Running Time error on other devices? https://www.rockbox.org/tracker/task/13101 |
| 13:46:12 | pamaury | well good thing rockbox is not running on any atomic clock or that would be a problem |
| 13:51:08 | | Join shdwprince [0] (~textual@130.180.220.58) |
| 13:55:55 | | Quit shdwprince (Ping timeout: 276 seconds) |
| 13:56:37 | | Join shdwprince [0] (~textual@130.180.216.4) |
| 13:56:42 | | Part shdwprince |
| 14:00 |
| 14:06:45 | chrisjj | Good thing no-one's using it to find which soak-test track causes a crash. |
| 14:07:07 | chrisjj | No-one who knows it is wrong, that is :-) |
| 14:08:02 | pamaury | patches are welcome as usual |
| 14:08:15 | pamaury | honestly it's such a minor issue that I couldn't care less |
| 14:09:12 | pamaury | and the explanation is most probably super simple anyway |
| 14:11:11 | dys | pamaury: I rendered some call graphs |
| 14:11:11 | dys | CALLed addresses don't match up with LINK instructions as the jump distance gets larger in the update images, but they mostly do in the flash dump. |
| 14:11:29 | dys | I guess there are multiple smaller blocks with their own checksum in the update images |
| 14:12:33 | dys | also, there's about 200kB code missing in the flash dump. I guess it's the 0x200000-0x260000 that's zeroed out in the flash |
| 14:13:21 | dys | Maybe one of the other devices on the bus issued a write instruction during my SPI bus takeover |
| 14:30:37 | dys | pamaury: here's the script: http://paste.debian.net/911268/ |
| 14:30:38 | dys | it emits graphviz syntax. I used the "dot" tool to render a svg and view that with inkscape |
| 14:31:05 | dys | call trees for the threadX kernel and multiple for the application are visible |
| 14:36:45 | dys | another thing I noted: there are absolute calls to the 0x75c0xxxx region. I guess it copies some code to the bin SRAM for a speedup. |
| 14:37:04 | gevaerts | lebellium: I think so |
| 14:37:09 | dys | s/bni/bfin/ |
| 14:37:46 | gevaerts | It's been a *long* time since I've had the "standard" bootloader installed, and I've had those replacement pseudo-OF files for even longer |
| 14:41:09 | | Quit Rower (Ping timeout: 264 seconds) |
| 14:42:17 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 14:43:00 | | Join edhelas [0] (~edhelas@145.133.43.230) |
| 14:45:59 | | Quit edhelas (Client Quit) |
| 14:48:15 | *** | Saving seen data "./dancer.seen" |
| 14:55:09 | | Join JanC_ [0] (~janc@lugwv/member/JanC) |
| 14:56:24 | | Nick JanC is now known as Guest95357 (~janc@lugwv/member/JanC) |
| 14:56:24 | | Quit Guest95357 (Killed (karatkievich.freenode.net (Nickname regained by services))) |
| 14:56:24 | | Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) |
| 15:00 |
| 15:05:37 | | Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) |
| 15:06:59 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 15:25:34 | | Quit idonob (Ping timeout: 240 seconds) |
| 15:42:34 | | Quit Rower (Ping timeout: 240 seconds) |
| 15:42:56 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 15:43:47 | dys | pamaury: I found one of these blocks. going to patch your descrambler :-) |
| 15:47:29 | dys | nowait, it's also in the flash dump, only a little later |
| 15:47:54 | dys | it might be a boot block header. but then this also means 104 is not the version that's in the flash |
| 15:48:12 | * | dys curses |
| 15:49:33 | | Join wodz [0] (~wodz@89-74-169-198.dynamic.chello.pl) |
| 15:51:43 | wodz | pamaury: ping |
| 15:52:16 | pamaury | wodz: pong |
| 15:52:33 | wodz | pamaury: Did you try aplay on your nwz? |
| 15:52:47 | pamaury | wodz: not yet |
| 15:53:56 | wodz | pamaury: mixer_test binary expects some param but does not have help so I'd need to disasm to understand what it expects :/ |
| 16:00 |
| 16:00:36 | | Join idonob [0] (~Owner@S010610c37b922980.vs.shawcable.net) |
| 16:01:18 | | Join edhelas [0] (~edhelas@145.133.43.230) |
| 16:01:32 | | Quit edhelas (Client Quit) |
| 16:05:38 | dys | ja, these 16-byte chunks of bogus instructions are probably boot code headers |
| 16:12:31 | pamaury | wodz: I found the RKNanoD programming manual \o/ |
| 16:12:49 | wodz | pamaury: wow |
| 16:13:19 | pamaury | dys: I haven't had a look at the descrambled firmware. So you think there is some structure in it basically ? |
| 16:14:11 | dys | pamaury: I'm not sure anymore. If there are lots of boot block headers around, it could also explain why calls and subroutines don't match up when distances are large. |
| 16:16:11 | pamaury | wodz: it doesn't really document the boot part though |
| 16:19:01 | pamaury | wodz: have you tried aplay ? |
| 16:19:38 | wodz | pamaury: only scontent command of aplay |
| 16:19:50 | pamaury | what does that do ? |
| 16:21:09 | wodz | pamaury: ah, no I confused aplay with amixer. |
| 16:26:41 | pamaury | dys: so you think the descramble file is a boot stream following the blackfin manual ? or something completely different ? |
| 16:27:13 | pamaury | and what about flash dump ? |
| 16:27:50 | dys | pamaury: The flash dump also contains these 16-byte blocks of invalid instructions |
| 16:28:19 | dys | I'm currently writing up an interpreter for the bcode so i can emit what the code actually looks like in memory |
| 16:28:34 | pamaury | can you point me to one of them so I can have a look ? |
| 16:29:00 | prof_wolfff | wodz: did you see my comments about a patch to test USB on nano2g |
| 16:29:22 | wodz | prof_wolfff: Yes. How do I test this exactly? |
| 16:29:44 | dys | pamaury: the very start of the firmware images, or searching for illegal instructions in the objdump disassembly should yield some |
| 16:30:42 | | Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) |
| 16:31:12 | pamaury | ok I'll have a look |
| 16:31:23 | pamaury | dys: did you investigate what the checksum at the end of image can be ? |
| 16:31:48 | wodz | pamaury: Codec on sony seems to be more than dumb codec. It looks more like dsp + codec. cs47l01 doesn't yield any datasheet BUT cs4700 is a family of dsps |
| 16:32:02 | prof_wolfff | wodz: if you use the patch then read/write in flash is disabled for sectors at offset >= 2GB, writing/reading to this zone using dd will reveal if the flash driver is involved or the error is produced by the USB driver |
| 16:32:21 | dys | pamaury: I tried lots of summing with various sizes and endianesses and varying bytes cut of from start and end of the data to no avail. that's why I suspected that there might be multiple summed blocks |
| 16:33:26 | prof_wolfff | wodz: .rockbox folder should reside in the first 2GB of flash because any files on the second 2GB are never accessed |
| 16:33:36 | wodz | prof_wolfff: I don't get it. Should I dd to offset above 2GB? |
| 16:33:38 | pamaury | wodz: yeah the codec is very complicated, the driver upload some binary blobs to it for dsp |
| 16:33:59 | prof_wolfff | yes, i will try to find the command i was using on my nano2g, just one moment... |
| 16:35:08 | prof_wolfff | wodz: if writing abobe 2GB reproduces the error the the problem is on USB driver code, if not then the problem is in the nand driver or the flash HW |
| 16:35:56 | wodz | prof_wolfff: clever |
| 16:37:22 | pamaury | dys: those invalid blocks don't really look like bfin boot stream though |
| 16:37:54 | pamaury | unless |
| 16:37:56 | pamaury | hum |
| 16:38:05 | dys | hmm. my interpreter seems to yield target addresses that the code uses for absolute jumps |
| 16:38:10 | dys | so I'm confident |
| 16:38:36 | pamaury | dys: what is your interpret doing ? |
| 16:38:57 | pamaury | I suspect that if you remove the first 0x18 bytes of the file, it's a valid boot stream |
| 16:39:23 | dys | decoding the 16-byte headers documented in the reference manual… it's work in progress |
| 16:39:45 | Bilgus | chrisjj? what about selective backlight? |
| 16:40:06 | pamaury | if you are going to do that, I found the best strategy is to produce an ELF file out of it |
| 16:40:13 | pamaury | that what I did for several formats |
| 16:40:37 | pamaury | the first 0x18 bytes of the decrypted file are not a valid boot block though |
| 16:42:43 | prof_wolfff | wodz: for writing i was using something similar to next command, if the numbers are ok then this command writes 1GB (16384*65536) of zeroed data in /dev/sdX starting at offset 2GB (32768*65536): dd if=/dev/zero of=/dev/sdX bs=65536 count=16384 seek=32768 conv=fdatasync |
| 16:43:56 | wodz | prof_wolfff: I'll try to test it soon, no promise I'll find time today though |
| 16:44:23 | prof_wolfff | ok, for reading try this one: dd if=/dev/sdX bs=65536 count=16384 skip=32768 |
| 16:44:49 | pamaury | dys: can you upload your decoder when it's working ? |
| 16:45:02 | dys | of course :-) |
| 16:45:08 | prof_wolfff | sorry, dd if=/dev/sdX of=/dev/null bs=65536 count=16384 skip=32768 |
| 16:48:17 | *** | Saving seen data "./dancer.seen" |
| 16:52:11 | pamaury | wodz: aplay doesn't seem to work |
| 16:57:07 | | Quit wodz (Ping timeout: 240 seconds) |
| 17:00 |
| 17:16:31 | pamaury | even with aplay I get distorted audio |
| 17:17:01 | pamaury | and there is this strange 'CODEC Mute' control element that randomly switches between on and off but that amixer can set or get, strange |
| 17:20:15 | * | pamaury thinks he'll have to RE the OF |
| 17:33:32 | | Join edhelas [0] (~edhelas@145.133.43.230) |
| 17:47:55 | | Quit edhelas (Read error: Connection reset by peer) |
| 17:50:23 | pamaury | ah great Sony, your CODEC driver is s*** |
| 17:53:01 | pamaury | oh my, Sony's audio code is horribly complicated :( |
| 18:00 |
| 18:00:57 | | Join furrywolf [0] (~randyg@70-1-114-74.pools.spcsdns.net) |
| 18:07:19 | | Quit prof_wolfff (Quit: Bye) |
| 18:07:44 | | Join prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com) |
| 18:15:33 | | Quit mutnai (Quit: Page closed) |
| 18:22:21 | | Join Jinx [0] (Dojo@unaffiliated/jinx) |
| 18:27:06 | | Join wodz [0] (~wodz@89-74-169-198.dynamic.chello.pl) |
| 18:28:10 | | Quit Rower (Ping timeout: 245 seconds) |
| 18:28:21 | pamaury | hum, so clear some codec parameters are important and set by OF |
| 18:28:32 | pamaury | and it seems to solve the random "not playing audio" problem |
| 18:28:36 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 18:28:38 | pamaury | but not the audio distortion |
| 18:32:40 | * | pamaury doesn't know what is wrong |
| 18:40:21 | | Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) |
| 18:42:09 | pamaury | it's really puzzling, mtpapp plays audio afaict and it's not distorted |
| 18:43:44 | Bilgus | anyone with FlySpray Delete Privileges Delete these stupid ass posts from me? https://www.rockbox.org/tracker/task/10363 |
| 18:44:04 | gevaerts | I *think* I can do that |
| 18:44:29 | gevaerts | There |
| 18:44:52 | Bilgus | Thank you don't know Wtf I was thinking |
| 18:48:20 | *** | Saving seen data "./dancer.seen" |
| 18:50:04 | __builtin | Bilgus: have you been able to reproduce the bug yet? |
| 18:50:11 | Bilgus | several |
| 18:50:43 | __builtin | interesting, I'll take a look |
| 18:52:34 | Bilgus | the save file he supplied indeed shows the bug after 2 moves just move whites bishop queens side up one and back and it will appear |
| 18:52:49 | __builtin | which one, exactly? |
| 18:53:17 | __builtin | ah, never mind |
| 18:54:21 | | Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) |
| 18:55:36 | __builtin | hmm, that save segfaults the simulator |
| 18:56:08 | __builtin | looks like it crashes on rockbox/apps/plugins/chessbox/gnuchess.c:2021 |
| 18:57:25 | Bilgus | the the other is loading the .pgn I've narrowed it down to pgn_parse_game()−−>,rb->strcpy(temp_ply->pgn_text, token_buffer);and pgn_to_coords(temp_ply); |
| 18:57:58 | Bilgus | The buffer is undersized and the strcpy is un constrained but thats not it |
| 18:59:25 | Bilgus | I've been testing a physical fuze+ although the pgn bug fails on Data Abort on that and works fine in the sim lol |
| 19:00 |
| 19:00:13 | __builtin | wait, are you talking about the chessbox.save file he provided? |
| 19:01:25 | Bilgus | No this is the one I discovered trying to reproduce the one referenced in the report |
| 19:01:38 | | Quit mutnai (Ping timeout: 260 seconds) |
| 19:03:07 | * | __builtin is confused |
| 19:03:20 | __builtin | what, exactly, is the bug? |
| 19:04:49 | Bilgus | first bug (referenced in bug report) board flips Computer stops making moves then crashes, second bug ( one I found trying to reproduce 1st) loading .Pgn crashes on data abort |
| 19:05:54 | Bilgus | the savefile he supplied reproduces 1st |
| 19:10:43 | Bilgus | I put the bad pgn file in there too I'll have time to do some more tonight |
| 19:19:12 | | Quit wodz (Ping timeout: 258 seconds) |
| 19:19:18 | __builtin | this is probably not the issue, but there's a key combo that allows the AI to move for you, and you to play the AI's side |
| 19:19:59 | dys | pamaury: I do see block chains with the interpreter now |
| 19:20:07 | dys | HAP90-b80.104: http://paste.debian.net/911335/ |
| 19:20:13 | dys | flashrom dump: http://paste.debian.net/911334/ |
| 19:20:18 | dys | code: http://paste.debian.net/911336/ |
| 19:20:45 | dys | pamaury: note how the chain in the firmware image breaks after 8kB |
| 19:20:52 | Bilgus | __builtin, AFAICT it isn't |
| 19:21:08 | dys | I suspect some periodic checksum in the firmware image that breaks the block chain |
| 19:21:16 | dys | (pamaury) |
| 19:23:20 | dys | and by 8kB I mean 32kB |
| 19:27:08 | pamaury | dys: the flash rom dump doesn't look like it has the boot code headers |
| 19:27:36 | dys | pamaury: IMHO it does. i pasted the chain of them above |
| 19:28:10 | dys | pamaury: note that the beginning of the flash dump 0x200000..0x260000 is zeroed out for unknown reasons |
| 19:28:24 | dys | this data is present in the update images however |
| 19:28:45 | dys | so i started in the middle of the block chain there |
| 19:29:03 | pamaury | ok maybe but then it doesn't start at 0x60000, there is an initial gap |
| 19:29:50 | dys | I ran it on the dump cropped to the inner section, maybe that explains the confusion? |
| 19:29:54 | dys | (sorry for not mentioning) |
| 19:30:34 | pamaury | dys: if by cropped you mean "remove the first 0x60000 bytes", then it doesn't start with a valid boot header |
| 19:31:04 | pamaury | the first 16 bytes are 00 0C 02 14 13 20 00 E3 A8 06 40 43 00 0C 08 1C |
| 19:31:27 | dys | I removed the first 0x260000 bytes for woring with the assembly, because is mostly boring stuff there |
| 19:32:06 | pamaury | and similarly, the descrambled upgrade file doesn't start with a valid header |
| 19:32:36 | pamaury | it only starts at offset 24, which is a bit odd |
| 19:32:41 | dys | the first block is taken at an offset: struct boot_header *header = (struct boot_header *) ((buf+24)); |
| 19:33:04 | dys | possible, if my theory with the PSoC sending a boot redirect is correct |
| 19:33:20 | dys | it might tell the boot kernel to fetch a boot block from anywhere, if I read the docs correctly |
| 19:33:45 | pamaury | yeah but that means those 24 bytes are possibly very important |
| 19:35:35 | dys | also, the flags look a bit strange. maybe they are, maybe I got the code with the bit struct members wrong |
| 19:37:08 | pamaury | I don't trust bitfield in C, the ordering depends on the compiler |
| 19:37:15 | dys | another thing: the XOR of the entire header should be 0 according to the manual |
| 19:37:23 | dys | maybe it lies about the XOR sum |
| 19:37:26 | dys | maybe the byte substitution table has a bug? |
| 19:37:55 | pamaury | that doesn't seem very likely since I extract it from the rom dump |
| 19:37:56 | dys | pamaury: ja, i should redo that without bitfields |
| 19:38:08 | dys | pamaury: ah, ok, thanks for confirming |
| 19:39:32 | pamaury | for the XOR checksum, you can look at ADI source code, there is the checksum code |
| 19:42:28 | dys | afk, need to fetch something to eat |
| 19:42:55 | pamaury | dys: the code source says "Since the XOR value exists inside of the block header, the XOR checksum of the actual block should always come out to be 0x00." |
| 19:43:24 | dys | it always comes up as 138 |
| 19:43:53 | pamaury | then there is something wrong |
| 19:44:13 | | Quit saratoga (Ping timeout: 260 seconds) |
| 19:46:14 | | Join girafe [0] (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr) |
| 19:46:42 | pamaury | but yeah if it's always 0 or 0x8a, it must indicate something wrong |
| 19:47:58 | pamaury | I will double check the table |
| 19:48:21 | pamaury | could be a stupid copy-paste error |
| 19:51:18 | pamaury | dys: don't laugh, the table has an obvious typo |
| 19:51:27 | pamaury | the array should 256 bytes and the lat entry 0xff |
| 19:51:31 | pamaury | currently it misses the last entry |
| 19:54:23 | pamaury | that seems to fix the problem, for almost all entries ;) |
| 19:54:36 | pamaury | sorry for the screw up :-/ |
| 19:55:15 | pamaury | I updated pamaury/7165141c37d3d8e2aa14d59aa197e4e8">https://gist.github.com/pamaury/7165141c37d3d8e2aa14d59aa197e4e8 |
| 19:59:21 | dys | no worries, I guess I would have already given up by now without your support :-) |
| 20:00 |
| 20:04:15 | pamaury | I think the next step is to extend your code to produce one or more elf files out of it |
| 20:04:53 | dys | i thought about making it emit sparse files, that would be less work |
| 20:05:02 | dys | but I concur emitting ELF would be the right thing to do |
| 20:05:55 | pamaury | I have a lib to create elf files, it's very easy |
| 20:06:34 | pamaury | several actually, but this one should do: |
| 20:06:51 | pamaury | https://git.rockbox.org/?p=rockbox.git;a=blob;f=utils/imxtools/sbtools/elf.c;h=68f66107a3d758e8dd2c855336409ee892ed2e16;hb=d4303ac |
| 20:07:00 | pamaury | https://git.rockbox.org/?p=rockbox.git;a=blob;f=utils/imxtools/sbtools/elf.h;h=bc2971c4f153b4468f97deb248b49da2aae3df0c;hb=d4303ac |
| 20:07:46 | pamaury | example use: https://git.rockbox.org/?p=rockbox.git;a=blob;f=utils/imxtools/sbtools/sbtoelf.c;h=11a46968dd05fe0edc7aab1be0f340a9d48ab8a2;hb=d4303ac |
| 20:09:14 | dys | thanks. I'm afraid I can look into it thursday at the earliest, probably next weekend |
| 20:09:49 | pamaury | ok, I might a quick go at it |
| 20:16:52 | | Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) |
| 20:28:29 | lebellium | pamaury: you don't have problems with Firefox to edit the wiki? Since today I no longer have the login popup, when I click on the log in button it immediately redirects me to the UserRegistration page :S |
| 20:28:41 | | Quit Rower (Ping timeout: 240 seconds) |
| 20:28:49 | pamaury | lebellium: it's working here, which version do you have ? |
| 20:29:00 | pamaury | I have 51 |
| 20:29:02 | lebellium | 51.0.1 |
| 20:29:20 | lebellium | I cleaned my cache and the specific cookies for Rockbox |
| 20:29:22 | lebellium | I don't understand |
| 20:29:54 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 20:29:58 | lebellium | with IE I have the login popup |
| 20:30:10 | pamaury | mayb you have the next multiprocess thing and it's causing that ? you need to go to firefox channel I think |
| 20:34:16 | lebellium | Hum indeed it probably comes from Firefox. I had v50 yesterday |
| 20:34:26 | lebellium | and v51 got installed today |
| 20:40:51 | | Quit lebellium (Remote host closed the connection) |
| 20:44:38 | | Quit mutnai (Quit: Page closed) |
| 20:45:18 | | Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr) |
| 20:46:03 | lebellium | pamaury: I restarted Firefox in safe mode (all plugins off) and it worked |
| 20:46:24 | lebellium | so it probably comes from one of my plugins not properly compatible with Firefox 51... |
| 20:47:16 | pamaury | lebellium: either a plugin or e10s (the multiprocess). I suggest you google e10s to see if it's enabled, or try to disable plugins one by one |
| 20:47:51 | lebellium | ok |
| 20:47:52 | lebellium | thanks |
| 20:47:58 | pamaury | dys: do you know any other devices that use blackfin ? |
| 20:48:22 | *** | Saving seen data "./dancer.seen" |
| 20:49:07 | | Quit xorly (Ping timeout: 259 seconds) |
| 20:49:08 | dys | I don't know of any DAPs other than teak/onkyo, but I didn't look very hard |
| 20:49:37 | pamaury | I'm just wondering if this encryption is specific to teak/onkyo or is a standard thing on blackfin |
| 20:51:31 | dys | I really think they homebrew it. I don't think AD would promote something that primitive. |
| 20:53:42 | | Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) |
| 21:00 |
| 21:16:33 | | Quit JdGordon_ (Ping timeout: 255 seconds) |
| 21:30:18 | | Quit Rower (Ping timeout: 258 seconds) |
| 21:30:44 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 21:39:41 | | Quit Moarc (Ping timeout: 240 seconds) |
| 21:40:36 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 21:48:53 | | Join wodz [0] (~wodz@89-74-169-198.dynamic.chello.pl) |
| 22:00 |
| 22:01:37 | | Quit michaelni (Read error: Connection reset by peer) |
| 22:04:43 | dys | pamaury: with the missing byte in table, my call analysis script now resolves 2491 calls instead of ~742 |
| 22:04:48 | dys | http://ansel.ydns.eu/~andreas/HAP90-b80.104.svg.xz |
| 22:07:23 | dys | there are 6365 total calls. Probably simply stripping the boot headers out of the image will improve things wrt. analysis without going the full way to use the proper load addresses. |
| 22:07:36 | pamaury | I'm writing a tool to create elf files |
| 22:09:09 | | Quit wodz (Ping timeout: 240 seconds) |
| 22:10:34 | dys | Can't wait to return from my busy week :-) |
| 22:18:06 | | Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) |
| 22:22:58 | | Quit paulk-collins (Quit: Leaving) |
| 22:28:34 | | Join shdwprince [0] (~textual@130.180.219.140) |
| 22:28:46 | | Part shdwprince |
| 22:45:39 | | Quit Rower (Ping timeout: 240 seconds) |
| 22:45:52 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 22:48:26 | *** | Saving seen data "./dancer.seen" |
| 22:52:05 | | Join Link8 [0] (~me@145.132.155.235) |
| 22:59:44 | | Quit Link8 (Remote host closed the connection) |
| 23:00 |
| 23:19:38 | amazoniantoad | Bilgus, IT WORKS! |
| 23:19:42 | amazoniantoad | it worked it worked! |
| 23:19:44 | amazoniantoad | omfffgggg |
| 23:58:04 | [Saint] | chrisjj: regarding your .wps question, you could probably use the logical comparator tags for that. |
| 23:58:04 | [Saint] | But...I know you'll just ignore this anyway, like everything else I say to you, so I'm not too sure why I'm bothering. |
| 23:58:04 | [Saint] | %?if(%pp,=,%pp)< %pp|%pp> |
icon identifies that the person is a core developer (has commit access).