00:11:26 | | Quit Strife89 (Ping timeout: 248 seconds) |
00:12:01 | | Join Strife89 [0] (~quassel@adsl-98-80-192-129.mcn.bellsouth.net) |
00:22:18 | | Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 56.0.2/20171024165158]) |
00:24:45 | CH23 | can i test a bootloader via simulator? |
00:26:19 | pamaury | CH23: no |
00:26:23 | | Quit Rower (Ping timeout: 248 seconds) |
00:28:40 | | Quit petur (Quit: Leaving) |
00:35:48 | fire2199 | pamaury : for which player is the code you have with the tms320dm320? |
00:46:05 | pamaury | fire2199: Creative Zen Vision:M, mrobe-500 and sansa connect |
00:48:32 | | Join zed [0] (~zed@p54A1E7BD.dip0.t-ipconnect.de) |
00:48:56 | | Nick zed is now known as Guest91723 (~zed@p54A1E7BD.dip0.t-ipconnect.de) |
00:49:00 | Guest91723 | Hey guys. Is there any backup of themes till server is unavailable |
00:49:56 | | Nick Guest91723 is now known as zed187 (~zed@p54A1E7BD.dip0.t-ipconnect.de) |
00:53:01 | pamaury | not that I know of |
00:53:25 | zed187 | damn |
00:53:27 | __builtin | archive.org? |
00:53:44 | __builtin | zed187: ^ |
00:55:41 | zed187 | i cant find any rockbox themes there |
00:57:25 | CH23 | https://web.archive.org/web/20161023032120/http://themes.rockbox.org/index.php |
00:57:36 | CH23 | you're doing it wrong then :P |
00:57:43 | zed187 | ok great |
00:57:45 | zed187 | thank you |
00:59:09 | fire2199 | pamaury : do you have the entire code source open? |
01:00 |
01:00:18 | *** | Saving seen data "./dancer.seen" |
01:11:05 | | Quit zed187 () |
01:11:52 | pamaury | fire2199: all our code is there: https://git.rockbox.org/?p=rockbox.git;a=summary |
01:12:16 | | Quit lebellium_ (Quit: Leaving) |
01:12:24 | pamaury | specifically in firmware/target/arm/tms320dm320 for the soc part |
01:18:57 | fire2199 | ok |
01:23:37 | | Quit fire2199 (Quit: leaving) |
01:30:40 | | Quit pamaury (Ping timeout: 260 seconds) |
01:33:54 | | Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-fldmbzhhiuligypt) |
01:35:51 | CH23 | i get an error when building the sansa clip plus bootloader : [ERR] Packed data (134205 bytes) doesn't fit in the firmware (134136 bytes) |
01:36:36 | CH23 | error comes from mkamsboot, using latest dev build of mkamsboot |
01:38:14 | __builtin | looks like it's a handful of bytes too big |
01:38:39 | CH23 | i build bootloader from source without changes |
01:39:42 | CH23 | ./mkamsboot clipplus01.02.18/clppa.bin rockbox/build/bootloader-clipplus.sansa bootloader2017-11-05.01\:00\:00/clppa.bin |
01:39:59 | CH23 | bootloader-clipplus.sansa is also latest release |
01:40:32 | __builtin | it's probably some recent changes that increased the size beyond the threshold |
01:41:45 | CH23 | that's probable |
02:00 |
02:02:34 | | Quit ZincAlloy (Quit: Leaving.) |
02:03:19 | | Join Bilgus_ph [0] (41ba23be@gateway/web/freenode/ip.65.186.35.190) |
02:05:12 | Bilgus_ph | Ch23 look at my commits either reduce dia critic or disable codepagw that will free up some bytes |
02:06:47 | CH23 | Bilgus_ph: thanks, i mostly wanted to make sure it's known to do this currently. |
02:09:12 | | Quit ender` (Quit: drug, n: A substance that, injected into a rat, produces a scientific paper.) |
02:09:38 | Bilgus_ph | Jhmikes mentioned something that was unneeded that freed up some bytes but I don't remember what it was after his last commit to the file system |
02:10:38 | dandels | Does rockbox support (re)binding keys? |
02:11:08 | __builtin | dandels: what exactly do you mean? |
02:12:25 | dandels | The zen mozaic has a "wildcard" button which the stock firmware allows binding to things such as "Now playing". I couldn't find a way to get that functionality on Rockbox. |
02:13:49 | dandels | If that didn't make sense then it's because I should be going to sleep |
02:14:15 | __builtin | if you don't mind modifying the source it's totally possible |
02:14:31 | __builtin | I'm not sure about doing it purely within rockbox, though |
02:14:39 | dandels | I had hoped for an easier way to do it, but I'll look into modifying the source |
02:15:21 | CH23 | dandels: you mean a shortcut key? like, you can set the key to go to a certain screen or app? |
02:15:46 | __builtin | Bilgus_ph might know more; I'm not too knowledgeable about that |
02:16:00 | dandels | CH23: yes |
02:17:05 | Bilgus_ph | We don't have that functionality as far as I know but you can set a shortcut using the quick menu so close... |
02:17:12 | CH23 | dandels: if you want the less inconvenient way, you can add shortcuts to the 'home' menu |
02:17:26 | | Quit Bilgus_ph (Quit: Page closed) |
02:17:55 | CH23 | otherwise you'll have to modify source |
02:19:21 | dandels | I'll look into hacking at the source. It appears that one of my buttons doesn't do anything right now. |
02:21:53 | dandels | -> sleep |
02:21:55 | | Quit dandels (Quit: WeeChat 1.9.1) |
03:00 |
03:00:19 | *** | Saving seen data "./dancer.seen" |
03:33:33 | | Quit _meg (Ping timeout: 240 seconds) |
03:36:41 | | Join _meg [0] (~notsure@211.25.203.45) |
03:43:28 | | Quit Ruhan (Quit: Connection closed for inactivity) |
04:00 |
04:31:28 | | Quit fs-bluebot (Ping timeout: 240 seconds) |
04:32:21 | | Quit bluebrother (Ping timeout: 240 seconds) |
04:34:18 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
04:45:27 | | Join fs-bluebot [0] (~fs-bluebo@port-92-196-120-247.dynamic.qsc.de) |
05:00 |
05:00:23 | *** | Saving seen data "./dancer.seen" |
05:27:30 | jhMikeS | Bilgus (for logs): The secret sauce was not defining HAVE_PRIORITY_SCHEDULING for the bootloader |
06:00 |
06:05:55 | | Quit TheSeven (Ping timeout: 258 seconds) |
06:07:27 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
06:24:33 | | Quit bluebrother (Disconnected by services) |
06:24:39 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
06:28:01 | | Quit fs-bluebot (Ping timeout: 248 seconds) |
06:40:54 | | Quit TheSeven (Ping timeout: 246 seconds) |
06:41:13 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
06:42:23 | | Join fs-bluebot [0] (~fs-bluebo@port-92-196-127-224.dynamic.qsc.de) |
07:00 |
07:00:24 | *** | Saving seen data "./dancer.seen" |
07:10:42 | | Join PurlingNayuki [0] (~purlingna@2001:da8:215:4ff:5fc1:3ce0:6c17:4a83) |
07:17:47 | | Quit jhMikeS (Ping timeout: 260 seconds) |
07:21:26 | | Quit PurlingNayuki (Ping timeout: 258 seconds) |
08:00 |
08:23:57 | | Join PurlingNayuki [0] (~purlingna@45.77.71.80) |
08:29:20 | | Quit PurlingNayuki (Remote host closed the connection) |
08:35:18 | | Quit Strife89 (Quit: No Ping reply in 180 seconds.) |
08:36:55 | | Join Strife89 [0] (~quassel@adsl-98-80-192-129.mcn.bellsouth.net) |
08:56:01 | | Join dys [0] (~dys@tmo-100-214.customers.d1-online.com) |
09:00 |
09:00:26 | *** | Saving seen data "./dancer.seen" |
09:03:00 | | Quit Strife89 (Quit: No Ping reply in 180 seconds.) |
09:04:28 | | Join Strife89 [0] (~quassel@adsl-98-80-192-129.mcn.bellsouth.net) |
09:11:43 | | Join JanC_ [0] (~janc@lugwv/member/JanC) |
09:13:00 | | Quit JanC (Killed (orwell.freenode.net (Nickname regained by services))) |
09:13:01 | | Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) |
09:27:42 | | Join lebellium [0] (~hexchat@89-93-177-206.hfc.dyn.abo.bbox.fr) |
09:27:47 | | Join lebellium_ [0] (~chatzilla@89-93-177-206.hfc.dyn.abo.bbox.fr) |
09:28:48 | | Join Rower [0] (husvagn@m176-64-233-132.cust.tele2.se) |
09:51:18 | | Quit lebellium (Quit: Leaving) |
09:51:30 | | Join lebellium [0] (~hexchat@89-93-177-206.hfc.dyn.abo.bbox.fr) |
09:53:46 | | Quit alucryd (Remote host closed the connection) |
09:56:31 | | Join alucryd [0] (~quassel@archlinux/developer/alucryd) |
09:59:29 | | Join johnb3 [0] (~johnb2@p5B3AF24C.dip0.t-ipconnect.de) |
10:00 |
10:01:08 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
10:05:03 | | Quit lebellium (Quit: Leaving) |
10:05:27 | | Quit jhMikeS (Ping timeout: 240 seconds) |
10:05:49 | | Join lebellium [0] (~hexchat@89-93-177-206.hfc.dyn.abo.bbox.fr) |
10:07:42 | | Quit lebellium (Client Quit) |
10:07:57 | | Join lebellium [0] (~hexchat@89-93-177-206.hfc.dyn.abo.bbox.fr) |
10:13:01 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:99c:a79e:508b:d505) |
10:27:56 | | Quit dys (Ping timeout: 260 seconds) |
10:28:40 | | Join dys [0] (~dys@tmo-109-178.customers.d1-online.com) |
10:35:53 | | Join ender` [0] (krneki@foo.eternallybored.org) |
10:40:47 | | Join petur [0] (~petur@rockbox/developer/petur) |
11:00 |
11:00:29 | *** | Saving seen data "./dancer.seen" |
11:07:27 | | Quit _meg (Ping timeout: 240 seconds) |
11:07:57 | | Join _meg [0] (~notsure@211.25.203.45) |
11:21:24 | | Join dandels_ [0] (~dandels@unaffiliated/dandels) |
11:34:36 | | Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) |
11:51:35 | | Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) |
11:57:46 | | Quit dys (Ping timeout: 260 seconds) |
12:00 |
12:06:29 | | Join dys [0] (~dys@tmo-099-140.customers.d1-online.com) |
12:06:56 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
12:15:44 | | Quit Strife89 (Quit: No Ping reply in 180 seconds.) |
12:17:35 | | Join Strife89 [0] (~quassel@adsl-98-80-192-129.mcn.bellsouth.net) |
12:27:45 | | Join Strife1989 [0] (~quassel@adsl-98-80-186-100.mcn.bellsouth.net) |
12:28:34 | | Quit Strife89 (Ping timeout: 240 seconds) |
12:38:41 | | Join Strife89 [0] (~quassel@adsl-98-80-190-153.mcn.bellsouth.net) |
12:41:45 | | Quit Strife1989 (Ping timeout: 246 seconds) |
12:47:09 | | Quit Rower (Ping timeout: 264 seconds) |
13:00 |
13:00:32 | *** | Saving seen data "./dancer.seen" |
13:06:40 | | Quit dandels_ (Ping timeout: 240 seconds) |
13:06:59 | | Join dandels [0] (~dandels@unaffiliated/dandels) |
13:08:15 | | Join Strife1989 [0] (~quassel@adsl-98-80-195-8.mcn.bellsouth.net) |
13:11:11 | | Quit Strife89 (Ping timeout: 248 seconds) |
13:16:25 | | Join Strife89 [0] (~quassel@adsl-98-80-183-89.mcn.bellsouth.net) |
13:16:55 | | Join PurlingNayuki [0] (~purlingna@2001:da8:215:4ff:5fc1:3ce0:6c17:4a83) |
13:17:52 | | Quit Strife1989 (Ping timeout: 246 seconds) |
13:21:44 | | Quit Strife89 (Quit: No Ping reply in 180 seconds.) |
13:23:17 | | Join Strife89 [0] (~quassel@adsl-98-80-183-89.mcn.bellsouth.net) |
13:56:22 | | Part robertd1 |
13:59:53 | | Join robertd1 [0] (~root@201.242.176.168) |
14:00 |
14:21:55 | | Quit PurlingNayuki (Remote host closed the connection) |
14:22:30 | | Quit Strife89 (Quit: No Ping reply in 180 seconds.) |
14:24:28 | | Join PurlingNayuki [0] (~purlingna@2001:da8:215:4ff:5fc1:3ce0:6c17:4a83) |
14:25:11 | | Join Strife89 [0] (~quassel@adsl-98-80-183-89.mcn.bellsouth.net) |
14:30:24 | | Quit CH23 (Ping timeout: 260 seconds) |
14:39:46 | | Quit PurlingNayuki (Remote host closed the connection) |
14:40:19 | | Join PurlingNayuki [0] (~purlingna@2001:da8:215:4ff:5fc1:3ce0:6c17:4a83) |
14:45:21 | | Quit Strife89 (Quit: No Ping reply in 180 seconds.) |
14:47:24 | | Join Strife89 [0] (~quassel@adsl-98-80-183-89.mcn.bellsouth.net) |
14:53:14 | | Join johnb5 [0] (~johnb2@p5B3AF24C.dip0.t-ipconnect.de) |
14:56:42 | copper | I'm pretty much done porting my PodOne theme to the Mini: https://imgur.com/sIjIoYi |
14:58:57 | copper | Any ETA on the theme site? |
14:59:22 | | Part robertd1 |
14:59:38 | | Join robertd1 [0] (~root@201.242.176.168) |
15:00 |
15:00:36 | *** | Saving seen data "./dancer.seen" |
15:21:39 | | Join PimpiN8 [0] (~textual@145.132.155.235) |
15:33:28 | | Join johnb3 [0] (~johnb2@p5B3AF24C.dip0.t-ipconnect.de) |
15:39:25 | johnb3 | Bilgus: I have started to test "Power Saving" also on Clip+, Zip and FuzeV2. So far: all fine on clip+. Display low speed on the zip slows down screen refresh and also drops key presses (not queuing them) to an extent where I feel it doesn't make sense. I was about to say that the FuzeV2 doesn't show such effects, when I decided to check the register value. Going to the second screen in HW Info I get a Divide by Zero crash: deja vu. ;-) |
15:40:11 | johnb3 | I am currently running the battery bench on the Fuze with all saving active. |
15:42:11 | johnb3 | However, with all active I also got crashes during USB data transfer (data abort). I need to verify that all is fine with the regular dev build and then figure which settig does this (after the bench). |
15:43:21 | | Quit PurlingNayuki (Remote host closed the connection) |
15:44:01 | | Join PurlingNayuki [0] (~purlingna@2001:da8:215:4ff:5fc1:3ce0:6c17:4a83) |
15:48:38 | | Quit PurlingNayuki (Ping timeout: 246 seconds) |
15:57:49 | | Quit johnb3 (Ping timeout: 246 seconds) |
15:58:42 | vflyson | hello. I’m planning to purchase ipod classic to put rockbox on it, but am not sure if the 7th generation is supported or not, on the website only 6g is mentioned |
15:59:26 | vflyson | is 7g only related to the hard drive and not the actual hardware of the player? |
16:00 |
16:23:27 | gevaerts | They're mostly the same, yes |
16:23:51 | gevaerts | One of the 6G sizes has a weird disk, apart from that I don't think there's any real difference |
16:23:55 | gevaerts | So they all work |
16:30:51 | __builtin | starting with the 6.5G it has hardware for the inline mic |
16:32:18 | __builtin | copper: unfortunately no |
16:44:11 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
16:50:32 | | Join dandels_ [0] (~dandels@unaffiliated/dandels) |
16:57:04 | | Quit johnb5 (Ping timeout: 240 seconds) |
16:59:00 | * | pamaury is finally making some sense of the mmc code in the clip+ ROM... |
17:00 |
17:00:40 | *** | Saving seen data "./dancer.seen" |
17:04:35 | | Quit dandels_ (Ping timeout: 246 seconds) |
17:09:30 | | Join Saratoga [0] (20d43f5f@gateway/web/freenode/ip.32.212.63.95) |
17:09:39 | Saratoga | pamaury: awesome! |
17:20:24 | | Join dandels_ [0] (~dandels@unaffiliated/dandels) |
17:21:18 | | Quit Saratoga (Ping timeout: 260 seconds) |
17:24:44 | | Quit dan- (Max SendQ exceeded) |
17:25:27 | | Quit dandels_ (Ping timeout: 240 seconds) |
17:27:11 | | Join dan- [0] (~d@101.165.131.18) |
17:27:11 | | Quit dan- (Changing host) |
17:27:11 | | Join dan- [0] (~d@freenode/corporate-sponsor/privateinternetaccess.com/doaks) |
17:27:56 | | Join dandels_ [0] (~dandels@unaffiliated/dandels) |
17:45:43 | | Join regnarg [0] (~regnarg@router-kraduha-nat-j.pilsfree.net) |
17:47:11 | | Quit dandels_ (Ping timeout: 260 seconds) |
17:48:10 | regnarg | Hi, I have a Creative ZEN that won't boot because of low battery (as decribed on https://www.rockbox.org/wiki/STMP37xxRecovery#Battery_is_too_discharged_to_even_boot). I wanted to try the charge firmware but the dropbox link for the zen version is dead (404). I tried to build it myself, but mkimxboot requires original firmware in sb format and I do not know how to get it (I have the exe updater and the _rk.bin file extracted by zenutils |
17:48:11 | regnarg | ). |
17:51:48 | pamaury | regnarg: the ZEN should charge itself even with low battery I think |
17:52:03 | pamaury | have you try to plug the cable and let it charge for some time? |
17:52:27 | pamaury | (I will upload a new file, be patient) |
17:54:13 | regnarg | I think I have tried it last time it happened, but it was a long time ago and the player was replaced since then. I will try it again, thanks. |
17:54:16 | vflyson | thanks gevaerts |
17:56:17 | vflyson | what has the longest battery life by the way? I assume it’s 7g... I’m going to replace the hdd with a flash storage so do not care about the stock disk size really |
17:57:13 | __builtin | the 6G has a larger stock battery capacity, but it's probably to compensate for the larger disk needing more power |
18:00 |
18:04:59 | pamaury | regnarg: I'm working on create a charge firmware again, I must have written the code at some point but lost it, it shouldn't be too long |
18:06:47 | | Join PurlingNayuki [0] (~purlingna@221.219.24.140) |
18:14:13 | | Quit PurlingNayuki (Remote host closed the connection) |
18:14:37 | | Join PurlingNayuki [0] (~purlingna@221.219.24.140) |
18:14:48 | | Quit PurlingNayuki (Remote host closed the connection) |
18:15:32 | | Join PurlingNayuki [0] (~purlingna@221.219.24.140) |
18:20:57 | | Quit Jinx (Quit: reboot) |
18:26:28 | pamaury | regnarg: I updated the link on the wiki |
18:26:46 | pamaury | it's untested but there isn't much that can go wrong anyway |
18:27:21 | | Join johnb5 [0] (~johnb2@p5B3AF24C.dip0.t-ipconnect.de) |
18:30:25 | fs-bluebot | Build Server message: New build round started. Revision ee2eb13, 273 builds, 13 clients. |
18:31:17 | pamaury | regnarg: and for info, this is the code: g#1722 |
18:31:20 | fs-bluebot | Gerrit review #1722 at http://gerrit.rockbox.org/r/1722 : mkimxboot: add support for the ZEN (recovery/bootloader) by Amaury Pouly |
18:31:20 | pamaury | let me know if it works |
18:32:51 | | Quit PurlingNayuki (Remote host closed the connection) |
18:33:15 | | Join PurlingNayuki [0] (~purlingna@221.219.24.140) |
18:43:08 | fs-bluebot | Build Server message: Build round completed after 763 seconds. |
18:43:09 | fs-bluebot | Build Server message: Revision ee2eb13 result: All green |
18:43:20 | regnarg | pamaury: Thank you very much, I'll let you know |
18:47:14 | | Quit PurlingNayuki (Remote host closed the connection) |
18:47:35 | | Join PurlingNayuki [0] (~purlingna@221.219.24.140) |
18:47:47 | pamaury | so regarding clip+ ROM, I believe the two scsi vendor command allow one to send arbitrary SD/MMC command |
18:53:05 | | Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) |
19:00 |
19:00:41 | *** | Saving seen data "./dancer.seen" |
19:03:19 | | Join PimpiN8 [0] (~textual@145.132.155.235) |
19:19:46 | | Quit johnb5 (Quit: Nettalk6 - www.ntalk.de) |
19:24:01 | | Quit alexweissman (Remote host closed the connection) |
19:27:37 | vflyson | _builtin: so does it mean 6G would last longer because of having a bigger power bank comparing to 7g, if both used with the same flash drive? |
19:29:47 | __builtin | vflyson: I can't be sure, but I would think so |
19:29:56 | | Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) |
19:30:39 | vflyson | interesting... and they have the same hardware inside, as in 6g is not much slower than 7g, wouldn’t you happen to know? |
19:31:03 | __builtin | they're virtually identical; they share 100% code |
19:31:42 | sth | is this about the ipod? |
19:31:52 | __builtin | yes |
19:31:59 | sth | if so 6g and 7g is the same pretty much |
19:32:31 | sth | 6g lacks headset controls |
19:32:51 | sth | 6.5g and 7g has it, plus mic support |
19:32:56 | __builtin | apart from some minor differences like that, they're identical |
19:33:02 | sth | 7g is just slim 160gb iirc |
19:33:39 | sth | 6g also has screwed up audio, not sure if they fixed that in newer versions |
19:38:00 | sth | is there hope for the x1000 app port? |
19:38:13 | | Quit alexweissman (Remote host closed the connection) |
19:43:38 | | Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) |
19:50:24 | | Quit alexweissman (Remote host closed the connection) |
19:52:20 | | Join johnb3 [0] (~johnb2@p5B3AF24C.dip0.t-ipconnect.de) |
20:00 |
20:07:26 | | Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) |
20:08:11 | | Join Rower [0] (~husvagn@m176-64-233-132.cust.tele2.se) |
20:10:15 | | Join xorly [0] (~xorly@ip-86-49-24-93.net.upcbroadband.cz) |
20:16:06 | | Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) |
20:16:11 | | Quit alexweissman (Remote host closed the connection) |
20:16:26 | | Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) |
20:17:13 | | Quit dandels (Quit: WeeChat 1.9.1) |
20:27:12 | _Bilgus | jhMikeS, I see in export/config.h #ifdef HAVE_BOOTLOADER_USB_MODE |
20:27:12 | _Bilgus | #define HAVE_PRIORITY_SCHEDULING |
20:27:37 | _Bilgus | is removing this going to cause usb problems or is it a relic? |
20:32:38 | jhMikeS | It was originally defined for gigabeat S because I wanted priority in the bootloader (for safety reasons because battery management is very much at the mercy of software) |
20:33:17 | jhMikeS | For other targets, if it has no negative effect, it's should be irrelevant |
20:34:18 | _Bilgus | I'm testing the clip+ now I have a fuze+ and a clipzip to test on but thats about it |
20:34:21 | * | jhMikeS should probably see the history for what happened there |
20:36:02 | jhMikeS | I don't think you'll have any bad effect. |
20:37:12 | _Bilgus | seems to work fine for the clip+ and zip, knocks off 2k too |
20:38:09 | jhMikeS | Should probably just add the #define to the beast's config file to activate priority, otherwise just don't set it for bootloaders |
20:38:56 | __builtin | jhMikeS: regarding your PCM rework, are you planning to support different sample depths? |
20:39:04 | jhMikeS | yes |
20:39:14 | __builtin | how? |
20:39:28 | jhMikeS | on the DMA end or the input end? |
20:39:41 | __builtin | input end |
20:39:56 | jhMikeS | I'm already supporting mono, so it's all pretty much the same |
20:40:39 | jhMikeS | just need converter functions that shift the input when it doesn't match the output |
20:41:29 | jhMikeS | pcm_play_data takes a format structure with the type code and channel count |
20:41:53 | __builtin | ah, I see |
20:42:12 | __builtin | like what SDL does; that makes sense |
20:42:35 | jhMikeS | it just sets mix_samples and write_samples to point to the right converter |
20:42:52 | __builtin | are you planning on merging it soon? |
20:43:27 | jhMikeS | not too soon. it's still being put in a compilable state. |
20:43:52 | __builtin | ok, thanks |
20:43:54 | jhMikeS | some things I'm a bit indecisive about |
20:47:40 | _Bilgus | It looks like the bootloader is using the scroll engine as well I can't think of anything that scrolls there though |
20:48:43 | jhMikeS | it isn't removed by the linker |
20:48:45 | jhMikeS | ? |
20:48:55 | _Bilgus | nope |
20:50:09 | __builtin | _Bilgus: that's odd |
20:50:44 | __builtin | I can confirm it with the ipod6g bootloader as well |
20:52:20 | __builtin | looks like firmware/drivers/lcd-color-common.c calls scroll_init() unconditionally |
20:53:12 | | Join ender [0] (krneki@foo.eternallybored.org) |
20:53:46 | _Bilgus | all of the lcd drivers do |
20:56:06 | jhMikeS | it's called by the viewport code |
20:56:12 | | Quit [7] (Disconnected by services) |
20:56:21 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
20:57:01 | jhMikeS | lcd_clear_display calls lcd_clear_viewport |
21:00 |
21:00:12 | | Join CR0W_ [0] (narf@rrcs-67-53-148-69.west.biz.rr.com) |
21:00:19 | | Join St0neHead- [0] (stonehead@2a01:7e00:e001:3700:6667::2) |
21:00:35 | | Join SuperChickeNES [0] (~ChickeNES@162.243.44.61) |
21:00:39 | _Bilgus | ah so its forcing it to load? |
21:00:45 | *** | Saving seen data "./dancer.seen" |
21:00:49 | jhMikeS | in a couple places apparently |
21:01:05 | jhMikeS | btw, maybe try building with thumb code too and see what happens |
21:03:09 | | Join Marex_ [0] (~Marex@195.140.253.167) |
21:06:01 | | Join dandels [0] (~dandels@unaffiliated/dandels) |
21:08:51 | _Bilgus | like with -mthumb? |
21:10:30 | _Bilgus | it causes some of the I assume hand written asm to fail |
21:11:08 | jhMikeS | what? it should have the proper return sequences |
21:11:15 | jhMikeS | clip uses thumb |
21:11:34 | jhMikeS | I just tried and it saved 13244 bytes on e200 |
21:11:40 | | Quit ender` (*.net *.split) |
21:12:00 | | Quit CR0W (*.net *.split) |
21:12:00 | | Quit nialv7 (*.net *.split) |
21:12:00 | | Quit Marex (*.net *.split) |
21:12:00 | | Quit St0neHead (*.net *.split) |
21:12:00 | | Quit ChickeNES (*.net *.split) |
21:12:00 | | Quit ruskie (*.net *.split) |
21:12:09 | _Bilgus | https://pastebin.com/5BGrDjKu |
21:13:11 | jhMikeS | thumb and no priority gives -16564 |
21:13:53 | _Bilgus | WOW |
21:14:13 | jhMikeS | you can't just add the compiler option. there's a special way of configuring so it compiles with the thumb_cc.py |
21:14:21 | _Bilgus | maybe I'm doing something wrong |
21:14:26 | | Quit sanchaez (Ping timeout: 240 seconds) |
21:14:27 | _Bilgus | ah ok |
21:14:38 | jhMikeS | I don't know what it is though :) |
21:14:44 | _Bilgus | lol ok |
21:15:47 | jhMikeS | I just hand-modded the makefile |
21:17:25 | | Join sanchaez [0] (~sanchaez@95.67.87.200) |
21:19:29 | | Join ruskie [0] (~ruskie@sourcemage/mage/ruskie) |
21:27:41 | _Bilgus | jhMikeS, ../tools/configure −−thumb |
21:29:23 | jhMikeS | yeah, but it's the default for clip-v1. no options needed |
21:29:25 | _Bilgus | ~2k saved and 4k with no priority |
21:30:16 | _Bilgus | the clipv1 was like already over with head months ago |
21:30:26 | _Bilgus | likely* |
21:31:26 | jhMikeS | I guess the line " if [ "$ARG_ARM_THUMB" != 0 ]; then ARG_ARM_THUMB=1; fi" |
21:32:13 | _Bilgus | really? all the thumb capable targets have that though |
21:33:44 | jhMikeS | will the compilation fail if the bootloader is too big? I just compiled clip v1 |
21:34:34 | jhMikeS | which one(s) is/are oversized? |
21:35:36 | jhMikeS | not sure what you mean though. all the arm targets are thumb capable. |
21:36:11 | _Bilgus | no its based on makeams I mean I suppose there truly is a maximum limit but its strictly limited on using the OF file size, the OF is compressed and the rb bootloader is packed in there with it |
21:37:43 | _Bilgus | I'm saying it looked like all the arm targets had that line "if [ "$ARG_ARM_THUMB" != 0 ]; then ARG_ARM_THUMB=1; fi" |
21:38:11 | jhMikeS | I see from the logs the clip plus was the one |
21:39:19 | jhMikeS | definitely not. almost all targets are ARM and most don't have it |
21:39:39 | jhMikeS | nothing with large ram has it |
21:41:45 | jhMikeS | everything with it is memory=2 |
21:46:08 | _Bilgus | here are all the sansa firmware badger accumulated https://daniel.haxx.se/sansa/amsfw.html#clip |
21:46:37 | | Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") |
21:53:05 | _Bilgus | witht the new fs code and have priority the clipv1 is 1.2k too large it already had thumb and with no priority it has 747 bytes free |
22:00 |
22:01:42 | jhMikeS | it's mkamsboot that throws the error, right? |
22:02:46 | _Bilgus | yes |
22:03:19 | _Bilgus | but because the new firmware won't fit in with the compressed OF |
22:04:27 | jhMikeS | been a loooong time since I did this thing |
22:05:20 | _Bilgus | it goes [(OF)] = xyz MB -> compression [(rbblc)(OFc)] = xyz MB |
22:07:01 | _Bilgus | I imagine there is a real maximum of ~16 mb but thats sorta arbitrary as well since it would be based on the SANSA_AMS_OF size in the driver code |
22:08:05 | _Bilgus | from what I can tell the device uses magic headers to actually delineate the bounds |
22:14:06 | jhMikeS | I get 786 remaining without priority |
22:14:50 | _Bilgus | i got 747 so probably you have a different firmware |
22:15:09 | _Bilgus | I don't rem which one I have laying around |
22:15:31 | _Bilgus | its been like a year since I messed with it |
22:17:04 | | Quit _meg (Ping timeout: 240 seconds) |
22:17:18 | | Join fire2199 [0] (~fire2199@gateway/tor-sasl/fire2199) |
22:19:14 | regnarg | pamaury: The charging fw does not seem to help. I uploaded with ./sbloader -d -u 066f:3700 -p hid -x 64 creative_zen_charge.sb (after reconnecting usb and with blacklisted usbhid) and it seemed to go well: |
22:19:14 | regnarg | Device: 066f:3700 @ 1.22 |
22:19:15 | regnarg | Transfer size: 64 |
22:19:15 | DBUG | Enqueued KICK regnarg |
22:19:15 | regnarg | Status: Passed |
22:19:18 | jhMikeS | I did the last one |
22:19:45 | jhMikeS | 1.01.35 |
22:20:01 | regnarg | After that, I let it charge for an hour and tried resetting, no difference (still boots into hw recovery with black screen) |
22:20:23 | pamaury | regnarg: maybe your battery is dead |
22:21:07 | | Join _meg [0] (~notsure@211.25.203.45) |
22:21:09 | regnarg | We used the player a week ago on bat with no issues. I will probably try to disassemble it and charge the battery with an external li-ion charger |
22:21:21 | regnarg | Thanks for the help anyway |
22:21:24 | pamaury | regnarg: another option is to try and upload Creative's bootloader, it is in the firmware if you have the tols to extract it, other I can upload it somewhere |
22:22:01 | pamaury | then maybe something else is broken? As I recall, the ZEN doesn't boot into hardware recovery mode unless battery is extremely low or battery is disconnected |
22:22:14 | regnarg | I have extracted the firmware using zenutils and I have: |
22:22:15 | regnarg | ZEN_PCFW_L22_1_21_03e.exe ZEN_PCFW_L22_1_21_03e_rk_FRESC ZEN_PCFW_L22_1_21_03e_rk_Hdevicon.ico ZEN_PCFW_L22_1_21_03e_rk_Hjukebox2.jrs ZEN_PCFW_L22_1_21_03e_rk_0xa9544c20 |
22:22:15 | regnarg | ZEN_PCFW_L22_1_21_03e.opt ZEN_PCFW_L22_1_21_03e_rk_HCreative_S.TTF ZEN_PCFW_L22_1_21_03e_rk_Hdevlogo.png ZEN_PCFW_L22_1_21_03e_rk_Hsplash.jbm |
22:22:15 | regnarg | ZEN_PCFW_L22_1_21_03e_rk.bin ZEN_PCFW_L22_1_21_03e_rk_HCreative_T.TTF ZEN_PCFW_L22_1_21_03e_rk_Hjukebox.grs ZEN_PCFW_L22_1_21_03e_rk.mk |
22:22:15 | *** | Alert Mode level 1 |
22:22:15 | regnarg | ZEN_PCFW_L22_1_21_03e_rk_CINF ZEN_PCFW_L22_1_21_03e_rk_HDeviceInfo.xml ZEN_PCFW_L22_1_21_03e_rk_Hjukebox.opt ZEN_PCFW_L22_1_21_03e_rk_NULL |
22:23:03 | _Bilgus | jHmikes, it looks like most of the space used up by scroll_engine is in the line buffer and thread stack |
22:23:09 | [Saint] | *cough* pastebin *cough* |
22:23:32 | pamaury | regnarg: it's the FRESC file, try to upload it with sbloader |
22:24:54 | _Bilgus | eh nm I suppose at init that would all be 0 therefore easily compressed |
22:25:23 | _Bilgus | sounds like no priority is the way to go barring a rewrite of the scroll stuff |
22:25:42 | regnarg | Screen stays black and interestingly, the recovery usb device is still there. I can send the firmware twice and it always says ok and nothing happens.... possibly an issue with sbloader? |
22:26:06 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
22:26:06 | * | [Saint] senses _Bilgus is thinking highly about breaking things |
22:26:27 | _Bilgus | me?? NO |
22:26:44 | [Saint] | scroll_engine is...not fun. |
22:26:48 | regnarg | Maybe a different transport size? (i guessed it as both 48 and 1024 suggested in help give transfer errors) |
22:26:53 | [Saint] | ties to the skin engine make it a bit of a nightmare. |
22:27:34 | _Bilgus | Its getting included with the bootloader just trying to free up some bytes looking at things that aren't really needed at boot |
22:28:21 | pamaury | regnarg: it seems more likely your device resets in between the runs I would say but that's very hypothetical |
22:29:14 | regnarg | pamaury: You're right; I see the reconnect in dmesg, silly mistake. |
22:30:51 | [Saint] | Wait...it is? |
22:31:14 | [Saint] | Is that just by process of accidental/unnecessary function inclusion, or do we actually use it? |
22:31:22 | pamaury | regnarg: I can't be certain but it sounds like there is a hardware problem, at this stage I would bet on the battery |
22:31:35 | [Saint] | Offhand I don't think I've seen the bootloader scrool anything, ever. |
22:31:37 | pamaury | either dead or disconnected |
22:31:41 | [Saint] | bah *scroll |
22:32:16 | *** | Alert Mode OFF |
22:32:48 | _Bilgus | jhmike was saying it gets included because viewport clear |
22:33:16 | regnarg | pamaury: Ok, thank you, I'll try to somehow charge/replace the battery and see what happens |
22:35:11 | pamaury | regnarg: sorry I can't help more :-/ if you are willing to experiment more, we could try to upload hwstub, it's a small piece of code I use for debugging, we could try to read the battery voltage, see what we get. But if you have a multimeter, you may as well open the device and measure it directly |
22:35:42 | [Saint] | ...why the hell is it even using the viewport subsystem? |
22:35:50 | [Saint] | Oh. Shit. I remember. |
22:36:02 | [Saint] | Skinning the bootloader was an idea tossed around about a decade ago. |
22:36:10 | [Saint] | Probably a legacy of this. |
22:37:18 | fire2199 | pamaury : do you think for an mp3 cd player it will be a big work to write code that will handle only screen and touch buttons and audio cd playing? |
22:37:28 | [Saint] | In the SKIN_ALL_THE_THINGS period, the USB screen got /some/ support, and the bootloader didn't make it out unscathed. Of course, this was a very long time ago and I take a lot of drugs, so take that with a grain of salt. |
22:37:48 | regnarg | pamaury: Thank you, I'll try the battery first... it should not be too hard to open. If that does not help, I may investigate further. If it does, I can try discharging it again and reproducing the issue. Either way, I'll try to let you know. |
22:40:04 | pamaury | fire2199: screen and buttons don't sound too difficult, however I have no idea for cd reading, and in any case you will need to do some audio decoding which is non trivial (unless you can find some code optimised for this DSP) |
22:40:07 | _Bilgus | its nbd I was just looking through for a few bytes of no consequence |
22:45:45 | _Bilgus | like 424 bytes 7k in bss though but like I said thats all very compressible |
22:48:27 | | Join wodz [0] (~wodz@89-79-40-110.dynamic.chello.pl) |
22:50:53 | regnarg | pamaury: An unexpected turn of events: we managed to get the player to boot using the Windows firmware update tool (after about a dozen reconnects while the updater was "waiting for device")... but it seems to be very fragile because last time it did not work, even after about thirty reconnects |
22:50:59 | wodz | pamaury: I found out what made this 'special visual effect' on atj with mmu. I forgot to update function calculating PMA from VMA. It was used in setting up DMA transfer from SD. |
22:51:27 | regnarg | now it seems to have booted, the storage is visible over usb and it seems to be charging |
22:53:26 | | Quit pystar89 (Ping timeout: 260 seconds) |
22:53:40 | | Quit EmanueleSorce[m] (Ping timeout: 276 seconds) |
22:53:59 | pamaury | regnarg: good, yeah sounds like a hardware problem if it's random |
22:54:14 | | Quit walle303 (Ping timeout: 246 seconds) |
22:54:16 | pamaury | wodz: nice :) |
22:57:42 | regnarg | I remember another Zen behaving very similarly... dead after battery discharged, impossible to get it to boot but then after many retries the updater managed to bring it back to life. And another one which died in a similar way (black screen, hw recovery), but that one was replaced in warranty. It does not seem to be a single piece issue. |
22:58:44 | pamaury | it could be a flash failure as well, as least a transient one or an almost-dead storage |
22:58:57 | wodz | pamaury: Working on this I came across interesting issue. According to simplified sd protocol docs card deselect has response R1b but most common response type used is no response. ATJ doesn't mount properly if I set response to anything else then no response for deselect. |
22:59:38 | pamaury | wodz: iirc, select has response type R1b but deselect has no response |
23:00 |
23:00:43 | wodz | pamaury: I thought so too, but docs doesn't destinguish the two other then if RCA != own RCA that means deselect. |
23:00:48 | *** | Saving seen data "./dancer.seen" |
23:01:33 | | Quit PimpiN8 (Read error: Connection reset by peer) |
23:01:51 | pamaury | wodz: well yeah, all deselected card will no answer (otherwise several would try to answer at the same time) and the one selected card answers |
23:02:03 | wodz | pamaury: anyway NRSP makes sense since card should automaticaly deselect when other card on the bus is selected and in this case it should not interfere. |
23:02:58 | wodz | doc is super vague in description |
23:03:03 | pamaury | the only special thing about deselect is that selecting address 0 deselects all cards (because no card can have a RCA of 0 after init) |
23:03:17 | jhMikeS | time to flay the bootloader |
23:03:56 | | Quit Rower (Ping timeout: 260 seconds) |
23:04:50 | pamaury | wodz: why do you need to deselect the card by the way? |
23:05:00 | pamaury | (that's not really needed unless you have two cards on the same bus) |
23:05:20 | wodz | pamaury: card enters power save mode when deselected |
23:05:44 | | Join PimpiN8 [0] (~textual@145.132.155.235) |
23:06:49 | pamaury | wodz: yeah but select can be very slow as well |
23:07:27 | wodz | pamaury: just as hdd spinup yet we spin it down |
23:09:05 | pamaury | wodz: just checked by the way, on imx233 I don't expect a response on deselect, and on select there is one case where I wait for the answer and one where I don't (because then I wait for TRAN mode so send SD_STATUS, not sure if that's really legal) |
23:09:08 | | Quit lebellium (Quit: Leaving) |
23:09:11 | | Quit lebellium_ (Quit: ChatZilla 0.9.93 [Firefox 56.0.2/20171024165158]) |
23:19:01 | | Quit wodz (Quit: Leaving) |
23:19:36 | | Part robertd1 |
23:26:55 | | Join CrashBash-Kun [0] (~CrashBash@unaffiliated/crashbash-kun) |
23:28:35 | | Join walle303 [0] (walle303ke@pisg/dev/walle303) |
23:28:48 | pamaury | man Sony is braindead |
23:29:16 | pamaury | the first thing the radio driver does when one opens the device file is to mute *all audio* from all sources |
23:29:48 | pamaury | and of course it won't unmute on close but it will unmute when you set the tuning frequency using Sony's magic ioctl |
23:32:15 | pamaury | yeh \o/ now I have radio working on the NWZ \o/ |
23:43:51 | _Bilgus | how important is the usb serial descriptor? |
23:46:40 | pamaury | _Bilgus: it's quite useful actually, especially on windows, why? |
23:47:39 | _Bilgus | I was jw what the consequence of hardcoding a device descriptor for the bootloader would be across the sansa AS3514 devices would be |
23:48:09 | _Bilgus | atm we are pulling in ascodec to read that one sting |
23:48:17 | _Bilgus | string* |
23:49:12 | pamaury | _Bilgus: ideally you want the descriptor to be unique per target at least (otherwise windows may take two devices with the same serial and believe they are the same and it will not rescan the devices, this may be confusing |
23:49:39 | pamaury | maybe unique per storage size also, not sure |
23:49:53 | pamaury | for the bootloader it is not crucial that it is unique per device |
23:50:35 | _Bilgus | its only like 1/2 a KB doesn't sound like its worth the extra trouble tbh |
23:53:55 | * | pamaury goes to bed |
23:58:04 | | Quit pamaury (Ping timeout: 240 seconds) |