--- Log for 13.10.120 Server: wilhelm.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 15 days and 20 hours ago 00.37.32 *** Saving seen data "./dancer.seen" 00.43.49 Quit rogeliodh (Quit: Ping timeout (120 seconds)) 00.44.20 Join rogeliodh [0] (~rogeliodh@rogeliodh.dev) 01.13.06 Quit ac_laptop (Ping timeout: 272 seconds) 02.25.42 Join petur [0] (~petur@199.59.5.111) 02.25.42 Quit petur (Changing host) 02.25.42 Join petur [0] (~petur@rockbox/developer/petur) 02.37.34 *** Saving seen data "./dancer.seen" 03.18.23 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 03.58.28 Quit pamaury (Ping timeout: 260 seconds) 04.10.52 # speachy: any insights into why older electronics sometimes expect low-voltage AC? apparently the original NES could take AC or DC if the voltage was correct. 04.11.23 # for that matter why did they use center-negative barrel jacks? 04.11.34 # pretty much everything today is center positive 04.37.37 *** Saving seen data "./dancer.seen" 04.38.24 Join pamaury [0] (~pamaury@maths.r-prg.net.univ-paris7.fr) 04.38.24 Quit pamaury (Changing host) 04.38.24 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 04.42.17 # incidently i ended up ordering an inverter barrel jack cable 04.42.40 # just to deal with that problem where it's not practical to rewire existing cables to be center-negative 04.43.14 # it's easier just to use an adapter that flips the wires 04.43.50 # I'd be very wary of that. If you're not careful, you associate power supply and device, and then one day the adapter cable isn't there... 04.44.02 # indeed. 04.44.26 # Maybe if you heatshrink the connectors or something like that 04.44.42 # i was planning to add some kind of label to the inverter cable 04.44.54 # since it is only intended for some rare situations 04.45.42 # i checked out the main device i wanted to modify 04.45.52 # turns out it is soldered to the board so not very easy to rewire 04.46.12 # i would rewire it to be center positive if i could 04.46.17 # but doesn't seem practical 04.46.34 # it's easier just to use an inverter cable 04.46.36 # but you're right 04.46.41 # it needs to be clearly labeled 04.46.46 # at the very least 05.19.34 Quit S|h|a|w|n (Quit: Leaving) 05.47.20 Quit lemon_jesus (Ping timeout: 272 seconds) 06.16.33 Join ulmutul [0] (~ulmutul@dslb-146-060-189-092.146.060.pools.vodafone-ip.de) 06.18.25 Quit Oksana (Ping timeout: 240 seconds) 06.24.16 Join JanC_ [0] (~janc@lugwv/member/JanC) 06.24.26 Quit JanC (Killed (adams.freenode.net (Nickname regained by services))) 06.24.26 Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) 06.25.43 # braewoods: I maintain the exact opposite: almost everything is center negative :) 06.26.10 # That applies to the 5mm barrel jacks; for smaller ones you are probably right (center positive). 06.26.41 # ulmutul: well my laptops from 2013 use center positive 06.26.49 # they use 7.5mm or so 06.27.11 # i have an older arm box with 5.5mm 5v center positive barrel jack 06.27.11 # E.g. all this guitar effect stuff is (and was) 9V/center positive. 06.27.18 # I see. 06.27.35 # i don't own such things so i guess that's why 06.28.56 # Some audio devices need AC voltage to generate symmetric voltage, i.e. they generate +9V/0V/-9V from a single 2-line-AC input. 06.37.40 *** Saving seen data "./dancer.seen" 06.49.25 Quit Stanley00 () 06.57.48 # ulmutul: i see. odd though considering generating inverted voltages is just a matter of flipping wires. 06.57.59 # but i guess crossing wires isn't always practical. 07.01.22 # braewoods: anything using classic op-amps or bipolar logic uses symmetrical +- voltage, and it's easier to get that from straight AC than it is to use a switching DC/DC charge pump to invert it. 07.06.51 # in other words: the voltage is doubled, you have a full swing of lets say 18V (from -9 to +9V). 07.08.16 Quit _bilgus_ (Remote host closed the connection) 07.10.09 Join _bilgus_ [0] (~bilgus@2605:a000:1301:89f6:e5a5:7286:a5d3:d72f) 07.18.24 # no, wait, bipolar is something else. ugh. not enough sleep. 07.21.01 # anayway. it greatly simplifies your power supplies, and before the days of switched supplies, it was pretty much the simplest way of achieving it. 07.24.54 # (Most of what I know about this stuff was via osmosis; my last gig had me working with some very talanted analog folks working to design an ultra-low-power BTLE radio) 07.30.10 Join MrZeus__ [0] (~MrZeus@2a02:c7f:70d0:6a00:cc6a:52fa:7d38:2ab9) 07.49.17 # BTW, the pine64 folks are proposing something based on the design of their PineCube -- https://wiki.pine64.org/index.php/PineCube 07.49.47 # Allwinner V3 (ARM Cortex-A7 @ 1.2GHz, 128MB on-package RAM) 08.00.10 # it probably would make a decent enough "hosted" port -- we'd have the full ability to control the base Linux layer. 08.00.27 # but I'd really want to go native. 08.31.52 # I think pine64 is offering to send a couple over to us. Who all would want one? 08.37.44 *** Saving seen data "./dancer.seen" 08.42.50 # looks perfect to start with 08.42.59 # it has more than needed but 08.43.22 # it's mostly a matter of removing stuff we don't want. 08.43.33 # or simply leaving it there unused 08.43.45 # in the mean time it's a good dev platform 08.44.12 # more than enough RAM 08.44.30 # aaand full schematics + source code. :) 08.44.45 # GPIO could be used for buttons 08.45.11 # the networking bits could be removed 08.45.18 # same with camera 08.45.39 # usb is probably the only communication necessary 08.45.48 # and it can be used to get a serial console and more 08.46.44 # we'd need OTG 08.47.53 # I was also looking at this previously: https://www.ebay.com/itm/Cherry-Pi-Allwinner-V3S-LINUX-QT-ARM-Open-Source-Maker-Dev-Board-PK-Raspberry-Pi/284019059827 08.48.17 # same SoC (albeit in different packaging and half the RAM) 08.48.53 # speachy: ah. 08.49.02 # well usb OTG is probably a good idea to have anyway 08.49.12 # it's something rockbox relies on 08.49.38 # eventually i'll look at MTP support work 08.49.45 # well, yeah. obviously pine64 would be spinning a new board, but having a working port to an existing board (same SoC) would be 90% of the way there 08.49.46 # but i suspect some ports simply won't work with it 08.49.53 # due to lacking hardware or so 08.50.31 # anything with a soft USB stack (which is nearly all of 'em) are technically capable of MTP. Whether or not they have enough RAM is to pull it off is another matter. :) 08.50.32 # speachy: sounds interesting. not sure what type of interfaces you'd want to do audio with. 08.50.37 # USB is an option i guess? 08.51.03 # the pinecube uses teh SoC's internal audio codec, as does that "cherry pi". 08.51.12 # oh, it has audio 08.51.29 # the SoC supports i2s for external codecs too, naturally 08.51.39 # are they any good? 08.51.42 # i suspect cheap stuff 08.52.01 # with a cpu this beefy we could just do all decoding in software 08.52.09 # just need good quality outputs? 08.52.15 # (well, we already do all decoding in software) 08.52.19 # Oh. 08.52.21 # lol 08.52.53 # the SoC has both internal headphone driver and a line-level output from its codec. 08.53.25 # the pine64 speaker uses an external amp attached to the line out, whereas the "pi" is a straight headphone connection 08.54.11 # tbh I think that, with proper component isolation, the quality will be plenty good. 08.54.28 # (eg don't cheap out on isolating capacitors and power supply filtering) 08.54.35 # i see 08.54.45 # it has bluetooth and wifi 08.54.55 # of these only BT has any merit but rockbox has no BT stack 08.55.16 # just wifi, I think. 08.55.20 # https://www.pine64.org/cube/ 08.55.37 # interesting. 08.56.17 # well it would simplify the board if we strip out anything that isn't going to be used 08.56.52 # I just don't see the bt stuff on the schematic obviously. 08.56.58 # there is a dedicated uart for debug 08.57.23 # we'd probably want to use u-boot... 08.57.35 # or maybe not 08.57.40 # a custom RB bootloader might work just as well 08.57.52 # but we'll probably be taking references from u-boot and linux 08.58.08 # ok, there it is, BT is uart-attached 09.01.45 # Do we have some idea what the cost would be? If that's fairly high due to relatively low volume and other fun stuff, it might be a good idea to add an external audio codec with a good reputation to help make it worth the price 09.01.58 # assuming this goes forward, step 1 would be to port rockbox-as-an-app to their base SDK platform. 09.02.25 # well, this pine64 thing is $30 in single-uint quantities, including a camera and other crap. 09.02.51 # I'd prefer an external codec too, but it's a tradeoff between form factor + battery life. 09.03.39 # I'm thinking shooting for something the size of the Rocker would be ideal, and that's probably not going to get us a large enough battery for an external codec worth a damn 09.04.21 # but the nice thing about this base platform is that it's easily extendable. 09.04.33 # no reason we couldn't end up with more than one player at different size/pricepoints 09.05.19 # but this is likely to only be viable if we're able to re-use an existing case design that already has the tooling paid for 09.06.27 # Right. Screen is optional though, so not included in that $30. It's unclear what sort of sales volume the DAP-respin would get, and I'm guessing a screen is more expensive than a camera and the other stuff we don't need, so let's say $40. Plus indeed a case, which is kind of essential... 09.06.28 # new tooling is in the six digits range. 09.06.46 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 09.07.33 # If you only sell 50, 3d print it, but yes, that's the real issue these days 09.07.53 # the case is the most expensive part, solely due to the NRE. 09.08.33 # displays are a plentiful and cheap commodity 09.09.13 # and other than the actual SoC+PMIC (and possibly an external audio codec) there's little else of note. 09.10.03 # well, biggest possible battery in the remaining volume, anyway.. 09.11.50 # another price point -- that CherryPi thing is $17 in single-unit quantities. Obviously lacking a display, case, and battery. 09.13.21 # if we, say, double that for the missing bits that means we're probably looking at a $50-60 final pricing; ie in the range of the rocker or m3k. 09.14.40 # and a platform that doesn't need to be reverse-engineered 09.14.43 # (and that cherry pi thing has wifi too) 09.15.15 # i assume sd card for storage 09.15.20 # the SoC has full mainline linux support (except for the video encoder which we don't care about) 09.15.21 # or would MMC be an option? 09.15.37 # eMMC is an option, but we'd want external SD. 09.15.53 # how fast would the SD cards be? 09.16.03 # it would be nice if we could saturate USB 09.16.04 # 2.0 09.16.23 # optional but nice if doable 09.16.28 # there's enough ram to buffer writes 09.16.30 # so 09.16.32 # it should be doable 09.16.45 # it's SD 2.0 (ie 4-bit) but the question is if the controller can handle UHS-1 signaling on top of that. 09.16.46 # if the physical hardware would otherwise allow it 09.16.59 # and how fast can that be? 09.17.36 # hm. 09.17.41 # ah. the most common one i know 09.17.52 # limited to 32G 09.18.02 # standard SD is up to 25MHz @4bits == 100Mbit = 12.5 MB/s max 09.18.18 # that's fast enough i guess 09.18.18 # UHS ups that to 100MHz (I think) ie 50MB/s. 09.18.30 # comparable to existing native targets 09.18.52 # UHS-1, that is. UHS-2 goes to 8 bit signaling (and a second row of pins on the card) 09.19.06 # UHS-1 is fast enough 09.19.09 # Forget "limited to 32GB" That's a confused set of weirdness 09.19.26 # gevaerts: i see. i know SD 2.0 specified that. 09.19.57 # UHS-1 requires different (LVDS?) signaling across the pins; it's not just a higher clock speed. 09.20.22 # ah. 09.20.29 # Yes. As I understand it the spec says 'You have plenty of bits in the block address to use loads of storage, but we're going to declare that you can't go over 32GB for no good reason at all' 09.20.45 # so unofficially it can go higher 09.21.10 # such is the decree of the SD Association. 09.21.31 # There's no native rockbox device with an SD card size limit of 32GB. Some have such a limit in the OF... 09.21.34 # granted, SDXC got rid of that arbitrary limit. 09.22.18 # main reason to use SD cards is size constraints i guess 09.22.23 # main drawback is they tend to be slow 09.22.29 # the only thing is that SDXC mandated exFAT. 09.22.35 # and that required separate licensing from MS 09.22.46 # can't we just have users reformat their cards? 09.22.50 # Which again should have been out of scope for the spec... 09.22.51 # so when you see "32GB" max it usually means they can't handle exfat 09.23.04 # i know FAT32 can go beyond 32G 09.23.15 # and yes, one can always reformat the card. 09.23.59 # and rockbox has several workarounds for not-quite-reformatted-properly SDXC cards. 09.25.01 # anyway -- the addressing protocol of SD maxes out at 2TB. That's our acutal upper limit 09.25.12 # lol 09.25.27 # (though I suppose they could wave the magic wand and go to larger block sizes like they did to go from SD->SDHC) 09.25.41 # anyway 09.26.21 # it's kinda interesting how they greatly expand the LBAs for PATA but i think only SATA really ever reached drives that massive 09.26.25 # 48-bit LBA 09.26.47 # natively anyway 09.26.54 # ok, the S3/V3 SoC does not handle UHS signaling 09.27.02 # so it's impossible 09.27.19 # not a big deal; only real benefit is faster IO, no? 09.27.46 # just would be nice to make syncing faster 09.27.49 # If the SD association had specified LBA48, there would be a paragraph in the spec saying that while the protocol supports for 48 bit addressing, you can only use 35 of those 09.27.56 # lol 09.28.37 # afaik we don't want to use the massive drives that earlier MP3 players used 09.28.46 # want to use sd cards to limit how much space is needed 09.28.53 # in practical terms the bottleneck in our file transfers is not the raw SD bus speed. our stack isn't the most efficient. 09.28.59 # ah. 09.29.00 # (but it is small!) 09.29.14 # (I think the bigger bottleneck is actually on the USB side) 09.29.26 # we'd need to benchmark it 09.29.32 # might be possible to improve it 09.29.34 # but 09.29.46 # some improvements may have to be gated for targets that don't have enough RAM 09.29.51 # SD 2.0 maxes out at 25MB/s, though it's not clear if that's with 4-bit or 8-bit signaling. 09.30.05 # that would be sufficient 09.30.08 # but how? 09.30.22 # anyway 09.30.31 # ie dial the clock speed as high as the card claims to support and have at it 09.30.43 # i would need to profile the existing stack to see what is slowing it down 09.30.47 # lack of buffering? etc 09.30.53 # that's the raw bus bandwidth, not counting overhead and things like waiting for the card to actually perform writes 09.31.27 # buffering, inefficient use of DMA, our multitasking/scheduling model.. 09.31.57 # huh, there's now an SDUC that goes up to 128TB. 09.32.03 # i may profile rockbox on a few devices 09.32.10 # to see where time is spent when writing 09.32.22 # see if i can improve it 09.32.39 # but OFC... it may not be practical 09.32.52 # easiest avenue to explore is larger buffers 09.33.11 # might be viable for 32MB targets 09.33.12 # There's things you can measure if you want to isolate where you should look first. There's the set of test plugins of course that include file read/write speed tests (but that goes through the FAT layer, which may have an impact), and you can change the USB code to just throw away incoming data and send junk back to measure raw USB speed 09.33.39 # gevaerts: actually i was considering testing writing from directly in RB vs over USB 09.33.50 # though yes 09.33.58 # the direct writes should be more efficient 09.34.06 # Yes. I think you need all the numbers :) 09.34.08 # no USB layer to go through (in theory) 09.34.28 # i know enough about stuff now 09.34.32 # i'll look into it later 09.34.37 # also keep in mind that those obscene speeds are only achievable during sequential access 09.34.40 # especially writes 09.34.50 # probably 09.34.51 # and in mass storage we're jumping all over the place 09.34.54 # If it turns out that SD writing goes at 3MB/s on a specific target, but USB only does 2MB/s anyway. that 3MB is fine 09.35.10 # i just wish to see if i can find something that can be improved upon 09.35.28 # if more caching could help 09.35.29 # there's a lot of overhead to set up a transfer; the longer the actual transfer the less that overhead matters 09.35.30 # that might work 09.35.48 # speachy: indeed. i expect large files, like single file FLAC albums would be most efficient 09.35.50 # to write 09.36.01 # 300+ MB a pop 09.36.27 # that's why for benchmarks I was bypassing filesystems altogetehr and just going for straight dd (with 64K blocks) 09.36.38 # so no filesystem overhead to cause jumping around 09.36.47 # If you want to measure USB in isolation, look for USB_USE_RAMDISK in usb_storage.c. That still includes a memcpy(), but you can comment that out (and get garbage of course) for raw speed 09.37.32 # bbl 09.38.15 # (and results will obviously vary from target to target) 09.47.22 Quit ulmutul (Ping timeout: 272 seconds) 10.02.47 # So! 10.02.59 # today's the day I want to do the toolchain bump 10.37.47 *** Saving seen data "./dancer.seen" 10.53.15 Quit massiveH (Quit: Leaving) 11.01.49 # <_bilgus_> I contend it doesn't matter as long as the fuckers label it 11.02.43 # * speachy raises an eyebrow. 11.02.44 # <_bilgus_> ran across a norditrack or similar no label at all but want $75 for a power brick old transformer wall wart 11.03.03 # ah, okay, finally context. :) 11.03.26 # <_bilgus_> took it apart no protection for rp they meant that to die 11.03.45 # <_bilgus_> sorry screen was half up thought I was in the middle lol 11.06.51 Join johnb7 [0] (~johnb2@p5b3af7ce.dip0.t-ipconnect.de) 11.14.20 # <_bilgus_> speachy re pine I don't have a lot of experience LL porting stuff but this is probably the best chance to do it! 11.15.10 # <_bilgus_> if none of our superstars showup then I'd dev one and we can just send them around as rb community property 11.16.12 # speachy I ran battery bench on the x3ii: http://www.mediafire.com/folder/5qmycn43z1sew/batterybench_X3ii 11.16.53 # Am I right, that currently we don't differentiate between x20 and x3ii: https://git.rockbox.org/cgit/rockbox.git/tree/firmware/target/hosted/xduoo/powermgmt-xduoo.c?id=f791df13751d0c43a2b1ae0adb6f6bc4385c2cc3 11.17.19 # correct. I don't know if there are any appreciable differences with respect to the batteries. 11.22.33 # btw, thanks a lot for the audio fixes on the x3ii: the nasty pop is gone, I don't hear a click anymore on pause/unpause at least if 'fade on pause' is active, the remaining sound on track skip is bearable. 11.23.29 # 13:06, eh? booting into the OF afterwards, what was their view of the remaining life? 11.26.17 # see the conditions.txt: volume was at -50 with those buds. I haven't checked the OF status afterwards, but wanted to record the charging curve, triggered batterybench again, but it went into USB mode (connected to a wall charger) and didn't record anything. mount<0> or something on the screen (I noticed only after 5h). 11.28.29 # the curve is definitely skewed high. the last 10% took >5h to drain. :) 11.30.45 # usually I use an mp3 album, but this time it was mpc. I didn't pay attention. 11.31.09 # the absolute life doesn't matter so much as the percentages 11.31.14 # in this context anyway 11.34.10 # <_bilgus_> johnb7, disk is not accessible in usb it mounts it for itsself 11.35.25 # <_bilgus_> in theory bb keeps everything in ram so just be sure to unplug before saving I suppose 11.37.32 # then how was the charging curve recorded for all the targets? 11.37.56 # _bilgus_: do you still have the battery bench you did for the X3? I want to double-check something 11.38.35 # hold down play when you plug in USB, it won't mount then. 11.40.02 # speaking of x3: the OF has the high/low gain setting. Is this identical with the +6bB in RB or does it also set a different bias current and thus influence battery life? 11.41.29 # <_bilgus_> pastebin 11.42.35 # <_bilgus_> speachy https://pastebin.com/fbz1zVeH 11.42.52 # no idea, I haven't looked into that. 11.43.07 # danke 11.46.30 # <_bilgus_> how to best measure that? probably a dummy load and voltage drop 11.47.20 # Basically, I was wondering if in RB we could save further ... 11.49.59 # <_bilgus_> we do have a manulal for the audio chip IIRC there are probably some phantom power settings etc but that all depends oon having the right things in place at the board level 12.00.28 # the x3's audio (and power) paths are pretty poorly optimized 12.00.39 # x3ii seems to be better in that regard 12.02.01 # Build Server message: New build round started. Revision e91f89a, 290 builds, 9 clients. 12.02.32 # johnb7: this build going now incorporates your benchmark run 12.03.13 # including a stab at runtime estimation. tbh I suspect the overhead of mpc vs mp3 is lost in the noise versus keeping the audio path going. 12.04.12 # interesting, that 13 hour result matches xduoo's claims, but is about 3h longer than most reviews say things last. 12.11.22 # I have the bench running on the hifiwalker h2 now, with a 1300mAh battery 12.12.24 # they claim 30h (!) 12.14.04 # after this build is done I want to do the toolchain bump. 12.15.12 Quit pamaury (Quit: Konversation terminated!) 12.21.35 Quit petur (Quit: Connection reset by beer) 12.22.20 # Build Server message: Build round completed after 1218 seconds. 12.22.24 # Build Server message: Revision e91f89a result: All green 12.24.06 # ok, my builders are fixed. 12.26.36 # master build list updated to use gcc494 for everything 12.27.08 # Build Server message: New build round started. Revision b4865b0, 290 builds, 9 clients. 12.27.27 # okay, it's going. 12.35.04 # amiconn, Strife89, __builtin, please update your builders with the new arm/m68k toolchains. 12.35.43 Join lemon_jesus [0] (~lemon_jes@c-73-9-49-209.hsd1.in.comcast.net) 12.36.31 # I don't know who runs the vm[12]-b0hoon builders, alas. 12.36.50 # Will do 12.37.51 *** Saving seen data "./dancer.seen" 12.39.36 # speachy: define "toolchain bump"? 12.39.53 # braewoods: g#2305 12.39.55 # Gerrit review #2305 at http://gerrit.rockbox.org/r/2305 : Build: Bump all toolchains to GCC 4.9.4 + Binutils 2.26.1 by Solomon Peachy 12.40.20 # speachy: ah. ok. you should probably make sure to include that flag for disable the null pointer optimization. 12.40.39 # arm and m68k targets were still on gcc 4.4.4 and 4.5.2, respectively. 12.40.49 # i think it was introduced in 4.9.x and was the source of some bugs 12.40.56 # in linux kernel 12.41.28 # (mips and hosted arm/mips were already using 4.9.4, and of course simulator/etc builds were using whatever the host compiler was) 12.41.59 # speachy: may want to include this in CFLAGS for the 4.9.x toolchain 12.42.00 # -fno-delete-null-pointer-checks 12.42.20 # i assume rockbox uses NULL and may appear to dereference it at times 12.42.30 # i've seen kernel code do that 12.43.27 # speachy: i'd do the arm PP next 12.43.43 # or so 12.43.52 # arm PP was the main holdup for this 12.43.59 # ah. 12.44.03 Quit johnb7 (Quit: Nettalk6 - www.ntalk.de) 12.44.05 # so m68k should be fine? 12.44.23 # should i recompile the bootloader with new toolchain? though i can't see any benefit to doing so 12.44.39 # two major issues; a bug in binutils causing linking issues and some technically-not-legal inline asm that no longer worked. 12.44.39 # the issue is fixed 12.45.05 # if you don't have the ability to unbrick your ihp, I'd say no, don't rebuild the bootloader 12.45.11 # indeed 12.45.15 # i took a risk doing what i did 12.45.26 # i wanted to do it before the toolchain updates 12.45.29 # due to the risks it carries 12.45.43 # I was told (many moons ago) that the test builds I did for the ihp1xx worked with no issues. 12.46.15 # either way i will probably try a bootloader build after the toolchain is proven reliable for new firmware builds 12.46.21 # <_bilgus_> braewoods it'd be a good idea to keep what you have till it gets tested abit more, we don't change bootloader often at all 12.46.27 # indeed 12.46.37 # if pre5 seems to work just fine and such 12.46.45 # i'll do a 7 release 12.46.52 # and we can try that to replace BL 6 12.48.13 # but i need to test it more 12.48.36 # i intend to do 7 build on new toolchain 12.48.38 # but for now no 12.49.04 # i'll see if i can go back to OF 12.49.13 # so i can test it with OF as well 12.49.21 # 35 left.. 12.51.34 # my reasoning... if the toolchain works reliably for the main firmware, there's a greater chance it will do the same for the bootloader 12.52.01 # yes, but the bootloader is more likely to be um, abusing the C spec due to direct hardware or asm manipulation 12.52.18 # i see. 12.52.20 # I'm confident that the general firmware is fine. 12.52.39 # so the ASM stuff could be borked? 12.52.43 # is that what you're saying? 12.52.53 # that's what I'd suspect the most. 12.53.04 # but a good first pass would be to simply build it, and see if any warnings show up. 12.53.23 # hm 12.53.44 # gcc 4.5... first released on 2010 12.53.54 # so this isn't the same toolchain that build the previous bootloader 12.54.39 # I don't know the history of the bootloader binary builds. 12.54.49 # me either 12.54.57 # i was just looking at the timestamps to get a rough idea 12.55.43 # last one.. 12.56.11 # Build Server message: Build round completed after 1743 seconds. 12.56.12 # Build Server message: Revision b4865b0 result: 122 errors 113 warnings 12.57.26 # well, the only warning in the ihp boot code are some set-but-not-used variables 12.57.39 # totally harmless 12.58.15 # probably time to just punch m68k out 12.58.26 # so the toolchains are fairly synchronized 13.00.18 # looks like most of the red in bootloaders is due to use of division, probably in a printf. 13.01.39 # <_bilgus_> I'm pretty sure we had to make conditionals the last time to dial back the functionality quite possible it needs updated for the BLs 13.02.32 # <_bilgus_> for printf sorry damn the contexts! 13.04.47 # it's in ipod-specific code though 13.13.23 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 13.14.12 # <_bilgus_> I'm not finding the conditionals in vuprintf though apparently I don't remeber where they were 13.28.52 # could you look at g#2845 for me please? 13.28.53 # Gerrit review #2845 at http://gerrit.rockbox.org/r/2845 : Fix compile warnings (set-but-not-used) on big endian targets by Solomon Peachy 13.29.07 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 13.37.47 # Build Server message: New build round started. Revision ca32689, 290 builds, 9 clients. 13.38.23 # ok, this will fix mot of the yellow, and a bit of the red too. I think all that will remain are the PP bootloaders and their reference to division. 13.40.13 # <_bilgus_> looks sane to meeee 13.40.56 # <_bilgus_> I'm a little surprised that the older toolchain didn't highlight that seems cut and dry 13.43.38 # <_bilgus_> well thats enough for today I think I should have most of the plugins that need workarounds finished tomorrow and I think* the remote lcd stuff shoulkd fall into place so probably the weekend I should have the viewport stuff ready for testing 13.43.56 # probably only picked up because of the change to -Os 13.44.59 # no, that's not right, m68k was -Os before. guess the new toolchain is just has better diagnostics. :) 13.46.29 # <_bilgus_> makes sense I suppose I wonder if that error in the sim settings save is still there with the newer toolchain JhMikeS wasn't very happy when I removed his optimizations but I was tired of 60MB+ config.cfg files 13.48.15 # <_bilgus_> g#1975 13.48.16 # Gerrit review #1975 at http://gerrit.rockbox.org/r/1975 : Fix vuprintf fix possible %s buffer over-read by William Wilgus 13.54.51 Join johnb7 [0] (~johnb2@p5b3af7ce.dip0.t-ipconnect.de) 13.55.00 # on the plus side... check out the binary size deltas! 13.57.35 # Build Server message: Build round completed after 1188 seconds. 13.57.36 # Build Server message: Revision ca32689 result: 115 errors 55 warnings 14.01.29 # <_bilgus_> yeah 70k+ deltas amazing 14.01.43 # <_bilgus_> hopefully not a sign of bugs :[ 14.01.45 # the codecs are nearly all untouched 14.02.16 # <_bilgus_> theys have a lot of asm from all those years of 'improvements' 14.02.52 # <_bilgus_> I just hope there aren't any bugs in codec land some of that is a scary mess 14.03.05 # <_bilgus_> most* 14.03.10 # (I deliberately left those alone, I figure we can do benchmarks of -Os vs whatever they are now) 14.03.45 Quit johnb7 (Ping timeout: 240 seconds) 14.04.20 # <_bilgus_> I imagine most aren't currently -Os 14.04.48 # most are -O2 or -O3 14.04.49 # <_bilgus_> bb in 12hrs have fun 14.09.15 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) 14.37.52 *** Saving seen data "./dancer.seen" 14.44.25 Quit pamaury (Ping timeout: 240 seconds) 14.53.23 Join johnb7 [0] (~johnb2@p5b3af7ce.dip0.t-ipconnect.de) 15.18.04 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 15.25.18 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 15.37.02 # exit 15.37.25 # /quit 15.37.53 # wrong focus ... 15.38.06 Quit johnb7 (Quit: Nettalk6 - www.ntalk.de) 15.42.04 # the gigabeat-s/imx31 read is due to some horrid abuse of CPP, forward-declaring a function name inside a static initializer. 15.48.51 # Build Server message: New build round started. Revision b94db70, 290 builds, 8 clients. 15.51.48 # that should knock out everything but the PP bootloader and the ZenVisionM. 15.57.40 # speachy: is m68k big or little endian? 15.57.44 # big 15.57.49 # from what i've seen big endian is a bit rare 15.57.54 # it is now 15.57.54 # ah. 15.59.44 # speachy: kinda interesting though. i always thought big endian would take over but little endian did. 15.59.54 # intel was cheeeeeep 16.00.06 # big endian is native byte order so i thought it would dominate in networking gear, etc 16.00.12 # since, no need to byte swap as much. 16.00.15 # err 16.00.18 # network byte order 16.09.50 Quit mendelmunkis (Read error: Connection reset by peer) 16.10.14 Join mendelmunkis [0] (~mendelmun@ool-435680b7.dyn.optonline.net) 16.12.48 # Build Server message: Build round completed after 1435 seconds. 16.12.50 # Build Server message: Revision b94db70 result: 83 errors 61 warnings 16.16.30 Quit Acou_Bass (Ping timeout: 256 seconds) 16.19.44 Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) 16.22.29 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 16.36.21 # speachy: they were? seems like intel is expensive these days 16.36.46 # it seems like their biggest innovation is their pricing models lately 16.37.53 *** Saving seen data "./dancer.seen" 16.45.13 Quit Rower (Ping timeout: 264 seconds) 16.55.37 # braewoods: think back three decades. 16.56.33 # IBM went with intel for the PC because Motorla's 68K was much more expensive. 16.56.41 # (four decades, really..) 16.56.49 # the 8088 16.57.08 # so why did they pick that instead of the 6502? 16.57.17 # because it was stuck at 16 bit memory? 16.57.27 # the 8088 was _much_ more powerful than the 6502. 16.59.14 # 64 16.59.29 # speachy: was it painful to code for the original memory model? i vaguely recall it was using segments 16.59.33 # 16 x 16 16.59.35 # or so 16.59.44 # yeah, segmented. and still supported to this day. 16.59.55 # only if running in 16 bit mode 16.59.59 # no? 17.00.07 # but still simpler than dealing with that much memory on a 6502 17.01.54 # because 6502 required bank swapping? 17.03.30 # not to mention the method of switching and such were system specific 17.04.28 # it's also even more register constrained than the 8086; native 8-bit instead of 16-bit. 17.04.33 # too, I mean 17.05.06 # i think modern 32 bit CPUs even are far better to deal with 17.05.11 # flat memory model FTW 17.05.29 # i hate having to map memory around like that 17.05.35 # i'd rather have it always mapped 17.05.47 # yep. but memory used to be super expensive, so you neeed your code to be ultra-compact too. 17.06.10 # 64 bit doesn't offer as much as the leap to 32 bit did 17.06.12 # couldn't afford to waste 32 bits on memory addresses 17.07.05 # and i can't see 128 bits being a thing anytime soon since the main driver of cpu jumps were all memory related 17.07.19 # for common cpus 17.07.21 # anyway 17.07.27 # specialized ones are an exception 17.07.48 # 128-bit addressing, maybe not, but 128-bit ALUs are definitely a thing already 17.07.50 Quit lebellium (Quit: Leaving) 17.08.13 # speachy: in fact the 64 bit memory space only has 48 bits for physical memory in x86_64 17.08.23 # but that still leaves an insane amount of space for growth 17.08.55 # consumer PCs... the most i've ever had was 16G in a single system 17.09.09 # that only needs 34 bits 17.10.12 # ... lol 17.10.20 # from #learnprogramming 17.10.21 # TheHermann | how improve my C? 17.10.33 # The big problem is that consumer CPUs with a 128 bit ALU and 64 bit memory addressing would make the entire IT infrastructure grind to a halt because everyone would be too busy to debate whether it's a 64 bit or a 128 bit CPU to maintain the lot 17.10.49 # gevaerts: lol 17.11.03 # but there's like 0 benefit from having pointers that big 17.11.21 # Let's all go back to the nice 4 bitness of the Z80 :) 17.12.41 # gevaerts: no thanks. i don't want to use the appetizer of data processing. 17.12.43 # LOL 17.13.01 # since those are "nibbles" 17.13.19 # http://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html in case you weren't aware :) 17.15.46 # gevaerts: looks like trivia. 17.16.11 # to the users the difference is probably irrelevant beyond what it means for expectations 17.16.46 # speachy: is the new toolchain supposed to require gmp to build? 17.17.07 # It's trivia and fodder for people who like debating meaningless things 17.17.29 # gevaerts: kinda like how C digraphs and trigraphs are trivia because no one really uses them 17.17.32 # mendelmunkis: I think so. 17.17.41 # you could write programs with them but no one does 17.18.11 # can you give me a wiki account with my gerrit email so I can update the requirements page? 17.18.27 # ask speachy 17.18.30 # he's the one who set me up 17.19.06 # give me a few please 17.21.39 # no problem 17.23.10 # should be an email waiting for you now 17.23.37 # thanks 17.24.02 # speachy: bored? if so... a random detail i remembered. 17.24.12 # speachy: is this snippet defined behavior? 17.24.21 # no.. still cleaning up the mess I made of the build board 17.24.31 # speachy: int x = 0; printf("%d %d %d\n", ++x, ++x, ++x); 17.25.15 # now that's an interesting thing. probably going to be 3 3 3 17.25.25 # (if not "implementation defined") 17.25.52 # Actually not 17.26.04 # the evaluation order of function arguments is implementation defined 17.26.14 # so 17.26.16 Join ulmutul [0] (~ulmutul@dslb-146-060-189-092.146.060.pools.vodafone-ip.de) 17.26.24 # if they involve side-effects or otherwise depend on the order 17.26.30 # you will get different behavior 17.26.53 # you'd get 1 2 and 3 but their order in the output will vary 17.30.20 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 17.31.26 # tcc spits out 1 2 3 17.31.33 Join Oksana_ [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide) 17.31.48 # lol gcc spits out 3 3 3 17.32.20 # clang does 17.32.22 # 1 2 3 17.33.04 # 0 1 2 for clang/tcc 17.33.08 # 2 1 0 for gcc 17.33.11 # if i switch to x++ 17.33.35 # right. 17.33.37 # i remember now 17.33.45 # clang does left to right 17.33.48 # gcc does right to left 17.34.10 Nick mendelmunkis is now known as mendel_munkis (~mendelmun@ool-435680b7.dyn.optonline.net) 17.34.25 # speachy: err can you also add me to the wikiuser group? 17.35.19 # also is it worth updating the build VM now that WSL is a thing? 17.35.46 # this PP bootloader build failure is quite wonky. seems to actually be a linker issue. 17.36.48 # mendel_munkis: done 17.37.40 # the main reason for that VM was that our toolchains used to be finicky to build on more modern systems 17.38.01 # speachy: what's the log say? 17.38.14 # braewoods: https://build.rockbox.org/shownewlog.cgi?rev=b94db70;type=gogearhdd6330boot 17.38.51 # it's not picking up the __div0() that lives in lib/arm_support/support-arm.c 17.39.11 # but only in the bootloader builds. the main build works like a champ. 17.42.10 # speachy: according to this... it's actually an ASM file? 17.47.20 # speachy: oh i see. 17.47.40 # speachy: anyway.. maybe you need to reorder the files for linking. 17.47.52 # oddly I've known symbol references to disappear when you reorder the link stuff. 17.47.57 # i mean 17.47.59 # the errors 17.49.21 # so should I remove the recommendation to use the VM? (especially) since it is obsolete? 17.54.12 Quit pamaury (Ping timeout: 256 seconds) 17.55.13 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 18.06.25 # I would personally. That can be cchanged when/if the VM is updated. 18.07.36 # o..k... getting rid of -larm_support made it go away and link properly. 18.09.15 # what was __div0 supposed to do? 18.09.26 # it's the divide-by-zero exception handler 18.09.56 # I see. 18.09.58 # Right. 18.10.19 # which should actually not be callable because we've disabled exceptions in the stdlib. 18.12.16 Quit Rower (Ping timeout: 246 seconds) 18.16.48 Quit ulmutul (Quit: Leaving) 18.29.03 # ok, need to re-add libs after. 18.37.55 *** Saving seen data "./dancer.seen" 18.54.13 Quit Acou_Bass (Ping timeout: 264 seconds) 18.57.03 Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) 19.03.30 # Build Server message: New build round started. Revision e2adc67, 290 builds, 8 clients. 19.21.53 Quit Acou_Bass (Ping timeout: 260 seconds) 19.23.09 Nick Oksana_ is now known as Oksana (~Wikiwide@Maemo/community/ex-council/Wikiwide) 19.24.48 # Build Server message: Build round completed after 1278 seconds. 19.24.50 # Build Server message: Revision e2adc67 result: 20 errors 86 warnings 19.24.59 Quit Guest93825 (Ping timeout: 258 seconds) 19.25.09 Quit vup (Ping timeout: 260 seconds) 19.25.09 Quit genevino (Ping timeout: 260 seconds) 19.25.21 Join vup [0] (~~~~@46.101.193.235) 19.25.43 Join alexbobp [0] (~alex@meowface.org) 19.26.06 Nick alexbobp is now known as Guest18548 (~alex@meowface.org) 19.31.24 Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) 19.32.44 Join genevino [0] (~genevino@m2m.pm) 19.49.26 Quit bluebrother (Disconnected by services) 19.49.31 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 19.49.43 Join fs-bluebot_ [0] (~fs-bluebo@55d448d3.access.ecotel.net) 19.52.25 Quit fs-bluebot (Ping timeout: 264 seconds) 20.02.36 Quit Acou_Bass (Ping timeout: 256 seconds) 20.03.39 Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) 20.10.13 # Build Server message: New build round started. Revision cddd8d6, 290 builds, 8 clients. 20.10.55 # "$ git pull / You are not currently on a branch." Ugh. 20.11.15 # 'git chekout master' :) 20.12.11 # Ah, thanks 20.13.24 # Now I can set my comp to work on building the newer toolchains 20.15.02 Quit MrZeus__ (Ping timeout: 246 seconds) 20.28.05 # Build Server message: Build round completed after 1073 seconds. 20.28.07 # Build Server message: Revision cddd8d6 result: 4 errors 1 warnings 20.29.49 # excellent. just one final oddity to sort out. 20.37.58 *** Saving seen data "./dancer.seen" 20.48.13 # this final one is some sort of nested inline asm failure that only seems to trigger on this specific target. 20.52.06 # do the new toolchains actually build now? 20.52.22 # yes, but so did the old ones 20.52.25 # i know there was a long period where you either used the prebuilt ubunto vm with toolchain or got lucky 20.52.57 # at least i only ever got it to work on like 1 out of the 4 places i tried it 20.53.59 # IIRC I fixed the last of the known older toolchain build issues in July. Even archos's ancient gcc4.0.2 was building okay on modern systems 20.55.19 # (special snowflake developement system requirements really annoy me) 20.55.48 # ah nice, might give it a whirl again then 20.57.04 # I want to move to yet newer tooling, but just getting everyting dragged forward was a large enough hurdle. 21.01.17 # otoh you already did it once before so in theory should be slightly easier now 21.07.09 # should be a lot easier since everything's finally on the same baseline. 21.15.48 Quit ac_laptop (Ping timeout: 272 seconds) 21.25.52 Quit Moarc (Read error: Connection reset by peer) 21.25.53 Join Moarc_ [0] (~chujko@a105.net128.okay.pl) 21.37.45 # ooo..kay.. after all of this the damn zen vm target doesn't even work according to the wiki. 21.49.52 # Build Server message: New build round started. Revision 19d45c9, 291 builds, 10 clients. 21.51.01 # and this should resolve everything. 22.02.12 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 22.08.44 Quit Moarc_ (Quit: i znowu NADMUCHAƁ BALONA) 22.10.11 Join Moarc [0] (~chujko@a105.net128.okay.pl) 22.11.43 # Build Server message: Build round completed after 1311 seconds. 22.11.46 # Build Server message: Revision 19d45c9 result: 1 errors 0 warnings 22.25.41 # ok, that error is a typo in the buildserver's target list, will be resolved for the next build. 22.26.49 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 22.38.02 *** Saving seen data "./dancer.seen" 22.51.18 Quit Acou_Bass (Ping timeout: 260 seconds) 22.58.44 Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) 23.01.56 # speachy: please check your private messages 23.54.15 Quit [7] (Disconnected by services) 23.54.21 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)