--- Log for 18.10.120 Server: wilhelm.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 20 days and 19 hours ago 00.03.44 # Stanley00: what's crashing, exactly? The x1000e is supposed to be a mips32r2 core, and none of the other x1000 targets seem to crash with it. 00.04.14 # really, it's got SIGKILL, cannot run on my m5 00.04.24 # or is the m5 not an x1000? 00.04.30 # but when I replace it with just mips32, it work fine 00.04.41 # m5 is also x1000e as in spec 00.04.42 # "it" meaning the rb binary? 00.04.47 # yup 00.05.08 # let me check a gain, I did some modified recently, I might have mess it up 00.05.10 # one sec 00.07.28 # I mean, it's certainly possible fiio did something really funky with the m5 00.07.42 # <_bilgus__> Stanley nuke your staging dirs 00.08.28 # efqw: incidently, mainline just gained X2000-series support 00.08.58 # or rather, it's about to. 00.09.48 # the rest of the ingenic code got reorged too, unified with the generic mips code 00.11.15 # efqw: I swear, the more you dig into the m3k the more I want to nuke it from orbit. trying to "fix" anything in that hacky mess seems like a complete waste of effort. 00.11.24 # nvm, it's my bad with the config 00.11.31 # mips32r2 work fined 00.11.40 # *well 00.12.31 # Our current roadblocks for mainline support on the x1000 are: SFC, SLCD, The I2S stuff, and the PMU (AXP192). 00.12.52 # Yeah, it's like an onion, the more you peel it the harder you cry. 00.13.27 # This is by far the hackiest device I've ever seen. 00.14.23 # efqw: as far as shutting down is concerned, I really don't like the idea of issuing that ioctl from within rockbox; I assume it would effectively kill the sytem as-is, with things mounted and stuff possibly not flushed to disk properly 00.14.37 # bingo 00.14.45 # This is exactly what it does. 00.19.22 Quit Stanley00 (Ping timeout: 246 seconds) 00.21.09 # I doubt the i2s would be more than a tweak of the existing 4770 driver. ditto the axp192 (vs the other axp series) 00.21.42 # anyway. 00.23.33 # _bilgus__: no change in thumb settings was part of this. I think by default thumb is not used unless necessary for the processor. 00.24.18 # I don't know if GCC is smart enough to automatically choose thumb or not on a per-function basis 00.25.11 # it makes code smaller, and usually (slightly) slower 00.25.21 # <_bilgus__> there are some pragmas IIRC 00.25.43 # <_bilgus__> but automagic NTIKO 00.25.52 # <_bilgus__> ^coined? 00.26.36 # <_bilgus__> some slightly faster its prob a wash 00.26.42 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 00.27.16 # <_bilgus__> I wasn't suggesting enabling it any further than we already did I was just mentioning it as one of the hidden settings 00.27.44 # I think the way it's implemented (via that python wrapper) is seriously janky 00.27.50 # <_bilgus__> amognst others that aren forthcoming from my head 00.28.19 # <_bilgus__> dude that whole system is janky wait till you see my lua wrappers :p 00.28.46 # I mean, if we want thumb, why not just turn on -mthumb -mthumb-interwork in the global CFLAGS and be done with it? :) 00.29.34 # well, it will automatically retry compiling that specific file without -mthumb if it fails with it. 00.30.40 # probably worth a try to see how bad the fallout is. 00.30.56 # <_bilgus__> yeah no clue I try to stay away from the dark places until I really have to 00.31.27 # * speachy looks at the lcd rewrite _bilgus__ is cooking and seriously questions his last statement 00.31.28 # <_bilgus__> like the codecs folder 00.31.37 Quit Stanley00 (Ping timeout: 258 seconds) 00.31.43 # <_bilgus__> yeah lol but thats irked me for like 4 years 00.31.55 # I intend to kick the codec folder anthill next 00.32.03 # * _bilgus__ shudders 00.32.47 # anywhere overriding our warning flags is automatically suspect 00.32.53 # <_bilgus__> I get about half way into the hand optimized assembler and then start questioning if its worth it 00.33.34 # well, it's either that or finish hacking FP awareness into our threading/scheduler. :D 00.34.40 # which reminds me, I also need to revisit our threading on hosted and SDL. 00.35.16 # and on that note. I"m done for today. 00.35.45 # if you don't mind, please give the latest rocker bootloader a whirl (installable via rbutil, or a pre-patched one is on d.r.o too) 00.36.12 # <_bilgus__> same link as earlier? 00.39.21 # yeah. crap. forgot to update the checksum file. 00.39.26 # don't think rbutil cares though 00.40.00 # in hwinfo debug it'll report the BL build now too 00.40.08 *** Saving seen data "./dancer.seen" 01.26.52 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 02.19.55 Quit tobbez (Ping timeout: 240 seconds) 02.40.10 *** Saving seen data "./dancer.seen" 04.32.22 Join johnb3 [0] (~johnb2@p5b3af701.dip0.t-ipconnect.de) 04.33.34 Quit Stanley00 (Ping timeout: 256 seconds) 04.40.13 *** Saving seen data "./dancer.seen" 04.53.57 Quit S|h|a|w|n (Read error: Connection reset by peer) 05.10.52 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 05.41.12 Quit pamaury (Ping timeout: 265 seconds) 05.44.28 # speachy after updating BL and RB to the latest versions, I just tried OTG on the X3ii. Pretty cool! 06.40.14 *** Saving seen data "./dancer.seen" 06.48.40 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 06.55.16 # speachy: thanks for the theme page 06.55.23 # YP-R0 sd card: /dev/sdd1 06.56.56 Join MrZeus_ [0] (~MrZeus@185.195.232.139) 07.00.39 # well, I have a different result with OF and Safe Mode 07.02.17 # with Safe Mode: /dev/sdb = user internal memory (where .rockbox is); /dev/sdc: hidden internal memory; /dev/sdd1: SD card 07.02.48 # with OF: /dev/sdb = internal memory; /dev/sdc1: SD card 07.07.30 Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) 07.15.16 Join petur [0] (~petur@rockbox/developer/petur) 08.07.34 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 08.15.06 # speachy: I finally make it, https://gist.github.com/Stanley00/6d9b121ccfca7b8f70a75991d0264b31 08.16.55 Join Huntereb [0] (~Huntereb@174.226.3.228) 08.17.58 # basic playback and some plugins/games work, didn't test them all 08.18.10 # bootloader also works 08.24.55 Quit _bilgus__ (Remote host closed the connection) 08.26.45 Join _bilgus__ [0] (~bilgus@65.186.35.190) 08.34.42 # rasher: would it be possible to update the Simulator builds for Windows? http://rasher.dk/rockbox/simulator/ 08.40.17 *** Saving seen data "./dancer.seen" 09.02.39 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) 09.14.04 # lebellium: I meant from within the device itself 09.14.34 # speachy: but you removed the system files browser :) 09.15.10 # I have to revert back to an older build then 09.15.13 # and the sim builds... they potentially change every commit. we rebuild them all on the farm, but only linux. 09.15.58 # we don't even keep the binaries, just make sure they build. 09.26.19 # under \dev I have gadget, pts, shm, snd and v41 09.26.43 # otherwise I have mnt\media0, media1 and mmc but I already told you that 09.28.11 # Stanley00: so the m5 appears to be more akin to the hiby players 09.28.40 # lebellium: there's no block devices under /dev? that's odd 09.28.45 # yeah, kind of missing between m3k and hiby 09.30.04 # Stanley00: you can probaby use usb-hiby.c directly instead of patching fiio-usb.c 09.30.25 # speachy: well, I just changed the file browser settings to display hidden files. I have dev\mmcblk0, mmcblk0p1, mmcblk1, mmcblk1p1 09.30.29 # thanks, let me check that 09.30.58 # ditto on the bootloader; should be able to add a few #ifdefs to rocker_linux.c 09.32.08 # lebellium, two mmc devices, huh. I wonder if blk0 is the internal storage? 09.32.29 # how can I tell? 09.32.30 # do you have the ability to get a shell on it? 09.32.40 # I don't know what a shell is :) 09.32.46 # eject the sd card and see if any of those go away 09.33.34 # I still see the same files after ejecting the sd 09.33.43 # I'll reboot the device to be sure 09.34.25 # I confirm, still the same files 09.35.25 # speachy: oh, I see, so we just prefer to reuse the file with #ifdef instead of seperated for each platform then? 09.35.39 # Stanley00: when the only code change is a few #defines, absolutely 09.35.55 # these things are basically all built on the same "platform" 09.36.26 # agree, I just didn't how much should I change back then, let me try another patch then 09.38.10 # lebellium: another place to look is /sys/block/ 09.39.42 # sys/block/mmcblk0 when the card is inserted. no file when ejected 09.39.56 # awesome, thank you. 09.40.12 # any chance you could do the same on the sony? 09.40.31 # will also have to revert back to an older build, thank you :) 09.40.42 # sorry about that.. 09.41.09 # if I had one of thee things in front of me I'd be able to do it myself 09.42.53 # sdcard is mmcblk1 09.43.22 # there is also mmcblk0 which stays here whatever sd card inserted or ejected. 09.43.32 # excellent. 09.46.23 # so under /storage, do you already see the contents of everything, or just internal stuff? 09.46.26 Quit petur (Remote host closed the connection) 09.46.36 # or are there subdirs under there? 09.48.07 # should I have a storage folder? 09.50.08 Join simpleOne [0] (~simple@2a01cb0589a17d00b46ee167840143a1.ipv6.abo.wanadoo.fr) 09.50.15 # at root? or where exactly? I can't see it 09.50.31 # sorry, /contents 09.51.09 # _supposedly_ .rockbox exists directly under /contents 09.51.18 # contents is only internal memory. Alternatively, allcontents\int and ext 09.51.34 # yes .rockbox is under contents 09.51.41 # and /mnt/mmc is the sd? 09.52.06 # no, mnt/media 10.00.29 # ok. I need to write some more glue code for the nwz platform to enable hotswap but at least I have the paths correct now. :) 10.02.29 # is it easy to compile a Simulator for Windows from my Linux VM ? 10.08.59 # http://www.shaftnet.org/~pizza/rb-a10.zip 10.09.46 # if it actually works, you'll see in the top-level file listing when the card is inserted, and it will let you browse to it. 10.15.16 # I see 10.15.27 # and does it work? 10.15.44 # yes 10.15.56 # sweet, got it right. 10.16.13 # _hopefully_ the other sony targets place things in the same place 10.16.38 # Only the A10 and A20 have a microSD slot 10.16.50 # and the A20 is very close to the A10 10.18.14 # I just checked my E580, it's also in contents 10.18.30 # so none of the E series has an SD slot. 10.18.35 # nope 10.20.03 Join johnb3 [0] (~johnb2@p5b3af701.dip0.t-ipconnect.de) 10.20.06 # okay, the sd jiggery is now limited to the two A models 10.23.28 # Build Server message: New build round started. Revision 6a94f1e, 291 builds, 10 clients. 10.34.33 # I am trying to move from virtualbox to WSL. I am trying to build the toolchain for mips. rockboxdev.sh complains about missing mpfr. How do I install this in Ubuntu 20.4? 10.38.09 # Build Server message: Build round completed after 882 seconds. 10.38.13 # Build Server message: Revision 6a94f1e result: All green 10.38.14 # johnb3: I think simply run apt install libmpfr-dev should help 10.38.38 # apply the same for remain required libs for gcc 10.40.18 *** Saving seen data "./dancer.seen" 10.40.51 Join Tighe [0] (ad31c8fa@pool-173-49-200-250.phlapa.fios.verizon.net) 10.41.23 # Is their any development on iPod Nano 3rd Gen? 10.41.43 # thanks that worked. I compiled for arm before, so gcc should be already done. 10.43.07 # nope, it is building it again ... :-( 10.45.27 Quit Tighe (Remote host closed the connection) 11.03.36 Quit Stanley00 () 11.06.33 # <_bilgus__> see ya in 6 hrs :P 11.07.42 # actually I am done already. I have the arm and mips tool chain. Building the x3ii (bin) was less than a minute. 11.12.21 # So apparently it was reusing stuff. 11.15.13 # hmm. need player pics for the erosq/k still 11.43.21 Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) 12.00.54 # <_bilgus__> Well down to one? last issue with the fb rewrite and its in the greylib didn't change anything there and I can't seem to find where it does the final copy to the framebuffer buttttt I will eventually figure it out 12.05.37 # _bilgus__: let me know if you need more testing. 12.05.57 # i ordered some H320s from ebay to do some testing of the sister port 12.06.32 # given the realities we deal with on these i think i will end up extending the iriver_flash port to cover the H300 series as well 12.06.45 # in theory they should work since they are similar enough 12.07.37 # <_bilgus__> braewoods, hopefully soon but I'll try to get all the known bugs worked out first 12.08.04 # basically i intend to finish what the previous developer started 12.08.12 # to the extent that is realistic 12.08.20 # but first i need to see what of the old notes is still relevant 12.08.31 # it's been over 10 years. some of them may no longer apply. 12.10.01 # <_bilgus__> I think our 4.0 release is gonna be exciting with all these 'New' players! 12.10.11 # is that the next release? 12.10.15 # or is 3.16 the next one? 12.10.30 # <_bilgus__> yeah we ditch the HWcodecs next release is 4.0 12.12.29 # <_bilgus__> when I say we I mean speachy lol 12.14.17 # what releases still used them? 12.14.28 # <_bilgus__> 3.15 12.14.32 # i mean 12.14.34 # what targets 12.14.54 # <_bilgus__> ah archos and something else 12.15.02 # archos is retired 12.15.12 # <_bilgus__> yes after 3.15 12.15.32 # i guess it was retired due to it being to UPed for software 12.15.50 # but software decoding is far more flexible 12.15.53 # and portable 12.16.28 # <_bilgus__> our main issue was that they are rare and it had a ton of conditional code 12.16.36 # i see. 12.17.02 # as in so rare they only show up on ebay once in a blue moon? 12.17.50 # <_bilgus__> as in there is one person with an archos we have seen in two? years 12.18.06 # ah. 12.18.12 # wow. 12.18.22 # these things were clunky 12.18.24 # giant 12.18.32 # make my iriver h120 look small 12.18.36 # <_bilgus__> and she stated she didn't upgrade because the bootloader stopped fitting many releases ago 12.18.54 # ah so rockbox had outgrown it 12.19.05 # <_bilgus__> pretty sure it was the first target 12.20.52 # interesting 12.21.06 # the current h300 / h120 / h100 bootloaders use about 58k 12.21.10 # only about 7k to spare 12.21.46 # <_bilgus__> you should see the effort I had to go through to get multiboot into the sansas 12.22.02 # how much space did you have to work with? 12.22.16 # in the case of rockbox it has about 64k for these to work with 12.22.25 # <_bilgus__> it was down to 100 bytes left when I got done 12.22.31 # and the total space? 12.22.35 Join johnb3 [0] (~johnb2@p5b3af701.dip0.t-ipconnect.de) 12.22.38 # available 12.22.42 # for the bootloader 12.22.52 # <_bilgus__> I wanna say under 10mb we compress the OF and piggyback 12.23.01 # I se. 12.23.04 # see 12.23.41 # the iriver coldfire targets seem unique in that they store their bootloader in literal ROM 12.23.55 # so you can literally replace the OF 12.24.13 # <_bilgus__> In theory you could alway add another layer of bootstrap 12.24.46 # there's not much value in the OF on these if you want to upgrade them since flash based storage is the main option today 12.25.03 # and they don't work with flash based storage 12.25.06 # for whatever reason 12.25.10 # rockbox does just fine 12.25.54 # <_bilgus__> the great thing about OSS 12.25.56 # but while i'm working on the H300 bootloader i plan to stick to the original HDD 12.26.08 # since i may need to boot the OF 12.26.22 # plus, testing. 12.28.57 # though i can't say i think the H300 bootloader needs much more 12.29.14 # mostly just feature parity and a few odds and ends... if space allows 12.35.41 # interesting 12.35.52 # checking the FW patching routines.. 12.36.18 # it appears that the H100 and H300 firmwares use different offsets for the bootloader 12.40.19 *** Saving seen data "./dancer.seen" 12.42.23 # interesting... 12.42.40 # the BL entry point is listed differently in the H300... 12.42.44 # something is fishy here 12.43.06 # i'll need to read the ROM from within rockbox and see where the bootloader is actually stored 12.43.10 # make sure the assumptions are sane 13.06.27 Join beencubed [0] (~beencubed@209.131.238.248) 13.07.40 # Build Server message: New build round started. Revision 7603533, 291 builds, 10 clients. 13.09.40 Quit _bilgus__ (Read error: Connection reset by peer) 13.10.43 Join _bilgus__ [0] (~bilgus@65.186.35.190) 13.13.33 Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) 13.19.38 # yay. Finally got rbutil to build on macox 10.15. 13.20.31 # bluebrother^: i may need your assistance when i'm ready to publish new bootloaders for the main iriver ports 13.20.38 # so they can be available in rbutil 13.21.05 # ok 13.21.30 # i'm planning some new features if they don't make the bootloaders too big 13.21.42 # Build Server message: Build round completed after 843 seconds. 13.21.49 # mostly to bring it to feature parity with the H100/H120 bootloaders 13.21.56 # Build Server message: Revision 7603533 result: All green 13.22.08 # they can boot RB from flash but the H300 bootloader doesn't yet support it though it should be able to 13.22.08 # Build Server message: New build round started. Revision d097742, 291 builds, 10 clients. 13.22.52 # going to need to do some research to see how i can extend iriver_flash to support updating the bootloader from within rockbox 13.23.08 # but for now i wait for the units I ordered to arrive 13.26.06 # I could use some help getting manuals written (with keymaps) for these new targets 13.26.41 # because there's really no reason for them not to be considered "stable" 13.31.19 # speachy: anything specific? 13.32.01 Join johnb3 [0] (~johnb2@p5b3af701.dip0.t-ipconnect.de) 13.32.10 # installation instructions are probably cut-n-pasteable, but mostly a matter of screenshots where relevant and filling in the keymaps. 13.32.58 # AGPTek Rocker, xDuoo X3ii/X20, eros Q/K (and their clones) 13.33.06 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) 13.33.14 # do they have the same screen size? 13.33.58 # xduoo are portrait, eros landscape 13.34.18 # 320x240 or so 13.34.20 # 128x160 (I think) 240x320, and 320x240. So the latter set should be okay, not sure about the first 13.34.34 # Build Server message: Build round completed after 746 seconds. 13.34.40 # Build Server message: Revision d097742 result: All green 13.34.41 # Build Server message: New build round started. Revision a05d061, 291 builds, 9 clients. 13.35.07 # still haven't finished generating screenshots for the X3 yet. 13.35.14 # (or its keymaps) 13.35.49 # screenshots are done with the setting in debug + usb connect, right? 13.35.59 # I found it easier to do them in the simulator :) 13.36.38 # but for the manual, we only need to regen the screenshots once for a given screen size/depth 13.36.42 # ;-) Do we have simulator build for all of them? 13.37.04 # unless there's there's something unique about a particular sceenshot 13.37.35 # the eroses dont' have sim builds yet, mainly because I don't have playerpics yet 13.38.18 # I suppose fixing (or disabling) some of the wonky plugins would be a good idea too 13.38.36 # eg quake and duke3d supposedly goes kabloeey. most likely RAM limitation 13.39.11 # nice. Now github builds Rockbox Utiltiy for Linux and macOS :) 13.40.05 # bluebrother^: are those linked off hte wiki / download / etc pages? 13.40.48 # speachy: no. Right now it's a branch on my mirror of Rockbox that's used, and I only do build them so far, not even archive. 13.40.49 # speachy Is building the simulator straight forward (just the choice during make)? 13.41.00 # main issue was to get it compile on a recent macOS. 13.41.48 # next would be to have it build a Windows binary too. 13.41.56 # Also, where can I check for naming conventions (samples) for screenshots? 13.42.39 # where in the git repo ... 13.42.51 # johnb3: naming is ss-[name]-[resolution]{-player}.png 13.43.00 # manual/*/images 13.43.50 # speachy: I tried to play rockboy Mario Tennis on the Agptek H3 yesterday but the scrolling wheel is a pain 13.44.00 # I need a better target for that purpose :D 13.44.56 # the {-player} is optional and only used if you have an existing screenshot for that resolution but need a different one for a specific player. 13.46.00 # so mostly for the clips with their different color at the top 13.46.43 # Build Server message: Build round completed after 722 seconds. 13.46.44 # Build Server message: Revision a05d061 result: All green 13.46.46 # Build Server message: New build round started. Revision 1a1338c, 291 builds, 10 clients. 13.50.34 Join petur [0] (~petur@rockbox/developer/petur) 13.52.38 # As the 240x320 is already available for the x3ii, it is mainly about rockbox_interface/images/ ? 13.56.23 Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) 13.59.16 # Build Server message: Build round completed after 751 seconds. 13.59.18 # Build Server message: Revision 1a1338c result: All green 14.03.25 # johnb3, it's really a matter of adding keymaps 14.40.21 *** Saving seen data "./dancer.seen" 16.10.02 # lebellium: you said you own irivers from the H100 and H300 series? do you own any remotes? if so, which types? i've been trying to research the remotes and all i could find is the H100 series remote which is also H300 compatible. 16.10.29 # lebellium: but apparently there's also 2 kinds of H300 remotes but i have no idea what they look like. 16.10.50 # it appears to be one of the missing features but if i can't find any there's no way to support them 16.11.31 # plus support might be impossible anyway since the few notes i find suggest they found no way to detect the remote differences 16.13.18 # huh. ok. 16.13.32 # found the non-lcd remote in the manual 16.20.06 # I have the lcd remote which works for both H100 and H300. There is also a non-lcd remote for H10 16.21.01 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 16.22.35 # I'm not sure whether the non-LCD H10 remote also works with H100 and H300 16.22.47 # I would say probably yes 16.25.13 # the non-LCD remote in the H300 user manuals looks exactly like the H10 remote 16.26.28 # https://www.adverts.ie/ipod-mp3/iriver-h300-series-remote/200540 16.27.02 # -> this is probably the true LCD remote for H300 that no-one has 16.27.19 # The H100 remote is far more common 16.27.45 # so not much point in trying to support hardware that is that rare 16.28.06 # plus, what does it do that the H100 remote doesn't? 16.28.51 # oh ! https://www.rockbox.org/wiki/KeymapIriverHSeries 16.28.59 # Didn't even know we had such a great wiki page 16.30.11 # good to know 16.30.18 # but both h300 remotes that i can tell are super rare 16.30.28 # only seen them bundled with h300 units 16.30.30 # if at all 16.30.41 # at least at this point in time 16.31.25 # I think most H300 were sold without it 16.31.38 # yea 16.31.42 # It was probably a pricer bundle only sold in some regions 16.31.55 # and i'm not seeing anything unique to it 16.32.08 # they both have the same basic type of screen 16.32.28 # well, the design better suits the H300 case compared to the H100 remote. I would definitely buy it if I can find it one day :D 16.33.37 # lebellium: you own an iriver h10? 16.33.42 # yes 16.33.46 # the 20GB? 16.34.01 # yes 16.34.24 # but the HDD and battery are dying 16.34.32 # you can replace those thankfully 16.35.14 # the cradle seems to be rather rare 16.36.29 # lebellium: what does the remote look like? 16.37.03 # https://ireland.apollo.olxcdn.com/v1/files/7f9whq8liza53-PL/image;s=1000x700 16.37.08 # I don't have it 16.37.18 # ah 16.37.41 # but as I said, it looks like the same as the one in the H300 user manual 16.38.12 # Build Server message: New build round started. Revision 0851310, 291 builds, 10 clients. 16.40.22 *** No seen item changed, no save performed. 16.41.10 # they also made several LCD remote controls for their CD players (SlimX) 16.41.30 # At some point there was really much hype in remote controls :) 16.50.08 # Build Server message: Build round completed after 716 seconds. 16.50.13 # Build Server message: Revision 0851310 result: All green 16.59.29 # braewoods: I can't get the non-LCD remote for €25 16.59.35 # I can* 16.59.54 # ah. don't you already have it? 17.00.48 # No, I only have the H100 remote control twice (black + grey) 17.01.11 # If it's useful for some tests, I can buy it 17.01.54 # H10: https://img2.leboncoin.fr/ad-large/d1eb40f71639e8382178acf1382ff38288d35302.jpg 17.02.03 # H300 https://images.fr.shopping.rakuten.com/photo/1413898938.jpg 17.02.13 # as you can see, the connector is a bit different 17.39.49 Quit S|h|a|w|n (Ping timeout: 264 seconds) 17.50.22 Quit cockroach (Quit: leaving) 18.11.42 # ah. 18.11.45 # lebellium: i thought so. 18.12.28 # lebellium: feel free if you want but I don't know how valuable it would be. the main hitch is how to detect the other remotes. 18.12.42 # the comments suggest they never found a way to detect them. 18.13.36 # speachy: I had some time to think about the m3k and in my opinion the best way to work with the current kernel/rootfs combination we have is to write a new `shutdown` binary that kills all processes, flushes writeback, unmounts everything, and then tell axp192 to cut power via the ioctl() call. 18.13.59 # This way rb does NOT have to mess with this junk 18.14.02 # yep 18.15.06 # heck, it can be combined into the bootloader, have the system shutdown scripts call it with an argument to trigger the ioctl. 18.15.21 # braewoods: actually I didn't really understand why we are talking about iriver remote controls. Is there a plan to change something in the code related to this topic ? 18.15.57 # lebellium: i was revisiting the H300 and H100 in the process of doing research for producing a new set of bootloaders. 18.16.11 # i was seeing what else I might want to do within the realm of reason. 18.16.30 # the H320 hasn't seen a new bootloader in 14 years. 18.16.37 # but many fixes have been done in master since 18.16.43 # not all of which i know 18.17.18 # it's looking like it would be unrealistic to add support for the H300 only remotes given their scarcity 18.17.42 # plus the notes left behind suggest they... 18.17.54 # have no known way to detect their difference 18.17.56 # s 18.18.23 # lebellium: i was asking mostly for research i guess 18.18.42 # does that mean that if I currently plug the non-LCD remote to the H300, it won't be recognized by Rockbox? 18.19.22 # supposedly. 18.19.32 # support was never finished if these notes are still current 18.20.22 # https://www.rockbox.org/wiki/IriverPort 18.20.27 # Done (h100 remote only so far) 18.20.31 # for the h300 side 18.21.13 # Ok got it. I like buying things to help for some tests but if no-one is going to dig into the remote detection, I won't waste €25 for a basic remote without LCD :) 18.22.16 # lebellium: https://www.rockbox.org/wiki/IriverH3XXHardwareComponents#A_40H300_41_Responses_from_iRiver_H300_remote_buttons_40got_from_Info_45_62Debug_45_62View_I_47O_Ports_41 18.23.34 # 3 Rockbox users having the rare H300 LCD remote! 18.23.42 # good old time 18.23.58 # but yea, the main stickler is remote detection 18.26.43 # looks like they already went quite far without solution 18.26.59 # so probably a waste of time in 2020 :/ 18.28.19 # not much point in researching something that is next to impossible to find 18.28.24 Quit pamaury (Ping timeout: 258 seconds) 18.30.25 # It looks like one can make the difference between the H100 and any H300 remote though. So maybe back to the time it would have been great to have a user setting allowing to select between LCD and non-LCD when a H300 remote is detected? 18.31.02 # i'm not sure honestly 18.31.10 # the code suggests it is already implemented 18.32.12 # lebellium: actually i guess you can do us a favor 18.32.21 # buy it and see it if works with the latest development builds 18.32.27 # that's the only reason though 18.32.36 # the code suggests it may work 18.32.53 # it was commited in october 2006 18.33.23 # firmware/target/coldfire/iriver/h300/button-h300.c 18.33.25 # this file 18.34.15 # lebellium: guess i'm trying to sort through all the old data to see what is still unresolvd 18.34.31 # in my quest to construct a TODO list for the bootloader 18.40.23 *** Saving seen data "./dancer.seen" 18.43.28 # indeed if I understand button-h300.c the 3 remote are handled 18.43.57 # lebellium: well without the hardware i can't be sure 18.44.18 # up to you but that's something that would be nice to know. 18.44.32 # if the non-lcd works the lcd one probably does as well 18.48.47 # hm 18.49.54 # ok bought. I'll let you know when I get it 18.50.49 # good night 18.58.21 Quit lebellium (Quit: Leaving) 19.22.45 Quit petur (Remote host closed the connection) 19.43.56 Join fs-bluebot [0] (~fs-bluebo@55d45ee3.access.ecotel.net) 19.44.06 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 19.45.45 Quit fs-bluebot_ (Ping timeout: 240 seconds) 19.47.22 Quit bluebrother^ (Ping timeout: 256 seconds) 19.51.59 # speachy: what is this WPS i keep reading about in rockbox stuff? 20.21.44 # <__builtin> "While Playing Screen" 20.22.05 # <__builtin> it's one of the primary themeable elements 20.30.54 # ah 20.40.24 *** Saving seen data "./dancer.seen" 21.41.39 # <_bilgus__> and the skin engine (parser) is a bitch 22.11.16 Quit MrZeus_ (Ping timeout: 272 seconds) 22.20.44 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 22.33.38 # I've have updated the patch to use usb-hiby.c and rocker_linux.c for M5. Now, if there's a way to make an updatable firmware as in fiio m3k, that would be great 22.34.04 # how do you create firmware file for fiio m3k or hiby based player? 22.34.56 # I check the firmware from m5, and it zip file of bunch of (maybe signed apk) zip files 22.35.31 # Stanley00: currently we have no idea how to do this 22.35.53 # oh, how do you flash the firmware to m3k then? 22.37.17 # FiiO borrowed the OTA stuff from the ingenic BSP instead of implementing their own (saner) versions like hiby did (.upt ISO image with simple md5 hash inside) 22.38.12 # The Ingenic BSP was originally designed for iot (spy) speakers, so it does make some sense to have signed updates. 22.39.02 # Currently there are two ways to approach this on an M3K 22.40.06 # First, you can use the xvortex image (which is signed) to acquire a root shell, and then try to update the system UBI image (or remount it as rw and make your changes on the fly). I have not tried this so I cannot guarantee this will work. 22.40.26 *** Saving seen data "./dancer.seen" 22.46.50 # yes, and what is the second way then? 22.56.02 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) 23.02.07 # currently, I already have root shell on m5, but I just think this is not so user friendly way to install rockbox 23.06.46 Quit bonfire (Quit: Leaving) 23.13.21 # Sorry I was distracted by something else 23.13.38 # The 2nd way is to use the ingenic usb cloner to flash the ubi partition. 23.14.22 # This bypasses the recovery (which is where the signature check happens) 23.15.49 # We do not have rights/permission to distribute this cloner tool 23.16.52 # But if you have it, all you need to do is to dump your device's flash partitions. 23.16.55 # I tried this cloner tool, but it seems it will need some config specific to the board, right? 23.17.11 # Do you have all of the flash dumped? 23.17.17 # *partitions 23.17.43 # I have some kind of mtd layout from dmesg message, not sure if it is the right one? 23.17.53 # That's all you need. 23.19.14 # also, do I need special boot mode for the m5? I'm just feeling that plug it in usb port doesn't sound right 23.20.00 # You need to power off the device, hold down a key and insert the USB cable 23.20.30 # If the device doesn't start and your PC finds a new USB device, then it's good 23.24.26 # hmm... for my m5, there's only 3 buttons, and one of them already used for offline update, I will test this later today, thanks for the info 23.25.29 # use the other one then 23.25.45 # it's not power as that one is attached to the PMU 23.28.54 # this left out just one button remain, but I need at least 12 hours more so I can comeback to my dev pc to try this 23.39.34 # Build Server message: New build round started. Revision dfae5d8, 292 builds, 9 clients. 23.43.12 # if you're on windows, you can use zadig to install the libusb driver 23.43.21 # the cloner driver is just libusb 23.49.02 # I'm using linux, so I hope it would be easier 23.49.03 Quit TheSeven (Ping timeout: 244 seconds) 23.49.34 # on linux it needs sudo to set up udev rules 23.49.44 # I recommend using a vm for this 23.49.46 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 23.52.31 # oh, sudo and closed source tools sounds to sketch... I will go with vm then 23.53.29 # yup 23.57.29 # Build Server message: Build round completed after 1076 seconds. 23.57.44 # Build Server message: Revision dfae5d8 result: All green 23.57.51 # efqw: ah, one more thing, did the poweroff issue with m3k fixed? 23.58.10 # I would love to fix those issue with m5 too