--- Log for 20.10.117 Server: orwell.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 19 days and 16 hours ago 00.01.36 Join walle303 [0] (walle303ke@pisg/dev/walle303) 00.07.07 Quit petur (Remote host closed the connection) 00.07.29 Quit ender` (Quit: My door mechanisms will be designed so that blasting the control panel on the outside seals the door and blasting the control panel on the inside opens the door, not vice versa. — Evil Overlord List #96) 00.17.08 Quit Moarc (Ping timeout: 255 seconds) 00.18.17 Join Moarc [0] (~chujko@a105.net128.okay.pl) 00.21.47 Quit ender| (Ping timeout: 252 seconds) 00.24.33 Quit michaelni (Ping timeout: 240 seconds) 00.27.03 Join ender| [0] (krneki@2a01:260:4094:1:42:42:42:42) 00.31.46 Quit Moarc (Ping timeout: 240 seconds) 00.33.16 Join Moarc [0] (~chujko@a105.net128.okay.pl) 00.34.26 Join EmanueleSorce[m] [0] (emanueleso@gateway/shell/matrix.org/x-bkuwtyvdedposbdd) 00.34.26 Join nialv7 [0] (m7nialmatr@gateway/shell/matrix.org/x-dxxuakdmwtndqppn) 00.37.25 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) 00.41.02 Quit ender| (Ping timeout: 252 seconds) 00.44.55 Quit sanchaez (Ping timeout: 240 seconds) 00.46.30 Join ender| [0] (krneki@2a01:260:4094:1:42:42:42:42) 00.49.18 Quit almog1006 (Quit: Page closed) 01.19.22 Quit Ruhan (Quit: Connection closed for inactivity) 01.39.29 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) 01.52.09 *** Saving seen data "./dancer.seen" 02.00.31 Quit Acou_Bass (Ping timeout: 248 seconds) 02.10.28 Quit JanC (Remote host closed the connection) 02.12.33 Join Acou_Bass [0] (~Acou_Bass@gateway/vpn/privateinternetaccess/acoubass/x-14649893) 02.21.39 Join JanC [0] (~janc@lugwv/member/JanC) 02.51.53 Join bray90820 [0] (~bray90820@50-83-217-236.client.mchsi.com) 02.55.57 Quit Acou_Bass (Ping timeout: 248 seconds) 03.01.47 Join Acou_Bass [0] (~Acou_Bass@gateway/vpn/privateinternetaccess/acoubass/x-14649893) 03.07.52 Quit Huntereb_ (Quit: See ya!) 03.08.44 Join Huntereb [0] (~Huntereb@d-209-42-136-23.cpe.metrocast.net) 03.23.25 Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-zngzdsvetgktexgf) 03.38.07 Quit Acou_Bass (Ping timeout: 248 seconds) 03.52.11 *** Saving seen data "./dancer.seen" 03.54.05 Join Acou_Bass [0] (~Acou_Bass@gateway/vpn/privateinternetaccess/acoubass/x-14649893) 05.21.31 Join smbgaiden [0] (~smbgaiden@cpe-70-95-76-131.san.res.rr.com) 05.52.15 *** No seen item changed, no save performed. 06.05.05 Quit TheSeven (Ping timeout: 258 seconds) 06.05.32 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 06.10.06 Quit TheSeven (Ping timeout: 246 seconds) 06.12.19 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 06.18.13 Quit TheSeven (Ping timeout: 246 seconds) 06.18.31 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 07.02.54 Quit Ruhan (Quit: Connection closed for inactivity) 07.52.18 *** Saving seen data "./dancer.seen" 08.18.11 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 08.20.36 Join ender` [0] (krneki@foo.eternallybored.org) 08.30.24 Quit smbgaiden (Ping timeout: 248 seconds) 09.05.53 Join JanC_ [0] (~janc@lugwv/member/JanC) 09.07.10 Quit JanC (Killed (barjavel.freenode.net (Nickname regained by services))) 09.07.10 Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) 09.18.07 Join almog1006 [0] (4d8bf186@gateway/web/freenode/ip.77.139.241.134) 09.52.20 *** Saving seen data "./dancer.seen" 09.57.04 Quit Acou_Bass (Ping timeout: 240 seconds) 10.03.13 Join Acou_Bass [0] (~Acou_Bass@host-78-144-148-231.as13285.net) 10.04.55 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 10.11.46 # pamaury: I made progress with UPGRADE.DRV. Well not directly. I mapped ~90% of all syscalls with ~95% of certainty. This used in UPGRADE.DRV make sense on first glance. 10.21.10 # wodz: cool, thanks. Can you tell what it is doing now or it's stll unclear? 10.21.39 # pamaury: I spend all time yesterday on mapping syscalls 10.22.25 # pamaury: and there are well over hundred 10.23.33 # oh wow, ok. How do they work, can any drv register syscalls? 10.26.07 Join dys [0] (~dys@2003:5b:203b:100:6af7:28ff:fe06:801) 10.26.37 # * pamaury disappears but will be back 10.30.40 Quit pamaury (Ping timeout: 240 seconds) 10.33.29 Join Piece_Maker [0] (~Acou_Bass@host-78-144-145-50.as13285.net) 10.35.42 Quit Acou_Bass (Ping timeout: 248 seconds) 10.35.43 Nick Piece_Maker is now known as Acou_Bass (~Acou_Bass@host-78-144-145-50.as13285.net) 10.39.10 Join parchd [0] (~parchd@unaffiliated/parchd) 11.21.56 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 11.22.54 # pamaury: back? 11.23.53 # yes 11.27.37 # Ok. So SYSCFG.BIN is loaded at 0x80000000 (phys address 0). At 0x80000300 there is syscall dispatcher which takes syscall num in v0 as argument (this is NOT ABI compatible). 11.27.59 # hence In order to perform syscall you need to write wrapper in assembly. 11.28.35 # ok, that makes more sense now 11.29.32 # Then, there is mechanism of dynamically registering new syscalls and drivers can register new syscalls 11.30.33 # there are fixed offsets in syscall numbering as 0x10000 is for system, 0x20000 for something else and so on 11.32.58 Quit _meg (Ping timeout: 255 seconds) 11.36.02 Join _meg [0] (~notsure@211.25.203.45) 11.37.49 Quit Acou_Bass (Ping timeout: 258 seconds) 11.38.16 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) 11.38.39 Join Acou_Bass [0] (~Acou_Bass@host-78-144-156-102.as13285.net) 11.41.59 Quit parchd (Quit: Lost terminal) 11.45.04 Quit _meg (Ping timeout: 240 seconds) 11.45.10 Join Piece_Maker [0] (~Acou_Bass@host-78-144-153-179.as13285.net) 11.46.47 Quit Acou_Bass (Ping timeout: 240 seconds) 11.46.48 Nick Piece_Maker is now known as Acou_Bass (~Acou_Bass@host-78-144-153-179.as13285.net) 11.49.14 Join _meg [0] (~notsure@211.25.203.45) 11.52.24 *** Saving seen data "./dancer.seen" 11.58.53 Join Piece_Maker [0] (~Acou_Bass@host-89-241-246-92.as13285.net) 12.01.36 Quit Acou_Bass (Ping timeout: 248 seconds) 12.01.37 Nick Piece_Maker is now known as Acou_Bass (~Acou_Bass@host-89-241-246-92.as13285.net) 12.24.24 Quit almog1006 (Ping timeout: 260 seconds) 12.26.46 Join robertd1 [0] (~root@201.242.176.168) 12.31.33 Quit robertd1 (Ping timeout: 264 seconds) 12.36.34 Quit _meg (Ping timeout: 240 seconds) 12.37.36 Join _meg [0] (~notsure@211.25.203.45) 12.52.23 Join robertd1 [0] (~root@201.242.176.168) 13.20.58 Quit saratoga (Ping timeout: 260 seconds) 13.52.26 *** Saving seen data "./dancer.seen" 13.56.32 Join petur [0] (~petur@rockbox/developer/petur) 14.42.47 Join dan- [0] (~d@101.165.131.18) 14.42.47 Quit dan- (Changing host) 14.42.47 Join dan- [0] (~d@freenode/corporate-sponsor/privateinternetaccess.com/doaks) 14.45.58 Quit __jae__ (Read error: Connection reset by peer) 15.10.10 Quit Aldem (Read error: Connection reset by peer) 15.12.27 Quit wodz (Ping timeout: 240 seconds) 15.17.10 Join Aldem [0] (~Aldem@unaffiliated/aldem) 15.19.55 Quit petur (Read error: Connection reset by peer) 15.34.05 Join almog1006 [0] (4d8bf186@gateway/web/freenode/ip.77.139.241.134) 15.43.45 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 15.52.27 *** Saving seen data "./dancer.seen" 15.55.16 Join johnb3 [0] (~johnb2@p5B3AFD32.dip0.t-ipconnect.de) 15.58.13 # pamaury: I don't know whether you have seen this https://www.rockbox.org/irc/log-20171019#03:01:11 . WMA files also cause a bus error. The report was on E350 and I can reproduce it on the E450. 16.02.33 # yeah I've seen that, but since I can't solve the flac problem, I con 16.02.40 # don't know how to solve this one either 16.18.11 Quit almog1006 (Quit: Page closed) 16.55.26 # Fuze+ Normal 20hrs, NAS@MAXCPU 20hrs, HBUS200 19h 33m, NAS 19h, NAS+HBUS200 18h 50m 16.56.23 # Pamaury I have the battery benches done disabling autoslow at max cpu gives better performance and no decrease in runtime 16.56.37 # https://www.mediafire.com/#tt3zaxek277cp 16.57.28 # HUS @ 200 knocks off 2.5% runtime 17.00.14 # Bilgus: thanks, so disabling auto-slow at maximum frequency since like the best option 17.00.48 # * pamaury has to go 17.01.23 # between that and boosting hbus I think it'll give a tidy performance increase without affecting runtime noticeably 17.05.34 Quit pamaury (Ping timeout: 248 seconds) 17.17.06 Quit johnb3 (Ping timeout: 252 seconds) 17.25.57 Join krabador [0] (~krabador@unaffiliated/krabador) 17.33.12 Quit krabador (Remote host closed the connection) 17.36.46 Join krabador [0] (~krabador@unaffiliated/krabador) 17.40.29 Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-raikydefsadyymfl) 17.49.34 Quit krabador (Quit: Leaving) 17.49.50 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 17.49.59 Join krabador [0] (~krabador@unaffiliated/krabador) 17.51.12 Quit cc___ (Ping timeout: 252 seconds) 17.52.29 *** Saving seen data "./dancer.seen" 17.53.28 Quit Aldem (Read error: Connection reset by peer) 17.55.04 Join Aldem [0] (~Aldem@unaffiliated/aldem) 18.23.01 Quit Aldem (Read error: Connection reset by peer) 18.24.05 # jhMikeS, I statred to make that mutex static but noticed the as3525 did'nt have it static so I figured there might be some reason it wasn't 18.24.07 # https://github.com/Rockbox/rockbox/blob/master/firmware/target/arm/as3525/system-as3525.c#L36 18.25.40 Join Aldem [0] (~Aldem@unaffiliated/aldem) 18.26.53 # probably just a dumb oversight on my part 18.27.42 Join johnb3 [0] (~johnb2@p5B3AFD32.dip0.t-ipconnect.de) 18.47.35 Join wodz [0] (~wodz@89-79-40-110.dynamic.chello.pl) 18.49.16 # pamaury: I think I found a place calculating some checksum in FwuTail block. Routine reads 0x200 bytes starting from FwuTail signature and the calculates something on last 4 bytes hence I think this is some checksum 18.53.23 # pamaury: If test with checksum pass it checks for 0x55aa55aa at offset 0x14 of the buf. FwuTail sig seems to be checked at offset 0x18 of the buf. Does it ring a bell? 18.53.49 # pamaury: And buf is 0x200 bytes long and seems to be last 0x200 bytes of upgrade file 19.02.33 Join sanchaez [0] (~sanchaez@95.67.87.200) 19.06.27 # jhMikeS: I just commented on the imx233 cpu frequency lock. Can it it be call in non-thread context? 19.07.34 # wodz: yes that seems to match my impression. Can you tell on what the checksum is done and the algorithm? (I guess the checksum is done on the entire file except the last 0x200 bytes) 19.08.36 # pamaury: I believe it is calced on last 0x1fc bytes only 19.09.46 Quit smack_da_cactus (Quit: Page closed) 19.10.19 # ok weird, I just looked and it seems the last 0x200 essentially have four nonzero parts: first 4 bytes, then 0x55aa55aa then FwuTail, then lots zero and finally 4 bytes. 19.11.14 # ah no sorry, I've shifted everything by 0x10 19.12.36 # so at offset 0, 4 bytes. At offet 0x10, 4 bytes. At offset 0x14, 0xaa55aa55 then 'FwuTail'. At offset 0x1fc, 4 bytes 19.13.12 # so you think the first 4 bytes are a checksum of the 0x1fc others? That leaves the 4 bytes at offset 0x10 and 0x1fc. 19.13.31 # * pamaury needs to disassemble more of the Product tool so see if the can find out 19.20.23 Quit dys (Ping timeout: 246 seconds) 19.21.36 Quit robertd1 (Quit: Leaving.) 19.21.57 Join robertd1 [0] (~root@201.242.176.168) 19.23.11 # I think 4 bytes at 0x1fc is the checksum of 0x1fc bytes 19.23.59 # so last 4 bytes is the checksum 19.24.10 Join lebellium [0] (~chatzilla@89-93-177-206.hfc.dyn.abo.bbox.fr) 19.31.36 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:b940:68ea:7a9d:2983) 19.43.13 # pamaury: it was confirmed on head-fi that nwztool works for the ZX300 so I'll update the wiki. Do you still need info about this device or I can remove the "help us" comment? 19.43.42 # lebellium: oh right I forgot to update the wiki, go ahead 19.44.37 # about the NW-A40 I don't know. Did you get confirmation it works from the user who emailed you? 19.45.22 # yes 19.47.05 # Build Server message: 3New build round started. Revision 6e79c4c, 273 builds, 13 clients. 19.47.39 Quit krabador (Quit: Leaving) 19.48.35 # Foswiki detected an internal error - please check your Foswiki logs and webserver logs for more information. 19.48.37 # Unmatched [ in regex; marked by <-- HERE in m/([ <-- HERE =|`}>&'?~"<#{%^\])/ 19.48.38 # grrr 19.48.42 # can't edit the wiki 19.51.28 # oh this error message did not prevent it from saving my changes 19.52.33 *** Saving seen data "./dancer.seen" 19.52.37 Join smbgaiden [0] (~smbgaiden@cpe-70-95-76-131.san.res.rr.com) 19.55.12 Quit johnb3 (Ping timeout: 248 seconds) 19.55.55 # lebellium: it seems to be a spurious error message 19.55.56 Join amayer [0] (~amayer@24.152.198.8.res-cmts.eph2.ptd.net) 19.58.08 # Build Server message: 3Build round completed after 663 seconds. 19.58.09 # Build Server message: 3Revision 6e79c4c result: All green 20.02.41 Join krabador [0] (~krabador@unaffiliated/krabador) 20.10.57 Join mendelmunkis [0] (~Moshe@ool-435154da.dyn.optonline.net) 20.11.05 # pamaury: looks like simple additive checksum (there are some shifts thought) 20.13.49 # I am attempting to use sbloader to recover fuze+ (https://www.rockbox.org/irc/log-20170904) sbloader gives me an error followed by disconnect every time i run it 20.15.24 Join Darkham_ [0] (~krabador@unaffiliated/krabador) 20.16.32 Quit Darkham_ (Remote host closed the connection) 20.18.06 Quit krabador (Ping timeout: 248 seconds) 20.19.57 Join johnb3 [0] (~johnb2@p5B3AFD32.dip0.t-ipconnect.de) 20.21.00 # mendelmunkis: you'll have to be more specific. First why you need to recover and then what kind of error and which firmware you are uploading 20.21.18 Quit _meg (Ping timeout: 248 seconds) 20.22.49 Join _meg [0] (~notsure@211.25.203.45) 20.28.42 # My fuze+ has no signs of life unless i plug it in in recovery mode. i am uploading sansafuzep_recovery.sb which i grabbed from https://www.dropbox.com/s/x5gpo0j9t6l8rbw/sansafuzep_recovery.sb?dl=0 and my error is transfer error at send step 8 /n Error: cannot get status report 20.28.48 Quit bzed (Ping timeout: 248 seconds) 20.35.28 # mendelmunkis: that doesn't sound so good. Did you do anything or it just died like that? 20.36.02 # you can try to upload the original firmware (download the latest firware upgrade from sansa, upload the firmware.sb inside) see if it work better 20.37.38 # i don't think i did anything out of the ordinary. about a month ago i successfully loaded the recovery firmware but before i could install sansa firmware i had to leave town for a month i came back and thats my current state 20.41.59 Part robertd1 20.43.41 Join krabador [0] (~krabador@unaffiliated/krabador) 20.49.32 # mendelmunkis: is the battery particularly low you think? 20.55.07 # i replaced the battery ~mid july but its a distinct possibility 20.56.03 Join robertd1 [0] (~root@201.242.176.168) 20.57.24 Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 56.0/20170926190823]) 20.58.55 Join lebellium [0] (~chatzilla@89-93-177-206.hfc.dyn.abo.bbox.fr) 21.00.27 Quit lebellium (Client Quit) 21.01.48 Join lebellium [0] (~chatzilla@89-93-177-206.hfc.dyn.abo.bbox.fr) 21.04.11 # mendelmunkis: I mean discharged 21.05.10 # I understood you i was reffering to the fact that the batteries come full and this was after my fuze+ died 21.05.56 # I can't parse your sentence :) 21.06.51 Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 56.0/20170926190823]) 21.07.19 Join petur [0] (~petur@rockbox/developer/petur) 21.08.06 Join lebellium [0] (~chatzilla@89-93-177-206.hfc.dyn.abo.bbox.fr) 21.08.18 # batteries don't come full they come with partial charge 21.09.01 # he means is the battery low now like did you charge it before you attempted to push new firmware 21.09.25 # no i have a hard time charging without working firmware 21.09.43 # but i just relized it will charge in recovery 21.10.25 # mendelmunkis: it doesn't charge in recovery 21.10.35 # but I have a recovery firmware to charge it 21.11.02 # oh thats crazy 21.11.18 # https://www.dropbox.com/s/8ftv699ne56vbdt/sansa_fuzeplus_charge.sb?dl=0 21.11.26 # try uploading this one 21.11.56 # the screen will stay black (but sbload should not throw an error), leave it alone charging for at least 15min, possibly an hour 21.11.58 # then retry 21.14.06 Quit krabador (Read error: Connection reset by peer) 21.15.30 # It gives me cant get status report error but lsusb still reads it in recovery mode 21.15.52 # mendelmunkis: did you unplug and replug it? 21.16.04 # also maybe force a reset by holding power for 10 seconds 21.16.21 # while plugged or unplugged? 21.16.27 # unplugged 21.17.32 # I held power for ten sec then plugged it in lsusb reports recovery mode 21.17.56 # Bilgus: A new situation rg. the ATA one: I still have the regular MBOOT_BL on it. I compiled the MBoot FW w/ NoVoltageShutDown and your No_Internal patch. Many tries in between. 2min ago I somehow got it into Bootloader USB Mode and after unpluging it booted into the MBoot_FW. In RB I see my 64GB card in internal and SD (according to the redirect in your patch). 21.18.14 # ye sthat is correct 21.18.37 Join bzed [0] (~bzed@shell.bzed.at) 21.18.39 # But I am afraid this is a transient state :-( I am charging it right now. 21.19.52 # I could try and rolo the revovery from SD. 21.20.02 # thats the idea 21.20.17 # then you can write the new bootloader directly to the drive 21.25.03 # I am going in circles: rolo caused the ATA -2 again. 21.25.32 # which recovery firmware are you trying to rolo? 21.26.18 # ClipPlus_rockbox_RECOVERY3.3VCCD_NWB.sansa was on the SD. 21.26.54 # I mean there is no way around it the recovery has to access the internal memory in order for you to restore it 21.27.16 # if you already have the MB FW with no internal maybe you should just run that 21.27.44 # and be sure you never start the device without the SD card and never go into OF 21.28.06 # mendelmunkis: was the upload successful? 21.28.49 # i got a error cant get status report 21.28.58 # The problem is I cannot start that reliably. I probably have to hit a lucky moment, when maybe I can write the other bin file. 21.29.11 # ugh 21.29.52 # explain why you can't start that reliably? you already have the MB BOOTLOADER on the device yes? 21.30.15 # mendelmunkis: leave it plugged anyway, the upload might have been successful 21.30.16 # Thanks anyway. I believe you provided anything which has the potential to fix it. Now I need some luck. 21.30.35 # or is it precisely because the BOOTLOADER inits the internal and crashes the device? 21.31.01 # I assume so. 21.31.13 # mendelmunkis: for the charging recovery firmware, I think the status report is not supposed to be successful, but I wrote it a long time ago so I don't remember 21.31.13 # pamaury: I replugged is that a problem or should I transfer again? 21.31.22 # hmm well let me know if you need anything else 21.31.26 # mendelmunkis: transfer again 21.31.30 # thank you 21.31.39 # mendelmunkis: as long as you don't get an error during data transfer, it should be ok 21.31.45 # (ie error at step x) 21.32.05 # im assuming it works because its so small it can transfer in one go? 21.32.23 # i was worried because lsusb was still reporting recovery 21.32.28 # mendelmunkis: it's not so simple 21.32.40 # mendelmunkis: the charging recovery will not change the lsusb output 21.33.23 # ok do you mind pointing me to an explanation of the charging sb? 21.33.38 # what do you want to know? 21.34.12 # I can explain everything but it may be long ^^ 21.35.07 # Why does it transfer when your standard recovery doesn't? 21.36.19 # And i would like to see the source if you don't mind sharing. 21.37.46 # because a SB file is not just a binary blob that is uploaded and executed. It's made up for chunks that each loaded indivually then executed, then it goes to the next chunk. The charging recovery is something I wrote and only has one chunk that poke a few registers to start charging and stops. 21.38.18 # Thanks 21.38.24 # On the other hand, the standard recovery firmware needs to enable RAM, and for this we rely on a few blobs from the original firmware, those are run before the actual recovery code. And I suspect one of those stops boot if battery is too low 21.38.44 # the recovery firmware is built is mkimxboot: https://git.rockbox.org/?p=rockbox.git;a=tree;f=rbutil/mkimxboot;h=5e343cdeb95e70e30dbcef2dd0d97a12e82d0929;hb=HEAD 21.38.59 # and the actual code is there: https://git.rockbox.org/?p=rockbox.git;a=blob;f=rbutil/mkimxboot/dualboot/dualboot.c;h=77b816bf76d300b5414f623dd2b124ab28cb02d2;hb=HEAD 21.40.53 # i was referring to the charge source 21.41.12 # unless I misunderstood what i was reading? 21.41.43 # the code in dualboot.c contains the code for charging 21.41.58 # despite the name it does more than dualbooting 21.42.28 # ok thanks 21.42.51 Quit johnb3 (Ping timeout: 260 seconds) 21.43.59 # unrelatedly i am assuming that to switch boot order is just removing the ! on line 119? 21.45.48 # if you want to boot OF by default rather than rockbox then yes 21.49.01 # pamaury: Checksum is simple additive one. The only twist is that it sums words (I think LE) and not bytes. 21.50.24 # wodz: ok thanks, I'll check if it matches what I see. 21.50.47 # I'm a bit more worried about the other unknowns bytes, I think more disassembly of the Product tool might be necessary 21.51.48 # pamaury: CRC routine has two variants - one taking halfwords and second taking words. 'FwuTail' block is using word version. 21.52.37 *** Saving seen data "./dancer.seen" 21.53.39 # and what is the other variant used for? is it CRCing the rest of the firmware? 21.54.49 # pamaury: The fwu for e150 I have has 01 07 00 00 @ 0, 2f cd 4f ba @ 0x10, aa 55 aa 55 @ 0x14, 'FwuTail' @ 0x18 and 81 0a dc 64 @ 0x1fc 21.55.09 # pamaury: Don't know yet where halfword version is used 21.55.15 Quit mendelmunkis (Read error: Connection reset by peer) 21.57.41 # pamaury: There are 6 sites calling CRC routine total. 2 use word version, 4 use halfword version. 21.58.43 # the one thing that puzzles me is that this FwuTail doesn't seem to appear in all ATJ firmware, I can't see a logic there 22.02.39 Join johnb3 [0] (~johnb2@p5B3AFD32.dip0.t-ipconnect.de) 22.03.34 Quit johnb3 (Client Quit) 22.04.49 Join johnb3 [0] (~johnb2@p5B3AFD32.dip0.t-ipconnect.de) 22.17.50 Join mendelmunkis [0] (~Moshe@ool-435154da.dyn.optonline.net) 22.18.40 # pamaury: Thank you very much. i have recovery 22.19.28 # great :) 22.21.30 # which partition do i dd the sansa sb to? 22.21.58 # i have 4 22.22.58 Quit johnb3 (Ping timeout: 258 seconds) 22.23.33 # mendelmunkis: see https://www.rockbox.org/wiki/SansaFuzePlusRescue 22.23.45 # basically first find the partition with type 53 using fdisk 22.23.56 # then don't just dd the firmware, you need an offset 22.24.14 # dd if=firmware.sb bs=512 seek=4 of=/dev/sdX 22.28.19 # pamaury: There is yet another checksum routine. This one takes whole file *WITHOUT* last 0x200 and sums words. 22.30.20 # wodz: I found some info in textual form in the firmware! 22.30.31 # STRUCT FwuTail_t {BYTE bLength = 1 ; BYTE bType = 7 ; BYTE Reserved1[14] ; 22.30.31 # DWORD dFwuChecksum ; DWORD dFlag = 1437226410 ; BYTE pbDescriptor[8] = "FwuTail" ; BYTE pbFwuCrcChecksum[32] ; BYTE Reserved2[444] ; DWORD dFwuTailChecksum ; } 22.30.52 # so there are three checksums, one of the firmware apparently, of the fwutail, one of ? 22.31.02 # LOL 22.31.13 # this is seriously overkill 22.34.32 Quit mendelmunkis (Remote host closed the connection) 22.34.35 # oh wait, the pbFwuCrcChecksum is all zero in the E150 firmware 22.35.20 Join mendelmunkis [0] (~Moshe@ool-435154da.dyn.optonline.net) 22.37.41 # wodz: I think I found the code in the product tool that creates the fwutail 22.38.10 # from what I see, dFwuChecksum is just a sum, but done over double-words (32-bit) 22.38.43 # and same thing for dFwuTailChecksum, but on the 0x1fc bytes of the tail 22.41.02 # pamaury: That matches what I see here 22.41.30 Part chrisb ("rcirc on GNU Emacs 26.0.50") 22.44.04 # I am still confused by something though, the fwutail seem to be included 'in the firmware', ie it's within the first N bytes, where N is the firmware size given in the header 22.44.56 # but if the tail includes the CRC of the entire firmware, that means the size is already created to by the fw size + 512 to account for the fwutail, so the tail is not just some bytes that are added after the firmware is created 22.45.03 # but not all firmware include this :-/ 22.45.34 Quit Aldem (Read error: Connection reset by peer) 22.47.17 Join Aldem [0] (~Aldem@unaffiliated/aldem) 22.51.52 # wodz: are you porting to the E100 or E150? 22.52.00 # e150 22.52.22 # but I believe there are minor differences between the two 22.54.04 Quit mendelmunkis (Quit: Leaving) 22.54.44 # I guess I'll add to check for FwuTail, see if it contains the magic string at the end, I don't see any obvious flag that would indicate its presence 22.55.04 # how does firmware upgrade work? Do you just put the firmware at the root? 22.59.17 # I think yes 23.10.53 # pamaury: firmware (file length - 0xa00) is stored near the begining of the file 0x10 offset? check routine uses unaligned access for this field which is strange 23.11.14 # wodz: yes 23.11.59 # wodz: do you have name of devices or firmwares that have an ATJ213x? 23.14.41 # pamaury: iriver e100/e150/e200/e300, philips Ariaz4 23.14.58 # pamaury: I have a few firmwares as well 23.17.51 # hmm, unaligned access opcodes might be artifact of struct declared as packed and low level of optimization 23.18.02 # yeah probably 23.18.25 # probably because the compiler did not assume that the structure was aligned in the first place 23.19.55 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 23.22.44 Quit amayer (Quit: Leaving) 23.40.12 # lovely IDA decided to corrupt database and can't recover it :/ 23.40.30 Quit petur (Quit: Leaving) 23.42.31 Join lebellium_ [0] (~chatzilla@89-93-177-206.hfc.dyn.abo.bbox.fr) 23.43.46 Join lebellium___ [0] (~chatzilla@89-93-177-206.hfc.dyn.abo.bbox.fr) 23.45.34 Quit lebellium (Ping timeout: 248 seconds) 23.45.41 Nick lebellium___ is now known as lebellium (~chatzilla@89-93-177-206.hfc.dyn.abo.bbox.fr) 23.47.17 Quit lebellium_ (Ping timeout: 258 seconds) 23.48.33 # wodz: you can always restore from packed database 23.49.05 # pamaury: It says it can't (or more exactly it throws an error and crashes) 23.52.11 Quit wodz (Quit: Leaving) 23.52.39 *** Saving seen data "./dancer.seen" 23.58.24 # Build Server message: 3New build round started. Revision 7e42e90, 273 builds, 12 clients.