Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2020-10-13

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:00
01:13:06 Quit ac_laptop (Ping timeout: 272 seconds)
02:00
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:00
03:18:23 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
03:58:28 Quit pamaury (Ping timeout: 260 seconds)
04:00
04:10:52braewoodsspeachy: 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:23braewoodsfor that matter why did they use center-negative barrel jacks?
04:11:34braewoodspretty 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:17braewoodsincidently i ended up ordering an inverter barrel jack cable
04:42:40braewoodsjust to deal with that problem where it's not practical to rewire existing cables to be center-negative
04:43:14braewoodsit's easier just to use an adapter that flips the wires
04:43:50gevaertsI'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:02braewoodsindeed.
04:44:26gevaertsMaybe if you heatshrink the connectors or something like that
04:44:42braewoodsi was planning to add some kind of label to the inverter cable
04:44:54braewoodssince it is only intended for some rare situations
04:45:42braewoodsi checked out the main device i wanted to modify
04:45:52braewoodsturns out it is soldered to the board so not very easy to rewire
04:46:12braewoodsi would rewire it to be center positive if i could
04:46:17braewoodsbut doesn't seem practical
04:46:34braewoodsit's easier just to use an inverter cable
04:46:36braewoodsbut you're right
04:46:41braewoodsit needs to be clearly labeled
04:46:46braewoodsat the very least
05:00
05:19:34 Quit S|h|a|w|n (Quit: Leaving)
05:47:20 Quit lemon_jesus (Ping timeout: 272 seconds)
06:00
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:43ulmutulbraewoods: I maintain the exact opposite: almost everything is center negative :)
06:26:10ulmutulThat applies to the 5mm barrel jacks; for smaller ones you are probably right (center positive).
06:26:41braewoodsulmutul: well my laptops from 2013 use center positive
06:26:49braewoodsthey use 7.5mm or so
06:27:11braewoodsi have an older arm box with 5.5mm 5v center positive barrel jack
06:27:11ulmutulE.g. all this guitar effect stuff is (and was) 9V/center positive.
06:27:18braewoodsI see.
06:27:35braewoodsi don't own such things so i guess that's why
06:28:56ulmutulSome 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:48braewoodsulmutul: i see. odd though considering generating inverted voltages is just a matter of flipping wires.
06:57:59braewoodsbut i guess crossing wires isn't always practical.
07:00
07:01:22speachybraewoods: 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:51ulmutulin 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:24speachyno, wait, bipolar is something else. ugh. not enough sleep.
07:21:01speachyanayway. 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:54speachy(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:17speachyBTW, the pine64 folks are proposing something based on the design of their PineCube −− https://wiki.pine64.org/index.php/PineCube
07:49:47speachyAllwinner V3 (ARM Cortex-A7 @ 1.2GHz, 128MB on-package RAM)
08:00
08:00:10speachyit probably would make a decent enough "hosted" port −− we'd have the full ability to control the base Linux layer.
08:00:27speachybut I'd really want to go native.
08:31:52speachyI 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:50braewoodslooks perfect to start with
08:42:59braewoodsit has more than needed but
08:43:22speachyit's mostly a matter of removing stuff we don't want.
08:43:33braewoodsor simply leaving it there unused
08:43:45speachyin the mean time it's a good dev platform
08:44:12braewoodsmore than enough RAM
08:44:30speachyaaand full schematics + source code. :)
08:44:45braewoodsGPIO could be used for buttons
08:45:11braewoodsthe networking bits could be removed
08:45:18braewoodssame with camera
08:45:39braewoodsusb is probably the only communication necessary
08:45:48braewoodsand it can be used to get a serial console and more
08:46:44speachywe'd need OTG
08:47:53speachyI 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:17speachysame SoC (albeit in different packaging and half the RAM)
08:48:53braewoodsspeachy: ah.
08:49:02braewoodswell usb OTG is probably a good idea to have anyway
08:49:12braewoodsit's something rockbox relies on
08:49:38braewoodseventually i'll look at MTP support work
08:49:45speachywell, 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:46braewoodsbut i suspect some ports simply won't work with it
08:49:53braewoodsdue to lacking hardware or so
08:50:31speachyanything 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:32braewoodsspeachy: sounds interesting. not sure what type of interfaces you'd want to do audio with.
08:50:37braewoodsUSB is an option i guess?
08:51:03speachythe pinecube uses teh SoC's internal audio codec, as does that "cherry pi".
08:51:12braewoodsoh, it has audio
08:51:29speachythe SoC supports i2s for external codecs too, naturally
08:51:39braewoodsare they any good?
08:51:42braewoodsi suspect cheap stuff
08:52:01braewoodswith a cpu this beefy we could just do all decoding in software
08:52:09braewoodsjust need good quality outputs?
08:52:15speachy(well, we already do all decoding in software)
08:52:19braewoodsOh.
08:52:21braewoodslol
08:52:53speachythe SoC has both internal headphone driver and a line-level output from its codec.
08:53:25speachythe pine64 speaker uses an external amp attached to the line out, whereas the "pi" is a straight headphone connection
08:54:11speachytbh I think that, with proper component isolation, the quality will be plenty good.
08:54:28speachy(eg don't cheap out on isolating capacitors and power supply filtering)
08:54:35braewoodsi see
08:54:45braewoodsit has bluetooth and wifi
08:54:55braewoodsof these only BT has any merit but rockbox has no BT stack
08:55:16speachyjust wifi, I think.
08:55:20braewoodshttps://www.pine64.org/cube/
08:55:37braewoodsinteresting.
08:56:17braewoodswell it would simplify the board if we strip out anything that isn't going to be used
08:56:52speachyI just don't see the bt stuff on the schematic obviously.
08:56:58speachythere is a dedicated uart for debug
08:57:23braewoodswe'd probably want to use u-boot...
08:57:35braewoodsor maybe not
08:57:40braewoodsa custom RB bootloader might work just as well
08:57:52braewoodsbut we'll probably be taking references from u-boot and linux
08:58:08speachyok, there it is, BT is uart-attached
09:00
09:01:45gevaertsDo 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:58speachyassuming this goes forward, step 1 would be to port rockbox-as-an-app to their base SDK platform.
09:02:25speachywell, this pine64 thing is $30 in single-uint quantities, including a camera and other crap.
09:02:51speachyI'd prefer an external codec too, but it's a tradeoff between form factor + battery life.
09:03:39speachyI'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:21speachybut the nice thing about this base platform is that it's easily extendable.
09:04:33speachyno reason we couldn't end up with more than one player at different size/pricepoints
09:05:19speachybut 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:27gevaertsRight. 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:28speachynew tooling is in the six digits range.
09:06:46 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
09:07:33gevaertsIf you only sell 50, 3d print it, but yes, that's the real issue these days
09:07:53speachythe case is the most expensive part, solely due to the NRE.
09:08:33speachydisplays are a plentiful and cheap commodity
09:09:13speachyand other than the actual SoC+PMIC (and possibly an external audio codec) there's little else of note.
09:10:03speachywell, biggest possible battery in the remaining volume, anyway..
09:11:50speachyanother price point −− that CherryPi thing is $17 in single-unit quantities. Obviously lacking a display, case, and battery.
09:13:21speachyif 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:40braewoodsand a platform that doesn't need to be reverse-engineered
09:14:43speachy(and that cherry pi thing has wifi too)
09:15:15braewoodsi assume sd card for storage
09:15:20speachythe SoC has full mainline linux support (except for the video encoder which we don't care about)
09:15:21braewoodsor would MMC be an option?
09:15:37speachyeMMC is an option, but we'd want external SD.
09:15:53braewoodshow fast would the SD cards be?
09:16:03braewoodsit would be nice if we could saturate USB
09:16:04braewoods2.0
09:16:23braewoodsoptional but nice if doable
09:16:28braewoodsthere's enough ram to buffer writes
09:16:30braewoodsso
09:16:32braewoodsit should be doable
09:16:45speachyit'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:46braewoodsif the physical hardware would otherwise allow it
09:16:59braewoodsand how fast can that be?
09:17:36braewoodshm.
09:17:41braewoodsah. the most common one i know
09:17:52braewoodslimited to 32G
09:18:02speachystandard SD is up to 25MHz @4bits == 100Mbit = 12.5 MB/s max
09:18:18braewoodsthat's fast enough i guess
09:18:18speachyUHS ups that to 100MHz (I think) ie 50MB/s.
09:18:30braewoodscomparable to existing native targets
09:18:52speachyUHS-1, that is. UHS-2 goes to 8 bit signaling (and a second row of pins on the card)
09:19:06braewoodsUHS-1 is fast enough
09:19:09gevaertsForget "limited to 32GB" That's a confused set of weirdness
09:19:26braewoodsgevaerts: i see. i know SD 2.0 specified that.
09:19:57speachyUHS-1 requires different (LVDS?) signaling across the pins; it's not just a higher clock speed.
09:20:22braewoodsah.
09:20:29gevaertsYes. 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:45braewoodsso unofficially it can go higher
09:21:10speachysuch is the decree of the SD Association.
09:21:31gevaertsThere's no native rockbox device with an SD card size limit of 32GB. Some have such a limit in the OF...
09:21:34speachygranted, SDXC got rid of that arbitrary limit.
09:22:18braewoodsmain reason to use SD cards is size constraints i guess
09:22:23braewoodsmain drawback is they tend to be slow
09:22:29speachythe only thing is that SDXC mandated exFAT.
09:22:35speachyand that required separate licensing from MS
09:22:46braewoodscan't we just have users reformat their cards?
09:22:50gevaertsWhich again should have been out of scope for the spec...
09:22:51speachyso when you see "32GB" max it usually means they can't handle exfat
09:23:04braewoodsi know FAT32 can go beyond 32G
09:23:15speachyand yes, one can always reformat the card.
09:23:59speachyand rockbox has several workarounds for not-quite-reformatted-properly SDXC cards.
09:25:01speachyanyway −− the addressing protocol of SD maxes out at 2TB. That's our acutal upper limit
09:25:12braewoodslol
09:25:27speachy(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:41braewoodsanyway
09:26:21braewoodsit's kinda interesting how they greatly expand the LBAs for PATA but i think only SATA really ever reached drives that massive
09:26:25braewoods48-bit LBA
09:26:47braewoodsnatively anyway
09:26:54speachyok, the S3/V3 SoC does not handle UHS signaling
09:27:02braewoodsso it's impossible
09:27:19braewoodsnot a big deal; only real benefit is faster IO, no?
09:27:46braewoodsjust would be nice to make syncing faster
09:27:49gevaertsIf 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:56braewoodslol
09:28:37braewoodsafaik we don't want to use the massive drives that earlier MP3 players used
09:28:46braewoodswant to use sd cards to limit how much space is needed
09:28:53speachyin practical terms the bottleneck in our file transfers is not the raw SD bus speed. our stack isn't the most efficient.
09:28:59braewoodsah.
09:29:00speachy(but it is small!)
09:29:14speachy(I think the bigger bottleneck is actually on the USB side)
09:29:26braewoodswe'd need to benchmark it
09:29:32braewoodsmight be possible to improve it
09:29:34braewoodsbut
09:29:46braewoodssome improvements may have to be gated for targets that don't have enough RAM
09:29:51speachySD 2.0 maxes out at 25MB/s, though it's not clear if that's with 4-bit or 8-bit signaling.
09:30:05braewoodsthat would be sufficient
09:30:08braewoodsbut how?
09:30:22braewoodsanyway
09:30:31speachyie dial the clock speed as high as the card claims to support and have at it
09:30:43braewoodsi would need to profile the existing stack to see what is slowing it down
09:30:47braewoodslack of buffering? etc
09:30:53speachythat's the raw bus bandwidth, not counting overhead and things like waiting for the card to actually perform writes
09:31:27speachybuffering, inefficient use of DMA, our multitasking/scheduling model..
09:31:57speachyhuh, there's now an SDUC that goes up to 128TB.
09:32:03braewoodsi may profile rockbox on a few devices
09:32:10braewoodsto see where time is spent when writing
09:32:22braewoodssee if i can improve it
09:32:39braewoodsbut OFC... it may not be practical
09:32:52braewoodseasiest avenue to explore is larger buffers
09:33:11braewoodsmight be viable for 32MB targets
09:33:12gevaertsThere'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:39braewoodsgevaerts: actually i was considering testing writing from directly in RB vs over USB
09:33:50braewoodsthough yes
09:33:58braewoodsthe direct writes should be more efficient
09:34:06gevaertsYes. I think you need all the numbers :)
09:34:08braewoodsno USB layer to go through (in theory)
09:34:28braewoodsi know enough about stuff now
09:34:32braewoodsi'll look into it later
09:34:37speachyalso keep in mind that those obscene speeds are only achievable during sequential access
09:34:40speachyespecially writes
09:34:50braewoodsprobably
09:34:51speachyand in mass storage we're jumping all over the place
09:34:54gevaertsIf 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:10braewoodsi just wish to see if i can find something that can be improved upon
09:35:28braewoodsif more caching could help
09:35:29speachythere's a lot of overhead to set up a transfer; the longer the actual transfer the less that overhead matters
09:35:30braewoodsthat might work
09:35:48braewoodsspeachy: indeed. i expect large files, like single file FLAC albums would be most efficient
09:35:50braewoodsto write
09:36:01braewoods300+ MB a pop
09:36:27speachythat's why for benchmarks I was bypassing filesystems altogetehr and just going for straight dd (with 64K blocks)
09:36:38speachyso no filesystem overhead to cause jumping around
09:36:47gevaertsIf 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:32braewoodsbbl
09:38:15speachy(and results will obviously vary from target to target)
09:47:22 Quit ulmutul (Ping timeout: 272 seconds)
10:00
10:02:47speachySo!
10:02:59speachytoday'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:00
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:03speachyah, 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:12johnb7speachy I ran battery bench on the x3ii: http://www.mediafire.com/folder/5qmycn43z1sew/batterybench_X3ii
11:16:53johnb7Am 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:19speachycorrect. I don't know if there are any appreciable differences with respect to the batteries.
11:22:33johnb7btw, 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:29speachy13:06, eh? booting into the OF afterwards, what was their view of the remaining life?
11:26:17johnb7see 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:29speachythe curve is definitely skewed high. the last 10% took >5h to drain. :)
11:30:45johnb7usually I use an mp3 album, but this time it was mpc. I didn't pay attention.
11:31:09speachythe absolute life doesn't matter so much as the percentages
11:31:14speachyin 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:32johnb7then how was the charging curve recorded for all the targets?
11:37:56speachy_bilgus_: do you still have the battery bench you did for the X3? I want to double-check something
11:38:35speachyhold down play when you plug in USB, it won't mount then.
11:40:02johnb7speaking 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:52speachyno idea, I haven't looked into that.
11:43:07speachydanke
11:46:30_bilgus_how to best measure that? probably a dummy load and voltage drop
11:47:20johnb7Basically, 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
12:00:28speachythe x3's audio (and power) paths are pretty poorly optimized
12:00:39speachyx3ii seems to be better in that regard
12:02:01fs-bluebotBuild Server message: New build round started. Revision e91f89a, 290 builds, 9 clients.
12:02:32speachyjohnb7: this build going now incorporates your benchmark run
12:03:13speachyincluding 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:12speachyinteresting, that 13 hour result matches xduoo's claims, but is about 3h longer than most reviews say things last.
12:11:22speachyI have the bench running on the hifiwalker h2 now, with a 1300mAh battery
12:12:24speachythey claim 30h (!)
12:14:04speachyafter 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:20fs-bluebotBuild Server message: Build round completed after 1218 seconds.
12:22:24fs-bluebotBuild Server message: Revision e91f89a result: All green
12:24:06speachyok, my builders are fixed.
12:26:36speachymaster build list updated to use gcc494 for everything
12:27:08fs-bluebotBuild Server message: New build round started. Revision b4865b0, 290 builds, 9 clients.
12:27:27speachyokay, it's going.
12:35:04speachyamiconn, 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:31speachyI don't know who runs the vm[12]-b0hoon builders, alas.
12:36:50Strife89Will do
12:37:51***Saving seen data "./dancer.seen"
12:39:36braewoodsspeachy: define "toolchain bump"?
12:39:53speachybraewoods: g#2305
12:39:55fs-bluebotGerrit 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:20braewoodsspeachy: ah. ok. you should probably make sure to include that flag for disable the null pointer optimization.
12:40:39speachyarm and m68k targets were still on gcc 4.4.4 and 4.5.2, respectively.
12:40:49braewoodsi think it was introduced in 4.9.x and was the source of some bugs
12:40:56braewoodsin linux kernel
12:41:28speachy(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:59braewoodsspeachy: may want to include this in CFLAGS for the 4.9.x toolchain
12:42:00braewoods-fno-delete-null-pointer-checks
12:42:20braewoodsi assume rockbox uses NULL and may appear to dereference it at times
12:42:30braewoodsi've seen kernel code do that
12:43:27braewoodsspeachy: i'd do the arm PP next
12:43:43braewoodsor so
12:43:52speachyarm PP was the main holdup for this
12:43:59braewoodsah.
12:44:03 Quit johnb7 (Quit: Nettalk6 - www.ntalk.de)
12:44:05braewoodsso m68k should be fine?
12:44:23braewoodsshould i recompile the bootloader with new toolchain? though i can't see any benefit to doing so
12:44:39speachytwo major issues; a bug in binutils causing linking issues and some technically-not-legal inline asm that no longer worked.
12:44:39braewoodsthe issue is fixed
12:45:05speachyif you don't have the ability to unbrick your ihp, I'd say no, don't rebuild the bootloader
12:45:11braewoodsindeed
12:45:15braewoodsi took a risk doing what i did
12:45:26braewoodsi wanted to do it before the toolchain updates
12:45:29braewoodsdue to the risks it carries
12:45:43speachyI was told (many moons ago) that the test builds I did for the ihp1xx worked with no issues.
12:46:15braewoodseither 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:27braewoodsindeed
12:46:37braewoodsif pre5 seems to work just fine and such
12:46:45braewoodsi'll do a 7 release
12:46:52braewoodsand we can try that to replace BL 6
12:48:13braewoodsbut i need to test it more
12:48:36braewoodsi intend to do 7 build on new toolchain
12:48:38braewoodsbut for now no
12:49:04braewoodsi'll see if i can go back to OF
12:49:13braewoodsso i can test it with OF as well
12:49:21speachy35 left..
12:51:34braewoodsmy 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:01speachyyes, but the bootloader is more likely to be um, abusing the C spec due to direct hardware or asm manipulation
12:52:18braewoodsi see.
12:52:20speachyI'm confident that the general firmware is fine.
12:52:39braewoodsso the ASM stuff could be borked?
12:52:43braewoodsis that what you're saying?
12:52:53speachythat's what I'd suspect the most.
12:53:04speachybut a good first pass would be to simply build it, and see if any warnings show up.
12:53:23braewoodshm
12:53:44braewoodsgcc 4.5... first released on 2010
12:53:54braewoodsso this isn't the same toolchain that build the previous bootloader
12:54:39speachyI don't know the history of the bootloader binary builds.
12:54:49braewoodsme either
12:54:57braewoodsi was just looking at the timestamps to get a rough idea
12:55:43speachylast one..
12:56:11fs-bluebotBuild Server message: Build round completed after 1743 seconds.
12:56:12fs-bluebotBuild Server message: Revision b4865b0 result: 122 errors 113 warnings
12:57:26speachywell, the only warning in the ihp boot code are some set-but-not-used variables
12:57:39braewoodstotally harmless
12:58:15braewoodsprobably time to just punch m68k out
12:58:26braewoodsso the toolchains are fairly synchronized
13:00
13:00:18speachylooks 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:47speachyit'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:52speachycould you look at g#2845 for me please?
13:28:53fs-bluebotGerrit 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:47fs-bluebotBuild Server message: New build round started. Revision ca32689, 290 builds, 9 clients.
13:38:23speachyok, 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:56speachyprobably only picked up because of the change to -Os
13:44:59speachyno, 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:16fs-bluebotGerrit 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:00speachyon the plus side... check out the binary size deltas!
13:57:35fs-bluebotBuild Server message: Build round completed after 1188 seconds.
13:57:36fs-bluebotBuild Server message: Revision ca32689 result: 115 errors 55 warnings
14:00
14:01:29_bilgus_yeah 70k+ deltas amazing
14:01:43_bilgus_hopefully not a sign of bugs :[
14:01:45speachythe 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:10speachy(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:48speachymost 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:00
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:02johnb7exit
15:37:25Strife89 /quit
15:37:53johnb7wrong focus ...
15:38:06 Quit johnb7 (Quit: Nettalk6 - www.ntalk.de)
15:42:04speachythe gigabeat-s/imx31 read is due to some horrid abuse of CPP, forward-declaring a function name inside a static initializer.
15:48:51fs-bluebotBuild Server message: New build round started. Revision b94db70, 290 builds, 8 clients.
15:51:48speachythat should knock out everything but the PP bootloader and the ZenVisionM.
15:57:40braewoodsspeachy: is m68k big or little endian?
15:57:44speachybig
15:57:49braewoodsfrom what i've seen big endian is a bit rare
15:57:54speachyit is now
15:57:54braewoodsah.
15:59:44braewoodsspeachy: kinda interesting though. i always thought big endian would take over but little endian did.
15:59:54speachyintel was cheeeeeep
16:00
16:00:06braewoodsbig endian is native byte order so i thought it would dominate in networking gear, etc
16:00:12braewoodssince, no need to byte swap as much.
16:00:15braewoodserr
16:00:18braewoodsnetwork 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:48fs-bluebotBuild Server message: Build round completed after 1435 seconds.
16:12:50fs-bluebotBuild 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:21braewoodsspeachy: they were? seems like intel is expensive these days
16:36:46braewoodsit 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:37speachybraewoods: think back three decades.
16:56:33speachyIBM went with intel for the PC because Motorla's 68K was much more expensive.
16:56:41speachy(four decades, really..)
16:56:49braewoodsthe 8088
16:57:08braewoodsso why did they pick that instead of the 6502?
16:57:17braewoodsbecause it was stuck at 16 bit memory?
16:57:27speachythe 8088 was _much_ more powerful than the 6502.
16:59:14speachy64
16:59:29braewoodsspeachy: was it painful to code for the original memory model? i vaguely recall it was using segments
16:59:33braewoods16 x 16
16:59:35braewoodsor so
16:59:44speachyyeah, segmented. and still supported to this day.
16:59:55braewoodsonly if running in 16 bit mode
16:59:59braewoodsno?
17:00
17:00:07speachybut still simpler than dealing with that much memory on a 6502
17:01:54braewoodsbecause 6502 required bank swapping?
17:03:30braewoodsnot to mention the method of switching and such were system specific
17:04:28speachyit's also even more register constrained than the 8086; native 8-bit instead of 16-bit.
17:04:33speachytoo, I mean
17:05:06braewoodsi think modern 32 bit CPUs even are far better to deal with
17:05:11braewoodsflat memory model FTW
17:05:29braewoodsi hate having to map memory around like that
17:05:35braewoodsi'd rather have it always mapped
17:05:47speachyyep. but memory used to be super expensive, so you neeed your code to be ultra-compact too.
17:06:10braewoods64 bit doesn't offer as much as the leap to 32 bit did
17:06:12speachycouldn't afford to waste 32 bits on memory addresses
17:07:05braewoodsand i can't see 128 bits being a thing anytime soon since the main driver of cpu jumps were all memory related
17:07:19braewoodsfor common cpus
17:07:21braewoodsanyway
17:07:27braewoodsspecialized ones are an exception
17:07:48speachy128-bit addressing, maybe not, but 128-bit ALUs are definitely a thing already
17:07:50 Quit lebellium (Quit: Leaving)
17:08:13braewoodsspeachy: in fact the 64 bit memory space only has 48 bits for physical memory in x86_64
17:08:23braewoodsbut that still leaves an insane amount of space for growth
17:08:55braewoodsconsumer PCs... the most i've ever had was 16G in a single system
17:09:09braewoodsthat only needs 34 bits
17:10:12braewoods... lol
17:10:20braewoodsfrom #learnprogramming
17:10:21braewoodsTheHermann | how improve my C?
17:10:33gevaertsThe 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:49braewoodsgevaerts: lol
17:11:03braewoodsbut there's like 0 benefit from having pointers that big
17:11:21gevaertsLet's all go back to the nice 4 bitness of the Z80 :)
17:12:41braewoodsgevaerts: no thanks. i don't want to use the appetizer of data processing.
17:12:43braewoodsLOL
17:13:01braewoodssince those are "nibbles"
17:13:19gevaertshttp://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html in case you weren't aware :)
17:15:46braewoodsgevaerts: looks like trivia.
17:16:11braewoodsto the users the difference is probably irrelevant beyond what it means for expectations
17:16:46mendelmunkisspeachy: is the new toolchain supposed to require gmp to build?
17:17:07gevaertsIt's trivia and fodder for people who like debating meaningless things
17:17:29braewoodsgevaerts: kinda like how C digraphs and trigraphs are trivia because no one really uses them
17:17:32speachymendelmunkis: I think so.
17:17:41braewoodsyou could write programs with them but no one does
17:18:11mendelmunkis can you give me a wiki account with my gerrit email so I can update the requirements page?
17:18:27braewoodsask speachy
17:18:30braewoodshe's the one who set me up
17:19:06speachygive me a few please
17:21:39mendelmunkisno problem
17:23:10speachyshould be an email waiting for you now
17:23:37mendelmunkisthanks
17:24:02braewoodsspeachy: bored? if so... a random detail i remembered.
17:24:12braewoodsspeachy: is this snippet defined behavior?
17:24:21speachyno.. still cleaning up the mess I made of the build board
17:24:31braewoodsspeachy: int x = 0; printf("%d %d %d\n", ++x, ++x, ++x);
17:25:15speachynow that's an interesting thing. probably going to be 3 3 3
17:25:25speachy(if not "implementation defined")
17:25:52braewoodsActually not
17:26:04braewoodsthe evaluation order of function arguments is implementation defined
17:26:14braewoodsso
17:26:16 Join ulmutul [0] (~ulmutul@dslb-146-060-189-092.146.060.pools.vodafone-ip.de)
17:26:24braewoodsif they involve side-effects or otherwise depend on the order
17:26:30braewoodsyou will get different behavior
17:26:53braewoodsyou'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:26braewoodstcc spits out 1 2 3
17:31:33 Join Oksana_ [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide)
17:31:48braewoodslol gcc spits out 3 3 3
17:32:20braewoodsclang does
17:32:22braewoods1 2 3
17:33:04braewoods0 1 2 for clang/tcc
17:33:08braewoods2 1 0 for gcc
17:33:11braewoodsif i switch to x++
17:33:35braewoodsright.
17:33:37braewoodsi remember now
17:33:45braewoodsclang does left to right
17:33:48braewoodsgcc does right to left
17:34:10 Nick mendelmunkis is now known as mendel_munkis (~mendelmun@ool-435680b7.dyn.optonline.net)
17:34:25mendel_munkisspeachy: err can you also add me to the wikiuser group?
17:35:19mendel_munkisalso is it worth updating the build VM now that WSL is a thing?
17:35:46speachythis PP bootloader build failure is quite wonky. seems to actually be a linker issue.
17:36:48speachymendel_munkis: done
17:37:40speachythe main reason for that VM was that our toolchains used to be finicky to build on more modern systems
17:38:01braewoodsspeachy: what's the log say?
17:38:14speachybraewoods: https://build.rockbox.org/shownewlog.cgi?rev=b94db70;type=gogearhdd6330boot
17:38:51speachyit's not picking up the __div0() that lives in lib/arm_support/support-arm.c
17:39:11speachybut only in the bootloader builds. the main build works like a champ.
17:42:10braewoodsspeachy: according to this... it's actually an ASM file?
17:47:20braewoodsspeachy: oh i see.
17:47:40braewoodsspeachy: anyway.. maybe you need to reorder the files for linking.
17:47:52braewoodsoddly I've known symbol references to disappear when you reorder the link stuff.
17:47:57braewoodsi mean
17:47:59braewoodsthe errors
17:49:21mendel_munkisso 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:00
18:06:25speachyI would personally. That can be cchanged when/if the VM is updated.
18:07:36speachyo..k... getting rid of -larm_support made it go away and link properly.
18:09:15braewoodswhat was __div0 supposed to do?
18:09:26speachyit's the divide-by-zero exception handler
18:09:56braewoodsI see.
18:09:58braewoodsRight.
18:10:19speachywhich 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:03speachyok, 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:00
19:03:30fs-bluebotBuild 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:48fs-bluebotBuild Server message: Build round completed after 1278 seconds.
19:24:50fs-bluebotBuild 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:00
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:13fs-bluebot_Build Server message: New build round started. Revision cddd8d6, 290 builds, 8 clients.
20:10:55Strife89"$ git pull / You are not currently on a branch." Ugh.
20:11:15speachy'git chekout master' :)
20:12:11Strife89Ah, thanks
20:13:24Strife89Now I can set my comp to work on building the newer toolchains
20:15:02 Quit MrZeus__ (Ping timeout: 246 seconds)
20:28:05fs-bluebot_Build Server message: Build round completed after 1073 seconds.
20:28:07fs-bluebot_Build Server message: Revision cddd8d6 result: 4 errors 1 warnings
20:29:49speachyexcellent. just one final oddity to sort out.
20:37:58***Saving seen data "./dancer.seen"
20:48:13speachythis final one is some sort of nested inline asm failure that only seems to trigger on this specific target.
20:52:06lonoxmontdo the new toolchains actually build now?
20:52:22speachyyes, but so did the old ones
20:52:25lonoxmonti know there was a long period where you either used the prebuilt ubunto vm with toolchain or got lucky
20:52:57lonoxmontat least i only ever got it to work on like 1 out of the 4 places i tried it
20:53:59speachyIIRC 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:19speachy(special snowflake developement system requirements really annoy me)
20:55:48lonoxmontah nice, might give it a whirl again then
20:57:04speachyI want to move to yet newer tooling, but just getting everyting dragged forward was a large enough hurdle.
21:00
21:01:17lonoxmontotoh you already did it once before so in theory should be slightly easier now
21:07:09speachyshould 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:45speachyooo..kay.. after all of this the damn zen vm target doesn't even work according to the wiki.
21:49:52fs-bluebot_Build Server message: New build round started. Revision 19d45c9, 291 builds, 10 clients.
21:51:01speachyand this should resolve everything.
22:00
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:43fs-bluebot_Build Server message: Build round completed after 1311 seconds.
22:11:46fs-bluebot_Build Server message: Revision 19d45c9 result: 1 errors 0 warnings
22:25:41speachyok, 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:00
23:01:56efqwspeachy: please check your private messages
23:54:15 Quit [7] (Disconnected by services)
23:54:21 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)

Previous day | Next day