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

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

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

#rockbox log for 2016-06-01

00:01:45 Quit JdGordon_ (Ping timeout: 244 seconds)
00:04:17 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
00:51:12 Quit ZincAlloy (Quit: Leaving.)
01:00
01:13:29***Saving seen data "./dancer.seen"
01:36:57 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon)
01:40:15 Quit pamaury (Ping timeout: 258 seconds)
01:40:15 Quit JdGordon (Ping timeout: 258 seconds)
01:56:46 Quit girafe (Read error: Connection reset by peer)
02:00
02:02:51 Join alexweissman [0] (~alexweiss@c-68-51-85-190.hsd1.in.comcast.net)
02:10:43__builtinwhy don't we have an automated check of the source code for whitespace errors?
02:15:04 Quit amayer (Ping timeout: 244 seconds)
02:27:49 Join amayer [0] (~amayer@mail.weberadvertising.com)
02:40:12 Quit Guest65764 (Ping timeout: 250 seconds)
02:58:40 Join JdGordon [0] (~jonno@124-148-153-116.dyn.iinet.net.au)
02:58:40 Quit JdGordon (Changing host)
02:58:40 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon)
03:00
03:01:15 Quit JdGordon_ (Ping timeout: 260 seconds)
03:03:44 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon)
03:05:42 Quit JdGordon (Ping timeout: 244 seconds)
03:13:30***Saving seen data "./dancer.seen"
03:27:12 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon)
03:30:22 Quit JdGordon_ (Ping timeout: 276 seconds)
03:36:13__builtinn1cky: I've made some further changes to the OTP plugin, nothing major
03:37:14 Quit krabador (Quit: Take The Time)
03:38:39__builtinif you want to try it out, it's at https://fwei.tk/rockbox.zip
03:38:57__builtin^ clip zip build for anyone that wants to follow along
03:40:58__builtinGN
03:58:31 Join athidhep [0] (~afoakf@unaffiliated/athidhep)
04:00
04:00:24 Quit michaelni (Quit: Leaving)
04:10:53n1cky__builtin: downloading now
04:11:42 Join michaelni [0] (~michael@chello213047041020.graz.surfer.at)
04:16:34 Join shadows [0] (e@gateway/shell/openshells.net/x-tgibkckioyjtnlsq)
05:00
05:07:51 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon)
05:11:14 Quit JdGordon (Ping timeout: 264 seconds)
05:13:32***Saving seen data "./dancer.seen"
05:29:29 Join Strobokopp [0] (~Strobokop@x5f7684ef.dyn.telefonica.de)
05:32:43 Quit Stroboko1p (Ping timeout: 260 seconds)
05:46:02 Quit athidhep (Quit: athidhep)
05:47:53 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739)
05:52:39 Quit michaelni (Ping timeout: 260 seconds)
06:00
06:05:16 Join michaelni [0] (~michael@chello213047041020.graz.surfer.at)
06:45:32 Quit prof_wolfff (Ping timeout: 240 seconds)
06:51:56 Join PurlingNayuki [0] (~Thunderbi@v163-44-154-238.a00f.g.sin1.static.cnode.io)
07:00
07:08:47 Part edhelas ("Disconnected: closed")
07:13:35***Saving seen data "./dancer.seen"
07:29:35 Quit PurlingNayuki (Remote host closed the connection)
07:32:10 Join prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com)
07:45:44 Join ender` [0] (krneki@foo.eternallybored.org)
07:52:01 Quit pixelma (Remote host closed the connection)
07:52:01 Quit amiconn (Read error: Connection reset by peer)
07:52:46 Join pixelma [0] (~pixelma@rockbox/staff/pixelma)
07:52:50 Join amiconn [0] (~amiconn@rockbox/developer/amiconn)
08:00
08:19:03 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
08:21:47 Join PurlingNayuki [0] (~Thunderbi@v163-44-154-238.a00f.g.sin1.static.cnode.io)
08:28:59 Quit prof_wolfff (Ping timeout: 240 seconds)
08:31:28 Quit PurlingNayuki (Quit: PurlingNayuki)
08:35:23 Join PurlingNayuki [0] (~Thunderbi@v163-44-154-238.a00f.g.sin1.static.cnode.io)
08:56:25 Join PurlingNayuki1 [0] (~Thunderbi@v163-44-154-238.a00f.g.sin1.static.cnode.io)
08:57:27 Quit PurlingNayuki (Remote host closed the connection)
08:57:28 Nick PurlingNayuki1 is now known as PurlingNayuki (~Thunderbi@v163-44-154-238.a00f.g.sin1.static.cnode.io)
09:00
09:13:39***Saving seen data "./dancer.seen"
09:18:42 Quit PurlingNayuki (Ping timeout: 272 seconds)
09:20:42 Join petur [0] (~petur@rockbox/developer/petur)
09:22:11 Quit akaWolf (Ping timeout: 260 seconds)
09:38:23 Join PurlingNayuki [0] (~Thunderbi@v163-44-154-238.a00f.g.sin1.static.cnode.io)
09:40:16 Quit Guest85177 (Ping timeout: 244 seconds)
09:42:02 Join Guest85177 [0] (~Slayer@c-69-255-136-113.hsd1.va.comcast.net)
09:56:57 Join elensil [0] (~edhelas@2001:1c02:1903:d800:cc34:f104:30f:4a82)
10:00
10:02:46 Join prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com)
10:04:58 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf)
10:17:42 Join Boltermor [0] (~Boltermor@subscr-46-148-172-80.dhcp-docsis.net.tomkow.pl)
10:32:16 Join jvoisin [0] (~jvoisin@dustri.org)
10:58:17 Join PaulFertser [0] (paul@paulfertser.info)
10:58:52PaulFertserHey folks. Please tell me which PIDs of those from the OpenMoko VID pool are already in use? I'm preparing a patch for usb.ids list (used by lsusb and others).
11:00
11:00:14PaulFertserAnd it doesn't allow ranges.
11:12:07gevaertsPaulFertser: none yet, I believe, we're still discussing how to allocate them...
11:12:20*gevaerts wishes we had done more at this point
11:12:55gevaertsAnyone to contact when we do?
11:13:31PaulFertsergevaerts: ok, np then, I believe you can freely amend the usb.ids yourself as per https://usb-ids.gowdy.us/read/?action=help?help=mailsubmit instructions. You were already allocated the whole block, so nothing to do from the "OM" side.
11:13:43***Saving seen data "./dancer.seen"
11:14:21gevaertsOK. I'll keep that in mind
11:14:50gevaerts__builtin: we should probably actually do something about this soon
11:38:59 Join krabador [0] (~krabador@unaffiliated/krabador)
11:47:13 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
11:51:57 Join ZincAlloy [0] (~Adium@2a02:8108:8bc0:1664:c491:9256:56eb:9cc5)
12:00
12:06:26 Quit prof_wolfff (Ping timeout: 264 seconds)
12:13:37 Quit krabador (Quit: Take The Time)
12:31:59 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon)
12:33:53 Quit JdGordon_ (Ping timeout: 250 seconds)
12:38:01 Join Guest65764 [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627)
12:44:42 Join krabador [0] (~krabador@unaffiliated/krabador)
12:52:42 Join prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com)
13:00
13:13:47***Saving seen data "./dancer.seen"
13:46:43 Join chrisb [0] (~chrisb@pool-71-175-249-107.phlapa.east.verizon.net)
13:52:41 Quit elensil (Quit: Leaving.)
13:52:59 Join elensil [0] (~edhelas@2001:1c02:1903:d800:cc34:f104:30f:4a82)
14:00
14:04:38 Join rahimn [0] (~root@2401:1800:7800:101:be76:4eff:fe1c:1e6e)
14:23:32 Quit krabador (Ping timeout: 260 seconds)
14:23:48 Join krabador [0] (~krabador@5.170.105.112)
14:23:52 Quit krabador (Changing host)
14:23:52 Join krabador [0] (~krabador@unaffiliated/krabador)
14:30:33rahimnMy Sansa Clip+ won't turn on, and when plugged into my computer showed up as a 32MB UNDEF device
14:32:08rahimnI tried dd if=clppa.bin of=... and the command completed, but it didn't help. The player still won't turn on. After unplugging it and plugging it in again, it doesn't even show up as 32MB any more. Is it worth trying to short the two pads, or is it unrecoverable.
14:32:11rahimn?
14:32:16rahimnThanks for any advice :)
14:32:59 Quit krabador (Remote host closed the connection)
14:40:20 Join krabador [0] (~krabador@unaffiliated/krabador)
14:41:21pamaurygevaerts: you are right, we should allocate those IDs, it's not even complicated
14:41:32pamauryexcept that it needs changes on the rbutil side
14:46:58elensilhi pamaury
14:47:22pamauryhi
14:47:48elensilif you have some times tonight we can have a look at your usb_audio patch ?
14:48:58pamaurysure
14:49:32elensildo you have an iPod at your place to reproduce the issue ?
14:51:09pamaurynope, we'll have to do this the old fasion way, debug log, custom builds and all
14:51:54elensilokay
14:56:10pamaurybut the patch is still a hack, there are things in it that I know are wrong and would take some time to fix, at least we can try to identify where the problem is
14:58:25 Quit rahimn (Quit: rahimn)
14:59:19elensilsure
14:59:39 Quit Boltermor (Ping timeout: 240 seconds)
15:00
15:03:20 Join Boltermor [0] (~Boltermor@subscr-46-148-172-80.dhcp-docsis.net.tomkow.pl)
15:13:50***Saving seen data "./dancer.seen"
15:20:20 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon)
15:22:52 Quit JdGordon (Ping timeout: 272 seconds)
15:32:56 Quit shadows (Ping timeout: 252 seconds)
15:36:28 Quit elensil (Remote host closed the connection)
15:38:27 Join fs-bluebot [0] (~fs-bluebo@xd9baf36b.dyn.telefonica.de)
15:40:31 Quit fs-bluebot_ (Ping timeout: 246 seconds)
15:40:52 Quit bluebrother (Ping timeout: 246 seconds)
15:42:50 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
15:43:14 Join elensil [0] (~edhelas@2001:1c02:1903:d800:cc34:f104:30f:4a82)
16:00
16:13:43 Join metaphysis [0] (~metaphysi@2a02:2f01:504b:e00:102b:6de0:f3de:5f32)
16:39:15 Quit petur (Quit: *plop*)
16:41:47 Quit Boltermor (Ping timeout: 260 seconds)
16:44:11 Join Boltermor [0] (~Boltermor@188.146.2.102.nat.umts.dynamic.t-mobile.pl)
17:00
17:13:51***Saving seen data "./dancer.seen"
17:15:08 Join smoke_fumus [0] (~smoke_fum@188.35.176.90)
17:17:25 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury)
17:17:57 Quit ZincAlloy (Quit: Leaving.)
17:23:02 Quit pamaury_ (Ping timeout: 276 seconds)
17:28:34 Quit metaphysis (Quit: metaphysis)
17:36:47 Quit krnlyng (Ping timeout: 244 seconds)
17:47:15 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
17:49:11 Join krnlyng [0] (~liar@178.114.82.126.wireless.dyn.drei.com)
18:00
18:02:55 Quit elensil (Quit: Leaving.)
18:04:30 Join paulk-collins [0] (~paulk@gagarine.paulk.fr)
18:05:17 Quit PurlingNayuki (Remote host closed the connection)
18:31:39 Quit Boltermor (Read error: Connection reset by peer)
19:00
19:13:53***Saving seen data "./dancer.seen"
19:44:48Horrorcatpamaury: no issues with the mpr121/touchpad/i2c commits
20:00
20:01:47pamauryHorrorcat: cool, I will commit it very soon then
20:03:15 Quit pamaury (Remote host closed the connection)
20:16:40 Quit aevin (Ping timeout: 260 seconds)
20:19:29 Join einhirn [0] (~Miranda@p4FC10D7A.dip0.t-ipconnect.de)
20:23:32 Quit einhirn (Ping timeout: 240 seconds)
20:23:58 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
20:43:59 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
20:50:38 Join girafe [0] (~girafe@LFbn-1-8020-64.w90-112.abo.wanadoo.fr)
20:58:36__builtinso there are no plans yet as to how to allocate the USB IDs?
21:00
21:00:23 Join PurlingNayuki [0] (~Thunderbi@v163-44-154-238.a00f.g.sin1.static.cnode.io)
21:01:22 Quit Guest65764 (Ping timeout: 260 seconds)
21:04:08__builtinif that's the case, how about we allocate the IDs to devices by the order in which they first ran rockbox?
21:04:39__builtinand maybe reserve 1 or 2 for testing purposes
21:11:31__builtingevaerts: btw, fixed whitespace in g#1332
21:11:32fs-bluebotGerrit review #1332 at http://gerrit.rockbox.org/r/1332 : Fix broken simulator build with weird sdl-config by Franklin Wei
21:11:53pamauryI have a possibly stupid remark: do we really want to assigned IDs to every device or only devices that still have users ?
21:11:57pamauryhow many IDs to we have ?
21:12:09__builtin256
21:12:14gevaerts__builtin: good idea. Will you do the research to sort them properly? :)
21:12:50__builtinI have google and IRC to help me :P
21:12:53*gevaerts votes to only allocate ids to targets that are actually autobuilt
21:13:05__builtinand it doesn't have to be in perfect order
21:13:21gevaertsThere's more in configure, but there's no point in e.g. giving the logik dax an id
21:13:22*pamaury agrees with gevaerts
21:13:54***Saving seen data "./dancer.seen"
21:15:32*__builtin starts filling out the table
21:16:38gevaertsGreat!
21:17:51gevaerts__builtin: do you consider g#1332 to be ready now?
21:17:53fs-bluebotGerrit review #1332 at http://gerrit.rockbox.org/r/1332 : Fix broken simulator build with weird sdl-config by Franklin Wei
21:18:06__builtinyeah, shouldn't break anything
21:18:10gevaertsok
21:18:15__builtin(hopefully)
21:18:16gevaertsI'll push it soon
21:19:29pamaury+1 for g#1332, I can't see how it hurts
21:19:30fs-bluebotGerrit review #1332 at http://gerrit.rockbox.org/r/1332 : Fix broken simulator build with weird sdl-config by Franklin Wei
21:20:00gevaertsThe reason I'm waiting is because I just unblocked a build client that was blocked because of this, and I want to make sure it's in again
21:20:18__builtinhmm, I don't really think it's that important to have the IDs assigned in a totally strict order, right?
21:20:36__builtincould it just be by the order the configure menu gives them in?
21:20:50gevaertsAnd the server needs a few minutes to update that list
21:21:07gevaerts__builtin: sure, sounds good enough
21:21:18gevaertsMake sure you remember to check if targets actually can do USB :)
21:21:41__builtinhow many of those are there?
21:21:44*gevaerts will review the list to help catch any that slipped through
21:21:48gevaertsI don't know!
21:22:28gevaertsAt least 14
21:23:05gevaertspamaury: what should we do with ipod 1G..3G?
21:23:31gevaertsHmmm, I'm not sure now
21:23:37 Part chrisb ("rcirc on GNU Emacs 25.0.94.1")
21:23:38gevaertsThey do have USB, don't they?
21:23:44gevaertsOr are they just firewire?
21:24:10pamauryhuh, I don't know to be honest
21:24:16pamauryI don't have those
21:24:32gevaertsAnyway, they don't have a driver now, and I think the odds of them ever getting one are fairly low
21:24:36pamauryisn't the best check to see if target has USBSTAC K?
21:26:12 Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se)
21:26:14gevaertsAh, 1 and 2 only do firewire, so no issue there
21:26:32gevaerts3G has USB hardware, but we don't support it (so we do the old reboot-on-connect)
21:26:39__builtinso don't 1G/2G/3G?
21:27:06gevaertsI somehow doubt there are enough of those around to make someone appear who's motivated enough to reverse engineer that bit and write a driver
21:27:56 Join Zero_Diamond [0] (~bollocks@75.105.137.190)
21:28:49Zero_DiamondI have an issue that I could use some help with
21:29:01Zero_DiamondI just got a new Sansa e260v2
21:29:23Zero_DiamondFor whatever reason, when I plug it in, Windows 7 considers it a "device" and... won't assign it an actual drive letter?
21:29:44Zero_DiamondSo I can't use the Rockbox Utility
21:30:17Zero_DiamondI can't for the life of me figure out a way to force the internal memory to a drive letter
21:30:31__builtinare you running rockbox or OF?
21:30:40gevaertsZero_Diamond: it needs to be in MSC mode
21:31:02Horrorcat(mass storage … controller(?))
21:31:16gevaertsclass
21:31:25__builtingevaerts: should I assign lyre an ID?
21:31:41Zero_DiamondOriginal firmware at the moment, trying to get it set up with Rockbox
21:31:49gevaertsZero_Diamond: the manual has a bit about that in chapter 2
21:31:50Zero_DiamondHow do I put it into MSC mode?
21:32:09pamaury__builtin: lyre is dead afaik
21:32:15__builtinalright
21:32:26pamaurywe can assign it later if people complain
21:32:57gevaerts__builtin: I'd say intersect HAVE_USBSTACK in firmware/export/config and the build table (http://git.rockbox.org/?p=www.git;a=blob;f=buildserver/builds;h=eda485a3e0c67d5d080df605a61d6c4ba5420779;hb=HEAD)
21:33:32gevaertsZero_Diamond: there should be a "usb mode" item in the settings
21:33:34*pamaury writes a script
21:33:58*gevaerts isn't sure if the lyre was ever alive enough to be dead
21:34:29*pamaury agrees
21:35:31Zero_DiamondThat's odd
21:35:33Zero_DiamondI don't see it
21:35:42Zero_DiamondI've got the manual up so I'll see what that says
21:38:13__builtinandroid/SDL targets don't need IDs, either, right?
21:38:22*gevaerts nods
21:39:06fs-bluebotBuild Server message: New build round started. Revision 615c638, 255 builds, 16 clients.
21:39:59Zero_Diamond... there's no option here.
21:40:13Zero_DiamondIt says it should be under Settings -> USB Mode
21:40:20Zero_DiamondThere's no USB Mode category to be found.
21:42:47 Quit idonob (Ping timeout: 260 seconds)
21:43:57__builtinok, how do I print the common lines of two files in bash?
21:45:23__builtinnvm
21:45:26pamaurycomm
21:45:31*__builtin isn't sure this is right
21:45:41Horrorcat__builtin: python3 -c 'import sys; lines1 = list(open(sys.argv[1])); lines2 = set(open(sys.argv[2])); print("\n".join(line for line in lines1 if line in lines2))' file1 file2
21:45:54__builtinhttp://pastebin.com/N21munbK
21:46:09__builtinshouldn't there be a lot more targets?
21:47:01fs-bluebotBuild Server message: Build round completed after 475 seconds.
21:47:02fs-bluebotBuild Server message: Revision 615c638 result: All green
21:48:46Zero_DiamondHuh. Apparently this firmware is old?
21:49:18Zero_DiamondIt looks like Sansa added MSC Mode as of 03.01.14... this is 03.01.11A
21:49:46__builtinis an upgrade possible?
21:50:25Zero_DiamondAha, I think I've got it
21:50:39Zero_DiamondThere's a keypress combo you can do to manually make it go MSC
21:50:47Zero_DiamondAppears to have worked!
21:52:41pamaury__builtin: the list looks sensible
21:52:57__builtinsure there's nothing missing?
21:53:16__builtinonly 43 targets listed
21:53:40*gevaerts checks
21:54:05gevaertsThere are some missing I'd say
21:54:32 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon)
21:55:43__builtinI get 63 targets with HAVE_USBSTACK
21:55:47*gevaerts nods
21:55:49 Join Guest65764 [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627)
21:56:47 Quit JdGordon_ (Ping timeout: 260 seconds)
21:56:52gevaertsiaudio7, logikdax, sim, sansaview, and tatungtpj1022 definitely shouldn't get an id
21:57:52gevaertsI don't know what the creativezenv or creativezv are
21:58:27gevaertsOr the samsung ypz5
21:58:28pamaurycreativezenv is incomplete so
21:58:39pamaurycreativez never got full suppport iirc
21:58:42pamaurysame for ypz5
21:58:43gevaerts(I can't find those in the builds file anyway)
21:59:33gevaertsThe others, gogearhdd1630 gogearhdd6330 hifimanhm60x hifimanhm801 ihifi760 ihifi960 iriverh10 iriverh10_5gb samsungyh820 samsungyh920 samsungyh925 zenvisionm30gb zenvisionm60gb, are in builds
22:00
22:00:01__builtinok, so I'm missing a few then
22:00:05 Join shadows [0] (e@gateway/shell/openshells.net/x-vjdzohzqgygarvep)
22:00:11gevaertsI don't know if those zen vision m things actually work these days, but I do know they have a USB stack
22:00:32gevaerts(7 of those are pp5022)
22:06:52__builtinargh, some of the names in the builds file don't correspond exactly with filenames in firmware/export/config
22:08:00__builtinalright, here's the new list: http://pastebin.com/q1s1q7YH
22:08:06__builtin54 targets
22:10:19gevaertsWhich names are you using, actually?
22:11:10__builtinactually, it turns out that was a mistake in my script
22:11:21*__builtin didn't escape a "." properly
22:12:19gevaertsLooks good to me
22:18:01 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
22:18:45__builtinyou know what, I think alpha order is fine
22:22:36*pamaury votes for alphabetical order based on the second letter of each target and then sorted by manufacturer
22:22:43pamaury(and then RAM size)
22:28:46__builtin see http://www.rockbox.org/wiki/USBIDs
22:30:48gevaertsGreat!
22:31:11gevaertsNow we just have to make this decision about defaults and settability :)
22:31:42 Join Strife89|Quassel [0] (~quassel@adsl-98-80-192-50.mcn.bellsouth.net)
22:31:52pamauryI think it could be useful to be able to select between OF and RB ID
22:32:15pamauryabout the default, I think your argument about OF ID causing more harm than good is probably a good one
22:32:42Horrorcathave I mentioned that I love the percieved rockbox policy of "if in doubt, add a switch"?
22:33:16gevaertsHorrorcat: the great thing is that the *actual* policy is to avoid settings :)
22:33:25gevaertsNot that it's a very effective policy...
22:34:09Horrorcat:-O
22:34:45*pamaury thinks we might have loads of people complaining otherwise
22:35:09Horrorcatdoesn’t having a bunch of targets sorted alphabetically and then append new targets unsorted to that list rustle anyones jimmies?
22:35:23 Quit Strife89 (Ping timeout: 260 seconds)
22:35:26pamaurybut in practice, I think the default policy should be "keep OF" until we have RBUtil released with knowledge of the new ids
22:35:46gevaertsProbably
22:36:04gevaertsAlthough there is the rbutil feature of looking at rockbox-info.txt
22:36:24pamauryoh right
22:36:35gevaertsBut I'm not sure if that counts
22:36:56gevaertsI mean, you could easily connect, remove .rockbox, and then use rbutil to reinstall
22:37:26gevaertsbluebrother: do you happen to be planning a new rbutil release soon?
22:37:31 Quit [7] (Ping timeout: 250 seconds)
22:37:44 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
22:40:45__builtinhow about we don't use any systematic order at all?
22:40:50__builtinjust randomize it
22:41:12Horrorcatyes, I was about to suggest that
22:41:56gevaertsAt least use the rockbox playlist randomiser if you do that
22:41:57 Quit Zero_Diamond ()
22:42:19pamauryit's not like it really matters
22:42:25__builtinexactly
22:50:38 Quit pamaury (Read error: Connection reset by peer)
22:51:29 Join ZincAlloy [0] (~Adium@ip5f5ab954.dynamic.kabel-deutschland.de)
22:51:52 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
22:52:27 Quit pamaury (Read error: Connection reset by peer)
22:54:04 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
22:55:39fs-bluebotBuild Server message: New build round started. Revision 4d42e36, 255 builds, 16 clients.
22:58:09__builtinok, how about this: https://www.fwei.tk/temp.txt
22:58:13__builtin(stupid pastebin)
22:58:42__builtinshuffled the lines up so we don't have to "break" the system with a new port
23:00
23:02:10*gevaerts thinks any order is good
23:02:28fs-bluebotBuild Server message: Build round completed after 409 seconds.
23:02:29fs-bluebotBuild Server message: Revision 4d42e36 result: All green
23:03:37 Quit Strife89|Quassel (Ping timeout: 276 seconds)
23:07:20*pamaury too
23:08:27fs-bluebotBuild Server message: New build round started. Revision b2afd93, 255 builds, 16 clients.
23:09:19pamaurygevaerts: is it with you that I once discussed the speed of our usb storage stack ?
23:09:45gevaertsI don't think it's likely that we never discussed it
23:10:39pamaurybecause I stumbled on the problem again when I tried to test high speed sd cards and basically hit the usb stack limit :(
23:12:01gevaertsI'm not sure I actually know *why* it's slow
23:12:15pamauryI *think* it is because of the usb thread
23:12:26gevaertsI mean, there's the 100Hz thing, but shouldn't that then mean 100 transfers per second, which would mean 6.4MB/s?
23:12:36gevaertsI mean, I've seen faster than that
23:13:09pamauryyeah, it seem we stall between 12 and 15MB/s
23:13:30pamauryeven with ramdisk I can't do more than 16MB/s
23:13:34 Quit pamaury (Read error: Connection reset by peer)
23:13:58***Saving seen data "./dancer.seen"
23:14:05 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
23:14:09gevaertsThat more or less matches what I've seen on PP5022
23:14:32*pamaury begins messing around with the code to find out
23:14:45pamauryby the way, can someone have a quick look at g#1330 ?
23:14:47fs-bluebotGerrit review #1330 at http://gerrit.rockbox.org/r/1330 : Rework sd/mmc handling by Amaury Pouly
23:14:55 Quit pamaury (Read error: Connection reset by peer)
23:15:07fs-bluebotBuild Server message: Build round completed after 399 seconds.
23:15:08fs-bluebotBuild Server message: Revision b2afd93 result: 0 errors 4 warnings
23:15:09fs-bluebotBuild Server message: New build round started. Revision ccd500a, 255 builds, 16 clients.
23:15:29 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
23:15:30gevaertsBut then on PP5022 I doubt we can do *much* faster. ATA with DMA was faster than a naive ramdisk there due to the memcpy
23:15:44gevaertsDo we know RAM speeds on various targets?
23:15:59pamauryon fuze+ it's 100+MB/s
23:16:46pamauryand I doubt it is limited by the usb dma
23:16:50gevaertsfuze+ is the ARC driver, right?
23:16:53pamauryyes
23:17:22gevaertsSo two RAM transfers, presumably, USB->RAM and RAM->SD
23:17:29*gevaerts assumes that SD also does dma
23:17:59gevaertsSo 50MB/s would be the hard limit
23:18:37pamauryyes, but for example even ramdisk without memcpy (so basically reading garbage/always the same buffer) stalls at 16MB/s
23:18:53gevaertsYes, that's also what I did for the "ultimate" speed tests
23:19:33gevaertsDoes increasing HZ actually change that?
23:20:25pamaurygood question, let me have a try
23:20:47pamauryalthough increasing HZ is always dangerous because of some bad code/implicit dependencies
23:21:13gevaertsYes, but luckily we only want to know about USB without any other stuff :)
23:21:43gevaerts(for now)
23:22:40prof_wolfffmaybe it is not related... but my recent tests with the new designware driver on Classic were ~26-28 MB/s for sequential rd/wr, and ~33-35MB/s when HDD access was disabled (only USB transfers)
23:24:41gevaertsHow do CPU and RAM speeds compare between classic and fuze+?
23:24:42pamauryhum actually I was mistaken, I forgot to disable some code the last time, so with no memcpy I am reading at 22MB/S
23:25:35fs-bluebotBuild Server message: Build round completed after 627 seconds.
23:25:36fs-bluebotBuild Server message: Revision ccd500a result: 42 errors 4 warnings
23:25:37fs-bluebotBuild Server message: New build round started. Revision 59ae562, 255 builds, 14 clients.
23:25:58prof_wolfffclassics CPU=216MHz, AHB=108
23:26:04gevaertsThat's a weird error...
23:26:11pamauryweird error...
23:26:24gevaertsoh, it *is* on ARM
23:26:38gevaertsThat at least makes some sense
23:26:45pamauryfuze+ tops at 400Mhz, AHB at 150MHz
23:26:52pamaurysorry 450MHz
23:27:31gevaertsIt would be good to know how fast those USB controllers can actually go if we take the entire top level of the stack out
23:27:58gevaertsWhat does the OF do on fuze+ with fast SD cards?
23:28:11pamauryOF is crap and incredibly slow
23:28:17pamaury(last time I tried)
23:28:34gevaertsok, so it might be possible that we're just hitting hardware limits I guess
23:28:46pamaurylet me try with increased HZ
23:28:50*gevaerts nods
23:29:10gevaertsIf that makes things go faster, we can improve things. If it doesn't, I'm not sure what it means :)
23:29:18gevaertsIf it goes slower, I blame context switching time
23:29:23prof_wolfffRAM speed should not affect too much, what affects is writing the NAND, on my tests, the same driver used on Sansa Zip, gives 33-35MB/s raw and only about 4-8MB/s (cant recall this number exactly) when reading/writting the internal memory, speeds on nano were even worse but "raw" speed is also 33-35/MB/s on Nano2G
23:30:19gevaertsWell, only if your test does things properly :)
23:30:23pamauryRAM speed is important on the ARC driver because the transfer descriptor list is in memory
23:30:52pamauryalthough on the fuze+ we have to put in in iram
23:31:02*gevaerts tested on ipod video once with a naive ramdisk (i.e. an extra memcpy every time), and it was *slower* than the HDD
23:31:28 Quit dudemann (Ping timeout: 250 seconds)
23:31:39pamauryok, HZ=1000 does not even boot :-)
23:32:04gevaertspamaury: bootloader USB!
23:32:17pamauryah yeah, that's more work !! :-p
23:32:21gevaertsI mean, it's simpler, at the small cost of an increaed bricking risk :)
23:32:51gevaertsThe transfer descriptor size is more or less negligible compared to the actual transfer size, so I'm not sure if that really should have much of an effect
23:33:10prof_wolfffthe test is a simple dd with block size = 64Kb (IIRC) but the target is patched to not to write/read some sectors, just return if sector>XXX, this tryes to measure the maximum USB bus speed for this USB HW
23:33:43gevaerts64K is the usual block size
23:33:47fs-bluebotBuild Server message: Build round completed after 492 seconds.
23:33:48fs-bluebotBuild Server message: Revision 59ae562 result: 0 errors 99 warnings
23:33:53gevaertsIt's what everyone does anyway
23:34:23prof_wolfffthe patch is at storage-ipod6g level so the only thing not done is to write/read the HDD
23:34:23gevaertsAh, deepthought-ender finds sdl again with the configure fix :)
23:37:41pamauryHZ=300 gives 22MB/s in bootloader
23:38:17*gevaerts decides to test (write speed, easier to disable actual IO) on fuzev2
23:40:19 Join edhelas [0] (~edhelas@145.133.43.230)
23:40:31edhelaspamaury: sorry I didn't had time tonight
23:40:43gevaerts39MB/s "pure" USB write speed
23:41:24pamauryarc has 25MB/s pure writ
23:42:03pamauryso maybe ARC core is just not very good or our driver is not optimal
23:42:21pamauryedhelas: no problem, maybe this week-end ?
23:42:30gevaertsWell, I wrote that one, what did you expect? :)
23:42:40 Quit girafe (Read error: Connection reset by peer)
23:42:52pamauryI read that one very carefully, I don't remember anything particularly bad it in
23:44:44gevaertsHZ is in tick.h, right?
23:44:48pamauryyes
23:45:05gevaertsChanging it on fuzev2 doesn't seem to change much USB-wise
23:47:20pamauryI can imagine a way to test arc raw speed (in an unrealistically ideal scenario) but it woul be annoying to write the code...
23:49:06gevaertsOK, hangs on boot with HZ=10000 :)
23:49:59 Quit pamaury (Read error: Connection reset by peer)
23:50:32 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
23:50:33 Quit holgersson (Remote host closed the connection)
23:51:00 Join holgersson [0] (~quassel@unaffiliated/holgersson)
23:51:05pamauryok I will do it for the sake of testing: I will create an interface with one OUT endpoint, and setup the TD to be a loop with a 64KB buffer
23:51:19pamauryyou can't do better than this on the arc, we'll see how much I can push
23:52:04*gevaerts nods
23:54:38gevaertsSame speed with HZ=10
23:54:46gevaerts(and slow screen fades :)
23:54:47pamauryhaha
23:56:13gevaertsHZ=1 gives me a proper panic
23:56:18gevaertsdivision by zero :)

Previous day | Next day