--- Log for 30.08.120 Server: card.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 1 day and 9 hours ago 00.00.05 # it's all about the LCD controller and video-related stuff 00.00.28 # we can't use the LCD controller on this thing, alas. :/ 00.00.44 # (I mean with the SSD1306) 00.01.42 # <_Bilgus_> another one whats up with people not using the onboard stuff 00.02.20 # well, it's not a standard LCD interface. though why they didn't attach it via spi or i2c is beyond me 00.02.51 # we could at least had a HW peripheral DMAing the data out instead having to bitbang everything. 00.07.57 # g#2713 and g#2714 00.08.01 # Gerrit review #2713 at http://gerrit.rockbox.org/r/2713 : jz4760: Prioritize Audio DMA above all others by Solomon Peachy 00.08.01 # Gerrit 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.50 # hand 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.47 # great! documentation is wrong. 00.21.19 # ADCFG_VBAT_SEL doesn't exist in the programming manual. 00.21.56 # ok, 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.58 # not 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.29 # I need to try the SD command interrupt operation again. 00.28.19 # huh, that's no longer hanging. still doesn't work, but now it looks like IRQs are making it through. 00.28.47 # I 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.54 # excellent! MSC interrupts are definitely making it through, which proves my code is broken instead of the IRQ delivery stuff. 00.32.29 # yay for panicf() :) 00.32.39 # <_Bilgus_> LCd results fps: full 1921fps gslib 4664.5 00.32.59 # that'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.47 # in the lcd_grey_data() helper you mean? or in the core? 00.36.08 # <_Bilgus_> grey helper 00.37.07 # amy 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.03 # current git master has no boost 00.41.17 # <_Bilgus_> doesn't matter to the plugin 00.42.02 # doesn'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.18 # I 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.42 # it 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.09 # given that keypresses are handled by the main tick thread, it's not surprising it stalls 00.48.38 # ...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.28 # the clip+ also has sane IRQ handling 00.49.48 # <_Bilgus_> touche 00.51.26 # I think the clip+ also directly polls GPIOs for keypresses. not irq driven either. 00.58.05 # <_Bilgus_> that sounds about right 00.58.26 # it 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.47 # "something" 01.00.09 # <_Bilgus_> yeah and that sucks *something* 01.01.27 # a failure that only happens under heavy load could also be something more mundane like the power supply 01.02.47 # johnb'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.18 # also 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.01 # are 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.34 # chagned the IRQ patch again, priorities are now Audio DMA and TCU0 (for our systick) 01.31.46 # but at this point I'd love to know if it's a crash, hang, deadlock, or what... 01.32.38 # wait. 01.32.43 # <_Bilgus_> ok 01.33.02 # this might be self-inflicted 01.34.22 # comment out USE_HW_UDELAY in system-jz4760.c 01.40.54 # <_Bilgus_> behaves much better 01.40.59 # <_Bilgus_> no cube crash 01.41.00 # yeah 01.41.31 # systick 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.28 # Build Server message: New build round started. Revision b01e929, 280 builds, 8 clients. 01.46.44 # I'm packing it in. way past pumpkin time. 01.47.20 # <_Bilgus_> ok thanks and have a good night 01.47.30 # I'll fix udelay to use a different timer in the morning. bleh. 01.47.39 # <_Bilgus_> are you pushing the 2713/14? 01.47.47 # yeah, they'll land after this one. 01.47.53 # s/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.46 # I 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.56 # s/glitch/hang 01.54.09 # so we'd block forever. 02.04.12 # Build Server message: Build round completed after 1124 seconds. 02.04.13 # Build Server message: Revision b01e929 result: All green 02.04.14 # Build 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.55 # Build Server message: Build round completed after 943 seconds. 02.19.56 # Build Server message: Revision cc5b043 result: All green 02.19.57 # Build Server message: New build round started. Revision e06ab68, 280 builds, 7 clients. 02.37.00 # Build Server message: Build round completed after 1023 seconds. 02.37.01 # Build Server message: Revision e06ab68 result: All green 02.38.22 *** Saving seen data "./dancer.seen" 03.23.27 Quit ufdm (Remote host closed the connection) 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.41.56 Quit Huntereb (Ping timeout: 240 seconds) 05.44.58 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 05.45.53 # speachy: 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.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.22 # Your 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.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.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.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.03.24 Join __Bilgus [0] (41ba23be@65.186.35.190) 10.04.48 # <__Bilgus> pamaury 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 # <__Bilgus> Hunterb long time no see got any agptek goodies? 10.22.25 Join mikroflops [0] (~yogurt@c188-150-217-176.bredband.comhem.se) 10.23.24 # pamaury: 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.27 # pamaury: 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.45 # johnb4: latest build ought to behave better. 10.30.13 # ok, 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.46 Join johnb2 [0] (~johnb2@p5b3af394.dip0.t-ipconnect.de) 11.00.59 # speachy 11.01.20 # : the previous build would not mount anymore on Windows ... 11.01.28 # I had to use the card reader. 11.01.43 # Audio playback seems fine. 11.02.16 # Anything in particular you want me to test? 11.02.50 # no, just establishing a new baseline 11.03.58 # http://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.48 # I paused an mp3, vol +1 froze the player 11.17.50 # when it goes from 480 to 192 I hear the single clicks again, e.g. Vol- 11.18.15 # Boosting/unboosting in debug->freq just froze the player 11.19.30 # but the click is not always reproducible from WPS and vol change 11.20.42 # ok. please go back to the dev build then 11.21.12 # oh, on the dev build, can you do one other test? enable "pause/resume on headphone unplug/plug" in the settings/playback stuff 11.21.17 # and see if that works 11.22.59 # <__Bilgus> slowing down greylib seems to have quelled the worst of it 11.24.40 # <__Bilgus> spoke too soon crashed on fire 11.27.30 # speachy : both pause and pause/resume work 11.27.52 # ok, thank you. there's a bug ticket claiming they don't. I can't recreate it either. 11.31.46 # __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.59 # *are they 11.32.19 # <__Bilgus> johnb who knows 11.32.24 # :-) 11.32.26 # johnb2: it's an OLED, so use will age the display pixels. brighter == more age. basic physica, alas. 11.32.42 # <__Bilgus> extra brightness on an OLED will always make it age faster 11.33.44 # So I better get the other screen mounted soon, instead of maxing contrast and brightness 11.34.08 # <__Bilgus> 10000 hrs 11.34.30 # <__Bilgus> where did the rest of my sentence go 11.36.06 # <__Bilgus> I bet lifetime is probably 10000 hrs at best anyways 11.36.32 # the 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.07 # there's no shortage of 128x64 SSD1306-based OLED units out there.. :) 11.37.42 # But I am not sure if I was able to replace it, if needed ;-) 11.37.56 # <__Bilgus> my 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.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.27.59 Quit __Bilgus (Ping timeout: 245 seconds) 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 # <__Bilgus> speachy 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.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.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.31 # __Bilgus: ...lovely 16.48.58 Quit JanC (Ping timeout: 244 seconds) 16.50.19 Join JanC [0] (~janc@lugwv/member/JanC) 17.04.48 Quit JanC (Remote host closed the connection) 17.05.19 Join JanC [0] (~janc@lugwv/member/JanC) 17.27.28 # Build Server message: New build round started. Revision 06e9abc, 280 builds, 8 clients. 17.41.22 # __Bilgus: the CPU load % you were reporting for greylib, how is that derived? 17.43.53 # Build Server message: Build round completed after 984 seconds. 17.43.53 # <__Bilgus> its the difference between time taken to display wireframe versus greylib I believe 17.43.55 # Build Server message: Revision 06e9abc result: All green 17.46.11 # <__Bilgus> looking at the ADC code I think an interrupt might help here 17.46.39 # <__Bilgus> decouple the read_data command from running the adc 17.47.01 # it is does use an IRQ...? 17.47.05 # s/is// 17.47.22 # <__Bilgus> theres something abou polling the KEY data so no interrupt needed 17.47.54 # key data is polled in interrupt context (ie system tick handler) 17.48.45 # it 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.32 # so we effectively lag input and battery by 1 tick. 17.49.44 # (ie 10ms) 17.52.33 # <__Bilgus> I don't think we know what actually feeds the button array then 17.54.00 # <__Bilgus> I figured the KEY_INT was driving through the button matrix 17.56.15 # it 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.30 # a single GPIO, that is 17.57.21 # <__Bilgus> we'd just kick it off then 17.58.13 Join meatloaf [0] (~ambassado@2601:246:4400:b3c0:7593:e6ad:5904:25dd) 17.58.42 # I wonder if instead of constantly having the ADC sampling, you mean? 17.59.17 # <__Bilgus> I'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 # <__Bilgus> if we drop below the threshold on button press we can use that falling sig to kick off the adc 18.00.22 # <__Bilgus> then we just keep a few state vars and last sample tick 18.00.42 # might 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 # <__Bilgus> possible but thats where pullups come in 18.01.37 # we can't power down the ADC so I don't really see this making much of a difference. 18.03.07 # hmm. we have peak stack reporting, right? 18.03.29 # <__Bilgus> maybe but I figure it removes some load to not be doing adc interrupts when unneeded 18.04.00 # <__Bilgus> yes? 18.04.44 # oh, 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 # <__Bilgus> oh short circuit them? 18.06.12 # so only initiate sampling if GPIO141 is asserted, and when it deasserts.. BTN_NONE 18.07.11 Quit lebellium_ (Quit: Leaving) 18.08.06 # <__Bilgus> I'll throw together a gpio sampler for the debug menu 18.08.33 # I need to see about reporting the irq stack watermark 18.14.41 # I don't like that we hang. audio dropout sure, but hang? is it a deadlock? a non-panic crash? 18.14.54 # stuck 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.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.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.01.10 # huh, 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.11 # and the first C function sucks down 32 bytes. 21.04.39 # make that 50 21.05.55 Quit pamaury (Ping timeout: 240 seconds) 21.08.01 # counting from the beginning works better. 356 bytes after bootup. 21.09.19 # 372 after USB hotplug.. 21.09.44 Join _BILGUS [0] (41ba23be@65.186.35.190) 21.10.47 Quit sakax (Quit: Leaving) 21.10.53 # <_BILGUS> so are you counting wrong or is it ovflow? 21.12.16 # I was counting wrong. well, not "wrong" per se but not every address on the stack gets written to 21.14.28 # my build has full reclocking, changes that explicltly disable the UARTs, and... fire's still running 30 seconds later. 21.17.01 # this isn't crashing on me. 21.18.42 # still going.. 21.22.46 # still going... 21.23.28 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 21.37.05 # Build Server message: New build round started. Revision 8dadce5, 280 builds, 8 clients. 21.38.12 # <_BILGUS> cool does it still click in your ear? 21.38.20 # nope. fire's still going. 21.38.28 # it's what's building now 21.38.46 # (plus re-enabling the reclocking) 21.38.53 # <_BILGUS> I'm adding gpio to the debug menu atm 21.39.20 # <_BILGUS> so uart like for serial? 21.39.37 # I 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.41 # yeah, serial output. 21.40.15 # <_BILGUS> oh I already added the pieces for scrolling 21.40.23 # oh awesome. :) 21.40.35 # didn't know how to do it so I was actually looking it up 21.40.38 # <_BILGUS> yeah it gets annoying quick having cut off data 21.40.48 # <_BILGUS> check out the clip+ one 21.41.04 # <_BILGUS> well + zip .... 21.41.47 # wonder if high load (or high lcd update rate) was inducing noise on the floating UART lines 21.43.11 # <_BILGUS> or they just need to be forced to input with a pullup 21.43.24 # interrupts weren't turned on though.. so none of this should have mattered. 21.44.05 # but 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.32 # I was able to crash the player within seconds before and now it's still going. 21.45.13 # when 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 # <_BILGUS> it works fine in OF so I guess possible but more probably we have a shoddy setup 21.46.26 # I don't think the OF reclocks at all, if the battery life is any indication 21.46.39 # <_BILGUS> not that I could point to the specific instance but it all starts smelling like shit 21.47.16 # <_BILGUS> I'm dying for more documentation it sucks having to test to figure out values 21.47.41 # (or heck, the kernel sources for the OF..) 21.47.54 # (and probably more importantly, uboot) 21.50.13 # _BILGUS: but hey, you "enjoy" this sort of thing... :D 21.50.40 # <_BILGUS> indeed but it still is nice to have something to check 21.52.10 # yeah. a lot of unnecessary effort. 21.52.25 # Build Server message: Build round completed after 919 seconds. 21.52.27 # Build Server message: Revision 8dadce5 result: 5 errors 0 warnings 21.52.59 # grrr. 21.53.35 # <_BILGUS> hmm no changing on the gpio or the actual direction I wonder if the docs lie 21.54.36 # <_BILGUS> nope just me being dumb\ 21.55.34 # I need to fix the mikmod crash 21.55.54 # there's a missing nullptry check somewhere 21.56.05 # in the instrument/etc display screens 21.56.48 # Build Server message: New build round started. Revision 748133c, 280 builds, 8 clients. 21.56.59 # there, that'll fix the x3 bootloader. 21.59.41 # <_BILGUS> so no gpio activity on the button presses but it gets all kinds of activity when the hold button is switched 22.00.11 # <_BILGUS> gonna 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.27 # Build Server message: Build round completed after 940 seconds. 22.12.29 # 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 # <_BILGUS> Ok So I am correct KEY_INT does trigger when a button is pressed 22.40.52 # <_BILGUS> PORT E pin 13 23.03.39 # <_BILGUS> and I think we can now do multiple buttons with at least some buttons 23.04.07 # <_BILGUS> play back option all toggle another gpio it appears 23.07.18 # 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.11 # Build Server message: Build round completed after 952 seconds. 23.23.12 # Build Server message: Revision 63e6aec result: 3 errors 0 warnings 23.41.49 Quit _BILGUS (Remote host closed the connection)