| 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:00 |
| 01:25:34 | | Quit _meg (Ping timeout: 240 seconds) |
| 01:26:01 | | Join _meg [0] (~notsure@211.25.203.45) |
| 01:39:10 | | Join Strife1989 [0] (~quassel@adsl-98-80-194-40.mcn.bellsouth.net) |
| 01:42:29 | | Quit Strife89 (Ping timeout: 240 seconds) |
| 01:45:52 | *** | Saving seen data "./dancer.seen" |
| 02:00 |
| 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 | __builtin | yay, Duke Nukem's sound works properly now :) |
| 02:53:23 | __builtin | unaligned accesses breaking everything again |
| 03:00 |
| 03:25:47 | Aldem | Hail to the king |
| 03:27:55 | __builtin | only some sounds, though |
| 03:28:00 | __builtin | others are mysteriously absent |
| 03:28:14 | __builtin | probably more alignment issues |
| 03:41:22 | __builtin | hmm, 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 | __builtin | ok, looks like the fault is working properly |
| 04:00 |
| 04:09:06 | __builtin | but it's not displaying a panic screen like it should :( |
| 04:09:35 | __builtin | any ideas why? |
| 04:12:55 | | Join Strife89 [0] (~quassel@adsl-98-80-186-250.mcn.bellsouth.net) |
| 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 | __builtin | great, looks like the fault is in tlsf |
| 05:00 |
| 05:45:55 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 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@211.25.203.45) |
| 06:21:05 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 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:00 |
| 07:05:21 | | Quit alexweissman (Remote host closed the connection) |
| 07:06:15 | | Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) |
| 07:45:56 | *** | Saving seen data "./dancer.seen" |
| 07:59:27 | | Quit alexweissman (Remote host closed the connection) |
| 08:00 |
| 08:39:28 | | Quit dys (Ping timeout: 248 seconds) |
| 09:00 |
| 09:01:15 | | Quit JanC (Killed (hobana.freenode.net (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:00 |
| 10:07:39 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 10:10:42 | | Join lebellium [0] (~chatzilla@89-93-177-206.hfc.dyn.abo.bbox.fr) |
| 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@211.25.203.45) |
| 10:34:51 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 10:59:49 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 11:00 |
| 11:22:59 | lebellium | pamaury: what is "vol: X dB" for in the debug menu? |
| 11:24:51 | pamaury | lebellium: 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:28 | lebellium | so it's supposed to stay at 0 dB? |
| 11:27:10 | pamaury | I 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:18 | lebellium | well, normal users shouldn't go to the debug menu |
| 11:28:42 | lebellium | you only need to bother with my questions :P |
| 11:29:57 | pamaury | basically 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:37 | pamaury | Also 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:51 | lebellium | I hate this *panic* invalid pcm alsa volume screen when I go too up :P |
| 11:34:37 | pamaury | it's a debug menu, you are not allowed to complain :-p |
| 11:35:00 | lebellium | that's right |
| 11:46:04 | *** | Saving seen data "./dancer.seen" |
| 11:46:46 | | Join CH23 [0] (56580a02@gateway/web/freenode/ip.86.88.10.2) |
| 11:51:28 | lebellium | pamaury: 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:07 | CH23 | Bilgus: 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:31 | CH23 | this is when using internal OS |
| 11:57:40 | pamaury | lebellium: most Sony's clip at high volume anyway |
| 11:58:15 | lebellium | max volume in OF is the same as in Rockbox with acoustic=off but the volume curve is more like acoustic=on |
| 11:58:18 | lebellium | it's strange |
| 11:59:04 | | Quit jhMikeS (Ping timeout: 240 seconds) |
| 11:59:31 | CH23 | it doesn't do this on bootloader v4.0, so it might be multiboot related |
| 11:59:42 | pamaury | max 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:54 | pamaury | at least on pre-A10 devices |
| 12:00 |
| 12:00:38 | lebellium | ok |
| 12:01:07 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 12:01:43 | pamaury | but 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:30 | lebellium | volume 10/30 in OF is more or less like -15 or -20dB in Rockbox with acoustic=off, |
| 12:07:17 | lebellium | so it's a weird volume curve |
| 12:07:39 | lebellium | you have a very large quiet range from -100dB to -20dB |
| 12:09:17 | | Part robertd1 |
| 12:09:31 | | Join robertd1 [0] (~root@201.242.176.168) |
| 12:21:10 | pamaury | iirc there is a mistake in my digital volume code. It goes 2dB steps are a time instead of 1dB |
| 12:50:32 | robertd1 | strange fatal error: bitmaps/rockboxicon.h: No such file or directory |
| 12:52:45 | pamaury | robertd1: what are you building? try "make clean" |
| 12:54:32 | robertd1 | hi Pamaury. I was building the bootloader thanks |
| 12:56:09 | robertd1 | yes, that did it |
| 12:58:12 | CH23 | speaking 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:00 |
| 13:06:00 | pamaury | CH23: no it doesn't work like that |
| 13:08:47 | pamaury | one has to use mkamsboot to create a flashable firmware |
| 13:09:28 | pamaury | I 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:30 | CH23 | pamaury: would i still be able to recover via the hardware shorting? |
| 13:33:21 | pamaury | CH23: I think so but you better ask the people that actually know the clip+ ad friends |
| 13:34:12 | CH23 | i'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:47 | CH23 | nailed it. hah. |
| 13:51:55 | CH23 | Bilgus: 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:25 | robertd1 | i dont know if it is a placebo effect but the walkman sounds much better with rockbox installed |
| 14:00 |
| 14:16:58 | | Quit _meg (Ping timeout: 240 seconds) |
| 14:19:54 | | Join _meg [0] (~notsure@211.25.203.45) |
| 14:26:50 | | Join Bilgus_PH [0] (41ba23be@gateway/web/freenode/ip.65.186.35.190) |
| 14:27:15 | CH23 | it seems that the kernel panic only occurs when multiboot loader is used, in combination with multiboot firmware, running on the internal memory |
| 14:27:52 | CH23 | multiboot firmware on internal memory with regular bootloader has no effect |
| 14:27:58 | Bilgus_PH | CH23: I'm pretty sure the only way the bootloader could cause a panic would be in the bootloader USB mode |
| 14:28:24 | Bilgus_PH | the multiboot firmware OTOH yes I could see that |
| 14:29:54 | Bilgus_PH | but 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:33 | CH23 | if there's anything i could help you with, just let me know |
| 14:30:59 | Bilgus_PH | Now the question would be do you see it when using the multiboot bootloader and a non multiboot FW on internal memory..\ |
| 14:31:36 | CH23 | i'll test it |
| 14:32:35 | Bilgus_PH | As 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:01 | Bilgus_PH | and that filesystem is his baby as well amongst other things |
| 14:34:49 | Bilgus_PH | Btw CH23 thanks for testing its always good to have more eyes on it :) |
| 14:35:33 | CH23 | i can't program but i still want to contribute some of my time into rockbox |
| 14:37:15 | CH23 | and considering i paid ridiculously little for the 2 clip+'s i have, i wouldn't mind one getting bricked too much |
| 14:37:20 | Bilgus_PH | MANULAS! |
| 14:37:26 | Bilgus_PH | MANUALS lol |
| 14:37:58 | CH23 | manuals sounds like something i could write. |
| 14:39:34 | Bilgus_PH | the fomat for them is a little funky like a mix between html and qbasic its called Latex not too bad though |
| 14:40:28 | CH23 | never worked with LaTex but i'm aware of its existence |
| 14:40:49 | CH23 | also yes, with default firmware on multibootloader it also panics |
| 14:45:21 | Bilgus_PH | ok 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:27 | Bilgus_PH | HMm 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:14 | CH23 | i did |
| 14:47:27 | CH23 | brb |
| 14:47:46 | Bilgus_PH | assuming 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:11 | Bilgus_PH | and 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:00 |
| 15:02:08 | Bilgus_PH | yeah 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.62.140.137.90) |
| 15:10:48 | CH23 | Bilgus_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:01 | CH23 | i should look into this |
| 15:12:07 | Bilgus_PH | I used to do that too until I learned git |
| 15:12:41 | Bilgus_PH | You still get into clusters everyonce in a while but its pretty easy |
| 15:13:41 | Bilgus_PH | plus you have a nice repository of everything you've done |
| 15:14:00 | CH23 | i made my life easy, i created a few shell scripts to build and install the different things |
| 15:14:53 | Bilgus_PH | yeah I think I saw you firmware building one a while back.. Whatever works :) |
| 15:15:05 | CH23 | so one for normal bootloader, one for multibootloader, one for fw, one for multi fw, and then two to only build, not install |
| 15:15:21 | CH23 | idk i shouldn't do this because i use up server time for each build |
| 15:19:19 | CH23 | i noticed with mkamsboot, that firmware 01-02-18 isn't supported, is there a specific reason for that? |
| 15:19:49 | Bilgus_PH | someone didn't test it with that version so didn't put in the header for it |
| 15:20:22 | Bilgus_PH | like 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.65.186.35.190) |
| 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.62.140.137.90) |
| 15:49:47 | Bilgus_PH | CH23 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:00 |
| 16:02:24 | CH23 | mkamsboot 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] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) |
| 16:13:47 | | Quit alexweissman (Remote host closed the connection) |
| 16:14:04 | | Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) |
| 16:19:18 | | Join Bilgus_PH [0] (4cf32773@gateway/web/freenode/ip.76.243.39.115) |
| 16:19:42 | Bilgus_PH | CH23 it is pretty arbritrary to add another FW into the mkams utility |
| 16:20:20 | CH23 | half-half expected that. |
| 16:20:33 | Bilgus_PH | you would just need to test that it actually worked |
| 16:20:38 | Bilgus_PH | https://github.com/Rockbox/rockbox/blob/master/rbutil/mkamsboot/mkamsboot.c |
| 16:23:42 | CH23 | { MODEL_CLIPPLUS, "01.02.18", "80b547244438b113e2a55ff0305f12c0" }, |
| 16:24:02 | CH23 | it's in there already? |
| 16:24:47 | CH23 | I think it was never updated on the rockbox site |
| 16:26:29 | Bilgus_PH | huh thats kinda odd oh you downloaded it not built it?! |
| 16:26:51 | Bilgus_PH | I guess that makes sense |
| 16:28:34 | CH23 | i don't always build everything :P |
| 16:28:55 | CH23 | i expect the site to contain up to date versions of tools |
| 16:29:49 | Bilgus_PH | yeah 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:19 | CH23 | i'll see if i can build it |
| 16:30:45 | Bilgus_PH | IIRC there are instructions somewhere |
| 16:32:00 | CH23 | it's done already. |
| 16:32:46 | Bilgus_PH | nice :) |
| 16:33:56 | CH23 | and it works. |
| 16:36:16 | CH23 | is it worth rechecking the multi/singleboot stuff? |
| 16:37:21 | Bilgus_PH | well if it panics on usb pull then yeah |
| 16:38:18 | Bilgus_PH | I'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:49 | Bilgus_PH | so I guess build the DEV version of the bootloader w/o the multiboot patches and see if it still happens |
| 16:39:46 | CH23 | i think what happens is that the multifirmware hooks into the multibootloader and on unplug it is confused on which memory it operates |
| 16:40:46 | CH23 | i have nothing to back up this idea |
| 16:40:50 | Bilgus_PH | well see I can see it with the firmware but you siad it happens with the multibootloader and regular FW on internal memory |
| 16:41:27 | CH23 | i'll rerun all cases to make sure i wasn't mixing up things |
| 16:41:31 | Bilgus_PH | the bootloader literally just loads the firmware into memory |
| 16:41:40 | Bilgus_PH | and then its done |
| 16:41:51 | Bilgus_PH | control never ever returns to it |
| 16:42:43 | Bilgus_PH | so 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:00 |
| 17:15:06 | CH23 | ...and now it all works? not quite sure why. |
| 17:20:58 | Bilgus_PH | well 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:29 | Bilgus_PH | basically the multiboot bootloader and a regular FW on internal drive |
| 17:22:13 | Bilgus_PH | I can totally see the multiboot FW causing it no matter which bootloader because its a WIP |
| 17:22:40 | CH23 | i tried the following combinations: mbl+mfw , mbl+rfw , rbl+rfw , rbl+mfw (all internal) |
| 17:23:48 | CH23 | mbl = multi boot loader, mfw = multi firmware, rbl = regular boot loader, rfw = regular firmware |
| 17:24:09 | Bilgus_PH | ok 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:58 | Bilgus_PH | figure when you plug the usb the sdcard is unmounted from the fw and mounted for the USB |
| 17:25:18 | CH23 | it happened when using the internal flash |
| 17:25:42 | Bilgus_PH | now 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:25:49 | Bilgus_PH | hmm |
| 17:26:08 | Bilgus_PH | could just be random |
| 17:26:09 | CH23 | before this i used the bootloader firmware you uploaded, from february i believe |
| 17:26:27 | CH23 | it happened every time, on both of my devices |
| 17:26:44 | Bilgus_PH | I have changed a few things since feb but nothing that really affected the operation |
| 17:27:04 | Bilgus_PH | try putting it backl and see if it happens again maybe? |
| 17:27:15 | CH23 | yeah trying to find yours again |
| 17:28:18 | Bilgus_PH | https://www.mediafire.com/folder/bt7aow95pwlo8/MultiBoot_Bootloaders |
| 17:28:25 | CH23 | thanks |
| 17:28:58 | Bilgus_PH | no thank you :) |
| 17:31:02 | CH23 | ha! |
| 17:31:32 | CH23 | whatever happened between your version and the current one, it was enough to make it not panic |
| 17:31:47 | __builtin | ah, I think I found the bug in duke :) |
| 17:33:54 | CH23 | this is multibootfirmware 2017-10-08 + multibootloader 2017-02-10 on internal, no SD present |
| 17:34:56 | Bilgus_PH | ok 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:34 | Bilgus_PH | __builtin: more unaligned memory accesses? |
| 17:35:57 | __builtin | kind of |
| 17:36:22 | __builtin | It was my fault this time, I *thought* I was fixing the unaligned accesses but I changed some things I shouldn't have |
| 17:36:33 | Bilgus_PH | It seems like duke would be a very mature codebase is this just because its running on ARM? |
| 17:36:36 | Bilgus_PH | ah ok |
| 17:36:42 | __builtin | yes |
| 17:37:23 | __builtin | see http://gerrit.rockbox.org/r/#/c/1664/7..8/apps/plugins/sdl/tests/duke3d/Game/src/audiolib/multivoc.c line 731-732 |
| 17:37:45 | __builtin | I shouldn't have changed those two lines, since they were just reading a byte value |
| 17:38:44 | __builtin | If 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:58 | Bilgus_PH | doesn't all that conversion from BE to LE make it slow? |
| 17:43:21 | __builtin | yes, but it's necessary |
| 17:43:36 | __builtin | though it's not converting, per se |
| 17:43:49 | __builtin | (the data's already little-endian in memory) |
| 17:43:59 | CH23 | i'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:26 | Bilgus_PH | well 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:28 | CH23 | so 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:28 | Bilgus_PH | __builtin: oh i see you are shifting the address so the code calls the right memory location |
| 17:47:01 | __builtin | yeah, 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:06 | Bilgus_PH | CH23 the MFW isn't really a issue thats really not the final code the bootloader OTOH is important |
| 17:53:35 | CH23 | OTOH meaning? |
| 17:53:54 | Bilgus_PH | on the other hand |
| 17:53:57 | CH23 | ah |
| 17:54:42 | Bilgus_PH | now does the MFW panic if its on the internal memory? |
| 18:00 |
| 18:01:18 | __builtin | crap, Timidity isn't closing its files properly :( |
| 18:01:29 | CH23 | the plot thickens. they both panic again, using todays dev+multi for both bootloader and firmware |
| 18:01:48 | CH23 | i wonder if it's due to my laptop now |
| 18:12:28 | __builtin | aha, I can blame stdio_wrapper :) |
| 18:13:22 | __builtin | \o/ music works :) |
| 18:18:20 | __builtin | on target, too! :D |
| 18:20:26 | CH23 | Bilgus_PH: what do error codes mean to you? |
| 18:35:41 | CH23 | the conclusion of this whole thing: multiboot firmware should only go on micro SDs, all else is fine. |
| 18:41:31 | Bilgus_PH | well the MFW has a wip filesystem rewrite so not entirely unexpected |
| 18:44:09 | CH23 | i'm very happy with it as it is, there's not really a reason to use the MFW internally anyway |
| 18:45:10 | CH23 | as long as the MBL works as it should |
| 19:00 |
| 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] (~u@h-152-82.A586.priv.bahnhof.se) |
| 19:46:15 | *** | Saving seen data "./dancer.seen" |
| 20:00 |
| 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] (~wodz@89-79-40-110.dynamic.chello.pl) |
| 20:46:40 | wodz | pamaury: ping |
| 20:54:14 | pamaury | wodz: pong |
| 20:55:40 | pamaury | wodz: 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:45 | wodz | pamaury: 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:00 |
| 21:01:25 | wodz | pamaury: 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:57 | wodz | picked 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] (~quassel@adsl-98-67-57-151.mcn.bellsouth.net) |
| 21:08:09 | | Quit Strife89 (Ping timeout: 255 seconds) |
| 21:15:04 | | Join LjL [0] (~ljl@unaffiliated/ljl) |
| 21:19:53 | | Join Strife89 [0] (~quassel@adsl-98-80-190-60.mcn.bellsouth.net) |
| 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] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) |
| 22:00 |
| 22:00:35 | | Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-mfguawsxyazacdjy) |
| 22:06:03 | | Quit wodz (Quit: Leaving) |
| 22:08:57 | | Quit Strife89 (Ping timeout: 240 seconds) |
| 22:09:09 | | Join Strife89 [0] (~quassel@adsl-98-80-191-4.mcn.bellsouth.net) |
| 22:28:41 | | Join Halamix2 [0] (~Halamix2@unaffiliated/halamix2) |
| 23:00 |
| 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] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
icon identifies that the person is a core developer (has commit access).