Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2021-06-23

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:46tomfspeachy: 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:35braewoods_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:12munkishas anyone else here tried copying large files from a computer to a SD card via a FUZE+ in bootloader usb mode?
10:34:44braewoodsmunkis: why? you need something?
10:38:17munkisevery 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:56munkisand finding out if anyone else has the same issue seems like a good starting point.
10:42:26braewoodsmunkis: i have gotten weird usb hangs if i leave my fuze+ connected for a long time
10:42:35braewoodsit panics upon allocation attempts for the buffer
10:42:51braewoodsnot in bootloader mode
10:42:54braewoodsnormal mode
10:44:38munkissounds like it's probably the same bug in the usb code.
10:45:14munkisI usually only leave it plugged in for a while while copying stuff in bootloader mode.
10:45:32braewoodsit 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:54braewoodsi'll look into it again sometime
10:46:15braewoodsi'll test it again with my new desktop build
10:46:44speachybraewoods: 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:03braewoodsspeachy: ok.. i'll look into it.
10:47:12munkisthanks for the confirmation.
10:47:14speachy(eg memcpy 32 bits into a stack-allocated variable, and then check that)
10:47:35braewoodsspeachy: which targets?
10:47:39braewoodsarmv4 PP?
10:47:43braewoodsm68k?
10:48:05braewoodsi'm used to GCC automatically handling unaligned access
10:48:10braewoodswhen packed structs are in use
10:48:15speachyarmv4/armv5 definitely, m68k (I think), and pretty sure mips too.
10:48:20braewoodsbut these aren't normal targets
10:48:34braewoodsin any case i'll test if my code works on non-x86
10:48:52braewoodsi have a problem with unaligned access because the ZIP disk structs do not naturally align with modern CPUs
10:48:52speachyunder linux the kernel is often set up to trap the faults and fix-up behind the scenes
10:49:32braewoodsmy plan is to use subroutines to copy them to an aligned version of the same struct
10:49:50braewoodsand also to deal with endianness at the same time
10:50:13braewoodsif zip is to be used on m68k, i need to account for big endian
10:53:09braewoodsspeachy: thanks, i'll test the code once i get enough of it written
10:53:25braewoodsi figured i'd have to test it anyway given i can't test it on the machine i'm writing it on
10:53:36braewoodsi mean i can to an extent but
10:53:42braewoodsdoesn'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:32desowin g#3497
11:26:34rb-bluebotGerrit review #3497 at https://gerrit.rockbox.org/r/c/rockbox/+/3497 : Sansa Connect: Implement RTC functionality by Tomasz Moń
11:27:03desowinWOuld be nice if someone could review this. Using file seems to be the only option without rewriting AVR firmware.
11:27:44desowinThe 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:32desowinthe OF even contains code to reflash AVR and there isn't any crypto going on there
11:29:31desowinit poses quite some risk though, as any invalid AVR flash will leave you without working buttons
11:29:48desowinso I decide not to deal with it
11:35:17braewoodsdesowin: 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:29braewoodsit's not a file intended to be editted by the user.
11:35:33***No seen item changed, no save performed.
11:41:12braewoodsok got a test harness written u
11:41:14braewoodsup
11:41:21desowinhow do you do that in fat file system? Isn't just putting it in .rockbox directory enough?
11:44:05braewoodsdesowin: not entirely sure but FAT does have the hidden file attribute
11:44:49braewoodsnot sure if it's exposed though
11:47:37braewoodsspeachy: is there any way to set the hidden file attribute?
11:47:51braewoodsit looks like using FAT directly is the only real option
11:48:41braewoodsdesowin: nevermind then, i was just thinking it would be best to hide the file if possible
11:48:44speachydon't see how that would be difficult, but the question is if we (and/or everyone else) actually respects that.
11:48:58braewoodslinux afaik doesn't care about hidden files
11:49:01braewoodsit just uses posix rules
11:49:11braewoodswindows does care about hidden attribute
11:49:16braewoodsi think they're the only ones that do
11:51:00braewoodsthe idea is just to protect the file against accidents
11:51:21braewoodsi guess writing to a file under the current rockbox directory is the simplest option
11:51:40braewoodsdesowin: oh, and if you're inclined, you could also add a checksum for your data payload
11:52:04braewoodsrockbox provides two crc32 algorithms
11:54:40 Quit akaWolf (Ping timeout: 265 seconds)
12:00
12:10:06braewoodsok first test works but it's aligned naturally
12:10:24braewoodstime to test it with a zip comment that's odd lengthed
12:16:30braewoodsinteresting
12:16:38braewoodsthe existing code works for my PP test unit
12:16:49braewoodsas i would expect but
12:16:59braewoodsi guess i've handled the alignment problem then?
12:17:51braewoodsspeachy: your thoughts? my code worked even though i'm not attempting to align when reading from the packed struct
12:18:09braewoodsi thought i'd get a code hang or something if i had an unaligned access
12:18:32braewoodslet me see what asm gcc is generating
12:23:33braewoodsbraewoods/rockbox/blob/microzip/firmware/common/zip.c">https://github.com/braewoods/rockbox/blob/microzip/firmware/common/zip.c
12:24:13braewoodsline 231 is where the loop i'm concerned about it
12:29:16 Join akaWolf [0] (~akaWolf@akawolf.org)
12:59:08desowinbraewoods: 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:21braewoodsi see.
13:00
13:00:32desowinfor 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:45braewoodsdesowin: why negated? why not just repeat the same thing twice?
13:01:53desowinother data uses either 5-bit CRC over 11-bit/19-bit data and actual data packets use CRC-16
13:02:19desowinbraewoods: most common noise pattern is repeated same bit, you wouldn't catch that if you didn't negate
13:02:31braewoodsi see; ok
13:03:07braewoodshuh i have my first mystery
13:03:30braewoodsfor some reason my zip code is reading the lf_offset as something non-sensical
13:03:32braewoodshm.
13:12:25braewoodsdoh. found the problem. i didn't have printf setup right.
13:31:18braewoodsah, i see. gcc is dealing with the unaligned access transparently
13:31:20braewoodsgo figure.
13:32:46braewoodsdone for now
13:34:19braewoodsi'll let it setup an m68k toolchain and try on my h120
13:34:59braewoodswrote 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:57braewoodsspeachy: 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:23braewoodsbut afaik zip already records timestamps in the main header
15:43:27braewoodsso not sure what value it offers
15:46:40braewoodsinteresting. the zip archive's time fields are the same as FATs.
15:46:48braewoodsi 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:01munkisI 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)

Previous day | Next day