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-08-30

00:00:05speachyit's all about the LCD controller and video-related stuff
00:00:28speachywe can't use the LCD controller on this thing, alas. :/
00:00:44speachy(I mean with the SSD1306)
00:01:42_Bilgus_another one whats up with people not using the onboard stuff
00:02:20speachywell, it's not a standard LCD interface. though why they didn't attach it via spi or i2c is beyond me
00:02:51speachywe could at least had a HW peripheral DMAing the data out instead having to bitbang everything.
00:07:57speachyg#2713 andg#2714
00:08:01fs-bluebotGerrit review #2713 at http://gerrit.rockbox.org/r/2713 : jz4760: Prioritize Audio DMA above all others by Solomon Peachy
00:08:01fs-bluebotGerrit review #2714 at http://gerrit.rockbox.org/r/2714 : xduoox3: Use correct "ms_clk" divider for SADC and be smarter with plling by Solomon Peachy
00:13:27_Bilgus_i'll give er a rip
00:13:50speachyhand on for the sadc patch, gotta rev it due to checking the wrong thing
00:15:23_Bilgus_k
00:17:54 Join Oksana_ [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide)
00:20:47speachygreat! documentation is wrong.
00:21:19speachyADCFG_VBAT_SEL doesn't exist in the programming manual.
00:21:56speachyok, updated patch pushed.
00:24:17_Bilgus_looping if there are other IRqs good catch
00:25:31_Bilgus_still compiling OH how I miss my home PC
00:25:58speachynot sure if that's strictly required but due to how the HW IRQs are shared and then mapped out into that "irq_num" multiple "irq" from the same physical IRQ might get lost.
00:27:16_Bilgus_I feel like thats pretty typical though
00:27:29speachyI need to try the SD command interrupt operation again.
00:28:19speachyhuh, that's no longer hanging. still doesn't work, but now it looks like IRQs are making it through.
00:28:47speachyI wonder how hard it would be to wire up a JTAG probe to this thing
00:30:28_Bilgus_cube crashed it HARD and fast
00:31:54speachyexcellent! MSC interrupts are definitely making it through, which proves my code is broken instead of the IRQ delivery stuff.
00:32:29speachyyay for panicf() :)
00:32:39_Bilgus_LCd results fps: full 1921fps gslib 4664.5
00:32:59speachythat's.. kinda insane
00:33:20_Bilgus_that thing is just going so much fastyer than the screen can even display
00:34:00_Bilgus_maybe we can yield out of the update function
00:35:47speachyin the lcd_grey_data() helper you mean? or in the core?
00:36:08_Bilgus_grey helper
00:37:07speachyamy objections to me pushing those two patches? (I just fixed the tabs in the irq patch)
00:37:59_Bilgus_IDK cube crashes now let me try slowing down grey lib and see if it helps
00:38:21***Saving seen data "./dancer.seen"
00:38:44_Bilgus_I also can't seem to exit from the boost test plugin
00:40:35_Bilgus_yeah it can't pick up the press release
00:41:03speachycurrent git master has no boost
00:41:17_Bilgus_doesn't matter to the plugin
00:42:02speachydoesn't the cpu_boost plugin API function require HAVE_ADJUSTABLE_CPU_FREQ to even be present?
00:42:50_Bilgus_for the boost part it should still allow you to exit
00:43:18speachyI mean, the test_boost plugin doesn't even get compiled without adjustable_cpu_freq
00:45:07_Bilgus_oh maybe its a bad plugin then
00:45:42_Bilgus_ok test mem does it too just not so bad that I can't quit
00:46:42speachyit took a few to break out but I was able to quit. test_mem also stalled audio playback when running.
00:47:33_Bilgus_yeah all the intensive ones do
00:48:09speachygiven that keypresses are handled by the main tick thread, it's not surprising it stalls
00:48:38speachy...the limit of a cooperative scheduler, eh?
00:48:41_Bilgus_lua script rliimage the twist stops playback too
00:48:52_Bilgus_the clip+ handles it flawless
00:49:28speachythe clip+ also has sane IRQ handling
00:49:48_Bilgus_touche
00:51:26speachyI think the clip+ also directly polls GPIOs for keypresses. not irq driven either.
00:58:05_Bilgus_that sounds about right
00:58:26speachyit seems the common failure here is very high CPU loading.
00:58:43_Bilgus_I'm not overly worried about the key stuff yet I think I can probably get it a bit better
00:59:31_Bilgus_unfortunately that probably points to something being wrong
00:59:47_Bilgus_but damned if grey lib needs to run at 4khz
00:59:47speachy"something"
01:00
01:00:09_Bilgus_yeah and that sucks *something*
01:01:27speachya failure that only happens under heavy load could also be something more mundane like the power supply
01:02:47speachyjohnb's player acting up where ours did not, on the same firmware and file, is quite suspicious. Though there's the SD card variable.
01:03:18speachyalso there's a bug report in teh tracker about HP pause/resume not working but .. itworksfineforme(tm).
01:05:19_Bilgus_nope cube is still crashing
01:05:28_Bilgus_lets try even slower
01:06:01speachyare you using the cache changes too?
01:08:16_Bilgus_head + 2713 2714
01:10:52_Bilgus_well slowing it way down helped it no crashes but it needs to be faster
01:14:01 Quit massiveH (Quit: Leaving)
01:14:47_Bilgus_also oddly the grey screen starts out with random data + lines
01:18:28_Bilgus_at 5HZ which is about as slow as I can make it and have it look OK
01:18:43_Bilgus_fire runs for about 1 minute before it crashes
01:19:24_Bilgus_fps tells me 1% cpu load so its not a loading issue I don't think
01:19:50_Bilgus_lets try setting grey to display the regular image
01:23:51_Bilgus_still crashes
01:25:08_Bilgus_so maybe something is mis configured we keep toggling the CS pin maybe its mapped to the wrong gpio
01:30:34speachychagned the IRQ patch again, priorities are now Audio DMA and TCU0 (for our systick)
01:31:46speachybut at this point I'd love to know if it's a crash, hang, deadlock, or what...
01:32:38speachywait.
01:32:43_Bilgus_ok
01:33:02speachythis might be self-inflicted
01:34:22speachycomment out USE_HW_UDELAY in system-jz4760.c
01:40:54_Bilgus_behaves much better
01:40:59_Bilgus_no cube crash
01:41:00speachyyeah
01:41:31speachysystick and my udelay code used the same hw timer
01:41:39_Bilgus_lets see if fire crashes after a bit
01:41:46_Bilgus_but its wayyyyyy better
01:42:05_Bilgus_still stutters a bit
01:45:28fs-bluebotBuild Server message: New build round started. Revision b01e929, 280 builds, 8 clients.
01:46:44speachyI'm packing it in. way past pumpkin time.
01:47:20_Bilgus_ok thanks and have a good night
01:47:30speachyI'll fix udelay to use a different timer in the morning. bleh.
01:47:39_Bilgus_are you pushing the 2713/14?
01:47:47speachyyeah, they'll land after this one.
01:47:53speachys/land/build/
01:48:39_Bilgus_ok I'm going to slow down greylib a bit and get the cpu% down, some dma things before I pack it in
01:53:46speachyI think the reason for the audio glitches was that we'd hit a udelay() somewhere aroudn the time we trip over an os tick, and we'd never meet the delay criteria.
01:53:56speachys/glitch/hang
01:54:09speachyso we'd block forever.
02:00
02:04:12fs-bluebotBuild Server message: Build round completed after 1124 seconds.
02:04:13fs-bluebotBuild Server message: Revision b01e929 result: All green
02:04:14fs-bluebotBuild Server message: New build round started. Revision cc5b043, 280 builds, 7 clients.
02:14:54 Join Rower- [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
02:16:35 Quit Rower (Ping timeout: 240 seconds)
02:19:55fs-bluebotBuild Server message: Build round completed after 943 seconds.
02:19:56fs-bluebotBuild Server message: Revision cc5b043 result: All green
02:19:57fs-bluebotBuild Server message: New build round started. Revision e06ab68, 280 builds, 7 clients.
02:37:00fs-bluebotBuild Server message: Build round completed after 1023 seconds.
02:37:01fs-bluebotBuild Server message: Revision e06ab68 result: All green
02:38:22***Saving seen data "./dancer.seen"
03:00
03:23:27 Quit ufdm (Remote host closed the connection)
04:00
04:15:04 Join Huntereb [0] (~Huntereb@174.226.2.53)
04:20:01 Quit _Bilgus_ (Remote host closed the connection)
04:28:02 Join johnb4 [0] (~johnb2@91.58.243.148)
04:38:23***Saving seen data "./dancer.seen"
04:50:55 Quit johnb4 (Ping timeout: 240 seconds)
04:54:24 Quit prof_wolfff (Ping timeout: 240 seconds)
05:00
05:41:56 Quit Huntereb (Ping timeout: 240 seconds)
05:44:58 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
05:45:53pamauryspeachy: did you manage to download a PDF from this chinese website ?
05:52:07 Quit pamaury (Quit: this->disconnect())
05:53:19 Join johnb4 [0] (~johnb2@p5b3af394.dip0.t-ipconnect.de)
05:57:06 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
06:00
06:05:27 Join advcomp2019_ [0] (~advcomp20@65-131-168-14.sxct.qwest.net)
06:05:28 Quit advcomp2019_ (Changing host)
06:05:28 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019)
06:07:15 Quit advcomp2019__ (Ping timeout: 258 seconds)
06:07:55 Quit J_Darnley (Read error: Connection reset by peer)
06:08:19 Join J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be)
06:09:25 Quit johnb4 (Ping timeout: 240 seconds)
06:09:58 Join johnb4 [0] (~johnb2@p5b3af394.dip0.t-ipconnect.de)
06:12:18 Quit TorC (Ping timeout: 256 seconds)
06:14:51 Join TorC [0] (~Tor@fsf/member/TorC)
06:18:58 Quit toruvinn (Ping timeout: 260 seconds)
06:22:40 Quit johnb4 (Ping timeout: 246 seconds)
06:25:07 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
06:26:22pamauryYour work almost makes me wan to finish the Fiio X1 first gen port, even though it's old
06:27:33 Join lebellium [0] (~lebellium@2a01cb080a0f0b00e44e1c68a1faaac4.ipv6.abo.wanadoo.fr)
06:31:10 Join toruvinn [0] (~toruvinn@178-37-200-229.adsl.inetia.pl)
06:32:22 Quit SovietShaman (Ping timeout: 256 seconds)
06:33:04 Quit advcomp2019_ (Ping timeout: 240 seconds)
06:38:26***Saving seen data "./dancer.seen"
07:00
07:16:02 Quit Oksana_ (Ping timeout: 265 seconds)
07:25:02 Join lebellium_ [0] (~lebellium@2a01cb080a0f0b0060e62403ebba4ace.ipv6.abo.wanadoo.fr)
07:29:15 Quit lebellium (Ping timeout: 272 seconds)
07:32:32 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net)
07:43:48 Quit livvy (Remote host closed the connection)
07:45:32 Join Oksana_ [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide)
07:48:48 Join prof_wolfff [0] (~prof_wolf@240.red-88-19-58.staticip.rima-tde.net)
07:49:23 Quit beencubed (Ping timeout: 265 seconds)
07:53:06 Join lemon_jesus5 [0] (~lemon_jes@c-73-9-49-209.hsd1.il.comcast.net)
07:54:52 Quit toruvinn (Ping timeout: 256 seconds)
07:54:53 Quit scorche (Ping timeout: 256 seconds)
07:55:26 Quit lemon_jesus (Ping timeout: 256 seconds)
07:55:27 Nick lemon_jesus5 is now known as lemon_jesus (~lemon_jes@c-73-9-49-209.hsd1.il.comcast.net)
07:58:05 Join johnb2 [0] (~johnb2@p5b3af394.dip0.t-ipconnect.de)
07:58:33 Join scorche [0] (~scorche@rockbox/administrator/scorche)
08:00
08:03:13 Quit scorche (Ping timeout: 264 seconds)
08:16:02 Join toruvinn [0] (~toruvinn@178-37-200-229.adsl.inetia.pl)
08:22:08 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
08:27:12 Join sakax [0] (~r0b0t@unaffiliated/r0b0t)
08:32:50 Join scorche [0] (~scorche@rockbox/administrator/scorche)
08:35:04 Quit johnb2 (Ping timeout: 240 seconds)
08:38:29***Saving seen data "./dancer.seen"
08:39:44 Quit scorche (Ping timeout: 240 seconds)
08:40:34 Quit mikroflops (Quit: Lost terminal)
09:00
09:12:16 Join livvy [0] (~livvy@gateway/tor-sasl/livvy)
09:15:48 Join scorche [0] (~scorche@rockbox/administrator/scorche)
09:17:03 Quit livvy (Ping timeout: 240 seconds)
09:30:14 Join livvy [0] (~livvy@gateway/tor-sasl/livvy)
10:00
10:03:24 Join __Bilgus [0] (41ba23be@65.186.35.190)
10:04:48__Bilguspamaury unfortunately no such luck and It cuts off the real juicy stuff but it EXIUSTS!
10:12:42 Join Huntereb [0] (~Huntereb@174.226.2.53)
10:16:47__BilgusHunterb long time no see got any agptek goodies?
10:22:25 Join mikroflops [0] (~yogurt@c188-150-217-176.bredband.comhem.se)
10:23:24speachypamaury: I actually bought one of those a few years ago −− got it for cheap as the rotary encoder on the wheel is flaky.
10:25:27speachypamaury: dusting off your incomplete port is one of the eventual goals of what I'm trying to do now..
10:27:38 Join johnb4 [0] (~johnb2@p5b3af394.dip0.t-ipconnect.de)
10:28:45speachyjohnb4: latest build ought to behave better.
10:30:13johnb4ok, will try
10:37:51 Join advcomp2019 [0] (~advcomp20@65-131-168-14.sxct.qwest.net)
10:37:51 Quit advcomp2019 (Changing host)
10:37:51 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
10:38:30***Saving seen data "./dancer.seen"
10:39:13 Join johnb2 [0] (~johnb2@p5b3af394.dip0.t-ipconnect.de)
10:54:23 Quit johnb2 (Quit: Nettalk6 - www.ntalk.de)
10:55:58 Quit scorche (Read error: Connection reset by peer)
10:59:41 Quit johnb4 (Quit: Nettalk6 - www.ntalk.de)
11:00
11:00:46 Join johnb2 [0] (~johnb2@p5b3af394.dip0.t-ipconnect.de)
11:00:59johnb2speachy
11:01:20johnb2: the previous build would not mount anymore on Windows ...
11:01:28johnb2I had to use the card reader.
11:01:43johnb2Audio playback seems fine.
11:02:16johnb2Anything in particular you want me to test?
11:02:50speachyno, just establishing a new baseline
11:03:58speachyhttp://www.shaftnet.org/~pizza/x3-test-a1.zip <−− Now this is the one that I'm curious about. :)
11:08:04 Join scorche [0] (~scorche@rockbox/administrator/scorche)
11:14:48johnb2I paused an mp3, vol +1 froze the player
11:17:50johnb2when it goes from 480 to 192 I hear the single clicks again, e.g. Vol-
11:18:15johnb2Boosting/unboosting in debug->freq just froze the player
11:19:30johnb2but the click is not always reproducible from WPS and vol change
11:20:42speachyok. please go back to the dev build then
11:21:12speachyoh, on the dev build, can you do one other test? enable "pause/resume on headphone unplug/plug" in the settings/playback stuff
11:21:17speachyand see if that works
11:22:59__Bilgusslowing down greylib seems to have quelled the worst of it
11:24:40__Bilgusspoke too soon crashed on fire
11:27:30johnb2speachy : both pause and pause/resume work
11:27:52speachyok, thank you. there's a bug ticket claiming they don't. I can't recreate it either.
11:31:46johnb2__Bilgus: I am not familiar with display physics. Are all the brightness and contrast settings safe/in spec or are the prone to age the display/controller?
11:31:59johnb2*are they
11:32:19__Bilgusjohnb who knows
11:32:24johnb2:-)
11:32:26speachyjohnb2: it's an OLED, so use will age the display pixels. brighter == more age. basic physica, alas.
11:32:42__Bilgusextra brightness on an OLED will always make it age faster
11:33:44johnb2So I better get the other screen mounted soon, instead of maxing contrast and brightness
11:34:08__Bilgus10000 hrs
11:34:30__Bilguswhere did the rest of my sentence go
11:36:06__BilgusI bet lifetime is probably 10000 hrs at best anyways
11:36:32speachythe OLED panel can be replaced too if it comes to that, though I'd imagine the buttons/etc would have fallen off well before that
11:37:07speachythere's no shortage of 128x64 SSD1306-based OLED units out there.. :)
11:37:42johnb2But I am not sure if I was able to replace it, if needed ;-)
11:37:56__Bilgusmy driving of the panel shouldn't cause any issues either average power should still be pretty close I just give it longer to display in current mode it is therefore brighter
12:00
12:06:33 Nick mendelmunkis is now known as mendel_munkis (~mendelmun@ool-ae2cb138.dyn.optonline.net)
12:38:33***Saving seen data "./dancer.seen"
12:44:25 Quit johnb2 (Quit: Nettalk6 - www.ntalk.de)
13:00
13:27:59 Quit __Bilgus (Ping timeout: 245 seconds)
14:00
14:14:48 Quit ac_laptop (Quit: WeeChat 2.9)
14:15:05 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
14:15:34 Quit Moarc (Quit: i znowu NADMUCHAŁ BALONA)
14:17:44 Join __Bilgus [0] (41ba23be@65.186.35.190)
14:19:48 Join Moarc [0] (~chujko@a105.net128.okay.pl)
14:20:33__Bilgusspeachy I'm messing with changing the drive strength on the pins going to the LCD but I did notice 2709 runs much less stable at head now
14:24:34 Join johnb4 [0] (~johnb2@p5b3af394.dip0.t-ipconnect.de)
14:28:28 Quit ac_laptop (Ping timeout: 246 seconds)
14:36:21 Quit johnb4 (Ping timeout: 265 seconds)
14:38:37***Saving seen data "./dancer.seen"
14:46:40 Join Rower [0] (~Rower@185.246.208.202)
14:48:49 Quit Rower- (Ping timeout: 264 seconds)
15:00
15:02:28 Join Rower- [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
15:02:35 Quit Rower- (Remote host closed the connection)
15:05:13 Quit Rower (Ping timeout: 246 seconds)
15:25:00 Quit mendel_munkis (Ping timeout: 258 seconds)
15:38:16 Join mendelmunkis [0] (~mendelmun@ool-ae2cb138.dyn.optonline.net)
16:00
16:05:28 Join johnb4 [0] (~johnb2@p5b3af394.dip0.t-ipconnect.de)
16:09:48 Quit johnb4 (Ping timeout: 256 seconds)
16:12:28 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
16:28:18 Quit JanC (Remote host closed the connection)
16:38:40***Saving seen data "./dancer.seen"
16:38:51 Join JanC [0] (~janc@lugwv/member/JanC)
16:47:31speachy__Bilgus: ...lovely
16:48:58 Quit JanC (Ping timeout: 244 seconds)
16:50:19 Join JanC [0] (~janc@lugwv/member/JanC)
17:00
17:04:48 Quit JanC (Remote host closed the connection)
17:05:19 Join JanC [0] (~janc@lugwv/member/JanC)
17:27:28fs-bluebotBuild Server message: New build round started. Revision 06e9abc, 280 builds, 8 clients.
17:41:22speachy__Bilgus: the CPU load % you were reporting for greylib, how is that derived?
17:43:53fs-bluebotBuild Server message: Build round completed after 984 seconds.
17:43:53__Bilgusits the difference between time taken to display wireframe versus greylib I believe
17:43:55fs-bluebotBuild Server message: Revision 06e9abc result: All green
17:46:11__Bilguslooking at the ADC code I think an interrupt might help here
17:46:39__Bilgusdecouple the read_data command from running the adc
17:47:01speachyit is does use an IRQ...?
17:47:05speachys/is//
17:47:22__Bilgustheres something abou polling the KEY data so no interrupt needed
17:47:54speachykey data is polled in interrupt context (ie system tick handler)
17:48:45speachyit returns the last ADC value while kicking off a new ADC read, which then trips an IRQ when it's done, updating the state
17:49:32speachyso we effectively lag input and battery by 1 tick.
17:49:44speachy(ie 10ms)
17:52:33__BilgusI don't think we know what actually feeds the button array then
17:54:00__BilgusI figured the KEY_INT was driving through the button matrix
17:56:15speachyit might be that all the keys feed both the ADC and a GPIO pin, but doing an blocking ADC sample in interrupt context probably isn't wise.
17:56:30speachya single GPIO, that is
17:57:21__Bilguswe'd just kick it off then
17:58:13 Join meatloaf [0] (~ambassado@2601:246:4400:b3c0:7593:e6ad:5904:25dd)
17:58:42speachyI wonder if instead of constantly having the ADC sampling, you mean?
17:59:17__BilgusI'll test later if my idea is right but I see it floats high when no buttons are pressed so i'll start futzing gpios till it turns off
17:59:53__Bilgusif we drop below the threshold on button press we can use that falling sig to kick off the adc
18:00
18:00:22__Bilgusthen we just keep a few state vars and last sample tick
18:00:42speachymight that also cause issues if the user fat-fingers keypresses? they'd have to let go of everything in order for the level to reset for a new trigger
18:00:56 Quit ZincAlloy (Quit: Leaving.)
18:01:08__Bilguspossible but thats where pullups come in
18:01:37speachywe can't power down the ADC so I don't really see this making much of a difference.
18:03:07speachyhmm. we have peak stack reporting, right?
18:03:29__Bilgusmaybe but I figure it removes some load to not be doing adc interrupts when unneeded
18:04:00__Bilgusyes?
18:04:44speachyoh, here's an idea −− use the gpio as the trigger to start sampling via the tick/button handler, but when the GPIO is removed stop sampling.
18:06:05__Bilgusoh short circuit them?
18:06:12speachyso only initiate sampling if GPIO141 is asserted, and when it deasserts.. BTN_NONE
18:07:11 Quit lebellium_ (Quit: Leaving)
18:08:06__BilgusI'll throw together a gpio sampler for the debug menu
18:08:33speachyI need to see about reporting the irq stack watermark
18:14:41speachyI don't like that we hang. audio dropout sure, but hang? is it a deadlock? a non-panic crash?
18:14:54speachystuck in an IRQ handler?
18:15:53 Quit JanC (Remote host closed the connection)
18:16:14 Join JanC [0] (~janc@lugwv/member/JanC)
18:34:24 Quit pamaury (Ping timeout: 240 seconds)
18:38:43***Saving seen data "./dancer.seen"
18:51:52 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
18:52:47 Quit meatloaf (Ping timeout: 260 seconds)
19:00
19:00:29 Quit __Bilgus (Remote host closed the connection)
19:05:02 Quit pamaury (Ping timeout: 258 seconds)
19:18:36 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
19:26:19 Quit bluebrother (Disconnected by services)
19:26:24 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother)
19:27:42 Join fs-bluebot_ [0] (~fs-bluebo@55d4a844.access.ecotel.net)
19:29:57 Quit fs-bluebot (Ping timeout: 258 seconds)
19:33:58 Quit ac_laptop (Quit: WeeChat 2.9)
19:34:53 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
19:34:59 Quit pamaury (Ping timeout: 240 seconds)
19:55:53 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
20:00
20:05:25 Quit pamaury (Ping timeout: 240 seconds)
20:19:06 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
20:35:25 Quit pamaury (Ping timeout: 240 seconds)
20:38:47***Saving seen data "./dancer.seen"
20:52:33 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
21:00
21:01:10speachyhuh, that's unexpected. supposeddly the irqstack max depth is only 152 bytes. seems quite low given the irqhandler asm sucks down 132 bytes before it hands off to C.
21:02:11speachyand the first C function sucks down 32 bytes.
21:04:39speachymake that 50
21:05:55 Quit pamaury (Ping timeout: 240 seconds)
21:08:01speachycounting from the beginning works better. 356 bytes after bootup.
21:09:19speachy372 after USB hotplug..
21:09:44 Join _BILGUS [0] (41ba23be@65.186.35.190)
21:10:47 Quit sakax (Quit: Leaving)
21:10:53_BILGUSso are you counting wrong or is it ovflow?
21:12:16speachyI was counting wrong. well, not "wrong" per se but not every address on the stack gets written to
21:14:28speachymy build has full reclocking, changes that explicltly disable the UARTs, and... fire's still running 30 seconds later.
21:17:01speachythis isn't crashing on me.
21:18:42speachystill going..
21:22:46speachystill going...
21:23:28 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
21:37:05fs-bluebot_Build Server message: New build round started. Revision 8dadce5, 280 builds, 8 clients.
21:38:12_BILGUScool does it still click in your ear?
21:38:20speachynope. fire's still going.
21:38:28speachyit's what's building now
21:38:46speachy(plus re-enabling the reclocking)
21:38:53_BILGUSI'm adding gpio to the debug menu atm
21:39:20_BILGUSso uart like for serial?
21:39:37speachyI intend to rewrite the debug hwinfo to be scrollable.. there's far more output in the 4760's dump than fits on screen
21:39:41speachyyeah, serial output.
21:40:15_BILGUSoh I already added the pieces for scrolling
21:40:23speachyoh awesome. :)
21:40:35speachydidn't know how to do it so I was actually looking it up
21:40:38_BILGUSyeah it gets annoying quick having cut off data
21:40:48_BILGUScheck out the clip+ one
21:41:04_BILGUSwell + zip ....
21:41:47speachywonder if high load (or high lcd update rate) was inducing noise on the floating UART lines
21:43:11_BILGUSor they just need to be forced to input with a pullup
21:43:24speachyinterrupts weren't turned on though.. so none of this should have mattered.
21:44:05speachybut even if this was (yet another) red herring the UARTs aren't needed, so disabling the code and turning 'em off is Right and Proper (tm)
21:44:32speachyI was able to crash the player within seconds before and now it's still going.
21:45:13speachywhen johnb's back I'll send him another reclocked build and see what happens. I wonder if he has defective hardware or something..
21:46:03_BILGUSit works fine in OF so I guess possible but more probably we have a shoddy setup
21:46:26speachyI don't think the OF reclocks at all, if the battery life is any indication
21:46:39_BILGUSnot that I could point to the specific instance but it all starts smelling like shit
21:47:16_BILGUSI'm dying for more documentation it sucks having to test to figure out values
21:47:41speachy(or heck, the kernel sources for the OF..)
21:47:54speachy(and probably more importantly, uboot)
21:50:13speachy_BILGUS: but hey, you "enjoy" this sort of thing... :D
21:50:40_BILGUSindeed but it still is nice to have something to check
21:52:10speachyyeah. a lot of unnecessary effort.
21:52:25fs-bluebot_Build Server message: Build round completed after 919 seconds.
21:52:27fs-bluebot_Build Server message: Revision 8dadce5 result: 5 errors 0 warnings
21:52:59speachygrrr.
21:53:35_BILGUShmm no changing on the gpio or the actual direction I wonder if the docs lie
21:54:36_BILGUSnope just me being dumb\
21:55:34speachyI need to fix the mikmod crash
21:55:54speachythere's a missing nullptry check somewhere
21:56:05speachyin the instrument/etc display screens
21:56:48fs-bluebot_Build Server message: New build round started. Revision 748133c, 280 builds, 8 clients.
21:56:59speachythere, that'll fix the x3 bootloader.
21:59:41_BILGUSso no gpio activity on the button presses but it gets all kinds of activity when the hold button is switched
22:00
22:00:11_BILGUSgonna keep investigating a bit more before I give up on the idea
22:00:11 Quit livvy (Remote host closed the connection)
22:08:01 Quit ac_laptop (Ping timeout: 246 seconds)
22:12:27fs-bluebot_Build Server message: Build round completed after 940 seconds.
22:12:29fs-bluebot_Build Server message: Revision 748133c result: All green
22:14:48 Quit JanC (Remote host closed the connection)
22:15:41 Join JanC [0] (~janc@lugwv/member/JanC)
22:16:49 Quit JanC (Remote host closed the connection)
22:17:41 Join JanC [0] (~janc@lugwv/member/JanC)
22:25:54 Quit JanC (Killed (rajaniemi.freenode.net (Nickname regained by services)))
22:25:58 Join JanC [0] (~janc@lugwv/member/JanC)
22:38:49***Saving seen data "./dancer.seen"
22:40:07_BILGUSOk So I am correct KEY_INT does trigger when a button is pressed
22:40:52_BILGUSPORT E pin 13
23:00
23:03:39_BILGUSand I think we can now do multiple buttons with at least some buttons
23:04:07_BILGUSplay back option all toggle another gpio it appears
23:07:18fs-bluebot_Build Server message: New build round started. Revision 63e6aec, 280 builds, 8 clients.
23:16:27 Quit TheSeven (Ping timeout: 260 seconds)
23:16:40 Join [7] [0] (~quassel@rockbox/developer/TheSeven)
23:23:11fs-bluebot_Build Server message: Build round completed after 952 seconds.
23:23:12fs-bluebot_Build Server message: Revision 63e6aec result: 3 errors 0 warnings
23:41:49 Quit _BILGUS (Remote host closed the connection)

Previous day | Next day