00:37:54 | | Quit munkis (Remote host closed the connection) |
00:38:30 | | Join munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) |
00:58:53 | __builtin | kirvesAxe: try moving one of those ogg files somewhere else |
01:00 |
01:04:25 | *** | Saving seen data "./dancer.seen" |
01:12:48 | | Quit pixelma (Quit: .) |
01:12:48 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
01:13:02 | | Join pixelma [0] (marianne@p200300ea8722b300305e95fffec66ff3.dip0.t-ipconnect.de) |
01:13:02 | | Join amiconn [0] (jens@p200300ea8722b300305e95fffec66ff3.dip0.t-ipconnect.de) |
01:13:54 | | Quit amiconn (Client Quit) |
01:13:54 | | Quit pixelma (Client Quit) |
01:16:23 | | Join amiconn [0] (jens@p200300ea8722b300305e95fffec66ff3.dip0.t-ipconnect.de) |
01:16:24 | | Join pixelma [0] (marianne@p200300ea8722b300305e95fffec66ff3.dip0.t-ipconnect.de) |
01:16:42 | | Quit munkis (Ping timeout: 240 seconds) |
01:23:36 | | Join munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) |
02:00 |
02:36:59 | braewoods | _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:28 | braewoods | so the user is free to choose how the main allocation is acquire |
02:37:41 | braewoods | acquired since zip support needs much higher temporary storage than most |
02:38:18 | braewoods | this is also intended for bootloader use so it was easier for me to do it this way |
02:38:39 | braewoods | so it works equally with a static buffer and dynamic buffer |
02:39:36 | braewoods | i also admit i don't know how buflib even works. |
02:39:41 | braewoods | i thought it was a malloc like clone. |
02:40:03 | braewoods | so i assumed it would fragment and more. |
02:51:47 | braewoods | _bilgus: i was making my choice based on what i saw in usb_storage which needs a similar buffer. |
02:52:11 | braewoods | __builtin: it uses a static one when BOOTLOADER is defined or so. the core_alloc otherwise. |
02:52:30 | braewoods | err |
02:52:33 | braewoods | oops |
02:52:59 | braewoods | so i thought that for some older bootloaders, core_alloc was not available or something. |
03:00 |
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:00 |
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] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
05:00 |
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 |
06:00:51 | | Quit akaWolf (Ping timeout: 268 seconds) |
06:07:04 | desowin- | g#3515 |
06:07:08 | rb-bluebot | Gerrit review #3515 at https://gerrit.rockbox.org/r/c/rockbox/+/3515 : Sansa Connect: Initial libertas WiFi driver port by Tomasz Moń |
06:07:24 | | Nick desowin- is now known as desowin (~linux@078088109026.wroclaw.vectranet.pl) |
06:08:02 | desowin | no DMA yet but that's way too big already |
06:09:10 | desowin | and 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] (~akaWolf@akawolf.org) |
07:00 |
07:04:31 | *** | Saving seen data "./dancer.seen" |
07:16:09 | | Quit akaWolf (Ping timeout: 258 seconds) |
07:41:32 | braewoods | oh, interesting. |
07:44:10 | braewoods | speachy: 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:41 | braewoods | i know the underlying FS supports up to 4GBish files |
07:50:46 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
07:51:54 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
08:00 |
08:25:50 | _bilgus | braewoods, 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 | _bilgus | so will your stack based alloc I imagine unless you have a strict ordering |
09:00 |
09:01:12 | | Quit massiveH (Quit: Leaving) |
09:04:35 | *** | Saving seen data "./dancer.seen" |
09:25:49 | braewoods | _bilgus: ok, i'll switch to buflib. i just was concerned about it being too slow or so. |
09:32:15 | desowin | would 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:46 | desowin | this is special as it is the first non-free firmware blob in Rockbox |
09:35:56 | speachy | desowin: Freely redistributable? |
09:36:20 | speachy | we do tend to make a point to separate out blobs as separate downloads. |
09:38:12 | speachy | ok, 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:09 | speachy | desowin: 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 | _bilgus | braewoods, dont take that as discouragement if you wanna roll your own more power to you |
09:43:49 | _bilgus | buflib is already written though and (mostly??) bug free |
09:45:59 | _bilgus | pictureflow 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 | _bilgus | like we alloc 1 mb and split it into new alloc pools |
09:50:39 | desowin | speachy: 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:21 | desowin | yes, the blob is redistribuable, but not really 3-clause BSD as it prohibits reverse engineering |
09:52:20 | desowin | I 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 | _bilgus | braewoods, uh nm buflib is not using TLSF as the backend |
09:53:18 | braewoods | i see. |
09:53:45 | _bilgus | not that you can't still use it its just not in core I think |
09:54:23 | desowin | speachy: but the big thing is that this patch has fully working spi communication as otherwise the firmware loading fails |
09:54:58 | _bilgus | buflib appears far more primitive |
09:57:52 | desowin | the 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:42 | desowin | and this implementation is correct, because it needs to flip both the register addresses and value *and* the contents of firmware blobs |
09:59:06 | desowin | hopefully DMA can be configured to do that swapping |
09:59:25 | speachy | yeah, I've emitted many an expletive over SPI-attached wifi module data ordering |
09:59:59 | _bilgus | braewoods, https://github.com/Rockbox/rockbox/tree/master/lib/tlsf |
10:00 |
10:00:30 | speachy | btw, 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:18 | braewoods | _bilgus: fair enough. my main issue is needing larger temporary memory that varies in size depending on the file data. |
10:02:32 | braewoods | zip files support filenames up to 65,535 bytes |
10:02:46 | braewoods | though in practice usually much smaller |
10:02:55 | speachy | braewoods: you could always make an executive decision and explcitly only support 8.3 filenames. |
10:03:06 | speachy | remember the use case is not general. |
10:03:19 | braewoods | speachy: erm... not relevant here? zip stores the FULL file path in the filename. |
10:03:55 | braewoods | not sure what 8.3 has to do with this. |
10:04:09 | braewoods | the filename is the full file path in the archive |
10:04:10 | speachy | rockbox itself doesn't support 64K paths. |
10:04:17 | _bilgus | our paths are max 320ish chars too |
10:04:27 | braewoods | is that macroed somewhere? |
10:04:48 | braewoods | good to know in any case |
10:04:53 | braewoods | that means i can take some shortcuts |
10:04:53 | _bilgus | yeah MAX_PATH? |
10:05:32 | braewoods | ok, well i don't know much about what rockbox actually supports |
10:05:35 | _bilgus | you might still want to have that 64k path though in terms of navigating the archive] |
10:05:36 | braewoods | :| |
10:06:17 | speachy | _bilgus: why? just skip over paths that are too long. |
10:06:18 | braewoods | _bilgus: how would that help? |
10:06:39 | braewoods | the way zIP is setup, the filenames are totally irrelevant to ZIP file navigation. |
10:06:55 | speachy | there's no point in extracting (or caring about in any way) a file rockbox can't handle. |
10:06:55 | braewoods | only matter if the caller cares |
10:07:18 | braewoods | yea, i'll cap my filename buffer to that then |
10:07:25 | braewoods | for some reason i thought rockbox could handle that |
10:07:33 | braewoods | but in practice not even Linux supports file paths that long |
10:07:39 | braewoods | the upper limit is normally 4K |
10:08:24 | braewoods | ok i'm in for another redesign... i don't mind too much |
10:08:35 | braewoods | i need to know this stuff for when i work on MTP again |
10:08:43 | _bilgus | I figured if you had a really long path it would truncate an possibly no longer be unique |
10:08:46 | braewoods | this is a lower skill project that is useful for learning more about rockbox file IO |
10:09:29 | braewoods | this is just the hard upper limit, not factoring in local system limitations. |
10:09:53 | braewoods | to know the true limit i need to know the base extraction path as well |
10:11:05 | braewoods | speachy: 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:47 | braewoods | send a single large file over MTP and let rockbox extract it |
10:16:35 | desowin | speachy: regarding the comment about HAVE_WIFI, probably the comment places too much importance to something that's not really important |
10:17:11 | desowin | but well, 10 years ago I didn't have the experience I have now |
10:18:06 | desowin | I had absolutely no idea how to tackle the USB and WiFi |
10:19:08 | speachy | what's your vision for enabling wifi on the connect? |
10:20:01 | speachy | (assuming working wifi, tcp, and ssl stacks..) |
10:20:27 | braewoods | the tcp stack is probably the main issue |
10:20:46 | braewoods | TLS we can probably import a library for |
10:20:49 | desowin | tcp stack is no big deal, the apps are much harder |
10:21:08 | braewoods | most of the network stuff can probably be grafted on to rockbox from a library |
10:21:20 | speachy | I mean what's the end-user story. what new and excicing features will they gain |
10:21:30 | desowin | there's plenty of RAM in connect and lwip runs on much more constrained systems |
10:21:30 | braewoods | i can think of a few. |
10:21:50 | braewoods | 1), auto-check for new rockbox updates |
10:22:02 | braewoods | not super important but could be interesting to do self-updates |
10:22:14 | braewoods | that could be a use case for my ZIP work once it's done |
10:23:01 | braewoods | 2) RSS feeds or other kinds of web API updates. |
10:23:07 | braewoods | obviously no point in a web browser |
10:23:20 | desowin | tbh. 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:46 | desowin | so that's the main driver for me now, however that sounds ;-) |
10:24:14 | braewoods | i'm just throwing out some ideas; the web stack would just have some uses for basic stuff like music streaming |
10:24:40 | braewoods | another use case? ice / shout cast support. |
10:24:48 | braewoods | probably client mainly |
10:24:59 | braewoods | wifi is probably fast enough for audio streaming |
10:25:25 | braewoods | that was one of the original features of the connect |
10:25:29 | braewoods | internet radio |
10:26:11 | speachy | most streaming stuff is now in DRM-wrapped services. |
10:26:20 | braewoods | indeed but internet radio is still a thing. |
10:26:33 | braewoods | if we have the underlying support for it, i wouldn't mind writing the application support. |
10:27:09 | braewoods | i don't know enough about low level networking to really code for it right now |
10:27:27 | speachy | I'd personally like to see a squeezelite port, but its real-world utility is slim. |
10:27:33 | braewoods | squeezelite? |
10:27:58 | speachy | the software client for the old slim devices/logitech audio server |
10:28:40 | braewoods | we could see that |
10:28:41 | speachy | because speaking generally, if I'm within range of wifi, I don't need to use a highly portable player. |
10:29:14 | speachy | it's a shame there aren't any viable BT stacks. |
10:29:19 | speachy | that's the real killer. |
10:29:44 | braewoods | true but one problem at a time. the connect presents us with an opportunity to develop some TCP/IP service features |
10:30:01 | braewoods | provided we can get the wifi functional enough |
10:30:28 | speachy | five available on ebay, heh. |
10:30:39 | braewoods | yea, it's a bit rare |
10:30:54 | braewoods | but it does give us a chance to start developing a new type of code |
10:30:58 | speachy | "getting wifi functional enough" is probably a couple months of dedicated effort, even by someone who's done it before. |
10:31:08 | braewoods | true but isn't most of the cost paid once? |
10:31:31 | braewoods | linux wifi uses 80211 subsystem |
10:31:32 | speachy | the last time I did this I was working with 64K of RAM |
10:31:44 | braewoods | now the minimal ram is in the megabytes |
10:32:33 | desowin | with the chip being FullMAC means just the "high level" stuff needs to be written |
10:32:47 | braewoods | things like ARP? |
10:32:55 | speachy | in my experience the fullmac devices actually took _more_ code overall. :/ |
10:33:14 | desowin | and regarding TCP/IP, it's fairly simple to implement that one using USB CDC - the biggest problem is the MAC address itself |
10:33:31 | braewoods | meaning layer 2. |
10:33:59 | braewoods | i took some networking courses though i mostly use sockets |
10:34:01 | speachy | heh, nothing wrong with generating a random macaddr at bootup time. |
10:34:10 | desowin | it'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:58 | desowin | as after connecting you just write lwip driver that passes the packets to 8686 |
10:35:10 | speachy | lwip 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:20 | desowin | (and vice verse, pass whatever arrives to lwip) |
10:35:23 | speachy | desowin: does that fullmac part implement WPA internally? |
10:35:29 | desowin | yes |
10:35:35 | braewoods | up to WPA2? |
10:35:38 | speachy | oh wow, so we wouldn't need an external supplicatnt |
10:35:48 | speachy | that simplifies things considerably |
10:36:25 | braewoods | we 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:55 | speachy | nothing else on our radar has wifi. |
10:37:14 | braewoods | huh so it'd mainly be a one trick pony during the first implementation |
10:37:39 | speachy | the most recent generation of "cellphones minus the cellular radio" DAPs all have wifi though. |
10:38:04 | braewoods | not surprising. the main killer feature is access to streaming audio. |
10:38:05 | speachy | but frankly doing a native rockbox port to one of those is insane. |
10:38:38 | braewoods | i did a music box using Linux on a dreamplug before using off the shelf software |
10:38:42 | braewoods | i think i used icecast |
10:38:44 | braewoods | or mpd |
10:38:51 | speachy | rockbox's emulators/games could go multiplayer over wifi too. :) |
10:39:08 | braewoods | there's *tons* of unexplored features here |
10:39:16 | speachy | but by that point we're already halfway down the stack of turtles |
10:39:26 | braewoods | i think the main FOSS audio streaming is mpd or icecast |
10:39:58 | braewoods | icecast has more client options than mpd does though |
10:40:09 | braewoods | but mpd is more compatible with how rockbox operates so :D |
10:41:09 | braewoods | desowin: 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:25 | braewoods | maybe even the ability to upload files to rockbox |
10:41:29 | braewoods | wirelessly |
10:43:41 | desowin | not 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:35 | speachy | desowin: yeah.. it seems that most libertas use has migrated to the "thin" firmware. |
10:45:53 | speachy | without WPA2 its general utility is greatly reduced. |
10:57:46 | braewoods | yea, i'd want to confirm it can operate on wpa2 only networks first |
10:59:16 | braewoods | speachy: 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:55 | braewoods | our USB stack would probably have to be modified if we ever found ourselves using a big endian port with that feature |
11:00 |
11:00:27 | braewoods | but since all our usb stack ports are little endian there's not really a way to test that |
11:01:42 | braewoods | _bilgus: thanks for the info on core_alloc; i'll use it for my ZIP code. |
11:02:12 | braewoods | that's what i get for trying to be too decoupled from the code :D |
11:02:52 | braewoods | i'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:15 | braewoods | speachy: 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:44 | braewoods | most of the simple ones are one shot |
11:09:09 | braewoods | oh, i guess i could hack one of the lightweight version to use a callback. |
11:09:33 | braewoods | when the buffer fills up, it calls that to flush it or refill it |
11:10:40 | desowin | I am pretty sure it can connect to WPA2, the only unknown is how much work is that |
11:12:36 | braewoods | sad thing is i saw some perfect implementations but because there was no license i couldn't use it in rockbox |
11:26:13 | _bilgus | contact the author.. |
11:39:52 | | Join eminguez [0] (~eminguez@196.red-79-159-201.dynamicip.rima-tde.net) |
12:00 |
12:11:01 | bertrik | I saw a "rockbox" for sale in the super market |
12:11:19 | speachy | pics! |
12:11:28 | bertrik | no, didn't take any |
12:11:38 | bertrik | it was a bluetooth speaker |
12:34:30 | | Quit Piece_Maker (Quit: ZNC 1.8.2 - https://znc.in) |
12:37:41 | | Quit eminguez (Quit: Connection closed) |
12:41:01 | | Join Piece_Maker [0] (~Piece_Mak@cpc95746-bolt17-2-0-cust360.10-3.cable.virginm.net) |
13:00 |
13:04:37 | *** | Saving seen data "./dancer.seen" |
15:00 |
15:04:41 | *** | No seen item changed, no save performed. |
17:00 |
17:04:43 | *** | No seen item changed, no save performed. |
19:00 |
19:04:44 | *** | No seen item changed, no save performed. |
20:00 |
20:06:18 | | Quit akaWolf (Ping timeout: 268 seconds) |
20:16:30 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
20:22:52 | braewoods | g#3516 |
20:22:55 | rb-bluebot | Gerrit review #3516 at https://gerrit.rockbox.org/r/c/rockbox/+/3516 : fat: move fattime_mktime to timefuncs by James Buren |
20:23:27 | braewoods | another 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:37 | braewoods | whoever has the time, please review it |
20:52:01 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
21:00 |
21:04:48 | *** | Saving seen data "./dancer.seen" |
22:00 |
22:01:30 | | Quit j-r (Ping timeout: 240 seconds) |
22:02:38 | | Join j-r [0] (~j-r@p2003000621560714404207fffefd0a65.dip0.t-ipconnect.de) |
22:07:58 | | Quit cockroach (Quit: leaving) |
23:00 |
23:04:52 | *** | Saving seen data "./dancer.seen" |
23:05:46 | rb-bluebot | Build Server message: New build round started. Revision c9f2308a1d, 297 builds, 7 clients. |
23:07:11 | braewoods | _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 | _bilgus | I don't know that its all that important storage is cheap |
23:08:05 | _bilgus | ram not so much |
23:08:18 | * | braewoods shrugs. |
23:08:33 | braewoods | to support basic ZIP though deflate is an essential |
23:08:56 | braewoods | we use it in our official ZIP archives |
23:09:24 | braewoods | if nothing else just compatibility with many ZIP archives is why i'd have it |
23:09:37 | _bilgus | we have control of them but yeah it'd be nice |
23:09:55 | braewoods | for now though i'm just interested in supporting ZIP archives with no compressed files |
23:10:06 | braewoods | just to test that the rest of it is solid |
23:10:10 | _bilgus | idk we were doing it in dos with pkzip |
23:10:32 | braewoods | we use infozip today |
23:16:24 | _bilgus | https://github.com/LuaDist/zip/blob/master/deflate.c ? |
23:17:02 | braewoods | eh? |
23:17:24 | braewoods | i was referring to us using the zip/unzip utilities in the build process |
23:17:33 | braewoods | which are infozip |
23:18:35 | _bilgus | oh lol |
23:18:54 | _bilgus | I thought you were saying their implementation |
23:18:58 | braewoods | no |
23:19:14 | braewoods | i'm not sure what i'll use but we only need the decompression half |
23:31:27 | rb-bluebot | Build Server message: Build round completed after 1542 seconds. |
23:31:35 | rb-bluebot | Build Server message: Revision c9f2308a1d result: All green |