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).

#rockbox log for 2021-07-02

00:37:54 Quit munkis (Remote host closed the connection)
00:38:30 Join munkis [0] (
00:58:53__builtinkirvesAxe: try moving one of those ogg files somewhere else
01:04:25***Saving seen data "./dancer.seen"
01:12:48 Quit pixelma (Quit: .)
01:12:48 Quit amiconn (Quit: - Chat comfortably. Anywhere.)
01:13:02 Join pixelma [0] (
01:13:02 Join amiconn [0] (
01:13:54 Quit amiconn (Client Quit)
01:13:54 Quit pixelma (Client Quit)
01:16:23 Join amiconn [0] (
01:16:24 Join pixelma [0] (
01:16:42 Quit munkis (Ping timeout: 240 seconds)
01:23:36 Join munkis [0] (
02:36:59braewoods_bilgus: well it probably is. i just wanted to be able to take a buffer allocated in whatever setup or so and sub-divide it as needed.
02:37:28braewoodsso the user is free to choose how the main allocation is acquire
02:37:41braewoodsacquired since zip support needs much higher temporary storage than most
02:38:18braewoodsthis is also intended for bootloader use so it was easier for me to do it this way
02:38:39braewoodsso it works equally with a static buffer and dynamic buffer
02:39:36braewoodsi also admit i don't know how buflib even works.
02:39:41braewoodsi thought it was a malloc like clone.
02:40:03braewoodsso i assumed it would fragment and more.
02:51:47braewoods_bilgus: i was making my choice based on what i saw in usb_storage which needs a similar buffer.
02:52:11braewoods__builtin: it uses a static one when BOOTLOADER is defined or so. the core_alloc otherwise.
02:52:59braewoodsso i thought that for some older bootloaders, core_alloc was not available or something.
03:04:26***Saving seen data "./dancer.seen"
03:25:20 Join kadoban [0] (~kadoban@user/kadoban)
03:29:05 Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7)
03:45:59 Quit kadoban (Quit: Client limit exceeded: 20000)
03:58:56 Quit blbro[m] (Remote host closed the connection)
03:59:53 Join kadoban [0] (~kadoban@user/kadoban)
04:05:51 Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7)
04:20:23 Quit kadoban (Quit: Client limit exceeded: 20000)
04:32:38 Quit blbro[m] (Remote host closed the connection)
04:33:10 Join kadoban [0] (~kadoban@user/kadoban)
04:34:12 Quit ufdm (Read error: Connection reset by peer)
04:39:20 Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7)
04:40:24 Quit blbro[m] (Remote host closed the connection)
04:40:24 Quit kadoban (Read error: Connection reset by peer)
04:44:31 Join ufdm [0] (
05:04:27***Saving seen data "./dancer.seen"
05:05:50 Join kadoban [0] (~kadoban@user/kadoban)
05:11:56 Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7)
06:00:51 Quit akaWolf (Ping timeout: 268 seconds)
06:07:04desowin- g#3515
06:07:08rb-bluebotGerrit review #3515 at : Sansa Connect: Initial libertas WiFi driver port by Tomasz Moń
06:07:24 Nick desowin- is now known as desowin (
06:08:02desowinno DMA yet but that's way too big already
06:09:10desowinand yes, that's definitely 802.11b/g
06:12:16 Join tomato6 [0] (~tomato@user/tomato)
06:13:39 Quit tomato (Ping timeout: 256 seconds)
06:13:40 Nick tomato6 is now known as tomato (~tomato@user/tomato)
06:22:29 Join akaWolf [0] (
07:04:31***Saving seen data "./dancer.seen"
07:16:09 Quit akaWolf (Ping timeout: 258 seconds)
07:41:32braewoodsoh, interesting.
07:44:10braewoodsspeachy: since rockbox's file APIs use 32 bit signed integers for many things, is it even possible to address files beyond the 2GB barrier?
07:44:41braewoodsi know the underlying FS supports up to 4GBish files
07:50:46 Join massiveH [0] (
07:51:54 Join akaWolf [0] (
08:25:50_bilgusbraewoods, I think buflib allows you to use a region as a sub region with a bit of wasted space for book keeping.. it will for sure fragment
08:26:46_bilgusso will your stack based alloc I imagine unless you have a strict ordering
09:01:12 Quit massiveH (Quit: Leaving)
09:04:35***Saving seen data "./dancer.seen"
09:25:49braewoods_bilgus: ok, i'll switch to buflib. i just was concerned about it being too slow or so.
09:32:15desowinwould be really nice if someone could review the wifi driver. I think the code as-is is good to go, as that's definitely a milestone
09:32:46desowinthis is special as it is the first non-free firmware blob in Rockbox
09:35:56speachydesowin: Freely redistributable?
09:36:20speachywe do tend to make a point to separate out blobs as separate downloads.
09:38:12speachyok, 3-clause BSD. We won't have a Connect manual yet, but once we do we'd need to reproduce that notice in there.
09:39:09speachydesowin: so just for my own sanity, all this driver does is put the wifi module to sleep? Have you measured the power consumption difference?
09:43:14_bilgusbraewoods, dont take that as discouragement if you wanna roll your own more power to you
09:43:49_bilgusbuflib is already written though and (mostly??) bug free
09:45:59_bilguspictureflow uses it in the manner you describe although it is a fixed secondary block sized IIRC so TLSF probably excels in that scenario
09:46:45_bilguslike we alloc 1 mb and split it into new alloc pools
09:50:39desowinspeachy: currently there's a #if 0 at the bottom, because if the firmware is loaded (and not configured - which requires the rest of driver to be ported) the power consumption is over 50 mA more
09:51:21desowinyes, the blob is redistribuable, but not really 3-clause BSD as it prohibits reverse engineering
09:52:20desowinI don't think you have to put it in the manual, currently the license is copied alongside binary, which fullfils the requirements
09:52:57_bilgusbraewoods, uh nm buflib is not using TLSF as the backend
09:53:18braewoodsi see.
09:53:45_bilgusnot that you can't still use it its just not in core I think
09:54:23desowinspeachy: but the big thing is that this patch has fully working spi communication as otherwise the firmware loading fails
09:54:58_bilgusbuflib appears far more primitive
09:57:52desowinthe byte ordering was really confusing, but the target chip is little endian, and the data is little endian, but transmitted in 16-bit words, MSB first
09:58:42desowinand this implementation is correct, because it needs to flip both the register addresses and value *and* the contents of firmware blobs
09:59:06desowinhopefully DMA can be configured to do that swapping
09:59:25speachyyeah, I've emitted many an expletive over SPI-attached wifi module data ordering
10:00:30speachybtw, the patch as a whole looks sane, just one minor comment in case HAVE_WIFI is not set.
10:01:49 Quit shifttym1ke (Read error: No route to host)
10:02:18braewoods_bilgus: fair enough. my main issue is needing larger temporary memory that varies in size depending on the file data.
10:02:32braewoodszip files support filenames up to 65,535 bytes
10:02:46braewoodsthough in practice usually much smaller
10:02:55speachybraewoods: you could always make an executive decision and explcitly only support 8.3 filenames.
10:03:06speachyremember the use case is not general.
10:03:19braewoodsspeachy: erm... not relevant here? zip stores the FULL file path in the filename.
10:03:55braewoodsnot sure what 8.3 has to do with this.
10:04:09braewoodsthe filename is the full file path in the archive
10:04:10speachyrockbox itself doesn't support 64K paths.
10:04:17_bilgusour paths are max 320ish chars too
10:04:27braewoodsis that macroed somewhere?
10:04:48braewoodsgood to know in any case
10:04:53braewoodsthat means i can take some shortcuts
10:04:53_bilgusyeah MAX_PATH?
10:05:32braewoodsok, well i don't know much about what rockbox actually supports
10:05:35_bilgusyou might still want to have that 64k path though in terms of navigating the archive]
10:06:17speachy_bilgus: why? just skip over paths that are too long.
10:06:18braewoods_bilgus: how would that help?
10:06:39braewoodsthe way zIP is setup, the filenames are totally irrelevant to ZIP file navigation.
10:06:55speachythere's no point in extracting (or caring about in any way) a file rockbox can't handle.
10:06:55braewoodsonly matter if the caller cares
10:07:18braewoodsyea, i'll cap my filename buffer to that then
10:07:25braewoodsfor some reason i thought rockbox could handle that
10:07:33braewoodsbut in practice not even Linux supports file paths that long
10:07:39braewoodsthe upper limit is normally 4K
10:08:24braewoodsok i'm in for another redesign... i don't mind too much
10:08:35braewoodsi need to know this stuff for when i work on MTP again
10:08:43_bilgusI figured if you had a really long path it would truncate an possibly no longer be unique
10:08:46braewoodsthis is a lower skill project that is useful for learning more about rockbox file IO
10:09:29braewoodsthis is just the hard upper limit, not factoring in local system limitations.
10:09:53braewoodsto know the true limit i need to know the base extraction path as well
10:11:05braewoodsspeachy: once i get this all finished i'm thinking it could be useful for extracting ZIP payloads. but no idea if that's better than just letting the OS do that. but it could be an improvement over a bunch of MTP calls.
10:11:47braewoodssend a single large file over MTP and let rockbox extract it
10:16:35desowinspeachy: regarding the comment about HAVE_WIFI, probably the comment places too much importance to something that's not really important
10:17:11desowinbut well, 10 years ago I didn't have the experience I have now
10:18:06desowinI had absolutely no idea how to tackle the USB and WiFi
10:19:08speachywhat's your vision for enabling wifi on the connect?
10:20:01speachy(assuming working wifi, tcp, and ssl stacks..)
10:20:27braewoodsthe tcp stack is probably the main issue
10:20:46braewoodsTLS we can probably import a library for
10:20:49desowintcp stack is no big deal, the apps are much harder
10:21:08braewoodsmost of the network stuff can probably be grafted on to rockbox from a library
10:21:20speachyI mean what's the end-user story. what new and excicing features will they gain
10:21:30desowinthere's plenty of RAM in connect and lwip runs on much more constrained systems
10:21:30braewoodsi can think of a few.
10:21:50braewoods1), auto-check for new rockbox updates
10:22:02braewoodsnot super important but could be interesting to do self-updates
10:22:14braewoodsthat could be a use case for my ZIP work once it's done
10:23:01braewoods2) RSS feeds or other kinds of web API updates.
10:23:07braewoodsobviously no point in a web browser
10:23:20desowintbh. I just think about checking how much the deep sleep saves as compared to what's currently there - the only sensible way to really check that is to port the driver
10:23:46desowinso that's the main driver for me now, however that sounds ;-)
10:24:14braewoodsi'm just throwing out some ideas; the web stack would just have some uses for basic stuff like music streaming
10:24:40braewoodsanother use case? ice / shout cast support.
10:24:48braewoodsprobably client mainly
10:24:59braewoodswifi is probably fast enough for audio streaming
10:25:25braewoodsthat was one of the original features of the connect
10:25:29braewoodsinternet radio
10:26:11speachymost streaming stuff is now in DRM-wrapped services.
10:26:20braewoodsindeed but internet radio is still a thing.
10:26:33braewoodsif we have the underlying support for it, i wouldn't mind writing the application support.
10:27:09braewoodsi don't know enough about low level networking to really code for it right now
10:27:27speachyI'd personally like to see a squeezelite port, but its real-world utility is slim.
10:27:58speachythe software client for the old slim devices/logitech audio server
10:28:40braewoodswe could see that
10:28:41speachybecause speaking generally, if I'm within range of wifi, I don't need to use a highly portable player.
10:29:14speachyit's a shame there aren't any viable BT stacks.
10:29:19speachythat's the real killer.
10:29:44braewoodstrue but one problem at a time. the connect presents us with an opportunity to develop some TCP/IP service features
10:30:01braewoodsprovided we can get the wifi functional enough
10:30:28speachyfive available on ebay, heh.
10:30:39braewoodsyea, it's a bit rare
10:30:54braewoodsbut it does give us a chance to start developing a new type of code
10:30:58speachy"getting wifi functional enough" is probably a couple months of dedicated effort, even by someone who's done it before.
10:31:08braewoodstrue but isn't most of the cost paid once?
10:31:31braewoodslinux wifi uses 80211 subsystem
10:31:32speachythe last time I did this I was working with 64K of RAM
10:31:44braewoodsnow the minimal ram is in the megabytes
10:32:33desowinwith the chip being FullMAC means just the "high level" stuff needs to be written
10:32:47braewoodsthings like ARP?
10:32:55speachyin my experience the fullmac devices actually took _more_ code overall. :/
10:33:14desowinand regarding TCP/IP, it's fairly simple to implement that one using USB CDC - the biggest problem is the MAC address itself
10:33:31braewoodsmeaning layer 2.
10:33:59braewoodsi took some networking courses though i mostly use sockets
10:34:01speachyheh, nothing wrong with generating a random macaddr at bootup time.
10:34:10desowinit's just high level API to connect to network, scan, etc. then it is just like if you had a fast ethernet card
10:34:58desowinas after connecting you just write lwip driver that passes the packets to 8686
10:35:10speachylwip works well enough (even more so as it's mostly maintained these days), and you'd need some sort of minimal SSL stack (can probably lift the mbed one)
10:35:20desowin(and vice verse, pass whatever arrives to lwip)
10:35:23speachydesowin: does that fullmac part implement WPA internally?
10:35:35braewoodsup to WPA2?
10:35:38speachyoh wow, so we wouldn't need an external supplicatnt
10:35:48speachythat simplifies things considerably
10:36:25braewoodswe do need enough of a general stack that could in theory be extended to other ports as they come up though i can't say many mp3 players have wifi chips
10:36:55speachynothing else on our radar has wifi.
10:37:14braewoodshuh so it'd mainly be a one trick pony during the first implementation
10:37:39speachythe most recent generation of "cellphones minus the cellular radio" DAPs all have wifi though.
10:38:04braewoodsnot surprising. the main killer feature is access to streaming audio.
10:38:05speachybut frankly doing a native rockbox port to one of those is insane.
10:38:38braewoodsi did a music box using Linux on a dreamplug before using off the shelf software
10:38:42braewoodsi think i used icecast
10:38:44braewoodsor mpd
10:38:51speachyrockbox's emulators/games could go multiplayer over wifi too. :)
10:39:08braewoodsthere's *tons* of unexplored features here
10:39:16speachybut by that point we're already halfway down the stack of turtles
10:39:26braewoodsi think the main FOSS audio streaming is mpd or icecast
10:39:58braewoodsicecast has more client options than mpd does though
10:40:09braewoodsbut mpd is more compatible with how rockbox operates so :D
10:41:09braewoodsdesowin: in any case if this all works out i could see myself writing higher level software to add internet or lan service integration
10:41:25braewoodsmaybe even the ability to upload files to rockbox
10:43:41desowinnot sure about WPA2, the datasheet floating around internet mentions WPA (Wi-Fi Protected Access) and glossary at the end includes WPA2, WPA2-PSK but no other details about it
10:45:35speachydesowin: yeah.. it seems that most libertas use has migrated to the "thin" firmware.
10:45:53speachywithout WPA2 its general utility is greatly reduced.
10:57:46braewoodsyea, i'd want to confirm it can operate on wpa2 only networks first
10:59:16braewoodsspeachy: is rbendian.h used by anything? i'm finding myself using it for ZIP files since we have some big endian targets that might use this
10:59:55braewoodsour USB stack would probably have to be modified if we ever found ourselves using a big endian port with that feature
11:00:27braewoodsbut since all our usb stack ports are little endian there's not really a way to test that
11:01:42braewoods_bilgus: thanks for the info on core_alloc; i'll use it for my ZIP code.
11:02:12braewoodsthat's what i get for trying to be too decoupled from the code :D
11:02:52braewoodsi'll still use my memory saving ideas since i don't want to use more RAM than i have to
11:04:36***Saving seen data "./dancer.seen"
11:05:15braewoodsspeachy: one of my challenges is going to be finding an inflate library that is resumeable like our crc algorithms since i can't guarantee i can fit both in ram at once.
11:05:44braewoodsmost of the simple ones are one shot
11:09:09braewoodsoh, i guess i could hack one of the lightweight version to use a callback.
11:09:33braewoodswhen the buffer fills up, it calls that to flush it or refill it
11:10:40desowinI am pretty sure it can connect to WPA2, the only unknown is how much work is that
11:12:36braewoodssad thing is i saw some perfect implementations but because there was no license i couldn't use it in rockbox
11:26:13_bilguscontact the author..
11:39:52 Join eminguez [0] (
12:11:01bertrikI saw a "rockbox" for sale in the super market
12:11:28bertrikno, didn't take any
12:11:38bertrikit was a bluetooth speaker
12:34:30 Quit Piece_Maker (Quit: ZNC 1.8.2 -
12:37:41 Quit eminguez (Quit: Connection closed)
12:41:01 Join Piece_Maker [0] (
13:04:37***Saving seen data "./dancer.seen"
15:04:41***No seen item changed, no save performed.
17:04:43***No seen item changed, no save performed.
19:04:44***No seen item changed, no save performed.
20:06:18 Quit akaWolf (Ping timeout: 268 seconds)
20:16:30 Join akaWolf [0] (
20:22:52braewoods g#3516
20:22:55rb-bluebotGerrit review #3516 at : fat: move fattime_mktime to timefuncs by James Buren
20:23:27braewoodsanother semi simple change; i wanted to move the fattime_mktime to a more general location so it can be used by zip code since ZIP timestamps are DOS timestamps.
20:23:37braewoodswhoever has the time, please review it
20:52:01 Join massiveH [0] (
21:04:48***Saving seen data "./dancer.seen"
22:01:30 Quit j-r (Ping timeout: 240 seconds)
22:02:38 Join j-r [0] (
22:07:58 Quit cockroach (Quit: leaving)
23:04:52***Saving seen data "./dancer.seen"
23:05:46rb-bluebotBuild Server message: New build round started. Revision c9f2308a1d, 297 builds, 7 clients.
23:07:11braewoods_bilgus: i hope to have something to review for the first version of ZIP support. i won't be including DEFLATE support in this version as i'm still hunting for a suitable option but it shouldn't be too hard to incorporate later.
23:07:59_bilgusI don't know that its all that important storage is cheap
23:08:05_bilgusram not so much
23:08:18*braewoods shrugs.
23:08:33braewoodsto support basic ZIP though deflate is an essential
23:08:56braewoodswe use it in our official ZIP archives
23:09:24braewoodsif nothing else just compatibility with many ZIP archives is why i'd have it
23:09:37_bilguswe have control of them but yeah it'd be nice
23:09:55braewoodsfor now though i'm just interested in supporting ZIP archives with no compressed files
23:10:06braewoodsjust to test that the rest of it is solid
23:10:10_bilgusidk we were doing it in dos with pkzip
23:10:32braewoodswe use infozip today
23:16:24_bilgus ?
23:17:24braewoodsi was referring to us using the zip/unzip utilities in the build process
23:17:33braewoodswhich are infozip
23:18:35_bilgusoh lol
23:18:54_bilgusI thought you were saying their implementation
23:19:14braewoodsi'm not sure what i'll use but we only need the decompression half
23:31:27rb-bluebotBuild Server message: Build round completed after 1542 seconds.
23:31:35rb-bluebotBuild Server message: Revision c9f2308a1d result: All green

Previous day | Next day