--- Log for 11.12.110 Server: anthony.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 6 days and 23 hours ago 00.01.39 Quit yosafbridge (Ping timeout: 272 seconds) 00.06.15 Quit bertrik (Quit: :tiuQ) 00.07.22 Join yosafbridge [0] (~yosafbrid@li14-39.members.linode.com) 00.08.53 Quit simonrvn (Ping timeout: 240 seconds) 00.10.45 *** Saving seen data "./dancer.seen" 00.11.30 Quit ender` (Quit: The word 'politics' is derived from the word 'poly', meaning 'many', and the word 'ticks', meaning 'blood sucking parasites'. -- Larry Hardiman) 00.11.57 Quit tchan (Ping timeout: 265 seconds) 00.16.58 Quit kugel (Ping timeout: 245 seconds) 00.18.29 Quit evilnick_B (Quit: Page closed) 00.18.43 Quit {phoenix} (Remote host closed the connection) 00.24.52 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 00.25.32 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 00.38.07 Quit pamaury (Remote host closed the connection) 00.39.43 Quit casainho (Remote host closed the connection) 00.41.19 Join simonrvn [0] (simon@210.23-ppp.3menatwork.com) 00.52.44 Quit liar (Quit: Leaving) 00.58.10 Join kugel [0] (~kugel@rockbox/developer/kugel) 00.59.40 Quit GodEater (Read error: Operation timed out) 01.08.48 Join krazykit` [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) 01.09.00 Quit krazykit (Ping timeout: 265 seconds) 01.15.48 Join GodEater [0] (~bibble@cl-711.lon-02.gb.sixxs.net) 01.15.48 Quit GodEater (Changing host) 01.15.48 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 01.18.09 Quit Horschti (Ping timeout: 264 seconds) 01.36.24 Join saratoga [0] (9803c6dd@gateway/web/freenode/ip.152.3.198.221) 01.36.46 # what the hell, this rm file is detected as unsupported by the metadata parser, but playback STILL loads a (completely random) codec to try and decode it 01.37.05 Quit mc2739 (Quit: leaving) 01.37.45 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 01.38.05 # and grep tells me playback.c does not check the return value on get_metadata 01.38.08 # how is this possible 01.40.03 # is there anyone that knows how metadata parsing is supposed to work 01.42.24 Join kugel_ [0] (~kugel@g231106188.adsl.alicedsl.de) 01.42.36 Quit kugel (Disconnected by services) 01.43.10 Quit kugel_ (Remote host closed the connection) 01.43.20 Join kugel [0] (~kugel@rockbox/developer/kugel) 01.48.28 Quit hebz0rl (Quit: night) 01.49.33 Join shai_ [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 01.52.19 # hmm no maybe thats ok in buffering.c 01.53.23 Quit shai (Ping timeout: 260 seconds) 01.53.29 # ah got it 01.57.13 Quit kugel (Remote host closed the connection) 01.58.22 Quit t0rc (Quit: Give someone code, help them with one project. Teach someone to code, help them rule the world.) 01.58.33 Quit Judas_PhD (Quit: This is a quitting message) 01.59.59 # New commit by 03saratoga (r28788): Correct mistake in the RealMedia parser that prevented rejecting files with unsupported codecs. 02.01.56 # r28788 build result: All green 02.02.37 # woot 02.02.48 # rasher: no commit logging so that i get more test files to fix 02.03.29 # now commit i mean to say 02.04.03 # saratoga: cute - congrats on the quick fix too 02.04.38 # saratoga: 11541 looked like a really good patch. What would need to be done to try to get this patch into my custom build? Would I have to try to apply each piece manually? 02.10.46 *** Saving seen data "./dancer.seen" 02.15.44 Join shai__ [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 02.18.27 Quit GodEater (Ping timeout: 272 seconds) 02.19.04 Quit shai_ (Ping timeout: 245 seconds) 02.25.44 # the_Kyle: yes 02.26.13 # ej0rge: if you still have db problems let me know 02.27.28 # saratoga: will do 02.29.11 # Well, I'm up to the challenge, I guess. Should I resubmit against latest trunk if I can get it working? Seems it needs a bump. 02.32.23 Join CaptainKewl [0] (~captainke@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 02.32.41 # I would of course resubmit as a comment to 11541 rather than starting a new task for it. 02.32.50 Join [Saint] [0] (cbb802e9@gateway/web/freenode/ip.203.184.2.233) 02.33.11 Quit Rob2222 (Ping timeout: 240 seconds) 02.35.31 Quit dfkt (Quit: -= SysReset 2.53=- Sic gorgiamus allos subjectatos nunc.) 02.37.56 Quit mortalscan (Ping timeout: 265 seconds) 02.39.50 Quit [Saint] (Ping timeout: 265 seconds) 02.44.43 Quit BHSPitMonkey (Ping timeout: 260 seconds) 03.07.47 # how does one exit the android app? 03.12.08 Quit moos (Ping timeout: 260 seconds) 03.26.23 Quit factor (Ping timeout: 240 seconds) 03.26.30 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 03.29.21 Join GodEater [0] (~bibble@cl-711.lon-02.gb.sixxs.net) 03.29.25 Quit GodEater (Changing host) 03.29.25 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 03.35.19 Nick krazykit` is now known as krazykit (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) 03.36.19 Quit pixelma (Disconnected by services) 03.36.22 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 03.36.24 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 03.36.36 Quit amiconn (Disconnected by services) 03.36.37 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 03.36.39 Quit Sudos (Ping timeout: 255 seconds) 03.36.57 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 03.41.15 Join simabeis_ [0] (~simabeis@lobmenschen.de) 03.42.22 Join Sudos [0] (~windstar_@c-68-38-20-238.hsd1.nj.comcast.net) 03.43.49 Quit simabeis (Ping timeout: 255 seconds) 03.44.14 Join ZhangNing [0] (~ZhangNing@116.3.3.241) 03.45.46 Quit MethoS- (Remote host closed the connection) 03.50.19 Quit Judas_PhD (Quit: This is a quitting message) 03.51.04 # preglow: i don't think you can 03.52.54 Join T44 [0] (~Topy44@f049005073.adsl.alicedsl.de) 03.56.47 Quit Topy44 (Ping timeout: 240 seconds) 03.57.52 Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 03.58.17 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 04.01.22 Quit yosafbridge (Quit: Coyote finally caught me) 04.10.47 *** Saving seen data "./dancer.seen" 04.11.04 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.142) 04.24.22 Join JesusFreak316 [0] (~JesusFrea@pool-173-65-30-16.tampfl.fios.verizon.net) 04.33.08 Quit amiconn (Disconnected by services) 04.33.09 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.33.19 Quit pixelma (Disconnected by services) 04.33.21 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.33.24 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.33.29 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.37.04 Quit TheSeven (Ping timeout: 272 seconds) 04.40.15 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.42.48 Join Barahir_ [0] (~jonathan@frnk-590fd278.pool.mediaWays.net) 04.45.38 Quit krabador (Quit: Sto andando via) 04.46.16 Quit Barahir (Ping timeout: 264 seconds) 04.56.02 Quit sasquatch (Quit: WeeChat 0.3.2) 04.56.27 Join sasquatch [0] (~username@p4FF2DFDC.dip.t-dialin.net) 04.59.32 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 04.59.52 Quit efyx (Remote host closed the connection) 05.00.27 Quit fdinel (Client Quit) 05.04.53 Quit Bushmills (Ping timeout: 264 seconds) 05.14.19 Quit ZhangNing (Ping timeout: 240 seconds) 05.24.39 Quit eWill (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]) 05.28.11 Quit antil33t () 05.30.57 # New commit by 03saratoga (r28789): Commit FS#11776 by Jonas Haggqvist. Enables option to log building the database in order to trouble shoot crashes. 05.32.54 # r28789 build result: All green 05.33.48 Quit InsDel (Read error: Connection reset by peer) 05.47.08 Quit LambdaCalculus37 (Quit: zoom) 05.58.30 # New commit by 03saratoga (r28790): Commit small piece of FS#11748 by Michael Hohmuth. Disables database specific fields if the database is not compiled in. 06.00.55 # r28790 build result: All green 06.01.29 Quit simonrvn (Ping timeout: 240 seconds) 06.06.04 Quit JesusFreak316 (Ping timeout: 245 seconds) 06.10.48 *** Saving seen data "./dancer.seen" 06.12.46 Join Bushmills [0] (~Bushmills@scarydevilmonastery.net) 06.12.46 Join The_Pwny [0] (~IceChat7@203-219-63-40.tpgi.com.au) 06.35.01 Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz) 06.35.25 Quit antil33t (Client Quit) 06.35.40 Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz) 06.44.02 Quit panni_ (Read error: Connection reset by peer) 06.45.20 Quit ReimuHakurei (Quit: Stand by, Ready!) 06.46.46 Join ReimuHakurei [0] (~reimu@74.112.212.15) 06.48.16 Quit ReimuHakurei (Read error: Connection reset by peer) 06.48.30 Join ReimuHakurei [0] (~reimu@74.112.212.15) 06.48.53 Quit ReimuHakurei (Read error: Connection reset by peer) 06.49.12 Join ReimuHakurei [0] (~reimu@74.112.212.15) 06.52.00 Quit ReimuHakurei (Read error: Connection reset by peer) 06.52.08 Join ReimuHakurei [0] (~reimu@74.112.212.15) 06.56.57 Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com) 06.58.24 Quit ReimuHakurei (Read error: Connection reset by peer) 07.14.31 Quit yosafbridge (Quit: Coyote finally caught me) 07.14.42 Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com) 07.38.42 Quit factor (Read error: Connection reset by peer) 07.40.57 Join simonrvn [0] (simon@210.23-ppp.3menatwork.com) 07.56.04 Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 08.06.13 Join Horscht [0] (~Horschti@xbmc/user/horscht) 08.10.49 *** Saving seen data "./dancer.seen" 08.24.46 Join mortalscan [0] (~mortalsca@109.169.55.155) 08.27.18 Quit BHSPitMonkey (Read error: Connection reset by peer) 08.36.06 Quit shai__ (Quit: Leaving) 08.59.43 Join bmbl [0] (~bmbl@dsl26-56.pool.bitel.net) 08.59.43 Quit bmbl (Changing host) 08.59.43 Join bmbl [0] (~bmbl@unaffiliated/bmbl) 09.02.37 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 09.31.42 Join user890104 [0] (Venci@venci-notebook-lan.ipv6.6bez10.info) 09.34.46 Quit Stummi (Excess Flood) 09.34.55 Join Stummi [0] (Stummi@rockbox/developer/Stummi) 09.34.58 Quit Stummi (Excess Flood) 09.35.23 Join Guest8118 [0] (Stummi@doppeldenk.org) 09.35.27 Quit Guest8118 (Excess Flood) 09.35.59 Join Stummi_ [0] (Stummi@rockbox/developer/Stummi) 09.47.05 Join Buschel [0] (~chatzilla@p54B66A28.dip.t-dialin.net) 10.00.13 Join slooopy [0] (~sloo@p5493DB9C.dip0.t-ipconnect.de) 10.00.18 Quit Judas_PhD (Quit: This is a quitting message) 10.05.51 Quit linuxstb (Read error: Connection reset by peer) 10.06.02 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 10.08.23 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 10.10.53 *** Saving seen data "./dancer.seen" 10.26.25 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 10.26.25 Quit bertrik (Changing host) 10.26.25 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 10.39.37 # New commit by 03Buschel (r28791): Derive clock and timer defines from frequency of external source. 10.41.26 # New commit by 03Buschel (r28792): Detail comment in timer configuration of S5L870x. 10.41.50 # r28791 build result: All green 10.42.44 # New commit by 03Buschel (r28793): Set DRAM configuration for iPod nano 2G in crt0.s 10.43.58 # r28792 build result: All green 10.46.16 # r28793 build result: All green 10.55.53 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 10.57.43 Part Bushmills 10.59.13 Nick S_a_i_n_t is now known as [Saint] (S_a_i_n_t@203.184.0.142) 10.59.50 Quit bmbl (Ping timeout: 240 seconds) 11.01.20 Quit Judas_PhD (Quit: This is a quitting message) 11.02.55 Join bmbl [0] (~bmbl@unaffiliated/bmbl) 11.14.02 Join dfkt [0] (dfkt@unaffiliated/dfkt) 11.21.36 Join pamaury [0] (~quassel@dhcp-129-228.residence.ens-lyon.fr) 11.21.36 Quit pamaury (Changing host) 11.21.36 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.22.20 # Yuk, several tricky problems have been appearing lately on the ams sansas: 1) fuze v2 not recognising the tuner chip and hanging 2) (big) SD cards not working on the clip+ 3) clip+ display being dim and player getting warm 11.22.37 # (only on some players apparently) 11.23.21 Join bimbel [0] (~bmbl@unaffiliated/bmbl) 11.24.51 Quit bmbl (Ping timeout: 245 seconds) 11.27.43 Join TheLemonMan [0] (~lem0n@ppp-154-132.98-62.inwind.it) 11.29.11 Nick bimbel is now known as bmbl (~bmbl@unaffiliated/bmbl) 11.31.26 Join {phoenix} [0] (~dirk@p57AA46C4.dip.t-dialin.net) 11.35.48 # <[Saint]> Is anyone able to tell me what the largest capacity disk is that I could expect to put in an iPod Colour/Photo? 11.38.42 # New commit by 03Buschel (r28794): iPod nano 2G: Call lcd_update_rect() in lcd_update() instead of using an own implementation. 11.40.35 # r28794 build result: All green 11.44.08 Join stoffel [0] (~quassel@p57B4D5A2.dip.t-dialin.net) 11.49.38 # saratoga: apparently i can't at all, since i got 2.2 11.49.43 # task killer leaves it be now 11.50.11 # kugel: I just tried your patched android build on my stock g2 and it is 0% cpu and doesnt appear to be waking up at all which is good, so maybe its a cyanogenmod thing, that said I still don't really like the way ticks are done 11.51.37 # kugel is here? 0.0 11.52.29 # <[Saint]> amee2k: logs 11.52.41 # ooh, right 11.52.58 # i think he is the only one i know who uses logs as bnc replacement >_> 11.54.15 # <[Saint]> sliding offtopic here, but lots of people use the logs instead of idling in channel. 11.56.41 # hehe 12.00.12 # omg... the network card on my rockbox laptop is so going on my ***** >_< 12.02.27 # is there a way to redirect kernel messages like "[ 1234.5678] eth0: coax cable problem" to something other than the currently selected terminal?! 12.02.51 # can a thread in our forums be split so that you can also split posts in themselves? 12.03.17 # the driver for some reason keeps insisting that the non-existent coax interface on my network card is, well, non-existent 12.03.22 # I mean if a post contains statements about two different topics 12.06.38 Join moos [0] (moos@rockbox/staff/moos) 12.08.13 Quit slooopy (Ping timeout: 265 seconds) 12.09.27 # I have no idea 12.10.55 *** Saving seen data "./dancer.seen" 12.21.31 Join slooopy [0] (~sloo@p5493C15B.dip0.t-ipconnect.de) 12.38.32 Join kugel [0] (~kugel@rockbox/developer/kugel) 12.39.31 Join kevku [0] (~kevku@2001:7d0:0:f000::135d) 12.49.47 Quit The_Pwny (Quit: Oops. My brain just hit a bad sector) 12.55.27 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 12.56.11 Join DerPapst [0] (~Alexander@p5DE5A2A9.dip.t-dialin.net) 12.56.58 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 13.10.20 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 13.11.09 # * Buschel just sped up nano 2g lcd by 50% :) 13.12.22 # kugel, are you familiar with the ams/amsv2 sd driver? 13.13.21 # several people seem to have problems with sd cards on the clip+ 13.14.19 # so I'm looking a bit into the driver. I plan to make the amsv1 and amsv2 drivers more similar, the amsv1 sd driver seems to do some things that the amsv2 sd driver does not. 13.14.51 # bertrik: no sorry 13.14.52 # Also I'm still a bit puzzled by the mci_delay()s a bit, they seem to be present whenever we *dont'* expect a response from the card 13.15.04 # but not consistently 13.15.11 # but FlynDice worked a lot on the v1 driver, which he did not on the v2 one IIRC 13.15.40 # yeah, I guess I need funman and FlynDice, but they both haven't been here for a while 13.15.52 # didn't the v1 one change all commands to expect a response which removed the need for the delays? 13.16.37 # I indeed remember a discussion about that, but I'm not sure if that was ever implemented 13.21.23 # ah yes, this was implemented for amsv1 sd driver in 27066, but there are still quite a few mci_delay()s left 13.22.59 # Yeah, I did some changes to the v1 driver that removed a few mci_delay() 13.26.32 # <[Saint]> Buschel: Oh? How so? 13.28.17 # Saint: playing a bit with the FIFO status :) 13.28.18 # ranmachan, I'd like to apply that to the ams v2 driver too. What do I need to test to make sure that it doesn't break anything? 13.28.27 Quit stripwax (Quit: http://miranda-im.org) 13.28.50 # <[Saint]> Buschel: You work on Nano2G a fair bit, do you know what's wrong with "System - Debug (Keep Out!) - View disk info"? 13.29.10 # <[Saint]> it seems to repeat the same set of info ~5 times 13.29.35 # [Saint]: never looked at it... 13.30.17 # yes, it's repeated 13.31.13 # <[Saint]> I had a quick look, but couldn't see why it does that. 13.31.15 # bertrik: You could just try if the r27066 patch applies similarily to the amsv2 code and sd cards still work fine with that 13.34.01 # The Physical Layer Simplified Spec should list the response types to various commands 13.34.12 # Only a few commands don't send a response back 13.34.54 # [Saint]: I cannot see this at a first glance as well 13.35.06 # [Saint]: what LCD type does your nano have? 13.35.18 # ranmachan, ok, then it sounds like a very good thing to actually receive the response instead of inserting some random delay :) 13.37.01 Quit bluebrother (Disconnected by services) 13.37.02 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 13.37.17 # <[Saint]> Buschel: I have mostly type 1, (7) LSD176 LCDs in my Nano2Gs 13.37.52 # [Saint]: would be great, if you could test my lcd driver changes on your nanos as well 13.38.11 # <[Saint]> yeah, that's sweet. 13.38.22 # <[Saint]> Is there an FS for it yet? 13.39.17 # not yet -> http://pastie.org/1367734 13.40.09 Join Luca_S [0] (~57113b1a@giant.haxx.se) 13.40.18 Join MethoS- [0] (~clemens@134.102.106.250) 13.41.16 # hello - re: SD driver on ams, I can test patches on a fuzev2 if needed 13.43.36 # I remember back from the initial porting days that my uSD did not work with the initial delays and started working when changing a couple of commands to expect a response 13.44.45 # talking about fuzev2, enabling USB breaks the cpu frequency switching :( 13.45.06 # (i mean, the CPU frequency switching patch that's on the tracker) 13.45.08 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 13.45.08 # Luca_S, I plan to put some patches in http://www.rockbox.org/tracker/task/11798 13.45.39 # you know how to patch, build and test, right? 13.45.57 # yep 13.47.35 # uhm, my linux vm is borked... I can test as soon as I restore an ubuntu vm :D 13.51.38 # * amee2k nervously rolls kugel around the channel 13.51.44 # i hate my life >_< 13.52.16 # the es18xx sound driver in deb testing is broken 13.52.41 # <[Saint]> amee2k: I can't imagine a channel that is appropriate for, but it isn't this one. 13.53.36 # [Saint]: it is appropriate in so far as i'm trying to get rb to work on the box and wanted to give kugel a status up on it 13.53.55 # <[Saint]> " i hate my life >_<" 13.54.45 # also, please just tell me to fsck off in my face, rather than beating around the bush like that 13.57.20 Join _jhMikeS_ [0] (~jethead71@adsl-99-36-12-236.dsl.sfldmi.sbcglobal.net) 13.57.20 Quit _jhMikeS_ (Changing host) 13.57.20 Join _jhMikeS_ [0] (~jethead71@rockbox/developer/jhMikeS) 13.57.20 Quit jhMikeS (Disconnected by services) 14.01.53 Quit antil33t (Read error: Connection reset by peer) 14.02.02 Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) 14.10.56 *** Saving seen data "./dancer.seen" 14.13.49 Join Kupop [0] (~Kupo@cpc2-bsfd7-2-0-cust220.5-3.cable.virginmedia.com) 14.21.38 Quit antil33t (Read error: Connection reset by peer) 14.21.47 Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) 14.22.04 # [Saint]: FS#11807 14.30.28 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 14.43.40 Quit slooopy (Ping timeout: 240 seconds) 14.45.50 # amee2k: what's up? 14.46.42 # kugel: the sound driver for my card is screwed up in deb testing :/ 14.47.34 # :( 14.47.39 Quit Kupop (Ping timeout: 255 seconds) 14.48.43 # exactly what i thought, just somewhat less polite 14.57.21 Quit linuxstb (Ping timeout: 245 seconds) 14.57.27 Join slooopy [0] (~sloo@p5493D545.dip0.t-ipconnect.de) 14.58.20 # did the idle usage change? 15.06.09 # i only gave it a very quick try so far, but first indication is no 15.07.01 # kugel: but htop now seems to show proper CPU% figures per-process 15.07.17 # didn't try powertop yet though 15.08.46 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 15.12.55 # bertrik: did you continue to disassemble the fuze+ firmware ? 15.13.36 Quit linuxstb (Ping timeout: 245 seconds) 15.25.35 Join einhirn [0] (~Miranda@p54850260.dip0.t-ipconnect.de) 15.28.30 Quit einhirn (Client Quit) 15.40.18 # I see some interesting strings in the fuze+ last stage bootloader 15.40.31 # and some C++ things too :( 15.43.19 Quit slooopy (Ping timeout: 265 seconds) 15.45.31 Quit shai (Ping timeout: 240 seconds) 15.48.14 # pamaury, no 15.48.35 # I did spot a c library, forgot which one it was 15.49.53 # ok, when I'm done with the bootloader, do you think I should try host or play ? 15.51.49 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 15.53.57 Quit GeekShadow (Ping timeout: 240 seconds) 15.54.00 # pamaury, actually I didn't get that far and am not planning to do more in the near future, so just pick the one you like 15.54.27 Join einhirn [0] (~Miranda@p54850260.dip0.t-ipconnect.de) 15.54.38 Quit einhirn (Client Quit) 15.56.34 Join slooopy [0] (~sloo@p5493DCC7.dip0.t-ipconnect.de) 15.57.13 Join einhirn [0] (~Miranda@p54850260.dip0.t-ipconnect.de) 16.05.36 Join casainho [0] (~chatzilla@2.81.139.144) 16.10.57 *** Saving seen data "./dancer.seen" 16.25.22 Quit casainho (Read error: Operation timed out) 16.32.13 Join noamsml_ [0] (~noamsml@adsl-75-45-243-240.dsl.sfldmi.sbcglobal.net) 16.33.03 Join hebz0rl [0] (~hebz0rl@dslb-088-065-220-099.pools.arcor-ip.net) 16.34.40 Quit noamsml (Ping timeout: 255 seconds) 16.35.58 Quit jfc (Ping timeout: 250 seconds) 16.38.07 Quit Strife89 (Quit: Reboot.) 16.40.42 Quit mortalscan (Ping timeout: 245 seconds) 16.42.07 Quit Feisar- (Remote host closed the connection) 16.43.19 Join Strife89 [0] (~Strife89@adsl-80-129-191.mcn.bellsouth.net) 16.43.50 Join ender` [0] (krneki@foo.eternallybored.org) 16.44.06 Join Feisar [0] (jljhook@irkki.fi) 16.44.17 Join jfc [0] (~john@dpc6682208002.direcpc.com) 16.44.32 Nick Feisar is now known as Guest24228 (jljhook@irkki.fi) 16.51.48 Quit Bawitdaba (Read error: Connection reset by peer) 16.52.07 Join Bawitdaba [0] (~Sphinx@cpe-74-70-40-135.nycap.res.rr.com) 16.55.40 # kugel: do you think testing performance on the new system has a point if the soundcard isn't working? 16.55.54 # yea 16.56.38 # because i just stalled and dropped out of the sky like a rock, as to what the problem with the card is 16.57.14 # so my working theory about it right now is that the driver build is simply screwed up 16.57.51 # after all, its an ISA-PNP device. so it was probably never tested on real metal until now 16.58.14 Quit Strife89 (Quit: Reboot.) 17.00.29 # testing comes with powertop 1.11 so i'll compile the new one too 17.05.37 Join Strife89 [0] (~Strife89@adsl-80-129-191.mcn.bellsouth.net) 17.10.44 Join casainho [0] (~chatzilla@2.81.139.144) 17.10.45 Quit ender` (Quit: If man could be crossed with the cat it would improve man, but it would deteriorate the cat. -- Mark Twain) 17.15.12 Join ender` [0] (krneki@foo.eternallybored.org) 17.27.44 # The last stage bootloader of fuze+ seems to support debug uart, don't know what you can do with it though 17.28.38 # theres usually a terminal console over that 17.33.13 # what keybinding is quit on the SDL app btw? 17.34.54 # I don't think stopping supported :) 17.35.43 # kugel: no noticable improvement. htop is still showing 60..70% idle load 17.36.16 # the process list attributes ~50% CPU load to the main process and the rest to its threads 17.36.57 # http://paste.debian.net/102148/ << deb testing, not patched, idling in main menu 17.37.06 # recompiling with your patch right now 17.37.46 # hm, does the SDL app support "LCD shutdown"? i.e. can it stop repainting the screen 17.37.49 # ? 17.38.22 Join shai_ [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 17.42.26 Quit shai (Ping timeout: 260 seconds) 17.45.17 # amee2k: how do you identify the main process? 17.46.32 # i switch htop into tree mode (F5) 17.46.43 Quit stoffel (Remote host closed the connection) 17.46.48 # oh, nice tip :) 17.46.55 # it shows one rockbox process on top and like 6 or 7 below it 17.47.07 # i suppose the subprocesses are scheduling entities of the threads 17.47.21 # :) 17.47.53 Quit TheLemonMan (Quit: free(me)) 17.49.18 Join GeekShadow [0] (~Antoine@93.21.177.169) 17.49.22 Quit GeekShadow (Changing host) 17.49.22 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 17.49.23 # http://ompldr.org/vNmlyMw/htop.png (the load figures are off because the compiler is running right now) 17.49.26 # amee2k: we use sdl thread (which map to pthreads) for the rockbox threads 17.49.37 # with my patch we implement a userspace threads 17.50.40 # which reduces the 7+ pthreads to 3 or 4 17.50.49 # (also cheaper context switching) 17.50.56 # okay 17.51.43 # amee2k: I'm surprised the main thread puts so much load 17.51.50 # it's mostly sleeping 17.52.15 # perhaps sem_wait() doesn't work correctly on your system, that's used all over the place for idling 17.52.44 # mmh, didn't someone quote the docs a few days ago that under certain conditions it reverts to polling? 17.53.06 # and err... busy waits 17.53.28 # yeah, someone said on some systems it was implemented as polling every x msec 17.53.34 # (from the doc) 17.54.34 Quit ender` (Quit: Where there's a will, there's an inheritance tax.) 17.54.36 # * TheSeven now has a generic copyright-free exploit for the s5l8702 :) 17.54.48 # but I think is was when there is a timeout 17.54.58 # TheSeven: exploit to do what 17.54.59 # ? 17.57.25 # run arbitrary code from DFU mode 17.58.04 # does this need an exploit ? 17.58.17 # yep :/ 17.58.40 # is it target specific ? I though a DFU mode would be design to run code :/ 17.59.00 # yes, code signed by apple using an RSA certificate 17.59.17 # nor our code :) 17.59.28 # not* 17.59.53 # hehe 18.00.02 Join ender` [0] (krneki@foo.eternallybored.org) 18.00.06 # how do you do that ? 18.10.58 *** Saving seen data "./dancer.seen" 18.10.59 # [Saint]: could you already test the lcd patch? 18.12.05 # kugel: where in the source is the sem_wait() call in question? 18.12.27 # i just tried making a testcase, but it appears to work correctly 18.12.33 # http://paste.debian.net/102150/ 18.13.32 Join InsDel [0] (~haqr.net@unaffiliated/insdel) 18.14.01 # pamaury: they have a nice buffer overflow vulnerability in the certificate parser :) 18.14.46 # lol, makes the whole thing useless 18.20.24 # yes, but exploiting that wasn't exactly trivial :) 18.21.41 # * TheSeven thinks it's time to start the rockbox port... 18.22.03 # ok 18.22.07 # who wants to hold hands? :) 18.22.08 # I trust you ;) 18.22.14 # * TheSeven hasn't created a port from scratch before 18.22.31 # which device ? 18.22.53 # * pamaury is too busy disassembling the fuze+ for now 18.24.10 # amee2k: wait_for_interrupt() in my patch, thread-sdl.c in svn 18.25.01 # hello 18.25.15 # while trying build my port, I get this error: Error: selected processor does not support `clz r2,r1' 18.25.26 # oh, thats in the patch? 18.25.44 # in support-arm.S 18.25.59 # i thought the regular pthreads implementation is using it too 18.26.12 # but grepping the source tree doesn't come up with any matches for me 18.26.56 Quit FOAD (Quit: I'll be back) 18.27.19 Join FOAD [0] (~dok@83.161.135.61) 18.29.15 Quit kugel (Remote host closed the connection) 18.30.04 # amee2k: which ARM core is that? does it actually support that instruction? 18.30.26 # if yes, there's probably a wrong -mcpu= whalue in tools/configure 18.30.51 # if not, it's probably some wrong define 18.31.00 # hu? wrong nick? 18.31.13 # i'm with the SDL guys here >_> 18.31.28 # ah, damn, wanted to ping casainho 18.31.29 # you want to talk with casainho 18.31.36 # hehe 18.33.30 # TheSeven: well, I need to see on datasheet -- 2 minutes 18.34.57 # TheSeven: it's ARM926EJ-S 18.35.49 # that's ARM9e, so it should support clz 18.35.55 # look at tools/configure in that case 18.37.44 # TheSeven: I have this there: arm9tdmicc 18.39.07 # should be arm926ejscc 18.39.42 # TheSeven: thanks ;-) 18.49.40 # TheSeven: that was the problem - now resolved, thanks. 18.50.20 Quit MethoS- (Remote host closed the connection) 18.50.47 Quit liar (Quit: Leaving) 18.51.26 Join Strife1989 [0] (~Strife89@adsl-67-60-29.mcn.bellsouth.net) 18.52.55 # New commit by 03Buschel (r28795): Fix typo in comment. 18.53.00 Quit Strife89 (Ping timeout: 240 seconds) 18.54.50 # r28795 build result: All green 18.56.14 Join panni_ [0] (hannes@ip-178-203-85-85.unitymediagroup.de) 19.02.34 Quit Luca_S (Quit: CGI:IRC (EOF)) 19.06.07 Quit Buschel (Ping timeout: 245 seconds) 19.07.05 Join krabador [0] (~krabador@host142-229-dynamic.252-95-r.retail.telecomitalia.it) 19.08.08 Quit bmbl (Read error: Connection reset by peer) 19.17.57 # what scramble magic number do we want to have for the ipod classic? 19.18.08 # ip6g? ipcl? something else? 19.20.02 # I think 6g is the best, least ambiguous 19.20.14 # Since they may call future models the "classic" as well 19.22.31 # well, there are already three versions of the ipod classic, which we can probably handle with one port 19.22.52 # and it looks like they're dropping the HDD-based series altogether soon 19.23.03 Nick Strife1989 is now known as Strife89 (~Strife89@adsl-67-60-29.mcn.bellsouth.net) 19.26.07 # Does any of that make "ipcl" better than "ip6g" though? 19.26.23 # kugel: http://paste.debian.net/102156/ << deb testing, with your patch, idling in main menu 19.27.16 # its down to one main process and 3 sub-processes now, with the main one still causing 40..50 CPU% load 19.27.28 # Llorean: yeah, but what about the names in the target tree? target/arm/s5l8702/ipod6g? target/arm/s5l8702/ipodclassic? or even in target/arm/s5l8700? 19.28.01 # of the subprocesses, the first one is floating very stable around 7%, the last one around 3%, and the middle one bottomed out at 0% 19.29.02 Join dantje_ [0] (~dvg@HSI-KBW-091-089-103-221.hsi2.kabelbw.de) 19.30.13 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 19.30.42 # TheSeven: arm/s5.../ for generic things (if ther are any) and then arm/s5.../ipodxxx/ for ipod specific 19.30.55 # yeah, that's clear :) 19.31.00 # TheSeven: I don't see why you'd use "ipodclassic" in it if you use "ip6g" for the magic number. I think using "ipod classic" as the name for it internally is just adding a risk of having a different ipod classic later if apple changes their mind. 19.31.34 # * TheSeven thinks that ipod6g might suggest similarity to the ipod 5g/5.5g 19.31.35 # I don't really see a disadvantage to ipod6g internally, while iPod Classic doesn't have an immediate disadvantage (other than that people already think of all the iPods as "classic" sometimes already) other than in hypothetical futures. 19.31.49 # also, this definitely won't go into arm/ipod because it's just completely different 19.31.51 # I don't see how "6g" suggests similarity in any way. 19.32.02 # other than it's a generation of ipod. 19.32.05 Join Kitar|st [0] (Kitarist@89.142.62.117) 19.32.58 # where does the SDL app have its button map?! 19.33.42 # having things in /target/arm/ipod/video for the 5g but /target/arm/s5l870x/ipod6g just seems to be a bit confusing to me 19.34.05 # arm/ipod is the old style tree no ? 19.34.22 # arm/ipod are the portalplayer-based ones 19.34.59 # another issue is having the s5l8701 (nano2g) in the s5l8700 dir, but the s5l8702 separately 19.35.26 # there are *some* similarities between the 8701/8702, but not that many 19.35.37 # the 8702/8720 seems to be more similar 19.36.37 # the wiki has a TargetTree entry which states firmware/target/// 19.36.50 # yeah, but what is the model? 19.37.04 # people tend to merge that into whole series of chips if they are similar enough to share most things 19.37.48 # but the odd relation between the samsung model numbers and their similarities will lead to confusion here 19.39.14 # if we would really follow what the wiki says, it should be firmware/target/arm/samsung/ipod6g or even firmware/target/arm/samsung/s5l8702/ipod6g 19.39.25 # perhaps the problem comes from this s5l8700 dir ? Does this chip exist or is it family ? 19.39.56 # yeah you're right, I think lately we used something more closer to target/// 19.39.57 # or is the player manufacturer being meant? then it would be target/arm/apple/ipod6g, but no other target seems to interpret it that way 19.40.22 # there are four s5l chips we know: 19.40.40 # - s5l8700 (various meizu players, samsung yp-s3) 19.40.47 # - s5l8701 (ipod nano 2g) 19.40.54 # - s5l8702 (ipod nano3g, ipod classic) 19.41.02 # - s5l8720 (ipod nano 4g, ipod touch 2g) 19.41.22 # the 8700/8701 have many things in common, and the 8702/8720 19.41.42 # that's a weird numbering :-/ 19.42.16 # or do something like s5l8700v2 :) 19.42.20 # to make it even worse: ipod nano 5g is s5l8730, but ipod nano 5g is s5l8723 19.42.35 # damn 19.42.40 # the latter one should be 6g of course 19.43.06 # do 730 and 723 share something in common ? with other series ? 19.43.19 # no idea, we haven't seen unencrypted code for these yet 19.43.48 # and nobody has the doc ? 19.44.11 # the only thing that's in the wild is a leaked "samsung confidential" preliminary datasheet for the s5l8700 19.44.16 # everything else was reverse-engineered 19.44.35 # I guess there are unwilling to share it ? ;) 19.44.48 # and that datasheet doesn't even fully match our reverse-engineering results of the 8700 19.45.01 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 19.45.57 # I would personally go for arm/s5l8702 and put s5l8720 with it, they share the "2" ;) 19.46.23 # or s5l8702_8720 19.46.27 # urgh 19.47.15 # actually i'd like to identify all the damn cores they're using, and name them according to their manufacturer 19.47.24 # not caring about socs at all 19.48.11 # e.g. synopsys/usb-otg.c, arm/primecell/vic-pl192.c, ... 19.48.17 # but do you have this information ? 19.48.28 # only for some small parts of it :/ 19.49.19 # our tree is a total mess :| 19.49.29 # TheSeven: but what about cores that were from company A when SoC X was built but from company B when SoC Y was built? 19.49.58 # what do you mean ? 19.50.42 # gevaerts: i would go for the core's designer, not the soc manufacturer 19.51.03 # but i'd guess that we won't ever manage to figure this out for lots of cores 19.51.29 # TheSeven: those get taken over every year or so 19.51.46 Quit AlexP (Quit: Please insert girder) 19.52.42 # the USB core in the PortalPlayer 502x and imx31 SoCs is from ARC, Synposys, and possibly ChipIdea (not sure about that last one) 19.53.56 # We call it ARC because that name appears somewhere in a datasheet, but... 19.55.26 # And in the end I think Synposys has something like seventeen USB cores thanks to their acquisitions 20.03.52 Quit Llorean (Quit: Leaving.) 20.05.49 Quit einhirn (Read error: Connection reset by peer) 20.06.33 Join ReimuHakurei [0] (~reimu@74.112.212.15) 20.10.47 Join AlexP [0] (~alex@rockbox/staff/AlexP) 20.11.00 *** Saving seen data "./dancer.seen" 20.11.49 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 20.32.33 Join AlexP_ [0] (~alex@rockbox/staff/AlexP) 20.33.09 Quit AlexP (Ping timeout: 240 seconds) 20.33.27 Quit ReimuHakurei (Quit: Stand by, Ready!) 20.33.33 Join ReimuHakurei [0] (~reimu@74.112.212.15) 20.54.14 # bertrik: I have an explaination for the SGTL in sb file format 20.54.25 # sigmatel? 20.54.36 # SiGmaTeL I mean 20.56.35 # in the imx23 manual there is a register called SGTL which is supposed to returned "SigmaTel..." and is used by the debugger to check it's a genuine freescald chip. They used the same in the format. I particularly like the comment: 20.57.07 # The debugger does a string compare on these 12 successive little endian bytes. Any chip that reads back these values is either a Freescale chip or it is a competitors chip that is violating Freescale registered trademarks and or copyrights. 20.58.40 # ah, interesting 21.02.42 # if one day we create a chip, we'll design a nice register which prints rockbox and put a copyright on it ;) 21.15.51 # pamaury: any advances? 21.16.07 # pamaury: on imx23 port? 21.17.25 # I'm in the last stage of the bootloader, there are lots of interesting things; probably some LCD code so perhaps I'll figure the pins, if bertrik don't already have them already. But there is quite a bunch of code, I don't really know what it does. when I'm done, I'll move on to the firmware itself, to figure out the pins 21.17.40 Quit slooopy (Ping timeout: 240 seconds) 21.18.08 # I'm not quite ready to write code :) 21.18.15 Nick noamsml_ is now known as noamsml (~noamsml@adsl-75-45-243-240.dsl.sfldmi.sbcglobal.net) 21.19.23 # pamaury: you mean you have for example, rockbox kernel() working? 21.19.49 # no, I didn't write any line of code, nor I have a fuze+ for now ;) 21.20.00 # I'm disassembling the fuze+ firmware 21.20.06 # ah, ok 21.20.32 # because I started the port, I am trying to build bootloader, using empty stubs 21.20.51 # I am looking for the help of BobC 21.21.37 # he wrote the code for last port, of s3c2440/mini2440 21.21.47 # we both have now the same hardware/imx233 21.22.08 # I don't know how we will do for the fuze+ port (if there is one); but my guess is that reusing the original firmware bootloader since it's doing lots of hardware initialisation 21.22.12 Join fml [0] (~chatzilla@manz-590ef5a7.pool.mediaWays.net) 21.22.26 # s/reusing/we will reuse 21.22.58 # we have initizlization code from Chumby code :-) 21.23.02 # do you know Chumby? 21.23.25 # Hello. FS#11785 contains a rather trivial fix for 14-Nimbus. But we don't have the real name of the contributor. How do we deal with such patches? I was to fix the font I would do it in the very same way. 21.24.02 # yes I know Chumby 21.24.30 # then it's the same for you, you won't have to write all the really low level init stuff probably 21.25.25 # fml: why not just fix it yourself then? :) 21.25.43 # but contrary to you, we don't don't know the pins / have no control over them ;) 21.26.04 # pamaury: I already used the chumby code to initialize the SDRAM and write/read to it :-) 21.26.29 # pamaury: well, the SDRAM are the same pins for sure :-) 21.26.39 # yeah, you don't have much choice :) 21.26.39 # TheSeven: because he/she was the one who noticed and fixed it (the former was the harder part). 21.26.55 # pamaury: even the LCD, because of LCD controller 21.27.15 # pamaury: ok, good luck 21.27.17 # bye 21.27.23 # thanks 21.30.00 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 21.30.10 Join slooopy [0] (~sloo@p5493D691.dip0.t-ipconnect.de) 21.32.49 # so should I go for "ip6g" and firmware/target/arm/s5l8702/ipod6g? 21.33.22 Quit ReimuHakurei (Quit: Stand by, Ready!) 21.33.32 Join ReimuHakurei [0] (~reimu@74.112.212.15) 21.33.32 Quit ReimuHakurei (Client Quit) 21.34.39 # yeah 21.34.40 Join ReimuHakurei [0] (~reimu@74.112.212.15) 21.35.12 Quit krabador (Ping timeout: 265 seconds) 21.38.24 Join krabador [0] (~krabador@host142-229-dynamic.252-95-r.retail.telecomitalia.it) 21.40.26 Quit liar (Quit: Leaving) 21.41.46 # hm... ipco, ip3g, ip4g, ipvd, ip6g, mini, mn2g, nano, nn2g, ... very consistent... 21.43.51 Quit krabador (Quit: Sto andando via) 21.45.24 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 21.45.58 Quit GeekShadow (Quit: The cake is a lie !) 21.46.11 Join Buschel [0] (~chatzilla@p54A3A6CE.dip.t-dialin.net) 21.52.01 # ipod 6g feels really silly if the previous model was called "ipodvideo" everywhere 21.53.08 # hm, very good variable name: t_manufacturer="s5l8702" 21.54.10 Join JesusFreak316 [0] (~JesusFrea@pool-173-65-30-16.tampfl.fios.verizon.net) 22.01.08 # * Buschel needs some testers with nano 2G's for FS#11807 22.05.23 # New commit by 03alle (r28796): Fix the eogonek glyph in 14-Nimbus (the credit goes to the author of FS#11785) 22.06.49 # Buschel: pasting the flyspray's title might attract more people :) 22.07.09 # r28796 build result: All green 22.07.45 # how does this compare to DMA? 22.08.19 # I thought most people would just use the link :o) but here is the description: "Major speed up of iPod nano 2G LCD" 22.08.50 # TheSeven: I don't know how this compares to DMA. did you bring this to wokr? 22.09.00 # *work 22.09.05 # my embios-based benchmarks are using DMA 22.09.22 # :o) what do the numbers tell you? 22.09.35 # i posted them some weeks ago 22.09.41 # let me check the logs 22.09.51 # ahhh, wait. you had the strange LCD that was limited to 50-60 fps? 22.09.55 # the reason i am doing this from emBIOS is that the rockbox LCD driver architecture doesn't work well for DMA 22.10.15 # Buschel: I have the "type 7" one, which IIUC is the one you also have 22.10.22 # (LCD_DETECT0: 1, LCD_DETECT1: 0) 22.11.02 # and the limit seemed to come from the system bus actually, not the LCD itself 22.11.03 *** Saving seen data "./dancer.seen" 22.11.12 # TheSeven: we talked a while ago and you had measured there was a limitation in fps which seemed to be connected to HCLK 22.11.26 # * Buschel is too slow 22.11.48 # what are your LCD_DETECT values? 22.12.02 # (diagmode => others => status => second page IIRC) 22.12.41 # ? how do I enter diagmode? 22.13.25 # prev+select during boot 22.13.38 # 01[01:11] 25.8fps full RGB, 103.5fps quarter RGB, 22.5fps full YUV, 89.5fps quarter YUV at 48MHz 22.13.38 # 01[01:13] 51.7fps full RGB, 206.5fps quarter RGB, 51.7fps full YUV, 206.5fps quarter YUV at 192MHz 22.13.44 # I made a recording using Rockbox on my Clip+. Mic gain by default is set at 23. I increased it to 29. During an unusually loud portion of the recording, I had to decrease the level back to 25 due to distortion. 22.13.45 # those are DMA measurements IIRC 22.14.01 Quit krazykit (Quit: awe yeeeeeee) 22.14.11 # hm no, that were rockbox measurements 22.14.15 # But I can use SoX to increase the volume to four times the original without clipping a single sample. 22.14.50 # What did I do wrong to make the volume still so quiet even though I was getting distortion in the recording? 22.14.59 # 01[01:20] 51.7fps in emBIOS using DMA 22.15.02 # mine is DETECT0: 1 DETECT1: 0 22.15.09 # 01[01:27] Buschel: 25.8fps using DMA at 48MHz :/ 22.16.17 # how do I exit diagnosis mode? resetting? 22.16.20 # yep 22.16.32 # you can also use the "deep sleep" or "reset" tests :) 22.16.40 Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) 22.16.42 # I also get a hissing sound in the recording whenever the buffer is written to flash, but I think this is a hardware issue, and there's probably not much I can do about that. It's not particularly noticeable all the time anyway. 22.16.43 # and as we apparently have the same LCD: what values are you getting with and without your patch in rockbox? 22.17.13 # what is Texas Instrument SSI useful to ? 22.17.49 # TheSeven: w/o 192 MHz: 86.5 / 343.5 48 MHz: 36.3 / 144.5 22.17.55 # TheSeven: v= 22.18.27 # TheSeven: v03 192 MHz: 129.0 / 515.5, 48 MHz: 64.5 / 228.5 22.18.38 # 50% faster 22.18.57 # why are you getting more fps than me on the same LCD type? 22.19.17 # different configuration? 22.19.23 # i'm using HCLK=96MHz/48MHz, LCDCON=0xc01 22.19.51 # what DRAM speeds do you measure? and what is LCD_CON set on your nano? 22.20.00 # too slow again... :/ 22.20.10 # LCD_CON is 0xc01 here as well 22.20.24 # * TheSeven suspects this might be bootloader-related 22.20.27 Quit fml (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]) 22.20.28 # HCLK is also 96 or 48 MHz 22.21.10 # you are using the apple bootloader, right? 22.22.17 # yes 22.22.40 # hm, in this case emBIOS loader might be the culprit 22.24.16 # TheSeven: do you see any way to use 16 bit register writes instead of those damned 8 bit writes? 22.24.44 # no idea 22.24.54 # TheSeven: I played around with LCD_CON but I don't think the spec is correct 22.25.11 # however they are doing 16bit writes on the 8702/8720, so there might be a way to make it work on the 8701, too 22.25.55 # fun fact: on the 8702 they're doing 16bit writes when writing directly, however for DMA they set up 8bit transfers IIUC :) 22.25.56 # the spec says you can set APB bus width and set endianess 22.26.21 # * TheSeven thinks there was a reason why apple chose 8bit on the 8701 22.27.33 # e.g. architectural reasons. I don't think they thought about performance... 22.27.48 Quit casainho (Ping timeout: 245 seconds) 22.27.51 # because it's fast enough anyway :) 22.31.00 # the_Kyle: what codec did you use for recording? 22.31.25 # I mean your encoder settings 22.33.10 # pixelma: I'm using Wavpack. It doesn't have any additional encoder settings. Frequency is 44100 and channels is set to mono. 22.33.42 # the AMS chips have a 14 bit ADC, your PC uses 16 bit, and 4x louder is 2 bits 22.33.57 # theory: we don't shift the 14 bit output 2 bits to the left when saving it to wav 22.34.23 # wavpack? 22.34.31 # that was to saratoga 22.35.05 # presumably the input the wavpack encoder is functionally equivalent to wav 22.35.17 # 'to the wavpack encoder' 22.35.31 # aha 22.37.35 # This seems to explain it quite well. Looks like I need to adjust the volume on the PC to get the desired result and just keep my mic gain somewhere around 23 to 25. 22.39.08 # Since I'm working with Wavpack, this shouldn't reault in any loss of quality, and SoX does this and other things very well. 22.39.17 # result* 22.40.49 Quit moos (Ping timeout: 240 seconds) 22.40.53 Join AlexP [0] (~alex@rockbox/staff/AlexP) 22.43.39 Join BigBambi [0] (~alex@rockbox/staff/AlexP) 22.44.35 Quit AlexP (Read error: Operation timed out) 22.45.04 Join moos [0] (moos@rockbox/staff/moos) 22.45.08 Quit AlexP_ (Ping timeout: 264 seconds) 22.47.45 Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) 22.51.23 Quit dickhead () 22.52.20 Join casainho [0] (~chatzilla@bl20-126-39.dsl.telepac.pt) 22.53.48 # hello 22.54.14 # I am getting this warning while trying to port rockbox: warning: implicit declaration of function ‘lcd_set_backdrop’ 22.54.28 # seen Bagder 22.54.43 # \seen Bagder 22.55.13 # casainho: msg logbot 22.55.27 # it'll tell you that you need glasses though 22.55.30 # casainho: I'm here 22.59.23 # Bagder: i were trying to know last time yo were active. 23.00.43 Quit JesusFreak316 (Ping timeout: 245 seconds) 23.01.48 # that'd be 1987, in the spring B) 23.01.50 # any one cann tell me if I need to build lcd-2bit-vert.c with my bootloader files? 23.02.22 # Bagder: I didn't saw you talking since a long time :-) 23.02.31 # Bagder: I am back to do another port... 23.02.39 # I'm lurking in the shadows 23.02.51 # you need that file if you have a LCD using that format 23.03.28 # so what's the target this time? 23.04.15 # this one: http://lyre.sourceforge.net/?q=blog 23.04.26 # hey, I know, very crap LCD 23.05.01 Quit hebz0rl (Remote host closed the connection) 23.05.06 # lots of CPU for such an LCD... 23.05.12 # yeah... 23.05.24 # but I need something I can build, I can source 23.05.43 # * TheSeven realizes that config.h and SOURCES are just a *damn* *huge* *MESS*! 23.05.50 Join JesusFreak316 [0] (~JesusFrea@pool-173-65-30-16.tampfl.fios.verizon.net) 23.07.16 # #define HAVE_LCD_BITMAP --- my LCD is 2 bits, black and white... what should I define? 23.07.52 Part DylanJ 23.11.22 Quit Buschel (Ping timeout: 276 seconds) 23.12.21 Join Buschel [0] (~chatzilla@p54A3A6CE.dip.t-dialin.net) 23.13.50 # casainho: black&white is 1 bit :) 23.13.57 # Buschel: if i ever work out this new libmad filterbank, would you be able to use it in mpc, or are the two codecs too different? 23.14.41 # TheSeven: ok, so what should I do? 23.15.18 # #define LCD_DEPTH 1 23.15.38 # ok 23.15.44 # saratoga: it is possible. the array and some algorithms need to be resorted though 23.16.01 # do you know if there is any target like my? with same kinf of LCD? 23.16.07 # you mean the D coefficients? 23.17.08 # sorry, was a typo: I wanted to tpye "arrays". the subband samples must be resorted to be able to use the combination of dct/dewindowing/D 23.17.40 # casainho: not with the same one, no, but there are targets with 1bit lcd 23.17.53 # so the lcd frame buffer routines can be used 23.18.00 # thats better then the D coefficients though :) 23.18.15 # its been a month and i'm still toying with those! 23.18.33 # I can imagine 23.19.00 # Bagder: can you suggest me a target so I can look at it code? 23.19.09 # the recorder? 23.19.52 # Bagder: firmware/config/export/???.h ??? 23.20.24 # Bagder: ok, found it, Archos :-) 23.22.25 # i have this terrible feeling that i'm missing some obvious underlying simplification to this filter because sometimes i'll make a simple mistake (flip to pointers) and the output doesn't change 23.22.28 # TheSeven: why are all the LCD registers defined as 16bit? all are 32bit 23.22.41 # was this intentional? 23.24.18 # no idea, IIRC bertrik did this 23.24.27 # did I? 23.25.24 # at least it wasn't me who wrote s5l8700.h :) 23.25.52 # svn ann firmware/export/s5l8700.h 23.26.10 # TheSeven: interesting is that you can use LCD_WDATA and the following registers to write data to the LCD IF. so, you are able to use stmia 23.27.00 # TheSeven: bad news is that we still have a 8bit configuration and therefore need 4x the data accesses that we would need 23.27.48 # I don't know the reason why they are defined as 16-bit 23.28.16 # then let's correct them 23.28.25 # * Buschel just compiles 23.28.34 # I know that apple is also using STRH instructions on them, and only actually using 8 bits :) 23.29.42 # I thought that, generally, on arm all accesses are 32-bit anyway 23.30.27 Nick BigBambi is now known as AlexP (~alex@rockbox/staff/AlexP) 23.31.35 # i'm pretty sure that 16 vs. 32 bit accesses on the LCD regs don't make any difference at all 23.32.45 # TheSeven: correct. but I had the hope using 1x stm instead of 4x str would make a difference 23.32.48 # damn, what should I do about the ATA driver? 23.32.58 # and it doesn't... :/ 23.34.01 # it would again be interesting to find a way to be allowed to write 16 or 32 bits to the LCD FIFO and let the LCF IF do the rest (8 bit transfer to LCD itself) 23.34.16 # *that* should make a differencre 23.34.35 Quit slooopy (Ping timeout: 265 seconds) 23.34.51 # Buschel, we do something like that for the ams sansas IIRC, so the FIFO converts from 32-bit input to 2x16-bit output 23.34.55 # is there anybody around who knows how this weird semi-generic ATA driver works? 23.35.06 # i.e. how do I implement a lowlevel driver for that? 23.35.28 # bertrik: problem is the missing (or incomplete/buggy/preliminary) spec 23.35.46 # I think we also found that polling often the FIFO for full-status seemed to slow it down somehow 23.36.30 # bertrik: my patch also reduces the polls -> +50% speed 23.36.30 # New commit by 03wodz (r28797): HD300 - tweak lcd_update() (4-5% speedup) 23.37.03 # You have inspired me :-) 23.37.12 # :) 23.38.20 # r28797 build result: All green 23.38.26 Join rasher_ [0] (~rasher@0x5550f5a3.adsl.cybercity.dk) 23.38.26 Quit rasher_ (Changing host) 23.38.26 Join rasher_ [0] (~rasher@rockbox/developer/rasher) 23.38.57 # * TheSeven throws a rotten banana at whoever designed that ATA driver 23.43.25 Quit rasher (Quit: leaving) 23.43.25 Nick rasher_ is now known as rasher (~rasher@rockbox/developer/rasher) 23.47.08 Join slooopy [0] (~sloo@p5493C7FA.dip0.t-ipconnect.de) 23.47.56 # on arm9 theres no speed advantage to STM over STR, although the code size is smaller for the former 23.48.11 # arm7 and arm11 are faster with stm and ldm though 23.48.40 # at least code readability is better :) 23.48.42 # 2010-12-11 17:48:19 Starting client StrifeBox, revision 35, cores 1 23.48.42 # 2010-12-11 17:48:19 HELLO 35 arm-eabi-gcc444,sdl Strife89:randomshit StrifeBox i686 32 Linux 23.49.48 # If I have the USB patches applied, is there any way to keep my clip+ from booting into the OF if it's powered off before I plug in the USB cable? 23.50.06 # the_Kyle: yes, but using a usb-aware bootloader 23.50.13 # by* 23.51.03 # Did my bootloader not rebuild and become USB aware when I built the zip file? Or do I need to patch the OF again? 23.55.21 # the latter 23.56.15 # New commit by 03Buschel (r28798): S5L870x LCD interface registers are 32 bit. 23.57.39 # there is no USB aware bootloader for AMSv2 (and technically its not the bootloader that decides but rather the patcher code in mkamsboot) 23.57.57 # r28798 build result: All green 23.58.08 Quit liar (Quit: Leaving) 23.58.52 Quit simonrvn (Remote host closed the connection)