--- Log for 03.12.110 Server: niven.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 day and 9 hours ago 00.01.42 Quit ender` (Quit: If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell) 00.06.21 Quit n1s (Quit: Lämnar) 00.17.26 # * pamaury starts to disassemble the second elf file of the ____ section of the fuze+ firmware 00.22.37 Join designate72 [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 00.24.05 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 00.24.33 Quit JdGord (Quit: Bye) 00.25.01 *** Saving seen data "./dancer.seen" 00.28.08 Quit chattr (Remote host closed the connection) 00.32.00 # saratoga: yeah, i kinda expected it to be 00.32.08 # their codecs are nice and concise 00.32.52 Join n1s [0] (~n1s@nl118-174-240.student.uu.se) 00.32.53 Quit n1s (Changing host) 00.32.53 Join n1s [0] (~n1s@rockbox/developer/n1s) 00.34.22 Join chattr [0] (~mike@244.87.189.72.cfl.res.rr.com) 00.34.54 Join Keripo [0] (~Keripo@eng348.wireless-resnet.upenn.edu) 00.35.54 # hum, there are breakpoint instructions in the fuze+ code ! 00.42.02 Quit BlakeJohnson861 (Ping timeout: 255 seconds) 00.49.28 Quit mt (Ping timeout: 245 seconds) 00.50.11 # hmm, interestingly gcc can decide a function call is unlikely with no branch hints or profiling info at all 00.50.33 Quit dfkt (Quit: -= SysReset 2.53=- Sic gorgiamus allos subjectatos nunc.) 00.50.52 # New commit by 03kugel (r28728): Android: Make lcd updates synchronous, doesn't make it faster but smoother (no updates are skipped) and guaranteed to be glitch free. ... 00.51.35 # pamaury: what that means? why is there a Brekpoint instrautcion? 00.51.51 # pamaury: are you doing debug? 00.52.12 # no, I just find it weird that the fimware code has some breakpoint instructions in it 00.52.35 # what firmware is that? 00.52.39 # fuze+ 00.52.58 # r28728 build result: 5 errors, 43831 warnings (kugel committed) 00.53.38 # original firmware? 00.53.47 # yes 00.54.03 # it's easy to access OF? 00.54.11 # how did you got it? 00.54.37 # having break point instructions is very weird! 00.55.07 # you can easily download the firmware and I spent quite a number of hours figuring out the format and encryption scheme with bertrik 00.55.15 # the tool is in svn 00.56.26 # New commit by 03kugel (r28729): Fix red by moving the difinition up. 00.57.36 Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 00.58.01 # ah, ok! :-) 00.58.25 # maybe format/encrytipon schme is worng ;-) 00.59.01 # r28729 build result: 723 errors, 62215 warnings (kugel committed) 00.59.05 # msut be worng... I mean, there should no be breakpoint instructions, or the fimrware would not run,, right? 00.59.57 # these are conditional 01.00.11 # I guess there are a cheap & low-level panic :) 01.00.21 # I assure you the format is right :) 01.00.42 # perhaps they distributed a debug built, would also explain the zero key 01.01.33 # possibly, that would explain some strange conditions in the code which seriously look like assertions 01.02.10 # what SOC does it uses? 01.02.35 # stmp37xx == imx23 01.02.40 # uaua!!! 01.02.51 # pamaury: I am working also with imx233! 01.03.02 Quit Keripo (Quit: Leaving.) 01.03.16 # yes, I know. We weren't talking about imx23 by chance :) 01.03.47 # hey, I think guys at Chumby don't know how to decrypt image file!! and you got it???? 01.04.31 # I documented it on the wiki and I wrote the sbinfo tool in svn with bertrik 01.04.34 # where is the tool on SVN? 01.04.45 # ./utils/sbinfo/ 01.05.03 Join Keripo [0] (~Keripo@eng348.wireless-resnet.upenn.edu) 01.05.11 # what the heck 01.06.11 # New commit by 03kugel (r28730): That was a bit too far upwards :( 01.06.19 # pamaury: thanks!!!!! 01.06.47 # kugel: you particulary good at generated lots of builds errors 01.06.51 # *generating 01.07.19 # pamaury: so, will you create imx23 on Rockbox tree? 01.07.29 # well, I checked the sims before the first commit but not a real target. now I checked a real target but not the sims :'( 01.07.36 # pamaury: do you have any working code? 01.07.36 # bad luck 01.07.43 # haha 01.07.58 # well, first we need to disassmemble the firmware to figure out the pins 01.08.11 # bertrik is working on some part and I'm working on another one 01.08.26 # I suspect we also don't know yet how to inject some code? 01.08.29 # If we get sufficiently enough information, we'll try to port it I guess 01.08.30 # r28730 build result: All green 01.08.57 # here is the code I have for imx233, for Propendous board I am using: http://lyre.svn.sourceforge.net/viewvc/lyre/propendous-imx233_board/firmware/ 01.09.10 # we got a lot of help from Chumby devs! 01.09.19 # None of us as a real target. It seems there a reset mode which puts a recovery version of the firmware and you can update the firmware by putting the file at the root in MSC mode 01.09.28 # *has 01.10.07 # If we are lucky, we can just write the code, convert it to .sb using elftosb2 and update the firmware just like with the OF 01.10.08 # there is a USB mode recovery 01.10.16 # on fuze+ ? 01.10.26 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 01.10.34 # on imx233 there is a USB recovery mode.... 01.11.12 # I think I read somewhere in the doc that the manufacturer can enable/disable boot modes, so we don't really know if it's enabled and how to trigger it 01.11.56 # yes, there are fuse bits, that manufacture can burn 01.12.23 # there is a windows application to communicate by USB with imx233 and we can see/configure that bits 01.12.31 # yeah, and we saw that they did a nice job at keeping the zero key ;) 01.13.02 # yeah... that's de default key of imx233... so maybe they are not changing nothing on the fuse bits... 01.13.05 Quit n1s (Quit: Lämnar) 01.13.18 # There might be some difference between imx233 which is a board and imx23 which is on the fuze+ 01.13.36 # hmmm, ok 01.13.48 # I think they regretted the USB recovery on the e200 (it made more trouble than it helped) and the non-existent usb recovery on the ams series worked pretty well so I assume they deactivated it again 01.14.03 Quit Stummi (Ping timeout: 260 seconds) 01.14.15 # why more trouble ? 01.14.20 # hey, there is only imx233! 01.14.23 # right? 01.15.04 Join pdrai [0] (DraaK@88.159.105.188) 01.15.32 Join Stummi [0] (Stummi@rockbox/developer/Stummi) 01.15.53 # kugel: I've had no rockbox time for ages, you don't want to take over the open() patch do you? 01.15.55 # when it comes to the chip, I think there is one which is imx23=imx233=stmp37xx, you can call it the way you want 01.17.55 # JdGordon|: I can have a look...maybe 01.18.12 # kugel: actually, someone on the forum and on irc (if iirc) told us he tried the "reset function" (hold on/off for 20 seconds) and he said it acted like a firmware upgrade. So maybe there is a kind of recovery function 01.18.31 # kugel: I'd also ask about the dynamic screen size one but IIRC you wernt particularly keen on it? 01.18.42 Quit robin0800 (Remote host closed the connection) 01.19.56 # I'm not overly keen on it because it doesn't really solve any problems because themes and many plugins are still resolution dependend, but I'm be in favor in generally 01.20.58 Quit Keripo (Ping timeout: 240 seconds) 01.21.05 Join Keripo [0] (~Keripo@dhcp0101.kin.resnet.group.upenn.edu) 01.21.56 # I thought the other day that we could possibly have themes resolution independent if we let %V (and friends) take % (e.g. x=10% of the width) as parameters and have bmp resize for the theme's images 01.22.50 # pamaury, so you don't have a Sansa Fuze+? 01.23.07 # no 01.23.20 # not yet ;) 01.23.20 # kugel: I dont tinhk that would solve it all that much 01.23.38 # and that is ony a bit scary 01.32.18 # pamaury: so, what is your motivation? 01.32.48 # make sure the fuze+ arise 01.33.12 # I just don't want to buy a fuze+ if I'm not sure we can port it 01.33.24 # And that wasn't clear until we decrypted the sb format 01.33.34 # s/until/before 01.34.51 # d oyou know how many FLASH chips fuze+ have inside? 01.35.05 # the wiki as some photos on the fuze+ 01.35.08 # *has 01.35.11 # where is stored firmware + user files? 01.35.11 # *of 01.35.36 # it is probably stored in a nand memory 01.37.33 # time to go to bed, see you 01.39.52 # see you 01.39.53 # thaks 01.41.35 Quit pamaury (Remote host closed the connection) 01.55.38 Join webguest10 [0] (~50d4d691@giant.haxx.se) 01.55.45 Quit webguest10 (Client Quit) 02.01.56 Quit kugel (Remote host closed the connection) 02.09.40 Quit casainho (Remote host closed the connection) 02.10.31 # bertrik: (logs) - looks like another FM Radio chip in Fuzev2 - see FS#11791 02.12.39 Part designate72 ("Leaving") 02.13.54 Join elcan [0] (user36@pr0.us) 02.16.00 Join ReimuHakurei [0] (~ReimuHaku@74.112.212.15) 02.25.03 *** Saving seen data "./dancer.seen" 02.25.13 Quit ReimuHakurei (Quit: > Me... > Quitting IRC... > LOLYEAHRIGHT!) 02.25.21 Quit iq (Remote host closed the connection) 02.26.38 Join LambdaCalculus37 [0] (~rmenes@c-68-36-232-73.hsd1.nj.comcast.net) 02.26.38 Quit LambdaCalculus37 (Changing host) 02.26.38 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 02.29.00 Join iq [0] (~iq@unaffiliated/iq) 02.29.13 Quit LambdaCalculus37 (Client Quit) 02.31.35 Join LambdaCalculus37 [0] (~rmenes@c-68-36-232-73.hsd1.nj.comcast.net) 02.31.35 Quit LambdaCalculus37 (Changing host) 02.31.35 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 02.33.59 Part LambdaCalculus37 02.34.34 Quit DerPapst (Quit: Leaving.) 02.34.46 Join madalu [0] (~user@unaffiliated/madalu) 02.35.22 # preglow: I'm still hoping some day we get a GSOC student willing and able to tackle an ffmpeg aac port to rockbox, but it'd be so much work i'm not sure it'll ever happen 02.37.55 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 02.41.38 Quit liar (Ping timeout: 240 seconds) 02.59.46 Quit madalu (Remote host closed the connection) 03.01.12 Join xxcv [0] (~null@c211-30-174-99.carlnfd1.nsw.optusnet.com.au) 03.03.41 Quit JesusFreak316 (Read error: Connection reset by peer) 03.08.27 Join madalu [0] (~user@unaffiliated/madalu) 03.31.29 Join Llorean [0] (~DarkkOne@99-68-45-56.lightspeed.hstntx.sbcglobal.net) 03.31.31 Quit Llorean (Changing host) 03.31.31 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 03.55.57 Join eWill [0] (~chatzilla@adsl-76-235-49-53.dsl.dytnoh.sbcglobal.net) 03.58.51 # I want to use RButil to create a voice file -- without the device connected. Possible? 04.00.46 # never mind, I think I figured it out. 04.01.07 Quit ehntoo (Remote host closed the connection) 04.04.53 # still can't make a voice file for fuze v2 --- Encoding of C:/Users//AppData/Local/Temp/rbvoice//LANG_CREDITS.wav failed 04.04.56 Quit InsDel (Read error: Connection reset by peer) 04.14.24 Quit TheSeven (Ping timeout: 245 seconds) 04.16.42 Quit tchan (Quit: WeeChat 0.3.3-dev) 04.18.39 Join Barahir_ [0] (~jonathan@frnk-590fdb8d.pool.mediaWays.net) 04.19.12 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.19.26 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 04.22.01 Quit Barahir (Ping timeout: 255 seconds) 04.25.05 *** Saving seen data "./dancer.seen" 04.43.00 Quit amiconn (Disconnected by services) 04.43.00 Quit pixelma (Disconnected by services) 04.43.00 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.43.02 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.43.04 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.43.20 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.50.02 Quit sasquatch (Quit: WeeChat 0.3.2) 04.50.27 Join sasquatch [0] (~username@p4FF2CADB.dip.t-dialin.net) 04.56.30 Quit Keripo (Quit: Leaving.) 04.57.10 Join Keripo [0] (~Keripo@dhcp0101.kin.resnet.group.upenn.edu) 04.58.27 Quit ReimuHakurei__ (Quit: Stand by, Ready!) 05.01.41 Quit anewuser () 05.08.09 Join ReimuHakurei [0] (~reimu@74.112.212.15) 05.15.20 Join someuser [0] (~d5973ec1@giant.haxx.se) 05.15.44 # join #slimrat 05.16.13 Quit someuser (Client Quit) 05.25.13 Join froggyman [0] (~seth@unaffiliated/froggyman) 05.30.34 Quit factor (Quit: Leaving) 05.31.06 Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 05.33.00 Quit LambdaCalculus37 (Quit: bed) 05.33.28 Quit Horscht (Quit: Verlassend) 05.48.30 Quit timccc (Ping timeout: 240 seconds) 05.48.30 Quit ReimuHakurei (Read error: Connection reset by peer) 05.53.28 Quit JdGordon (Ping timeout: 255 seconds) 05.54.41 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 05.57.20 Quit factor (Quit: Leaving) 05.57.45 Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 05.59.33 Quit factor (Excess Flood) 06.00.00 Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 06.08.18 Quit Strife89 (Ping timeout: 240 seconds) 06.15.24 Join Jeshikah [0] (~4a69ab57@giant.haxx.se) 06.20.36 Quit madalu (Ping timeout: 276 seconds) 06.23.10 # a great audio/video format converter that's free) the videos would absolutely not play under rockbox. i assume that it's an issue of incompatible codecs, so i'm asking that here 06.23.48 # you might want to try again, sarting at the begining of your question 06.24.09 # agh, lemme try it in sections: 06.24.31 # what codecs does rockbox support for the mpg files? 06.25.08 *** Saving seen data "./dancer.seen" 06.25.13 # http://www.rockbox.org/wiki/PluginMpegplayer 06.29.31 # tyvm, will try it and see how it works for me 06.38.45 # yay, it's working now, lol, it seems it was the choice of width/height that was messing it up, lol 06.39.23 Quit Jeshikah (Quit: CGI:IRC 0.5.9 (2006/06/06)) 06.42.59 Join Strife89 [0] (~Strife89@adsl-80-128-22.mcn.bellsouth.net) 06.46.33 Quit xxcv () 06.48.41 # WTF?! "PANIC: No font!" 06.48.45 # never seen that one before 06.57.04 Quit JdGordon| (Quit: leaving) 06.58.30 Quit Judas_PhD (Quit: This is a quitting message) 06.59.11 Join ReimuHakurei [0] (~reimu@74.112.212.15) 07.00.48 Join xxcv [0] (~null@c211-30-174-99.carlnfd1.nsw.optusnet.com.au) 07.06.53 Quit UnclePervyJesus (Ping timeout: 260 seconds) 07.12.30 Join ReimuHakurei_ [0] (~reimu@74.112.212.15) 07.14.49 Quit ReimuHakurei (Ping timeout: 245 seconds) 07.33.15 Join timccc [0] (~timccc@112.166.15.141) 07.33.41 Join n1s [0] (~n1s@nl118-174-240.student.uu.se) 07.33.41 Quit n1s (Changing host) 07.33.41 Join n1s [0] (~n1s@rockbox/developer/n1s) 07.42.55 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 07.42.56 # user mayaaren396 in the forums seems like a spammer 07.43.48 Quit factor (Read error: Connection reset by peer) 07.46.48 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 07.55.27 Join ReimuHakurei__ [0] (~reimu@74.112.212.15) 07.55.48 Quit ReimuHakurei_ (Read error: Connection reset by peer) 08.00.38 Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 08.06.36 Join evilnick_ [0] (~evilnick@cpe-24-193-43-185.nyc.res.rr.com) 08.07.27 Join fyre^OS [0] (~nnscript@cpe-69-203-144-35.si.res.rr.com) 08.09.53 Quit evilnick (Ping timeout: 245 seconds) 08.09.54 Quit fyrestorm (Ping timeout: 260 seconds) 08.10.29 Quit kadoban (Ping timeout: 260 seconds) 08.25.10 *** Saving seen data "./dancer.seen" 08.40.11 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 08.46.14 Join Unit193 [0] (~Unit193@cpe-24-166-59-166.neo.res.rr.com) 08.47.55 Join ender` [0] (krneki@foo.eternallybored.org) 08.49.46 Quit Strife89 (Quit: Bed) 08.50.40 Quit MethoS- (Remote host closed the connection) 08.52.04 Quit advcomp2019 (Ping timeout: 276 seconds) 08.52.20 Quit simonrvn (Ping timeout: 240 seconds) 08.52.27 Part Unit193 08.53.19 Join simonrvn [0] (simon@211.59-ppp.3menatwork.com) 08.53.49 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 09.02.48 Quit TheSeven (Ping timeout: 245 seconds) 09.08.27 Quit eWill (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630]) 09.11.50 Quit antil33t () 09.14.08 Join Rob2223 [0] (~Miranda@p4FFF32D6.dip.t-dialin.net) 09.14.14 Join advcomp2019 [0] (~advcomp20@97-114-234-88.sxcy.qwest.net) 09.14.16 Quit advcomp2019 (Changing host) 09.14.16 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 09.17.41 Quit Rob2222 (Ping timeout: 255 seconds) 09.21.31 Join petur [0] (d408b802@rockbox/developer/petur) 09.24.24 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 09.26.43 Join kevku [0] (~kevku@2001:7d0:0:f000::135d) 09.28.32 Join LinusN [0] (~linus@rockbox/developer/LinusN) 09.30.06 Quit n1s (Quit: Lämnar) 09.43.52 # god damn spammers 09.44.08 # Fricking loads of them at the moment 09.53.04 # maybe there should be a better captcha? 09.54.01 # One that isn't always the same would be a start 09.56.37 # btw, on first call the capture is not rendered correct 09.57.09 # (and i don't like graphical captchas. Somthing like "how many is three plus four?" is also good) 10.00.18 # Yeah, I know 10.00.24 # But I can't do anything about this 10.00.46 Join Kitr88 [0] (~Kitarist@BSN-182-117-76.dial-up.dsl.siol.net) 10.00.47 # scorche: Could you have a look at fixing/changing the forum captcha? 10.01.05 # The current one is a) broken on first try and b) always asks the same thing 10.01.19 # I find it strange that the Lyre project has a binary copy of elftosb2 in their svn, is this allowed ? 10.01.34 # We've just had a big increase in spammers, maybe they just worked it out 10.03.00 Quit JdGordon (Ping timeout: 240 seconds) 10.04.08 Quit Kitar|st (Ping timeout: 255 seconds) 10.04.53 Quit Kitr88 (Ping timeout: 240 seconds) 10.05.31 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 10.07.46 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 10.07.47 Join Kitar|st [0] (Kitarist@BSN-142-68-37.dial-up.dsl.siol.net) 10.25.11 *** Saving seen data "./dancer.seen" 10.25.55 Join mt [0] (~mt@41.233.153.220) 10.32.09 # aaargh, more of the bastards 10.43.30 Quit simonrvn (Quit: ZNC - http://znc.sourceforge.net) 10.43.56 # AlexP, do you have direct access to the files for the forum? I don't know the SMC-Forum, but I think shouldn't be a big issue to find out whre the captcha-code is generated and hack this to generate a realy random code. As quick'n'dirty-solution for the actuall spammer-problem 10.47.14 Join simonrvn [0] (simon@211.59-ppp.3menatwork.com) 10.47.25 # aren't these spammers human? 10.47.43 # i think that they are bots 10.49.36 # oh, i thought the forum-files are in svn somewhere under www or so. But it seems that i was wrong 10.53.13 # yes, the forum is hosted on a different machine ran by scorche 11.04.00 Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz) 11.04.59 Part timccc 11.27.25 Join hebz0rl [0] (~hebz0rl@dslb-088-065-219-254.pools.arcor-ip.net) 11.42.35 Quit mt (Ping timeout: 255 seconds) 12.03.50 # Stummi: No, I don't have any access 12.04.29 # Bagder: I'm not sure - the captcha is broken (it always gives the same question), so if someone found that out it'd be easy to get the bots to do it 12.04.43 # Either way, it'd be nice to have a working one :) 12.12.35 Quit kevku (Ping timeout: 260 seconds) 12.13.49 Join sampattuzzi [0] (~sam@128.232.133.246) 12.14.29 Quit sampattuzzi (Quit: Ex-Chat) 12.14.51 Join sampattuzzi [0] (~sam@128.232.133.246) 12.16.17 # AlexP: banjia26 12.16.24 Join kugel [0] (~kugel@rockbox/developer/kugel) 12.16.25 # already done :) 12.16.34 # good :) 12.20.54 # Hello people of rockbox. I'm trying to debug some USB issues which I reckon are due to rockbox not handleing I/O errors correctly. Could somebody point me to the correct section of the usb stack and possibly relevant documentation for the USB spec? 12.21.46 Join MethoS- [0] (~clemens@134.102.106.250) 12.25.12 *** Saving seen data "./dancer.seen" 12.26.19 Join InsDel [0] (~haqr.net@unaffiliated/insdel) 12.27.46 # sampattuzzi: You're probably looking for SCSI specs here 12.28.06 # And in the rockbox code, firmware/usbstack/usb_storage.c 12.28.38 # gevaerts, cool, I will take a look at that, see if it makes any sense. 12.28.45 # What I would do is start with USB tracing (if you're on linux, wireshark can do that) of both the OF and the rockbox code 12.28.46 # you might get more by talking to us about what issues you've got, and why you think there's a problem with our handling 12.29.01 # If you manage to get such traces, please attach them to your flyspray task :) 12.29.49 # The main problem is that I've never been able to test these things due to a lack of suitably broken hardware 12.30.15 # gevaerts, out of interest, I noticed lots of logf() calls in the code but couldn't find a way of enabling them in the documentation. 12.30.47 # logf.h sort of explains it ;) 12.31.02 # sampattuzzi: enable the "#define LOGF_ENABLE" near the top of the source file, then pick "Advanced" when configure asks, and then enable logf there 12.31.59 # Torne: context is FS#10873 12.32.24 # gevaerts, thanks, I was just about to post a link. 12.32.56 # ah 12.40.17 Quit InsDel (Read error: Connection reset by peer) 12.44.32 # Ah, I could do with that new linux kernel patch. The build is making my system sloow. 12.45.08 # sampattuzzi: I usually run something like nice ionice -c 3 make to build stuff 12.45.15 # better than nothing ;) 12.46.07 # bzed, cheers, I'm giving that a go now. 12.51.27 Quit sampattuzzi (Ping timeout: 255 seconds) 12.52.00 Quit xxcv () 12.52.47 # ah, he's gone 12.52.57 # i was gonna point out there's a tiny shell script that does exactly the same thing as that patch 12.53.02 # without needing a new kernel :) 12.54.47 Join dfkt [0] (dfkt@unaffiliated/dfkt) 12.59.19 Join jhMikeS [0] (~jethead71@99.29.196.3) 12.59.20 Quit jhMikeS (Changing host) 12.59.20 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 12.59.20 Quit _jhMikeS_ (Disconnected by services) 13.36.40 Quit bluebroth3r (Ping timeout: 265 seconds) 13.36.57 Join DerPapst [0] (~Alexander@wlan-nat-24.fh-friedberg.de) 13.38.11 Join bluebrother [0] (~dom@g226069017.adsl.alicedsl.de) 13.38.11 Quit bluebrother (Changing host) 13.38.11 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 13.43.20 Quit kugel (Ping timeout: 272 seconds) 13.44.22 Join timccc [0] (~timccc@112.166.15.141) 13.45.26 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 13.46.39 Join mt [0] (~mt@41.239.54.89) 13.47.07 Join sampattuzzi [0] (~sam@128.232.133.246) 13.49.40 # gevaerts, I obviously missed a step, what did you say I had to do in the logf.h file? 13.50.08 # in logf.h, nothing 13.50.24 # In the source file where you want logging, look for "#define LOGF_ENABLE" and enable it 13.51.53 # And then do an (A)dvanced build 13.51.54 # ah, okay, that's what I missed. Excuse my ignorance. 13.52.40 # I did the second part. 13.54.03 Quit Rob2223 (Read error: Connection reset by peer) 13.54.20 Quit Bawitdaba (Read error: Connection reset by peer) 13.54.34 Join Bawitdaba [0] (~Sphinx@cpe-74-70-40-135.nycap.res.rr.com) 13.54.39 Join Rob2222 [0] (~Miranda@p4FFF32D6.dip.t-dialin.net) 14.01.55 # Okay, got myself a trace and uploaded it to the bug. Can't work out what it's doing though. 14.02.03 # http://www.rockbox.org/tracker/task/10873?getfile=22927 14.02.55 # A USB-level trace would be much more interesting I think, especially if you have both rockbox and the OF 14.03.48 # In what sense? 14.04.52 # A trace from the linux side then? 14.05.05 # yes, e.g. using wieshark 14.05.09 # *wireshark 14.06.59 Join n1s [0] (~n1s@rockbox/developer/n1s) 14.08.43 Join jfc^2 [0] (~john@dpc6682208002.direcpc.com) 14.09.20 Quit scorche (Disconnected by services) 14.09.27 Join scorche` [0] (~scorche@rockbox/administrator/scorche) 14.09.37 Join tchan1 [0] (~tchan@c-69-243-144-187.hsd1.il.comcast.net) 14.10.59 Quit jfc^3 (Read error: Operation timed out) 14.12.49 Quit tchan (Ping timeout: 245 seconds) 14.14.05 # hm... did anyone else ever have the idea of porting rockbox to PC style platforms? 14.14.45 # i recently got my hands on two really old laptops... a thinkpad that i modded into a serial terminal using linux 14.14.49 # and now i've got this old 14.15.31 # Armada 1700 here and kinda thought it would make a nice jukebox with rockbox on it 14.16.05 # theres nothing on the wiki at least that suggests there is an x86 port 14.16.36 # amee2k: there's a simulator 14.16.55 # You should be able to do something based on the SDL application port 14.17.06 # its like a P2 200 in it 14.17.07 # which is a native build using libsdl, assumming you have a framebufer 14.17.25 # the windows 98 on it takes ages to load 14.17.46 # i could try install linux on it and see if the simulator works 14.17.54 # but a native port would be like 14.17.58 # infinitely superior 14.18.32 # Well, feel free to work on it 14.18.40 # it would also take a lot of work whereas compiling the sdl app takes a few minutes tops 14.19.03 # gevaerts: yeah... if i ever get the hang of this i might just do it 14.19.36 # what i'd find kinda ugly about just using the simulator is that you'd end up with the emulation screen on an X display 14.19.41 # instead of a real display 14.20.12 # and i'm not sure if i can get any useful performance out of a slow processor like that 14.20.15 # You can use SDL on a framebuffer 14.20.36 # hmm... 14.20.43 # * amee2k ponders 14.22.34 # so i'd basically package an embedded linux as bootloader lol 14.25.13 *** Saving seen data "./dancer.seen" 14.27.57 Quit antil33t (Read error: Connection reset by peer) 14.28.07 Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz) 14.28.52 Join designate72 [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 14.30.54 Quit sampattuzzi (Ping timeout: 255 seconds) 14.44.57 Join TheLemonMan [0] (~lem0n@151.62.150.229) 14.45.55 Join Strife89 [0] (~Strife89@adsl-80-128-22.mcn.bellsouth.net) 15.07.28 Join sampattuzzi [0] (~sam@128.232.133.246) 15.07.51 Join komputes [0] (~komputes@ubuntu/member/komputes) 15.07.56 # mmmh, i'll first see if i can fix the ipod and play around with the plugin api. if i can't even get that in my thick head, not much point in trying a port >_< 15.10.30 # porting to native x86 is going to involve a *reasonable* amount of specialist x86 knowledge 15.10.37 # to implement, say, context switching 15.11.14 # i don't want to stop you but you may find it easier and more useful to just get the SDL version on an absolutely minimal linux distro 15.11.20 # The advantage is that such knowledge is reasonably widespread and things are well documented 15.11.26 # Well, true 15.11.50 # but you'd still need to write drivers and stuff 15.11.52 # a tiny linux distro consisting of basically just a kernel and a copy of rockbox with libsdl compiled to use the framebuffer, though 15.12.03 # is going to boot in a comparable time to a native rockbox port 15.12.09 # but you have to do *way* less to get it running 15.12.30 # yeah, what gevaerts said. i don't need to reverse engineer the platform first 15.12.36 # so, yeah. if you really want to do it, go for it; but x86 is *really weird* 15.12.50 # even though the docs exist, you may be underestimating just how weird it is 15.12.53 # :) 15.12.55 # also, i understand it that rockbox assumes a plain memory model so no need to deal with segmentation or paging 15.12.57 # Of course you *can* reverse engineer it, and only look at documentation when you really get stuck :) 15.13.10 # amee2k: you can't avoid dealing with segmentation on x86, at least in a minimal way 15.13.23 # and you would probably want to write a pagetable anyway 15.13.36 # Torne: well, yeah. you set up three segments that span the entire available memory and leave it at that 15.13.49 # i did some real mode os deving when i was in school, maybe 6 or 7 years ago 15.14.07 # make it a payload for coreboot and flash to the bios chip! 15.14.08 # it was kinda cool, but i didn't get too much into PM stiff 15.14.10 # you don't need to do anything *complicated* with the MMU but it's probably nicer to have it enabled and make a fixed virtual memory map 15.14.25 # we do that on the ARM platforms we support that have an MMU 15.14.27 # n1s: does coreboot support such old laptops? :) 15.14.41 # hmmm thats an interresting idea actually 15.14.51 # to deal with awkward physical memory mappings 15.15.04 # gevaerts: it hardly supports anything so you will still have all the fun porting to do :) 15.15.27 # iirc, handling the memory stuff kinda was what got me stuck with protected mode stuff back then 15.15.54 # well, i was about to put a multiboot header on the kernel thingy and use grub to load it 15.16.01 # but anyway; the advantages I can imagine of running rockbox natively on x86 versus running it under linux is virtually zero 15.16.16 # that'd dump me right into protected mode with at least a half decent memory layout provided 15.16.16 # for a sufficiently small linux. 15.16.58 # hehe 15.17.18 # these days small and linux is sort of a contradiction unless you really want to start a distro from scratch 15.17.28 # er, why? 15.17.36 # for the serial terminal mod on the thinkpad i tried to fit linux on a 128M flash card 15.17.39 # forget it :P 15.17.51 # i have several working linux systems that fit in 4MB 15.17.58 # maybe one or two that fit in 2MB 15.18.14 # yeah, but support for them is awkward, and they're usually specialized 15.18.23 # you would only need a kernel, busybox to handle boot/init, and rockbox and the libraries it uses (SDL) 15.18.28 # I'd be surprised if that came to more than 16MB 15.18.29 # so you'd effeectively end up forking the distro and modifying it for your stiff 15.18.31 # stuff* 15.18.32 # you could make it a ramdisk image, even 15.18.56 # no, this is not using some specialised system 15.18.58 # amee2k: for small embedded things you don't need to complicate things and use a "distro" 15.19.01 # yeah... thats kinda what i meant by making a distro from scratch 15.19.13 # You don't hvae to make it from scratch 15.19.16 # OE builds it for you 15.19.24 # "OE" ? 15.19.24 # gevaerts, I'm looking at the wireshark traces right now and they appear completely different. OF shows only protocol USB and info URB_BULK whereas rockbox has a lot of USBMS and varied info. 15.19.33 # openembedded 15.19.42 # does that work? 15.19.45 # of course 15.19.49 # why wouldn't it work? 15.19.51 # buildroot should also be decent 15.19.55 # i looked into emdebian but its a pile of wank 15.19.58 # gevaerts, would you like me send them to you in some format? 15.20.13 # sampattuzzi: can you attach them to the bug report? 15.20.16 # they don't even have a precompiled 486 kernel lol 15.20.20 # no it isn't. 15.20.27 # and why would you have precompiled kernels for embedded systems? 15.20.29 # that would be mad 15.20.33 # gevaerts, which would be the best file format, they are very long. 15.20.36 # anyway. this is kinda offtopic. 15.20.48 # feel free to try and port to native x86 if you want 15.20.55 # lol 15.20.55 # gevaerts, flat text would seem a little inaccessible. 15.21.04 # but I seriously think there will be no real benefit over using linux/sdl 15.21.11 # sampattuzzi: native wireshark saves, compressed 15.21.15 # well, i'll play around with it on the ipod and see how it goes 15.21.18 # if you don't know how to make a sufficiently small linux then that's a different problem, unrelated to rockbox :) 15.21.27 # i can show you, if you ask some other time ;) 15.22.16 # that would be cool so i might just take you up on that sometime 15.22.18 # :) 15.23.59 Join evilnick_B [0] (0c140464@rockbox/staff/evilnick) 15.25.13 # the interesting and rockbox-relevant part, then, would be getting the RaaA-on-SDL done nicely 15.25.31 # (rather than running the simulator) 15.25.51 # you could develop/debug/test that on a full linux for convenience 15.26.05 # hehe yeah 15.26.20 # the sdl app already works although it's not much different from a touch sim 15.26.33 # i've been thinking about a convenient way to update the firmware without the device acting as usb device 15.26.40 # n1s: yeah, i meant making it "nice" 15.26.50 # ah 15.27.01 # i.e. keyboard shortcuts, proper filesystem scanning, etc 15.27.07 # some of the same issues we have on android, i guess 15.27.08 # well, it should work in full screen mode, obviously 15.27.22 # and the configuration menu would probably need some way to configure the keymap 15.27.58 # for a PC booting off an intenral hard disk updating the firmware is easy.. just copy it over 15.28.04 # though that can stay in a header file for the first try 15.28.06 # i think RaaA as it is would work *better* for a dedicated system's only UI than it works as a regular desktop app 15.28.13 # n1s: yes, undoubtedly 15.28.29 # Torne: yeah, but you need to get the hard drive out and on a usb adapter 15.28.36 # every time you update it 15.28.54 # until you got it working enough so you can upload updates via USB 15.29.28 # amee2k: can't you run a shell on your busybox thing to copy stuff via usb? 15.30.09 # you wouldn' tneed to do anything to make usb work if it was running the linux kernel 15.30.12 # i'm not sure if you can make a USB host controller act as a device end too 15.30.12 # you just plug in a usb stick 15.30.16 # you can't. 15.30.35 # yeah, i kinda expected it won't work 15.31.13 # i could make a USB to serial bridge with an avr controller, but the transfer rate would drag ass 15.31.35 # yah. or if you used linux, then USB host would Just Work and you could use any usb storage device. 15.31.35 # although for early phase debugging you probably want to run it in a VM 15.31.39 # most uarts top out at something like 115.2 kbaud 15.31.44 # also, you could have networking 15.31.47 # and thats a tough call for the AVR too 15.32.02 # you could just have a button that ran a script in the host OS which downloaded and installed hte latest build from the internet :) 15.32.08 # rockbox does support a network stack? 15.32.23 # no, but it wouldn't need to 15.32.32 # linux has one. 15.32.35 # hmmm 15.32.37 # and busybox implements wget and friends 15.32.38 # i see 15.32.48 # so you just exit rockbox, run a shell script that downloads a new build and installs it, then run rockbox again 15.32.55 # you can automate that esaily :) 15.33.54 # hmmm i'm kinda starting to like the idea of layering it on a linux kernel 15.34.18 # there are lots of advantages. the only real advantage to doing it natively is it *might* boot slightly faster 15.34.32 # but we're likely talking a difference measured in a single digit number of seconds here, if that 15.34.54 # functionality and using existing device drivers are certainly big + points 15.35.26 # indeed 15.35.32 # especially using the linux VFS layer. i kinda understand rb natively only mounts a single file system at a time 15.35.41 # no, we support multiple mounts 15.35.52 # see devices with both internal storage and an SD slot 15.35.54 # like the fuze 15.36.08 # the simulator intercepts the raw file system calls and redirects them to appropriate C library calls, right? 15.36.20 # you wouldn' tbe using the simulator 15.36.26 # you'd be using the SDL app port 15.36.34 # they're similar, but not the same thing 15.37.22 # so you would use linux filesystem and harddrive functions 15.37.51 # indeed. rather than simulating a single device filesystem, the port would just have access to the entire host's FS 15.38.00 # so yeah, it would see whatever was mounted on the linux VFS. 15.38.26 # things like mounting USB devices and so on can just be don eby the host, with busybox udev scripts to automount inserted storage devices, etc 15.39.27 # anyway, if you wanted to do something like this a good start would be experimenting with the sdl port on a regular linux system 15.39.42 # just fire it up and try using it and see what works well and what doesn't :) 15.39.59 # cutting the host linux down to the bare minimum can be done seperately later 15.41.57 # hmmm 15.43.02 # well, you might want to try specifically getting it to run fullscreen on the framebuffer console with SDL. 15.43.04 Quit TheLemonMan (Quit: free(me)) 15.43.05 # rather than in a window under X 15.43.19 # but that can (and should) still be done on a regular linux distro, just don't run X. 15.43.33 # i've got my projects desk full of ipod and battery charger parts right now 15.43.36 # you can debug with a real debugger when stuff goes wrong, there, which helps a lot ;) 15.43.43 # sampattuzzi: thanks. I'll have a closer look later today 15.43.57 # which will hopefully improve when the fucking flash card for the pod finally arrives >:| 15.44.10 # then i'll install debian on the lappy 15.44.17 # gevaerts, it all looks very confusing but I would love to know more about how it's working. 15.44.50 # i'm not too fond of the idea of killing X on my desktop 15.45.01 # too much crap running that i don't want to kill along with it 15.46.03 Nick Strife89 is now known as Desk-Strife89 (~Strife89@adsl-80-128-22.mcn.bellsouth.net) 15.46.25 # sampattuzzi: the annoying thing is that wireshark doesn't seem to have nice decoding for UMS yet 15.46.45 # amee2k: well you don't have to kill it, just switch to a tty ;) 15.46.58 # as long as your console is a framebuffer console 15.47.08 # hmmm 15.47.23 # hm, it should 15.50.59 # bertrik: any progress on fuze+ ? 15.51.06 # no 15.51.52 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 15.51.55 Quit antil33t (Read error: Connection reset by peer) 15.52.04 Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz) 15.55.47 Join ReimuHakurei_ [0] (~reimu@74.112.212.15) 15.56.25 # I'm seeing some pin control registers accessed in the second elf, I don't know yet what is the use 15.57.39 Quit ReimuHakurei__ (Read error: Connection reset by peer) 15.57.50 Quit MagusG (Ping timeout: 276 seconds) 16.03.55 # I think the second elf file basically deals with clocks and ram 16.06.39 # ok, the chumby command file was structured with several parts each initing something: power, clocks, sdram 16.09.32 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 16.11.38 # sampattuzzi: if you open the apple trace, then "Mark All Packets" (Edit menu), then unmark the four last GET CONFIGURATION lines (nrs 47,48,49,50), save as, select "marked packets only", then save, and open the new file, you'll get *much* better decoding 16.16.08 # sampattuzzi: anyway, that OF trace will be *very* helpful in understanding what we're supposed to do 16.16.46 # gevaerts, brilliant! I'm glad we're getting somewhere. 16.22.22 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 16.25.00 # AlexP: ban chong11chong 16.25.17 *** Saving seen data "./dancer.seen" 16.33.45 Quit sampattuzzi (Ping timeout: 255 seconds) 16.35.30 Join panni_ [0] (hannes@ip-178-203-77-160.unitymediagroup.de) 16.36.28 Quit petur (Quit: Page closed) 16.38.34 Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) 16.39.46 Join kevku [0] (~kevku@2001:7d0:0:f000::135d) 16.42.38 Join sampattuzzi [0] (~sam@128.232.133.246) 16.47.17 Join toffe82 [0] (~chatzilla@maf.wirelesstcp.net) 16.47.39 # omg :o So much initialisation code for DRAM ! 16.50.42 Join bertrik_ [0] (~bertrik@rockbox/developer/bertrik) 16.50.43 Quit bertrik (Read error: Connection reset by peer) 16.57.36 Quit sampattuzzi (Ping timeout: 255 seconds) 16.59.36 Quit mortalscan (Remote host closed the connection) 16.59.52 Join mortalscan [0] (~mortalsca@109.169.55.155) 17.00.05 Nick bertrik_ is now known as bertrik (~bertrik@rockbox/developer/bertrik) 17.01.02 Part LinusN 17.04.52 Quit TheSeven (Ping timeout: 240 seconds) 17.11.18 Join sampattuzzi [0] (~sam@global-1-100.nat.csx.cam.ac.uk) 17.11.30 Join kugel [0] (~kugel@rockbox/developer/kugel) 17.12.57 Quit {phoenix} (Remote host closed the connection) 17.16.51 Nick tchan1 is now known as tchan (~tchan@c-69-243-144-187.hsd1.il.comcast.net) 17.17.00 Quit tchan (Changing host) 17.17.00 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 17.22.51 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 17.23.50 # saratoga: done 17.26.25 # sampattuzzi: ping 17.27.39 Part Zagor 17.30.26 Quit robin0800 (Remote host closed the connection) 17.31.06 Quit sampattuzzi (Ping timeout: 260 seconds) 17.33.15 Join TheLemonMan [0] (~lem0n@62.98.144.175) 17.35.14 Join Topy [0] (~Topy44@g227209241.adsl.alicedsl.de) 17.38.09 Join sampattuzzi [0] (~sam@global-1-100.nat.csx.cam.ac.uk) 17.38.46 # gevaerts, I'm here now, what did you want to say? 17.39.01 Quit T44 (Ping timeout: 245 seconds) 17.39.11 # sampattuzzi: I posted a quick patch. Could you try it? 17.39.16 # Although I suspect it's not enough 17.39.49 # okidoky 17.47.12 # gevaerts, okay well it's not mounted so I will do a trace for you. 17.47.49 Quit riotz (Read error: Operation timed out) 17.52.45 # wtf, the fuze+ firmware seems to have several dram settings ! 17.52.53 Join riotz_ [0] (riot33r@gateway/shell/shellium.org/x-dlkhklpspgrvalsi) 17.53.58 # gevaerts, uploaded 17.54.07 # Thanks 17.56.50 # pamaury: they could use different ram chips in the same model, other players do this 17.57.25 # there are 4 different settings, it's hard to tell the difference, some really low-level settings 17.57.37 # I don't know how they choose yet 17.58.40 # if it's runtime selected somehow, we should probably do that too or risk some players not working 17.59.23 # or jus use the most lax of the sets of settings, as that should work for all chips and efficiency is not too important at this stage 18.02.17 # well, perhaps we can just reuse the same init code 18.02.27 # after all, the sb format is quite flexible 18.02.37 # we can just replace the relevant part of it :) 18.03.08 # of course, we need to check what the init code does, especially for virtual memory, interrupts and so one 18.03.10 # *on 18.07.52 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 18.14.25 # hum, there are some tables in the imx23 document, I'll have to check if the values match 18.17.41 # oops, there is a unknown register ! 18.25.18 *** Saving seen data "./dancer.seen" 18.25.34 Join Strife89TX [0] (~cstrife89@207.144.201.128) 18.32.56 # OK....tonight i will investigate the compatibility of multiple mods we have done on the forums with new version of SMF to evaluate an upgrade 18.33.56 # depending on the results of that evaluation, i might or might not take the forums offline tomorrow and perform the upgrade 18.34.32 # (note: this is also dependent on how many 2500+ word final papers i need to work on this weekend) 18.34.36 Nick scorche` is now known as scorche (~scorche@rockbox/administrator/scorche) 18.36.04 # at the same time, i will look at upgrading a few other services on the server (might as well), so the themesite might be affected in some manner as well 18.37.53 Quit ReimuHakurei_ (Ping timeout: 240 seconds) 18.40.19 # Samsung put ways more encryption in themes than in fw and bootloader .-. 18.41.22 # lulz 18.41.44 # Perhaps artwork is more important to them than a commercial firmware? 18.41.44 # heaven forbid people personalize their players 18.42.23 # maybe they never heard of the chain of trust 18.42.30 # Art could be stolen for other works, I guess. 18.43.19 Quit Guinness (Read error: Connection reset by peer) 18.44.31 # yes but if you can break into the firmware that decrypts the art, no amount of encryption on the art is effective as you can either decrypt it the same way as the firmware does or dump the decrypted data 18.45.50 Join domonoky1 [0] (~Domonoky@agsb-4d049afe.pool.mediaWays.net) 18.46.45 # UMS error handling is a mess 18.46.57 Quit domonoky (Ping timeout: 245 seconds) 18.52.23 Quit DerPapst (Quit: Leaving.) 18.52.25 # error handling in rockbox is a mess 18.52.50 # true that 18.52.52 # Maybe, but usually it's not because someone did weird things in a spec 18.53.40 # ah, you mean the protocol error handing :) 18.53.52 # * gevaerts claims that a bad sector is *not* a protocol error and therefore an endpoint HALT is *not* an appropriate response 18.54.13 # it's a sense error 18.54.57 # Well no, it returns an error code in the sense data :) 18.55.08 # err, yeah 18.55.14 # but not in the transport 18.55.16 # But in USB it also involves stalling the endpoint, which messes everything up 18.56.09 # yeah, ums is really different from other usb protocols 18.56.17 # hm 18.56.24 # Maybe there's an alternative solution 18.56.38 # to what ? 18.56.57 # My guess is that the stall is there because you send less data than expected, which would otherwise confuse the host 18.57.38 # But according to my reading of the UMS spec, that stall is optional 18.57.52 # I don't have the spec in mind 18.58.29 # So in theory, we could just send enough data (all zeroes or something, or just random junk) instead 18.58.47 # The host should know that this data is junk because we still return an error code 18.59.08 # The problem I have right now is that after a stall the CSW doesn't always get through 18.59.16 # It sometimes gets eaten by the stall itself 19.00.35 # And that's not at all trivial to fix 19.01.54 # gevaerts, how does tho OF deal with it? 19.02.29 # By having a different usbstack design :) 19.03.50 # okay, I didn't realize they could be that different. 19.05.20 # scorche: can we get that comments/blog software for the front page while you're at it ;) 19.06.46 # bertrik: perhaps we should setup a wiki page for our firmware analysis ? 19.07.09 # hvvbb 19.07.16 Join DerPapst [0] (~Alexander@p5DE5B254.dip.t-dialin.net) 19.10.52 # scorche: ta 19.11.13 Quit sampattuzzi (Read error: Connection reset by peer) 19.14.02 # gevaerts: my disk is really nice. it has: 1. sectors that can't be written and can't be read, 2. sectors that can be written but can't be read, 3. sectors that can both be written and read successfully, but don't return the data that was written :) 19.14.16 # but I haven't yet spotted read-only blocks 19.14.29 # TheSeven: yes, I want that disk :) 19.15.04 # TheSeven: nice disk :) 19.15.17 # also, there are both consecutive and scattered bad sectors 19.15.31 # the scattered ones have almost identical distance in between them 19.15.55 Join sampattuzzi [0] (~sam@global-1-100.nat.csx.cam.ac.uk) 19.16.09 # sampattuzzi: could you try the patch I just uploaded? 19.16.36 Quit TheLemonMan (Quit: free(me)) 19.16.51 # gevaerts, certainly 19.17.36 Join Horscht [0] (~Horschti@xbmc/user/horscht) 19.18.33 # sampattuzzi: oh, wait. That patch has some bits in there you don't want... 19.18.48 Join krabador [0] (~krabador@host26-168-dynamic.116-80-r.retail.telecomitalia.it) 19.18.52 # There are two lines that check for sector 10000. Remove those 19.19.02 # (they're for local simulation of bad sectors) 19.20.33 Quit DerPapst (Read error: Connection reset by peer) 19.20.36 # 47 and 58? 19.21.03 Join DerPapst [0] (~Alexander@p5DE5B254.dip.t-dialin.net) 19.21.16 # In the patch, yes, but renove them from usb_storage.c after patching 19.21.24 # Otherwise I suspect the patch won't apply 19.21.43 # indeed 19.27.21 # still no luck 19.29.35 # Weird 19.29.43 # gevaerts, new trace for you. 19.30.31 # sampattuzzi: that looks a bit short 19.30.39 # Did you capture the correct bus? 19.30.59 # let me just check that. 19.32.31 # gevaerts, yep, it only produces 21 new packets when I plug it in. Then that's it. 19.33.46 # sampattuzzi: dmesg should tell you which bus number is used. 19.34.28 # e.g. "usb 2-1: new high speed USB device using ehci_hcd and address 33" means bus 2 19.38.01 # gevaerts, that should be better now. 19.40.39 Join stoffel [0] (~quassel@p57B4D34C.dip.t-dialin.net) 19.42.05 # sampattuzzi: can you also provide dmesg output for that one? I don't see anything unexpected in the trace 19.43.47 # The read starting at packet 561 fails, which gets notified by 566, after which the host retrieves sense data (567/570) that indicate the error 19.44.01 # After that the host does a Test Unit Ready and then goes on reading somewhere else 19.44.04 Quit kugel (Remote host closed the connection) 19.45.12 # * gevaerts will look more after dinner 19.45.45 Quit krazykit (Ping timeout: 245 seconds) 19.45.53 # gevaerts, done, but enjoy you dinner first. 19.45.57 # *your 19.47.53 Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) 19.57.09 Quit sampattuzzi (Quit: Ex-Chat) 19.58.49 # saratoga: i am still working on finals so the fact that i hope to find any time to work on it this weekend is a miracle in and of itself ;) 20.02.08 # yes I figured so 20.06.21 Quit Strife89TX (Quit: Vamoose!) 20.06.34 Quit DerPapst (Read error: Connection reset by peer) 20.07.06 Join DerPapst [0] (~Alexander@p5DE5B254.dip.t-dialin.net) 20.13.28 Join InsDel [0] (~haqr.net@unaffiliated/insdel) 20.25.19 *** Saving seen data "./dancer.seen" 20.26.45 Quit factor (Read error: Connection reset by peer) 20.27.03 Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 20.33.44 # * gevaerts is confused 20.35.37 Join {phoenix} [0] (~dirk@p57AA3B8E.dip.t-dialin.net) 20.38.04 Join bmbl [0] (~bmbl@unaffiliated/bmbl) 20.38.25 Quit designate72 (Quit: Leaving) 20.49.04 Join designate72 [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 20.55.43 Quit Llorean (Read error: Connection reset by peer) 20.56.57 Join Llorean [0] (~DarkkOne@99-68-45-56.lightspeed.hstntx.sbcglobal.net) 21.11.05 # n1s: I don't think make install makes a zip 21.13.05 Quit bmbl (Quit: Verlassend) 21.15.08 # i think it assembles a local .rockbox folder, then does a bunch of file copies into the simdisk folder without bothering to zip it first 21.19.27 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 21.29.07 Quit jgarvey (Quit: Leaving) 21.41.59 # New commit by 03pamaury (r28731): sbinfo: fix crazy condition to avoid empty elf file generation (it is reversed) 21.42.14 # zagor: Did you ever sign up for the Rockbox gmail calendar? 21.42.58 # what is the rockbox gmail calendar ? 21.43.35 # pamaury: It will be to do things like have release schedules etc. 21.43.46 # I posted to the dev list about it, let me find the link 21.43.59 # * Dreamxtreme looks 21.44.11 # * Dreamxtreme really should sign up for the mailing lists 21.44.24 # really ? I can't remember seeing such a mail... 21.44.31 # r28731 build result: All green 21.44.36 # but I want to join :) 21.44.59 # pamaury: http://www.rockbox.org/mail/archive/rockbox-dev-archive-2010-10/0214.shtml 21.45.20 # pamaury: I've just tried to get rockbox@gmail.com, but it is taken :( 21.45.39 # Anyone any preference for what I should get? 21.46.31 # rockbox-dev ? 21.47.30 # I'll try that 21.48.26 # wtf 21.48.36 # That isn't available either 21.48.44 # well, rockbox.dev isn't 21.49.36 # rockbox-committers ? 21.49.46 # rockbox-rule-the-world ? :) 21.50.58 # hehe :) 21.51.57 # bertrik: I put some firmware information on this wiki page: http://www.rockbox.org/wiki/SansaFuzePlusFirmware 21.52.41 # OK, it is rockbox.calendar for now 21.59.19 # * pamaury starts the analysis of the third elf file of the ___ section of the fuze+ firmware 22.00.21 Quit komputes (Read error: Connection reset by peer) 22.01.46 # are there any news regarding the "rockbox recognize some SD cards only sometimes in sansas" problem? 22.02.10 Quit Llorean (Changing host) 22.02.10 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 22.08.18 Join csh_ [0] (~chatzilla@88.241.182.31) 22.10.40 # hi again. i thought that since there is no fpu in mp3 players, can't we use fixed-point numbers instead of float and double? there are fixed-point arithmetic libraries for c and c++, and these libraries can do calculations of sin, cos, sqrt, etc. 22.12.13 # pamaury: rockbox.calendar@gmail.com 22.12.53 # Who has access to it ? 22.14.14 # pamaury: gevaerts and I (and the Swedes in time) have access to edit, everyone has access to view 22.14.27 # pamaury: That is gevaerts and I as "release managers" 22.14.36 # how do I access the calendar ? 22.14.48 # You can add it to your gmail calendar 22.15.19 # done 22.15.21 # nice 22.15.42 # Yeah :) 22.15.57 # We figured it is better to have to go via the release managers to change stuff 22.16.09 # csh_: yes, all rockbox codecs are in fixed point precision 22.16.14 # But this way, everyone can see the schedule in advance 22.17.26 # so, if i convert doubles and floats to fixed points, i can get enough performance from libmodplug, can't i? 22.18.04 # csh_: correct, that is the way codecs are ported to rockbox 22.18.58 # excellent, on free times i will work on it. thanks a lot saratoga 22.19.04 # no problem 22.19.14 # take a look at our existing codecs (or mod decoder) 22.19.21 # it should give you an idea how fixed precision works 22.19.27 # it is quite different then floating point 22.19.56 # ok, firstly i will look at it. thanks 22.20.16 Quit csh_ (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630]) 22.21.51 Quit t0rc (Quit: Give someone code, help them with one project. Teach someone to code, help them rule the world.) 22.22.06 # it seems there is some code duplication in the fuze+ init code 22.24.05 # is there a patch somewhere for the code from last summer's TTS project? 22.25.22 *** Saving seen data "./dancer.seen" 22.27.25 # Was there any code? 22.29.30 # wiki says he converted it to fixed point 22.31.19 # i think the memory alloc's that it (festival?) did turned out to be too unsuitable for conversion to static allocation so he basically gave up 22.31.30 Join ReimuHakurei [0] (~reimu@208.119.81.194) 22.31.34 # saratoga: make install did definitely make a zip at some point 22.31.49 # maybe it's changed but then i don't see why it should be so slow 22.32.46 # any arm expert here ? 22.32.57 # * n1s points to Torne 22.33.08 # what does this mean: MCR p15, 0, R0,c7,c10, 4 22.33.30 # I'm not really familliar with the arm internals, appart from basic instructions 22.33.31 # Bagder: about? 22.33.54 # yeps 22.34.01 # PM :) 22.34.13 # pamaury: that's a DSB 22.34.33 # everything on c7 is cache control 22.34.44 # what does DSB mean ? 22.34.50 # c10, 4 is data sync barrier, or on older arms drain write buffer 22.35.30 # (on older arms draining the write buffer was sufficient for a DSB) 22.36.05 # ok thanks, I think I need to find a good doc on this or read the arm manual 22.36.34 # it's all in teh ARM ARM 22.36.41 # just.. read an old version, if you have an old chip 22.36.44 # it's less confusing that way 22.37.13 # * Torne recommends DDI0100E for ARM9 and DDI0100I for ARM11 22.37.28 # the ARMv7 arm is way harder to follow 22.37.39 # it's an arm9 22.37.51 # rev E is easy to find on the internet, google for that number and pdf 22.37.52 # :) 22.38.07 Quit stoffel (Remote host closed the connection) 22.38.07 # and that version is a mere 811 pages, not too uch to take in ;) 22.39.59 # anyway, you need DSB when you're writing something to ram that you want to be visible outside the core proper, unless the memory is unbuffered 22.40.03 # or maybe i'm wrong, the install target in root.make does call buildzip with "zip -r0" as an arg but i now realized that someone made make install do target builds too now, right? 22.40.28 # it's just a writecombining buffer basically, but it's written back lazily so unless you DSB then other bus masters, or the ARM's own MMU, won't see the writes 22.40.34 # ok thanks 22.40.34 # well, aren't guaranteed to see the writes. 22.40.53 # you basically do it whenever you do a cache clean 22.41.10 # actually there are a bunch of these things in the code at the beginning so I need to figure out by myself :) 22.41.11 # except it also applies to memory that's mapped uncached but buffered 22.41.24 # Heh 22.41.29 # Well, it's probably using hte MMU 22.41.40 Quit designate72 (Remote host closed the connection) 22.41.48 # I haven't seen any mmu code so far but that might change 22.42.34 # which core is it specifically? 22.42.40 # i.e. is it one with an MMU or an MPU? 22.43.06 # ARM926EJ-S 22.43.19 # right, so that's an MMU 22.43.26 # so it will use it 22.43.32 # because otherwise you can't set up caching/buffering. 22.43.45 # ARMs that have an MMU don't have the protection unit's cache/buffer range registers 22.43.56 # you have to write pagetables to configure which memory is cached or bufferd. 22.44.28 # sounds sensible, then I'll have to find the code to see how the mmu is configured 22.44.43 # look for it setting cp15 register c2 22.44.47 # that's the base address of the pagetables 22.45.09 # also bit 0 in c1 turns the MMU on 22.45.16 # one or both of those should be easy to spot :) 22.45.32 # indeed 22.46.45 # it's probably very near where you are :) 22.47.05 # you have to DSB after writing pagetables 22.47.23 # the MMU isn't hooked up to the write buffer so it doesn't see pending writes ;) 22.47.52 # saratoga: you are correct, the make install just sends in a zip command for fun but never uses it 22.48.36 # hum, I see lots of accesses to c7, c10 22.48.39 # but none to c1 22.48.49 # or I missed one in the previous elf files 22.49.09 Join kadoban [0] (~mud@cpe-66-66-78-170.rochester.res.rr.com) 22.53.56 # is there a seperate bootloader/ 22.54.00 # it's possible the MMU init was done there 22.54.08 # and this code just relies on it already being in a known config 22.54.45 Quit efyx (Remote host closed the connection) 22.54.50 Join TheLemonMan [0] (~lem0n@ppp-175-144.98-62.inwind.it) 22.55.00 # we don't really know. There is probably a bootloader loading the .sb file; but the .sb file also contains some init code 22.55.23 # ah 22.55.39 # perhaps there is something in the imx23 doc :) 22.55.47 # the .sb is bootstrapped by the onboard rom 22.56.45 # I was wondering if maybe the bootloader was in the i2c eeprom on board the fuze+ 22.56.49 # Actually, I don't think the rom does more than reading the sb file and executing the instructions, so I must have missed it 23.00.10 # searching for addresses in that doc is just awful :| 23.00.35 # TheSeven: I find it quite easy on the contrary 23.00.41 # amsv2 is ARM926EJ-S so you should be able to reuse it's MMU setup 23.00.48 # you have a memory map at the end and a register list 23.01.15 # TheSeven: you are looking at the fuze+ firmware ? 23.01.19 # yeah, but i need to get the register name and search it in the rest of document to know what bit does what 23.01.39 # how do you think people do ? :D 23.02.33 Quit ReimuHakurei (Read error: Connection reset by peer) 23.02.48 Join ReimuHakurei [0] (~reimu@208.119.81.194) 23.03.07 # at which part of the firmware are you looking at ? 23.03.07 # it's pretty tiring :P and im not a hw geek too so i just reverse stuff w/o knowing what it does 23.03.43 # oh, im not looking at fuze firmware, im reversing my samsung player bootloader 23.03.50 # ok 23.09.30 # what would be the use of SSP at early boot stage ? 23.15.12 # power supply? 23.15.45 # or maybe communicate with the touchpad, turn off a led or something? 23.16.11 Join T44 [0] (~Topy44@f049064100.adsl.alicedsl.de) 23.16.31 # still can't tell, I haven't disassemble enough things, I just see that it does some intricate things to setup ssp :) 23.18.31 # what was the reason we still have directory cache off by default? 23.18.39 Join ReimuHakurei_ [0] (~reimu@208.119.81.194) 23.18.41 Quit ReimuHakurei (Read error: Connection reset by peer) 23.19.03 Quit Topy (Ping timeout: 245 seconds) 23.19.06 # saratoga: Something to do with it failing with large amounts of files? 23.19.11 # I can't remember 23.19.18 # I asked not long ago 23.19.49 # how large is large? 23.20.07 # pamaury, I'm seeing some difference in commands sent in sd-as3525.c and sd-as3525v2.c, do you know more about this? 23.20.31 # saratoga: I can't remember 23.20.34 # nope, I haven't touch as3525 except for the usb core 23.20.40 # HVSC might have been involved 23.20.52 # for example, for as3525, we try high speed mode only for v2 cards, while for as3525v2 it's done regardless of v1/v2 23.21.22 # pamaury: ssp usually involves dma, especially for sound 23.21.30 # pamaury: so it might just set it up early 23.21.46 # that's at booting stage, I would be surprised 23.21.53 # fuck, that's fuze+ code doesn't make anysense, it's writing a reserved bit ! 23.23.56 Quit ReimuHakurei_ (Read error: Connection reset by peer) 23.24.01 Join ReimuHakurei_ [0] (~reimu@208.119.81.194) 23.24.59 # in which register? 23.25.10 # various SoCs tend to extend ARM's CP15 stuff slightly 23.25.14 # AlexP: seems we agreed to enable it by default on the mailing list 6 months ago 23.25.43 # it's a clock register, not arm related as far as can tell 23.25.48 # ah 23.26.08 # saratoga: I'm all for it; I just vaguely remember some counter reason last time I asked 23.26.14 # Lt me check 23.26.23 # but that's a shame, it set/clear a reserved bit from the start routine and I just can't tell what it's doing 23.26.47 Quit Keripo (Quit: Leaving.) 23.27.00 # what FM tuner the fuze+ has ? 23.27.32 # the SansaFuzePlus page as a photo which says Si4703 23.27.58 # *has 23.29.40 # mine has a SI4703 on the I2C bus 23.30.25 # uhu its the same :D 23.31.00 # any idea why ata transfer speed would scale almost linearly with the transfer size? 23.32.02 Quit ReimuHakurei_ (Read error: Connection reset by peer) 23.33.40 Quit evilnick_B (Quit: Page closed) 23.34.54 # saratoga: From my log searching, various people just said that as far as they know dirchache fails if you have too many small files 23.35.02 # But I think this was all IIRC 23.35.20 # I *think* I tested with the HVSC with no issues 23.35.33 # But someone should check then enable IMO 23.35.46 # I think I unpacked HVSC three times on my clip 23.38.16 # gevaerts: With success, or did dircche fail? 23.38.39 # I *think* it worked 23.38.45 # hm, this may not have been the clip 23.38.53 # * gevaerts can't remember any details 23.38.58 # Yeah, I also think it did when I tried with one copy 23.40.50 # again writing to a reserved bit, there is something strange there 23.40.51 # It must be in the logs somewhere 23.40.51 # This is it, nobody has any concrete don't enable it, just a few "I think it might not have IIRC" type things 23.40.51 # I say we enable it personally 23.43.39 # yeah, llet's just do it 23.43.40 # if it breaks something horribly we'll, er, fix it. 23.43.40 # * gevaerts finds things 23.43.40 # Torne: Aye 23.43.40 # OK, apparently when I unpacked four copies of HVSC, dircache didn't work 23.43.48 # (on ipod video) 23.43.57 # Two worked 23.44.44 # http://www.rockbox.org/irc/log-20100828#22:35:29 23.44.44 # gevaerts: does it fail gracefully? 23.44.44 # n1s: well, I had to check if it was enabled 23.44.48 # So apparently, yes 23.45.38 # how many files is 4 copies? 23.45.47 # well, that sounds good 23.46.02 # yeah, 4 copies = stupid-amount-of-files 23.46.14 # and if it also failed gracefully, then just do it 23.47.49 Join marines [0] (~marines@marvin.uplink.cz)