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

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

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

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2020-09-04

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__BilgusSpeachy, 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__BilgusEvery register I checked is the same when it works as when it doesnt
09:11:36__Bilgusso the ADC gets the enable bit set but it never completes a sample
09:17:44speachythe key_int gpio you mean?
09:19:52speachybecause the ADC clock is hanging directly off the XTAL
09:21:02__Bilgusno the interrupts happen just fine it acts as if the XTAL source stops
09:21:39__Bilgusthe en bit gets set the setup is the same but it never fires off a result
09:21:56speachy__Bilgus: L289, that should be |= AUXEN
09:22:11__Bilguswhat i eneded up doing was mapping that interrupt to a button press so I coiuld get through the debug menus lol
09:22:38speachywe end up turning off the battery sample if one's running when we do a keypress.
09:24:26__BilgusI'm not sure how that'd make the adc stall but i'll try it
09:25:41__Bilgusmaybe one of the reserved bits gets wiped
09:28:13__Bilgusnope no dice
09:28:37__BilgusI'
09:29:43__BilgusI'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__Bilgusvoltage ref
09:31:09 Join lebellium_ [0] (~lebellium@2a01cb080a0f0b00cc2459fa1a997fa1.ipv6.abo.wanadoo.fr)
09:34:37 Quit lebellium (Ping timeout: 260 seconds)
09:35:19speachyoh, it's not just rolo; power on voltage isn't registering properly either.
09:37:34__BilgusI feel like its just got to a configuration error somewhere but damn if I can find it
09:37:55__Bilgusgot to be*
09:41:03speachyvoltage history since powerup is 9.8v, 9.8, 7.5, 5.2, 4.3, 4.0, 3.8
09:45:18__Bilgusah thats a misnomer
09:45:49__Bilgusits just picking up that defa0ult value of 0xFFF
09:46:32__Bilgusits just that it got thrown into the averaging
09:46:48__Bilgusbut its trending down so the adc is doing samples
09:49:15 Quit emacsomancer (Quit: WeeChat 2.8)
09:50:18__BilgusANDD 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:10speachyhuh, the codec api has the cache manipulations in it, but no users on single-core targets.
09:55:49speachyplugins 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__Bilguscache manipulations?
10:02:16speachyshould 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:52speachyooo! just lost keyboard after a rolo, and when I hit the power button, it paniced with a TLB exception
10:21:27__BilgusI det it to 4.222 6DD
10:21:31__BilgusI set*
10:23:35__Bilgusso looking at gpios there is exactly one GPIO that has changed between the rolo restart and a regular one GPIOB Bit 28
10:28:47speachynothing seems to explicitly access that bit
10:30:13__Bilgusit won't let me flip it either so probably an input
10:33:16speachywhen 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:31speachywe might need to do something timilar to the imx31 or rk27xx's custom rolo code.
10:44:37__Bilgusah ok so that would make sense of why its seemingly random it just depends on what has changed
10:45:02__Bilgusthat gpio as far as I can tell is just a red herring
10:45:49speachy...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__Bilgusok i'll try to figure that out this evening
11:09:33speachyinterrupts are disabled too.
11:09:39speachyso that theory's probably out
11:10:27speachywe 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__Bilgusit 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__Bilgusyour 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__BilgusSpeachy I *think* I have it figured out
13:10:20__Bilgusg# 2732
13:10:32__Bilgusno blue bot huh
13:10:36__Bilgushttps://gerrit.rockbox.org/2732
13:14:56fs-bluebotBuild Server message: New build round started. Revision 5f5e44f, 280 builds, 8 clients.
13:20:00__Bilgusnope 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:04fs-bluebotBuild Server message: Build round completed after 1389 seconds.
13:38:08fs-bluebotBuild 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:43ultraelephantHello. 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:40speachyultraelephant: PM me your desired username and email address and I'll create an account for you
15:58:05fs-bluebotBuild Server message: New build round started. Revision 90a4f28, 280 builds, 7 clients.
16:00
16:02:56speachy__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:17fs-bluebotBuild Server message: Build round completed after 2533 seconds.
16:40:19fs-bluebotBuild 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__BilgusSpeachy I assume 2709 will patch on top of this still?
20:27:36__Bilgussorry 2729
20:28:57speachy2729 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__BilgusI 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:06speachythe 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__BilgusI'm not familar with that low level but I get the general idea
20:36:24__BilgusI did see where the bootloader closes the ADC though but atm i'm not sure exactly what code is getting executed there
20:39:52speachyit'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:43speachywell, one thing worth mentioning is that we won't _start_ sampling the ADC for 30s after startup.
20:56:20speachybattery ADC, I mean
20:56:58speachyshould probably initialize last_tick = -BATT_WAIT_TIME
21:00
21:03:30__Bilgusnah i'll just add bat tick at the end funny I didn't even catch that till you mentioned it
21:08:14__Bilgusspeachy so most of these interrupts (all?) have a corresponding pin that you could poll correct?
21:08:57speachyThe GPIOs, yes.
21:09:27__Bilgusall the external devices trigger through such?
21:09:36speachynot quite
21:10:36braewoodsspeachy: is it my imagination or did the mp3 player SOCs die with portalplayer?
21:10:45__BilgusI 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:48braewoodsin terms of new ones
21:11:14braewoodsit seems new ones are either based on other types of SOCs or a hodge-podge of other components.
21:11:20speachythere 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__Bilgusah so like lv 0 -> lv1 -> lv2
21:12:30speachyone of the reasons IRQ handling is so expensive is that we have to walk that hierarchy to figure out what happened.
21:12:50speachygranted, that hierarchy (and thus priority) is completely software-defined.
21:14:43speachybraewoods, 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__BilgusI was thinking more along the lines of always do a audio transfer on the start of some interrupts
21:15:10speachy__Bilgus, the rockbox HW PCM API won't allow for that
21:16:06__Bilgusah I suppose thats where you double buffering comes in
21:17:16speachythe 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:53speachyI think I've finished the core changes to optionally go triple-buffered
21:19:35speachybut I have to rewrite the jz4760's pcm DMA code to be descriptor-based first.
21:20:45braewoodsspeachy: how much memory does the playback buffer use?
21:20:49speachy(mips32r2 adds a true priority-aware HW interrupt controller as part of the CPU core. which we can't use, naturally)
21:21:00braewoodsi know audio can be fairly large so i'd expect 4k or more.
21:21:27braewoodsdepends how much audio you're buffering and the sample rate i believe
21:21:38__Bilgusspeachy yeah thats the first thing I found then realized the instructions werent there
21:21:49speachythe PCM core defaults to 256 frames, aka stereo samples.
21:22:14braewoodshm.
21:22:20braewoodsso like 1k at most?
21:22:21speachyI upped it to 2K samples, as 1K wasn't enough.
21:22:42braewoodsassuming 16 bit samples
21:22:43speachy256 frames per buffer, and there are two buffers.
21:23:01braewoodsand 1 byte per channel
21:23:10braewoodserr
21:23:12braewoods2 bytes
21:23:14__Bilgusits just funny how such a fast processor is the worst running of a great many of our ports
21:23:14speachyso now there are 2x 2048frame buffers, for a total of 16KB. (on the jz47xx targets)
21:23:35braewoodsisn't that partly due to how young it is?
21:24:05__Bilgusthat OF on the XDUOO exemplifies how slow it could be but at least it playsback right lol
21:24:26__Bilgusand it has 8MP ram?
21:24:28braewoodswhat architectures does rockbox use? mostly ARM derivatives?
21:24:30__BilgusMB
21:24:39speachywell, the OF was running native linux. which has some very robust and mature irq handling infrastructure.
21:24:54__Bilgusbrae most code is in arm I think
21:24:55braewoodsah, embedded linux. a bit surprising.
21:24:56speachyit has 32MB RAM, I believe
21:25:10braewoodsthat's not a lot of RAM for Linux though it's workable.
21:25:19braewoodsopenwrt runs on it and all
21:25:26__Bilgusthats a lot of ram for rockbox though
21:25:32speachymore than enough, given the limited functionality used. remember, no networking, nearly no UI
21:25:51braewoodsah. not even a wayland or X environment?
21:25:55speachythe frame buffer on this thing is what, 1KB? :)
21:25:59braewoodskernel framebuffer?
21:26:31braewoodsmain thing i ever used the linux framebuffer for was terminals
21:26:44braewoodskinda useless otherwise on most platforms
21:27:02speachy__Bilgus: Funny thing is that rockbox sounds better than the OF. (DSD notwithstanding)
21:27:29speachy__Bilgus: they don't reclock the PLL, and have it tuned for 48KHz-based audio rather than 44.1KHz
21:27:37braewoodsdoes rockbox utilize inline ASM at all? or is it all C?
21:27:51__Bilguswe have too much asm IMO
21:27:53speachyC unless asm is necessary
21:28:05braewoodsi hate writing ASM though I have from time to time.
21:28:10braewoodsintrinsics are usually better
21:28:34__Bilgusor somebody wanted to really squeeze performance but good luck decoding it
21:28:51braewoodsmost of the time there's no benefit to writing raw ASM since compilers have advanced so much
21:29:01braewoodsexcept maybe sheer code size
21:29:04__Bilguswell braewoods our bar to entry is low pays shit but it is fun
21:29:09braewoodsbut i don't think rockbox is that resource constrained
21:29:41speachybraewoods: 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:49braewoodsah.
21:30:38braewoodsmight explain why openwrt, though being built from nearly 100% C or C++ code packages, drops support for older stuff after awhile
21:30:49braewoodsthey used to support 32MB targets but no longer
21:30:57braewoods64MB is the minimum now
21:31:03speachybraewoods: 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__Bilguswe 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:45braewoodsspeachy: i see. thought SSE and altivec are not for ARM.
21:31:48speachyopenwrt'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:59speachyfor higher sustained throughput I maen
21:32:22braewoodswhereas the main high speed IO interface in rockbox is disk IO or USB
21:32:42braewoodsnetworking isn't necessarily involved
21:32:51braewoodsmain use would be bluetooth accessories
21:32:59speachybluetooth is UART-based.
21:33:14braewoodsbut it still has networking stuff like MAC addresses, no?
21:33:19speachyaudio data is via an out-of-band channel directly into the audio codec
21:33:59speachyyeah, BT has its addressing too. but it's a completely different, um, paradigm to the classic ISO/OSI model
21:34:10speachybluetooth is application-centric, not network-centric.
21:34:20braewoodsindeed. the closest analog is point to point links.
21:35:06braewoodsit's more like USB than wifi then.
21:35:21speachy__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:03braewoodsdo any rockbox targets support a TCP/IP stack?
21:36:10braewoodsonly use I could see is accessing file shares or something
21:36:46speachybraewoods: 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:07braewoodsi see.
21:37:21braewoodsso done very cheaply
21:37:22speachyrockchip's rknano line and Actions's atj2127 (?) still ship by the bucketful.
21:38:31speachyminimal 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:00braewoodssounds expensive to design
21:40:06braewoodsi've seen people turn router SOCs into a network connected music box
21:40:53braewoodsthough that doesn't require as much stuff.
21:40:55speachyeh, 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:32braewoodsreminds me of the vocore project a bit
21:42:01braewoodsa lot of integrated stuff that might make for a useable base.
21:42:16braewoodshttps://vocore.io/v2u.html
21:42:31speachythe 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:39braewoodsdo any rockbox devices support USB 3?
21:44:09braewoodsnot that i expect them to but it would be nice in some cases
21:46:29speachyNo
21:47:25speachyUSB 3 gains nothing; you don't need the extra throughput and it requires high-speed PHYs that cost money, power, and space.
21:53:00speachy__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:18speachyie at the top of system_main()
22:00
22:01:16braewoodsspeachy: one benefit but only one. faster sync possibly.
22:02:16speachybraewoods: these things lack the I/O performance to saturate USB2
22:02:26braewoodsI see.
22:02:49braewoodsso they're a bigger bottleneck than their storage devices in some cases
22:03:59braewoodsi wonder what the fastest USB write speed for PP rockbox is...
22:04:02braewoodsseems to be pretty slow
22:04:08braewoodsaround 6 MB/s or less
22:15:18speachyour USB and SD bits are optimized for memory usage, rather than performance
22:21:59__Bilgusspeachy could you look at this to see if i'm doing something stupid sanity check persay
22:22:02__Bilgushttps://gerrit.rockbox.org/r/#/c/2732/2/firmware/rolo.c
22:23:25speachyI think it's sane. although IMO the preparing/executing messages should go in regardless.
22:23:49__Bilgusdon't even see them
22:24:05__Bilgusthey are dwarfed by that load
22:24:19__Bilgusbut I did find my error I calculated twice
22:24:52speachyyeah
22:28:56__Bilgushuh it still fails the checksum
22:29:11__BilgusI'm alomost sure my code is sane now!
22:34:28__Bilgushth can such a simple copy go awry?
22:34:52__Bilgusirqs not restoring the stack properly clock errors? my code being shit?
22:41:24***Saving seen data "./dancer.seen"
22:43:01braewoodsspeachy: i see.
23:00
23:02:05__Bilgusnow i'm beginning to really woinder about power stability
23:02:31__Bilgusand my inability to type
23:06:17speachyFINALLY. got out of that damn rabbit hole.
23:08:56braewoodsspeachy: ehhh, what's up doc?
23:08:58braewoods=p
23:09:02speachymostly
23:09:32speachyfirefox 80 silentlybroke compatibility with older versions of the sync server.
23:09:53speachyI 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__BilgusI 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__BilgusI guess next I'll stop interrupts
23:12:04speachyinterrupts are disabled when rolo_restart is called
23:12:36__Bilgusso they are
23:13:53__Bilgushmm so the nand code
23:14:19speachyunused at the moment
23:14:47braewoods__Bilgus: stop interrupting! =p
23:14:49braewoodslol
23:14:58braewoodsanyway.
23:15:20braewoodshm.
23:16:02__Bilguspower supply or init for the memory what else my shit code..
23:16:16__Bilgusbut I really don't see any logic errors
23:16:45__Bilgusgcc error?
23:17:31__Bilgusshould try at a different optimization and maybe look very close at that mak
23:17:34__Bilguse
23:17:41speachyI'd look at the asm first.
23:18:22__Bilgusyeah good point
23:18:42__BilgusGCCOPTS
23:21:03speachyhere's a question −− which one is correct?
23:22:42speachyand.. you're checksuming the dest[i] prior to copying it?
23:22:57speachyswap L164 and L165
23:23:16speachyor 164 and 166
23:26:58 Quit beencubed (Quit: Leaving)
23:28:22speachyI haven't found any documentation for that magic bit 28 in C0_STATUS
23:29:42speachyah, there we go.
23:34:57__Bilgusok doesn't fail if I check after the copy heisenbyte?
23:39:36speachyseems silly to compute the checksum of the destination prior to writing to it...
23:40:25__BilgusHAH shit code
23:40:51__BilgusI can't believe I just wasted an hour on that sorry
23:44:59speachywe might not have sufficient nops after some coprocessor instructions
23:45:27speachyand I need to convert nop -> ssnop to future-proof this code a bit too.
23:47:39__Bilguslol after that I think I'm going to go watch youtube
23:51:23 Quit livvy (Ping timeout: 240 seconds)

Previous day | Next day