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).

#rockbox log for 2017-10-08

00:04:28 Quit pamaury (Ping timeout: 258 seconds)
00:13:22 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:16:12 Join kugel [0] (~kugel@rockbox/developer/kugel)
00:16:22 Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 56.0/20170926190823])
00:24:29 Quit __builtin (Ping timeout: 240 seconds)
00:25:58 Join __builtin [0] (~xray@rockbox/developer/builtin)
00:37:26 Quit ZincAlloy (Quit: Leaving.)
01:25:34 Quit _meg (Ping timeout: 240 seconds)
01:26:01 Join _meg [0] (~notsure@
01:39:10 Join Strife1989 [0] (
01:42:29 Quit Strife89 (Ping timeout: 240 seconds)
01:45:52***Saving seen data "./dancer.seen"
02:09:57 Quit ender` (Quit: If man could be crossed with the cat it would improve man, but it would deteriorate the cat. — Mark Twain)
02:41:43 Quit dovber (Ping timeout: 246 seconds)
02:52:21__builtinyay, Duke Nukem's sound works properly now :)
02:53:23__builtinunaligned accesses breaking everything again
03:25:47AldemHail to the king
03:27:55__builtinonly some sounds, though
03:28:00__builtinothers are mysteriously absent
03:28:14__builtinprobably more alignment issues
03:41:22__builtinhmm, I suppose I can steal linux's alignment trap code to track those down
03:45:54***Saving seen data "./dancer.seen"
03:47:20__builtinok, looks like the fault is working properly
04:09:06__builtinbut it's not displaying a panic screen like it should :(
04:09:35__builtinany ideas why?
04:12:55 Join Strife89 [0] (
04:13:07 Quit Aldem (Read error: Connection reset by peer)
04:13:59 Quit Strife1989 (Ping timeout: 240 seconds)
04:16:15 Join Aldem [0] (~Aldem@unaffiliated/aldem)
04:19:46 Join Bilgus [0] (~Bilgus@unaffiliated/bilgus)
04:23:00 Quit _Bilgus (Ping timeout: 240 seconds)
04:23:44 Quit Aldem (Read error: Connection reset by peer)
04:24:58 Join Aldem [0] (~Aldem@unaffiliated/aldem)
04:27:20__builtingreat, looks like the fault is in tlsf
05:45:55***Saving seen data "./dancer.seen"
06:05:57 Quit [7] (Ping timeout: 258 seconds)
06:06:49 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
06:10:34 Quit jhMikeS (Ping timeout: 240 seconds)
06:12:04 Quit _meg (Ping timeout: 240 seconds)
06:15:32 Join _meg [0] (~notsure@
06:21:05 Join jhMikeS [0] (
06:25:42 Quit jhMikeS (Ping timeout: 255 seconds)
06:30:52 Quit TheSeven (Ping timeout: 258 seconds)
06:31:23 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
07:05:21 Quit alexweissman (Remote host closed the connection)
07:06:15 Join alexweissman [0] (
07:45:56***Saving seen data "./dancer.seen"
07:59:27 Quit alexweissman (Remote host closed the connection)
08:39:28 Quit dys (Ping timeout: 248 seconds)
09:01:15 Quit JanC (Killed ( (Nickname regained by services)))
09:01:20 Join JanC [0] (~janc@lugwv/member/JanC)
09:08:36 Join dovber [0] (~dovber@2600:8801:3180:d1:beee:7bff:fee3:335f)
09:46:00***Saving seen data "./dancer.seen"
10:07:39 Join ender` [0] (
10:10:42 Join lebellium [0] (
10:10:56 Quit _meg (Ping timeout: 260 seconds)
10:11:28 Join petur [0] (~petur@rockbox/developer/petur)
10:14:34 Join _meg [0] (~notsure@
10:34:51 Join jhMikeS [0] (
10:59:49 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
11:22:59lebelliumpamaury: what is "vol: X dB" for in the debug menu?
11:24:51pamaurylebellium: it's the digital volume, this will go away when we have proper handling of 32-bit samples in the dsp. jhMikeS is working on it
11:25:28lebelliumso it's supposed to stay at 0 dB?
11:27:10pamauryI think the debug menu itself is broken with respect to this value, it displays 0 unless you change it. I should remove it so that no one asks me about it :-p
11:28:18lebelliumwell, normal users shouldn't go to the debug menu
11:28:42lebelliumyou only need to bother with my questions :P
11:29:57pamaurybasically as long as you don't touch the value of vol, it stays at 0. When you touch it, it actualls sets it to this value. Be careful, it may result in a high volume.
11:30:37pamauryAlso the way the volume works in that on the high-volume range I use the analog volume, and start from about -10dB I start using the digital volume, something like thta
11:30:51lebelliumI hate this *panic* invalid pcm alsa volume screen when I go too up :P
11:34:37pamauryit's a debug menu, you are not allowed to complain :-p
11:35:00lebelliumthat's right
11:46:04***Saving seen data "./dancer.seen"
11:46:46 Join CH23 [0] (56580a02@gateway/web/freenode/ip.
11:51:28lebelliumpamaury: I think the "acoustic mode" is closer to the Sony volume curve but at the same time it goes louder and is clipping at max volume
11:54:07CH23Bilgus: every time i unplug the clip from my laptop it gives me a *panic*. currently on Version: afbae17M-171008 , but it's been doing this for a while now.
11:54:31CH23this is when using internal OS
11:57:40pamaurylebellium: most Sony's clip at high volume anyway
11:58:15lebelliummax volume in OF is the same as in Rockbox with acoustic=off but the volume curve is more like acoustic=on
11:58:18lebelliumit's strange
11:59:04 Quit jhMikeS (Ping timeout: 240 seconds)
11:59:31CH23it doesn't do this on bootloader v4.0, so it might be multiboot related
11:59:42pamaurymax volume in OF is not handled the same as in Rockbox. Rockbox makes no attempt to prevent clipping at the highest volume because it can't. I think the OF stops before clipping
11:59:54pamauryat least on pre-A10 devices
12:01:07 Join jhMikeS [0] (
12:01:43pamaurybut I'm not sure about acoustic vs non-acoustic
12:02:18 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
12:05:31 Quit jhMikeS (Ping timeout: 258 seconds)
12:06:30lebelliumvolume 10/30 in OF is more or less like -15 or -20dB in Rockbox with acoustic=off,
12:07:17lebelliumso it's a weird volume curve
12:07:39lebelliumyou have a very large quiet range from -100dB to -20dB
12:09:17 Part robertd1
12:09:31 Join robertd1 [0] (~root@
12:21:10pamauryiirc there is a mistake in my digital volume code. It goes 2dB steps are a time instead of 1dB
12:50:32robertd1strange fatal error: bitmaps/rockboxicon.h: No such file or directory
12:52:45pamauryrobertd1: what are you building? try "make clean"
12:54:32robertd1hi Pamaury. I was building the bootloader thanks
12:56:09robertd1yes, that did it
12:58:12CH23speaking of bootloader, i just build one, is 'bootloader-clipplus.sansa' flashable? do i just rename it and then move it to the root of my device?
13:06:00pamauryCH23: no it doesn't work like that
13:08:47pamauryone has to use mkamsboot to create a flashable firmware
13:09:28pamauryI would advise extra caution, if you brick, it's hard to recover, usually someone knowledgeable creates it and tests it and then we release it
13:19:48 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
13:31:30CH23pamaury: would i still be able to recover via the hardware shorting?
13:33:21pamauryCH23: I think so but you better ask the people that actually know the clip+ ad friends
13:34:12CH23i'm just going to try, there's no better way to learn. yolo and all.
13:46:06***Saving seen data "./dancer.seen"
13:46:47CH23nailed it. hah.
13:51:55CH23Bilgus: i have now tested the multibootloader using latest patches #1552, #1557, #1558, on today's build, with OF 01.02.16, as well as using today's build for firmware, using patches #1556, #1613, and on unplugging the usb cable i still get a kernel panic
13:58:25robertd1i dont know if it is a placebo effect but the walkman sounds much better with rockbox installed
14:16:58 Quit _meg (Ping timeout: 240 seconds)
14:19:54 Join _meg [0] (~notsure@
14:26:50 Join Bilgus_PH [0] (41ba23be@gateway/web/freenode/ip.
14:27:15CH23it seems that the kernel panic only occurs when multiboot loader is used, in combination with multiboot firmware, running on the internal memory
14:27:52CH23multiboot firmware on internal memory with regular bootloader has no effect
14:27:58Bilgus_PHCH23: I'm pretty sure the only way the bootloader could cause a panic would be in the bootloader USB mode
14:28:24Bilgus_PHthe multiboot firmware OTOH yes I could see that
14:29:54Bilgus_PHbut that has to do with some dismount stuff, I have observed that as well with loading the database but its kinda a kludge atm anyways thats why its pending a re-write
14:30:33CH23if there's anything i could help you with, just let me know
14:30:59Bilgus_PHNow the question would be do you see it when using the multiboot bootloader and a non multiboot FW on internal memory..\
14:31:36CH23i'll test it
14:32:35Bilgus_PHAs far as the multiboot FW goes I'm waiting for JhMikeS to get time as I don't have the skills or knowledge he does
14:33:01Bilgus_PHand that filesystem is his baby as well amongst other things
14:34:49Bilgus_PHBtw CH23 thanks for testing its always good to have more eyes on it :)
14:35:33CH23i can't program but i still want to contribute some of my time into rockbox
14:37:15CH23and considering i paid ridiculously little for the 2 clip+'s i have, i wouldn't mind one getting bricked too much
14:37:26Bilgus_PHMANUALS lol
14:37:58CH23manuals sounds like something i could write.
14:39:34Bilgus_PHthe fomat for them is a little funky like a mix between html and qbasic its called Latex not too bad though
14:40:28CH23never worked with LaTex but i'm aware of its existence
14:40:49CH23also yes, with default firmware on multibootloader it also panics
14:45:21Bilgus_PHok I'll look into it when I get home I'm not sure how it could since the bootloader loads firmware and then transfers control to the firmware
14:46:27Bilgus_PHHMm Ch23 could you build a bootloader form the current DEV like basically what you just did but without adding patches and try it then
14:47:14CH23i did
14:47:46Bilgus_PHassuming you created a new branch when you made the stuff so you don't lose what you already did you can type 'git status' then git add <files> it lists at top
14:49:11Bilgus_PHand then git commit and put a small message then <ctrl> O and <ctrl> X and finally git checkout master and git checkout -b <your new branch>
14:51:53 Quit CH23 (Ping timeout: 260 seconds)
15:02:08Bilgus_PHyeah looking at the as2525 bootloader code once it hits kernel_entry(); it will never return to the bootloader so I'm guessing something else has changed in some ancillary code that is shared with the bootloader
15:08:10 Join CH23 [0] (3e8c895a@gateway/web/freenode/ip.
15:10:48CH23Bilgus_PH: i'm the worst when it comes to branching; instead of stashing changes i delete the entire thing and download it all again
15:11:01CH23i should look into this
15:12:07Bilgus_PHI used to do that too until I learned git
15:12:41Bilgus_PHYou still get into clusters everyonce in a while but its pretty easy
15:13:41Bilgus_PHplus you have a nice repository of everything you've done
15:14:00CH23i made my life easy, i created a few shell scripts to build and install the different things
15:14:53Bilgus_PHyeah I think I saw you firmware building one a while back.. Whatever works :)
15:15:05CH23so one for normal bootloader, one for multibootloader, one for fw, one for multi fw, and then two to only build, not install
15:15:21CH23idk i shouldn't do this because i use up server time for each build
15:19:19CH23i noticed with mkamsboot, that firmware 01-02-18 isn't supported, is there a specific reason for that?
15:19:49Bilgus_PHsomeone didn't test it with that version so didn't put in the header for it
15:20:22Bilgus_PHlike maybe it wasn't out yet or it didn't work
15:25:08 Quit Bilgus_PH (Ping timeout: 260 seconds)
15:31:16 Join Bilgus_PH [0] (41ba23be@gateway/web/freenode/ip.
15:40:18 Quit CH23 (Ping timeout: 260 seconds)
15:46:10***Saving seen data "./dancer.seen"
15:47:18 Join CH23 [0] (3e8c895a@gateway/web/freenode/ip.
15:49:47Bilgus_PHCH23 I'll bb later if you find anything out I'll read it in the logs later on
15:49:52 Quit Bilgus_PH (Quit: Page closed)
15:54:49 Join krabador [0] (~krabador@unaffiliated/krabador)
16:02:24CH23mkamsboot v1.6 is from 2012-02-05, but i don't know what date order that is. the latest clppa.bin is dated 17th of may, 2012, so indeed it was never checked for mkamsboot
16:13:44 Join alexweissman [0] (
16:13:47 Quit alexweissman (Remote host closed the connection)
16:14:04 Join alexweissman [0] (
16:19:18 Join Bilgus_PH [0] (4cf32773@gateway/web/freenode/ip.
16:19:42Bilgus_PHCH23 it is pretty arbritrary to add another FW into the mkams utility
16:20:20CH23half-half expected that.
16:20:33Bilgus_PHyou would just need to test that it actually worked
16:23:42CH23 { MODEL_CLIPPLUS, "01.02.18", "80b547244438b113e2a55ff0305f12c0" },
16:24:02CH23it's in there already?
16:24:47CH23I think it was never updated on the rockbox site
16:26:29Bilgus_PHhuh thats kinda odd oh you downloaded it not built it?!
16:26:51Bilgus_PHI guess that makes sense
16:28:34CH23i don't always build everything :P
16:28:55CH23i expect the site to contain up to date versions of tools
16:29:49Bilgus_PHyeah thats not going to happen there are too many different things to keep track of and several different people in charge of each
16:30:19CH23i'll see if i can build it
16:30:45Bilgus_PHIIRC there are instructions somewhere
16:32:00CH23it's done already.
16:32:46Bilgus_PHnice :)
16:33:56CH23and it works.
16:36:16CH23is it worth rechecking the multi/singleboot stuff?
16:37:21Bilgus_PHwell if it panics on usb pull then yeah
16:38:18Bilgus_PHI'm still not sure how it could hapeen bc the way it loads the FW but you said it doesn't happen with the stable bootloader
16:38:49Bilgus_PHso I guess build the DEV version of the bootloader w/o the multiboot patches and see if it still happens
16:39:46CH23i think what happens is that the multifirmware hooks into the multibootloader and on unplug it is confused on which memory it operates
16:40:46CH23i have nothing to back up this idea
16:40:50Bilgus_PHwell see I can see it with the firmware but you siad it happens with the multibootloader and regular FW on internal memory
16:41:27CH23i'll rerun all cases to make sure i wasn't mixing up things
16:41:31Bilgus_PHthe bootloader literally just loads the firmware into memory
16:41:40Bilgus_PHand then its done
16:41:51Bilgus_PHcontrol never ever returns to it
16:42:43Bilgus_PHso all I can think is that something has changed in the initial setup from the bootloader, something I didn't change but has changed in the code base
17:15:06CH23...and now it all works? not quite sure why.
17:20:58Bilgus_PHwell now try readding the multiboot patches and see if it stilll happens if you would
17:21:10 Quit krabador (Remote host closed the connection)
17:21:29Bilgus_PHbasically the multiboot bootloader and a regular FW on internal drive
17:22:13Bilgus_PHI can totally see the multiboot FW causing it no matter which bootloader because its a WIP
17:22:40CH23i tried the following combinations: mbl+mfw , mbl+rfw , rbl+rfw , rbl+mfw (all internal)
17:23:48CH23mbl = multi boot loader, mfw = multi firmware, rbl = regular boot loader, rfw = regular firmware
17:24:09Bilgus_PHok so maybe it happens because when you plug the usb while mfw is on the sd card it isn't quite initialized by the time it tries to read again
17:24:58Bilgus_PHfigure when you plug the usb the sdcard is unmounted from the fw and mounted for the USB
17:25:18CH23it happened when using the internal flash
17:25:42Bilgus_PHnow the actual firmware resides in the RAm but maybe it tries to update something on disk and its not expecting it to be uninitialized
17:26:08Bilgus_PHcould just be random
17:26:09CH23before this i used the bootloader firmware you uploaded, from february i believe
17:26:27CH23it happened every time, on both of my devices
17:26:44Bilgus_PHI have changed a few things since feb but nothing that really affected the operation
17:27:04Bilgus_PHtry putting it backl and see if it happens again maybe?
17:27:15CH23yeah trying to find yours again
17:28:58Bilgus_PHno thank you :)
17:31:32CH23whatever happened between your version and the current one, it was enough to make it not panic
17:31:47__builtinah, I think I found the bug in duke :)
17:33:54CH23this is multibootfirmware 2017-10-08 + multibootloader 2017-02-10 on internal, no SD present
17:34:56Bilgus_PHok not sure why but it could still be something that changed in another part of the codebase but if you can't reproduce it with the current patch I'll call it good :)
17:35:34Bilgus_PH__builtin: more unaligned memory accesses?
17:35:57__builtinkind of
17:36:22__builtinIt was my fault this time, I *thought* I was fixing the unaligned accesses but I changed some things I shouldn't have
17:36:33Bilgus_PHIt seems like duke would be a very mature codebase is this just because its running on ARM?
17:36:36Bilgus_PHah ok
17:37:23__builtinsee line 731-732
17:37:45__builtinI shouldn't have changed those two lines, since they were just reading a byte value
17:38:44__builtinIf I can just figure out how to make the device display the fault PC and address when the alignment fault fires, life would be so much easier
17:41:58Bilgus_PHdoesn't all that conversion from BE to LE make it slow?
17:43:21__builtinyes, but it's necessary
17:43:36__builtinthough it's not converting, per se
17:43:49__builtin(the data's already little-endian in memory)
17:43:59CH23i'll test one more thing, because, if people rely on your build, and use current dev rockbox build, it might be good to update the mediafire file maybe Bilgus_PH
17:45:26Bilgus_PHwell plan to have the stuff on gerrit in main soon so probably not a big deal but I may as long as you can confirm it is fixed
17:46:11***Saving seen data "./dancer.seen"
17:46:28CH23so using current multiboot firmware, on the multibootloader that you uploaded, will panic. using current normal firmware, on the multibootloader you uploaded, works fine.
17:46:28Bilgus_PH__builtin: oh i see you are shifting the address so the code calls the right memory location
17:47:01__builtinyeah, it's just to prevent it from accessing an unaligned long or short address
17:47:16__builtin"unaligned" byte accesses are OK
17:49:42__builtin(because they're always byte-aligned, I suppose)
17:52:06Bilgus_PHCH23 the MFW isn't really a issue thats really not the final code the bootloader OTOH is important
17:53:35CH23OTOH meaning?
17:53:54Bilgus_PHon the other hand
17:54:42Bilgus_PHnow does the MFW panic if its on the internal memory?
18:01:18__builtincrap, Timidity isn't closing its files properly :(
18:01:29CH23the plot thickens. they both panic again, using todays dev+multi for both bootloader and firmware
18:01:48CH23i wonder if it's due to my laptop now
18:12:28__builtinaha, I can blame stdio_wrapper :)
18:13:22__builtin\o/ music works :)
18:18:20__builtinon target, too! :D
18:20:26CH23Bilgus_PH: what do error codes mean to you?
18:35:41CH23the conclusion of this whole thing: multiboot firmware should only go on micro SDs, all else is fine.
18:41:31Bilgus_PHwell the MFW has a wip filesystem rewrite so not entirely unexpected
18:44:09CH23i'm very happy with it as it is, there's not really a reason to use the MFW internally anyway
18:45:10CH23as long as the MBL works as it should
19:01:30 Quit CH23 (Quit: Page closed)
19:37:39 Quit diox (Read error: Connection reset by peer)
19:42:47 Join diox [0] (
19:46:15***Saving seen data "./dancer.seen"
20:03:17 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
20:07:21 Join krabador [0] (~krabador@unaffiliated/krabador)
20:35:34 Quit krabador (Quit: Leaving)
20:44:44 Quit diox (Ping timeout: 264 seconds)
20:46:34 Join wodz [0] (
20:46:40wodzpamaury: ping
20:54:14pamaurywodz: pong
20:55:40pamaurywodz: I have a question regarding atjboottool. Since firmware files contains some informations in the header that might be important, it seems like when you unpack/repack a firmware, it should be kept. Can you tell me what you plan to do when repacking atj firmware? Will you throw away all/most of the OF files or do you want to keep them?
20:55:45wodzpamaury: Nothing actually. I thought read32_cop() is failing for no apparent reason on ATJ but it turned out this is due to my experiments with MMU.
20:58:36 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
21:01:25wodzpamaury: That is good question. If we want dualboot we should patch BRECF* or MBRCF* or SYSCFG.BIN. I can't remember size restrictions now. If we don't want dualboot we can put bootloader instead of SYSCFG.BIN to be c
21:01:57wodzpicked up by rom bootloader.
21:05:11 Quit LjL (Quit: You can't break me, for I have no spine)
21:05:14 Join Strife1989 [0] (
21:08:09 Quit Strife89 (Ping timeout: 255 seconds)
21:15:04 Join LjL [0] (~ljl@unaffiliated/ljl)
21:19:53 Join Strife89 [0] (
21:24:20 Quit Strife1989 (Ping timeout: 264 seconds)
21:46:18***Saving seen data "./dancer.seen"
21:57:14 Quit alexweissman (Remote host closed the connection)
21:57:36 Join alexweissman [0] (
22:00:35 Join Ruhan [0] (uid76353@gateway/web/
22:06:03 Quit wodz (Quit: Leaving)
22:08:57 Quit Strife89 (Ping timeout: 240 seconds)
22:09:09 Join Strife89 [0] (
22:28:41 Join Halamix2 [0] (~Halamix2@unaffiliated/halamix2)
23:46:08 Quit petur (Remote host closed the connection)
23:46:19***Saving seen data "./dancer.seen"
23:54:27 Quit pamaury (Ping timeout: 240 seconds)
23:58:24 Join jhMikeS [0] (

Previous day | Next day