| 00:51:41 | *** | Saving seen data "./dancer.seen" |
| 00:54:00 | | Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) |
| 01:00 |
| 01:06:55 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 01:12:24 | | Quit _3dsv (Ping timeout: 240 seconds) |
| 01:15:57 | | Quit pixelma (Quit: .) |
| 01:15:57 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 01:18:46 | | Join amiconn [0] (jens@rockbox/developer/amiconn) |
| 01:18:46 | | Join pixelma [0] (marianne@rockbox/staff/pixelma) |
| 01:21:02 | | Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) |
| 01:25:28 | | Quit ZincAlloy (Ping timeout: 256 seconds) |
| 01:34:02 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:dcd9:60d7:43b1:6910) |
| 01:38:31 | | Quit ZincAlloy (Ping timeout: 272 seconds) |
| 01:40:40 | | Join _3dsv [0] (~3dsv@068-184-255-059.res.spectrum.com) |
| 01:43:22 | | Join mendel_munkis_ [0] (~mendelmun@ool-ae2cb138.dyn.optonline.net) |
| 01:43:42 | | Quit pamaury (Ping timeout: 272 seconds) |
| 01:46:25 | | Quit mendel_munkis (Ping timeout: 264 seconds) |
| 02:00 |
| 02:08:11 | | Join MonTaGaTnoM [0] (~shawn156@unaffiliated/shawn156) |
| 02:09:33 | | Quit S|h|a|w|n (Ping timeout: 260 seconds) |
| 02:11:28 | | Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) |
| 02:12:37 | | Quit MonTaGaTnoM (Ping timeout: 246 seconds) |
| 02:22:22 | | Quit Moarc (Quit: i znowu NADMUCHAŁ BALONA) |
| 02:25:47 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 02:29:40 | | Join pamaury [0] (~pamaury@maths.r-prg.net.univ-paris7.fr) |
| 02:29:41 | | Quit pamaury (Changing host) |
| 02:29:41 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 02:51:43 | *** | Saving seen data "./dancer.seen" |
| 04:00 |
| 04:09:20 | | Nick mendel_munkis_ is now known as mendel_munkis (~mendelmun@ool-ae2cb138.dyn.optonline.net) |
| 04:51:46 | *** | No seen item changed, no save performed. |
| 05:00 |
| 05:24:12 | | Join sakax [0] (~r0b0t@unaffiliated/r0b0t) |
| 05:38:34 | | Quit S|h|a|w|n (Read error: Connection reset by peer) |
| 06:00 |
| 06:51:49 | *** | Saving seen data "./dancer.seen" |
| 06:58:04 | | Quit mendel_munkis (Ping timeout: 240 seconds) |
| 08:00 |
| 08:16:34 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 08:46:13 | | Quit Topy44 (Ping timeout: 244 seconds) |
| 08:51:51 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 09:07:58 | | Quit mikroflops (Ping timeout: 258 seconds) |
| 09:08:57 | | Join mikroflops [0] (~yogurt@c188-150-217-176.bredband.comhem.se) |
| 09:14:43 | | Quit koniu (Ping timeout: 240 seconds) |
| 09:22:02 | | Join koniu [0] (~koniu@gateway/tor-sasl/koniu) |
| 09:23:44 | | Quit t0mato (Quit: Ping timeout (120 seconds)) |
| 09:27:52 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 09:40:35 | | Join t0mato [0] (~t0mato@193.32.127.158) |
| 09:50:01 | | Join Topy44 [0] (cJC4RU1ccD@bellatrix.uberspace.de) |
| 10:00 |
| 10:41:51 | | Quit pamaury (Quit: Konversation terminated!) |
| 10:44:02 | | Quit Topy44 (Ping timeout: 260 seconds) |
| 10:48:57 | | Join Topy44 [0] (OOvo1SKgJD@bellatrix.uberspace.de) |
| 10:51:53 | *** | Saving seen data "./dancer.seen" |
| 11:00 |
| 11:55:54 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 12:00 |
| 12:06:40 | | Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) |
| 12:07:28 | | Quit _3dsv (Remote host closed the connection) |
| 12:07:54 | | Join _3dsv [0] (~3dsv@068-184-255-059.res.spectrum.com) |
| 12:11:07 | | Quit ZincAlloy (Ping timeout: 246 seconds) |
| 12:19:34 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:fcae:47fe:b196:fdd1) |
| 12:20:51 | | Join mendelmunkis [0] (~mendelmun@ool-ae2cb138.dyn.optonline.net) |
| 12:24:31 | | Quit ZincAlloy (Ping timeout: 272 seconds) |
| 12:48:21 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:f1a5:dfbd:c0a4:72b1) |
| 12:51:54 | *** | Saving seen data "./dancer.seen" |
| 13:00 |
| 13:33:28 | | Quit pamaury (Ping timeout: 256 seconds) |
| 13:45:03 | | Join fs-bluebot_ [0] (~fs-bluebo@55d46d45.access.ecotel.net) |
| 13:45:14 | | Quit bluebrother (Disconnected by services) |
| 13:45:19 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
| 13:46:20 | | Quit fs-bluebot (Ping timeout: 272 seconds) |
| 13:52:12 | bluebrother^ | hmm, seems my internet reconnected just as I was writing some thoughts ... |
| 13:52:21 | bluebrother^ | so I've been thinking about the rbutil elevation thing. My current thought is to leave the implementation in rbutil as-is, and if it does find external patcher binaries (ipodpatcher / sansapatcher) it'll call them. That way it can still work using sudo, and we don't need to bundle the patchers, which should simplify things a bit. |
| 13:52:27 | bluebrother^ | we'd ship the patchers as part of the release though. On Mac they'd be simply part of the dmg, on Windows part of the zip. |
| 13:52:27 | mendelmunkis | sounds aboutright on the timing |
| 13:52:49 | bluebrother^ | Linux ... not sure how exactly that would work with the appimage, but I guess it will work in some way. |
| 13:53:09 | bluebrother^ | so we can get the best of both worlds. Thoughts? |
| 13:54:28 | genevino | is there some kind of probability the surfans f20 gets rockbox at some point? |
| 13:55:07 | mendelmunkis | that reminds me. I should really get around to packaging rbutil for debian. |
| 13:57:28 | bluebrother^ | genevino: there's always probability. But it might be 0 ;-) |
| 14:00 |
| 14:13:24 | speachy | genevino: looks like another hibyplayer unit. probably wouldn't be hard to do |
| 14:21:18 | bluebrother^ | speachy: I've added a sticky topic in the Rockbox Utility forum with the link to the development binaries. Seems this is coming up again and again :) |
| 14:21:58 | speachy | how much of a PITA is rbutil to cross-compile for windows? is that even possible? |
| 14:22:15 | speachy | I'm thinking maybe we could add it to the dev build list |
| 14:22:48 | bluebrother^ | it's rather simple with mxe. |
| 14:23:26 | bluebrother^ | if using the cross compiler as offered by your distro: depends on the distro :) |
| 14:23:50 | bluebrother^ | I hope to get some progress soonish on that elevation thing. |
| 14:24:11 | speachy | let's see if mingw64 on fedora builds it cleanly... |
| 14:24:14 | bluebrother^ | and then merge the libtomcrypt stuff, and try to get 1.5.0 done. |
| 14:25:13 | bluebrother^ | in theory you'd only need to have the used packages installed. Right now Qt5 and crypto++ should be the main ones. |
| 14:30:30 | speachy | huh, it built... execept for cryptopp |
| 14:32:23 | speachy | rebuilding with the libtom stuff applied |
| 14:44:17 | bluebrother^ | since we have a github mirror I was wondering if it would make sense to use travis for Rockbox Utility CI builds. |
| 14:45:02 | bluebrother^ | might even allow us to build for macos. |
| 14:46:25 | speachy | dunno if it makes sense or not, but it's worth considering |
| 14:46:51 | speachy | having automated builds is a GoodThing(tm) |
| 14:46:56 | bluebrother^ | true. |
| 14:47:36 | bluebrother^ | we did consider automated builds for Rockbox Utility years back. Never happened though, since most work was on Rockbox anyway. But with CI services like travis these days ... |
| 14:47:53 | bluebrother^ | maybe I should give it a shot. I have a fork on my github anyway. |
| 14:51:41 | speachy | can rbutil compile out-of-tree? it doesn't 'make clean' properly.. |
| 14:51:56 | *** | Saving seen data "./dancer.seen" |
| 14:52:48 | speachy | huh, the Surfans F20 looks like a very close cousin to the HIFI WALKER H2. |
| 14:55:51 | genevino | speachy: well i already had a look at the firmware update file and it's just some iso9660 image with some 3.10 linux kernel and some other magic |
| 14:56:09 | | Join skx_ [0] (~r0b0t@unaffiliated/r0b0t) |
| 14:56:19 | speachy | genevino: it's 98% identical to the rocker, x3ii, and x20. |
| 14:56:28 | genevino | speachy: unfortunately the current firmware has no real shuffle-all mode, which is annoying. |
| 14:56:35 | | Quit sakax (Quit: Leaving) |
| 14:56:39 | | Quit skx_ (Client Quit) |
| 14:56:40 | genevino | speachy: yeah i also ordered a rocker, should arrive next days. :) |
| 14:56:55 | | Join sakax [0] (~r0b0t@unaffiliated/r0b0t) |
| 14:57:08 | bluebrother^ | speachy: yes. In fact I always build out-of-tree. |
| 14:57:22 | bluebrother^ | mkdir build; cd build; qmake .. && make |
| 14:59:49 | genevino | speachy: i'm actually surprised, i would have expected some original china cheapo-player firmware to much worse than what the original f20 fw is. |
| 15:00 |
| 15:53:57 | | Quit Skyrider (Quit: ZNC - 1.6.0 - http://znc.in) |
| 15:55:57 | | Quit jerwin (Quit: bye) |
| 16:00 |
| 16:00:05 | | Join jerwin [0] (~flippy-fl@unaffiliated/flippy) |
| 16:00:47 | | Join johnb2 [0] (~johnb2@p5b3afdc3.dip0.t-ipconnect.de) |
| 16:07:03 | | Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) |
| 16:12:08 | | Quit johnb2 (Ping timeout: 256 seconds) |
| 16:52:00 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:02:43 | | Quit sakax (Remote host closed the connection) |
| 17:24:28 | braewoods | speachy: do they provide the kernel source at least? if not they're technically breaking the GPL... |
| 17:25:17 | speachy | braewoods: no idea if any of them do. Probably not. |
| 17:25:29 | speachy | there's nothing "technical" about it. |
| 17:25:38 | speachy | and we can't do anything about it either. |
| 17:25:57 | speachy | I can say there's no source code download link posted anywhere for those units. |
| 17:26:18 | speachy | (as well as the Linux kernel itself, there's also u-boot) |
| 17:28:07 | braewoods | and whatever userspace stuff they use |
| 17:28:16 | braewoods | it may also have busybox or so |
| 17:28:58 | braewoods | GPLv2 is clearly violated in any case |
| 17:29:19 | braewoods | if you could get source release that could be beneficial to rockbox on some targets but i wouldn't count on it |
| 17:30:10 | speachy | it would be a great boon for doing native ports, but putting that aside it would allow for some needed bugfixing in the kernel. |
| 17:30:51 | braewoods | perhaps best outcome is if rockbox could get its own device. |
| 17:31:08 | braewoods | instead of always have to use someone else's designed hardware |
| 17:31:12 | braewoods | having* |
| 17:31:27 | braewoods | would be interesting to see something like that from pine microsystems |
| 17:31:50 | speachy | eh, piggybacking on other hardware isn't inherently bad. |
| 17:32:10 | braewoods | i know but it does make it easier |
| 17:32:21 | braewoods | there's no need for reverse engineering (in theory) |
| 17:32:26 | speachy | but doing our own would probably take a couple hundred grand worth of funding before the first unit rolls off the line. |
| 17:32:58 | speachy | with proper docs/sources on exisitng hardware, we wouldn't need to RE things either. |
| 17:33:21 | braewoods | which reminds me |
| 17:33:27 | braewoods | does RB support bluetooth on anything? |
| 17:33:28 | speachy | we'd still need to write our own drivers for new/unique hardware, regardless of anything else. |
| 17:34:05 | speachy | nope. on the rocker and other hiby-based targets, the OS-level stuff is all there though, and just needs an appropriate UI written |
| 17:34:30 | speachy | on native targets, it's a lot more involved, as we'd have to port over a bluetooth stack and all that jazz. |
| 17:34:34 | braewoods | so if it ever does it would be through another subsystem |
| 17:34:52 | braewoods | how much RAM does the rocker have even? |
| 17:34:54 | speachy | no inherent reason why not; just man-hours |
| 17:34:57 | braewoods | I thought it was 32MB |
| 17:35:05 | speachy | 32MB, embedded into the main SoC package. |
| 17:35:19 | braewoods | so how do you fit rockbox and the linux kernel into it? |
| 17:35:20 | speachy | but only ~6-7MB is really usable by rockbox. |
| 17:35:26 | braewoods | Ah. |
| 17:35:35 | braewoods | so very tight fit compared to older ports |
| 17:36:04 | braewoods | sheesh. too bad it wasn't 64MB. |
| 17:36:43 | speachy | yes and no; the underlying Linux OS does most of the heavy lifting; rockbox is "just" an application on top of it. |
| 17:37:15 | braewoods | so main issue is memory for decoding buffers and such? |
| 17:37:19 | | Quit petur (Quit: Leaving) |
| 17:37:22 | speachy | The X1000e does come in a 64MB version I believe, but I don't recall seeing anything |
| 17:37:33 | speachy | anything with that version, I mean. |
| 17:38:00 | braewoods | this may be the future rockbox has to deal with... fewer native ports and more piggybacking off Linux or so |
| 17:38:12 | speachy | yeah; playlist management, UI stuffs, voiced menus, codecs and codec buffers, etc.. |
| 17:38:43 | speachy | it's plenty for "normal" use; only becoming tight when some of the more memory-hungry plugins are used. ie various games/emulators. |
| 17:39:07 | braewoods | oui. if i were you i'd want to do most of the allocations statically to reduce waste from heap usage |
| 17:39:17 | speachy | (the X1000 is a 1GHz MIPS32r2 core. _Plenty_ of raw oomph!) |
| 17:39:40 | speachy | rockbox is already mostly static. max RAM used is a compile-time option. |
| 17:39:48 | braewoods | I see. |
| 17:39:54 | braewoods | Ok. |
| 17:40:18 | braewoods | I just realized some time ago that dynamic allocations are heavily used but they're a liability in resource cramped devices. |
| 17:40:56 | braewoods | pointers can consume precious memory |
| 17:41:12 | braewoods | i wonder though, do these targets have MMUs? |
| 17:41:20 | braewoods | they're embedded so I don't know. |
| 17:41:21 | speachy | most of the rockbox targets don't. |
| 17:41:35 | speachy | but the jz4760 and x1000 does. |
| 17:41:38 | braewoods | there's less need for MMUs in this kind of application |
| 17:42:08 | braewoods | ah. |
| 17:42:42 | speachy | rockbox doesn't natively use the MMUs on anything though. |
| 17:45:39 | speachy | I've toyed with taking a devkit based on a high-end STM32 microcontroller and porting rockbox over to it as a proof of concept, but there's no real path forward from taking that into something that resembles a DAP. |
| 17:48:50 | speachy | Heh. if we had enough cash on hand to commit to a sufficiently-large order we could probably get (for example) AGPTek/Benjie |
| 17:49:17 | speachy | ..to hand over the full source code in the process, and we could use that to do a native port to that hardware. |
| 17:49:40 | speachy | don't know what "sufficiently large" would be in this context but it's likely in the ~10K unit range. |
| 17:58:19 | braewoods | I'd probably ask pine microsystems first if they'd have any interest. |
| 17:58:29 | braewoods | they've already been producing ARM based phones and tablets |
| 17:59:49 | speachy | designing new hardware will drive up the cost, as that NRE has to be amortized across the production run. |
| 18:00 |
| 18:00:24 | speachy | and without working software, it would be a design-to-spec |
| 18:00:48 | speachy | (and we really couldn't do the sw port until we get at least an initial prototype) |
| 18:01:30 | speachy | ... that 10K unit production run really is the minimum for reasonable per-unit costs |
| 18:02:36 | speachy | still, probably wouldn't hurt to drop 'em a line, but I suspect we're going to need a kickstarter with a couple hundred grand raised to make this viable. |
| 18:04:11 | | Quit Rower (Ping timeout: 240 seconds) |
| 18:05:12 | speachy | (and we have to be somewhat competitively priced compared to commercially-revelant devices) |
| 18:07:57 | | Quit Oksana (Read error: Connection reset by peer) |
| 18:20:10 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 18:20:48 | | Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) |
| 18:25:04 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 18:36:57 | | Quit ac_laptop (Quit: WeeChat 2.9) |
| 18:37:23 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 18:40:23 | _bilgus__ | $60 - 100 is competive but not realistic |
| 18:48:27 | speachy | yeah. |
| 18:50:40 | speachy | that's why I was thinking it may be smarter to talk someone into cranking out a big order of an existing product that was (presumably) already competitively priced. |
| 18:51:35 | speachy | the only engineering investment would be the actual rockbox port. |
| 18:51:55 | speachy | and since we're swimming in developers, that'll be simple! |
| 18:52:02 | *** | Saving seen data "./dancer.seen" |
| 19:00 |
| 19:44:00 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 19:45:03 | | Join fs-bluebot [0] (~fs-bluebo@55d46b32.access.ecotel.net) |
| 19:46:59 | | Quit bluebrother^ (Ping timeout: 240 seconds) |
| 19:47:35 | | Quit fs-bluebot_ (Ping timeout: 265 seconds) |
| 19:47:45 | speachy | just reached out to the pine64 folks. |
| 19:58:31 | | Join smoke_fumus [0] (~smoke_fum@188.35.176.90) |
| 20:00 |
| 20:18:18 | | Quit ZincAlloy (Quit: Leaving.) |
| 20:52:03 | *** | Saving seen data "./dancer.seen" |
| 20:53:39 | braewoods | speachy: well they develop products around their ARM boards. |
| 20:54:03 | braewoods | it's more niche than usual though so who knows if there's any interest |
| 20:54:26 | braewoods | but if they did go for it the devices would probably have a ton more RAM than rockbox usually does |
| 21:00 |
| 21:11:35 | | Quit braewoods (Quit: WeeChat 2.8) |
| 21:11:56 | | Join pacman [0] (~braewoods@learnprogramming/staff/braewoods) |
| 21:11:58 | | Nick pacman is now known as braewoods (~braewoods@learnprogramming/staff/braewoods) |
| 21:23:42 | speachy | they started out with Allwinner SoCs but I think all of their recent stuff has been on various Rockchip parts. |
| 21:26:55 | speachy | as for RAM, it'll be whatever the cheapest is for a given technology. For example I think the _smallest_ LPDDR4 part one can get is 64MB. :) |
| 21:28:11 | speachy | wait, that's LPDDR2. smallest LPDDR4 part Micron makes is 512MiB |
| 21:38:15 | | Quit smoke_fumus (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/) |
| 22:00 |
| 22:00:29 | speachy | but one of the reasons the injenic parts are so popular are because they embed the RAM into the package, greatly reducing the necessary pincount of the SoC, and the resulting improvements to pcm size/complexity/bom cost |
| 22:00:31 | braewoods | speachy: and the smallest modules are 4GB |
| 22:00:44 | speachy | Gb, not GB. |
| 22:01:07 | braewoods | in terms of standard DDR4 memory modules |
| 22:03:49 | speachy | ah yes |
| 22:04:56 | speachy | A 64-bit memory bus does mean you'll need 8 8-bit parts. |
| 22:11:05 | braewoods | given how fast they are you'd probably be underclocking it to keep the heat down |
| 22:11:19 | braewoods | just how much cpu does rockbox need? i can't see it needing much |
| 22:11:53 | speachy | couple hundred mhz on even an ARM7TDMI are plenty for all of our codecs. |
| 22:16:23 | speachy | we're more sensitive to latency though. |
| 22:19:57 | speachy | so even a semi-modern microcontroller |
| 22:20:02 | speachy | is plenty |
| 22:20:11 | | Quit cockroach (Quit: leaving) |
| 22:26:29 | braewoods | speachy: is it common for codecs to be implemented in software or via ASICs these days? |
| 22:26:47 | braewoods | i've never seen an ASIC for audio codecs but that doesn't mean they don't exist. |
| 22:27:14 | speachy | it's pretty common to put various accelerators into ASICs. |
| 22:27:44 | braewoods | was just wondering whether it'd be all software or not since modern cpus may be a lot more efficient than they used to be |
| 22:27:48 | braewoods | maybe good enough for rockbox |
| 22:28:23 | speachy | the accelerators are often (usually?) under various NDAs that preclude public source code distribution |
| 22:28:36 | braewoods | how typical |
| 22:28:42 | braewoods | i can't see what the point of that would be |
| 22:28:46 | braewoods | oh well |
| 22:29:23 | speachy | take the ATJ2127, for example −− it has nearly no RAM, because the hardware can DMA data off the SD card, into the HW decoder engine, and out to the DAC without any CPU intervention |
| 22:29:33 | speachy | no need to buffer anything |
| 22:31:18 | speachy | the usual reason for locking down the decoders are patents and DRM. |
| 22:31:51 | braewoods | I see |
| 22:31:55 | speachy | mp3's fully in the public domain now, but the mpeg4-derived stuff isn't, for example. |
| 22:32:10 | speachy | and of course DRM is a festering pile of swill that ruins everything it touches. |
| 22:33:43 | speachy | but we don't generally care because the CPU is more than powerful enough −− and the analog portions of the system draw more juice than the CPU anyway. |
| 22:34:01 | braewoods | i wonder if there's asics for the non-patented codecs like vorbis and opus |
| 22:34:11 | speachy | (we can't turn off the clocks, or the RAM, or the audio codec... |
| 22:35:03 | speachy | pretty sure both can be had in hardware form, but how widespread they are is unknown. |
| 22:35:31 | braewoods | it's simpler just to put it in software |
| 22:35:45 | braewoods | we're not talking stuff that's incredibly demanding like video codecs |
| 22:36:29 | speachy | definitely is simpler, but one-off NRE more than pays for itself if you can shrink your unit costs across a large production run |
| 22:36:59 | speachy | or it enables you to get 30 minutes more battery life than the competition for the same battery |
| 22:37:25 | braewoods | or the same with smaller battery |
| 22:37:52 | speachy | exactly |
| 22:38:17 | speachy | on aliexpress there are quite a few DAPs priced under $2. |
| 22:39:18 | speachy | probably clones of a reference design from the ASIC maker. |
| 22:39:51 | braewoods | don't cpus with their own embedded memory have lower latency to access it? |
| 22:39:56 | braewoods | i would think so |
| 22:40:06 | speachy | depends on how the memory was embedded |
| 22:40:35 | braewoods | i see. |
| 22:40:53 | braewoods | is it always DRAM? I know SRAM has lower power requirements and such |
| 22:41:11 | speachy | DRAM is much denser (and therefore cheaper) on a bit-by-bit basis. |
| 22:41:45 | speachy | DRAM loses on the power front becuase it needs to be constantly refreshed. |
| 22:42:02 | speachy | whereas SRAM will hold its contents as long as power remains applied. |
| 22:42:57 | braewoods | right. |
| 22:43:04 | braewoods | i know SRAM is still used. |
| 22:43:09 | braewoods | afaik x86 cpu cache is SRAM |
| 22:43:15 | speachy | but SRAM can get tightly coupled −− the last gig I had we had 12K of SRAM that had zero-cycle latency. :) |
| 22:43:40 | speachy | (running at 32MHz) |
| 22:44:11 | speachy | but the overriding priority for that design was obscenely low sleep current |
| 22:49:02 | speachy | on a typical MCU you'll have some TCRAM / IRAM that's effectively zero-cycle access (and relatively tiny), possibly additional (and slower) on-chip SRAM, and possibly external DRAM. and perhaps flash too, for devices that allow exeuction from flash, but that can have some relatively heinous random access latencies. |
| 22:50:12 | speachy | you'll want to put the most performance-critical code in the fastest, lowest-latency RAM. |
| 22:50:41 | speachy | (as well as any code that needs to run before you have initialized your DRAM controller...) |
| 22:51:06 | speachy | oh, if I'm prattling on about stuff you already know please tell me |
| 22:52:07 | *** | Saving seen data "./dancer.seen" |
| 22:56:51 | braewoods | not really; i've never needed to care about any of this other than when installing components |
| 23:00 |
| 23:00:19 | speachy | all the stuff Linux (and low-level boot code!) normally does for us we have to do ourselves. |
| 23:04:16 | | Quit Acou_Bass (Ping timeout: 256 seconds) |
| 23:07:08 | | Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
| 23:08:49 | braewoods | speachy: though not all of it; Linux needs its own bootloader after all |
| 23:08:55 | braewoods | grub, etc |
| 23:09:22 | speachy | I was actually thinking more like uboot or the BIOS/UEFI layer |
| 23:09:55 | braewoods | afaik Linux is only self-booting on UEFI if built as an application |
| 23:10:12 | braewoods | otherwise it needs something between the firmware and itself to boot |
| 23:12:28 | speachy | things like setting up the DRAM controller and the SoC clocks |
| 23:12:50 | fs-bluebot | Build Server message: New build round started. Revision 0f23cad, 280 builds, 7 clients. |
| 23:13:42 | _bilgus__ | and with that the lua file browser has sort by name, size, date |
| 23:14:19 | speachy | heh. I find myself idly wondering if it rewriting our UI in LUA makes sense. |
| 23:15:11 | _bilgus__ | see there are things I really like about lua but there are things I REALLY HATE |
| 23:18:40 | _bilgus__ | I only 'improved' our version because I see it as a way to put the onus on users to do their own expansion Fs#13226 for instance :p |
| 23:18:41 | fs-bluebot | http://www.rockbox.org/tracker/task/13226 Allow for per-directory sort settings (feature requests, closed) |
| 23:19:59 | _bilgus__ | though pamaury said he probes devices with lua and it is surely a good lang for those quick kinda scripts |
| 23:21:34 | _bilgus__ | then again it wouldn't be that hard to do what you are saying and it sorta jives with a project I was toying with namely uncoupling the WPS from the core |
| 23:25:27 | _bilgus__ | your lang in plugins open both possibilities |
| 23:26:11 | _bilgus__ | I suppose that also depends if all our targets could run the lua core |
| 23:26:26 | speachy | yeah, we still have several 2MB targets. |
| 23:30:52 | _bilgus__ | theres several tens of kb that can be freed by excising unused builtins and such but lua is a very good at fragging ram |
| 23:31:40 | _bilgus__ | i was gonna say memory hungry and its that too but its more of the way it pigs up what it does have |
| 23:33:43 | speachy | much lower-hanging fruit than that to deal with. |
| 23:33:53 | speachy | like, say, bluetooth support |
| 23:34:38 | fs-bluebot | Build Server message: Build round completed after 1308 seconds. |
| 23:34:44 | _bilgus__ | yeah I do have a few more examples at home that I need to remember to commit a music player in lua and maybe some more rlimage examples |
| 23:34:50 | fs-bluebot | Build Server message: Revision 0f23cad result: All green |
| 23:36:41 | _bilgus__ | that would be pretty easily handled by lua actually |
| 23:37:28 | _bilgus__ | how do you talk to the bluetooth controller? file handles I assume |
| 23:38:16 | _bilgus__ | and with the open plugin stuff I added it also wouldn't be too hard to integrate into the menu somewhere |
| 23:44:55 | braewoods | _bilgus__: is this on Linux? |
| 23:45:12 | braewoods | i might be able to help with bluez as it's the same crap used on desktop Linux |
| 23:45:13 | _bilgus__ | pretty sure the hosted devices are linux |
| 23:45:45 | _bilgus__ | I don't even have a rocker to test do you? |
| 23:45:54 | braewoods | no i don't |
| 23:46:02 | braewoods | i thought you did lol |
| 23:46:43 | | Quit TheSeven (Disconnected by services) |
| 23:46:53 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
| 23:47:11 | _bilgus__ | hehe no I really like sansa and I recently traded a clipzip for a xduoo with speachy |
| 23:50:41 | _bilgus__ | otherwise its really hard to dev without having a device in hand |
| 23:50:56 | _bilgus__ | not that I haven't done so.. |
icon identifies that the person is a core developer (has commit access).