Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2017-10-20

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:00
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
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:00
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:00
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:00
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:00
07:02:54 Quit Ruhan (Quit: Connection closed for inactivity)
07:52:18***Saving seen data "./dancer.seen"
08:00
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:00
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:00
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:46wodzpamaury: 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:10pamaurywodz: cool, thanks. Can you tell what it is doing now or it's stll unclear?
10:21:39wodzpamaury: I spend all time yesterday on mapping syscalls
10:22:25wodzpamaury: and there are well over hundred
10:23:33pamauryoh 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:00
11:21:56 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
11:22:54wodzpamaury: back?
11:23:53pamauryyes
11:27:37wodzOk. 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:59wodzhence In order to perform syscall you need to write wrapper in assembly.
11:28:35pamauryok, that makes more sense now
11:29:32wodzThen, there is mechanism of dynamically registering new syscalls and drivers can register new syscalls
11:30:33wodzthere 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:00
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:00
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:00
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:00
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:13johnb3pamaury: 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:00
16:02:33pamauryyeah I've seen that, but since I can't solve the flac problem, I con
16:02:40pamaurydon't know how to solve this one either
16:18:11 Quit almog1006 (Quit: Page closed)
16:55:26BilgusFuze+ Normal 20hrs, NAS@MAXCPU 20hrs, HBUS200 19h 33m, NAS 19h, NAS+HBUS200 18h 50m
16:56:23BilgusPamaury I have the battery benches done disabling autoslow at max cpu gives better performance and no decrease in runtime
16:56:37Bilgushttps://www.mediafire.com/#tt3zaxek277cp
16:57:28BilgusHUS @ 200 knocks off 2.5% runtime
17:00
17:00:14pamauryBilgus: thanks, so disabling auto-slow at maximum frequency since like the best option
17:00:48*pamaury has to go
17:01:23Bilgusbetween 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:00
18:23:01 Quit Aldem (Read error: Connection reset by peer)
18:24:05BilgusjhMikeS, 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:07Bilgushttps://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:53jhMikeSprobably 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:16wodzpamaury: 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:23wodzpamaury: 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:49wodzpamaury: And buf is 0x200 bytes long and seems to be last 0x200 bytes of upgrade file
19:00
19:02:33 Join sanchaez [0] (~sanchaez@95.67.87.200)
19:06:27pamauryjhMikeS: I just commented on the imx233 cpu frequency lock. Can it it be call in non-thread context?
19:07:34pamaurywodz: 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:36wodzpamaury: I believe it is calced on last 0x1fc bytes only
19:09:46 Quit smack_da_cactus (Quit: Page closed)
19:10:19pamauryok 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:14pamauryah no sorry, I've shifted everything by 0x10
19:12:36pamauryso at offset 0, 4 bytes. At offet 0x10, 4 bytes. At offset 0x14, 0xaa55aa55 then 'FwuTail'. At offset 0x1fc, 4 bytes
19:13:12pamauryso 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:11wodzI think 4 bytes at 0x1fc is the checksum of 0x1fc bytes
19:23:59wodzso 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:13lebelliumpamaury: 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:42pamaurylebellium: oh right I forgot to update the wiki, go ahead
19:44:37lebelliumabout the NW-A40 I don't know. Did you get confirmation it works from the user who emailed you?
19:45:22pamauryyes
19:47:05fs-bluebot_Build Server message: New build round started. Revision 6e79c4c, 273 builds, 13 clients.
19:47:39 Quit krabador (Quit: Leaving)
19:48:35lebelliumFoswiki detected an internal error - please check your Foswiki logs and webserver logs for more information.
19:48:37lebelliumUnmatched [ in regex; marked by <−− HERE in m/([ <−− HERE =|`}>&'?~"<#{%^\])/
19:48:38lebelliumgrrr
19:48:42lebelliumcan't edit the wiki
19:51:28lebelliumoh 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:55pamaurylebellium: 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:08fs-bluebot_Build Server message: Build round completed after 663 seconds.
19:58:09fs-bluebot_Build Server message: Revision 6e79c4c result: All green
20:00
20:02:41 Join krabador [0] (~krabador@unaffiliated/krabador)
20:10:57 Join mendelmunkis [0] (~Moshe@ool-435154da.dyn.optonline.net)
20:11:05wodzpamaury: looks like simple additive checksum (there are some shifts thought)
20:13:49mendelmunkisI 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:00pamaurymendelmunkis: 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:42mendelmunkisMy 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:28pamaurymendelmunkis: that doesn't sound so good. Did you do anything or it just died like that?
20:36:02pamauryyou 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:38mendelmunkisi 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:32pamaurymendelmunkis: is the battery particularly low you think?
20:55:07mendelmunkisi 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
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:11pamaurymendelmunkis: I mean discharged
21:05:10mendelmunkisI understood you i was reffering to the fact that the batteries come full and this was after my fuze+ died
21:05:56pamauryI 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:18Bilgusbatteries don't come full they come with partial charge
21:09:01Bilgushe means is the battery low now like did you charge it before you attempted to push new firmware
21:09:25mendelmunkisno i have a hard time charging without working firmware
21:09:43mendelmunkisbut i just relized it will charge in recovery
21:10:25pamaurymendelmunkis: it doesn't charge in recovery
21:10:35pamaurybut I have a recovery firmware to charge it
21:11:02Bilgusoh thats crazy
21:11:18pamauryhttps://www.dropbox.com/s/8ftv699ne56vbdt/sansa_fuzeplus_charge.sb?dl=0
21:11:26pamaurytry uploading this one
21:11:56pamaurythe screen will stay black (but sbload should not throw an error), leave it alone charging for at least 15min, possibly an hour
21:11:58pamaurythen retry
21:14:06 Quit krabador (Read error: Connection reset by peer)
21:15:30mendelmunkisIt gives me cant get status report error but lsusb still reads it in recovery mode
21:15:52pamaurymendelmunkis: did you unplug and replug it?
21:16:04pamauryalso maybe force a reset by holding power for 10 seconds
21:16:21mendelmunkiswhile plugged or unplugged?
21:16:27pamauryunplugged
21:17:32mendelmunkisI held power for ten sec then plugged it in lsusb reports recovery mode
21:17:56johnb3Bilgus: 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:14Bilgusye sthat is correct
21:18:37 Join bzed [0] (~bzed@shell.bzed.at)
21:18:39johnb3But I am afraid this is a transient state :-( I am charging it right now.
21:19:52johnb3I could try and rolo the revovery from SD.
21:20:02Bilgusthats the idea
21:20:17Bilgusthen you can write the new bootloader directly to the drive
21:25:03johnb3I am going in circles: rolo caused the ATA -2 again.
21:25:32Bilguswhich recovery firmware are you trying to rolo?
21:26:18johnb3ClipPlus_rockbox_RECOVERY3.3VCCD_NWB.sansa was on the SD.
21:26:54BilgusI mean there is no way around it the recovery has to access the internal memory in order for you to restore it
21:27:16Bilgusif you already have the MB FW with no internal maybe you should just run that
21:27:44Bilgusand be sure you never start the device without the SD card and never go into OF
21:28:06pamaurymendelmunkis: was the upload successful?
21:28:49mendelmunkisi got a error cant get status report
21:28:58johnb3The 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:11Bilgusugh
21:29:52Bilgusexplain why you can't start that reliably? you already have the MB BOOTLOADER on the device yes?
21:30:15pamaurymendelmunkis: leave it plugged anyway, the upload might have been successful
21:30:16johnb3Thanks anyway. I believe you provided anything which has the potential to fix it. Now I need some luck.
21:30:35Bilgusor is it precisely because the BOOTLOADER inits the internal and crashes the device?
21:31:01johnb3I assume so.
21:31:13pamaurymendelmunkis: 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:13mendelmunkispamaury: I replugged is that a problem or should I transfer again?
21:31:22Bilgushmm well let me know if you need anything else
21:31:26pamaurymendelmunkis: transfer again
21:31:30mendelmunkisthank you
21:31:39pamaurymendelmunkis: as long as you don't get an error during data transfer, it should be ok
21:31:45pamaury(ie error at step x)
21:32:05mendelmunkisim assuming it works because its so small it can transfer in one go?
21:32:23mendelmunkisi was worried because lsusb was still reporting recovery
21:32:28pamaurymendelmunkis: it's not so simple
21:32:40pamaurymendelmunkis: the charging recovery will not change the lsusb output
21:33:23mendelmunkisok do you mind pointing me to an explanation of the charging sb?
21:33:38pamaurywhat do you want to know?
21:34:12pamauryI can explain everything but it may be long ^^
21:35:07mendelmunkisWhy does it transfer when your standard recovery doesn't?
21:36:19mendelmunkisAnd i would like to see the source if you don't mind sharing.
21:37:46pamaurybecause 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:18mendelmunkisThanks
21:38:24pamauryOn 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:44pamaurythe recovery firmware is built is mkimxboot: https://git.rockbox.org/?p=rockbox.git;a=tree;f=rbutil/mkimxboot;h=5e343cdeb95e70e30dbcef2dd0d97a12e82d0929;hb=HEAD
21:38:59pamauryand 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:53mendelmunkisi was referring to the charge source
21:41:12mendelmunkisunless I misunderstood what i was reading?
21:41:43pamaurythe code in dualboot.c contains the code for charging
21:41:58pamaurydespite the name it does more than dualbooting
21:42:28mendelmunkisok thanks
21:42:51 Quit johnb3 (Ping timeout: 260 seconds)
21:43:59mendelmunkisunrelatedly i am assuming that to switch boot order is just removing the ! on line 119?
21:45:48pamauryif you want to boot OF by default rather than rockbox then yes
21:49:01wodzpamaury: Checksum is simple additive one. The only twist is that it sums words (I think LE) and not bytes.
21:50:24pamaurywodz: ok thanks, I'll check if it matches what I see.
21:50:47pamauryI'm a bit more worried about the other unknowns bytes, I think more disassembly of the Product tool might be necessary
21:51:48wodzpamaury: 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:39pamauryand what is the other variant used for? is it CRCing the rest of the firmware?
21:54:49wodzpamaury: 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:09wodzpamaury: Don't know yet where halfword version is used
21:55:15 Quit mendelmunkis (Read error: Connection reset by peer)
21:57:41wodzpamaury: There are 6 sites calling CRC routine total. 2 use word version, 4 use halfword version.
21:58:43pamaurythe 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:00
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:40mendelmunkispamaury: Thank you very much. i have recovery
22:19:28pamaurygreat :)
22:21:30mendelmunkiswhich partition do i dd the sansa sb to?
22:21:58mendelmunkisi have 4
22:22:58 Quit johnb3 (Ping timeout: 258 seconds)
22:23:33pamaurymendelmunkis: see https://www.rockbox.org/wiki/SansaFuzePlusRescue
22:23:45pamaurybasically first find the partition with type 53 using fdisk
22:23:56pamaurythen don't just dd the firmware, you need an offset
22:24:14pamaurydd if=firmware.sb bs=512 seek=4 of=/dev/sdX
22:28:19wodzpamaury: There is yet another checksum routine. This one takes whole file *WITHOUT* last 0x200 and sums words.
22:30:20pamaurywodz: I found some info in textual form in the firmware!
22:30:31pamaurySTRUCT FwuTail_t {BYTE bLength = 1 ; BYTE bType = 7 ; BYTE Reserved1[14] ;
22:30:31pamauryDWORD dFwuChecksum ; DWORD dFlag = 1437226410 ; BYTE pbDescriptor[8] = "FwuTail" ; BYTE pbFwuCrcChecksum[32] ; BYTE Reserved2[444] ; DWORD dFwuTailChecksum ; }
22:30:52pamauryso there are three checksums, one of the firmware apparently, of the fwutail, one of ?
22:31:02wodzLOL
22:31:13pamaurythis is seriously overkill
22:34:32 Quit mendelmunkis (Remote host closed the connection)
22:34:35pamauryoh wait, the pbFwuCrcChecksum is all zero in the E150 firmware
22:35:20 Join mendelmunkis [0] (~Moshe@ool-435154da.dyn.optonline.net)
22:37:41pamaurywodz: I think I found the code in the product tool that creates the fwutail
22:38:10pamauryfrom what I see, dFwuChecksum is just a sum, but done over double-words (32-bit)
22:38:43pamauryand same thing for dFwuTailChecksum, but on the 0x1fc bytes of the tail
22:41:02wodzpamaury: That matches what I see here
22:41:30 Part chrisb ("rcirc on GNU Emacs 26.0.50")
22:44:04pamauryI 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:56pamaurybut 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:03pamaurybut 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:52pamaurywodz: are you porting to the E100 or E150?
22:52:00wodze150
22:52:22wodzbut I believe there are minor differences between the two
22:54:04 Quit mendelmunkis (Quit: Leaving)
22:54:44pamauryI 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:04pamauryhow does firmware upgrade work? Do you just put the firmware at the root?
22:59:17wodzI think yes
23:00
23:10:53wodzpamaury: 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:14pamaurywodz: yes
23:11:59pamaurywodz: do you have name of devices or firmwares that have an ATJ213x?
23:14:41wodzpamaury: iriver e100/e150/e200/e300, philips Ariaz4
23:14:58wodzpamaury: I have a few firmwares as well
23:17:51wodzhmm, unaligned access opcodes might be artifact of struct declared as packed and low level of optimization
23:18:02pamauryyeah probably
23:18:25pamauryprobably 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:12wodzlovely 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:33pamaurywodz: you can always restore from packed database
23:49:05wodzpamaury: 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:24fs-bluebot_Build Server message: New build round started. Revision 7e42e90, 273 builds, 12 clients.

Previous day | Next day