| 00:03:54 | speachy | make that tuesday. email sent to the list for a heads-up and any last-minute objections. |
| 00:25:38 | | Quit ac_laptop (Ping timeout: 260 seconds) |
| 00:36:23 | *** | Saving seen data "./dancer.seen" |
| 00:36:44 | __builtin | hmm, I'm pretty sure 4.9.4 breaks quake on ipod6g |
| 00:37:10 | __builtin | "breaks" as in hanging on exit IIRC |
| 00:40:06 | _bilgus_ | g#2811 is updated to where I've gotten to currently |
| 00:40:08 | fs-bluebot | Gerrit review #2811 at http://gerrit.rockbox.org/r/2811 : LCD core move buf ptr and address look up function viewport struct WIP by William Wilgus |
| 00:41:12 | _bilgus_ | basically the mechanism is there but there are still some things that will disappear from plugin.c/h and some clean up + remote displays |
| 00:42:26 | _bilgus_ | probably the lcd_address lookup might be better in ASM but I imagine with the static buffers it'll be not a big difference |
| 00:44:16 | __builtin | hehe, from 2006: https://www.rockbox.org/irc/log-20060309#06:00:50 |
| 00:44:30 | __builtin | That seals it. I'm insane. |
| 00:45:43 | speachy | you're in good company |
| 00:48:23 | _bilgus_ | I thought that was one of the pre-reqs |
| 00:49:23 | __builtin | speachy: anyway, regarding 4.9.4 I'm fine if you push it |
| 00:49:56 | __builtin | the bug itself is pretty minor and that'll give me the motivation to fix it :) |
| 00:50:27 | speachy | several plugins segfault on exiting from the hibylinux stuff too |
| 00:50:33 | speachy | unreliably |
| 00:51:19 | __builtin | someone just needs to spend an afternoon with a debugger and some luck, I bet |
| 00:51:27 | _bilgus_ | oh speaking of weird hangs that rolo hang on the x3 works its self out usually given enough time |
| 00:52:03 | speachy | _bilgus_: really? that's... a really useful datum |
| 00:52:07 | _bilgus_ | perhaps even every time given infinite time limits;) |
| 00:52:11 | __builtin | I had one in the course of the quake port that turned out to be an off-by-one in a loop condition |
| 00:53:54 | _bilgus_ | the thing that bothered me the most is working between lua and the RB C backend pretty much a off by one waiting to happen every traversal between the two |
| 00:54:20 | __builtin | I had the equivalent of i−−; do { ... } while(−−i != 0); |
| 00:54:26 | __builtin | in assembly, of coruse |
| 00:54:40 | __builtin | so it'd break whenever i=1 and loop around to 0xffffffff |
| 00:54:56 | _bilgus_ | they say thats faster because the one less check but I mess it up more than not |
| 00:55:38 | __builtin | it'd then proceed to loop 0xffffffff times, which led to a nice 10-minute delay |
| 00:56:55 | __builtin | hard to say but it sounds like something similar could be happening here, who knows |
| 00:57:15 | speachy | __builtin: https://twitter.com/secretGeek/status/7269997868 |
| 00:57:20 | _bilgus_ | ah I got ya I figured there was something hold the memory |
| 00:57:31 | | Quit galaxy_knuckles (Ping timeout: 246 seconds) |
| 00:57:41 | __builtin | the issue was i != 0 as the condition |
| 00:57:54 | __builtin | fixed by using > (bne -> bgt in asm) |
| 00:58:47 | speachy | _bilgus_: the thing is, there's not a lot steps to block in the rolo code, between "loading" and the "executing" that doesn't show.. |
| 00:59:16 | speachy | maybe it's the core_alloc_maximum() that's blocking? |
| 00:59:27 | _bilgus_ | my thought.. |
| 00:59:28 | speachy | I guess it wouldn't hurt to add in a few more display updates |
| 00:59:56 | | Join galaxy_knuckles [0] (~gknux@db4g.com) |
| 00:59:56 | | Quit galaxy_knuckles (Changing host) |
| 00:59:56 | | Join galaxy_knuckles [0] (~gknux@unaffiliated/galaxy-knuckles/x-1756549) |
| 01:00 |
| 01:00:21 | _bilgus_ | it might be a badly behaving buffer not realsing in a timely manner |
| 01:00:45 | speachy | isn't audio-related though; this happens indpedently of audio running |
| 01:01:34 | _bilgus_ | not sure but probably generally when i'm using rolo I don't have audio playing |
| 01:01:54 | speachy | voice prompts? |
| 01:02:07 | _bilgus_ | doesn't mean thats not the case but I'll try to pay closer attention to the exact circumstances |
| 01:02:22 | _bilgus_ | I think voice does set fixed buffers |
| 01:02:29 | speachy | my usual run is to power on, dump firmware over, hit play on rolo prompt |
| 01:02:57 | speachy | anectdotally the longer I wait at the prompt, the more likely it is to get stuck. |
| 01:02:57 | _bilgus_ | though I added code to dump the voice buffers recently so that might work to test |
| 01:03:34 | speachy | we don't HAVE_STORAGE_FLUSH or HAVE_BOOTDATA |
| 01:04:15 | speachy | so that leaves audio_stop(), the core_alloc_maximum(), core_get_Data(), and load_firmware(). |
| 01:04:19 | _bilgus_ | bootdata would actually be nice on hosted builds emulated ofc |
| 01:04:57 | _bilgus_ | mm once I figure out something with jHMikeS redirection code lol |
| 01:05:02 | speachy | I have on my todo list to get rolo working on hosted targets. ought to be easy, unless I'm missing something really fundamental |
| 01:05:43 | speachy | (I guess we'd want to make sure all open fds are closed upon exec()) |
| 01:06:15 | _bilgus_ | I think the FS keeps track and warns oh nm thats only for plugins |
| 01:06:59 | _bilgus_ | but yeah good point just odd that it works elsewhere |
| 01:07:30 | speachy | I Think nobody ever bothered to write it |
| 01:08:41 | _bilgus_ | ah Mr.Somebodys arch nemesis! |
| 01:47:53 | fs-bluebot | Build Server message: New build round started. Revision 5cfd3ae, 287 builds, 10 clients. |
| 01:57:22 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 02:00 |
| 02:02:28 | fs-bluebot | Build Server message: Build round completed after 874 seconds. |
| 02:02:30 | fs-bluebot | Build Server message: Revision 5cfd3ae result: All green |
| 02:36:27 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:15:34 | | Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) |
| 03:24:35 | | Quit prof_wolfff (Ping timeout: 240 seconds) |
| 03:45:45 | fs-bluebot | Build Server message: New build round started. Revision c8fa530, 287 builds, 10 clients. |
| 04:00 |
| 04:00:24 | fs-bluebot | Build Server message: Build round completed after 880 seconds. |
| 04:00:27 | fs-bluebot | Build Server message: Revision c8fa530 result: All green |
| 04:05:43 | | Join w4tchguard [0] (~w4tchguar@2001:ac8:84:33::a10d) |
| 04:18:39 | | Join Xeha [0] (~Xeha@unaffiliated/xeha) |
| 04:30:31 | braewoods | speachy: interesting. seems the CF mod has 2 issues with the latest current bootloader. ata -80 error when exiting USB mode or when trying to boot from disk. |
| 04:30:46 | braewoods | i'm guessing they're related since it worked with the original disk |
| 04:31:06 | braewoods | anyway that's more than enough reason to try to fix it |
| 04:36:29 | *** | Saving seen data "./dancer.seen" |
| 04:50:29 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 05:00 |
| 05:05:31 | | Quit SiliconExarch (Quit: Idle for 30+ days) |
| 05:10:59 | | Quit w4tchguard (Remote host closed the connection) |
| 05:11:18 | | Join w4tchguard [0] (~w4tchguar@2001:ac8:84:33::a10d) |
| 05:21:39 | | Quit S|h|a|w|n (Read error: Connection reset by peer) |
| 05:58:18 | | Join johnb3 [0] (~johnb2@p5b3af6d7.dip0.t-ipconnect.de) |
| 06:00 |
| 06:03:25 | johnb3 | speachy, _bilgus_ : I mentioned that I wanted to run batterybench on the X3ii. When connecting to my PC againg, I was annoyed to see, that no file was created. I thought maybe I hit a wrong button and it didn't run at all. But no, starting it again, it briefly flashes "Cannot create file", then "plugin returned error". This was with 7c00e9b30b-201010 |
| 06:36:32 | *** | Saving seen data "./dancer.seen" |
| 06:41:46 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 07:00 |
| 07:02:54 | pamaury | lebellium: I will have a look but I need the key from the device |
| 07:03:00 | pamaury | it can't be guessed |
| 07:05:25 | | Quit johnb3 (Ping timeout: 240 seconds) |
| 07:08:31 | pamaury | lebellium: actually, I do have the DMP-Z1 key, I just didn't commit it, I will now and upload a build |
| 07:11:07 | fs-bluebot | Build Server message: New build round started. Revision e371dee, 287 builds, 10 clients. |
| 07:20:32 | lebellium | great |
| 07:23:50 | fs-bluebot | Build Server message: Build round completed after 763 seconds. |
| 07:23:51 | fs-bluebot | Build Server message: Revision e371dee result: All green |
| 07:29:55 | | Quit w4tchguard (Ping timeout: 240 seconds) |
| 07:41:44 | | Join Soap [0] (~Soap@rockbox/staff/soap) |
| 07:52:25 | | Quit pamaury (Ping timeout: 264 seconds) |
| 07:59:41 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 08:00 |
| 08:11:35 | fs-bluebot | Build Server message: New build round started. Revision fcdfeb2, 287 builds, 10 clients. |
| 08:13:21 | speachy | johnb3: There's probably a plugin path problem due to the funky pivot_root thing going on for hosted builds |
| 08:14:56 | speachy | thought I'd fixed all of that though |
| 08:17:13 | blbro[m] | [pamaury](https://matrix.to/#/@freenode_pamaury:matrix.org): I'm planning to push the tomcrypt stuff soonish, in case you still want to give it a look. |
| 08:20:24 | speachy | johnb3: yeah, found it, fixing now. |
| 08:22:06 | speachy | _bilgus_: I think we need to yank HOME_DIR from all users of the plugin API. This is limited to a handful of test_ plugins... and lua. |
| 08:23:38 | fs-bluebot | Build Server message: Build round completed after 724 seconds. |
| 08:23:40 | fs-bluebot | Build Server message: Revision fcdfeb2 result: All green |
| 08:24:45 | | Join prof_wolfff [0] (~prof_wolf@26.red-83-54-195.dynamicip.rima-tde.net) |
| 08:24:47 | pamaury | blbro[m]: ah yeah, let me have a try, can you give ne the gerrit link again ? |
| 08:25:48 | speachy | pamaury: starting at https://gerrit.rockbox.org/r/#/c/2641 |
| 08:26:36 | | Join johnb3 [0] (~johnb2@p5b3af6d7.dip0.t-ipconnect.de) |
| 08:36:04 | pamaury | speachy: blbro[m]: just tried to decrypt a file and seems to work |
| 08:36:36 | *** | Saving seen data "./dancer.seen" |
| 08:38:19 | speachy | _bilgus_: actually I think every user outside of the actual filesystem code is a bug. |
| 09:00 |
| 09:10:16 | _bilgus_ | speachy, doubt lua uses it in a meaningful way besides as just a Const |
| 09:11:38 | speachy | _bilgus_: ok, I'm yanking the constant defines. it's not referenced by any of the scripts |
| 09:12:23 | speachy | all but one remaining use is in calls to create_[datetime|numbered]_filename() |
| 09:23:14 | | Quit ufdm_ (Quit: Leaving) |
| 09:23:31 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 09:30:12 | pamaury | lebellium: the tool is at https://www.rockbox.org/wiki/SonyNWUPGTool |
| 09:30:19 | pamaury | I will try to write instructions on how to use it |
| 09:35:00 | lebellium | thank you |
| 09:35:42 | | Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) |
| 09:35:44 | braewoods | speachy: any idea what host environment the build bots use? |
| 09:36:32 | lebellium | in the wiki table I think nw-wm1 code is now split between nw-wm1a and nw-wm1z ? |
| 09:42:54 | pamaury | yes indeed |
| 09:43:16 | pamaury | that table is obsolete, it should be generated from the code since there is a list of kas in there... |
| 09:55:00 | speachy | braewoods: they're whatever their respective owners set up. It's not tracked. Mine are all fedora-based FWIW |
| 10:00 |
| 10:09:58 | braewoods | Ok. |
| 10:11:53 | speachy | ha! it works! |
| 10:11:56 | speachy | ROLO on hosted targets. |
| 10:16:08 | braewoods | speachy: in theory, wouldn't the be as simple as the program doing an exec on itself or other executable? |
| 10:16:27 | braewoods | depending on whether you want to replace the existing process or make a new one and exit |
| 10:16:36 | speachy | braewoods: yes indeed. though some prep work was needed first to close down open files/etc |
| 10:16:43 | braewoods | indeed. |
| 10:17:05 | braewoods | same idea as certain muds that did copyover as an exec on itself |
| 10:17:21 | speachy | heh, haven't heard that term in a long time |
| 10:17:36 | braewoods | they'd save some state or so so the new instance could reinitialize the existing network connections |
| 10:17:46 | speachy | muts also needed to maintain state, we don't have that worry. |
| 10:18:01 | braewoods | you actually have the opposite problem |
| 10:18:10 | braewoods | you want to deinitialize as much as possible for a clean transfer |
| 10:18:12 | speachy | (well, we have the so-called bootdata, but that doesn't exist on any hosted target) |
| 10:18:43 | fs-bluebot | Build Server message: New build round started. Revision 6533d98, 287 builds, 10 clients. |
| 10:18:46 | braewoods | plus you could also leverage posix shared memory or so if you need to persist memory structures |
| 10:19:03 | braewoods | though that has its own problems |
| 10:19:20 | braewoods | you effectively can't share anything but PODs in this system since pointers are worthless |
| 10:19:45 | braewoods | those are relative to a process' own memory map and so pointers are non-portable between processes |
| 10:20:04 | speachy | but in our case we want to explicitly blow it all away; the issues tend to come from things like init code not handling hardware not in idle/powerup/reset state etc |
| 10:20:29 | braewoods | right. less of an issue on a hosted target though? |
| 10:20:34 | braewoods | since the kernel handles all that |
| 10:20:44 | braewoods | at most you might be writing to sysfs |
| 10:20:52 | braewoods | or performing ioctl calls |
| 10:21:03 | speachy | exactly. except for held-open file descriptors |
| 10:21:10 | braewoods | and a few other inherited stuff |
| 10:21:26 | pamaury | lebellium: I've written stuff in https://www.rockbox.org/wiki/SonyNWUPGTool this should hopefully help with the tool |
| 10:21:43 | efqw | speachy: tbh I'd rather see fiio pushing an ota to update the recovery and remove the signature check |
| 10:22:08 | braewoods | efqw: is that even something you could get cooperation on? |
| 10:22:15 | speachy | efqw: well, yeah, but if they thought it was important to implement that crap to begin with, convingcing them it's not necessary is a much harder battle |
| 10:22:38 | speachy | efqw: I wonder if the FiiO firmware implements DRM (eg in wma files) |
| 10:22:49 | efqw | No, I'm convinced that this is not intentional, they just took what Ingenic offered in the BSP as-is. |
| 10:22:52 | braewoods | WMA DRM is effectively dead... |
| 10:22:58 | braewoods | what else is there? |
| 10:23:09 | braewoods | audible or whatever? |
| 10:23:11 | efqw | braewoods: I have no leverage on this unfortunately. |
| 10:23:27 | lebellium | pamaury: yes I just read that, thank you. I was wondering whether we should explain how to get the UPG file because Sony actually only provides .EXE firmware files for the latest models. To get the UPG file I had to execute the .exe and go to the TEMP directory used by Sony |
| 10:23:27 | braewoods | so probably better to find a workaround |
| 10:23:31 | speachy | efqw: the ingenic sdk supplied that signed-zip monstrosity? gack |
| 10:23:48 | efqw | Did you download the sdk? |
| 10:23:51 | speachy | but I get the ingenic stuff wanting to support DRM (soc has hardware video decoder) |
| 10:23:59 | braewoods | efqw: can you modify the recovery? |
| 10:24:06 | speachy | I have a copy somewhere but I never bothered to poke around in it. |
| 10:24:08 | braewoods | perhaps you can patch out the problem. |
| 10:24:47 | braewoods | depends if the bootloader is locked so to pseak |
| 10:24:49 | braewoods | speak |
| 10:24:50 | efqw | braewoods: that is our fallback plan, we *do* have the capability to flash whatever we want onto the device right now, with the help of the usb cloner tool |
| 10:24:52 | braewoods | but if it isn't |
| 10:25:11 | braewoods | you can theoretically disable or install your own signing keys |
| 10:25:32 | braewoods | probably would be simpler to disable it |
| 10:25:33 | efqw | that'd be pointless as we might as well just update the rootfs UBI directly |
| 10:26:23 | braewoods | efqw: honestly the only other option i know of is to have the private key and those are effectively impossible to bruteforce |
| 10:26:27 | pamaury | lebellium: yes that's a good point |
| 10:26:48 | braewoods | efqw: realistically i only see one option short of some other oversight in their implementation |
| 10:26:57 | braewoods | patching it out |
| 10:27:18 | braewoods | but yea |
| 10:28:15 | braewoods | on the bright side since the recovery is a standard ELF binary... its binary format is well known so it should be easier to patch. |
| 10:28:25 | braewoods | o.O |
| 10:28:34 | braewoods | at least i assume that from what i saw being said earlier |
| 10:28:56 | braewoods | linux pretty much exclusively relies on ELF for all its binaries |
| 10:29:24 | efqw | speachy: keep in mind that the ingenic BSP was originally intended for those internet-connected (spy) speakers |
| 10:29:45 | efqw | the deal just didn't pan out, not many speakers used their chips unfortunately |
| 10:30:03 | pamaury | lebellium: I just created a subsection in UPGTool on this. Could you help me fill it ? I almost never use Windows |
| 10:30:05 | speachy | braewoods: if we are forced to use the burntool we'll just upload our own patched main firmware image. we can update it from the inside afterwards. |
| 10:30:22 | braewoods | right |
| 10:30:29 | efqw | The speaker market is mostly Allwinner or MediaTek nowadays I believe. |
| 10:30:43 | speachy | mucking with recovery code is... dangerous. legally as well as technically. |
| 10:31:01 | efqw | MediaTek for Android based ones and Allwinner for everything else. |
| 10:31:34 | efqw | Rockchip also did RK3308 but I haven't seen any speakers with that SoC either. |
| 10:31:45 | braewoods | allwinner... they're a pretty popular ARM target for Linux boards. |
| 10:31:48 | speachy | if this pine64 lark works out in the end we'll probably end up with an allwinner-based DAP |
| 10:32:05 | speachy | either F1C-series or V3-series |
| 10:32:15 | braewoods | Not the A20 and such? |
| 10:32:26 | braewoods | that's the one i read about most. |
| 10:32:40 | braewoods | they're capped at 2GB due to hardware limitations i believe |
| 10:32:57 | efqw | We don't even need more than 1GB for rb. |
| 10:33:09 | efqw | 256M is plenty even for a hosted target. |
| 10:33:11 | braewoods | you get by with far less than that even |
| 10:33:49 | fs-bluebot | Build Server message: Build round completed after 906 seconds. |
| 10:33:51 | fs-bluebot | Build Server message: Revision 6533d98 result: All green |
| 10:33:52 | fs-bluebot | Build Server message: New build round started. Revision 4e89e0e, 287 builds, 9 clients. |
| 10:33:53 | speachy | vast, vast overkill. |
| 10:34:01 | braewoods | indeed. |
| 10:34:12 | braewoods | it might be good for IO performance during syncs but little else |
| 10:34:22 | speachy | the F1C and V3 stuff has on-package RAM too, which greatly reducess the PCB size and complexity |
| 10:34:33 | braewoods | how much? |
| 10:34:44 | braewoods | i'd think at least 64MB |
| 10:34:49 | efqw | Not to mention it significantly reduces the amount of engineering efforts required to route the PCB |
| 10:34:55 | speachy | F1C is 32 or 64, V3 is 64 or 128. |
| 10:35:01 | braewoods | I see. |
| 10:35:03 | efqw | F1C100s has 32MB and F1C200s has 64MB |
| 10:35:08 | braewoods | you'd probably want some room to grow... |
| 10:35:23 | speachy | even the lowest-end F1C has more than enough oomph to run everything rockbox has today. save perhaps Quake. |
| 10:35:23 | braewoods | but obviously there's a realistic limit. what would you use it for? |
| 10:35:30 | braewoods | the main thing i can see is more caching |
| 10:35:41 | speachy | cachine with solid state storage is not terribly important |
| 10:35:54 | speachy | ...I'd like 64. |
| 10:36:02 | efqw | F1C200s then? |
| 10:36:16 | speachy | the F1C100 can be had under $1 |
| 10:36:21 | efqw | What about the PMU? We need a real PMU like the AXP192. |
| 10:36:34 | braewoods | PMU? |
| 10:36:37 | *** | Saving seen data "./dancer.seen" |
| 10:36:37 | braewoods | power management? |
| 10:36:49 | speachy | PMU ultimately depends on what the rest of the board needs. if we have external codecs then sure, a PMU makes sense |
| 10:36:58 | | Quit kadoban (*.net *.split) |
| 10:37:00 | | Quit danielp3344 (*.net *.split) |
| 10:37:00 | efqw | Yeah, for battery charging and stuff like DC-DC |
| 10:37:10 | speachy | the V3+AXP208 (?) can be had for only a few $ in small quantities. |
| 10:37:11 | braewoods | oh. a BMS so to speak. |
| 10:37:18 | | Join kadoban [0] (kadobanmat@gateway/shell/matrix.org/x-vbpdmawecokvypon) |
| 10:37:19 | | Join danielp3344 [0] (danielp334@gateway/shell/matrix.org/x-urgmduafmxhabyqd) |
| 10:38:01 | efqw | The AXP stuff has built-in battery gauge so you can have pretty accurate runtime estimates compared to the voltage-based solutions |
| 10:38:13 | speachy | the F1C would be a good native candidate out of the box, the V3 is fast enough to handle hosted well, and would be an absolute screamer running natively |
| 10:38:33 | braewoods | and if you're building a design from scratch... |
| 10:38:37 | speachy | (1.2GHz Cortex A7..) |
| 10:38:48 | braewoods | you can tweak it to reflect what rockbox is capable of or so |
| 10:38:52 | | Quit amiconn (*.net *.split) |
| 10:38:52 | | Quit pixelma (*.net *.split) |
| 10:38:54 | | Quit bzed (*.net *.split) |
| 10:38:54 | efqw | yeah, I hope you have some fun with the pocketgo |
| 10:39:09 | | Join amiconn [0] (jens@rockbox/developer/amiconn) |
| 10:39:09 | | Join pixelma [0] (marianne@rockbox/staff/pixelma) |
| 10:39:09 | | Join bzed [0] (~bzed@shell.bzed.at) |
| 10:39:29 | speachy | both would work reasonably well with their internal codecs −− and for higher-end audio external codec options are legion |
| 10:39:32 | braewoods | though i'm no electrical engineer |
| 10:40:00 | braewoods | assuming that's the career field for designing electronics |
| 10:41:19 | | Quit Huntereb (Ping timeout: 246 seconds) |
| 10:42:08 | efqw | here's something to put on the wishlist if you're interested: I want a FM tuner as well |
| 10:42:22 | | Quit Xeha (Ping timeout: 246 seconds) |
| 10:42:43 | efqw | those can be had for under $1 and takes advantage of the unused stereo input that the F1C has |
| 10:43:14 | speachy | efqw: http://www.shaftnet.org/~pizza/rb-wishlist.txt |
| 10:44:27 | | Join Xeha [0] (~Xeha@unaffiliated/xeha) |
| 10:44:31 | braewoods | efqw: what about the digital FM extensions? |
| 10:44:42 | braewoods | would those be too difficult to support? |
| 10:44:51 | braewoods | hd radio, etc |
| 10:44:55 | efqw | speachy: oh I missed it, lol |
| 10:44:57 | speachy | braewoods: they are pretty power hungry and have extra licensing costs too, I think |
| 10:45:03 | braewoods | ah. |
| 10:45:08 | braewoods | just thought i'd throw that out there |
| 10:45:18 | braewoods | in some places analog FM is gone |
| 10:45:21 | braewoods | iirc |
| 10:45:40 | braewoods | there's "Hd radio" here but i've never owned a receiver |
| 10:45:42 | speachy | the data/text sideband on analog fm is suppored widely in tuner ICs, but full HD radio stream decoding is another matter |
| 10:46:15 | braewoods | i've experimented with SDRs and got it kinda working but not really |
| 10:46:35 | braewoods | it's not as good as a hardware option |
| 10:46:37 | braewoods | lol |
| 10:47:01 | braewoods | interesting how CPU intensive SDRs are even for really old analog stuff |
| 10:47:43 | braewoods | that must be why it's always done in hardware for serious implementations |
| 10:48:28 | fs-bluebot | Build Server message: Build round completed after 876 seconds. |
| 10:48:29 | fs-bluebot | Build Server message: Revision 4e89e0e result: All green |
| 10:48:52 | efqw | What's the BT module in the rocker? |
| 10:49:02 | speachy | CSR8821 I think |
| 10:49:12 | braewoods | does it matter? i thought everything used USB bluetooth. |
| 10:49:15 | efqw | UART based right? |
| 10:49:25 | speachy | UART (or USB) with I2S for audio. |
| 10:49:36 | braewoods | since that's what every PC i've ever used has implemented bluetooth with |
| 10:50:37 | efqw | but this is not PC |
| 10:50:41 | braewoods | indeed |
| 10:50:48 | braewoods | i just thought USB was the primary option |
| 10:50:55 | efqw | on embedded systems it's mostly UART with an optional pcm interface |
| 10:51:00 | lebellium | pamaury: yes I'll have a look a bit later |
| 10:51:26 | speachy | the only physical interfaces formally defined by the BT standards are UART, USB, and (I think) SDIO. I don't recall ever seeing the latter implemented. |
| 10:51:54 | braewoods | why do people use bluetooth? |
| 10:51:59 | braewoods | it seems really... weak |
| 10:52:03 | braewoods | low bandwidth, low range... |
| 10:52:07 | speachy | braewoods: you mean besides the whole "no wires" thing? :) |
| 10:52:19 | braewoods | yea |
| 10:52:30 | braewoods | it seems like a giant hassle with minimal gains |
| 10:52:31 | speachy | braewoods: and non-shitty BT audio codecs have been around for nearly as long as BT. |
| 10:53:00 | speachy | bluetooth is more than good enough for what it was designed to do. |
| 10:53:18 | efqw | speachy: you'd be surprised, check out drivers/bluetooth/*sdio.c |
| 10:53:19 | braewoods | wirelessly connecting low power accessories? |
| 10:53:30 | braewoods | or low bandwidth |
| 10:53:31 | braewoods | rather |
| 10:53:50 | braewoods | i wouldn't waste time implementing BT file transfe |
| 10:53:51 | braewoods | transfer |
| 10:53:56 | braewoods | it's too slow to be practical |
| 10:54:25 | efqw | btmtksdio.c, btmrvl_sdio.c, btsdio.c |
| 10:54:27 | speachy | BT for raw data transfer is rare |
| 10:54:30 | braewoods | usb can easily do megabytes... last time i tried BT file transfer it was measured in kilobytes |
| 10:54:32 | braewoods | lol |
| 10:54:59 | speachy | BT 3.0 (I think) defined a high data rate transfer that basically consisted of handing the data over to wifi. |
| 10:55:15 | braewoods | i see |
| 10:59:44 | efqw | Remember ampak? |
| 11:00 |
| 11:00:03 | efqw | I think we can get FM+WiFi+BT modules from them. |
| 11:00:33 | efqw | Even if we don't plan to use WiFi, it still fulfills the need for a FM tuner |
| 11:00:43 | speachy | I do not want wifi. it's going to add a ton of system complexity. |
| 11:00:55 | speachy | plus extra regulatory headaches |
| 11:00:55 | braewoods | i could only see one use to wifi and even then it would require a network stack to leverage |
| 11:01:14 | efqw | BT still has the regulatory headaches tbh |
| 11:01:27 | braewoods | i have setup icecast and mpd before |
| 11:01:29 | speachy | yes, but they are more self-contained |
| 11:01:56 | braewoods | you could remotely control rockbox over the network and such |
| 11:02:00 | braewoods | other than that I see little use |
| 11:02:30 | braewoods | i made a network controlled music player before |
| 11:02:35 | speachy | braewoods: "streaming audio" is quite useful, but it's not one that makes much sense for us. |
| 11:02:43 | braewoods | indeed |
| 11:02:53 | braewoods | so more in the area of |
| 11:02:55 | braewoods | MPD |
| 11:03:05 | braewoods | which allows remote control of what the linux system is playing |
| 11:03:08 | speachy | given there are plenty of alternatives on the market today. plus we'd probably never manage to get "apps" for the commercial services. |
| 11:03:10 | efqw | My point is, you can power down the WiFi part, and you still get BT+FM within one module. |
| 11:03:29 | braewoods | who needs apps for rockbox? |
| 11:03:34 | Ctcp | Ignored 2 channel CTCP requests in 1 hour and 28 minutes at the last flood |
| 11:03:34 | * | braewoods boggles |
| 11:03:36 | efqw | That will help with board layout and simplify the design. |
| 11:03:42 | speachy | braewoods: have you seen the plugin list? :) |
| 11:03:49 | braewoods | lol |
| 11:04:10 | braewoods | speachy: but yea, remote control via networking would be cool but that's the only use i see |
| 11:04:13 | braewoods | that's how MPD works |
| 11:04:27 | braewoods | it plays music on a system and remote users can control what it is doing |
| 11:04:33 | braewoods | it is network enabled |
| 11:04:37 | braewoods | but differnet use case |
| 11:04:56 | braewoods | if i was going to do that for RB, i'd probably write a bridge between MPD protocol and RB internals |
| 11:05:08 | braewoods | since MPD is well established |
| 11:05:13 | braewoods | plenty of clients for it |
| 11:05:44 | speachy | I have extensive network-controlled audio but tbh rockbox is poorly suited from a UI perspective; there are vastly superior ones already to be had |
| 11:05:55 | speachy | (even completely F/OSS ones) |
| 11:06:04 | braewoods | indeed so i'd just have it be a remote control interface of some kind |
| 11:06:26 | braewoods | there's another idea... |
| 11:06:36 | speachy | I mean, a RPi+Hifiberry DAC will cost you what, $30? |
| 11:06:38 | braewoods | replicate the RB UI in a web interface or so |
| 11:07:13 | braewoods | but kinda pointless |
| 11:07:37 | speachy | RB UI in a web interface would be as awful as our current touchscreen UI is today |
| 11:08:15 | braewoods | speachy: was the GCC toolchain updated? i'm building the toolchain and the script appears to have switch to 4.9.x |
| 11:08:19 | braewoods | at least for some targets? |
| 11:08:33 | speachy | braewoods: mips and hosted stuff has been 4.9.x for a couple of years now, I think. |
| 11:08:40 | braewoods | oh. |
| 11:08:42 | braewoods | ok. |
| 11:09:03 | efqw | I looked it up, the common AP6212 will do, it does BT4.0 and FM. Problem here is that I don't see separate pins to power down the WiFi part. |
| 11:09:03 | braewoods | it's weird how i see mips come up in embedded targets every now and then |
| 11:09:22 | efqw | Broadcom had other chips that allow you to power down individual parts of the chip. |
| 11:09:33 | braewoods | broadcom is terrible about open source support though |
| 11:09:59 | braewoods | at best the linux kernel usually manages to... |
| 11:10:13 | braewoods | work with a mixture of firmware blobs and kernel drivers |
| 11:10:37 | speachy | broadcom will be absolutely horrible to work with. |
| 11:10:46 | speachy | if we don't have a volume in the seven digits |
| 11:10:56 | speachy | they won't even answer the phone |
| 11:10:59 | efqw | Is CSR(qcom) any better though? |
| 11:11:06 | braewoods | qualcomm? |
| 11:11:14 | braewoods | they bought atheros... |
| 11:11:23 | speachy | CSR actually is better, but what helps is that their BT stuff is very self-contained. |
| 11:11:27 | braewoods | their qualcomm / atheros chips tend to be good |
| 11:11:36 | speachy | no massive blobs, GPL violations, etc etc |
| 11:11:37 | braewoods | some older ones work without any firmware blobs |
| 11:11:58 | efqw | MediaTek probably won't answer the phone either if you ask them about Airoha chips unfortunately. |
| 11:12:02 | speachy | their wifi stuff has been barely tolerable at bast though |
| 11:12:27 | speachy | (I have scars from dealing with Atheros back in the day; qualcomm made it _worse_) |
| 11:12:50 | braewoods | mediatek is pretty awful as well |
| 11:12:59 | braewoods | their official wifi drivers are 100% proprietary |
| 11:13:10 | braewoods | you can't even redistribute the source so... |
| 11:13:12 | efqw | What I like about CSR is that you can store the firmware on a flash sometimes and don't have to worry about fw blobs. |
| 11:13:21 | braewoods | it's hard to get updated images for openwrt |
| 11:13:38 | braewoods | though the openwrt community has tried to develope their own driver for it |
| 11:13:41 | braewoods | it's still got issues |
| 11:14:32 | braewoods | i hope pine microsystems is of some help |
| 11:15:03 | speachy | pamaury: It looks like that the NWZ_LINUX targets are likely broken with respect to anything that uses HOME_DIR. |
| 11:17:42 | braewoods | speachy: HOME_DIR? afaik there's 2 ways to look that up. assume the environment HOME variable is correct or look it up in passwd. |
| 11:18:10 | speachy | HOME_DIR is a build-time constant, see firmware/export/rbpaths.h |
| 11:18:13 | braewoods | Oh. |
| 11:18:15 | braewoods | Ok. |
| 11:18:22 | braewoods | so hard-coded |
| 11:18:34 | braewoods | hmmm |
| 11:18:36 | speachy | there is a special case in place to deal with $HOME on targets that actually set it (eg simulator) |
| 11:20:43 | speachy | we have places that hardcode using HOME_DIR in paths, and that gets passed into the hosted FS code that in turn tries to prepend HOME_DIR. |
| 11:21:13 | speachy | basically only places that should be using that HOME_DIR #define are the core filesystem code. everything else should just use "/" |
| 11:21:52 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 11:24:50 | efqw | I wasn't able to find out who made the BT module in the rocker unfortunately |
| 11:25:04 | efqw | That form factor is rather unique and hard to find |
| 11:25:47 | efqw | If you search for "Bluetooth module" most of the results that pops up are either those old chunky CSR stuff or ampak modules |
| 11:25:52 | speachy | efqw: CSR8821? |
| 11:26:35 | speachy | whoops, CSR8811 |
| 11:27:29 | efqw | yeah, 8811 makes sense |
| 11:27:30 | speachy | Or I guess that's not hte acual "module" |
| 11:27:43 | efqw | I was looking for 8821 but didn't find anything |
| 11:28:32 | speachy | not clear if it's that's just the IC and additional external components are under that can |
| 11:36:37 | efqw | ok, it's probably just the chip, a crystal, and some small passives |
| 11:42:08 | efqw | https://www.techrepublic.com/pictures/cracking-open-the-samsung-galaxy-tab-77/63/ |
| 11:42:35 | efqw | something like this but more condensed basically |
| 11:52:23 | | Quit koniu (Ping timeout: 240 seconds) |
| 11:52:58 | efqw | speachy: Have you managed to get a modified ubi with rb on it? If you ever do please send a copy to me so I can try it out. |
| 11:53:41 | | Join koniu [0] (~koniu@gateway/tor-sasl/koniu) |
| 11:54:32 | speachy | I haven't gone that far yet. tonight probably. I'm still kicking at other general hosted bugs. |
| 11:57:01 | efqw | sure, lmk if you do, I'll do more research on the ota part |
| 12:00 |
| 12:03:53 | speachy | ok, think I've finally got the rbpath mess cleaned up. |
| 12:04:05 | speachy | should fix a pile of misc bugs on our mostly-little-used hosted targets |
| 12:04:19 | speachy | and hopefully not introduce new ones on some of the corner cases |
| 12:05:15 | speachy | I need to land the eros changes first |
| 12:05:52 | speachy | but that will have to wait until I get back; I'm pretty sure I'm going to introduce some yellow with the next two. |
| 12:06:08 | fs-bluebot | Build Server message: New build round started. Revision 5efaa9e, 287 builds, 10 clients. |
| 12:06:10 | speachy | and then I'll try to generate a m3k patched image |
| 12:11:11 | efqw | sounds good |
| 12:11:25 | efqw | regarding the public key found in fiio |
| 12:12:00 | efqw | *found in fiio's recovery initramfs, I'm having trouble getting it into a human-readable format |
| 12:12:15 | efqw | It's a text file that starts with "v2" |
| 12:14:36 | | Join icypee [0] (493c5e9d@c-73-60-94-157.hsd1.ma.comcast.net) |
| 12:14:42 | icypee | hello |
| 12:14:51 | icypee | i moved all my data to a new sd card |
| 12:14:58 | icypee | and now rockbox won't read it |
| 12:15:04 | icypee | how do i fix this? |
| 12:18:59 | | Quit pamaury (Ping timeout: 240 seconds) |
| 12:20:07 | fs-bluebot | Build Server message: Build round completed after 839 seconds. |
| 12:20:09 | fs-bluebot | Build Server message: Revision 5efaa9e result: All green |
| 12:23:10 | | Quit michaelni (Ping timeout: 246 seconds) |
| 12:32:46 | | Join johnb3 [0] (~johnb2@p5b3af6d7.dip0.t-ipconnect.de) |
| 12:36:40 | *** | Saving seen data "./dancer.seen" |
| 12:37:19 | efqw | oh, I found the format |
| 12:38:03 | efqw | It was explained in $BSP_v6.0/development/tools/ota/verifier.c |
| 12:38:31 | efqw | *$BSP_v6.0/development/tools/ota/src/verifier.c |
| 12:38:38 | | Quit icypee (Remote host closed the connection) |
| 12:38:53 | | Join sakax [0] (~r0b0t@unaffiliated/r0b0t) |
| 12:39:47 | | Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) |
| 12:41:16 | efqw | The verifier code and RSA code were taken from an old branch of this: https://android.googlesource.com/platform/bootable/recovery |
| 12:41:33 | bluebrother | speachy: how does that github mirror of Rockbox' git work? Is it being pushed to regularly from the server? |
| 12:42:42 | bluebrother | played around with github actions, managed to get Rockbox Utility build with it (Linux for now): https://github.com/bluebrother/rockbox/actions |
| 12:43:21 | bluebrother | so adding the github workflow file to the main repo should eventually end up in the mirror, making github do the build afaiu. |
| 12:43:34 | bluebrother | could be interesting to get regular builds of Rockbox Utility. |
| 12:45:01 | bluebrother | oh, there's even an irc notifier action. |
| 12:45:04 | lebellium | pamaury done |
| 13:00 |
| 13:10:43 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 13:11:57 | pamaury | speachy: I don't remeber much what HOME_DIR is about, I never wrapped my head around hosted port, too much magic |
| 13:24:35 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 13:32:04 | | Quit beencubed (Quit: Leaving) |
| 13:36:34 | | Join beencubed [0] (~beencubed@209.131.238.248) |
| 14:00 |
| 14:00:27 | braewoods | took a fair effort but I finally figured out how rockbox does bootloader validation in the iriver_flash plugin |
| 14:00:51 | braewoods | not to mention the crc32 algorithm is a bit weird. |
| 14:02:45 | braewoods | i thought it would be identical to cksum since they use the same polynomial but nope |
| 14:03:24 | braewoods | so i ended up writing a short C program to duplicate the crc32 checksumming on my desktop so i can find the actual checksum for adding the test bootloader to the existing table |
| 14:03:56 | braewoods | what a pain but it works i guess |
| 14:04:08 | braewoods | it successfully works with the known good bootloaders |
| 14:08:38 | | Quit Rower (Ping timeout: 256 seconds) |
| 14:18:29 | _bilgus_ | do they use the same polynomial maybe its mi4 I was thinking of that uses a different one |
| 14:19:08 | braewoods | _bilgus_: the source for firmware/common/crc32.c says it uses... |
| 14:19:29 | braewoods | 0x04C11DB7 |
| 14:19:51 | braewoods | above the lookup table |
| 14:20:23 | braewoods | https://en.wikipedia.org/wiki/Cksum |
| 14:20:36 | braewoods | same here |
| 14:20:41 | braewoods | so no idea why they're different |
| 14:20:52 | braewoods | i'm not an expert on crc32 implementations |
| 14:21:07 | braewoods | main reason i've seen differences though were different polynomials |
| 14:22:04 | braewoods | i should check the coreutils implementation just to verify that |
| 14:26:23 | braewoods | cstrange |
| 14:26:25 | braewoods | strange |
| 14:26:27 | braewoods | anyway |
| 14:26:44 | braewoods | even if it's wrong... can't really change it now for compatibility reasons |
| 14:27:14 | braewoods | just noticed i couldn't reproduce the table checksums with cksum. |
| 14:27:30 | braewoods | which i assumed would be the same since they supposedly use the same polynomial |
| 14:29:18 | _bilgus_ | generally you seed the crc function with an initial seed 0xFFFFFFFF this also functions as a continuation function |
| 14:30:03 | _bilgus_ | so if you need the proper starting seed that could explain the issue |
| 14:31:13 | braewoods | their starting CRC value is 0 |
| 14:31:18 | braewoods | in coreutils |
| 14:31:27 | braewoods | i'll see what happens if i do that with RB's function |
| 14:32:23 | braewoods | nope |
| 14:32:28 | braewoods | oh well |
| 14:32:40 | braewoods | doesn't matter to me that much to find out since the RB implementation is what matters here |
| 14:33:49 | | Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) |
| 14:34:05 | braewoods | speachy, _bilgus_: how does this look for a consolidate set of build and setup instructions for bootloader building? |
| 14:34:07 | braewoods | https://dpaste.com/3KUZHKJJP |
| 14:34:25 | braewoods | it appears to work |
| 14:34:27 | braewoods | but |
| 14:34:38 | braewoods | i've never built this before so not sure if i've overlooked anything |
| 14:36:12 | _bilgus_ | the dependencies looks a bit short but if itworks it works |
| 14:36:23 | braewoods | _bilgus_: that's from the wiki page... the beginners guide |
| 14:36:33 | braewoods | it compiles just fine afaik |
| 14:36:43 | braewoods | https://www.rockbox.org/wiki/LinuxSimpleGuideToCompiling |
| 14:36:45 | *** | Saving seen data "./dancer.seen" |
| 14:36:47 | braewoods | is what i based it on |
| 14:37:54 | _bilgus_ | yeah I think strife updated or made that a while back.. |
| 14:40:21 | braewoods | i based it on Debian 10 host |
| 14:40:57 | braewoods | anyway i'll see where i can go with this |
| 14:41:11 | braewoods | just wanted to be pretty sure i'd followed the instructions completely |
| 14:41:41 | braewoods | i plan to build new bootloaders for both h1x0 targets |
| 14:41:49 | braewoods | but i can only test the h120 / h140 |
| 14:42:05 | braewoods | the other one... i guess i'll assume it works if the other does since they're related |
| 14:42:32 | braewoods | i can't even find the h115 etc for sale used |
| 14:42:38 | braewoods | the h120 and h140 are more common |
| 14:43:13 | braewoods | I ended up with one of each for about $120 combined |
| 14:43:18 | braewoods | err |
| 14:43:20 | braewoods | 2 h120s |
| 14:46:48 | | Quit petur (Remote host closed the connection) |
| 15:00 |
| 15:08:57 | braewoods | interesting line in that source though |
| 15:09:12 | braewoods | const unsigned char *buf = (const unsigned char*)src; |
| 15:09:19 | braewoods | the originally is a const void* |
| 15:09:36 | braewoods | is a cast really necessary considering void is implicitly converted when reassigned? |
| 15:10:23 | braewoods | no warnings from my GCC |
| 15:11:33 | braewoods | at least I understand why (void) casts are sometimes done |
| 15:11:54 | braewoods | tell the compiler something is either unused or only used for side-effects |
| 15:12:35 | braewoods | i've done it to suppress warnings for unused parameters in callback functions before since it's a portable way to do so. |
| 16:00 |
| 16:26:00 | | Quit pamaury (Ping timeout: 256 seconds) |
| 16:36:48 | *** | Saving seen data "./dancer.seen" |
| 16:39:23 | fs-bluebot | Build Server message: New build round started. Revision 2a471e2, 290 builds, 9 clients. |
| 16:43:12 | | Quit _bilgus_ (Remote host closed the connection) |
| 16:45:07 | | Join _bilgus_ [0] (~bilgus@2605:a000:1301:89f6:7df7:7326:e72f:ac24) |
| 16:53:37 | | Quit sakax (Remote host closed the connection) |
| 17:00 |
| 17:04:17 | fs-bluebot | Build Server message: Build round completed after 1494 seconds. |
| 17:04:18 | fs-bluebot | Build Server message: Revision 2a471e2 result: 112 errors 0 warnings |
| 17:21:15 | fs-bluebot | Build Server message: New build round started. Revision a5add39, 290 builds, 9 clients. |
| 17:30:37 | speachy | it occurs to me that instead of all of this pivot_root nonsense, why not just use chroot instead... |
| 17:42:27 | fs-bluebot | Build Server message: Build round completed after 1271 seconds. |
| 17:42:28 | fs-bluebot | Build Server message: Revision a5add39 result: All green |
| 17:45:55 | | Quit lebellium (Quit: Leaving) |
| 17:48:27 | | Quit _bilgus_ (Remote host closed the connection) |
| 17:49:35 | | Join _bilgus_ [0] (~bilgus@2605:a000:1301:89f6:7df7:7326:e72f:ac24) |
| 18:00 |
| 18:15:15 | fs-bluebot | Build Server message: New build round started. Revision db6f21e, 290 builds, 9 clients. |
| 18:30:22 | fs-bluebot | Build Server message: Build round completed after 907 seconds. |
| 18:30:23 | fs-bluebot | Build Server message: Revision db6f21e result: 7 errors 1 warnings |
| 18:36:49 | fs-bluebot | Build Server message: New build round started. Revision 135b3f6, 290 builds, 9 clients. |
| 18:36:52 | *** | Saving seen data "./dancer.seen" |
| 18:38:46 | braewoods | speachy: afaik pivot_root is mainly for initramfs to change to the true root |
| 18:39:35 | braewoods | it allows for a handover for the actual running system from the early boot one |
| 18:39:50 | braewoods | but i doubt initramfs is used much in embedded |
| 18:39:53 | speachy | what's called PIVOT_ROOT in our code is actually a mostly-faked chroot |
| 18:39:59 | braewoods | Oh. |
| 18:40:12 | braewoods | i thought you meant the Linux pivot_root feature. |
| 18:40:20 | braewoods | literally the same name |
| 18:40:59 | braewoods | you can do a lot of weird stuff with chroots |
| 18:41:10 | braewoods | bind mounts... mount namespaces... |
| 18:41:12 | braewoods | etc |
| 18:43:24 | speachy | but it's now all cleaned up to the point where proper chroot is _finally_ possible. bleh. |
| 18:43:52 | speachy | all internal paths are relative to /, and only in a single place do we prepend the actual system root |
| 18:48:01 | braewoods | speachy: have you looked at openat, etc? |
| 18:48:41 | braewoods | those can be pretty useful for coding for opening paths relative to a directory without having to maintain the directory path. |
| 18:52:15 | fs-bluebot | Build Server message: Build round completed after 926 seconds. |
| 18:52:16 | fs-bluebot | Build Server message: Revision 135b3f6 result: All green |
| 19:00 |
| 19:08:44 | | Join w4tchguard [0] (~w4tchguar@2001:ac8:84:33::a10d) |
| 19:30:07 | | Join mendelmunkis [0] (~mendelmun@ool-435680b7.dyn.optonline.net) |
| 19:36:09 | mendelmunkis | what do I need to do to update my build machine? |
| 19:36:15 | | Nick mendelmunkis is now known as mendel_munkis (~mendelmun@ool-435680b7.dyn.optonline.net) |
| 19:41:58 | speachy | take the rockboxdev.sh in the gerrit commit and regenrate everything |
| 19:42:20 | speachy | then update the rbclient.sh script used to invoke things and tell it you have the gcc494 stuff |
| 19:51:39 | | Join fs-bluebot_ [0] (~fs-bluebo@55d44e1a.access.ecotel.net) |
| 19:51:48 | | Quit bluebrother (Disconnected by services) |
| 19:51:53 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
| 19:53:48 | | Quit fs-bluebot (Ping timeout: 256 seconds) |
| 20:00 |
| 20:04:23 | speachy | I'm regenerating the toolchains myself now. |
| 20:07:18 | speachy | BTW, I don't recommend putting them in /usr/local (ie the default), as it makes it a lot harder to blow them away properly |
| 20:07:37 | speachy | I have mine in their own location, and add them to $PATH |
| 20:36:56 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:39:27 | _bilgus_ | speachy got the rocker much smaller than I expected and the OF bluetooth menu is terrible |
| 21:39:41 | _bilgus_ | what was it you wanted me to test? |
| 21:39:48 | speachy | yeah. its functionality isn't all that much better. :) |
| 21:41:12 | speachy | _bilgus_: http://www.shaftnet.org/~pizza/rb-rocker.upt |
| 21:41:19 | speachy | pair that with the latest dev build. |
| 21:43:02 | speachy | (rename that file to upgrade.upt, and in the OF you can tell it to initate an upgrade) |
| 21:43:34 | speachy | (one of the enhancements I've made to the loader is the ability to initate these upgrades without using the OF) |
| 21:44:18 | speachy | basically I need to make sure the loader still works properly on the rocker, and the tools menu fits/is usable |
| 21:50:48 | speachy | other enhancements −− plugging the USB cable in the loader no longer force-enters the OF's USB mode (it uses the last selection, unless adb is running in which case it does nothing) |
| 21:55:25 | _bilgus_ | compiling.. |
| 21:57:15 | speachy | the Rocker is in much better overall shape than it was a couple of weeks ago. Other than bluetooth and some possibly questionable keymaps, it's a solid player now. |
| 22:00 |
| 22:00:24 | _bilgus_ | for multiple devices at that excellent rockboxery there speachy |
| 22:01:27 | speachy | we're fortunate this hibylinux platform is so widespread and easy to inject ourselves into |
| 22:12:38 | _bilgus_ | upgrade.upt and I assume it goes in the root? |
| 22:12:46 | _bilgus_ | tells me NO UPGRADE! |
| 22:17:07 | _bilgus_ | nm update.upt |
| 22:17:38 | _bilgus_ | v_v succeed |
| 22:36:58 | *** | No seen item changed, no save performed. |
| 22:46:38 | | Join gu4rd__ [0] (~w4tchguar@2001:ac8:84:31::a08d) |
| 22:49:55 | | Quit w4tchguard (Ping timeout: 240 seconds) |
| 22:50:51 | | Join w4tchguard [0] (~w4tchguar@2001:ac8:84:37::a14d) |
| 22:51:25 | | Quit gu4rd__ (Ping timeout: 240 seconds) |
| 23:00 |
| 23:45:13 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 23:57:09 | | Quit [7] (Disconnected by services) |
| 23:57:15 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
icon identifies that the person is a core developer (has commit access).