--- Log for 11.10.120 Server: wilhelm.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 13 days and 19 hours ago 00.03.54 # make that tuesday. email sent to the list for a heads-up and any last-minute objections. 00.25.38 Quit ac_laptop (Ping timeout: 260 seconds) 00.36.23 *** Saving seen data "./dancer.seen" 00.36.44 # <__builtin> hmm, I'm pretty sure 4.9.4 breaks quake on ipod6g 00.37.10 # <__builtin> "breaks" as in hanging on exit IIRC 00.40.06 # <_bilgus_> g#2811 is updated to where I've gotten to currently 00.40.08 # Gerrit review #2811 at http://gerrit.rockbox.org/r/2811 : LCD core move buf ptr and address look up function viewport struct WIP by William Wilgus 00.41.12 # <_bilgus_> basically the mechanism is there but there are still some things that will disappear from plugin.c/h and some clean up + remote displays 00.42.26 # <_bilgus_> probably the lcd_address lookup might be better in ASM but I imagine with the static buffers it'll be not a big difference 00.44.16 # <__builtin> hehe, from 2006: https://www.rockbox.org/irc/log-20060309#06:00:50 00.44.30 # <__builtin> That seals it. I'm insane. 00.45.43 # you're in good company 00.48.23 # <_bilgus_> I thought that was one of the pre-reqs 00.49.23 # <__builtin> speachy: anyway, regarding 4.9.4 I'm fine if you push it 00.49.56 # <__builtin> the bug itself is pretty minor and that'll give me the motivation to fix it :) 00.50.27 # several plugins segfault on exiting from the hibylinux stuff too 00.50.33 # unreliably 00.51.19 # <__builtin> someone just needs to spend an afternoon with a debugger and some luck, I bet 00.51.27 # <_bilgus_> oh speaking of weird hangs that rolo hang on the x3 works its self out usually given enough time 00.52.03 # _bilgus_: really? that's... a really useful datum 00.52.07 # <_bilgus_> perhaps even every time given infinite time limits;) 00.52.11 # <__builtin> I had one in the course of the quake port that turned out to be an off-by-one in a loop condition 00.53.54 # <_bilgus_> the thing that bothered me the most is working between lua and the RB C backend pretty much a off by one waiting to happen every traversal between the two 00.54.20 # <__builtin> I had the equivalent of i--; do { ... } while(--i != 0); 00.54.26 # <__builtin> in assembly, of coruse 00.54.40 # <__builtin> so it'd break whenever i=1 and loop around to 0xffffffff 00.54.56 # <_bilgus_> they say thats faster because the one less check but I mess it up more than not 00.55.38 # <__builtin> it'd then proceed to loop 0xffffffff times, which led to a nice 10-minute delay 00.56.55 # <__builtin> hard to say but it sounds like something similar could be happening here, who knows 00.57.15 # __builtin: https://twitter.com/secretGeek/status/7269997868 00.57.20 # <_bilgus_> ah I got ya I figured there was something hold the memory 00.57.31 Quit galaxy_knuckles (Ping timeout: 246 seconds) 00.57.41 # <__builtin> the issue was i != 0 as the condition 00.57.54 # <__builtin> fixed by using > (bne -> bgt in asm) 00.58.47 # _bilgus_: the thing is, there's not a lot steps to block in the rolo code, between "loading" and the "executing" that doesn't show.. 00.59.16 # maybe it's the core_alloc_maximum() that's blocking? 00.59.27 # <_bilgus_> my thought.. 00.59.28 # I guess it wouldn't hurt to add in a few more display updates 00.59.56 Join galaxy_knuckles [0] (~gknux@db4g.com) 00.59.56 Quit galaxy_knuckles (Changing host) 00.59.56 Join galaxy_knuckles [0] (~gknux@unaffiliated/galaxy-knuckles/x-1756549) 01.00.21 # <_bilgus_> it might be a badly behaving buffer not realsing in a timely manner 01.00.45 # isn't audio-related though; this happens indpedently of audio running 01.01.34 # <_bilgus_> not sure but probably generally when i'm using rolo I don't have audio playing 01.01.54 # voice prompts? 01.02.07 # <_bilgus_> doesn't mean thats not the case but I'll try to pay closer attention to the exact circumstances 01.02.22 # <_bilgus_> I think voice does set fixed buffers 01.02.29 # my usual run is to power on, dump firmware over, hit play on rolo prompt 01.02.57 # anectdotally the longer I wait at the prompt, the more likely it is to get stuck. 01.02.57 # <_bilgus_> though I added code to dump the voice buffers recently so that might work to test 01.03.34 # we don't HAVE_STORAGE_FLUSH or HAVE_BOOTDATA 01.04.15 # so that leaves audio_stop(), the core_alloc_maximum(), core_get_Data(), and load_firmware(). 01.04.19 # <_bilgus_> bootdata would actually be nice on hosted builds emulated ofc 01.04.57 # <_bilgus_> mm once I figure out something with jHMikeS redirection code lol 01.05.02 # I have on my todo list to get rolo working on hosted targets. ought to be easy, unless I'm missing something really fundamental 01.05.43 # (I guess we'd want to make sure all open fds are closed upon exec()) 01.06.15 # <_bilgus_> I think the FS keeps track and warns oh nm thats only for plugins 01.06.59 # <_bilgus_> but yeah good point just odd that it works elsewhere 01.07.30 # I Think nobody ever bothered to write it 01.08.41 # <_bilgus_> ah Mr.Somebodys arch nemesis! 01.47.53 # Build Server message: New build round started. Revision 5cfd3ae, 287 builds, 10 clients. 01.57.22 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 02.02.28 # Build Server message: Build round completed after 874 seconds. 02.02.30 # Build Server message: Revision 5cfd3ae result: All green 02.36.27 *** Saving seen data "./dancer.seen" 03.15.34 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) 03.24.35 Quit prof_wolfff (Ping timeout: 240 seconds) 03.45.45 # Build Server message: New build round started. Revision c8fa530, 287 builds, 10 clients. 04.00.24 # Build Server message: Build round completed after 880 seconds. 04.00.27 # Build Server message: Revision c8fa530 result: All green 04.05.43 Join w4tchguard [0] (~w4tchguar@2001:ac8:84:33::a10d) 04.18.39 Join Xeha [0] (~Xeha@unaffiliated/xeha) 04.30.31 # speachy: interesting. seems the CF mod has 2 issues with the latest current bootloader. ata -80 error when exiting USB mode or when trying to boot from disk. 04.30.46 # i'm guessing they're related since it worked with the original disk 04.31.06 # anyway that's more than enough reason to try to fix it 04.36.29 *** Saving seen data "./dancer.seen" 04.50.29 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 05.05.31 Quit SiliconExarch (Quit: Idle for 30+ days) 05.10.59 Quit w4tchguard (Remote host closed the connection) 05.11.18 Join w4tchguard [0] (~w4tchguar@2001:ac8:84:33::a10d) 05.21.39 Quit S|h|a|w|n (Read error: Connection reset by peer) 05.58.18 Join johnb3 [0] (~johnb2@p5b3af6d7.dip0.t-ipconnect.de) 06.03.25 # speachy, _bilgus_ : I mentioned that I wanted to run batterybench on the X3ii. When connecting to my PC againg, I was annoyed to see, that no file was created. I thought maybe I hit a wrong button and it didn't run at all. But no, starting it again, it briefly flashes "Cannot create file", then "plugin returned error". This was with 7c00e9b30b-201010 06.36.32 *** Saving seen data "./dancer.seen" 06.41.46 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 07.02.54 # lebellium: I will have a look but I need the key from the device 07.03.00 # it can't be guessed 07.05.25 Quit johnb3 (Ping timeout: 240 seconds) 07.08.31 # lebellium: actually, I do have the DMP-Z1 key, I just didn't commit it, I will now and upload a build 07.11.07 # Build Server message: New build round started. Revision e371dee, 287 builds, 10 clients. 07.20.32 # great 07.23.50 # Build Server message: Build round completed after 763 seconds. 07.23.51 # Build Server message: Revision e371dee result: All green 07.29.55 Quit w4tchguard (Ping timeout: 240 seconds) 07.41.44 Join Soap [0] (~Soap@rockbox/staff/soap) 07.52.25 Quit pamaury (Ping timeout: 264 seconds) 07.59.41 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 08.11.35 # Build Server message: New build round started. Revision fcdfeb2, 287 builds, 10 clients. 08.13.21 # johnb3: There's probably a plugin path problem due to the funky pivot_root thing going on for hosted builds 08.14.56 # thought I'd fixed all of that though 08.17.13 # [pamaury](https://matrix.to/#/@freenode_pamaury:matrix.org): I'm planning to push the tomcrypt stuff soonish, in case you still want to give it a look. 08.20.24 # johnb3: yeah, found it, fixing now. 08.22.06 # _bilgus_: I think we need to yank HOME_DIR from all users of the plugin API. This is limited to a handful of test_ plugins... and lua. 08.23.38 # Build Server message: Build round completed after 724 seconds. 08.23.40 # Build Server message: Revision fcdfeb2 result: All green 08.24.45 Join prof_wolfff [0] (~prof_wolf@26.red-83-54-195.dynamicip.rima-tde.net) 08.24.47 # blbro[m]: ah yeah, let me have a try, can you give ne the gerrit link again ? 08.25.48 # pamaury: starting at https://gerrit.rockbox.org/r/#/c/2641 08.26.36 Join johnb3 [0] (~johnb2@p5b3af6d7.dip0.t-ipconnect.de) 08.36.04 # speachy: blbro[m]: just tried to decrypt a file and seems to work 08.36.36 *** Saving seen data "./dancer.seen" 08.38.19 # _bilgus_: actually I think every user outside of the actual filesystem code is a bug. 09.10.16 # <_bilgus_> speachy, doubt lua uses it in a meaningful way besides as just a Const 09.11.38 # _bilgus_: ok, I'm yanking the constant defines. it's not referenced by any of the scripts 09.12.23 # all but one remaining use is in calls to create_[datetime|numbered]_filename() 09.23.14 Quit ufdm_ (Quit: Leaving) 09.23.31 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) 09.30.12 # lebellium: the tool is at https://www.rockbox.org/wiki/SonyNWUPGTool 09.30.19 # I will try to write instructions on how to use it 09.35.00 # thank you 09.35.42 Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) 09.35.44 # speachy: any idea what host environment the build bots use? 09.36.32 # in the wiki table I think nw-wm1 code is now split between nw-wm1a and nw-wm1z ? 09.42.54 # yes indeed 09.43.16 # that table is obsolete, it should be generated from the code since there is a list of kas in there... 09.55.00 # braewoods: they're whatever their respective owners set up. It's not tracked. Mine are all fedora-based FWIW 10.09.58 # Ok. 10.11.53 # ha! it works! 10.11.56 # ROLO on hosted targets. 10.16.08 # speachy: in theory, wouldn't the be as simple as the program doing an exec on itself or other executable? 10.16.27 # depending on whether you want to replace the existing process or make a new one and exit 10.16.36 # braewoods: yes indeed. though some prep work was needed first to close down open files/etc 10.16.43 # indeed. 10.17.05 # same idea as certain muds that did copyover as an exec on itself 10.17.21 # heh, haven't heard that term in a long time 10.17.36 # they'd save some state or so so the new instance could reinitialize the existing network connections 10.17.46 # muts also needed to maintain state, we don't have that worry. 10.18.01 # you actually have the opposite problem 10.18.10 # you want to deinitialize as much as possible for a clean transfer 10.18.12 # (well, we have the so-called bootdata, but that doesn't exist on any hosted target) 10.18.43 # Build Server message: New build round started. Revision 6533d98, 287 builds, 10 clients. 10.18.46 # plus you could also leverage posix shared memory or so if you need to persist memory structures 10.19.03 # though that has its own problems 10.19.20 # you effectively can't share anything but PODs in this system since pointers are worthless 10.19.45 # those are relative to a process' own memory map and so pointers are non-portable between processes 10.20.04 # but in our case we want to explicitly blow it all away; the issues tend to come from things like init code not handling hardware not in idle/powerup/reset state etc 10.20.29 # right. less of an issue on a hosted target though? 10.20.34 # since the kernel handles all that 10.20.44 # at most you might be writing to sysfs 10.20.52 # or performing ioctl calls 10.21.03 # exactly. except for held-open file descriptors 10.21.10 # and a few other inherited stuff 10.21.26 # lebellium: I've written stuff in https://www.rockbox.org/wiki/SonyNWUPGTool this should hopefully help with the tool 10.21.43 # speachy: tbh I'd rather see fiio pushing an ota to update the recovery and remove the signature check 10.22.08 # efqw: is that even something you could get cooperation on? 10.22.15 # efqw: well, yeah, but if they thought it was important to implement that crap to begin with, convingcing them it's not necessary is a much harder battle 10.22.38 # efqw: I wonder if the FiiO firmware implements DRM (eg in wma files) 10.22.49 # No, I'm convinced that this is not intentional, they just took what Ingenic offered in the BSP as-is. 10.22.52 # WMA DRM is effectively dead... 10.22.58 # what else is there? 10.23.09 # audible or whatever? 10.23.11 # braewoods: I have no leverage on this unfortunately. 10.23.27 # pamaury: yes I just read that, thank you. I was wondering whether we should explain how to get the UPG file because Sony actually only provides .EXE firmware files for the latest models. To get the UPG file I had to execute the .exe and go to the TEMP directory used by Sony 10.23.27 # so probably better to find a workaround 10.23.31 # efqw: the ingenic sdk supplied that signed-zip monstrosity? gack 10.23.48 # Did you download the sdk? 10.23.51 # but I get the ingenic stuff wanting to support DRM (soc has hardware video decoder) 10.23.59 # efqw: can you modify the recovery? 10.24.06 # I have a copy somewhere but I never bothered to poke around in it. 10.24.08 # perhaps you can patch out the problem. 10.24.47 # depends if the bootloader is locked so to pseak 10.24.49 # speak 10.24.50 # braewoods: that is our fallback plan, we *do* have the capability to flash whatever we want onto the device right now, with the help of the usb cloner tool 10.24.52 # but if it isn't 10.25.11 # you can theoretically disable or install your own signing keys 10.25.32 # probably would be simpler to disable it 10.25.33 # that'd be pointless as we might as well just update the rootfs UBI directly 10.26.23 # efqw: honestly the only other option i know of is to have the private key and those are effectively impossible to bruteforce 10.26.27 # lebellium: yes that's a good point 10.26.48 # efqw: realistically i only see one option short of some other oversight in their implementation 10.26.57 # patching it out 10.27.18 # but yea 10.28.15 # on the bright side since the recovery is a standard ELF binary... its binary format is well known so it should be easier to patch. 10.28.25 # o.O 10.28.34 # at least i assume that from what i saw being said earlier 10.28.56 # linux pretty much exclusively relies on ELF for all its binaries 10.29.24 # speachy: keep in mind that the ingenic BSP was originally intended for those internet-connected (spy) speakers 10.29.45 # the deal just didn't pan out, not many speakers used their chips unfortunately 10.30.03 # lebellium: I just created a subsection in UPGTool on this. Could you help me fill it ? I almost never use Windows 10.30.05 # braewoods: if we are forced to use the burntool we'll just upload our own patched main firmware image. we can update it from the inside afterwards. 10.30.22 # right 10.30.29 # The speaker market is mostly Allwinner or MediaTek nowadays I believe. 10.30.43 # mucking with recovery code is... dangerous. legally as well as technically. 10.31.01 # MediaTek for Android based ones and Allwinner for everything else. 10.31.34 # Rockchip also did RK3308 but I haven't seen any speakers with that SoC either. 10.31.45 # allwinner... they're a pretty popular ARM target for Linux boards. 10.31.48 # if this pine64 lark works out in the end we'll probably end up with an allwinner-based DAP 10.32.05 # either F1C-series or V3-series 10.32.15 # Not the A20 and such? 10.32.26 # that's the one i read about most. 10.32.40 # they're capped at 2GB due to hardware limitations i believe 10.32.57 # We don't even need more than 1GB for rb. 10.33.09 # 256M is plenty even for a hosted target. 10.33.11 # you get by with far less than that even 10.33.49 # Build Server message: Build round completed after 906 seconds. 10.33.51 # Build Server message: Revision 6533d98 result: All green 10.33.52 # Build Server message: New build round started. Revision 4e89e0e, 287 builds, 9 clients. 10.33.53 # vast, vast overkill. 10.34.01 # indeed. 10.34.12 # it might be good for IO performance during syncs but little else 10.34.22 # the F1C and V3 stuff has on-package RAM too, which greatly reducess the PCB size and complexity 10.34.33 # how much? 10.34.44 # i'd think at least 64MB 10.34.49 # Not to mention it significantly reduces the amount of engineering efforts required to route the PCB 10.34.55 # F1C is 32 or 64, V3 is 64 or 128. 10.35.01 # I see. 10.35.03 # F1C100s has 32MB and F1C200s has 64MB 10.35.08 # you'd probably want some room to grow... 10.35.23 # even the lowest-end F1C has more than enough oomph to run everything rockbox has today. save perhaps Quake. 10.35.23 # but obviously there's a realistic limit. what would you use it for? 10.35.30 # the main thing i can see is more caching 10.35.41 # cachine with solid state storage is not terribly important 10.35.54 # ...I'd like 64. 10.36.02 # F1C200s then? 10.36.16 # the F1C100 can be had under $1 10.36.21 # What about the PMU? We need a real PMU like the AXP192. 10.36.34 # PMU? 10.36.37 *** Saving seen data "./dancer.seen" 10.36.37 # power management? 10.36.49 # PMU ultimately depends on what the rest of the board needs. if we have external codecs then sure, a PMU makes sense 10.36.58 Quit kadoban (*.net *.split) 10.37.00 Quit danielp3344 (*.net *.split) 10.37.00 # Yeah, for battery charging and stuff like DC-DC 10.37.10 # the V3+AXP208 (?) can be had for only a few $ in small quantities. 10.37.11 # oh. a BMS so to speak. 10.37.18 Join kadoban [0] (kadobanmat@gateway/shell/matrix.org/x-vbpdmawecokvypon) 10.37.19 Join danielp3344 [0] (danielp334@gateway/shell/matrix.org/x-urgmduafmxhabyqd) 10.38.01 # The AXP stuff has built-in battery gauge so you can have pretty accurate runtime estimates compared to the voltage-based solutions 10.38.13 # the F1C would be a good native candidate out of the box, the V3 is fast enough to handle hosted well, and would be an absolute screamer running natively 10.38.33 # and if you're building a design from scratch... 10.38.37 # (1.2GHz Cortex A7..) 10.38.48 # you can tweak it to reflect what rockbox is capable of or so 10.38.52 Quit amiconn (*.net *.split) 10.38.52 Quit pixelma (*.net *.split) 10.38.54 Quit bzed (*.net *.split) 10.38.54 # yeah, I hope you have some fun with the pocketgo 10.39.09 Join amiconn [0] (jens@rockbox/developer/amiconn) 10.39.09 Join pixelma [0] (marianne@rockbox/staff/pixelma) 10.39.09 Join bzed [0] (~bzed@shell.bzed.at) 10.39.29 # both would work reasonably well with their internal codecs -- and for higher-end audio external codec options are legion 10.39.32 # though i'm no electrical engineer 10.40.00 # assuming that's the career field for designing electronics 10.41.19 Quit Huntereb (Ping timeout: 246 seconds) 10.42.08 # here's something to put on the wishlist if you're interested: I want a FM tuner as well 10.42.22 Quit Xeha (Ping timeout: 246 seconds) 10.42.43 # those can be had for under $1 and takes advantage of the unused stereo input that the F1C has 10.43.14 # efqw: http://www.shaftnet.org/~pizza/rb-wishlist.txt 10.44.27 Join Xeha [0] (~Xeha@unaffiliated/xeha) 10.44.31 # efqw: what about the digital FM extensions? 10.44.42 # would those be too difficult to support? 10.44.51 # hd radio, etc 10.44.55 # speachy: oh I missed it, lol 10.44.57 # braewoods: they are pretty power hungry and have extra licensing costs too, I think 10.45.03 # ah. 10.45.08 # just thought i'd throw that out there 10.45.18 # in some places analog FM is gone 10.45.21 # iirc 10.45.40 # there's "Hd radio" here but i've never owned a receiver 10.45.42 # the data/text sideband on analog fm is suppored widely in tuner ICs, but full HD radio stream decoding is another matter 10.46.15 # i've experimented with SDRs and got it kinda working but not really 10.46.35 # it's not as good as a hardware option 10.46.37 # lol 10.47.01 # interesting how CPU intensive SDRs are even for really old analog stuff 10.47.43 # that must be why it's always done in hardware for serious implementations 10.48.28 # Build Server message: Build round completed after 876 seconds. 10.48.29 # Build Server message: Revision 4e89e0e result: All green 10.48.52 # What's the BT module in the rocker? 10.49.02 # CSR8821 I think 10.49.12 # does it matter? i thought everything used USB bluetooth. 10.49.15 # UART based right? 10.49.25 # UART (or USB) with I2S for audio. 10.49.36 # since that's what every PC i've ever used has implemented bluetooth with 10.50.37 # but this is not PC 10.50.41 # indeed 10.50.48 # i just thought USB was the primary option 10.50.55 # on embedded systems it's mostly UART with an optional pcm interface 10.51.00 # pamaury: yes I'll have a look a bit later 10.51.26 # the only physical interfaces formally defined by the BT standards are UART, USB, and (I think) SDIO. I don't recall ever seeing the latter implemented. 10.51.54 # why do people use bluetooth? 10.51.59 # it seems really... weak 10.52.03 # low bandwidth, low range... 10.52.07 # braewoods: you mean besides the whole "no wires" thing? :) 10.52.19 # yea 10.52.30 # it seems like a giant hassle with minimal gains 10.52.31 # braewoods: and non-shitty BT audio codecs have been around for nearly as long as BT. 10.53.00 # bluetooth is more than good enough for what it was designed to do. 10.53.18 # speachy: you'd be surprised, check out drivers/bluetooth/*sdio.c 10.53.19 # wirelessly connecting low power accessories? 10.53.30 # or low bandwidth 10.53.31 # rather 10.53.50 # i wouldn't waste time implementing BT file transfe 10.53.51 # transfer 10.53.56 # it's too slow to be practical 10.54.25 # btmtksdio.c, btmrvl_sdio.c, btsdio.c 10.54.27 # BT for raw data transfer is rare 10.54.30 # usb can easily do megabytes... last time i tried BT file transfer it was measured in kilobytes 10.54.32 # lol 10.54.59 # BT 3.0 (I think) defined a high data rate transfer that basically consisted of handing the data over to wifi. 10.55.15 # i see 10.59.44 # Remember ampak? 11.00.03 # I think we can get FM+WiFi+BT modules from them. 11.00.33 # Even if we don't plan to use WiFi, it still fulfills the need for a FM tuner 11.00.43 # I do not want wifi. it's going to add a ton of system complexity. 11.00.55 # plus extra regulatory headaches 11.00.55 # i could only see one use to wifi and even then it would require a network stack to leverage 11.01.14 # BT still has the regulatory headaches tbh 11.01.27 # i have setup icecast and mpd before 11.01.29 # yes, but they are more self-contained 11.01.56 # you could remotely control rockbox over the network and such 11.02.00 # other than that I see little use 11.02.30 # i made a network controlled music player before 11.02.35 # braewoods: "streaming audio" is quite useful, but it's not one that makes much sense for us. 11.02.43 # indeed 11.02.53 # so more in the area of 11.02.55 # MPD 11.03.05 # which allows remote control of what the linux system is playing 11.03.08 # given there are plenty of alternatives on the market today. plus we'd probably never manage to get "apps" for the commercial services. 11.03.10 # My point is, you can power down the WiFi part, and you still get BT+FM within one module. 11.03.29 # who needs apps for rockbox? 11.03.34 Ctcp Ignored 2 channel CTCP requests in 1 hour and 28 minutes at the last flood 11.03.34 # * braewoods boggles 11.03.36 # That will help with board layout and simplify the design. 11.03.42 # braewoods: have you seen the plugin list? :) 11.03.49 # lol 11.04.10 # speachy: but yea, remote control via networking would be cool but that's the only use i see 11.04.13 # that's how MPD works 11.04.27 # it plays music on a system and remote users can control what it is doing 11.04.33 # it is network enabled 11.04.37 # but differnet use case 11.04.56 # if i was going to do that for RB, i'd probably write a bridge between MPD protocol and RB internals 11.05.08 # since MPD is well established 11.05.13 # plenty of clients for it 11.05.44 # I have extensive network-controlled audio but tbh rockbox is poorly suited from a UI perspective; there are vastly superior ones already to be had 11.05.55 # (even completely F/OSS ones) 11.06.04 # indeed so i'd just have it be a remote control interface of some kind 11.06.26 # there's another idea... 11.06.36 # I mean, a RPi+Hifiberry DAC will cost you what, $30? 11.06.38 # replicate the RB UI in a web interface or so 11.07.13 # but kinda pointless 11.07.37 # RB UI in a web interface would be as awful as our current touchscreen UI is today 11.08.15 # speachy: was the GCC toolchain updated? i'm building the toolchain and the script appears to have switch to 4.9.x 11.08.19 # at least for some targets? 11.08.33 # braewoods: mips and hosted stuff has been 4.9.x for a couple of years now, I think. 11.08.40 # oh. 11.08.42 # ok. 11.09.03 # I looked it up, the common AP6212 will do, it does BT4.0 and FM. Problem here is that I don't see separate pins to power down the WiFi part. 11.09.03 # it's weird how i see mips come up in embedded targets every now and then 11.09.22 # Broadcom had other chips that allow you to power down individual parts of the chip. 11.09.33 # broadcom is terrible about open source support though 11.09.59 # at best the linux kernel usually manages to... 11.10.13 # work with a mixture of firmware blobs and kernel drivers 11.10.37 # broadcom will be absolutely horrible to work with. 11.10.46 # if we don't have a volume in the seven digits 11.10.56 # they won't even answer the phone 11.10.59 # Is CSR(qcom) any better though? 11.11.06 # qualcomm? 11.11.14 # they bought atheros... 11.11.23 # CSR actually is better, but what helps is that their BT stuff is very self-contained. 11.11.27 # their qualcomm / atheros chips tend to be good 11.11.36 # no massive blobs, GPL violations, etc etc 11.11.37 # some older ones work without any firmware blobs 11.11.58 # MediaTek probably won't answer the phone either if you ask them about Airoha chips unfortunately. 11.12.02 # their wifi stuff has been barely tolerable at bast though 11.12.27 # (I have scars from dealing with Atheros back in the day; qualcomm made it _worse_) 11.12.50 # mediatek is pretty awful as well 11.12.59 # their official wifi drivers are 100% proprietary 11.13.10 # you can't even redistribute the source so... 11.13.12 # What I like about CSR is that you can store the firmware on a flash sometimes and don't have to worry about fw blobs. 11.13.21 # it's hard to get updated images for openwrt 11.13.38 # though the openwrt community has tried to develope their own driver for it 11.13.41 # it's still got issues 11.14.32 # i hope pine microsystems is of some help 11.15.03 # pamaury: It looks like that the NWZ_LINUX targets are likely broken with respect to anything that uses HOME_DIR. 11.17.42 # speachy: HOME_DIR? afaik there's 2 ways to look that up. assume the environment HOME variable is correct or look it up in passwd. 11.18.10 # HOME_DIR is a build-time constant, see firmware/export/rbpaths.h 11.18.13 # Oh. 11.18.15 # Ok. 11.18.22 # so hard-coded 11.18.34 # hmmm 11.18.36 # there is a special case in place to deal with $HOME on targets that actually set it (eg simulator) 11.20.43 # we have places that hardcode using HOME_DIR in paths, and that gets passed into the hosted FS code that in turn tries to prepend HOME_DIR. 11.21.13 # basically only places that should be using that HOME_DIR #define are the core filesystem code. everything else should just use "/" 11.21.52 Join petur [0] (~petur@rockbox/developer/petur) 11.24.50 # I wasn't able to find out who made the BT module in the rocker unfortunately 11.25.04 # That form factor is rather unique and hard to find 11.25.47 # If you search for "Bluetooth module" most of the results that pops up are either those old chunky CSR stuff or ampak modules 11.25.52 # efqw: CSR8821? 11.26.35 # whoops, CSR8811 11.27.29 # yeah, 8811 makes sense 11.27.30 # Or I guess that's not hte acual "module" 11.27.43 # I was looking for 8821 but didn't find anything 11.28.32 # not clear if it's that's just the IC and additional external components are under that can 11.36.37 # ok, it's probably just the chip, a crystal, and some small passives 11.42.08 # https://www.techrepublic.com/pictures/cracking-open-the-samsung-galaxy-tab-77/63/ 11.42.35 # something like this but more condensed basically 11.52.23 Quit koniu (Ping timeout: 240 seconds) 11.52.58 # speachy: Have you managed to get a modified ubi with rb on it? If you ever do please send a copy to me so I can try it out. 11.53.41 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 11.54.32 # I haven't gone that far yet. tonight probably. I'm still kicking at other general hosted bugs. 11.57.01 # sure, lmk if you do, I'll do more research on the ota part 12.03.53 # ok, think I've finally got the rbpath mess cleaned up. 12.04.05 # should fix a pile of misc bugs on our mostly-little-used hosted targets 12.04.19 # and hopefully not introduce new ones on some of the corner cases 12.05.15 # I need to land the eros changes first 12.05.52 # but that will have to wait until I get back; I'm pretty sure I'm going to introduce some yellow with the next two. 12.06.08 # Build Server message: New build round started. Revision 5efaa9e, 287 builds, 10 clients. 12.06.10 # and then I'll try to generate a m3k patched image 12.11.11 # sounds good 12.11.25 # regarding the public key found in fiio 12.12.00 # *found in fiio's recovery initramfs, I'm having trouble getting it into a human-readable format 12.12.15 # It's a text file that starts with "v2" 12.14.36 Join icypee [0] (493c5e9d@c-73-60-94-157.hsd1.ma.comcast.net) 12.14.42 # hello 12.14.51 # i moved all my data to a new sd card 12.14.58 # and now rockbox won't read it 12.15.04 # how do i fix this? 12.18.59 Quit pamaury (Ping timeout: 240 seconds) 12.20.07 # Build Server message: Build round completed after 839 seconds. 12.20.09 # Build Server message: Revision 5efaa9e result: All green 12.23.10 Quit michaelni (Ping timeout: 246 seconds) 12.32.46 Join johnb3 [0] (~johnb2@p5b3af6d7.dip0.t-ipconnect.de) 12.36.40 *** Saving seen data "./dancer.seen" 12.37.19 # oh, I found the format 12.38.03 # It was explained in $BSP_v6.0/development/tools/ota/verifier.c 12.38.31 # *$BSP_v6.0/development/tools/ota/src/verifier.c 12.38.38 Quit icypee (Remote host closed the connection) 12.38.53 Join sakax [0] (~r0b0t@unaffiliated/r0b0t) 12.39.47 Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) 12.41.16 # The verifier code and RSA code were taken from an old branch of this: https://android.googlesource.com/platform/bootable/recovery 12.41.33 # speachy: how does that github mirror of Rockbox' git work? Is it being pushed to regularly from the server? 12.42.42 # played around with github actions, managed to get Rockbox Utility build with it (Linux for now): https://github.com/bluebrother/rockbox/actions 12.43.21 # so adding the github workflow file to the main repo should eventually end up in the mirror, making github do the build afaiu. 12.43.34 # could be interesting to get regular builds of Rockbox Utility. 12.45.01 # oh, there's even an irc notifier action. 12.45.04 # pamaury done 13.10.43 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 13.11.57 # speachy: I don't remeber much what HOME_DIR is about, I never wrapped my head around hosted port, too much magic 13.24.35 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 13.32.04 Quit beencubed (Quit: Leaving) 13.36.34 Join beencubed [0] (~beencubed@209.131.238.248) 14.00.27 # took a fair effort but I finally figured out how rockbox does bootloader validation in the iriver_flash plugin 14.00.51 # not to mention the crc32 algorithm is a bit weird. 14.02.45 # i thought it would be identical to cksum since they use the same polynomial but nope 14.03.24 # so i ended up writing a short C program to duplicate the crc32 checksumming on my desktop so i can find the actual checksum for adding the test bootloader to the existing table 14.03.56 # what a pain but it works i guess 14.04.08 # it successfully works with the known good bootloaders 14.08.38 Quit Rower (Ping timeout: 256 seconds) 14.18.29 # <_bilgus_> do they use the same polynomial maybe its mi4 I was thinking of that uses a different one 14.19.08 # _bilgus_: the source for firmware/common/crc32.c says it uses... 14.19.29 # 0x04C11DB7 14.19.51 # above the lookup table 14.20.23 # https://en.wikipedia.org/wiki/Cksum 14.20.36 # same here 14.20.41 # so no idea why they're different 14.20.52 # i'm not an expert on crc32 implementations 14.21.07 # main reason i've seen differences though were different polynomials 14.22.04 # i should check the coreutils implementation just to verify that 14.26.23 # cstrange 14.26.25 # strange 14.26.27 # anyway 14.26.44 # even if it's wrong... can't really change it now for compatibility reasons 14.27.14 # just noticed i couldn't reproduce the table checksums with cksum. 14.27.30 # which i assumed would be the same since they supposedly use the same polynomial 14.29.18 # <_bilgus_> generally you seed the crc function with an initial seed 0xFFFFFFFF this also functions as a continuation function 14.30.03 # <_bilgus_> so if you need the proper starting seed that could explain the issue 14.31.13 # their starting CRC value is 0 14.31.18 # in coreutils 14.31.27 # i'll see what happens if i do that with RB's function 14.32.23 # nope 14.32.28 # oh well 14.32.40 # doesn't matter to me that much to find out since the RB implementation is what matters here 14.33.49 Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) 14.34.05 # speachy, _bilgus_: how does this look for a consolidate set of build and setup instructions for bootloader building? 14.34.07 # https://dpaste.com/3KUZHKJJP 14.34.25 # it appears to work 14.34.27 # but 14.34.38 # i've never built this before so not sure if i've overlooked anything 14.36.12 # <_bilgus_> the dependencies looks a bit short but if itworks it works 14.36.23 # _bilgus_: that's from the wiki page... the beginners guide 14.36.33 # it compiles just fine afaik 14.36.43 # https://www.rockbox.org/wiki/LinuxSimpleGuideToCompiling 14.36.45 *** Saving seen data "./dancer.seen" 14.36.47 # is what i based it on 14.37.54 # <_bilgus_> yeah I think strife updated or made that a while back.. 14.40.21 # i based it on Debian 10 host 14.40.57 # anyway i'll see where i can go with this 14.41.11 # just wanted to be pretty sure i'd followed the instructions completely 14.41.41 # i plan to build new bootloaders for both h1x0 targets 14.41.49 # but i can only test the h120 / h140 14.42.05 # the other one... i guess i'll assume it works if the other does since they're related 14.42.32 # i can't even find the h115 etc for sale used 14.42.38 # the h120 and h140 are more common 14.43.13 # I ended up with one of each for about $120 combined 14.43.18 # err 14.43.20 # 2 h120s 14.46.48 Quit petur (Remote host closed the connection) 15.08.57 # interesting line in that source though 15.09.12 # const unsigned char *buf = (const unsigned char*)src; 15.09.19 # the originally is a const void* 15.09.36 # is a cast really necessary considering void is implicitly converted when reassigned? 15.10.23 # no warnings from my GCC 15.11.33 # at least I understand why (void) casts are sometimes done 15.11.54 # tell the compiler something is either unused or only used for side-effects 15.12.35 # i've done it to suppress warnings for unused parameters in callback functions before since it's a portable way to do so. 16.26.00 Quit pamaury (Ping timeout: 256 seconds) 16.36.48 *** Saving seen data "./dancer.seen" 16.39.23 # Build Server message: New build round started. Revision 2a471e2, 290 builds, 9 clients. 16.43.12 Quit _bilgus_ (Remote host closed the connection) 16.45.07 Join _bilgus_ [0] (~bilgus@2605:a000:1301:89f6:7df7:7326:e72f:ac24) 16.53.37 Quit sakax (Remote host closed the connection) 17.04.17 # Build Server message: Build round completed after 1494 seconds. 17.04.18 # Build Server message: Revision 2a471e2 result: 112 errors 0 warnings 17.21.15 # Build Server message: New build round started. Revision a5add39, 290 builds, 9 clients. 17.30.37 # it occurs to me that instead of all of this pivot_root nonsense, why not just use chroot instead... 17.42.27 # Build Server message: Build round completed after 1271 seconds. 17.42.28 # Build Server message: Revision a5add39 result: All green 17.45.55 Quit lebellium (Quit: Leaving) 17.48.27 Quit _bilgus_ (Remote host closed the connection) 17.49.35 Join _bilgus_ [0] (~bilgus@2605:a000:1301:89f6:7df7:7326:e72f:ac24) 18.15.15 # Build Server message: New build round started. Revision db6f21e, 290 builds, 9 clients. 18.30.22 # Build Server message: Build round completed after 907 seconds. 18.30.23 # Build Server message: Revision db6f21e result: 7 errors 1 warnings 18.36.49 # Build Server message: New build round started. Revision 135b3f6, 290 builds, 9 clients. 18.36.52 *** Saving seen data "./dancer.seen" 18.38.46 # speachy: afaik pivot_root is mainly for initramfs to change to the true root 18.39.35 # it allows for a handover for the actual running system from the early boot one 18.39.50 # but i doubt initramfs is used much in embedded 18.39.53 # what's called PIVOT_ROOT in our code is actually a mostly-faked chroot 18.39.59 # Oh. 18.40.12 # i thought you meant the Linux pivot_root feature. 18.40.20 # literally the same name 18.40.59 # you can do a lot of weird stuff with chroots 18.41.10 # bind mounts... mount namespaces... 18.41.12 # etc 18.43.24 # but it's now all cleaned up to the point where proper chroot is _finally_ possible. bleh. 18.43.52 # all internal paths are relative to /, and only in a single place do we prepend the actual system root 18.48.01 # speachy: have you looked at openat, etc? 18.48.41 # those can be pretty useful for coding for opening paths relative to a directory without having to maintain the directory path. 18.52.15 # Build Server message: Build round completed after 926 seconds. 18.52.16 # Build Server message: Revision 135b3f6 result: All green 19.08.44 Join w4tchguard [0] (~w4tchguar@2001:ac8:84:33::a10d) 19.30.07 Join mendelmunkis [0] (~mendelmun@ool-435680b7.dyn.optonline.net) 19.36.09 # what do I need to do to update my build machine? 19.36.15 Nick mendelmunkis is now known as mendel_munkis (~mendelmun@ool-435680b7.dyn.optonline.net) 19.41.58 # take the rockboxdev.sh in the gerrit commit and regenrate everything 19.42.20 # then update the rbclient.sh script used to invoke things and tell it you have the gcc494 stuff 19.51.39 Join fs-bluebot_ [0] (~fs-bluebo@55d44e1a.access.ecotel.net) 19.51.48 Quit bluebrother (Disconnected by services) 19.51.53 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 19.53.48 Quit fs-bluebot (Ping timeout: 256 seconds) 20.04.23 # I'm regenerating the toolchains myself now. 20.07.18 # BTW, I don't recommend putting them in /usr/local (ie the default), as it makes it a lot harder to blow them away properly 20.07.37 # I have mine in their own location, and add them to $PATH 20.36.56 *** Saving seen data "./dancer.seen" 21.39.27 # <_bilgus_> speachy got the rocker much smaller than I expected and the OF bluetooth menu is terrible 21.39.41 # <_bilgus_> what was it you wanted me to test? 21.39.48 # yeah. its functionality isn't all that much better. :) 21.41.12 # _bilgus_: http://www.shaftnet.org/~pizza/rb-rocker.upt 21.41.19 # pair that with the latest dev build. 21.43.02 # (rename that file to upgrade.upt, and in the OF you can tell it to initate an upgrade) 21.43.34 # (one of the enhancements I've made to the loader is the ability to initate these upgrades without using the OF) 21.44.18 # basically I need to make sure the loader still works properly on the rocker, and the tools menu fits/is usable 21.50.48 # other enhancements -- plugging the USB cable in the loader no longer force-enters the OF's USB mode (it uses the last selection, unless adb is running in which case it does nothing) 21.55.25 # <_bilgus_> compiling.. 21.57.15 # the Rocker is in much better overall shape than it was a couple of weeks ago. Other than bluetooth and some possibly questionable keymaps, it's a solid player now. 22.00.24 # <_bilgus_> for multiple devices at that excellent rockboxery there speachy 22.01.27 # we're fortunate this hibylinux platform is so widespread and easy to inject ourselves into 22.12.38 # <_bilgus_> upgrade.upt and I assume it goes in the root? 22.12.46 # <_bilgus_> tells me NO UPGRADE! 22.17.07 # <_bilgus_> nm update.upt 22.17.38 # <_bilgus_> v_v succeed 22.36.58 *** No seen item changed, no save performed. 22.46.38 Join gu4rd__ [0] (~w4tchguar@2001:ac8:84:31::a08d) 22.49.55 Quit w4tchguard (Ping timeout: 240 seconds) 22.50.51 Join w4tchguard [0] (~w4tchguar@2001:ac8:84:37::a14d) 22.51.25 Quit gu4rd__ (Ping timeout: 240 seconds) 23.45.13 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 23.57.09 Quit [7] (Disconnected by services) 23.57.15 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)