| 00:07:05 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 00:07:16 | | Join _BILGUS__ [0] (41ba23be@65.186.35.190) |
| 00:08:13 | _BILGUS__ | nope still not working CLKGR0 indicates the clock is enabled but it will just never get a reading |
| 00:08:40 | _BILGUS__ | I even tried re-init for the ADC |
| 00:12:17 | | Quit massiveH (Quit: Leaving) |
| 00:40:58 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:17:37 | | Quit Oksana (Ping timeout: 264 seconds) |
| 01:30:40 | | Join Oksana [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 02:00 |
| 02:08:06 | | Quit _BILGUS__ (Remote host closed the connection) |
| 02:14:42 | | Join johnb4 [0] (~johnb2@p5b3af408.dip0.t-ipconnect.de) |
| 02:30:53 | | Quit johnb4 (Ping timeout: 256 seconds) |
| 02:40:59 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:03:14 | | Quit pamaury (Ping timeout: 260 seconds) |
| 03:06:47 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 03:44:25 | | Quit galaxy_knuckles (Ping timeout: 240 seconds) |
| 03:48:33 | | Join galaxy_knuckles [0] (~gknux@db4g.com) |
| 03:48:34 | | Quit galaxy_knuckles (Changing host) |
| 03:48:34 | | Join galaxy_knuckles [0] (~gknux@unaffiliated/galaxy-knuckles/x-1756549) |
| 04:00 |
| 04:23:45 | | Join ufdm_ [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 04:23:45 | | Quit ufdm (Read error: Connection reset by peer) |
| 04:41:02 | *** | Saving seen data "./dancer.seen" |
| 04:45:07 | | Join lemon_jesus0 [0] (~lemon_jes@c-73-9-49-209.hsd1.in.comcast.net) |
| 04:46:44 | | Quit lemon_jesus (Ping timeout: 240 seconds) |
| 04:46:45 | | Nick lemon_jesus0 is now known as lemon_jesus (~lemon_jes@c-73-9-49-209.hsd1.in.comcast.net) |
| 05:00 |
| 05:00:16 | | Quit pamaury (Ping timeout: 246 seconds) |
| 05:29:56 | | Quit koniu (Remote host closed the connection) |
| 05:30:24 | | Join koniu [0] (~koniu@gateway/tor-sasl/koniu) |
| 06:00 |
| 06:22:22 | | Join johnb4 [0] (~johnb2@p5b3af408.dip0.t-ipconnect.de) |
| 06:26:43 | | Quit johnb4 (Ping timeout: 246 seconds) |
| 06:36:44 | | Join lebellium [0] (~lebellium@2a01cb080a0f0b00a15b8d6e68551228.ipv6.abo.wanadoo.fr) |
| 06:41:03 | *** | Saving seen data "./dancer.seen" |
| 06:51:10 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 07:00 |
| 07:09:00 | | Join johnb4 [0] (~johnb2@p5b3af408.dip0.t-ipconnect.de) |
| 08:00 |
| 08:00:09 | | Quit johnb4 (Ping timeout: 260 seconds) |
| 08:21:53 | | Quit danielp3344 (Quit: killed) |
| 08:22:08 | | Quit blbro[m] (Quit: killed) |
| 08:22:12 | | Quit SiliconExarch (Quit: killed) |
| 08:30:13 | | Join danielp3344 [0] (danielp334@gateway/shell/matrix.org/x-pvvjpidbwbfxyrfw) |
| 08:41:07 | *** | Saving seen data "./dancer.seen" |
| 08:56:11 | | Join kadoban [0] (kadobanmat@gateway/shell/matrix.org/x-imgelumufkfuspvc) |
| 08:56:17 | | Join SiliconExarch [0] (sewiredci@gateway/shell/matrix.org/x-ctsyjwwbcnkorlew) |
| 08:56:18 | | Join blbro[m] [0] (blbrostrat@gateway/shell/matrix.org/x-ewlqthtxxeoqrsnq) |
| 09:00 |
| 09:06:00 | | Join __Bilgus [0] (41ba23be@65.186.35.190) |
| 09:08:12 | __Bilgus | Speachy, that rolo issue with the gpio as far as I can tell its not the adc causing the problem it acts like the device clock is stopped |
| 09:09:28 | __Bilgus | Every register I checked is the same when it works as when it doesnt |
| 09:11:36 | __Bilgus | so the ADC gets the enable bit set but it never completes a sample |
| 09:17:44 | speachy | the key_int gpio you mean? |
| 09:19:52 | speachy | because the ADC clock is hanging directly off the XTAL |
| 09:21:02 | __Bilgus | no the interrupts happen just fine it acts as if the XTAL source stops |
| 09:21:39 | __Bilgus | the en bit gets set the setup is the same but it never fires off a result |
| 09:21:56 | speachy | __Bilgus: L289, that should be |= AUXEN |
| 09:22:11 | __Bilgus | what i eneded up doing was mapping that interrupt to a button press so I coiuld get through the debug menus lol |
| 09:22:38 | speachy | we end up turning off the battery sample if one's running when we do a keypress. |
| 09:24:26 | __Bilgus | I'm not sure how that'd make the adc stall but i'll try it |
| 09:25:41 | __Bilgus | maybe one of the reserved bits gets wiped |
| 09:28:13 | __Bilgus | nope no dice |
| 09:28:37 | __Bilgus | I' |
| 09:29:43 | __Bilgus | I'd think if it was a configuration issue with the ADC it'd screw up other times as well but no I guess i'll look at gpios next and see if fsomething gets flipped maybe an undefined reference |
| 09:30:03 | __Bilgus | voltage ref |
| 09:31:09 | | Join lebellium_ [0] (~lebellium@2a01cb080a0f0b00cc2459fa1a997fa1.ipv6.abo.wanadoo.fr) |
| 09:34:37 | | Quit lebellium (Ping timeout: 260 seconds) |
| 09:35:19 | speachy | oh, it's not just rolo; power on voltage isn't registering properly either. |
| 09:37:34 | __Bilgus | I feel like its just got to a configuration error somewhere but damn if I can find it |
| 09:37:55 | __Bilgus | got to be* |
| 09:41:03 | speachy | voltage history since powerup is 9.8v, 9.8, 7.5, 5.2, 4.3, 4.0, 3.8 |
| 09:45:18 | __Bilgus | ah thats a misnomer |
| 09:45:49 | __Bilgus | its just picking up that defa0ult value of 0xFFF |
| 09:46:32 | __Bilgus | its just that it got thrown into the averaging |
| 09:46:48 | __Bilgus | but its trending down so the adc is doing samples |
| 09:49:15 | | Quit emacsomancer (Quit: WeeChat 2.8) |
| 09:50:18 | __Bilgus | ANDD of course now it works fine when I try to debug |
| 09:54:07 | | Join emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net) |
| 09:55:10 | speachy | huh, the codec api has the cache manipulations in it, but no users on single-core targets. |
| 09:55:49 | speachy | plugins has it too, but it looks like the plugin startup code relies on it, if nothing else. |
| 09:56:04 | | Join livvy [0] (~livvy@gateway/tor-sasl/livvy) |
| 10:00 |
| 10:01:12 | __Bilgus | cache manipulations? |
| 10:02:16 | speachy | should probably dial that ADC default down to something more realistic. 0x6b5 maps to 4200mv, which is the largest we could theoretically ever see. |
| 10:08:52 | speachy | ooo! just lost keyboard after a rolo, and when I hit the power button, it paniced with a TLB exception |
| 10:21:27 | __Bilgus | I det it to 4.222 6DD |
| 10:21:31 | __Bilgus | I set* |
| 10:23:35 | __Bilgus | so looking at gpios there is exactly one GPIO that has changed between the rolo restart and a regular one GPIOB Bit 28 |
| 10:28:47 | speachy | nothing seems to explicitly access that bit |
| 10:30:13 | __Bilgus | it won't let me flip it either so probably an input |
| 10:33:16 | speachy | when we rolo.. I don't think we're loading up the new HW vector table. that might be our ROLO issues in a nutshell; the previous image's vectors point at something bogus. |
| 10:41:10 | *** | Saving seen data "./dancer.seen" |
| 10:42:31 | speachy | we might need to do something timilar to the imx31 or rk27xx's custom rolo code. |
| 10:44:37 | __Bilgus | ah ok so that would make sense of why its seemingly random it just depends on what has changed |
| 10:45:02 | __Bilgus | that gpio as far as I can tell is just a red herring |
| 10:45:49 | speachy | ...vectors are in IRAM, which the crt0 code copies. |
| 10:55:56 | | Join MrZeus [0] (~MrZeus@05467834.skybroadband.com) |
| 11:00 |
| 11:03:11 | | Join johnb2 [0] (~johnb2@p5b3af408.dip0.t-ipconnect.de) |
| 11:07:01 | __Bilgus | ok i'll try to figure that out this evening |
| 11:09:33 | speachy | interrupts are disabled too. |
| 11:09:39 | speachy | so that theory's probably out |
| 11:10:27 | speachy | we don't globally enable interrupts until the end of system_main(), which in turn explicitly disables all interrupt sources first. |
| 11:11:13 | | Part johnb2 |
| 11:11:24 | | Join johnb2 [0] (~johnb2@p5b3af408.dip0.t-ipconnect.de) |
| 11:33:48 | | Quit __Bilgus (Remote host closed the connection) |
| 12:00 |
| 12:01:08 | | Join __Bilgus [0] (41ba23be@65.186.35.190) |
| 12:01:58 | __Bilgus | it doesn't act like an issue with interrupts its just like literally there is no clock getting to it yet CLKGR0 is enabled |
| 12:04:12 | __Bilgus | your theory holds at least some water though since If I ROLO the Fw directly (with the one already running) it never fails to have the adc |
| 12:07:23 | | Quit johnb2 (Quit: Nettalk6 - www.ntalk.de) |
| 12:19:06 | | Quit lebellium_ (Quit: Leaving) |
| 12:41:12 | *** | Saving seen data "./dancer.seen" |
| 12:47:00 | | Join johnb4 [0] (~johnb2@p5b3af408.dip0.t-ipconnect.de) |
| 12:51:22 | | Quit johnb4 (Ping timeout: 246 seconds) |
| 13:00 |
| 13:08:57 | __Bilgus | Speachy I *think* I have it figured out |
| 13:10:20 | __Bilgus | g# 2732 |
| 13:10:32 | __Bilgus | no blue bot huh |
| 13:10:36 | __Bilgus | https://gerrit.rockbox.org/2732 |
| 13:14:56 | fs-bluebot | Build Server message: New build round started. Revision 5f5e44f, 280 builds, 8 clients. |
| 13:20:00 | __Bilgus | nope spoke too soon Grr |
| 13:24:35 | | Quit ufdm_ (Quit: Leaving) |
| 13:24:54 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 13:28:36 | | Join johnb4 [0] (~johnb2@p5b3af408.dip0.t-ipconnect.de) |
| 13:32:59 | | Quit johnb4 (Ping timeout: 240 seconds) |
| 13:38:04 | fs-bluebot | Build Server message: Build round completed after 1389 seconds. |
| 13:38:08 | fs-bluebot | Build Server message: Revision 5f5e44f result: All green |
| 14:00 |
| 14:41:14 | *** | Saving seen data "./dancer.seen" |
| 14:47:38 | | Join sakax [0] (~r0b0t@unaffiliated/r0b0t) |
| 14:50:03 | | Quit livvy (Ping timeout: 240 seconds) |
| 14:50:06 | | Join johnb4 [0] (~johnb2@p5b3af408.dip0.t-ipconnect.de) |
| 14:54:58 | | Join livvy [0] (~livvy@gateway/tor-sasl/livvy) |
| 15:00 |
| 15:14:55 | | Join ultraelephant [0] (6dfc6ded@109-252-109-237.nat.spd-mgts.ru) |
| 15:15:43 | ultraelephant | Hello. I had founded all Linux scrobblers links dead and outdated, so I created python script for myself (ultraelephant/pyapplier">https://github.com/ultraelephant/pyapplier). I thought it may be useful for other users and wanted to add it to wiki page (https://www.rockbox.org/wiki/LastFMLog), but registration is disabled now. |
| 15:26:18 | | Quit __Bilgus (Remote host closed the connection) |
| 15:33:13 | | Quit johnb4 (Ping timeout: 264 seconds) |
| 15:45:40 | speachy | ultraelephant: PM me your desired username and email address and I'll create an account for you |
| 15:58:05 | fs-bluebot | Build Server message: New build round started. Revision 90a4f28, 280 builds, 7 clients. |
| 16:00 |
| 16:02:56 | speachy | __Bilgus: I just merged part of my audio path tweak patchset. Increasing the buffer size helps a _lot_. |
| 16:06:05 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 16:08:42 | | Join captainkewlllll [0] (60ffd643@pool-96-255-214-67.washdc.fios.verizon.net) |
| 16:20:47 | | Join Huntereb [0] (~Huntereb@174.226.2.53) |
| 16:40:17 | fs-bluebot | Build Server message: Build round completed after 2533 seconds. |
| 16:40:19 | fs-bluebot | Build Server message: Revision 90a4f28 result: All green |
| 16:41:16 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:10:05 | | Quit beencubed (Quit: Leaving) |
| 17:15:01 | | Join beencubed [0] (~beencubed@209.131.238.248) |
| 17:19:34 | | Quit pamaury (Ping timeout: 256 seconds) |
| 17:30:38 | | Quit captainkewlllll (Remote host closed the connection) |
| 17:39:42 | | Quit ultraelephant (Remote host closed the connection) |
| 17:57:43 | | Quit mendel_munkis (Remote host closed the connection) |
| 17:57:43 | | Join mendelmunkis [0] (~mendelmun@ool-ae2cb138.dyn.optonline.net) |
| 18:00 |
| 18:41:18 | *** | Saving seen data "./dancer.seen" |
| 19:00 |
| 19:01:54 | | Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) |
| 19:21:06 | | Join fs-bluebot_ [0] (~fs-bluebo@55d427b8.access.ecotel.net) |
| 19:21:13 | | Quit speachy (Ping timeout: 264 seconds) |
| 19:21:43 | | Quit bluebrother (Disconnected by services) |
| 19:21:48 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
| 19:23:04 | | Quit fs-bluebot (Ping timeout: 240 seconds) |
| 19:27:32 | | Join speachy [0] (~speachy@209.2.65.77) |
| 20:00 |
| 20:19:49 | | Join __Bilgus [0] (41ba23be@65.186.35.190) |
| 20:27:00 | __Bilgus | Speachy I assume 2709 will patch on top of this still? |
| 20:27:36 | __Bilgus | sorry 2729 |
| 20:28:57 | speachy | 2729 only adds audiobuf watermarking now. but I intend to add more stuff into it this weekend (eg rewrite audio DMA to use double-buffering) |
| 20:31:17 | __Bilgus | I think I might try doing a crc on the firmware that gets copied to the ram and if that doesn't pan out I guess I'll start figuring out how to get the vector table copied |
| 20:34:06 | speachy | the vector table appears to be copied, as it's part of the IRAM loadout. that said.. we might need another drop_icache after the IRAM copy |
| 20:35:00 | __Bilgus | I'm not familar with that low level but I get the general idea |
| 20:36:24 | __Bilgus | I did see where the bootloader closes the ADC though but atm i'm not sure exactly what code is getting executed there |
| 20:39:52 | speachy | it's possible our "70ms" delay isn't actually 70ms because the delay loop isn't properly calibrated. |
| 20:41:20 | *** | Saving seen data "./dancer.seen" |
| 20:46:10 | | Quit MrZeus (Ping timeout: 256 seconds) |
| 20:50:34 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 20:55:43 | speachy | well, one thing worth mentioning is that we won't _start_ sampling the ADC for 30s after startup. |
| 20:56:20 | speachy | battery ADC, I mean |
| 20:56:58 | speachy | should probably initialize last_tick = -BATT_WAIT_TIME |
| 21:00 |
| 21:03:30 | __Bilgus | nah i'll just add bat tick at the end funny I didn't even catch that till you mentioned it |
| 21:08:14 | __Bilgus | speachy so most of these interrupts (all?) have a corresponding pin that you could poll correct? |
| 21:08:57 | speachy | The GPIOs, yes. |
| 21:09:27 | __Bilgus | all the external devices trigger through such? |
| 21:09:36 | speachy | not quite |
| 21:10:36 | braewoods | speachy: is it my imagination or did the mp3 player SOCs die with portalplayer? |
| 21:10:45 | __Bilgus | I was thinking about the context switch to the interrupt is the issue so the longer you coulkd keep it from switching back the better no? |
| 21:10:48 | braewoods | in terms of new ones |
| 21:11:14 | braewoods | it seems new ones are either based on other types of SOCs or a hodge-podge of other components. |
| 21:11:20 | speachy | there are only four CPU-level IRQs, of which exactly one is actually used by the "interrupt coprocessor" −− which the jz4760 can feed with something like 45 sources. Each of those sources in turn can have multiple sources. |
| 21:11:55 | __Bilgus | ah so like lv 0 -> lv1 -> lv2 |
| 21:12:30 | speachy | one of the reasons IRQ handling is so expensive is that we have to walk that hierarchy to figure out what happened. |
| 21:12:50 | speachy | granted, that hierarchy (and thus priority) is completely software-defined. |
| 21:14:43 | speachy | braewoods, I'd argue that these ingenic jz47xx parts continue the DAP-targeted SoC tradition, and the modern X1000 and new X2000 series are still focused on high-end DAPs |
| 21:14:44 | __Bilgus | I was thinking more along the lines of always do a audio transfer on the start of some interrupts |
| 21:15:10 | speachy | __Bilgus, the rockbox HW PCM API won't allow for that |
| 21:16:06 | __Bilgus | ah I suppose thats where you double buffering comes in |
| 21:17:16 | speachy | the PCM code is actually double-buffered, quite sanely, but it's designed around the assumption that the HW has deep enough FIFOs to handle the interrupt->buffer swap handoff |
| 21:18:53 | speachy | I think I've finished the core changes to optionally go triple-buffered |
| 21:19:35 | speachy | but I have to rewrite the jz4760's pcm DMA code to be descriptor-based first. |
| 21:20:45 | braewoods | speachy: how much memory does the playback buffer use? |
| 21:20:49 | speachy | (mips32r2 adds a true priority-aware HW interrupt controller as part of the CPU core. which we can't use, naturally) |
| 21:21:00 | braewoods | i know audio can be fairly large so i'd expect 4k or more. |
| 21:21:27 | braewoods | depends how much audio you're buffering and the sample rate i believe |
| 21:21:38 | __Bilgus | speachy yeah thats the first thing I found then realized the instructions werent there |
| 21:21:49 | speachy | the PCM core defaults to 256 frames, aka stereo samples. |
| 21:22:14 | braewoods | hm. |
| 21:22:20 | braewoods | so like 1k at most? |
| 21:22:21 | speachy | I upped it to 2K samples, as 1K wasn't enough. |
| 21:22:42 | braewoods | assuming 16 bit samples |
| 21:22:43 | speachy | 256 frames per buffer, and there are two buffers. |
| 21:23:01 | braewoods | and 1 byte per channel |
| 21:23:10 | braewoods | err |
| 21:23:12 | braewoods | 2 bytes |
| 21:23:14 | __Bilgus | its just funny how such a fast processor is the worst running of a great many of our ports |
| 21:23:14 | speachy | so now there are 2x 2048frame buffers, for a total of 16KB. (on the jz47xx targets) |
| 21:23:35 | braewoods | isn't that partly due to how young it is? |
| 21:24:05 | __Bilgus | that OF on the XDUOO exemplifies how slow it could be but at least it playsback right lol |
| 21:24:26 | __Bilgus | and it has 8MP ram? |
| 21:24:28 | braewoods | what architectures does rockbox use? mostly ARM derivatives? |
| 21:24:30 | __Bilgus | MB |
| 21:24:39 | speachy | well, the OF was running native linux. which has some very robust and mature irq handling infrastructure. |
| 21:24:54 | __Bilgus | brae most code is in arm I think |
| 21:24:55 | braewoods | ah, embedded linux. a bit surprising. |
| 21:24:56 | speachy | it has 32MB RAM, I believe |
| 21:25:10 | braewoods | that's not a lot of RAM for Linux though it's workable. |
| 21:25:19 | braewoods | openwrt runs on it and all |
| 21:25:26 | __Bilgus | thats a lot of ram for rockbox though |
| 21:25:32 | speachy | more than enough, given the limited functionality used. remember, no networking, nearly no UI |
| 21:25:51 | braewoods | ah. not even a wayland or X environment? |
| 21:25:55 | speachy | the frame buffer on this thing is what, 1KB? :) |
| 21:25:59 | braewoods | kernel framebuffer? |
| 21:26:31 | braewoods | main thing i ever used the linux framebuffer for was terminals |
| 21:26:44 | braewoods | kinda useless otherwise on most platforms |
| 21:27:02 | speachy | __Bilgus: Funny thing is that rockbox sounds better than the OF. (DSD notwithstanding) |
| 21:27:29 | speachy | __Bilgus: they don't reclock the PLL, and have it tuned for 48KHz-based audio rather than 44.1KHz |
| 21:27:37 | braewoods | does rockbox utilize inline ASM at all? or is it all C? |
| 21:27:51 | __Bilgus | we have too much asm IMO |
| 21:27:53 | speachy | C unless asm is necessary |
| 21:28:05 | braewoods | i hate writing ASM though I have from time to time. |
| 21:28:10 | braewoods | intrinsics are usually better |
| 21:28:34 | __Bilgus | or somebody wanted to really squeeze performance but good luck decoding it |
| 21:28:51 | braewoods | most of the time there's no benefit to writing raw ASM since compilers have advanced so much |
| 21:29:01 | braewoods | except maybe sheer code size |
| 21:29:04 | __Bilgus | well braewoods our bar to entry is low pays shit but it is fun |
| 21:29:09 | braewoods | but i don't think rockbox is that resource constrained |
| 21:29:41 | speachy | braewoods: depends on the target. some of them truly are −− eg older portalplayers, where without asm optimizations in the codecs we'd never achieve realtime performance. |
| 21:29:49 | braewoods | ah. |
| 21:30:38 | braewoods | might explain why openwrt, though being built from nearly 100% C or C++ code packages, drops support for older stuff after awhile |
| 21:30:49 | braewoods | they used to support 32MB targets but no longer |
| 21:30:57 | braewoods | 64MB is the minimum now |
| 21:31:03 | speachy | braewoods: the ingenic "xburst" cores have a lot of custom DSP-ish instructions (aka SSE or altivec) that could give a serious boost to our codecs but.. the support for them was never mainlined into gcc and.. it's such a fast processor to begin with. |
| 21:31:42 | __Bilgus | we have dev resources and well commented code (usually) pick a spot and program away more geared towards making other stuff rather than core our plugin api is pretty pleasant you can even explore things in lua (not vanilla) |
| 21:31:45 | braewoods | speachy: i see. thought SSE and altivec are not for ARM. |
| 21:31:48 | speachy | openwrt's feature set has expanded considerably. upstream linux kernels only get larger, and all the software packages only grow. plus you need more RAM for buffers |
| 21:31:59 | speachy | for higher sustained throughput I maen |
| 21:32:22 | braewoods | whereas the main high speed IO interface in rockbox is disk IO or USB |
| 21:32:42 | braewoods | networking isn't necessarily involved |
| 21:32:51 | braewoods | main use would be bluetooth accessories |
| 21:32:59 | speachy | bluetooth is UART-based. |
| 21:33:14 | braewoods | but it still has networking stuff like MAC addresses, no? |
| 21:33:19 | speachy | audio data is via an out-of-band channel directly into the audio codec |
| 21:33:59 | speachy | yeah, BT has its addressing too. but it's a completely different, um, paradigm to the classic ISO/OSI model |
| 21:34:10 | speachy | bluetooth is application-centric, not network-centric. |
| 21:34:20 | braewoods | indeed. the closest analog is point to point links. |
| 21:35:06 | braewoods | it's more like USB than wifi then. |
| 21:35:21 | speachy | __Bilgus: yeah, if you step away from the low-level hardware stuff (which is _always_ a hair-pulling trainwreck) rockbox's internals are very well put together. |
| 21:36:03 | braewoods | do any rockbox targets support a TCP/IP stack? |
| 21:36:10 | braewoods | only use I could see is accessing file shares or something |
| 21:36:46 | speachy | braewoods: but back to your question about SoCs −− most DAP-targeted SOCs these days utilize mid-range microcontrollers, a bunch of HW-based codecs, and just enough RAM to handle a crude UI. |
| 21:37:07 | braewoods | i see. |
| 21:37:21 | braewoods | so done very cheaply |
| 21:37:22 | speachy | rockchip's rknano line and Actions's atj2127 (?) still ship by the bucketful. |
| 21:38:31 | speachy | minimal package pins −− enough for a few buttons, display, SD card, and the audio codec. highly integrated. not unlike the original archos players except the entire PCB is integrated into a single ASIC. with a quarter of the RAM. and faster. |
| 21:39:00 | braewoods | sounds expensive to design |
| 21:40:06 | braewoods | i've seen people turn router SOCs into a network connected music box |
| 21:40:53 | braewoods | though that doesn't require as much stuff. |
| 21:40:55 | speachy | eh, not especially. the individual IP blocks onboard are fairly standardized these days, and the design time more than pays for itself when you consider the reduced manufacturing cost (x capital-V-Volume) |
| 21:41:32 | braewoods | reminds me of the vocore project a bit |
| 21:42:01 | braewoods | a lot of integrated stuff that might make for a useable base. |
| 21:42:16 | braewoods | https://vocore.io/v2u.html |
| 21:42:31 | speachy | the SoC might be marginally more expensive, but if it means you can half the cost of the rest of the BOM, it's an easy net win. |
| 21:43:39 | braewoods | do any rockbox devices support USB 3? |
| 21:44:09 | braewoods | not that i expect them to but it would be nice in some cases |
| 21:46:29 | speachy | No |
| 21:47:25 | speachy | USB 3 gains nothing; you don't need the extra throughput and it requires high-speed PHYs that cost money, power, and space. |
| 21:53:00 | speachy | __Bilgus: I don't think adding more icache discards will help; the ROLO code drops all caches before jumping to the new code's entry point, and we discard caches again after the iram and bss are copied/initialized |
| 21:53:18 | speachy | ie at the top of system_main() |
| 22:00 |
| 22:01:16 | braewoods | speachy: one benefit but only one. faster sync possibly. |
| 22:02:16 | speachy | braewoods: these things lack the I/O performance to saturate USB2 |
| 22:02:26 | braewoods | I see. |
| 22:02:49 | braewoods | so they're a bigger bottleneck than their storage devices in some cases |
| 22:03:59 | braewoods | i wonder what the fastest USB write speed for PP rockbox is... |
| 22:04:02 | braewoods | seems to be pretty slow |
| 22:04:08 | braewoods | around 6 MB/s or less |
| 22:15:18 | speachy | our USB and SD bits are optimized for memory usage, rather than performance |
| 22:21:59 | __Bilgus | speachy could you look at this to see if i'm doing something stupid sanity check persay |
| 22:22:02 | __Bilgus | https://gerrit.rockbox.org/r/#/c/2732/2/firmware/rolo.c |
| 22:23:25 | speachy | I think it's sane. although IMO the preparing/executing messages should go in regardless. |
| 22:23:49 | __Bilgus | don't even see them |
| 22:24:05 | __Bilgus | they are dwarfed by that load |
| 22:24:19 | __Bilgus | but I did find my error I calculated twice |
| 22:24:52 | speachy | yeah |
| 22:28:56 | __Bilgus | huh it still fails the checksum |
| 22:29:11 | __Bilgus | I'm alomost sure my code is sane now! |
| 22:34:28 | __Bilgus | hth can such a simple copy go awry? |
| 22:34:52 | __Bilgus | irqs not restoring the stack properly clock errors? my code being shit? |
| 22:41:24 | *** | Saving seen data "./dancer.seen" |
| 22:43:01 | braewoods | speachy: i see. |
| 23:00 |
| 23:02:05 | __Bilgus | now i'm beginning to really woinder about power stability |
| 23:02:31 | __Bilgus | and my inability to type |
| 23:06:17 | speachy | FINALLY. got out of that damn rabbit hole. |
| 23:08:56 | braewoods | speachy: ehhh, what's up doc? |
| 23:08:58 | braewoods | =p |
| 23:09:02 | speachy | mostly |
| 23:09:32 | speachy | firefox 80 silentlybroke compatibility with older versions of the sync server. |
| 23:09:53 | speachy | I was trying to pull up the tab I had on another system so I could look up the reference for the interrupt coprocessor registers |
| 23:10:38 | __Bilgus | I updated that rolo checksum patch not really sure where to dart from here |
| 23:10:53 | | Quit TheSeven (Disconnected by services) |
| 23:11:02 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
| 23:11:09 | __Bilgus | I guess next I'll stop interrupts |
| 23:12:04 | speachy | interrupts are disabled when rolo_restart is called |
| 23:12:36 | __Bilgus | so they are |
| 23:13:53 | __Bilgus | hmm so the nand code |
| 23:14:19 | speachy | unused at the moment |
| 23:14:47 | braewoods | __Bilgus: stop interrupting! =p |
| 23:14:49 | braewoods | lol |
| 23:14:58 | braewoods | anyway. |
| 23:15:20 | braewoods | hm. |
| 23:16:02 | __Bilgus | power supply or init for the memory what else my shit code.. |
| 23:16:16 | __Bilgus | but I really don't see any logic errors |
| 23:16:45 | __Bilgus | gcc error? |
| 23:17:31 | __Bilgus | should try at a different optimization and maybe look very close at that mak |
| 23:17:34 | __Bilgus | e |
| 23:17:41 | speachy | I'd look at the asm first. |
| 23:18:22 | __Bilgus | yeah good point |
| 23:18:42 | __Bilgus | GCCOPTS |
| 23:21:03 | speachy | here's a question −− which one is correct? |
| 23:22:42 | speachy | and.. you're checksuming the dest[i] prior to copying it? |
| 23:22:57 | speachy | swap L164 and L165 |
| 23:23:16 | speachy | or 164 and 166 |
| 23:26:58 | | Quit beencubed (Quit: Leaving) |
| 23:28:22 | speachy | I haven't found any documentation for that magic bit 28 in C0_STATUS |
| 23:29:42 | speachy | ah, there we go. |
| 23:34:57 | __Bilgus | ok doesn't fail if I check after the copy heisenbyte? |
| 23:39:36 | speachy | seems silly to compute the checksum of the destination prior to writing to it... |
| 23:40:25 | __Bilgus | HAH shit code |
| 23:40:51 | __Bilgus | I can't believe I just wasted an hour on that sorry |
| 23:44:59 | speachy | we might not have sufficient nops after some coprocessor instructions |
| 23:45:27 | speachy | and I need to convert nop -> ssnop to future-proof this code a bit too. |
| 23:47:39 | __Bilgus | lol after that I think I'm going to go watch youtube |
| 23:51:23 | | Quit livvy (Ping timeout: 240 seconds) |
icon identifies that the person is a core developer (has commit access).