--- Log for 23.06.121  Server: lithium.libera.chat  Channel: #rockbox
--- Nick: rb-logbot  Version: Dancer V4.16  Started: 21 days and 11 hours ago

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.35.18 ***     No seen item changed, no save performed.
05.35.21 ***     No seen item changed, no save performed.
07.35.24 ***     No seen item changed, no save performed.
07.56.17 Quit    akaWolf (Ping timeout: 258 seconds)
08.00.51 Join    akaWolf [0] (~akaWolf@akawolf.org)
08.53.01 Quit    akaWolf (Ping timeout: 258 seconds)
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.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.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> 3Gerrit review #3497 at https://gerrit.rockbox.org/r/c/rockbox/+/3497 : 3Sansa 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.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> 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.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.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.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.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.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.08.30 Quit    lebellium (Quit: Leaving)
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.19.02 Quit    rudi_s (Ping timeout: 272 seconds)
20.19.40 Join    rudi_s [0] (~simon@user/rudi-s/x-7673890)
21.35.49 ***     Saving seen data "./dancer.seen"
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)