| 01:00 |
| 01:16:39 | | Join tomf [0] (tomf@our.lady.of.perpetual.faith) |
| 01:35:14 | *** | No seen item changed, no save performed. |
| 01:54:46 | tomf | speachy: thanks for fixing the iflash stuff! this is magical |
| 01:54:58 | | Join _bilgus [0] (~bilgus@162.154.213.134) |
| 03:00 |
| 03:35:18 | *** | No seen item changed, no save performed. |
| 05:00 |
| 05:35:21 | *** | No seen item changed, no save performed. |
| 07:00 |
| 07:35:24 | *** | No seen item changed, no save performed. |
| 07:56:17 | | Quit akaWolf (Ping timeout: 258 seconds) |
| 08:00 |
| 08:00:51 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 08:53:01 | | Quit akaWolf (Ping timeout: 258 seconds) |
| 09:00 |
| 09:00:51 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 09:01:35 | braewoods | _bilgus: question about unaligned memory access. i need to check a signature in a packed struct before i know i've found it. will this pose a problem for ARM if i just keep searching without care for alignment? the compiler should already be dealing with it since the struct type is packed but i don't deal with this very often. |
| 09:15:00 | | Quit skrzyp (Ping timeout: 252 seconds) |
| 09:16:52 | | Join skrzyp [0] (~skrzyp@skrzyp.net) |
| 09:35:28 | *** | Saving seen data "./dancer.seen" |
| 10:00 |
| 10:19:52 | | Join toffe82 [0] (~kvirc@c-67-174-59-249.hsd1.ca.comcast.net) |
| 10:33:12 | munkis | has anyone else here tried copying large files from a computer to a SD card via a FUZE+ in bootloader usb mode? |
| 10:34:44 | braewoods | munkis: why? you need something? |
| 10:38:17 | munkis | every time I do it my fuze+ crashes (often hard enough that it wont hard reset until the batt drains), an I am trying to figure out if it is A: my fuze+, B: all fuze+s, C: the rockbox bootloader, D: my bootloader which may be modified, or E: something else. |
| 10:38:56 | munkis | and finding out if anyone else has the same issue seems like a good starting point. |
| 10:42:26 | braewoods | munkis: i have gotten weird usb hangs if i leave my fuze+ connected for a long time |
| 10:42:35 | braewoods | it panics upon allocation attempts for the buffer |
| 10:42:51 | braewoods | not in bootloader mode |
| 10:42:54 | braewoods | normal mode |
| 10:44:38 | munkis | sounds like it's probably the same bug in the usb code. |
| 10:45:14 | munkis | I usually only leave it plugged in for a while while copying stuff in bootloader mode. |
| 10:45:32 | braewoods | it was also on a host known to have random issues with USB devices so may have been that was triggering weird stuff in rockbox |
| 10:45:54 | braewoods | i'll look into it again sometime |
| 10:46:15 | braewoods | i'll test it again with my new desktop build |
| 10:46:44 | speachy | braewoods: btw, wrt unaligned accesses, packed structs won't help you, you have to write your code assuming bytewise access/comparisons as you can't rely un unaligned loads on a large number of our targets. |
| 10:47:03 | braewoods | speachy: ok.. i'll look into it. |
| 10:47:12 | munkis | thanks for the confirmation. |
| 10:47:14 | speachy | (eg memcpy 32 bits into a stack-allocated variable, and then check that) |
| 10:47:35 | braewoods | speachy: which targets? |
| 10:47:39 | braewoods | armv4 PP? |
| 10:47:43 | braewoods | m68k? |
| 10:48:05 | braewoods | i'm used to GCC automatically handling unaligned access |
| 10:48:10 | braewoods | when packed structs are in use |
| 10:48:15 | speachy | armv4/armv5 definitely, m68k (I think), and pretty sure mips too. |
| 10:48:20 | braewoods | but these aren't normal targets |
| 10:48:34 | braewoods | in any case i'll test if my code works on non-x86 |
| 10:48:52 | braewoods | i have a problem with unaligned access because the ZIP disk structs do not naturally align with modern CPUs |
| 10:48:52 | speachy | under linux the kernel is often set up to trap the faults and fix-up behind the scenes |
| 10:49:32 | braewoods | my plan is to use subroutines to copy them to an aligned version of the same struct |
| 10:49:50 | braewoods | and also to deal with endianness at the same time |
| 10:50:13 | braewoods | if zip is to be used on m68k, i need to account for big endian |
| 10:53:09 | braewoods | speachy: thanks, i'll test the code once i get enough of it written |
| 10:53:25 | braewoods | i figured i'd have to test it anyway given i can't test it on the machine i'm writing it on |
| 10:53:36 | braewoods | i mean i can to an extent but |
| 10:53:42 | braewoods | doesn't give a complete picture |
| 11:00 |
| 11:04:27 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 11:26:32 | desowin | g#3497 |
| 11:26:34 | rb-bluebot | Gerrit review #3497 at https://gerrit.rockbox.org/r/c/rockbox/+/3497 : Sansa Connect: Implement RTC functionality by Tomasz Moń |
| 11:27:03 | desowin | WOuld be nice if someone could review this. Using file seems to be the only option without rewriting AVR firmware. |
| 11:27:44 | desowin | The only problem with rewriting AVR firmware is huge effort versus not so big payoff (IMHO, but maybe there's someone who wants to learn RE and will pick it up...) |
| 11:28:32 | desowin | the OF even contains code to reflash AVR and there isn't any crypto going on there |
| 11:29:31 | desowin | it poses quite some risk though, as any invalid AVR flash will leave you without working buttons |
| 11:29:48 | desowin | so I decide not to deal with it |
| 11:35:17 | braewoods | desowin: suggestion if you're not doing it already. mark the file as hidden and maybe even give it a unix hidden file prefix. |
| 11:35:29 | braewoods | it's not a file intended to be editted by the user. |
| 11:35:33 | *** | No seen item changed, no save performed. |
| 11:41:12 | braewoods | ok got a test harness written u |
| 11:41:14 | braewoods | up |
| 11:41:21 | desowin | how do you do that in fat file system? Isn't just putting it in .rockbox directory enough? |
| 11:44:05 | braewoods | desowin: not entirely sure but FAT does have the hidden file attribute |
| 11:44:49 | braewoods | not sure if it's exposed though |
| 11:47:37 | braewoods | speachy: is there any way to set the hidden file attribute? |
| 11:47:51 | braewoods | it looks like using FAT directly is the only real option |
| 11:48:41 | braewoods | desowin: nevermind then, i was just thinking it would be best to hide the file if possible |
| 11:48:44 | speachy | don't see how that would be difficult, but the question is if we (and/or everyone else) actually respects that. |
| 11:48:58 | braewoods | linux afaik doesn't care about hidden files |
| 11:49:01 | braewoods | it just uses posix rules |
| 11:49:11 | braewoods | windows does care about hidden attribute |
| 11:49:16 | braewoods | i think they're the only ones that do |
| 11:51:00 | braewoods | the idea is just to protect the file against accidents |
| 11:51:21 | braewoods | i guess writing to a file under the current rockbox directory is the simplest option |
| 11:51:40 | braewoods | desowin: oh, and if you're inclined, you could also add a checksum for your data payload |
| 11:52:04 | braewoods | rockbox provides two crc32 algorithms |
| 11:54:40 | | Quit akaWolf (Ping timeout: 265 seconds) |
| 12:00 |
| 12:10:06 | braewoods | ok first test works but it's aligned naturally |
| 12:10:24 | braewoods | time to test it with a zip comment that's odd lengthed |
| 12:16:30 | braewoods | interesting |
| 12:16:38 | braewoods | the existing code works for my PP test unit |
| 12:16:49 | braewoods | as i would expect but |
| 12:16:59 | braewoods | i guess i've handled the alignment problem then? |
| 12:17:51 | braewoods | speachy: your thoughts? my code worked even though i'm not attempting to align when reading from the packed struct |
| 12:18:09 | braewoods | i thought i'd get a code hang or something if i had an unaligned access |
| 12:18:32 | braewoods | let me see what asm gcc is generating |
| 12:23:33 | braewoods | braewoods/rockbox/blob/microzip/firmware/common/zip.c">https://github.com/braewoods/rockbox/blob/microzip/firmware/common/zip.c |
| 12:24:13 | braewoods | line 231 is where the loop i'm concerned about it |
| 12:29:16 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 12:59:08 | desowin | braewoods: there's no point in calculating 4-byte CRC over 4-byte payload. In such case just saving the value and its negated form is better (if you actually want some kind of corruption detection) |
| 12:59:21 | braewoods | i see. |
| 13:00 |
| 13:00:32 | desowin | for example in USB 2.0 (and 1.1 and 1.0) packet the PID is 4-bit and because it is extremely important, it is sent in both normal and negated form (and thus taking one byte) |
| 13:01:45 | braewoods | desowin: why negated? why not just repeat the same thing twice? |
| 13:01:53 | desowin | other data uses either 5-bit CRC over 11-bit/19-bit data and actual data packets use CRC-16 |
| 13:02:19 | desowin | braewoods: most common noise pattern is repeated same bit, you wouldn't catch that if you didn't negate |
| 13:02:31 | braewoods | i see; ok |
| 13:03:07 | braewoods | huh i have my first mystery |
| 13:03:30 | braewoods | for some reason my zip code is reading the lf_offset as something non-sensical |
| 13:03:32 | braewoods | hm. |
| 13:12:25 | braewoods | doh. found the problem. i didn't have printf setup right. |
| 13:31:18 | braewoods | ah, i see. gcc is dealing with the unaligned access transparently |
| 13:31:20 | braewoods | go figure. |
| 13:32:46 | braewoods | done for now |
| 13:34:19 | braewoods | i'll let it setup an m68k toolchain and try on my h120 |
| 13:34:59 | braewoods | wrote a basic test harness that tests reading the basic headers of a ZIP file |
| 13:35:37 | *** | Saving seen data "./dancer.seen" |
| 14:00 |
| 14:05:39 | | Quit akaWolf (Ping timeout: 265 seconds) |
| 14:12:18 | | Part toffe82 (Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is) |
| 14:18:24 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 15:00 |
| 15:08:18 | | Quit _bilgus (Ping timeout: 258 seconds) |
| 15:35:41 | *** | Saving seen data "./dancer.seen" |
| 15:42:57 | braewoods | speachy: i found a small optimization we can make to how we use zip to create archives. if you pass -x you'll disable the addition of optional extra fields, reducing the size of the archive a bit. zip by default includes extra timestamps in this area that adds 24 bytes per file or directory. |
| 15:43:23 | braewoods | but afaik zip already records timestamps in the main header |
| 15:43:27 | braewoods | so not sure what value it offers |
| 15:46:40 | braewoods | interesting. the zip archive's time fields are the same as FATs. |
| 15:46:48 | braewoods | i can reuse the FAT function for time conversion |
| 15:49:03 | | Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:2111:7e93:c689:b81) |
| 15:50:44 | | Quit akaWolf (Ping timeout: 250 seconds) |
| 16:00 |
| 16:06:29 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 16:25:05 | | Join JanC_ [0] (~janc@user/janc) |
| 16:25:51 | | Quit JanC (Killed (NickServ (GHOST command used by JanC_))) |
| 16:26:07 | | Nick JanC_ is now known as JanC (~janc@user/janc) |
| 17:00 |
| 17:23:23 | | Quit fmlatghor (Remote host closed the connection) |
| 17:23:48 | | Join fmlatghor [0] (~lcoogan@2601:5cd:8100:2890:9220:3aff:fe1a:350d) |
| 17:30:17 | | Quit ufdm (Read error: Connection reset by peer) |
| 17:35:43 | *** | Saving seen data "./dancer.seen" |
| 17:41:49 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 17:56:47 | | Join _bilgus [0] (~bilgus@162.154.213.134) |
| 18:00 |
| 18:08:30 | | Quit lebellium (Quit: Leaving) |
| 19:00 |
| 19:17:48 | | Quit reductum (Quit: WeeChat 2.8) |
| 19:18:27 | | Join reductum [0] (~reductum@cpe-72-134-86-174.natsow.res.rr.com) |
| 19:35:46 | *** | Saving seen data "./dancer.seen" |
| 19:39:01 | munkis | I am impressed full brightness and it still hasn't died. |
| 20:00 |
| 20:19:02 | | Quit rudi_s (Ping timeout: 272 seconds) |
| 20:19:40 | | Join rudi_s [0] (~simon@user/rudi-s/x-7673890) |
| 21:00 |
| 21:35:49 | *** | Saving seen data "./dancer.seen" |
| 23:00 |
| 23:35:53 | *** | No seen item changed, no save performed. |
| 23:56:02 | | Join f1reflyylmao [0] (~f1refly@p4fc47d44.dip0.t-ipconnect.de) |
| 23:57:06 | | Quit f1refly (Ping timeout: 268 seconds) |
| 23:57:06 | | Nick f1reflyylmao is now known as f1refly (~f1refly@p4fc47d44.dip0.t-ipconnect.de) |
icon identifies that the person is a core developer (has commit access).