--- Log for 30.09.120  Server: wilhelm.freenode.net  Channel: #rockbox
--- Nick: logbot_  Version: Dancer V4.16  Started: 2 days and 19 hours ago

00.04.22 Quit    akaWolf (Ping timeout: 246 seconds)
00.29.40 Join    akaWolf [0] (~akaWolf@akawolf.org)
00.31.01 ***     Saving seen data "./dancer.seen"
01.00.55 Quit    massiveH (Quit: Leaving)
01.27.44 Join    ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
01.28.56 Quit    ac_laptop (Ping timeout: 256 seconds)
01.31.47 Quit    ZincAlloy (Ping timeout: 240 seconds)
01.32.45 #       <braewoods> hm.
01.38.02 #       <braewoods> speachy: what does it take to register for the wiki? I was told registration is disabled.
01.38.24 #       <braewoods> I was trying to correct some outdated links...
01.40.46 Join    ZincAlloy [0] (~Adium@2a02:8108:943f:d824:6de1:ea53:aa02:1121)
01.45.51 Quit    ZincAlloy (Ping timeout: 272 seconds)
02.19.46 Quit    efqw (Read error: Connection reset by peer)
02.20.00 Join    efqw [0] (uid412670@gateway/web/irccloud.com/x-pzlbsqthyhjvsueh)
02.29.15 Quit    amiconn (Quit: No Ping reply in 64 seconds.)
02.29.27 Join    amiconn [0] (jens@rockbox/developer/amiconn)
02.31.05 ***     Saving seen data "./dancer.seen"
02.46.30 Join    petur [0] (~petur@rockbox/developer/petur)
03.03.32 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
03.17.10 Quit    michaelni (Ping timeout: 272 seconds)
03.18.13 Join    michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at)
04.31.09 ***     Saving seen data "./dancer.seen"
06.15.47 Quit    pamaury (Ping timeout: 240 seconds)
06.16.05 Join    Telehubis [0] (594cb4e3@89-76-180-227.dynamic.chello.pl)
06.16.40 #       <Telehubis> Hi, any other than Paypal donations possibilities?
06.16.59 Quit    Telehubis (Remote host closed the connection)
06.19.13 #       <braewoods> Ow. We got hit by another hit and run greeter.
06.19.34 #       <braewoods> I mean... 20 seconds?
06.19.37 #       <braewoods> that's not long to wait
06.20.42 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
06.31.11 ***     Saving seen data "./dancer.seen"
06.42.32 #       <speachy> braewoods: PM me your desired email and full name, I'll create the account.
06.42.43 #       <speachy> bots are heavily slamming the account creation page to this day.
06.45.37 #       <speachy> Telehubis, we have nothing else set up.  What did you have in mind?
08.15.11 Join    Telehubis [0] (594cb4e3@89-76-180-227.dynamic.chello.pl)
08.15.49 #       <Telehubis> Ok then. Hi :- )
08.17.03 #       <Telehubis> as for paypal I was using it but they have a fairly high additional fee (which is indirectly added) that is why I though maybe something else...?
08.20.01 #       <speachy> if there's one thing I've learned, the money people will _alway_ find a way to take their cut
08.21.08 #       <Telehubis> well then they are not charity
08.21.47 #       <speachy> are you in the US?
08.21.51 #       <Telehubis> nope
08.21.56 #       <Telehubis> Europe
08.22.20 #       <speachy> since international borders are involved I think there are no non-sucky options.
08.23.35 #       <Telehubis> ok, paypal it is
08.31.12 ***     No seen item changed, no save performed.
08.36.24 Quit    Telehubis (Remote host closed the connection)
10.25.53 #       <genevino> ok filling a 256gb sd card is a bit harder than i thought
10.31.13 ***     Saving seen data "./dancer.seen"
11.05.43 Quit    Huntereb (Ping timeout: 260 seconds)
11.28.30 #       <_bilgus__> INDEED
11.30.21 #       <_bilgus__> speachy, not sure I have any reason to want to be involved in that, not a form factor I'd ever want in my pocket
11.31.10 #       <speachy> that's what pine64 came back with; my emails are saying that's not what "we" want
11.31.32 #       <speachy> (where "we" is really "I" so far..)
11.34.23 #       <_bilgus__> the touch screen Is where it all really goes to shit i'd make a way to shove a player in my pocket but I break touch screens I count lifetimes in weeks
11.34.53 #       <efqw> what I really want is pretty much an iPod Classic clone, with USB-C and a decent IPS LCD
11.35.36 Join    johnb2 [0] (~johnb2@p5b3af332.dip0.t-ipconnect.de)
11.35.46 #       <efqw> imo some of those linux based sony players are quite nice but the proprietary connector is a total deal breaker for me
11.36.26 #       <efqw> I have no interest in anything that doesn't use MicroUSB or USB-C.
11.37.15 Join    MrZeus_ [0] (~MrZeus@2a02:c7f:70d0:6a00:9d0d:8a12:6a9b:2ed)
11.37.55 #       <_bilgus__> I feel like USB-c is pretty inevitable at this point I mean unless you like fucking your customers by making them buy overpriced custom dongles
11.39.02 #       <_bilgus__> well I guess thats possible even with USB-C if they really want headphones
11.39.28 Quit    akaWolf (Ping timeout: 246 seconds)
11.42.30 #       <efqw> speachy: please also clone the m3k kernel source from github just in case fiio decides to remove it in the future (albeit highly unlikely)
11.43.19 Join    lonoxmont [0] (~lonoxmont@024-180-058-254.res.spectrum.com)
12.07.04 Join    ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
12.11.23 Quit    ZincAlloy (Ping timeout: 240 seconds)
12.12.37 Quit    petur (Quit: Connection reset by beer)
12.19.59 Join    ZincAlloy [0] (~Adium@2a02:8108:943f:d824:5049:3abb:4a19:2040)
12.21.34 Join    sakax [0] (~r0b0t@unaffiliated/r0b0t)
12.24.31 Quit    ZincAlloy (Ping timeout: 244 seconds)
12.30.33 Join    akaWolf [0] (~akaWolf@188.243.183.39)
12.31.16 ***     Saving seen data "./dancer.seen"
12.33.40 #       <fs-bluebot> Build Server message: New build round started. Revision 1c0648c, 282 builds, 9 clients.
12.35.57 Join    ZincAlloy [0] (~Adium@2a02:8108:943f:d824:3065:daf3:1401:3dd7)
12.50.34 #       <fs-bluebot> Build Server message: Build round completed after 1015 seconds.
12.50.39 #       <fs-bluebot> Build Server message: Revision 1c0648c result: All green
12.51.22 Join    kugel [0] (~kugel@ip5b40d8e6.dynamic.kabel-deutschland.de)
12.51.22 Quit    kugel (Changing host)
12.51.22 Join    kugel [0] (~kugel@rockbox/developer/kugel)
12.52.20 Quit    kugel_ (Ping timeout: 256 seconds)
13.03.47 Quit    johnb2 (Ping timeout: 240 seconds)
13.07.27 Quit    kugel (Ping timeout: 240 seconds)
13.10.36 #       <genevino> _bilgus__: unfortunately, a lot of manufacturers still use micro-usb jacks.
13.11.27 #       <_bilgus__> still an open and standard connector..
13.14.47 #       <genevino> true, but one that breaks every now and then...
13.15.37 #       <genevino> usb-c is like MUCH more robust.
13.15.43 Quit    pamaury (Ping timeout: 246 seconds)
13.18.43 #       <lonoxmont> also usb-c isnt 4-dimensional
13.18.51 #       <lonoxmont> >try to insert cable
13.18.56 #       <lonoxmont> >doesnt fit, flip over
13.19.02 #       <lonoxmont> >still doesnt fit, flip over
13.19.04 #       <lonoxmont> >fits
13.19.09 #       <lonoxmont> pikachu.jpg
13.19.36 #       <genevino> hehe
13.22.13 Join    tor_ [0] (~tor@185.9.19.107)
13.41.01 #       <_bilgus__> if robust was the key criteria a well supported usb mini was fine
13.50.12 #       <speachy> what's the least robust are the original B connectors, which wear the socket rather than the cable.  wtf.
13.59.00 #       <lonoxmont> i think i like the micro over the mini
13.59.08 #       <lonoxmont> seems to stay in more tightly
13.59.16 #       <lonoxmont> at least the ones ive used
14.01.24 #       <braewoods> speachy: the usb type primarily used in printers?
14.01.49 #       <speachy> printers do seem to be the last holdout of B sockets, for reasons that I do not comprehend
14.03.01 #       <speachy> 1500 insertion cycles, and it's the socket that wears out.  mini-USB upped that to 5K, and micro-usb over 10K.
14.03.06 #       <genevino> so from the library view, i can just long-tap the middle button on my agptek rocker and "insert into current playlist" or even "insert into current playlist (shuffled)" which is exactly what i need to play all songs on my device shuffled. but where can i a) view this "current playlist"? also how the hell do i even clear the current playlist?
14.03.36 #       <genevino> oh, the latter question obviously was b)
14.03.41 #       <speachy> context menu while playing.
14.03.58 #       <speachy> I forget how to bring that up on the rocker though
14.04.39 #       <genevino> well when long-tapping the middle button, i get the database context menu, which is not what you mean, or?
14.05.01 Quit    tor_ (Quit: tor_)
14.05.21 #       <braewoods> speachy: i was reading a more in-depth analysis of IDE UDMA modes... apparently the higher speed ones aren't even an option due to low # of pins in most ATA based players
14.05.47 #       <braewoods> they need the full 80 pins to use higher modes or so but then how does CF do UDMA 7 then?
14.05.48 #       <speachy> braewoods: it's not the pin count; PATA drives only had 40 connectors, after all.
14.06.00 #       <lonoxmont> speachy: some other stuff uses the B sockets, not sure if they can carry more current or if its jsut cheap
14.06.02 #       <braewoods> Ah.
14.06.07 #       <speachy> but the _cables_ had 80 wires, pairing each wire with a ground.
14.06.15 #       <braewoods> Oh.
14.06.22 #       <lonoxmont> i have some HAM radio SDR stuff thats powered off of a b socket
14.06.29 #       <braewoods> sounds like overkill...
14.06.35 #       <braewoods> why do you need that many separate grounds?
14.06.36 #       <speachy> so a direct-attached drive should JustWork(tm) in "80-wire" mode.
14.06.42 #       <genevino> speachy: so do you have any further pointer how to simply clear the current playlist?
14.06.53 #       <speachy> signal integrity; minimizing crosstalk between the data lines
14.07.02 #       <lonoxmont> braewoods: because parallel
14.07.12 #       <genevino> speachy: going to "playlist catalogue" just tells me that /Playlists doesn't exist btw.
14.07.13 #       <lonoxmont> also what speachy says
14.07.38 #       <lonoxmont> every other wire in the cable is a ground
14.07.43 #       <braewoods> I see.
14.07.59 #       <lonoxmont> data ground data ground
14.08.18 #       <braewoods> and i'm guessing sata took over due to the limitations of PATA
14.08.21 #       <lonoxmont> yep
14.08.36 #       <lonoxmont> turns out its easier/cheaper to use serial instead
14.08.38 #       <braewoods> UDMA 7 being the last speed mode ever added
14.08.59 #       <lonoxmont> then you have less wires to worry about for thigns like timing skew and so forth
14.09.33 #       <braewoods> though we still see parallel interfaces
14.09.42 #       <braewoods> e.g., old school character lcds
14.10.06 #       <lonoxmont> yeah
14.10.21 #       <lonoxmont> but even then afaik they are usually less wires than the old pata stuff
14.10.53 #       <braewoods> how does serial work anyway? does it use shift registers or something to transfer bits?
14.11.02 #       <lonoxmont> then again nowadays its usually those flexible plastic ribbon cables
14.11.07 #       <lonoxmont> i think so yeah
14.11.08 #       <braewoods> i assumed due to low pin count it has to pulse the pins it does have
14.11.12 #       <lonoxmont> just shift registeres for days
14.12.10 #       <speachy> genevino: I don't think there is an explicit "clear playlist" since you can replace the runing playlist with something else at any time
14.12.36 #       <speachy> granted you can manually remove each item one by one
14.13.19 #       <lonoxmont> easy/lazy workaround would be replace it with a single song then delete that song
14.13.20 #       <lonoxmont> :B
14.13.28 #       <speachy> or ... just stop playing.  :)
14.13.32 #       <lonoxmont> that too
14.14.54 Quit    craftyguy (Quit: WeeChat 2.9)
14.18.12 #       <genevino> hmmm, it keeps complaining that /mnt/sd_0/Playlists doesn't exist when i try to select the playlist catalogue from the main menu. o.O
14.18.34 #       <speachy> I take it you have that directory?
14.18.53 #       <speachy> (ie "Playlists" in the top-level of the SD card?)
14.19.02 #       <genevino> i tried creating it but that didn't change something, yes.
14.20.01 #       <braewoods> genevino: did you try regenerating the database under settings?
14.20.14 #       <braewoods> might be related or not
14.20.17 #       <genevino> braewoods: not yet, should i?
14.20.31 #       <braewoods> you normally need a database of your music to add to playlists
14.20.42 #       <braewoods> though i guess it does support manual insertions by browsing
14.21.08 #       <genevino> ah wait a second, inserting means actually "clear, then insert", as apposed to "appending"
14.21.14 #       <genevino> oookay
14.21.22 #       <genevino> well that solves all the problems basically
14.25.00 #       <genevino> so yea lonoxmont was right, you could just "insert a single song"
14.25.19 #       <genevino> but i still don't know what's up with that /Playlists thing
14.25.48 #       <speachy> the error is odd; it's suppsoed to create the directory if it doesn't exist.
14.27.03 #       <braewoods> speachy: i get an error about updating databases when i disconnect RB from usb. any idea why that happens?
14.27.10 #       <braewoods> seems to happen on every RB thing i've ever owned
14.27.39 #       <braewoods> usually before I've installed anything to play
14.27.55 #       <speachy> I think that'/mnt/sd_0/' shouldn't be there though.
14.28.15 #       <braewoods> too bad a shell can't be opened
14.28.30 #       <braewoods> wouldn't that be nice though? shell over usb like adb has.
14.28.40 #       <speachy> "patches welcome"  :D
14.28.40 #       <braewoods> for Linux targets
14.28.51 #       <braewoods> you could then directly inspect what's going on.
14.28.52 #       <speachy> well, we _do_ have adb on the rocker
14.29.10 #       <speachy> including strace
14.29.13 #       <braewoods> i see.
14.31.18 ***     Saving seen data "./dancer.seen"
14.31.44 #       <genevino> well at least none of the issues i discovered on the rocker are actual dealbreakers that make using the device on a daily basis impossible.
14.31.55 #       <genevino> so there's that. ;)
14.33.48 #       <braewoods> i've been working with an iriver h120
14.34.13 #       <braewoods> it's possible to replace the OF entirely and install RB entirely to ROM save for its extras that must still be loaded from disk
14.34.31 #       <braewoods> since the device has 2MB of EEPROM
14.35.12 #       <braewoods> but you need to do some hacks to get it to work since this isn't the default mode of operation for RB
14.35.22 #       <braewoods> like flashing a newer bootloader
14.35.31 #       <speachy> ok, the playlist catalog thing is broken on hosted targets and simulator builds.
14.36.05 #       <braewoods> speachy: how many native targets are there?
14.36.07 #       <braewoods> err
14.36.09 #       <braewoods> hosted
14.36.52 #       <speachy> samxung yp-r0/r1, xduoo x3ii/x20, rocker, ibasso dx50/90, and most of the sonys.
14.37.54 #       <braewoods> ah... so pretty much all the "modern" ones
14.38.34 #       <braewoods> on the bright side, at least the system call ABI for Linux is totally exposed so you can write ASM if you have to...
14.38.42 #       <braewoods> you can bypass libc and such.
14.39.13 #       <braewoods> libc is mainly there for portability between architectures
14.41.30 #       <speachy> yeah, but why write our own libc when we don't need to?  :)
14.41.43 #       <speachy> this is a case of GIGO
14.43.52 #       <braewoods> so you link to their libc?
14.43.58 #       <braewoods> whatever they use since linux can use any
14.44.26 #       <braewoods> not sure how you would though without the libc headers for that system
14.44.40 #       <braewoods> it would probably be easier to statically link in your own choice of libc
14.45.19 #       <bluebrother> speachy: re that rocker install the other day: so Rockbox Utility should have a hint for the user to perform an update from the OF? I.e. the rocker needs to get added to BootloaderInstallHelper::postinstallHints()?
14.45.51 #       <speachy> bluebrother: yeah, that's a good idea.  I could have sworn I did something like that already though
14.46.02 #       <speachy> the rocker, x3, x3ii, and x20 all need that same blurb
14.46.25 #       <bluebrother> that existing part for h100 should fit, right?
14.48.05 Join    tor_ [0] (~tor@185.9.19.107)
14.55.11 #       <speachy> okay, g#2771 will fix the playlist (and recording) paths on hosted targets.
14.56.06 #       <speachy> oh, simulator too
14.56.22 #       <braewoods> speachy: it even simulates the bugs!
14.56.23 #       <braewoods> lol
14.56.50 #       <speachy> braewoods: that's actually a pretty important quality
14.56.57 #       <fs-bluebot> Build Server message: New build round started. Revision ff408fd, 282 builds, 9 clients.
15.09.21 #       <genevino> speachy: oh nice!
15.11.10 Join    kugel [0] (~kugel@ip5b40d8e6.dynamic.kabel-deutschland.de)
15.11.10 Quit    kugel (Changing host)
15.11.10 Join    kugel [0] (~kugel@rockbox/developer/kugel)
15.11.48 #       <fs-bluebot> Build Server message: Build round completed after 892 seconds.
15.11.50 #       <fs-bluebot> Build Server message: Revision ff408fd result: All green
15.13.25 #       <fs-bluebot> Build Server message: New build round started. Revision 728299e, 282 builds, 9 clients.
15.19.37 #       <braewoods> speachy: apparently there's been bootloader fixes in "SVN" that isn't in the latest build for h100 series
15.19.49 #       <braewoods> from 10 years ago...
15.19.55 #       <braewoods> why no new bootloaders?
15.19.57 #       <braewoods> I'm puzzled.
15.20.22 #       <speachy> ...nobody's bothered to test it out properly and upload it?
15.20.31 #       <braewoods> I see.
15.21.08 #       <braewoods> how can I build it myself?
15.21.21 #       <braewoods> or is that not advised?
15.22.19 #       <braewoods> either way... guess it's time to get a wiki account first
15.27.26 #       <bluebrother> braewoods: the problem with the bootloader on h100 is that if the flash goes wrong you need special hardware to revive the player. That only left this work to a few people back then. Unless you're feeling confident enough to (not) brick your player :)
15.27.47 #       <braewoods> i see.
15.29.37 #       <fs-bluebot> Build Server message: Build round completed after 972 seconds.
15.29.41 #       <fs-bluebot> Build Server message: Revision 728299e result: All green
15.32.45 #       <lonoxmont> bluebrother: need a jtag setup to unbrick the player i take it?
15.33.08 #       <lonoxmont> or is it something more janky?
15.35.41 #       <bluebrother> jtag afaik.
15.36.09 #       <lonoxmont> thats not as janky as it could be, at least its ostensibly an industry standard
15.36.20 #       <lonoxmont> but you are right that most people dont have jtag hardware lying about
15.36.35 #       <bluebrother> https://www.rockbox.org/wiki/IriverBDM
15.38.05 #       <bluebrother> not sure what you'd need to do to fix a failed flash. Probably loading rockbox to RAM, executing it and using iriver_flash. Never did jtag stuff on that player.
15.38.23 #       <bluebrother> another problem with the jtag is that you have to open the player and solder around :)
15.38.29 #       <lonoxmont> true
15.39.02 #       <braewoods> bluebrother: so how would one get or build a newer build for the bootloader?
15.39.12 #       <lonoxmont> very carefully
15.39.14 #       <lonoxmont> ( ≖‿≖)
15.39.14 #       <braewoods> it's probably time someone released an updated one that has more of the fixes
15.39.44 #       <lonoxmont> what fixes could the bootloader even have?
15.39.48 #       <speachy> we shoudl also probably do anoher ipod bootloader build with the iflash fixes
15.40.00 #       <speachy> to answer your question indirectly..
15.40.02 #       <lonoxmont> like as long as it loads the os im not sure what else there is to fix
15.40.22 #       <lonoxmont> unless it hangs around and acts like a bios or something and handles low level storage calls and whatnot
15.42.27 #       <bluebrother> there's a v7pre4 bootloader in the wiki. That's the one I'm using (with Rockbox in flash)
15.43.57 #       <bluebrother> though that's also 10+ years old :)
15.44.10 #       <bluebrother> and yeah, for h100 the bootloader isn't doing much afaik.
15.45.19 #       <braewoods> bluebrother: there's fixes with CF mod related to usb mode
15.45.33 #       <braewoods> fixed in SVN but not 7pre4
15.45.40 #       <bluebrother> what's svn? ;-)
15.45.52 #       <braewoods> basically means "fixed in git but not released"
15.46.12 #       <bluebrother> ok. I wouldn't mind an updated bootloader. Though someone has to do it.
15.46.21 #       <braewoods> indeed.
15.46.34 #       <braewoods> which is why i was trying to find out how to build an updated bootloader only
15.46.44 #       * bluebrother wants to update the bootloader on his clip+ for sd booting
15.46.55 #       <bluebrother> that hasn't been released either, right? As well as e200?
15.47.13 #       <braewoods> sansa clip+, isn't that stable?
15.47.35 #       <braewoods> yep
15.48.40 #       <braewoods> https://www.rockbox.org/wiki/CFModGuide
15.48.45 #       <braewoods> Note: On iRiver H1x0 targets, if a CFMod has been performed, returning from USB disk mode is not fully supported from the bootloader. Disk mode works to and from Rockbox (after RB has booted) but to Rockbox from bootloader USB disk mode. In other words, if a user plugs in the USB cable with the player turned off, then boots the player they will get into a working USB disk mode but will be unable
15.48.47 #       <braewoods> to get out of this mode without seeing the dreaded "ATA error: -80". A reset is then required.
15.49.13 #       <braewoods> http://www.rockbox.org/tracker/task/9642
15.49.16 #       <braewoods> is the linked issue
15.49.30 #       <braewoods> says svn bootloader reported to work
15.49.38 #       <braewoods> but that's from 2010 which is far newer than 7pre4
15.49.42 #       <braewoods> so
15.49.47 #       <bluebrother> the clip+ is stable, but iirc support to boot from sd has been added some time ago but no new release of the bootloader been done.
15.49.49 #       <braewoods> it probably would require an updated bootloader
15.50.06 #       <braewoods> indeed.
15.51.02 #       <braewoods> " Be careful! Do NOT attempt to build your own bootloader from SVN unless you know for sure what you're doing. "
15.51.10 #       <braewoods> So... who does?
15.51.18 Join    lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
15.51.44 #       <braewoods> i've been able to build uboot before and flash that but...
15.51.54 #       <braewoods> that was well documented
15.52.40 #       <bluebrother> the problem simply is that while the build server ensures the bootloader builds there's no way to tell if it's working. And as said before, if you flash a bad bootloader you'll brick your player.
15.52.52 #       <speachy> ../tools/configure --target=iriverh100 --type=b && make
15.52.59 #       * bluebrother ran into this with flashing coreboot to a laptop
15.53.08 #       <braewoods> indeed.
15.53.16 #       <braewoods> but there's only one way to find out i suppose
15.53.19 #       <speachy> and you um, break it, you're stuck with it.   :)
15.53.42 #       <bluebrother> braewoods: get a bdm setup up and running? ;-)
15.55.05 #       <braewoods> bdm?
15.55.45 #       <braewoods> speachy: thanks. any recommended build host?
15.55.47 #       <braewoods> ubuntu LTS or so?
15.56.10 #       <braewoods> or would it be better to try the build service's bootloader?
15.56.16 #       <genevino> speachy: since i'm just looking at your latest commit in git: i see both /sdcard and /mnt/sd_0 somewhere in the code, is /mnt/sd_0 just "wrong"?
15.57.24 #       <bluebrother> bdm is the jtag of the coldfire chip
15.57.39 #       <bluebrother> so to say
15.59.39 #       <braewoods> how hard is jtag to setup?
15.59.49 #       <braewoods> i've heard you usually need to...
15.59.52 #       <bluebrother> the adapter mentioned on the wiki seems to connect to the parallel port. That could become hard these days.
15.59.56 #       <braewoods> solder pins
16.00.14 #       <braewoods> bluebrother: adapter?
16.00.44 #       <braewoods> bluebrother: which url?
16.00.53 #       <bluebrother> typically: take the adapter and plug it in. If it's not development hardware you'd need to solder the pins (assuming you know about those and can access them)
16.01.20 #       <bluebrother> and of course jtag functionality could be locked. But back in those days you still had a chance to get to those things :)
16.01.36 #       <bluebrother> the IriverBDM wiki page I linked earlier
16.03.14 #       <braewoods> the alternative would be desoldering the EEPROM and direct reprogramming?
16.05.57 Join    johnb5 [0] (~johnb2@p5b3af332.dip0.t-ipconnect.de)
16.06.09 #       <speachy> you could use a clip-on connector on the eeprom
16.06.45 #       <braewoods> interesting.
16.06.46 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
16.06.59 #       <braewoods> that was how libreboot suggested first installs
16.07.03 #       <johnb5> bluebrother : I am pretty confident the SD bootloader for clip+ is already active.
16.07.09 #       <speachy> but you'd presumably need a full eeprom dump from a working unit.
16.07.27 #       <johnb5> It's not for sansa e200.
16.07.28 #       <bluebrother> possibly. If you get it desoldered. Looking at the pictures on the wiki it seems that one is bga
16.07.35 #       <braewoods> Oh.
16.07.39 #       <bluebrother> johnb5: good to know, I'll give that a try
16.07.52 #       <speachy> there's a AT24 I2C-attached eeprom on U23
16.08.58 #       <bluebrother> https://www.rockbox.org/wiki/IriverHardwareComponents -- scroll to 39VF160
16.09.12 #       <bluebrother> I _think_ that's the one.
16.09.22 #       <genevino> so can i read somewhere how the exact process i need to walk through to build some custom firmware image from the git repository checkout will look like?
16.09.48 #       <braewoods> bluebrother: you're right. no legs or otherwise to grab onto.
16.09.59 #       <braewoods> so JTAG is probably only option
16.10.02 #       <genevino> oh, looks like it's all in the README
16.10.04 #       <speachy> ah, ok, the tiny one's not actually used int he boot
16.10.54 #       <bluebrother> afaik the EEPROM isn't used at all by Rockbox but only used by the OF.
16.11.17 #       <braewoods> it is if you load the firmware to ram
16.11.21 #       <braewoods> or rom
16.11.21 #       <bluebrother> I also have no idea about internal flash (and its use) of the cpu itself.
16.12.08 #       <bluebrother> well, if you have a working jtag you should be able to load Rockbox to RAM and then execute it. And then it should be able to use iriver_flash.
16.13.08 #       <braewoods> Seeing what it would even mount to first
16.15.17 #       <braewoods> i see one unpopulated 5 pin thing
16.15.28 #       <braewoods> probably serial
16.15.33 #       <braewoods> but that's not jtag
16.16.09 #       <bluebrother> serial. Check the pictures in the wiki.
16.16.31 #       <speachy> BTW, there are a ton of usb-attached jtag adapters to be had.  openocd supports quite a few
16.16.33 #       <braewoods> bluebrother: i was.
16.16.36 #       <bluebrother> start with IriverPort, check the subpages.
16.16.49 #       <braewoods> just not seeing where you'd attach the BDM
16.17.04 #       <braewoods> Oh.
16.19.09 #       <braewoods> interesting.
16.19.20 #       <braewoods> iriver_flash has hardcoded checksums so
16.19.27 #       <braewoods> you'd need to mod it to add a new bootloader
16.19.59 #       <braewoods> go figure
16.20.14 #       <braewoods> so it would need a custom build regardless to develop a new bootloader release
16.22.50 #       <bluebrother> speachy: the only problem is that those usually target jtag for arm. For CF we'd need bdm. AFAIU that's different to those cheap jtag adapters.
16.24.41 #       <braewoods> bluebrother: would you suggest building from latest development or latest stable if i was trying to build a new bootloader?
16.24.51 #       <braewoods> either is far newer than current one
16.25.18 #       <braewoods> i have a server I can use for this... ECC RAM and all.
16.26.09 #       <bluebrother> building the bootloader is not a problem. That's rather quick on even non-modern hardware.
16.26.39 #       <braewoods> ok.
16.26.57 #       <braewoods> i just thought for something this sensitive probably should build with Debian or something.
16.27.04 #       <braewoods> and use a proper server that I have
16.27.25 #       <bluebrother> took 10 seconds on my laptop :P
16.27.28 #       <braewoods> i'll need to build a custom RB in either case
16.27.37 #       <braewoods> to patch the flasher
16.27.40 #       <speachy> there's nothing special about compiling the bootloader versus any other rockbox code
16.28.22 #       <bluebrother> https://www.rockbox.org/wiki/pub/Main/DataSheets/COLDFIRE2UM.pdf -- it only talks about bdm, not jtag. So I guess we need bdm. And according to wikipedia that's a 1 wire interface, so not standard jtag.
16.30.02 #       <bluebrother> though it shows the typical clock, di, do lines.
16.31.19 ***     Saving seen data "./dancer.seen"
16.31.57 #       <bluebrother> so it might be possible to get that working with those cheap wigglers.
16.32.13 #       * bluebrother wonders why wikipedia calls it a 1 wire interface then
16.32.40 #       <bluebrother> anyway, off for today. And I won't have the time to look into that, even though it's kinda interesting :)
16.34.17 Quit    sakax (Remote host closed the connection)
16.34.17 #       <speachy> there are patches for bdm and openocd, but it doesn't look like they ever landed.
16.35.45 #       <braewoods> speachy: i guess i'll try to get a cheap throwaway h120 and experiment from there.
16.35.55 #       <braewoods> i would like to try it.
16.36.20 #       <braewoods> an updated bootloader would be nice.
16.36.28 Quit    johnb5 (Quit: Nettalk6 - www.ntalk.de)
16.39.25 #       <braewoods> speachy: would you build from master or stable?
16.39.33 #       <braewoods> not sure myself
16.39.43 #       <braewoods> since i don't know what the existing ones were compiled form
16.41.03 #       <speachy> master is where I'd start, because if it doesn't work, at least you're at a point worth debugging.
16.42.15 #       <speachy> there is very little "pure bootloader" code in the tree; it's really cut-down rockbox binary that still relies on the common code/drivers/etc.
16.43.45 #       <speachy> (obviously cutting out everyhting that's not essential in the bootup..)
16.44.47 Quit    tor_ (Ping timeout: 240 seconds)
16.57.35 #       <braewoods> ok.
17.24.54 Quit    tchan (Quit: WeeChat 2.8)
17.45.20 Join    tchan [0] (~tchan@c-98-220-238-152.hsd1.il.comcast.net)
17.45.20 Quit    tchan (Changing host)
17.45.20 Join    tchan [0] (~tchan@lunar-linux/developer/tchan)
17.54.07 Quit    pamaury (Ping timeout: 240 seconds)
17.57.04 Join    ac_laptop [0] (~ac_laptop@186.2.247.129)
17.58.49 Quit    lebellium (Quit: Leaving)
18.08.39 #       <speachy> one of the changes in the m3k dump is enabling >96KHz audio and a kinda broken implementation of automatic freq selection.
18.10.45 #       <speachy> I've been working on cleaning up that part.. but most targets seem to #define SAMPR_CAP_ALL which clearly is wrong, as that incorrectly enables 96KHz, and possibly even 48KHz.
18.31.21 ***     Saving seen data "./dancer.seen"
18.35.22 Quit    ZincAlloy (Quit: Leaving.)
18.42.13 #       <genevino> currently trying to find out how to build a custom firmware image - can i find a ./tools/configure somewhere that someone used to successfully build an image for the agptek rocker?
19.01.26 #       <speachy> what's committed is what's used to build it.
19.01.43 #       <speachy> if it's failing, the error will be informative.
19.05.58 #       <genevino> allright, thank you.
19.09.26 Join    kevin__ [0] (~kevin@2601:648:8681:4d10::a347)
19.11.18 #       <kevin__> i got a used clip zip. it starts up okay, but it's never recognized as a usb device on windows or linux. Tried all the obvious stuff other than opening it up. now, plugging it into usb causes a shutdown into bootloop.
19.12.01 #       <kevin__> it charges on usb, but can't seem to connect to any computer without borking itself
19.13.42 #       <braewoods> kevin__: anything weird like buttons behaving strangely? i had a philips gogear hdd1630 that i got used that had a stuck power button. had to open it to repair the issue.
19.15.15 #       <kevin__> buttons all seem to work, music plays fine etc. it reboots and gets stuck on the flower screen whenever i plug it into a comp
19.15.49 #       <kevin__> at this point i'm suspecting a faulty microusb
19.15.50 #       <kevin__> port
19.16.30 #       <kevin__> i cant copy stuff to flash over a new firmware... :(. if only i could install firmware from microsd.
19.19.38 #       <kevin__> hmmm, so if i plug it into my sleeping laptop, it charges. and only once i open the laptop, it reboots. it's some issue with the mounting? idk
19.20.37 #       <braewoods> kevin__: did you try seeing if it boots while disconnected?
19.21.21 #       <speachy> any kernel messages on the linux side before it reboots?
19.24.32 #       <braewoods> yes that would also be helpful
19.24.43 #       <braewoods> clear your kernel ring buffer and then see what it spits out
19.24.53 #       <braewoods> dmesg -C
19.24.55 #       <braewoods> as root
19.27.18 #       <kevin__> it's not normally in a bootloop. it only bootloop once its usb is plugged in
19.27.23 #       <kevin__> [Wed Sep 30 15:05:06 2020] usb usb1-port4: attempt power cycle
19.27.24 #       <kevin__> [Wed Sep 30 15:05:07 2020] usb 1-4: new high-speed USB device number 17 using xhci_hcd
19.27.24 #       <kevin__> [Wed Sep 30 15:05:07 2020] usb 1-4: Device not responding to setup address.
19.27.24 DBUG    Enqueued KICK kevin__
19.27.24 #       <kevin__> [Wed Sep 30 15:05:07 2020] usb 1-4: Device not responding to setup address.
19.27.26 #       <kevin__> [Wed Sep 30 15:05:07 2020] usb 1-4: device not accepting address 17, error -71
19.27.29 #       <kevin__> [Wed Sep 30 15:05:07 2020] usb 1-4: new high-speed USB device number 18 using xhci_hcd
19.27.34 #       <kevin__> [Wed Sep 30 15:05:07 2020] usb 1-4: Device not responding to setup address.
19.27.37 #       <kevin__> [Wed Sep 30 15:05:08 2020] usb 1-4: Device not responding to setup address.
19.27.40 #       <kevin__> [Wed Sep 30 15:05:08 2020] usb 1-4: device not accepting address 18, error -71
19.27.43 #       <kevin__> [Wed Sep 30 15:05:08 2020] usb usb1-port4: unable to enumerate USB device
19.27.46 #       <kevin__> [Wed Sep 30 16:17:56 2020] usb 1-9: reset full-speed USB device number 4 using xhci_hcd
19.27.49 #       <kevin__> [Wed Sep 30 16:17:56 2020] usb 1-8: reset high-speed USB device number 3 using xhci_hcd
19.27.52 #       <kevin__> [Wed Sep 30 16:18:26 2020] usb 1-9: reset full-speed USB device number 4 using xhci_hcd
19.27.55 #       <kevin__> [Wed Sep 30 16:18:26 2020] usb 1-8: reset high-speed USB device number 3 using xhci_hcd
19.29.17 #       <kevin__> oops sry for spam. ive tried diff cables diff OSs, same issue so far. it was spotted once on windows (said device unrecognized), but then it started this whole bootloop on usb thing.
19.33.09 Quit    MrZeus_ (Read error: Connection reset by peer)
19.33.11 #       <lonoxmont> id say try and do a hard reset or power cycle on it
19.33.18 #       <kevin__> yeah, so sudo dmesg | grep -i usb isnt picking up anything if i try again idk if those messages above were even related, even though it only reboots on computer plugins
19.33.32 #       <kevin__> yeah i'm gonna let the battery drain fully and try some more tommorow
19.33.39 #       <lonoxmont> worst case crack it open and figure out how to unhook the battery and force it to completely power off
19.34.16 #       <kevin__> yeah i see this page https://www.rockbox.org/wiki/SansaAMSUnbrick (im clip zip)
19.34.35 Join    MrZeus_ [0] (~MrZeus@90.203.212.4)
19.36.19 #       <kevin__> thanks yall
19.39.14 Join    fs-bluebot_ [0] (~fs-bluebo@55d4659c.access.ecotel.net)
19.39.26 Quit    bluebrother (Disconnected by services)
19.39.31 Join    bluebrother^ [0] (~dom@rockbox/developer/bluebrother)
19.41.25 Quit    fs-bluebot (Ping timeout: 246 seconds)
20.06.24 #       <braewoods> i'll take the risk later
20.06.40 #       <braewoods> speachy: i mean, i'll try to make a new bootloader later on. right now got other plans.
20.06.56 #       <braewoods> need to wait for my CF parts to get here, etc
20.07.10 #       <braewoods> so i can actually test for the problem i'm trying to repair
20.13.30 #       <speachy> that's wise.
20.15.08 #       <braewoods> speachy: is there an official guide for testing bootloaders?
20.15.18 #       <braewoods> i saw the 7pre4 zip had a readme with something like that
20.15.41 #       <speachy> not that I'm aware of, beyond "bricking is a distinct possibility"
20.15.51 #       <braewoods> ok.
20.15.59 #       <braewoods> i expect v6 to remain the default for now
20.16.05 #       <braewoods> indefiniteyl for that matter
20.16.13 #       <braewoods> v7pre5 is what i'll label what i'm trying to do
20.16.32 #       <braewoods> i wonder what happened to the one who uploaded the previous one?
20.16.39 #       <braewoods> MiikaPekkarinen
20.16.41 #       <braewoods> or whoever
20.17.28 #       <speachy> that way predates my involvement (as a developer, anyway)
20.17.36 #       <braewoods> ah.
20.17.51 #       <speachy> I used to have an ihp-120 but it was stolen out of my car during tropical storm Fey
20.18.57 #       <braewoods> ouch.
20.19.06 #       <braewoods> i'm currently watching an auction for one of those
20.19.20 #       <braewoods> https://www.ebay.com/itm/iRiver-iHP-120-Multi-Codex-Jukebox-20G-Black/133529400598
20.20.04 #       <braewoods> i was going to try to get it for testing
20.20.20 #       <braewoods> but if you'd rather
20.21.42 Join    massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
20.22.44 #       <speachy> _bilgus__: comments on g#2773?  Discovered it while trying to hunt down an unrelated issue.  Seems like an oversight..
20.22.55 #       <fs-bluebot_> Build Server message: New build round started. Revision 91197dd, 282 builds, 9 clients.
20.23.09 #       <braewoods> speachy: i'm surprised anyone would steal an ancient mp3 player
20.23.11 #       <braewoods> o.O
20.23.41 #       <braewoods> they're not something many people want afaik
20.23.54 #       <speachy> and g#2774 is what I spent most of the afternoon working on, finally builds on everything I have access to.
20.24.50 #       <speachy> braewoods: TS Fay hit in August 2008.  They also stole a pair of prescription sunglasses too.
20.26.07 #       <braewoods> Oh. That long ago.
20.26.26 #       <braewoods> you said Fey originally so I thought it was this year
20.26.41 #       <braewoods> Oh.
20.26.45 #       <braewoods> wth wikipedia
20.26.48 #       <braewoods> https://en.wikipedia.org/wiki/Tropical_Storm_Fay_(2020)
20.27.07 #       <speachy> they recycle names every what, 9 years?
20.27.15 #       <braewoods> lol i see that
20.28.05 #       <speachy> Fay dropped something like 24" (~60cm) of rain on us..
20.31.24 ***     Saving seen data "./dancer.seen"
20.32.01 #       <_bilgus__> I wish the sim was even more tightly linked than it is currently
20.32.48 #       <braewoods> does the simulator work for bootloader testing?
20.32.50 #       <speachy> _bilgus__: as a general rule, the sansa ams targets support 96KHz audio, right?
20.33.29 #       <speachy> the simulator is only a UI simulator.  doesn't run any hw-specific code.
20.33.37 #       <speachy> and doesn't emulate anything at all
20.34.08 #       <braewoods> ok
20.36.23 #       <speachy> I'm trying to figure out how many targets that used to claim SAMPR_CAP_ALL actually supported >48KHz.
20.36.32 #       <_bilgus__> braewoods, bluebrother^  the clip+ bootloader is up to date tested and used in rbutil since last? year
20.37.31 #       <_bilgus__> amongst other players supported by that patch that we had on hand to test clip zip, fuze+ fuzev2 and maybe e200
20.39.00 #       <braewoods> _bilgus__: interesting. i'm looking to push out a new bootloader for the iriver h120 at least.
20.39.03 #       <fs-bluebot_> Build Server message: Build round completed after 968 seconds.
20.39.04 #       <fs-bluebot_> Build Server message: Revision 91197dd result: All green
20.39.16 #       <braewoods> but a bit later. mostly for fixes that were never made available in it.
20.40.21 #       <braewoods> for sensitive builds i usually use my LXD containers on my server
20.40.29 #       <braewoods> since it has ECC RAM and such at its disposal
20.42.39 #       <genevino> so what's a recommendable environment for building? i noticed sh-elf-gcc is only available from the AUR on arch/artix and it's not exactly trivial to use that.
20.43.46 #       <braewoods> most things prefer debian or ubuntu
20.43.50 #       <braewoods> especially cross-compiling
20.43.56 #       <genevino> gotcha.
20.44.08 #       <braewoods> e.g., openwrt, uboot, and lineage os
20.44.10 #       <braewoods> for starters
20.47.54 #       <speachy> genevino, https://www.rockbox.org/wiki/CrossCompiler
20.48.08 #       <speachy> step 2a works quite well.
20.49.42 #       <genevino> oh wow, thank you.
20.50.20 #       <braewoods> or
20.50.22 #       <braewoods> https://www.rockbox.org/wiki/Main/LinuxSimpleGuideToCompiling
20.51.01 #       <speachy> the whole page is out of date except for 2a.  heh.
20.51.13 #       <braewoods> i updated one of them to include wget
20.51.19 #       <braewoods> since my container was pretty bare
20.53.04 #       <genevino> "Instructions here might be obsolete. as nobody does it manually really."
20.53.04 #       <genevino> hehe
20.53.14 #       <_bilgus__> speachy I'd just say its an oversight was before me but I do wonder HTH you found it
20.53.22 #       <_bilgus__> (2773)
20.54.44 #       <speachy> I put an #error check in config.h if none of the target config files got #included
20.56.09 #       <speachy> okay, this is odd.  my clip+'s screen is _very_ dim and washed out.  only when the USB is plugged in is it visible too.
21.00.40 #       <speachy> _bilgus__: if you have a clip+ (or any sansa ams) player handy with the test plugins installed, can you tell me if it has 96KHz as an audio rate, and if it actually works?
21.01.19 #       <fs-bluebot_> Build Server message: New build round started. Revision 127862c, 282 builds, 9 clients.
21.09.45 #       <braewoods> speachy: is that something you can view from the debug options from the standard stable build?
21.10.01 #       <braewoods> i have a sansa clip+ with RB 3.15 already installed
21.10.32 #       <speachy> No, I need to see if it actually works, as on 3.15 it claims to support it.
21.11.06 #       <braewoods> how would I know? i don't have anything that supports 96khz afaik
21.11.07 #       <speachy> though.. with a dev build you could try to dial the mikmod plugin up to 96KHz
21.12.01 #       <speachy> I think there are a lot of targets that used to have SAMPR_CAP_ALL when that was limited to 48KHz, and when the upper cap got bumpted to 96, those weren't properly audited/updated.
21.13.34 #       <speachy> _bilgus__: I think thre's going to be some red in this build.  :/  Just discovered ipod nano broke with the lua change.
21.15.21 #       <fs-bluebot_> Build Server message: Build round completed after 843 seconds.
21.15.22 #       <fs-bluebot_> Build Server message: Revision 127862c result: 149 errors 0 warnings
21.24.40 #       <fs-bluebot_> Build Server message: New build round started. Revision c2c5945, 282 builds, 9 clients.
21.25.01 #       <speachy> so, looks like lua will gain the ability to interoperate with the remote control buttons on the ipods.
21.26.57 #       <speachy> cool, gave it a whack and the screen started working again
21.30.25 #       <speachy> okay, clip+ does _work_ with the higher rates but they're off a bit; only 88K sounds correct.
21.38.12 #       <fs-bluebot_> Build Server message: Build round completed after 812 seconds.
21.38.14 #       <fs-bluebot_> Build Server message: Revision c2c5945 result: All green
21.38.26 #       <speachy> anyone here have an imx233-based device?  (fuze+, most creative zens)
21.39.11 #       <speachy> (or the sony e360/e370, and samsung yp-z5)
21.43.00 #       <speachy> and an ipod6g/classic (since the nano2g works with 96K, the same-guts 6g/classic should too..)
21.43.58 #       <fs-bluebot_> Build Server message: New build round started. Revision 01650b8, 282 builds, 9 clients.
21.44.44 #       <_bilgus__> sorry AFK
21.48.23 #       <_bilgus__> speachy I have a fuze+ @ home I can get it this week sometime
21.50.49 #       <speachy> no worries.  of the imx233 players, only the sonys were seemed to be advertised with 96K support, so I left the rest at 48.
21.52.40 #       <_bilgus__> I think we already tried this on the clip+ or zip at one point
21.53.06 #       <speachy> I also have a codec here that's floating-point.  which pretty much limits its use to the newer hosted linux targets (ie armhf or mips) with FPUs.
21.53.28 #       <_bilgus__> ended up settling for decent 48k and good 44
21.53.58 #       <speachy> 88K sounds good, the others above 44 are a bit off.
21.54.15 #       <_bilgus__> yeah the int fp stuff is black magic as it is
21.54.39 #       <_bilgus__> 88 doesn't seem like a common format though
21.55.02 #       <speachy> 88 and 172 are common DSD->PCM downsampling targets.
21.55.11 #       <_bilgus__> not that 96k is either :p
21.56.05 #       <speachy> also there's a ticket asking about supporting various DSD-ish file formats; I found three different libraries to do DSD->PCM conversion but they all use FP too.
21.56.29 #       <speachy> which is probably fine, as the only targets that have enough ooomph to do that crap (and support high bitrates) all hve hardfloat anyway.
21.57.00 #       <speachy> though I can't imagine the jz4760's threading code is sane with respect to the FP state.
21.57.25 #       <speachy> (threading & interrupt)
21.58.27 #       <speachy> and doing native DSD playback on the HW that supports it would mean bypassing our mixer layer altogether.  Might be feasible in a PoC plugin though.
22.06.03 #       <speachy> Still have a few more chunks to pull/rework out of the m3k dump before I can properly tackle the m3k-specific code.
22.12.27 #       <fs-bluebot_> Build Server message: Build round completed after 1708 seconds.
22.12.28 #       <fs-bluebot_> Build Server message: Revision 01650b8 result: All green
22.12.29 #       <fs-bluebot_> Build Server message: New build round started. Revision 1cd004f, 282 builds, 9 clients.
22.31.27 ***     No seen item changed, no save performed.
22.34.12 #       <fs-bluebot_> Build Server message: Build round completed after 1304 seconds.
22.34.13 #       <fs-bluebot_> Build Server message: Revision 1cd004f result: All green
23.11.03 #       <fs-bluebot_> Build Server message: New build round started. Revision cb9b5d3, 282 builds, 9 clients.
23.27.33 Quit    ac_laptop (Ping timeout: 258 seconds)
23.28.35 Quit    MrZeus_ (Ping timeout: 240 seconds)
23.31.47 #       <fs-bluebot_> Build Server message: Build round completed after 1244 seconds.
23.31.48 #       <fs-bluebot_> Build Server message: Revision cb9b5d3 result: All green
23.32.31 Quit    massiveH (Quit: Leaving)
23.40.55 Quit    TheSeven (Ping timeout: 240 seconds)
23.41.33 Join    TheSeven [0] (~quassel@rockbox/developer/TheSeven)