--- Log for 07.10.104  Server: burroughs.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 2 days and 23 hours ago

00.00.56 Quit    marc77 (Read error: 110 (Connection timed out))
00.00.59 #       <amiconn> I'll retry with latest cvs code (had a testing directory which is no direct checkout)
00.02.24 #       <[IDC]Dragon> what a comprehensive MMC info you've got
00.02.50 #       <amiconn> It's still not everything that is contained in the MMC registers ...
00.03.13 #       <[IDC]Dragon> the year has only 4 bits, how short-sighted
00.03.31 #       <amiconn> Did you notice: You can get info for both internal and external
00.03.56 #       <[IDC]Dragon> I didn't
00.04.21 #       <amiconn> Ah, I remember that you have no working external card :(
00.07.13 #       <amiconn> Argh, my const'ing causes that dreaded "initialization discards..." warning if PREFER_C_WRITING is defined
00.07.25 #       <amiconn> Hidden bug :/
00.09.30 #       <amiconn> No panic with my latest build! :)
00.10.30 #       <amiconn> Windows chkdsk does find no filesystem error either
00.13.57 #       <[IDC]Dragon> hooray!
00.14.33 #       <[IDC]Dragon> \o/   Jens   \o/
00.15.30 #       <[IDC]Dragon> this will make Ondio hacking interesting!
00.19.10 #       <amiconn> FAT32 still working as well.
00.19.29 #       <[IDC]Dragon> beautiful
00.19.30 #       <amiconn> Of course I didn't do extensive tests
00.19.55 #       <[IDC]Dragon> the test suite doesn't help us here, of course
00.21.22 #       <amiconn> I could adapt my filesystem stress test plugin (which I originally wrote for checking FAT32 whether it fails when saving recorded data)
00.21.37 #       <amiconn> This has to be adapted to the player lcd
00.21.58 #       <[IDC]Dragon> what does it do?
00.23.01 #       <amiconn> It writes lots of data (pseudo-random sequence) to disk with a behaviour as close as possible to how the recording code does it
00.23.26 #       <amiconn> (writing 2 large blocks with a pseudo-random split point)
00.23.45 #       <[IDC]Dragon> linear write, not terribly interesting
00.23.47 #       <amiconn> Then it reads back all data and compares with the pseudo-random sequence
00.24.19 #       <[IDC]Dragon> honestly, I don't expect trouble from the unsigned
00.24.30 #       <amiconn> Well, it's not completely linear, because the FAT is accessed in between
00.24.53 #       <[IDC]Dragon> if some code only worked because it was signed, it must have been strangely wrong
00.25.14 #       <amiconn> Okay, perhaps I should simply commit
00.25.46 #       <[IDC]Dragon> how much work is it to port your test?
00.26.33 #       <amiconn> I would have to cut down the output to 2 lines. Shouldn't be that hard, since I use a roll function (restart at top line if bottom one was used last)
00.28.15 #       <amiconn> But running it can take a loong time. When I did the test with the recorder (using a little less than 2 GB in total) it ran ~9 hours
00.28.28 #       <amiconn> Of course I wouldn't test with 2 GB here
00.28.39 #       <[IDC]Dragon> I was about to ask
00.29.45 #       <amiconn> It's a nice little stress test anyway. Perhaps I'll run it on the Ondio too, stressing the MMC driver
00.29.54 #       <[IDC]Dragon> I'm building with unsigned ,too
00.30.11 #       <[IDC]Dragon> don't stress writing too hard
00.30.46 #       <amiconn> I think it's no problem, since it doesn't write the same sector everytime
00.31.06 #       <[IDC]Dragon> except for the fat
00.31.43 #       <amiconn> This is written to more than once, yes, but not that often too.
00.32.24 #       <amiconn> Of course we'd need plugin support to do the test
00.33.27 #       <[IDC]Dragon> ah, I remember
00.34.21 #       <amiconn> My test plugin needs a patch to plugin.[ch]. fsync() is not in the plugin api by default
00.34.45 #       <[IDC]Dragon> OK, forget it
00.35.59 #       <amiconn> I've still got the .patch file, so it's easy
00.37.22 #       <[IDC]Dragon> I'm starting it on my box now
00.37.37 #       <[IDC]Dragon> (the build)
00.38.57 Quit    PRVSaosn ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )")
00.39.18 Join    ripnetUK [0] (~mirc@82-70-100-230.dsl.in-addr.zen.co.uk)
00.46.26 #       <amiconn> [IDC]Dragon: Testing on FAT32 with ~100 MB of data...
00.47.18 #       <[IDC]Dragon> I did a manual test session, no problems.
00.47.56 #       <[IDC]Dragon> recording, deleting files, bookmarking,...
00.48.30 #       <amiconn> Both fat16 and fat32?
00.49.24 #       <[IDC]Dragon> no, just FAT32
00.49.45 #       <[IDC]Dragon> I'm not worried about a broken FAT16 in cvs
00.50.17 #       <[IDC]Dragon> (well, no more than we have that now)
00.50.39 #       <amiconn> You're right. So when my fat32 test completes without error, I'll commit, then I'll do the fat16 test.
00.51.07 #       <[IDC]Dragon> but killing peoples HD file systems would be very embarrassing
00.53.02 Quit    plok ("I'm outta here!")
00.53.06 ***     Saving seen data "./dancer.seen"
01.02.42 #       <amiconn> [IDC]Dragon: You just saved one config bit ;)
01.03.11 #       <amiconn> ANd I have to rebuild the .voice files
01.04.21 #       <[IDC]Dragon> not urgently
01.05.25 #       <[IDC]Dragon> Ondio can write, hooray!
01.05.34 #       <[IDC]Dragon> just dumped the ROMs
01.06.26 Quit    _aLF ("Leaving")
01.07.16 #       <amiconn> Rebuilding the .voice files should be easy, but I wonder how out "Klara" will pronounce ".talk" (without a hint, that is)
01.08.11 #       <[IDC]Dragon> Im not sure how to name that entry, in general
01.08.21 #       <[IDC]Dragon> feel free to improve
01.09.28 #       <amiconn> Just found that the german voice: entry is just "Sprachdatei". This should work of course, but it may confuse users
01.09.59 #       <[IDC]Dragon> I think it's fine
01.10.18 #       <amiconn> I would associate "Sprachdatei" with a .voice file
01.10.26 #       <amiconn> Unfortunately there is no simple german equivalent to "clip"
01.11.37 #       <[IDC]Dragon> I'll sleep well now
01.11.43 #       <[IDC]Dragon> cu
01.11.50 #       <[IDC]Dragon> and thanks!
01.11.53 #       <amiconn> Goodnight
01.11.58 Quit    [IDC]Dragon ()
01.24.58 Quit    mecraw ("Trillian (http://www.ceruleanstudios.com)")
01.53.10 Quit    AciD (Remote closed the connection)
01.53.40 Join    iRiverMan [0] (~acbf1317@labb.contactor.se)
01.56.43 #       <iRiverMan> hi#
02.02.02 Join    ashridah [0] (ashridah@220.253.118.206)
02.24.13 Quit    iRiverMan ("CGI:IRC (EOF)")
02.37.00 Quit    amiconn (" Peer didn't reset this connection")
02.53.07 ***     Saving seen data "./dancer.seen"
03.01.23 Quit    midk (Read error: 104 (Connection reset by peer))
03.22.50 Join    midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com)
04.09.05 Join    scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
04.10.29 Quit    scott666 (burroughs.freenode.net irc.freenode.net)
04.10.29 NSplit  burroughs.freenode.net irc.freenode.net
04.10.29 Quit    gromit``` (burroughs.freenode.net irc.freenode.net)
04.10.29 Quit    Professor (burroughs.freenode.net irc.freenode.net)
04.18.24 NHeal   burroughs.freenode.net irc.freenode.net
04.18.24 NJoin   gromit``` [0] (~gromit@ALagny-151-2-10-68.w82-121.abo.wanadoo.fr)
04.53.11 ***     Saving seen data "./dancer.seen"
05.26.09 Quit    ashridah ("gone")
06.20.23 Quit    scott666_ ("i'll be back...eventually...")
06.52.21 Join    LinusN [0] (~linus@labb.contactor.se)
06.53.15 ***     Saving seen data "./dancer.seen"
07.26.34 Join    methangas [0] (methangas@0x50a461b8.virnxx10.adsl-dhcp.tele.dk)
07.27.41 Join    [IDC]Dragon [0] (~idc-drago@pD9FF80B1.dip.t-dialin.net)
07.30.57 #       <[IDC]Dragon> good morning
07.31.35 #       <[IDC]Dragon> what a nice one, with FAT16 working :-)
07.32.05 Quit    midk ("just STOP it arspy")
07.32.10 Join    midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com)
07.40.05 #       <LinusN> wonderful
07.45.01 #       * [IDC]Dragon has the Ondio back together for the first time, before it was "just" a PCB on the bench
07.45.22 #       <[IDC]Dragon> I stripped the wires off
07.47.09 #       <LinusN> what wires?
07.47.40 #       <[IDC]Dragon> debug wires ;-)
07.49.27 #       <LinusN> ah
07.56.31 Join    Chronic007 [0] (~Miranda@24.30.163.142)
08.11.18 Join    plok [0] (s336156@student.uq.edu.au)
08.15.31 #       <[IDC]Dragon> Bagder: r u there?
08.17.04 #       * plok is away - Automatically set away. - messages will be saved.
08.28.27 #       <LinusN> [IDC]Dragon: http://forums.rockbox.org/index.php?topic=30.from1097128134;topicseen#msg94
08.30.18 #       <[IDC]Dragon> dunno what he did wrong
08.45.30 #       <[IDC]Dragon> hey, the OndioFM build fits as rombox!
08.46.27 #       <LinusN> nice
08.46.53 #       <[IDC]Dragon> another 0.3 sec boot time gained
08.47.18 Join    amiconn [0] (~jens@pD95D194F.dip.t-dialin.net)
08.47.18 #       <LinusN> wooooo
08.47.54 #       <plok> boot time on the iRiver is very long :( (H340 at least)
08.52.11 #       <LinusN> i heard it takes ages if you use the id3 database
08.53.17 ***     Saving seen data "./dancer.seen"
08.53.35 Join    webguest84 [0] (~0c68cc30@labb.contactor.se)
08.53.47 Quit    webguest84 (Client Quit)
08.55.22 Join    AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
08.55.35 #       <plok> I don't use the database but it still takes roughly 10 seconds to boot up I'd guess
08.57.31 #       <LinusN> the H120 takes quite a while too
09.11.24 Join    Zagor [242] (~bjst@labb.contactor.se)
09.11.48 #       <LinusN> Zagor: welcome
09.12.16 #       <Zagor> my ribs hurt :)
09.12.33 #       <LinusN> Zagor: i'm having problems deciding how to handle the iriver #ifdefs in for example backlight.c
09.13.01 #       <LinusN> i'm opting for #ifdef IRIVER_H100
09.14.10 #       <Zagor> yes, i agree. i think when the conditional is "which circuit board is this", the general player define is suitable
09.14.22 #       <LinusN> good
09.14.47 #       <Zagor> we can always refine it later if we find the need
09.15.08 #       <LinusN> we could have a PLATFORM define with several values
09.15.22 #       <LinusN> #if PLATFORM == IRIVER_H100
09.15.46 #       <Zagor> sure, no problem
09.16.06 #       <LinusN> i'll go for #ifdef IRIVER_H100 for now
09.19.19 #       <[IDC]Dragon> we already have PLATFORM_ID, but it's use was discouraged
09.19.39 #       <[IDC]Dragon> because we should check for features instead
09.20.16 #       <[IDC]Dragon> oh, forget that
09.20.30 #       <[IDC]Dragon> utter bullshit, I did that locally
09.20.41 #       <Zagor> :)
09.20.49 #       <LinusN> you had me confused for a while...
09.21.06 #       <[IDC]Dragon> we have ARCHOS_xxx, which are flags
09.21.11 #       <LinusN> imho, feature checks are platform specific
09.21.33 #       <[IDC]Dragon> yes, but you check for the feature,not the platform
09.21.38 #       <LinusN> but we should go from ARCHOS_xxx to PLATFORM= instead
09.22.01 #       <[IDC]Dragon> recently; ilike multi-valued items, since the # of platforms is growing
09.22.09 #       <[IDC]Dragon> agreed
09.22.27 #       <[IDC]Dragon> because this is another bunch of flags
09.22.49 #       <LinusN> my view of this is:
09.23.06 #       <LinusN> HAVE_xxx are for general features, like HAVE_BACKLIGHT
09.23.32 #       <[IDC]Dragon> for the backlight, I'd say CONFIG_BACKLIGHT = aaa|bbb|ccc for different hookups
09.23.34 #       <LinusN> PLATFORM_xxx is the platform, eg IRIVER_H100 or ARCHOS_RECORDER
09.24.25 #       <LinusN> [IDC]Dragon: agreed
09.24.42 #       <LinusN> but the CONFIG_BACKLIGHT values may differ between platforms
09.24.52 Join    uski [0] (~uski@ALagny-151-2-6-37.w82-121.abo.wanadoo.fr)
09.25.07 #       <[IDC]Dragon> yes, or not exist if no backlight
09.25.14 #       <LinusN> then we agree
09.25.17 #       <LinusN> uski: hi
09.25.41 #       <uski> hi LinusN :)
09.25.46 #       <uski> received my package ?
09.25.57 #       <LinusN> uski: I got your stuff
09.26.02 #       <uski> ok
09.26.04 #       <LinusN> :-)
09.26.07 Join    Tron|Uni [0] (~tron@hobbit.chemie.uni-hamburg.de)
09.26.15 #       <uski> what's up ? long time no see
09.26.32 #       <Tron|Uni> hi1
09.26.40 #       <Tron|Uni> err, "hi!"
09.27.40 #       <LinusN> uski: not much, i'm working a lot on the iriver port
09.32.36 #       * Bagder crawls in
09.33.31 #       <Bagder> nice warning flood yday LinusN ! :-)
09.33.42 #       <Bagder> 1254 ought to be some kind of record!
09.34.48 #       <Zagor> :)
09.37.19 #       <LinusN> Bagder:  :-)
09.39.30 Join    pillo [0] (~trillian@navlab03.dei.unipd.it)
09.41.01 #       <LinusN> does Dave Hooper pop into this channel?
09.47.38 #       <LinusN> does the H300 have a real time clock?
09.58.05 #       <LinusN> Bagder: u there?
09.58.10 Join    amiconn_ [0] (~jens@pD9E7FC12.dip.t-dialin.net)
09.58.23 #       <Zagor> he does sometimes
09.58.58 #       <LinusN> i want to add his scrambling code to our scrambler
09.59.21 #       <Bagder> I'm here
10.00.18 #       <LinusN> can we change the config/make system so we can build a target without scrambling?
10.01.17 #       <LinusN> currently it requires a $tool
10.01.48 #       * Bagder looks
10.01.51 Join    iRiverMan [0] (~acbcd005@labb.contactor.se)
10.02.02 #       <iRiverMan> hi
10.02.06 #       <LinusN> hi
10.03.34 #       <Bagder> LinusN: make the tool named cp for now
10.03.52 #       <LinusN> can't do that
10.04.09 #       <LinusN> it is prefixed with the path to the rockbox tools dir
10.04.40 #       <Bagder> want me to fix?
10.04.54 #       <LinusN> please
10.05.02 #       * Bagder dives
10.05.37 #       <LinusN> i'd like to add the iriver scrambling algorithm, but the source is currently unavailabe
10.05.49 Quit    ripnetUK ()
10.06.12 #       <Zagor> the link is dead?
10.06.20 #       <Zagor> i have it downloaded
10.06.28 #       <LinusN> DNS doesn't resolve
10.06.38 #       <LinusN> do we have his permission btw?
10.07.28 Quit    amiconn (Nick collision from services.)
10.07.28 Nick    amiconn_ is now known as amiconn (~jens@pD9E7FC12.dip.t-dialin.net)
10.08.12 #       <Bagder> LinusN: try this
10.08.28 #       <Bagder> or 'try now' rather
10.08.34 #       <LinusN> ok
10.08.43 #       <Zagor> LinusN: the license allows it, with a bsd-style banner clause. we can ask him for an exception to the clause.
10.08.54 Quit    [IDC]Dragon ()
10.09.43 #       <amiconn> hi all
10.09.50 #       <Bagder> hi Jens
10.10.25 #       <LinusN> Bagder: works, but now it UCL-packs.....
10.11.11 #       <Bagder> I didn't change that
10.11.29 #       <Bagder> that's a different problem
10.11.33 #       <LinusN> i know, i didn't get that far before
10.12.05 #       <Bagder> lemme think a while on how to correct that
10.12.15 #       <Bagder> unless you have an idea
10.12.17 #       <amiconn> Zagor: Next button issue: If you enter a sub-browser (plugins/ langs etc) from the menu, the first entry gets selected immediately. This seems to be a player-only issue
10.13.27 #       <LinusN> it shouldn't uclpack targets that don't support flashing
10.13.37 #       <LinusN> like the player for instance
10.13.50 #       <Bagder> the question is how it is nicest done in the makefile
10.14.19 #       <Bagder> probably the target shouldn't be included in the all: line
10.14.32 #       <amiconn> Zagor: I wonder how this happens. I thought the button code does only send *one* button event for button down, then waits until repeat kicks in, then send button|BUTTON_REPEAT events continiuously until release, then sends one single release event.
10.14.42 #       <Bagder> like how the ROMTARGET already works
10.14.55 #       <LinusN> exactly
10.15.12 #       <Bagder> I'll work on a fix
10.15.13 #       <Zagor> amiconn: yes, that's how it works
10.15.55 #       <amiconn> So I wonder what causes the sub-browser issue on the player. The button down event gets "eaten" by the menu code entering the sub-browser...
10.16.38 #       <Zagor> looking...
10.17.37 #       <Zagor> aha. "run" is now play+release, since play+repeat is context menu...
10.17.47 #       <Zagor> the puzzle keeps growing :)
10.18.20 #       <Zagor> (i.e. you see the same problem on recorder if you use PLAY to select the "browse plugins" menu entry)
10.20.32 #       <Bagder> LinusN: ... and update!
10.22.07 #       <LinusN> Bagder: how do i make it not to build plugins?
10.22.24 #       <Bagder> ifdef them in SOURCES
10.22.45 #       <LinusN> what is the plugins="yes" for in configure?
10.22.52 #       <Bagder> ah, right
10.22.56 #       <Bagder> that's how I made it
10.22.58 #       <Bagder> set it to ""
10.23.05 #       <Bagder> plugins=""
10.23.13 #       <LinusN> i have tried not to set it, but it doesn't work
10.23.17 #       <amiconn> Zagor: Ah, yes. I did not get that since I usually use Right to enter the browsers. Strangely, it works for Ondio, which has no separate Play...
10.24.08 #       <Zagor> that's because the ondio context menu is broken :) (I just noticed)
10.24.28 #       <Bagder> LinusN: odd, it worked for the ondios before
10.24.32 #       <LinusN> plugins="" doesn't help
10.24.51 #       <LinusN> it still tries to build the plugins library
10.25.10 #       <Zagor> hmm, tricky one
10.26.52 #       <LinusN> ENABLEDPLUGINS isn't used anywhere
10.29.02 #       <amiconn> LinusN: When plugins were disabled for Ondio, it did also still build the plugin lib. Seems that the Makefile for the plugin lib needs a fix
10.32.48 #       <Bagder> LinusN: ENABLEDPLUGINS is used in plugins/Makefile
10.33.03 #       <LinusN> Bagder: check my commit
10.33.04 #       <Bagder> use it in lib/Makefile as well, and I think it should work
10.33.23 #       <LinusN> i think it should be done in apps/Makefile
10.33.51 #       <Bagder> right, that's probably nicer
10.34.01 #       <Bagder> then you can remove it from plugins/Makefile
10.34.32 #       <LinusN> doing it now
10.35.15 #       <LinusN> done
10.35.36 #       <LinusN> ok, now the iriver target builds ok
10.36.43 #       <Bagder> cool
10.36.47 #       <Bagder> gotta run off
10.37.34 #       <LinusN> cu
10.40.34 #       * LinusN has a fairly safe lead the wiki statistics :-)
10.48.07 #       <Chronic007> I was noticing that earlier....thanks for all your hard work Linus
10.53.18 ***     Saving seen data "./dancer.seen"
10.53.51 Join    PaulS [0] (~437e19f6@labb.contactor.se)
10.55.21 #       <Chronic007> oh-yes, the good iriver port conversation is about to begin
11.04.46 Join    hima [0] (~hima_mhmd@62.139.64.184)
11.05.27 Join    MooMaunder [0] (~me@194.152.87.150)
11.10.29 Join    ashridah [0] (ashridah@220.253.119.48)
11.12.11 Quit    iRiverMan ("CGI:IRC (EOF)")
11.26.17 Part    hima
11.48.07 #       <LinusN> PaulS: u there?
11.59.35 #       <PaulS> Yep.. 
12.01.30 #       <LinusN> any luck with the jtag?
12.01.37 #       <PaulS> Thanks for the tip about pulling up the power supply line.  When I hold the system reset, it doesn't power off.
12.02.09 #       <LinusN> i have added valuable info for you in the schematics
12.02.29 #       <LinusN> cd ..
12.03.10 #       <PaulS> I didn't try JTAG again.  I did try the BDM interface again, but BKPT still didn't seem to do anything, so I imagine I'm using the wrong pads.
12.03.37 #       <PaulS> LinusN: Valuable info?  Hmm!
12.03.51 #       <LinusN> check the "connectors" schematic
12.04.16 #       <LinusN> now you can trace the correct pads from the debug connector
12.04.50 Quit    PaulS ("CGI:IRC (EOF)")
12.08.26 Join    PaulS_ [0] (~437e19f6@labb.contactor.se)
12.09.29 #       <PaulS_> LinusN: Thanks a lot.  This will take the guesswork out of it.  So far I only know I had the CPU reset correct.
12.14.26 #       <LinusN> i hope it helps
12.15.00 #       <PaulS_> I'm downloading the naked pics as I speak to see how far off I was.
12.15.13 Nick    PaulS_ is now known as PaulS (~437e19f6@labb.contactor.se)
12.17.16 #       <PaulS> Congrats on the blinkenleds, BTW, as well as the (presumably not actually functional) rockbox build.
12.17.45 #       <LinusN> does the H300 have a real time clock?
12.17.46 #       <PaulS> Were you using the drive access light, or the charging LED?
12.19.43 #       <LinusN> the backlight
12.20.01 #       <PaulS> Ah!  Those are LEDs too...
12.25.58 #       <ashridah> LinusN: sneaky :)
12.30.42 #       <PaulS> It appears that my guesses about the debug pads seem to agree with the connector schematic.
12.30.44 #       * LinusN sends his second coldfire patch to the binutils project
12.32.56 #       <dwihno> LinusN: How many of those patches has been sent without any response?
12.33.42 #       <LinusN> my very first patch (the windows resource compiler) still hasn't received a response
12.34.04 #       <LinusN> but the first coldfire patch has been accepted
12.34.09 Join    R3nTiL [0] (~zorroz@164-250-30-217.kgts.ru)
12.36.17 #       <dwihno> neato!
12.36.26 #       <dwihno> It's about giving stuff back! :)
12.39.17 #       <LinusN> yup
12.42.10 #       <PaulS> Good night, folks.
12.42.39 Part    PaulS ("Z")
12.44.16 #       <LinusN> lunch
12.52.12 Join    HuwSy [0] (~na@213-232-83-64.dsl.prodigynet.co.uk)
12.53.11 #       <HuwSy> lil help, im looking to flash my recorder10 back to the original firmware, whats the easiest way
12.53.20 ***     Saving seen data "./dancer.seen"
12.56.35 #       <LinusN> rename the original firmware file to firmware_rec.bin and run the firmware_flash.rock plugin again
12.56.57 #       <LinusN> assuming you did back up the original firmware when you flashed rockbox the first time
12.57.02 #       <HuwSy> iv lost the original file be the problem
12.57.17 #       <LinusN> which version was it?
12.57.27 #       <HuwSy> 1.27c
12.57.52 Join    [IDC]Dragon [0] (~d90a3255@labb.contactor.se)
12.58.03 Quit    plok (Ping timeout: 14400 seconds)
12.58.30 #       <LinusN> you can find the original firmware here: http://homepage.ntlworld.com/cyborgsystems/CS_Main/RockBox/Archos/jbrv1_bin_128.zip
12.58.52 #       <HuwSy> thank you
12.59.09 #       <LinusN> it's the "internal_rom_20000...." file
12.59.31 #       <LinusN> rename it to firmware_rec.bin and put it in the root of your archos, then run firmware_flash.rock
12.59.39 #       <LinusN> and pray....
12.59.45 #       <LinusN> :-)
12.59.57 #       <[IDC]Dragon> he's exaggerating...
13.00.09 #       <LinusN> seriously, i don't know if 1.28 works on the rec10, but i assume that it does
13.00.46 #       <LinusN> the only prob would be the hw mask, but i assume that firmware_flash.rock preserves it
13.00.58 #       <[IDC]Dragon> yes, it does
13.02.39 #       <LinusN> than all is fine.
13.06.46 #       <HuwSy> hum... its not letting me load up into rockbox to even attempt a flash. i think its overly flat
13.07.10 #       <HuwSy> oh well ill hopefully get it sorted later, thanx for the help
13.08.59 Quit    HuwSy ()
13.11.32 #       <[IDC]Dragon> everybody wants a flashback...
13.12.09 #       <[IDC]Dragon> amiconn: do you read?
13.31.18 Quit    R3nTiL ()
13.34.15 #       <amiconn> [IDC]Dragon: Now I'm here
13.40.16 #       <[IDC]Dragon> hi
13.40.30 #       <[IDC]Dragon> I have the flash plugin working now
13.41.50 #       <[IDC]Dragon> so you could flash yours tonight
13.42.08 #       <[IDC]Dragon> even RomBox works for me :-)
13.45.33 #       <amiconn> So it should work on the SP for sure
13.46.01 #       <amiconn> Did you already look into the RoLo issues with the archos fw?
13.47.13 #       <[IDC]Dragon> no, not yet
13.47.52 #       <[IDC]Dragon> I  actually forgot about that issue
13.48.32 #       <amiconn> That reminds me that we wanted to add a table of issues to the wiki topic, together with status
13.48.55 #       <[IDC]Dragon> yes please
14.06.52 Part    Chronic007
14.40.44 #       <[IDC]Dragon> Bagder: reading?
14.49.51 Join    zoevi [0] (~d9f69ab4@labb.contactor.se)
14.53.24 ***     Saving seen data "./dancer.seen"
14.58.10 #       <Bagder> reading now
14.58.23 Join    webguest46 [0] (~d96ee3e8@labb.contactor.se)
14.59.51 Quit    zoevi ("CGI:IRC")
15.01.42 #       <Bagder> LinusN: time to add iriver to the cvs build table?
15.01.51 #       <[IDC]Dragon> Bagder: how about enabling the Ondio daily build?
15.02.09 #       <Bagder> me fix!
15.02.33 #       <[IDC]Dragon> the download, I mean, with the pretty picture and stuff
15.02.41 #       <Bagder> yes
15.02.48 #       <[IDC]Dragon> ok
15.02.49 #       <Bagder> the whole package
15.03.16 #       <[IDC]Dragon> did Jens send you a picture?
15.03.21 #       <Bagder> yes
15.03.31 #       <Bagder> ah, no
15.03.33 #       <amiconn> No I didn't. Have to close the Ondio first.
15.03.34 #       <Bagder> only your pics
15.03.40 #       <Bagder> http://www.rockbox.org/ondio/
15.04.05 #       <[IDC]Dragon> those are my FM pictures
15.04.28 Join    elinenbe [0] (~elinenbe_@65.115.46.225)
15.04.56 #       <[IDC]Dragon> then use it for both, for the time being
15.05.02 #       <Bagder> yes
15.05.26 #       <elinenbe> LinusN: a huge congrats!  Great work... everything starts somewhere!
15.06.01 #       <amiconn> [IDC]Dragon: How did you take the pictures? With the scanner?
15.06.26 #       <[IDC]Dragon> amiconn: digicam. mine was also not closed for the pic, just placed
15.07.01 #       <[IDC]Dragon> scanner is even better, if you have one of those thick flatbeds
15.07.42 #       <[IDC]Dragon> I have a thin one with a LED bar, has no depth focus at all
15.08.07 #       <Bagder> reload daily build page
15.08.41 #       <[IDC]Dragon> that was quick
15.08.43 #       <LinusN> i think adding iriver to the daily builds page is a bit premature
15.08.52 #       <LinusN> elinenbe: thanks
15.09.04 #       <Bagder> LinusN: it would help us not break it when we modify things
15.09.12 #       <Bagder> and vice versa
15.09.22 #       <LinusN> it still needs a patched version of the compiler
15.09.37 #       <LinusN> and it only compiles crt0.S and backlight.c :-)
15.09.46 #       <Bagder> atm, yes
15.10.04 #       <Bagder> oh well, I won't push it
15.10.09 #       <elinenbe> LinusN: if I have an iriver, can I flash the rockbox firmware?
15.10.11 #       <LinusN> what the heck, add it then
15.10.25 #       <elinenbe> just to see the backlight flash?
15.10.29 #       <Bagder> LinusN: do we have the patch compiler on the host?
15.10.32 #       <Bagder> patched
15.10.40 #       <elinenbe> but, how would I flash it back to the iriver firmware?
15.10.41 #       <LinusN> elinenbe: yes, but you won't be able to restore the original firmware
15.10.54 #       <amiconn> [IDC]Dragon: My digicam doesn't make such nice pics as yours. First it's only 2 Mpixel, second it has no macro feature, closest range is ~60 cm
15.10.57 #       <LinusN> so your player will be a paperweight
15.11.14 #       <amiconn> I'll try to do it with the scanner @work tomorrow
15.11.17 #       <ashridah> elinenbe: you'd be fairly screwed without being able to take it apart and plug in a bdm to restore the original firmware
15.11.24 #       <LinusN> Bagder: i sent my second patch to the binutils project today
15.12.06 #       <Bagder> you will be the coldfire binutils king! ;-)
15.12.12 #       <LinusN> hehe
15.12.23 #       <Bagder> LinusN: is the gcc/binutils installed/working on labb?
15.12.23 #       <elinenbe> LinusN: I wouldn't put it up on the daily builds page yet then... that is just asking for trouble.
15.12.40 #       <Bagder> no daily builds, no
15.12.45 #       <Zagor> you will be cold fire binutils helpdesk ;)
15.12.46 #       <Bagder> but the cvs build table
15.12.49 #       <LinusN> elinenbe: only the build status, not any downloads
15.12.55 Quit    gromit``` (Read error: 110 (Connection timed out))
15.13.17 #       <[IDC]Dragon> amiconn: we only need the medium and small size pic, 2 MP from 60 cm should be enough for that
15.13.25 #       <LinusN> Bagder: no m68k compiler on labb, only on my computer
15.13.32 #       <Bagder> Zagor: check the daily build log careful tomorrow, the ondios should get built now
15.13.38 #       <Zagor> yup
15.13.49 #       <ashridah> what does BDM stand for anyway? 
15.13.59 #       <ashridah> breakout debugging module ?
15.14.00 #       <Bagder> LinusN: aha, care you install it on labb so that we can get it cvs-built?
15.14.01 #       <LinusN> ashridah: Background Debug Mode
15.14.04 #       <ashridah> ah. 
15.14.07 #       <ashridah> that was my second guess
15.14.10 #       <Bagder> s/you/to
15.14.12 #       <LinusN> Bagder: ok
15.14.22 #       <[IDC]Dragon> amiconn: the big one wast just my raw data, before scaling it to about the size I found on the build page
15.16.18 #       <amiconn> [IDC]Dragon: Another problem with digicam is to get the lighting right, and the neutral gray background
15.22.15 #       <[IDC]Dragon> amconn: I went on the balcony, placed it on the white backside of a calendar
15.22.31 #       <[IDC]Dragon> s/amconn/amiconn (sorry)
15.22.57 #       <amiconn> [IDC]Dragon: Use TAB completion ;)
15.23.05 #       <[IDC]Dragon> the white balance was still way off, but that can be corrected
15.23.28 #       <[IDC]Dragon> tab doesn't work if there's more people with A
15.23.29 #       <amiconn> The balcony approach does only work if you are at home when there is daylight
15.23.38 #       <Bagder> <g>
15.24.20 #       <[IDC]Dragon> just make a picture with any light, I'll try to fix it
15.24.40 #       <[IDC]Dragon> diffuse light preferred
15.24.56 Join    gromit` [0] (~gromit@ALagny-151-2-10-250.w82-121.abo.wanadoo.fr)
15.26.17 #       <amiconn> [IDC]Dragon: Does your Ondio really have such a strong blue colour? Mine does look more violet...
15.28.44 #       <[IDC]Dragon> it's a bit more violet than it appears
15.32.38 Quit    uski (Read error: 110 (Connection timed out))
15.43.04 #       <LinusN> Bagder: /usr/local/m68k-gcc
15.43.14 #       <Bagder> neato
15.43.18 #       <LinusN> patched with my latest addition
15.47.27 #       <[IDC]Dragon> Bagder: I guess tomorrow there will automagically appear something for the download link?
15.47.35 #       <Bagder> yes
15.47.39 #       <Bagder> if everything works
15.47.44 #       <[IDC]Dragon> ;-)
15.48.39 #       <Bagder> iriver h100 added to cvs build table
15.48.47 #       <LinusN> nice
15.49.19 #       <[IDC]Dragon> I don't see it, mabe after the next commit?
15.49.27 #       <Bagder> yes
15.50.02 #       <Bagder> I just added it to the script that builds stuff after each commit
15.51.53 #       <LinusN> and you added the compiler to the PATH?
15.51.56 #       <Bagder> yes
15.52.12 #       <Bagder> time to add the ondios to http://www.rockbox.org/docs/devicechart.html ?
15.52.39 #       <[IDC]Dragon> why not?
15.53.00 #       <Bagder> don't look at me! ;-)
15.53.05 #       <LinusN> [IDC]Dragon: your job
15.53.16 #       <[IDC]Dragon> ok, not now (no cvs)
15.53.28 #       <Bagder> I'm off
15.53.37 #       <LinusN> cu
15.56.02 #       <[IDC]Dragon> who did the mp3ClipGen.vbs script?
15.56.14 #       <[IDC]Dragon> I fail to remember
15.59.37 #       * [IDC]Dragon googles like crazy
16.07.41 #       <amiconn> [IDC]Dragon: Search the ml
16.11.23 #       <LinusN> time to go
16.11.25 #       <LinusN> bye all
16.11.40 Part    LinusN
16.13.09 #       <[IDC]Dragon> I tried. Brian Wolven is a candidate, but I haven't found a proof
16.16.49 #       <[IDC]Dragon> he is, now I found it
16.17.19 #       <[IDC]Dragon> or? no, this was playlist scripts
16.19.33 #       * amiconn is looking into the script
16.20.29 #       <amiconn> Hmm, no hint in there :(
16.20.30 #       <[IDC]Dragon> seems to be Brian: http://www.rockbox.org/mail/archive/rockbox-archive-2004-03/1332.shtml
16.23.03 #       <amiconn> It does look like that, yes
16.23.22 #       <[IDC]Dragon> the voice UI is olter than I thought
16.23.28 #       <[IDC]Dragon> older
16.23.56 #       <[IDC]Dragon> and v2.2 even more
16.38.28 Join    mecraw [0] (~lmarlow@69.2.235.2)
16.53.26 ***     Saving seen data "./dancer.seen"
17.16.59 Quit    webguest46 ("CGI:IRC (EOF)")
17.19.54 Join    ripnetUK [0] (~mirc@82-70-100-230.dsl.in-addr.zen.co.uk)
17.20.16 #       * ripnetUK builds a 68000 cross compiler
17.20.49 #       <ripnetUK> Im trying to cook a m68k cross compiler - do I need to use the cvs to get LinusN's patches in, or does that only apply if im using gdb? 
17.27.29 #       <Zagor> i'm not sure what his latest patch was
17.35.48 #       <ripnetUK> the onbe im talking about was assembling the 68k equivelent of sse instructions
17.36.10 #       <ripnetUK> i guess its a bit academic until we have working code anyway :)
17.36.21 #       <Zagor> the EMAC, yes. for that you need his patch.
17.42.56 Quit    ashridah ("sleep")
17.43.15 Part    Zagor
18.14.23 Join    marc77 [0] (~marc@pub212004076150.hfc.datazug.ch)
18.19.32 Join    bagawk [0] (~a78001db@labb.contactor.se)
18.20.04 #       <bagawk> hey
18.20.24 Part    bagawk
18.23.14 Join    uski [0] (~uski@lns-th2-5f-81-56-234-40.adsl.proxad.net)
18.25.57 Quit    [IDC]Dragon ("CGI:IRC")
18.40.50 Part    pillo
18.50.51 Join    _aLF [0] (~Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net)
18.50.53 #       <_aLF> hi
18.52.09 Join    Tim[RIP] [0] (Tim_RIP_@83.73.82.114.ip.tele2adsl.dk)
18.52.18 Part    Tim[RIP]
18.53.27 ***     Saving seen data "./dancer.seen"
18.57.33 Quit    marc77 (" HydraIRC -> http://www.hydrairc.com <- IRC has never been so cool")
18.59.38 Quit    ripnetUK ()
19.05.59 #       <amiconn> Bagder: The channel's topic is a bit outdated...
19.09.08 Quit    AciD (Read error: 104 (Connection reset by peer))
19.26.35 Join    AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
19.30.44 Join    [IDC]Dragon [0] (~idc-drago@pD9FF80B1.dip.t-dialin.net)
19.30.56 #       <[IDC]Dragon> hi again!
19.31.22 #       <[IDC]Dragon> amiconn: in case you'd like to flash: http://joerg.hohensohn.bei.t-online.de/archos/flash/flash_ondiosp.zip
19.31.54 #       <[IDC]Dragon> plus a cvs up-to-date build for the plugins, of course
19.36.43 #       <uski> [IDC]Dragon, rockbox works on the Ondio ?
19.36.56 #       * uski should try to keep up to date with the latest news :)
19.37.00 Quit    AciD (Connection reset by peer)
19.37.01 #       <[IDC]Dragon> indeed
19.37.36 Join    AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
19.37.42 #       <uski> if i buy an Ondio, when will I be able to run rockbox on it ?
19.37.54 #       <uski> ;)
19.38.05 #       <[IDC]Dragon> uski: now
19.38.42 #       <[IDC]Dragon> or rather: as soon as you'll get it delivered ;-)
19.38.44 #       <uski> you have support for the NAND flash ?
19.38.52 #       <uski> lol
19.39.00 #       <[IDC]Dragon> it's an internal MMC
19.39.06 #       <uski> oh ok
19.39.09 #       <uski> so i can be changed ?
19.39.12 #       <uski> s/i/it
19.39.30 #       <uski> or is it a bulk MMC chip, without the connector ?
19.39.42 #       <[IDC]Dragon> no, it's a chip that does MMC protocol
19.40.06 #       <[IDC]Dragon> but you can use an external MMC, too
19.40.27 #       <uski> ok
19.40.44 #       <uski> interesting.. :
19.40.46 #       <uski> :)
19.40.59 #       <[IDC]Dragon> or, you unsolder the chip and hook upo an MMC internally, there's enough space
19.41.13 #       <uski> even more interesting
19.41.29 #       <[IDC]Dragon> would be cool: 1 GB internal, plus n*1GB external
19.41.35 #       <uski> exactly :))
19.41.41 #       <uski> but a bit expensive today
19.41.50 #       <uski> but maybe in a few months prices will be lower
19.42.08 #       <[IDC]Dragon> I'm away now
19.42.12 #       <uski> oh, by the way, is there a native US english speaker here ? i need some help for my english homeworks ;) only 5 minutes..
19.42.16 #       <uski> see you [IDC]Dragon !
19.51.56 Quit    [IDC]Dragon ()
20.03.19 Join    ripnetUK [0] (~mirc@82-70-100-230.dsl.in-addr.zen.co.uk)
20.12.02 Quit    AciD (Read error: 104 (Connection reset by peer))
20.21.01 Quit    elinenbe (" Like VS.net's GUI?  Then try HydraIRC -> http://www.hydrairc.com <-")
20.29.23 Join    AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
20.53.31 ***     Saving seen data "./dancer.seen"
21.22.15 Quit    ripnetUK ()
21.45.08 Join    scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
22.20.00 Join    [IDC]Dragon [0] (~idc-drago@pD9FF8407.dip.t-dialin.net)
22.20.17 #       <amiconn> hi again Jörg
22.20.30 #       <[IDC]Dragon> hi there!
22.20.39 #       <[IDC]Dragon> flashed? ;-)
22.20.48 #       <uski> ooo
22.20.57 #       <uski> [IDC]Dragon, the flashing guy.
22.20.59 #       <amiconn> [IDC]Dragon: Nope, not yet
22.21.10 #       <[IDC]Dragon> :-(
22.21.23 #       <amiconn> [IDC]Dragon: Some questions beforehand:
22.21.52 #       <[IDC]Dragon> sure
22.22.07 #       <amiconn> (1) Do you also get the strange RoLo behaviour with the archos fw on your FM? (just for comparison)
22.22.19 #       <[IDC]Dragon> I haven't tried
22.22.28 #       <amiconn> (2) Do you believe it's safe for the SP? You obviously couldn't test...
22.23.04 #       <uski> (what's the SP?)
22.23.07 Quit    methangas (" HydraIRC -> http://www.hydrairc.com <- irc client ownage!")
22.23.34 #       <amiconn> uski: There are 2 different Ondio models, see the wiki article and/or archos site
22.23.37 #       <[IDC]Dragon> I think it's safe. the bootloader is identical, I put the original plus Rockbox into the image (one at least should work), and the bootloader has minimon as the last resort
22.23.38 #       <uski> ok
22.23.39 #       <uski> ty
22.24.38 #       <[IDC]Dragon> I can try the SP image, if it comforts you
22.24.55 #       <amiconn> [IDC]Dragon: That's why I'm asking whether you get the strange rolo behaviour too. If it is so, and archos fw works for you from flash, flashing should be safe for me too
22.25.02 #       <[IDC]Dragon> MAS and tuner shoudn't matter at boot time
22.25.24 #       <amiconn> (because then the strange behaviour is caused by some init rockbox does)
22.25.34 #       <[IDC]Dragon> the rolo'ed version is different from the real ROM one
22.25.58 #       <amiconn> [IDC]Dragon: If you try the SP image on fm, chances are that it hangs on boot with both firmwares
22.26.20 #       <[IDC]Dragon> I can uart-boot
22.26.50 #       <[IDC]Dragon> in fact, I have to, because the plugin won't let me use the wrong one
22.26.55 #       <amiconn> ...because the MAS init tries to start the decoding application, but the MAS memory cells to do so have different addresses. So the init waits forever
22.28.04 #       <[IDC]Dragon> ok, so it may hang. was just a suggestion to ease you.
22.28.06 #       <amiconn> If possible, just try RoLo into archos fw
22.28.59 #       <[IDC]Dragon> I'll try, but fail to see why this is comforting or not
22.29.36 #       <amiconn> Btw: I just found a way to speed up mmc writing by 50%, while still polling. Unfortunately this doesn't work for reading, have to implement DMA for speedup
22.29.56 #       <[IDC]Dragon> whoo, how?
22.30.15 #       <amiconn> Sending back-to-back by properly switching the SCI mode
22.30.45 #       <amiconn> I did already perform a quick test, the 50% are real-world, no estimation
22.31.13 #       <[IDC]Dragon> but you have a poll loop, with a certain reaction time?
22.31.20 #       <uski> ooo interesting: it seems to be possible to add a tuner to the SP model, simply by soldering some components
22.31.43 #       <amiconn> Yes, but for sending, I can use the double-buffering of the SCI if it is set to send-only
22.32.25 #       <amiconn> So the transfer-loop housekeeping is done in the background, while the last byte is still transferring
22.33.14 #       <[IDC]Dragon> nice
22.33.50 #       <amiconn> Just optimizing a bit further (remembering the last status to avoid switching it every time)
22.34.27 #       <amiconn> Maybe I don't need DMA for writing at all
22.34.48 #       <[IDC]Dragon> if you do back to back already, then no
22.36.22 #       <amiconn> I'm now pretty close to the theoretical max speed for writing. Theory says < ~350 kByte/s, real world is now ~330 kByte/s
22.36.43 #       <[IDC]Dragon> for readig, the bitswap loop may poll the DMA pointer, running behind it, for minimum latency.
22.36.58 #       <[IDC]Dragon> (sorry if you already said that)
22.37.06 #       <amiconn> Ah, nice idea.
22.37.31 #       <amiconn> My idea so far was to follow the block count, swapping each block as soon as it is completed
22.38.09 #       <[IDC]Dragon> for multiples, yes, also possible
22.38.32 #       <[IDC]Dragon> but gives a 1 sector swap latency at the end
22.38.48 #       <amiconn> Your approach might deliver the lowest latency, but the block-wise approach may even allow to yield() once
22.39.01 #       <amiconn> So it's not blocking the whole box
22.40.32 #       <[IDC]Dragon> rolo'ing Archos s/w hangs at about 60% of its progress bar
22.40.59 #       <amiconn> Ooops. This is different from the SP.
22.41.05 #       <[IDC]Dragon> how about one yield() and then running behind the DMA?
22.41.36 #       <amiconn> I could also yield every time the bitswap has catched up
22.41.53 #       <amiconn> s/catched/caught/
22.42.12 #       <[IDC]Dragon> but that may happen close before the end
22.42.36 #       <amiconn> Or even better, yield every time the bitswap has caught up, but only if > n bytes to go
22.43.08 #       <[IDC]Dragon> hmm
22.43.57 #       <amiconn> Problem: The DMA is chunked into block size anyway, with some necessary polling inbetween
22.44.12 #       <[IDC]Dragon> I think if we do it at the start, we're more sure to reach it again at the end, then stick as close as possible
22.44.25 #       <[IDC]Dragon> do the uncertain part first
22.45.12 #       <[IDC]Dragon> what block size do you have in mind?
22.45.35 #       <amiconn> Yes, but a complete transfer might run for several seconds. Just yielding once would not help much
22.45.35 #       <amiconn> The block size is fixed, 512 bytes
22.45.35 #       <[IDC]Dragon> ah, Ok, I was thinking in sectors
22.45.52 #       <[IDC]Dragon> huh?
22.46.01 #       <[IDC]Dragon> (confused again)
22.46.25 #       <[IDC]Dragon> if you do multi-block, it can be quite long?
22.46.32 #       <[IDC]Dragon> in one go
22.46.49 #       <[IDC]Dragon> with no further command
22.46.59 #       <amiconn> Each data block comes in with a start byte in front, which has to be polled for (worst case: 10 ms with the internal flash), the 512 bytes of data, then 2 bytes crc
22.47.51 #       <amiconn> Multi-block transfer is unlimited with MMC, you send a start command, and the card starts transferring block after block until you send a stop command (reading) or a stop token (writing)
22.48.00 #       <[IDC]Dragon> ok. Then we can poll for start, set the DMA, yield, run behind bitswapping.
22.48.15 #       <[IDC]Dragon> sequence repeats for each sector
22.49.02 #       <uski> gtg
22.49.12 #       <uski> have a nice technical talk ;)
22.49.39 #       <amiconn> For sector-wise, I think its better to use this sequence: poll for start, set DMA, bitswap previous block, yield, wait for end of DMA
22.50.38 #       <amiconn> If the thread itself should do the run-behind bitswap continuously, the poll-for-next would have to be done in the ISR
22.53.33 ***     Saving seen data "./dancer.seen"
22.54.26 #       <[IDC]Dragon> I have to leave now
22.54.27 Quit    uski ("Leaving")
22.54.38 #       <[IDC]Dragon> (like uski)
22.54.46 #       <[IDC]Dragon> nite!
22.54.52 Quit    [IDC]Dragon ()
22.54.55 #       <amiconn> nite [IDC]Dragon
23.20.14 Quit    AciD (Read error: 104 (Connection reset by peer))
23.20.45 Join    AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
23.44.13 Quit    gromit` ("Client exiting")