00:05:03 | | Quit petur (Remote host closed the connection) |
00:05:34 | | Quit mikroflops (Ping timeout: 240 seconds) |
00:06:06 | Bilgus | i think it still showed the same |
00:10:32 | | Join mikroflops [0] (~yogurt@178.174.137.46) |
00:13:54 | man_in_shack | ok |
00:16:16 | man_in_shack | lsusb says "Sandisk Corp." and block device reports as " UNDEF " |
00:16:28 | man_in_shack | the UNDEF is proably an indicator of death |
00:31:12 | Bilgus | what does sudo fdisk -l && lsblk report? |
00:34:42 | | Quit ender` (Quit: In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better.) |
00:41:27 | Bilgus | oh sorry just saw you already did |
00:43:53 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
00:51:12 | | Quit man_in_shack (Ping timeout: 248 seconds) |
01:00 |
01:04:32 | | Quit pamaury (Ping timeout: 248 seconds) |
01:04:53 | | Quit Tony_ (Ping timeout: 260 seconds) |
01:09:58 | | Join man_in_shack [0] (~chat@unaffiliated/man-in-shack/x-4279753) |
01:17:33 | | Join Tony_ [0] (ae3638f0@gateway/web/freenode/ip.174.54.56.240) |
01:28:45 | | Quit krabador (Quit: Leaving) |
01:47:29 | *** | Saving seen data "./dancer.seen" |
01:59:13 | | Quit Ruhan (Quit: Connection closed for inactivity) |
02:00 |
02:33:04 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
02:36:14 | | Quit JdGordon_ (Ping timeout: 248 seconds) |
02:48:02 | | Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman) |
03:00 |
03:03:56 | | Quit dys (Ping timeout: 264 seconds) |
03:13:14 | | Quit Aldem (Read error: Connection reset by peer) |
03:18:06 | | Quit prof_wolfff (Ping timeout: 260 seconds) |
03:19:15 | | Join prof_wolfff [0] (~prof_wolf@120.red-83-54-195.dynamicip.rima-tde.net) |
03:19:23 | | Join Aldem [0] (~Aldem@unaffiliated/aldem) |
03:30:26 | __builtin | pamaury (logs): yes |
03:30:40 | __builtin | I see, so ARM926 wouldn't support it then |
03:30:46 | __builtin | too bad :( |
03:31:02 | __builtin | at least I can set the A bit and root out the crashes |
03:38:40 | | Quit _meg (Ping timeout: 255 seconds) |
03:39:22 | | Join _meg [0] (~notsure@211.25.203.45) |
03:47:14 | | Join saratoga [0] (123e11e0@gateway/web/freenode/ip.18.62.17.224) |
03:47:33 | *** | Saving seen data "./dancer.seen" |
03:47:35 | saratoga | Bilgus: I get 250 MHz needed for real time decode of my AAC-HE test file |
03:47:57 | saratoga | i tried unboosted, its still running :) |
03:49:19 | Bilgus | on the fuze+? |
03:50:03 | saratoga | yeah |
03:50:17 | saratoga | damn it, plugin has this bug where it doesn't show the speed if the plugin finishes with the screen off |
03:50:24 | saratoga | so i lost the results for the unboosted test |
03:52:01 | saratoga | aac in general is really slow on the fuze |
03:52:12 | saratoga | maybe slow RAM? |
03:53:50 | Bilgus | yeah its weird that locking the frequency even at 64 mhz and it works properly so IDK whats up but i'll look into it more |
03:55:41 | saratoga | if you have the test plugins configured, double check that the speed is correct for unboosted |
03:56:01 | saratoga | long select the file and run it with boost enabled, and with the boost disabled (test plugin can do both) |
03:56:11 | saratoga | should make it obvious if something is wrong |
03:59:02 | | Quit man_in_shack (Read error: Connection reset by peer) |
04:00 |
04:00:09 | | Join man_in_shack [0] (~chat@unaffiliated/man-in-shack/x-4279753) |
04:01:51 | | Quit CrashBash-Kun (Read error: Connection reset by peer) |
04:03:26 | saratoga | strange that it is so slow given the 16KB cache and the ARM9e core |
04:19:53 | | Join advcomp2019__ [0] (~advcomp20@unaffiliated/advcomp2019) |
04:22:34 | | Quit advcomp2019_ (Ping timeout: 240 seconds) |
04:43:51 | | Quit scorche|sh (Ping timeout: 260 seconds) |
04:45:44 | | Join scorche|sh [0] (~scorche@squisch.net) |
04:45:45 | | Quit scorche|sh (Changing host) |
04:45:45 | | Join scorche|sh [0] (~scorche@rockbox/administrator/scorche) |
05:00 |
05:05:37 | | Quit Strife89 (Ping timeout: 255 seconds) |
05:06:06 | | Join Strife89 [0] (~quassel@adsl-98-80-181-168.mcn.bellsouth.net) |
05:47:34 | *** | Saving seen data "./dancer.seen" |
06:00 |
06:06:07 | | Quit TheSeven (Ping timeout: 258 seconds) |
06:06:31 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
06:27:31 | | Quit TheSeven (Ping timeout: 246 seconds) |
06:27:43 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
07:00 |
07:47:38 | *** | Saving seen data "./dancer.seen" |
08:00 |
08:28:03 | | Join ender` [0] (krneki@foo.eternallybored.org) |
08:44:57 | man_in_shack | rockbox to the rescue! |
08:46:27 | man_in_shack | my dad has given me an old android phone and rockbox works nicely on it :D |
08:46:34 | man_in_shack | https://www.ebay.com.au/itm/sansa-fuze-/272877700719? << means i don't need to buy these now :P |
08:49:48 | alexbobp | sansa fuzes are awesome though :P rockbox for android is a different experience |
08:49:51 | alexbobp | but long as you're happy! |
08:51:21 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
08:51:36 | man_in_shack | yah they awesome but also cost more than $0 |
08:51:38 | | Join petur [0] (~petur@91.183.48.77) |
08:51:38 | | Quit petur (Changing host) |
08:51:38 | | Join petur [0] (~petur@rockbox/developer/petur) |
08:51:54 | man_in_shack | also bluetooth audio is nice |
08:52:03 | man_in_shack | one fewer cable to run |
09:00 |
09:02:48 | | Join JanC_ [0] (~janc@lugwv/member/JanC) |
09:03:43 | wodz | one more battery to charge :P |
09:04:05 | | Nick JanC is now known as Guest86327 (~janc@lugwv/member/JanC) |
09:04:05 | | Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) |
09:05:11 | | Quit Guest86327 (Ping timeout: 260 seconds) |
09:05:33 | man_in_shack | wodz: not really. running a dedicated music player in my car one way or another |
09:05:48 | man_in_shack | has been sansa clip+ but the flash in it is dead |
09:46:13 | | Join p3tur [0] (~petur@rockbox/developer/petur) |
09:46:13 | | Quit petur (Read error: Connection reset by peer) |
09:47:40 | *** | Saving seen data "./dancer.seen" |
09:54:53 | | Nick p3tur is now known as petur (~petur@rockbox/developer/petur) |
10:00 |
10:03:09 | | Quit tchan (Quit: WeeChat 1.6) |
10:22:32 | | Quit dfkt (Quit: SIC GORGIAMVS ALLOS SVBJECTATOS NVNC.) |
10:23:05 | | Join dfkt [0] (~dfkt@unaffiliated/dfkt) |
10:29:52 | | Quit mc2739 (Ping timeout: 248 seconds) |
10:29:54 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
10:35:43 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
10:40:51 | | Quit Moarc (Ping timeout: 260 seconds) |
10:42:12 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
10:49:33 | | Quit pamaury (Ping timeout: 264 seconds) |
10:51:59 | | Join p3tur [0] (~petur@rockbox/developer/petur) |
10:54:43 | | Quit petur (Ping timeout: 255 seconds) |
11:00 |
11:19:41 | | Nick p3tur is now known as petur (~petur@rockbox/developer/petur) |
11:23:29 | | Join PimpiN8 [0] (~textual@2a02:a454:38ea:1:ed48:8e3f:8a7d:94dc) |
11:35:41 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
11:47:41 | *** | Saving seen data "./dancer.seen" |
12:00 |
12:20:12 | | Join CH23 [0] (4dfa0218@gateway/web/freenode/ip.77.250.2.24) |
12:20:46 | CH23 | is the clip+ recovery mode run from the internal flash, or from the SOC? |
12:26:19 | CH23 | man_in_shack: are you willing to sell me your broken clip+ ? i have some things i want to test |
12:28:28 | wodz | CH23: from SoC rom AFAIK |
12:29:08 | CH23 | wodz: just spoke with dongs, yeah it is. |
12:29:41 | CH23 | dongs, the person. not the body part. |
12:29:46 | | Quit yosafbridge (Quit: Leaving) |
12:30:36 | wodz | CH23: consult pamaury, he tried disassembling recovery mode on amsv2 |
12:31:32 | CH23 | i have most of the info i need; now i just need a matching NAND chip, and broken device. |
12:31:45 | | Join robertd1 [0] (~root@201.242.176.168) |
12:33:48 | wodz | Anyway I am pretty sure recover mode runs from rom and not from nand (there might be 2 recovery modes actually). You can force amsv2 device into recovery mode by shorting nand address lines and creating flash fault. How would it load recovery image then? |
12:33:58 | | Join yosafbridge [0] (~yosafbrid@68.ip-149-56-14.net) |
12:34:48 | CH23 | as i said, it runs from SOC |
12:54:20 | | Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) |
12:54:52 | | Join PimpiN8 [0] (~textual@2a02:a454:38ea:1:ed48:8e3f:8a7d:94dc) |
12:54:57 | | Quit PimpiN8 (Client Quit) |
13:00 |
13:01:04 | | Quit robertd1 (Remote host closed the connection) |
13:11:11 | Bilgus | saratoga pamaury I did the test codec for boost/unboosted at normal, locked 64MHz and Locked 454Mhz the results jive with the observations still not sure what it means though http://forums.rockbox.org/index.php/topic,52018.msg240757.html#msg240757 |
13:17:44 | man_in_shack | <CH23> man_in_shack: are you willing to sell me your broken clip+ ? i have some things i want to test << sure |
13:18:02 | man_in_shack | what country you in? |
13:18:06 | | Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) |
13:18:48 | | Quit TheLemonMan (Client Quit) |
13:20:31 | CH23 | man_in_shack: netherlands |
13:20:51 | man_in_shack | australia here |
13:20:55 | CH23 | oh boy |
13:20:59 | man_in_shack | (: |
13:21:08 | CH23 | that's gonna be heaps in shipping cost |
13:21:14 | man_in_shack | could be |
13:24:41 | | Join robertd1 [0] (~root@201.242.176.168) |
13:26:35 | man_in_shack | au$21.50 shipping |
13:28:59 | CH23 | and how much do you want for the device itself? |
13:36:34 | pamaury | CH23: wodz: I once tried to disassemble the ROM from amsv2 but it's very complicated, I never finished. My impression though was that the ROM supports two modes, one mode where the flash is accessible but does not contain valid code (I guess that's the 900MB partition thing) and one mode where the NAND is not accessible (the 30MB probably-ram-disk) |
13:37:45 | pamaury | but the thing that is not clear to me, and the code is too complicated to follow, is what would happen if you had a valid flash but not formatted. On a related question, we still don't know what exactly is responsible for the flash FTL and if it's possible to recreate/format it. |
13:39:06 | CH23 | previously i pulled a full disk image from my 4gb clip+, when in recovery though? |
13:39:23 | Bilgus | but that doesn't have any of the nand stuff |
13:40:14 | Bilgus | I have those images btw up on the forum and a build with them that allows you to access the 'hidden' part of the drive without recovery mode |
13:41:04 | Bilgus | see basically the sansa OF and rockbox block the first 0xF000 sectors from you to protect the firmware |
13:41:28 | Bilgus | its not special in any way except not being a valid partition |
13:41:50 | CH23 | and that's not writable in recovery |
13:41:58 | Bilgus | sure it is |
13:42:22 | CH23 | isn't that all you need to make it work then? |
13:42:23 | Bilgus | its writable in those special builds that I unblocked it as well |
13:42:44 | Bilgus | It doesn't have anything needed for the nand init |
13:43:35 | CH23 | i'm a bit confused. the recovery is 'directed' from the SOC rom, then gives access to the NAND, right? |
13:43:48 | CH23 | directed/run |
13:44:12 | pamaury | it gives you access to the NAND only if the NAND is accessible |
13:44:31 | pamaury | when the NAND is dead, it seems to switch to this 30MB ram disk |
13:44:47 | pamaury | which we don't know how to use afaik? |
13:44:53 | CH23 | so if you were to completely blank out the NAND, would it still give access? |
13:45:06 | Bilgus | like basically what recovery is for is if you screw the image up and the device no longer boots because bad code but hardware is still working fine |
13:45:45 | Bilgus | it seems the 30MB soesn't persist writes so not sure if its even a ram disk |
13:45:50 | Bilgus | doesn't* |
13:46:09 | CH23 | i want man_in_shack's device to see if i can transplant an equal NAND chip onto it, then via recovery DD an image to it |
13:46:54 | Bilgus | but I could take my device that works now erase the whole drive and it would be a brick.. put the device in 'recovery' write back the image reboot and all would work |
13:47:16 | Bilgus | the equal nand chip is the issue |
13:47:23 | CH23 | maybe not |
13:47:43 | *** | Saving seen data "./dancer.seen" |
13:47:44 | CH23 | the same flash chip was used in the sandisk cruzer 4gb and 8gb drives |
13:47:44 | Bilgus | maybe pigs can fly with enough thrust |
13:47:54 | CH23 | and some others |
13:48:33 | Bilgus | I for one hope thats the case but I'm not sure how likely it is but in theory yes that should work |
13:50:27 | Bilgus | speaking of johnb is going to try brute forcing an image to his readonly clip+ this weekend |
13:50:28 | pamaury | Bilgus: we don't really know what this "ram disk" is for, that's the main problem, and I never was able to figure it out |
13:50:32 | pamaury | but I could have another try |
13:50:36 | CH23 | from what dongs told me, it seems that these sandisk NAND chips aren't writable with those normal NAND flashing modules |
13:50:49 | Bilgus | it doesn't accept writes either so maybe some init that missing |
13:50:50 | CH23 | that's why i had the idea of doing it via recovery |
13:51:34 | Bilgus | CH23 dongs seems far more versed in NAND technology I can't say one way or another |
13:51:44 | CH23 | my readonly clip+ decided that readonly sucks and it's writable again |
13:51:50 | pamaury | well one thing we don't really know is whether those NAND are really NANDS |
13:51:57 | pamaury | or so SD with NAND "interface" |
13:52:06 | CH23 | according to the datasheet they seem to be |
13:52:29 | Bilgus | btw CH23 you said you found that datasheet could you upload it somewhere |
13:52:58 | pamaury | how far dongs went in his exploration of the NAND? Can he read/send command to the NAND chip? |
13:53:16 | Bilgus | also if its writable again why not put the multiboot bootloader on it and never touch the internal memory again? |
13:53:24 | CH23 | https://www.rockbox.org/irc/log-20170822 Bilgus we've been here before ;) |
13:53:59 | CH23 | also i already put the multiboot on it, because within rockbox it was always writable, so i copied it from the µSD card |
13:55:35 | pamaury | what does lsusb shows on recovery? There is the UNDEF with 30 MB, and the other one? |
13:55:44 | Bilgus | I'm saying the actual bootloader? |
13:56:14 | Bilgus | also I can't download that data sheet I'm sure most of that has to do with my lack of chinese |
13:56:27 | CH23 | oh hold on i have a mega link |
13:57:37 | * | pamaury starts looking at the ROM again |
13:58:11 | CH23 | https://mega.nz/#!aVwBDSrT!eDbUOvYfuBnQKY-oUnS_uoQISGvtY2CSoQJeXJD8ElI |
13:58:24 | Bilgus | Thanks |
13:58:31 | CH23 | this is for the SDTNPNAHEM-008G |
14:00 |
14:03:22 | | Quit jhMikeS (Ping timeout: 258 seconds) |
14:05:09 | | Quit deevious (Ping timeout: 255 seconds) |
14:05:21 | | Join deevious [0] (~Thunderbi@193.226.142.214) |
14:13:03 | Bilgus | I always knew NAND was a scary thing to trust your data to but wow |
14:13:11 | man_in_shack | uery CH23 |
14:17:01 | CH23 | i had one SSD fail on me, flash memory is scary stuff |
14:19:30 | wodz | I was scarred when I discovered that perfectly working nand chip reported 4 bits of error in some cells (still corrected by BCH). |
14:28:20 | man_in_shack | :O |
14:28:29 | man_in_shack | so are there docs on writing themes? |
14:30:11 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
14:34:24 | CH23 | https://www.rockbox.org/wiki/CustomWPS man_in_shack there's this |
14:34:46 | | Quit jhMikeS (Ping timeout: 255 seconds) |
14:37:48 | Bilgus | man_in_shack, do be aware while mostly correct there are some errors in there |
14:38:37 | man_in_shack | thanks :) |
14:38:39 | Bilgus | so if you just can't something to work it might not be you |
14:38:47 | Bilgus | ^get* |
14:39:28 | man_in_shack | so next, is there some sort of emulator for testing themes? :D |
14:39:53 | Bilgus | yep |
14:40:51 | man_in_shack | ahha, right at the bottom of the CustomWPS page |
14:41:01 | Bilgus | rasher.dk/rockbox/simulator/">http://rasher.dk/rockbox/simulator/ |
14:41:37 | Bilgus | Not sure how up to date those are but I've not heard any complaints |
14:42:06 | Bilgus | If you have linux we can give you more recent builds |
14:45:35 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
14:47:18 | man_in_shack | well it's for a 320x480 android target ... :P |
14:48:50 | pixelma | hmm, reminds me of my phone, but that one has a too "new" Android version for Rockbox |
14:49:39 | * | man_in_shack lords his 2.3.7 cyanogenmod over pixelma |
14:49:46 | | Join amayer [0] (~amayer@107-1-97-172-ip-static.hfc.comcastbusiness.net) |
14:50:54 | man_in_shack | it's so old it doesn't do google 2-phase auth |
14:51:03 | man_in_shack | so i can't get to play store :P |
14:51:10 | Bilgus | you could use a sim for any target thats 320x240 with a touchscreen |
14:51:40 | man_in_shack | execpt that's half the height :P |
14:52:52 | Bilgus | sorry I ignored the 480 conveniently? |
14:53:02 | man_in_shack | yes, yes you did |
14:53:16 | Bilgus | for that matter grab a bluetooth kb and dev on the device |
14:53:29 | pixelma | you can build a sim for any size RaaA target, I might even have one of the exact resolution from 2 years ago or so (probably cross-compiled for Windows but can't check right now) |
14:53:37 | man_in_shack | pfffffffffffffffffffftttttttttt |
14:53:47 | man_in_shack | ew windows |
14:54:13 | pixelma | back when my phone could still run Rockbox |
14:54:20 | Bilgus | oh yeah you do have linux duh hey you could just build your own |
14:58:50 | CH23 | about that i never got the simulator to work for me |
15:00 |
15:00:30 | man_in_shack | ok |
15:00:38 | man_in_shack | so is there a way to just build the simulator? |
15:01:37 | CH23 | https://www.rockbox.org/wiki/UiSimulator#A_2._Build_UIsimulator |
15:01:43 | man_in_shack | oh target=sdlapp type=sim |
15:02:21 | man_in_shack | i was trying target=android :) |
15:02:58 | CH23 | i believe target should be a number |
15:03:16 | man_in_shack | it also allows the string name |
15:03:27 | CH23 | oh didn't know that |
15:03:28 | man_in_shack | wheeeeee lots of warnings :D |
15:03:38 | man_in_shack | CH23: read the help more :P |
15:03:45 | CH23 | i get 3 error messages |
15:04:19 | CH23 | :/usr/bin/ld: cannot find -lXrandr |
15:04:26 | CH23 | :/usr/bin/ld: cannot find -lXrendr |
15:04:33 | CH23 | collect2: error: ld returned 1 exit status |
15:04:34 | man_in_shack | that's cos you're missing libs :) |
15:04:54 | CH23 | apparently but i have xrandr |
15:06:09 | CH23 | so i'm not sure what libraries those would be |
15:08:01 | | Join dys [0] (~dys@2a01:598:a084:182f:eab1:fcff:fe36:4b0b) |
15:08:25 | | Quit sielicki (Quit: WeeChat 1.9.1) |
15:08:51 | | Join sielicki [0] (~sielicki@unaffiliated/n1cky) |
15:10:56 | man_in_shack | you need libxrandr-dev |
15:11:01 | man_in_shack | and libxrender-dev |
15:14:31 | | Quit sielicki (Quit: WeeChat 1.9.1) |
15:14:59 | | Join sielicki [0] (~sielicki@unaffiliated/n1cky) |
15:18:25 | CH23 | thanks, now it works. |
15:19:18 | | Quit sielicki (Client Quit) |
15:20:05 | | Join sielicki [0] (~sielicki@unaffiliated/n1cky) |
15:25:39 | | Quit sielicki (Quit: WeeChat 1.9.1) |
15:27:36 | | Join sielicki [0] (~sielicki@unaffiliated/n1cky) |
15:46:53 | pamaury | looking at the amsv2 bootloader code, I suspect there is a pin to select whether it boots from internal SD or microsd |
15:47:01 | pamaury | I think it's XPB[5] |
15:47:18 | pamaury | but I'm not entirely sure |
15:47:30 | man_in_shack | ok |
15:47:46 | *** | Saving seen data "./dancer.seen" |
15:49:07 | pamaury | mmh, or maybe not, I see that in rockbox code this is used to determine the "variant" |
15:49:40 | man_in_shack | got simulator running ok now |
15:52:00 | pamaury | I need to disassemble more code |
15:58:56 | | Quit wodz (Ping timeout: 248 seconds) |
16:00 |
16:06:56 | man_in_shack | except i built it wrong :D |
16:07:09 | man_in_shack | no disassemble number pamaury! |
16:11:07 | * | pamaury cannot parse this sentence |
16:12:59 | CH23 | syntax error |
16:15:30 | | Quit CH23 (Quit: Page closed) |
16:23:01 | | Quit Aldem (Remote host closed the connection) |
16:23:30 | | Join Aldem [0] (~Aldem@unaffiliated/aldem) |
16:34:46 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
16:54:24 | | Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-xqzkmtvykiofrgus) |
17:00 |
17:02:55 | | Quit prof_wolfff (Ping timeout: 248 seconds) |
17:16:02 | | Quit petur (Quit: Connection reset by beer) |
17:24:52 | | Quit krabador (Remote host closed the connection) |
17:31:34 | | Quit prg318 (Quit: ZNC 1.6.5 - http://znc.in) |
17:34:07 | | Join prg318 [0] (~prg@deadcodersociety/prg318) |
17:37:34 | | Quit Huntereb (Ping timeout: 248 seconds) |
17:41:38 | Bilgus | ok I'm pretty sure it isn't the fuze+ causing the problems with the AAC-HE file |
17:42:42 | Bilgus | also pamaury for future reference you can't change the CPU speeds in system-target.h the tables in system-imx233.h need to be changed |
17:43:40 | Bilgus | I'm pretty sure the AAC-HE bug is either in the init of the buffer or something to do with watermark |
17:47:48 | *** | Saving seen data "./dancer.seen" |
17:49:06 | | Quit dys (Ping timeout: 240 seconds) |
17:49:06 | pamaury | Bilgus: I wrote the code so I'm pretty damn sure one can ;) |
17:50:57 | pamaury | Bilgus: imx233_set_cpu_frequency looks up the given cpu frequency in the table and simply applies what is listed. imx233_set_cpu_frequency is called only with CPUFREQ_DEFAULT_{SLEEP,NORMAL,MAX} |
17:51:16 | Bilgus | just experienced it first hand I set all defines to IMX233_CPUFREQ_64_MHz in system-target, then it looks up the setting by key in system-imx233 and 454 MHZ is the first one looked at, it then matches and returns the settings for 454 MHZ |
17:51:19 | pamaury | sorry CPUFREQ_{DEFAULT,SLEEP,MAX} |
17:51:50 | pamaury | huh, unless you changed something, there is no way IMX233_CPUFREQ_454_MHz =IMX233_CPUFREQ_64_MHz |
17:54:23 | Bilgus | thats exactly what I did lol |
17:55:29 | Bilgus | I didn't say you were wron I said for future reference |
17:59:03 | Bilgus | now the next question is where CPUFREQ_MAX is actually used |
18:00 |
18:00:35 | pamaury | what did you do? |
18:01:11 | pamaury | Bilgus: firmware/system.c |
18:04:24 | | Join Halamix2 [0] (~Halamix2@unaffiliated/halamix2) |
18:13:01 | | Join Huntereb [0] (~Huntereb@d-209-42-136-145.cpe.metrocast.net) |
18:15:53 | | Join PimpiN8 [0] (~textual@ip51cd65d5.speed.planet.nl) |
18:18:58 | Bilgus | ok so I'm back to not knowing WTF is the problem my clipzip plays the file fine it must be this fuze+ |
18:27:17 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
18:31:18 | | Quit Huntereb (Ping timeout: 258 seconds) |
18:43:29 | | Quit Halamix2 (Quit: Leaving) |
18:46:13 | | Join Huntereb [0] (~Huntereb@d-65-99-122-176.cpe.metrocast.net) |
18:49:19 | | Quit Huntereb (Client Quit) |
18:50:08 | | Join Huntereb [0] (~Huntereb@d-65-99-122-176.cpe.metrocast.net) |
18:51:46 | | Quit robertd1 (Ping timeout: 240 seconds) |
19:00 |
19:03:23 | | Quit Huntereb (Read error: Connection reset by peer) |
19:03:42 | | Join Huntereb [0] (~Huntereb@d-65-99-122-176.cpe.metrocast.net) |
19:04:37 | | Join petur [0] (~petur@78-23-23-252.access.telenet.be) |
19:04:39 | | Quit petur (Changing host) |
19:04:39 | | Join petur [0] (~petur@rockbox/developer/petur) |
19:09:52 | Bilgus | Pamaury I fixed it, moved cancel_cpu_boost(); from before the queue wait to after it and it works fine now the question is how much more time will devices spend boosted with that change or is there some other way to fix it like maybe checking how often the buffer needs filled in a time period |
19:09:53 | | Quit Huntereb (Read error: Connection reset by peer) |
19:10:15 | Bilgus | https://github.com/Rockbox/rockbox/blob/03dd4b92be7dcd5c8ab06da3810887060e06abd5/apps/codec_thread.c#L581 |
19:12:48 | Bilgus | maybe change the queue wait to queue_wait_w_tmo and set it to a hz/2 or so |
19:23:29 | | Join Huntereb [0] (~Huntereb@d-65-99-122-176.cpe.metrocast.net) |
19:29:01 | | Quit Huntereb (Read error: Connection reset by peer) |
19:33:27 | | Join Huntereb [0] (~Huntereb@d-65-99-122-176.cpe.metrocast.net) |
19:36:37 | | Quit Huntereb (Read error: Connection reset by peer) |
19:39:56 | | Join Huntereb [0] (~Huntereb@d-65-99-122-176.cpe.metrocast.net) |
19:42:39 | | Quit michaelni (Ping timeout: 240 seconds) |
19:47:49 | *** | Saving seen data "./dancer.seen" |
19:50:44 | | Quit Huntereb (Read error: Connection reset by peer) |
19:52:45 | | Join dys [0] (~dys@46.183.103.8) |
19:54:33 | | Join Huntereb [0] (~Huntereb@d-65-99-122-176.cpe.metrocast.net) |
19:56:10 | | Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) |
20:00 |
20:03:26 | | Quit Huntereb (Ping timeout: 240 seconds) |
20:09:46 | | Join Huntereb [0] (~Huntereb@d-209-42-136-23.cpe.metrocast.net) |
20:09:55 | | Join prof_wolfff [0] (~prof_wolf@120.red-83-54-195.dynamicip.rima-tde.net) |
20:13:02 | | Join lebellium [0] (~chatzilla@89-93-177-206.hfc.dyn.abo.bbox.fr) |
20:13:20 | Bilgus | ok Fixed the issue g#1693 |
20:13:22 | fs-bluebot | Gerrit review #1693 at http://gerrit.rockbox.org/r/1693 : Move cpu_boost for codec_thread & Fix AAC-HE Fuze+ (others?) by William Wilgus |
20:14:22 | | Quit Huntereb (Ping timeout: 248 seconds) |
20:19:21 | | Join Huntereb [0] (~Huntereb@d-209-42-136-23.cpe.metrocast.net) |
20:29:44 | | Quit Huntereb (Read error: Connection reset by peer) |
20:33:32 | | Join Huntereb [0] (~Huntereb@d-209-42-136-23.cpe.metrocast.net) |
20:43:33 | | Quit _meg (Ping timeout: 240 seconds) |
20:44:14 | | Quit pamaury (Ping timeout: 246 seconds) |
20:46:30 | | Join _meg [0] (~notsure@211.25.203.45) |
20:53:47 | | Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) |
20:57:43 | | Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 56.0/20170926190823]) |
20:57:45 | Bilgus | JhMikeS I see you've done quite a bit of work in codec_thread.c does this ^ look sane to you?? |
21:00 |
21:05:58 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
21:19:36 | | Quit alexweissman () |
21:33:21 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
21:34:09 | | Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) |
21:36:39 | | Quit dys (Ping timeout: 240 seconds) |
21:43:45 | | Join kugel_ [0] (~kugel@rockbox/developer/kugel) |
21:43:59 | | Quit kugel (Ping timeout: 248 seconds) |
21:47:53 | *** | Saving seen data "./dancer.seen" |
22:00 |
22:10:09 | | Quit Huntereb (Read error: Connection reset by peer) |
22:13:30 | Bilgus | Nope I spoke too soon It still happens just happens to have a specific scenario to make it happen you have to start the song and not press any buttons |
22:16:45 | | Join Huntereb [0] (~Huntereb@d-209-42-136-23.cpe.metrocast.net) |
22:19:27 | saratoga | pressing any buttons will enable boost |
22:19:41 | saratoga | to trouble shoot this you may want to disable the GUI boost feature if you haven't |
22:19:46 | saratoga | makes things more reproducible |
22:20:45 | saratoga | oh does it not have it? it felt like it did when i was using the UI |
22:21:17 | Bilgus | It does |
22:21:51 | Bilgus | starting to piss me off |
22:23:44 | | Quit Huntereb (Ping timeout: 255 seconds) |
22:26:15 | | Join Huntereb [0] (~Huntereb@d-209-42-136-23.cpe.metrocast.net) |
22:28:19 | Bilgus | lol and it doesn't do it with a debug build |
22:28:36 | Bilgus | I wonder if its some kind of a race condition |
22:33:02 | * | pamaury now remembers why the amsv2 rom is absolutely horrible to disassemble |
22:36:32 | | Quit Huntereb (Quit: See ya!) |
22:37:21 | | Join Huntereb [0] (~Huntereb@d-209-42-136-23.cpe.metrocast.net) |
22:41:51 | | Join wodz [0] (~wodz@89-79-40-110.dynamic.chello.pl) |
22:41:58 | wodz | pamaury: why? |
22:42:30 | pamaury | just about everything is an object |
22:42:33 | pamaury | like everything |
22:43:46 | pamaury | a buffer? It's an object. A queue? It's vector (object) of buffers (object). An OS queue? It's queue (object) with a semaphore (object) |
22:44:10 | wodz | c++ to the extreme? |
22:44:12 | pamaury | Now I let you imagine what a usb driver can be. I've got at least 10 levels of objects imbrications, and I'm not done |
22:44:30 | pamaury | yeah, very extreme |
22:44:44 | pamaury | with vtables everywhere |
22:45:27 | pamaury | oh also they do things like: A USB queue? It's a OS queue, but let's subclass it just in case, even though we don't actually change it |
22:45:57 | pamaury | They even have an object to represent the hardware registers of USB ?! |
22:46:20 | pamaury | It's too hard to do USB_REG_BLA = x; no no no, USB_REG::get()->write_reg(BLA, x) |
22:46:50 | pamaury | probably there is going to be an allocation in this call for good measure |
22:47:21 | wodz | thats the type of code when PC programmer starts to do embedded with c++ |
22:47:39 | wodz | lets abstract everything attitude |
22:48:10 | pamaury | I swear they even abstract thing that are clearly going to be unique |
22:48:41 | wodz | maybe they did this as RE countermeasure |
22:48:44 | pamaury | I'm sure the main code is: |
22:48:44 | pamaury | (new BootCode())->boot() |
22:49:27 | wodz | I've heard of one product where firmware was intentionally rewritten in c++ to make RE much harder |
22:50:09 | pamaury | well I guess that's successful. But I wonder if it's worth it. I suspect the C++ code is also impossible to follow |
22:52:20 | * | wodz is seriously pissed off by the lack of documentation and comments in qemu |
23:00 |
23:07:24 | saratoga | still don't understand why the fuze+ is so much slower than the same arm core in a fuzev2 |
23:11:38 | pamaury | is it? is it the cpu or the ram? |
23:14:16 | Bilgus | so are you able to reproduce the AAC-HE bug on your fuze+ saratoga? you power on, set screen timeout to on, go to files, choose file and don't press a button and it skips within 5 secs? |
23:14:42 | Bilgus | if its just my device i'm fine with leaving it be at this point |
23:22:15 | | Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") |
23:25:27 | | Quit bray90820 () |
23:26:40 | saratoga | pamaury: not sure what the cause is, but codecs need much higher boost frequency |
23:26:51 | saratoga | Bilgus: can i use any AACHE file? |
23:27:09 | Bilgus | idk maybe? |
23:27:25 | Bilgus | i can link you to the one i've been testing with |
23:27:50 | | Quit amayer (Quit: Leaving) |
23:28:08 | saratoga | my fuze+ apparently just makes loud electronic static noises when powered on |
23:28:18 | saratoga | i don't think i'd ever tried using it for music actually |
23:29:02 | saratoga | something must be wrong with the headphone circuit |
23:29:24 | Bilgus | :| |
23:30:19 | saratoga | yeah sorry |
23:30:23 | saratoga | i just used it for benchmarking really |
23:33:40 | pamaury | saratoga: how do you compare? You mean that even at top frequency the fuzev2 is faster than the fuze+? |
23:34:21 | saratoga | pamaury: test_codec for the same files gives much lower MHZ required for real-time decode |
23:35:38 | pamaury | is it an average frequency of boost/unboost? |
23:35:50 | saratoga | you can do it either fully boosted or fully unboosted |
23:36:13 | saratoga | it decodes the file as fast as possible using either setting, then gives you the % realtime and the frequency required for 100% decode |
23:36:49 | pamaury | I see |
23:36:49 | | Quit Soap_ (Read error: Connection reset by peer) |
23:36:58 | pamaury | is it possible that the core is actually different? |
23:37:16 | pamaury | ie the core in amsv2 is not what we think it is? |
23:37:36 | saratoga | IIRC it was identified from the ARM version bits |
23:37:45 | saratoga | but in any case, it is some kind of ARM9E core |
23:37:50 | saratoga | i don't think there is much variety there |
23:38:04 | saratoga | i guess some difference in memory or cache is most likely |
23:38:07 | pamaury | could it be the ram speed? That would be the obvious difference |
23:39:29 | saratoga | i'm testing the files now to compare |
23:40:54 | saratoga | AAC-HE needs 73 MHz on AMSv2 vs. 260 MHz on Fuze+ |
23:41:25 | pamaury | wow that's huge |
23:41:39 | pamaury | is that boosted? |
23:41:42 | saratoga | yeah it seems like something isn't right |
23:41:44 | saratoga | yeah boosted |
23:42:06 | Bilgus | huh when I ran it on my clipzip I got ~150 |
23:42:14 | saratoga | boosted AMSv2 for AAC-HE-PS takes 92 MHz |
23:42:26 | Bilgus | I'm pretty sure thats amsv2 |
23:42:27 | wodz | what mem_test plugin says? |
23:42:29 | saratoga | compare to bilgus here: http://forums.rockbox.org/index.php/topic,52018.msg240757.html#msg240757 |
23:42:41 | pamaury | it might be worth checking if the auto scaling function has a negative impact |
23:42:42 | saratoga | Bilgus: interesting, what build? |
23:43:32 | pamaury | changing imx233_clkctrl_enable_auto_slow(true) to imx233_clkctrl_enable_auto_slow(false) in system-imx233.c |
23:43:56 | saratoga | part of the difference is due to the lower clock on AMSv2 (38 MHz and 192 MHz), so memory latency will be lower |
23:44:43 | saratoga | but boosted AMSv2 (192 MHz) is still way faster per clock than unboosted imx233 (64 MHz) |
23:45:02 | Bilgus | its the multiboot build so like dev from july? |
23:45:09 | saratoga | huh, which file? |
23:46:09 | saratoga | i got 384 MHz on fuze+ a couple months ago with this file: https://download.rockbox.org/test_files/nero_hev2_64.m4a |
23:46:21 | saratoga | and 92 MHz just now |
23:46:31 | Bilgus | o_O |
23:46:57 | saratoga | build on amsv2 is from last april |
23:47:01 | | Quit krabador (Remote host closed the connection) |
23:47:03 | saratoga | stock dev build |
23:47:12 | Bilgus | oh ok fuze+ vs amsv2 |
23:47:12 | saratoga | but with test plugins enabled |
23:47:18 | saratoga | yeah |
23:47:40 | saratoga | wodz: i tried test_mem a while back but it didn't clear much up for me |
23:47:56 | *** | Saving seen data "./dancer.seen" |
23:48:23 | saratoga | i'm not sure if the plugin is very accurate |
23:50:42 | * | pamaury goes to bed |
23:51:08 | Bilgus | ill try that test file nero on the fuze+ so we get some apples to apples comparison |
23:51:53 | saratoga | test_mem says that boosted fuze+ memory has similar read speed but double write speed as amsv2 boosted |
23:51:56 | saratoga | for whatever that is worth |
23:53:13 | pamaury | could there be a difference due to iram? |
23:53:19 | saratoga | yes, likely |
23:53:26 | saratoga | hmm, not sure what test_mem tests |
23:53:34 | pamaury | the fuze+ has basically no iram |
23:53:59 | Bilgus | ok so first it skips the same as the other one |
23:55:44 | Bilgus | pamaury could you do a test on your fuze+ when you get a chance I'd hate to be hunting a bug that was unique to my player |
23:56:36 | saratoga | it tests the plugin buffer |
23:57:41 | Bilgus | ok that file boosted decode 148.25 118.73% 383 MHZ |
23:58:46 | Bilgus | Running unboosted now |