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-29

00:16:59braewoodssuccess. i erased and reprogrammed the boot sector with the same contents.
00:17:04braewoodsWP# is not active.
00:17:44 Quit TheSeven (Ping timeout: 240 seconds)
00:18:25 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
00:29:13braewoodswell then
00:29:20braewoodsafter my latest commit is accepted...
00:29:33braewoodstime to review the bootloader flashing again
00:29:42braewoodsand then work up the courage to test it
00:29:54braewoodsthe main danger section
00:30:50braewoodsi'll do the second erase/reprogram test tomorrow, see if the bootloader can be reprogrammed through RB
00:40:19***Saving seen data "./dancer.seen"
00:44:42braewoodsspeachy: please approve g#2932 ? i tested it to ensure it is working.
00:44:43fs-bluebotGerrit review #2932 at : iriver_flash: rewrite how the flash commands wait for the ROM by James Buren
01:30:29fs-bluebotBuild Server message: New build round started. Revision f65e410, 293 builds, 8 clients.
01:31:38_bilgusyou knowit highlights him every time you do that right? I assume you've tested this by your statements but mark it next time and it flags em for review in gerrit
01:37:10_bilgusand I see you are already in the credits excellent
01:47:39_bilgusmendel_munkis, I'm gonna optimize your patch a bit
01:48:24mendel_munkisit slows it down?
01:52:13fs-bluebotBuild Server message: Build round completed after 1304 seconds.
01:52:15fs-bluebotBuild Server message: Revision f65e410 result: All green
01:53:01_bilgusstill building and testing whats here already but I can tell you what to do if you prefer
01:53:17mendel_munkisplease do.
01:55:54_bilgusso instead of checking the flip bits every time instead make it a function pointer prototype (void) lcd_write_fn(int x y w h) at top of file static this prototype lcd_write_function = (*int default function of prototype)
01:57:23_bilgusthen in update rect call it as (*lcd_write_fn)(x, y, w, h);
01:57:59_bilguswhen you get to the place where flip bits is set then you can set lcd_write_fn to the flipped write fn
01:58:00mendel_munkisah I wanted to be able to scale it up to two checks which would require four functions.
01:58:16_bilgusthats fine its still going to be faster
01:59:00_bilgusbut i'll test what you already have and give you whatever logs the test plugins spit out
01:59:41mendel_munkisinteresting. 3b75f987 (it's not in gerrit) is meant to remove warnings but causes them on my machine. does it make sense to standardize using large format specifiers and cast up in debugf and logf?
01:59:59_bilgusignore them
02:00:39mendel_munkisignoreing warnings is not a habit I want to get into.
02:00:44_bilgusits because there are several different printf functions in flight or something along those lines
02:01:04_bilgusthen dont run debugf and logf builds?
02:01:14mendel_munkisI thought it was because of word size on different machines.
02:02:25_bilgusdon't think so its been like 6 years since I investigated it and it was the fact some printf specifiers didn't exist or were cast because they didn't exist
02:03:22braewoodsmendel_munkis: it's rare for the basic types to vary in size. long and long long are exceptions though.
02:03:51mendel_munkisguess what types I tend to see the warnings on.
02:04:01mendel_munkislong and long long
02:04:11_bilgusI mean feel free to go through and alter the stuff to ifdef around the weird shit and remember you aren't supposed to chanmge code operation in debug builds either or just ignore it when debugf and logf builds are enabled
02:04:16braewoodsbecause long differs from 32 or 64 bits
02:04:26braewoodslong long is generally 64 bits even on 32 bit platforms
02:04:41braewoodsdepends how it's used.
02:04:44braewoodsif it's printf, easy fix.
02:04:51braewoodsspecify the right format for the size
02:05:18mendel_munkisthe problem is that ifferent machine seem to want different formats.
02:05:21_bilgusand then get into a low mem target that doesn't implement and oops
02:05:34braewoodsmendel_munkis: example?
02:06:07braewoods%ld for example is for "long int"
02:06:08mendel_munkisgit commit 3b75f987 he changed the specifier to remove a warning. this causes a warning on my build machine
02:06:27mendel_munkisspecificly %lx vs %x
02:06:56_bilguswe have no 64 bit machines do we? and who is he?
02:07:15braewoodslong will vary.. it's usually the longest native type.
02:07:25braewoodsit's equal to long long on most 64 bit targets i know of
02:07:34braewoodsint on most 32 bit targets
02:07:45mendel_munkisSebastian Leonhardt
02:07:47_bilguslong and int are = in 32 bit land
02:08:02braewoodsone exception is win64. it's a weird one.
02:08:10braewoodslong is 32 bit still
02:08:16_bilgusyeah I try to forgot about windows
02:08:27mendel_munkisI just knew i was seeing warnings every time i build a debug build.
02:08:31braewoodsbut why would that matter? the simulator?
02:09:12_bilgusthats the only place but we don't talk about fight i mean simulators
02:09:41braewoodsthe input is
02:10:03braewoodsso... why would it cause an error with... %x?
02:10:25braewoodsmendel_munkis: what's the warning you get?
02:10:47braewoods%x expects an unsigned int
02:10:47mendel_munkiswarning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=]
02:11:05mendel_munkisapparently my gcc thinks uint32_t is a long
02:11:14braewoodswhat's the target platform?
02:11:31braewoodsso you're generating code for fuze+?
02:11:37braewoodsnot simulator or w/e?
02:12:00braewoodsoh, right. i guess they're technically different types.
02:12:10braewoodseven if equivalent
02:12:26braewoodsbest solution is probably to cast it
02:12:30braewoodssuppress the stupid warning
02:12:38braewoodswe're not dealing with 64 bit types
02:12:44mendel_munkisthats what I was originally suggesting
02:13:02mendel_munkisi wasjust thinking of casting up instead of down.
02:13:17braewoodsfor that target it wouldn't really be any different
02:13:19mendel_munkisthis is the edge case where casting down shouldn't lode data
02:13:24braewoodsprintf kinda sucks for the stdint.h types
02:13:33braewoodsafaik it was never updated for proper support
02:13:34rudi_sThe proper solution would be to use the appropriate string constants from inttypes.h (if supported by the target).
02:13:42braewoodsthat exists?
02:14:10braewoodshuh. TIL.
02:14:29braewoodsbut wow is this ugly and hard to read.
02:14:48rudi_sYeah, but it works and is correct. PRIu32 for uint32_t
02:15:10braewoodsit's weird how size_t and ssize_t have printf formats but these do not
02:15:11mendel_munkisdoes our GCC support C99?
02:15:18braewoodsyes it does. C99 is really old.
02:16:54braewoodsmendel_munkis: this exploits a lesser known feature people tend to forget about. C compilers will concatenate string literals that are only separated by whitespace.
02:17:01braewoods"a" "b" => "ab"
02:17:47rudi_sAlso without whitespace "a""b" -> "ab"
02:18:10mendel_munkiswhat exploits that?
02:18:24rudi_sPRI* from inttypes.h
02:18:55rudi_sPRIu32 is just the appropriate printf string for the target architecture, e.g "lu" or similar
02:19:38_bilgusand stack ovfl at head for test viewports that will need to be investigated
02:19:46braewoodsmendel_munkis: it's used in advanced level CPP stuff.
02:20:02braewoodsmendel_munkis: i also use it for breaking strings across multiple lines. it's good for readability.
02:20:30mendel_munkisI was trying to figure why it relevant to the conversation. I understand how it's usefull.
02:20:39braewoodsnevermind then.
02:20:47mendel_munkisno worries. thanks for the ideas
02:20:58braewoodsthe macros exploit this feature
02:21:01braewoodsthat's why i mentioned it
02:21:08braewoodsotherwise they make no sense
02:21:33braewoodsbecause it's the only way to construct string literals at compile time
02:22:20braewoodsi've just never seen these before.
02:22:32braewoodsi just assumed there was no proper solution.
02:22:40braewoodssince i'd never seen it done in actual source code.
02:26:10mendel_munkis_bilgus: why *int not *(void)?
02:26:22rudi_sI think the reason why they haven't proper printf() formats is that size_t/ssize_t is part of the C language and uint32_t is only a typedef. And it means you're still compatible with "older" compilers because they don't need to learn the new format specs.
02:26:45rudi_sBut it's annoying.
02:26:49_bilgusmendel context?
02:26:52braewoodsrudi_s: size_t is still a typedef... it's not a builtin type.
02:27:02braewoodsthough moot point since it's included in stddef.h or so
02:27:31mendel_munkis you suggested doing lcd_write_function = (*int default function of prototype) at the top of the file
02:27:37braewoodsi suspect it's just there since it was there in ANSI C
02:27:39rudi_sBut the concept of size_t is defined in the language AFAIK. But yeah, I don't know the actual reason either.
02:28:37_bilgusoh sorry i was typing it on the fly itd be (void)(*fn)(int int int int)
02:28:57mendel_munkisalso why are there HAVE_LCD_FLIP ifdefs in the fuzeplus lcd driver
02:29:04mendel_munkisok. thank you
02:29:26_bilgusso you can take it out to see if its the issue
02:30:06_bilgusbut for god sakes don't go throwing them all over try to keep it contained
02:30:45_bilguslol daggers for the eyes i tell ya
02:40:21***No seen item changed, no save performed.
02:48:49_bilgusmendel looking at numbers we are down from a year a go probably mostly from the framebuffer patch
02:49:45_bilgusbut bad news the test fps plugin left weird artifacts and glitched rhythmically till finished unlike the broken main stuff
02:54:19mendel_munkishuh just ran it with g#2909 as the parent and it looks fine.
02:54:21fs-bluebotGerrit review #2909 at : Whitespace cleanup on fb_viewport Rewrite by William Wilgus
02:55:57_bilgusthats a ways back
02:56:31_bilgusmaybe something to do with the test_vp crash then
02:58:17mendel_munkisyeah. (that was the head when I was working) when it's upside I think there may be a single line artifact at the side of the screen nearest the power button but otherwise everything looks normal.
02:59:19_bilgusok I'll try to find that tomorrow then
02:59:39mendel_munkisI am rebuilding off of current head and will take a look.
02:59:52_bilgusit looks like it .5 fps slower after your patch whatever that means
03:00:17mendel_munkisit means it introduces a ngligable delay.
03:01:54mendel_munkisnope it still looks normal on my device after rebasing.
03:02:03mendel_munkisare you using a theme?
03:06:45_bilgusjust cabbie
03:07:02_bilgushmm thats odd
03:07:55mendel_munkisunless that square in the middle isn't meant to be there?
03:08:02_bilgusdoes test_viewport plugin crash?
03:08:50mendel_munkisStkov main
03:11:20_bilgusweirderstill then idk have to revisit once I get it right number are meaningless till then
03:13:22mendel_munkisI may have accidently fixed a bug while updating. maybe try patchset 3
03:13:36_bilgusits probably clear_viewport not taking into account a smaller buffer though its supposed to
03:24:42_bilguswell it crash and hard locked on this try so I guess thats it for tonight
03:38:18 Join petur [0] (
03:38:18 Quit petur (Changing host)
03:38:18 Join petur [0] (~petur@rockbox/developer/petur)
03:39:44 Join p3tur [0] (~petur@
03:39:44 Quit p3tur (Changing host)
03:39:44 Join p3tur [0] (~petur@rockbox/developer/petur)
03:43:03 Quit petur (Ping timeout: 268 seconds)
03:43:44edhelasthe latest build fixes all the issues I had on my iPod theme :)
04:06:38 Nick p3tur is now known as petur (~petur@rockbox/developer/petur)
04:40:22***Saving seen data "./dancer.seen"
05:15:34Airwave_bilgus: f65e410497 fixes the theme issue I had!
05:25:51wodzspeachy: Running wheezy in chroot on my laptop did the trick. I was able to debug bluez4 bt code with gdb and run it under valgrind. I am more or less ready to publish it somewhere. The missing part is rockbox UI, extension of crosscompile env to include dbus and glib and tweaks to link rockbox with thouse libs.
05:30:18 Join johnb3 [0] (
05:33:59 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
06:19:43 Quit livvy (Ping timeout: 240 seconds)
06:23:42 Join livvy [0] (~livvy@gateway/tor-sasl/livvy)
06:33:44 Quit pamaury (Ping timeout: 240 seconds)
06:40:24***Saving seen data "./dancer.seen"
06:45:44 Join prof_wolfff [0] (
07:04:47speachywodz: glad to hear it! bilgus is theoretically working on the UI side. so on the x-compile stuff, I guess we need to add it? should it be part of the "toolchain" vs part of the build?
07:05:22wodzI'd extend toolchain. Easy stuff.
07:17:05speachyok. just requires a bit of coordination with teh builders
07:24:14speachythe alsa template needs to be added as part of the filesystem patcher.. hopefully the OF doesn't blow it away
07:24:51speachythis is just audio, correct? no AVRCP (controls and metadata)?
07:29:29wodzspeachy: I coded just audiosink part of a2dp. Controls should be easy to add. Don't know about metadata.
07:36:14speachydo you remember the exact bluez and glib version we need to match what's on these things?
07:36:38speachyand dbus
07:49:05wodzspeachy: My notes about crosscompiling
07:49:26wodzspeachy: I don't think we need bluez to crosscompile. All interactions are through DBus
07:50:43wodzshould be easy to intergrate in
07:52:51speachyyep, I think so.
08:03:25 Quit johnb3 (Quit: Nettalk6 -
08:22:42 Join MrZeus_ [0] (~MrZeus@2a02:c7f:70d0:6a00:a0ce:6e20:7667:79ed)
08:30:47wodzspeachy: wodz/9048a3e411bfe473f938e0214d0b0ee6">
08:30:50 Quit Stanley00 (Remote host closed the connection)
08:40:27***Saving seen data "./dancer.seen"
08:41:20wodzspeachy: looks like bluez4 has very limited AVRCP capabilities
08:41:50speachylimited is better than none!
08:45:46speachyon glib now
08:52:19 Join massiveH [0] (
09:08:32speachy$%@#$ it's wanting aclocal-1.15
09:10:51wodzspeachy: dmesg says input: 80:C7:55:63:59:D6 as /devices/virtual/input/input2
09:11:12speachywodz: oooo, sweeet. :D
09:11:21wodzspeachy: so somehow it handles playback controls present in headset
09:13:02speachyok, our /dev/input/* poll code can't handle variable number of devices. but that's relatively easy to fix.
09:29:37 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
09:31:05 Quit Rower ()
09:41:43wodzspeachy: Interestingly /dev/input/event2 is created BUT org.bluez.Input.GetProperties on the device returns it is not connected and Connect returns Error org.bluez.Error.NotSupported
09:42:04wodzspeachy: bluez4 dbus api doesn't mention the possiblity of such error :P
09:45:41speachyfortuantely there are a ton of cheap bluetooth protocol analyzers these days.
09:57:36 Join Rower [0] (
10:06:35speachywodz: libffi is installing its headers into $sysroot/usr/lib/libffi-3.2.1/include
10:06:56speachydespite −−includedir=/usr/include on the ./configure invocation
10:07:15wodzspeachy: I know
10:07:59wodzee wait, newer version should have it fixed
10:18:20speachyit's still broken in 3.2.1; it's installed to 'includesdir' and that's fixed at '$(libdir)/@PACKAGE_NAME@-@PACKAGE_VERSION@/include'
10:18:45speachysimplest solution is to just create a symlink or something. :/
10:23:40wodzI think I simply moved the files
10:25:57wodzspeachy: It states issue is fixed
10:26:50speachywodz: it's certianly fixed in v3.3
10:27:17speachybut anyway. symlinked in the script now, time to see if glib shits another brick
10:28:46speachyok, it wants libelf too
10:31:16wodzhow is that it didn't want it here?
10:32:01speachy../../glib-2.46.2/gio/gresource-tool.c:32:20: fatal error: libelf.h: No such file or directory
10:32:47speachy(re-trying with 2.46.1)
10:33:39 Quit massiveH (Quit: Leaving)
10:36:50speachyyeah, same issue.
10:39:23 Quit livvy (Ping timeout: 240 seconds)
10:40:28***Saving seen data "./dancer.seen"
10:46:26 Join johnb3 [0] (
10:56:13speachyadding '−−disable-libelf' seems to be doing the trick.
10:56:23speachyI guess I had the libelf headers on my build system when you didn't.
11:03:05speachydbus is blowing up because it wants expat
11:05:39speachyconfigure: error: Explicitly requested expat but expat not found
11:13:20_bilgusHaven't started the UI yet still fixing the last of the fires
11:21:57braewoodskinda interesting. i think the most difficult to repair iriver supported by RB is the 5/6G H10
11:22:26braewoodswhy? it uses a hard to find battery type.. it's removeable though so you might be able to repair it with new cells or so. no idea how it is put together.
11:22:47braewoodsand the HDD interface is very unusual. there's no adapters to upgrade the capacity.
11:23:56_bilgus< edhelas, Airwave > Awesome, thanks for testing!
11:27:08_bilgusHA the build I replaced on the fuze+ while testing the lcd was almost to the day exactly a year ago
11:29:10_bilgusthe lcd functions are up to 30% slower as well
11:29:27_bilgussome of that for sure changing the vp code
11:34:46speachy@!^% dbus is still trying to use x11
11:37:40speachyokay! got it finally. now for a full end-end build
11:40:58braewoodsspeachy: i did some research for the H300... there's two strategies i could use for embedding RB in ROM. it needs about 1.2MB for both images right now. the OF leaves 1.48MB unused between the bootloader region we use and the end of the OF
11:41:11braewoodsso it could conceivably fit in the unused space
11:41:24braewoodsbut the H100 doesn't allow co-existence due to space limitations
11:41:31braewoodswhat do you think i should go for?
11:42:04braewoodsthe same strategy for the H300 would mean more space for RB
11:42:31speachyI'd not bother trying to coexist.
11:42:43braewoodsme too. ok. i'll keep same approach.
11:42:51braewoodsto maintain behavior across ports.
11:43:27braewoodsi can't see the RB core becoming close to 2MB though
11:43:41braewoodsbut i split up the address space so it can use the full rom space
11:44:24braewoodsafter i successfully boot the current BL, i'll need to test its existing features to see what work is left
11:44:42braewoodsmain thing i know to implement is support for booting RB from ROM/RAM like the H1x0 bootloader does
11:46:31_bilgusbraewoods, If you start running out of room for your bootloader two options another bootstrap layer or see what can be discarded/pared from the bootloader side
11:47:05_bilgusI fear theres very little left to get rid of but maybe that device will be less demanding
11:47:05speachywodz: g#2935
11:47:08fs-bluebotGerrit review #2935 at : WIP: Add libraries to native MIPS toolchain to enable bluetooth by Solomon Peachy
11:47:47_bilgusso this puts the backend in so excited I might just put it at the front of my list
12:05:07braewoods_bilgus: existing one fits just fine for the H100.. i don't think space is a concern.
12:05:12braewoodsi've got 10k to work with.
12:05:24braewoodsbut we'll see
12:05:36braewoodsyou also saved a ton of space with the printf strip down
12:06:02braewoodsthe H100/H300 bootloaders to date have used the last 64K of the ROM
12:06:07braewoodsso that's what i intend to work around
12:06:14braewoodssince changing the location now would be difficult
12:06:33braewoodsand not much point in it if the bootloader still fits
12:16:14 Quit pamaury (Ping timeout: 272 seconds)
12:16:41speachywodz: when I try to launch it, I get: Discovering
12:16:46speachyDiscovering : 1
12:16:50speachySegmentation fault
12:33:25speachysomewhere within g_main_loop_run(loop)
12:34:08speachyit leaves adapter_property_value_changed(), and goes boom.
12:35:52mendel_munkisbilgus: you said that patchset 2 on 2928 was .5 fps slower?
12:36:08mendel_munkisbecause I'm testing patchset 3 at .6 fps slower
12:39:17mendel_munkisnever mind that. today my DD build is running at the same speed.
12:40:29***Saving seen data "./dancer.seen"
12:40:51edhelas_bilgus what is the final goal of this theme/ui refactoring ? mostly to cleanup the code or is there some glitches/performances issues fixes involved ?
12:46:24 Join p3tur [0] (~petur@rockbox/developer/petur)
12:49:27speachyedhelas: It started out as some bug/glitch hunting, and became a bit more along the way.
12:50:11_bilgusedhelas, first goal get it working right OFC after that I plan to rip out most of the custom implementations in the plugins
12:50:23_bilgusand finally expansion
12:50:26 Quit MrZeus_ (Ping timeout: 264 seconds)
12:50:39 Quit petur (Ping timeout: 268 seconds)
12:51:13_bilguscore was tied to screen width buffers its now able to handle any buffer
12:58:54_bilgusand performance nah but once right I'll try to optimize so its onlt 10-15% hit on lcd functions
13:02:50mendel_munkisbilgus: did you figure out why it was glitching on your machine?
13:03:01_bilgusmendel_munkis, between runs testing tends to bounce a bit, mostly true for anything doing multitasking of some sort
13:03:17_bilgusNo I won't get back to it till tongiht
13:03:24braewoods_bilgus: so why did you trade performance away?
13:03:59braewoodsin either case, each port's screen dimensions are fixed
13:04:03braewoodsthough they differ
13:04:08_bilgusI didn't but I'm not going to optimize till everything works PROPERLY
13:04:13speachybraewoods: I think folks tend to prefer glitch-free displays (and no crashing) over raw speed!
13:04:38mendel_munkisbraewoods: bear in mind that runninga variation of head I am getting over 60 fps
13:04:57mendel_munkis speedis only important up to a certain point
13:05:08speachysome of the stuff I fixed in that trap/udf hunt was of the "WTF did this never crash before?" variety.
13:05:30braewoods_bilgus: i'm reminded of this whenever someone says "exactly":
13:05:34_bilguspeople have kept trying to squeeze every performance for years and left a unmaintainable mess in places
13:05:57_bilguslove dilbert
13:06:15speachyplus abandoning support for the original Archos player and its charcell screen let us scrap some API choices.
13:06:29*_bilgus is loving that
13:06:32 Join wodz_home [0] (
13:06:46_bilgusa lot of ugly just POOF
13:07:01wodz_homespeachy: Lovely. g_main_loop_run(loop) is glib function :-)
13:07:53speachy...which shouldn't be doing anything other than sleeping waiting for events...
13:10:07speachyeven if I botched the cross compiled library somehow, it's actually running on the original.
13:10:45wodz_homespeachy: Interesting thing is I tested this on my agptek and on chroot with wheezy on my laptop.
13:10:50speachythough now that I think about it, I'm actually running this on an ErosQ, which might not have the exact same versions of everything.
13:11:34wodz_homespeachy: Are there update images available for ErosQ so I could look?
13:11:45speachynope, libdbus 1.10.2
13:12:07speachywodz_home: there's a patched one sitting on d.r.o/bootloaders/aigo
13:12:43wodz_homespeachy: Maybe I'll find some time and look into this
13:13:24 Quit wodz_home (Quit: Leaving)
13:18:02 Join MrZeus_ [0] (~MrZeus@2a02:c7f:70d0:6a00:a0ce:6e20:7667:79ed)
13:59:07 Quit p3tur (Quit: Connection reset by beer)
14:04:51 Join lebellium [0] (
14:08:47 Join amiconn_ [0] (jens@rockbox/developer/amiconn)
14:08:47 Nick amiconn is now known as Guest51137 (jens@rockbox/developer/amiconn)
14:08:47 Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn)
14:09:36 Join pixelma_ [0] (marianne@rockbox/staff/pixelma)
14:09:37 Nick pixelma is now known as Guest93120 (marianne@rockbox/staff/pixelma)
14:09:37 Nick pixelma_ is now known as pixelma (marianne@rockbox/staff/pixelma)
14:10:04 Quit Guest51137 (Ping timeout: 240 seconds)
14:10:05 Quit Guest93120 (Ping timeout: 240 seconds)
14:26:50 Quit johnb3 (Quit: Nettalk6 -
14:40:30***Saving seen data "./dancer.seen"
14:44:00 Join Misanthropos [0] (~Misanthro@
15:36:25braewoodsok... confirmed that the H320 flash rom can be reprogrammed in 3 key areas
15:36:41braewoodsso there's no WP to worry about.
15:36:44braewoodshw wise
16:01:56 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
16:08:24braewoodsit seems in theory the iAudio and MPIO coldfire ports could also support boot from rom but
16:08:28braewoodsthey're so rare
16:08:43braewoodssupporting them is probably impractical even if possible
16:08:49braewoodsplus their OFs don't seem to care about CF cards
16:09:06braewoodsit's mainly the H100 and H300 series that benefits from complete OF replacement
16:09:23braewoodssince the OF is worthless if you want to upgrade your storage to flash
16:09:56 Join b0hoon [0] (3e57ec73@
16:12:13b0hoonspeachy: hi. something is wrong with after last update. The build dirs stay and my vms refuse to build because of free space on disk.
16:13:19speachyb0hoon: oh yuck. okay, I see it on mine too.
16:13:42speachyfixed one bug and broke something else
16:14:42speachythe basic problem is that the master process was nuking the slave/builder process before the slave had finished uploading things, causing wasted build rounds.
16:15:58speachyI moved the cleanup out of the master, into the slave process. What I think is happening now is that when a build is cancelled, the slave is killed outright so nothing cleans up the leftover.
16:16:16 Quit vvrng (Ping timeout: 256 seconds)
16:18:00b0hoonso additional code. master should check if slave lives, and rm the dir?
16:18:48speachyohwait, it's not removing the dir at all due to $CWD being in the wrong place.
16:20:02speachyand upon cancel it is cleaning up properly.
16:20:07speachyokay, I'll push this out in a few.
16:20:36b0hoonspeachy: thanks
16:20:57speachythanks for the report. I have oodles fo space on my builders so I'd have never noticed
16:21:38b0hoonnp. i have vds set up as 50GB
16:21:59speachyokay, updated on the master, and the next build will push out an updated client.
16:25:34 Part b0hoon
16:30:49speachy8.2, 12, and 25GB of build-* dirs on my builders, yowch.
16:31:24 Quit Rower (Ping timeout: 256 seconds)
16:32:24 Quit MrZeus_ (Read error: Connection reset by peer)
16:32:48 Join MrZeus_ [0] (~MrZeus@2a02:c7f:70d0:6a00:a0ce:6e20:7667:79ed)
16:40:35***Saving seen data "./dancer.seen"
16:41:54fs-bluebotBuild Server message: New build round started. Revision 96f82f8, 293 builds, 8 clients.
16:57:19fs-bluebotBuild Server message: Build round completed after 924 seconds.
16:57:26fs-bluebotBuild Server message: Revision 96f82f8 result: All green
17:13:45 Quit mendel_munkis (Ping timeout: 240 seconds)
17:16:51 Join mendel_munkis [0] (
17:17:44 Quit prof_wolfff (Ping timeout: 240 seconds)
17:40:28braewoodsnext change, g#2936
17:40:30fs-bluebotGerrit review #2936 at : iriver_flash: revise cfi_read_id and cfi_get_flash_info by James Buren
17:41:06braewoodsand tested on both H320 and H120
17:41:13braewoodsboth are detected correctly
17:52:07 Join ubervison [0] (~ubervison@2a02:aa12:b106:1b80:4978:337a:24bd:4bbc)
17:52:22 Quit ubervison (Remote host closed the connection)
17:52:44 Join ubervison [0] (~ubervison@2a02:aa12:b106:1b80:4978:337a:24bd:4bbc)
18:02:39 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
18:07:50 Quit Stanley00 (Ping timeout: 264 seconds)
18:40:36***Saving seen data "./dancer.seen"
18:46:04_bilgusbraewoods, couple comments on your commit
18:50:12_bilgusfirst one you ignore I see it in the commit message second one though just for clarity won't even need a comment
18:53:08braewoods_bilgus: i think the parts i removed were from some ARCH code since those ROM chips were used in them.
18:53:18 Quit lebellium (Quit: Leaving)
18:56:41_bilgusoh yeah quite possible
18:58:05braewoods_bilgus: done with the revisions i think?
18:58:46braewoodsnote the removed ones were all less than 1MiB
18:59:00braewoodsand that's below what the H120 and H100 even supported
18:59:13braewoodsthey're not even useful for this plugin
18:59:24braewoodsplus they were used in, as you said, removed targets
19:00:02braewoodsSST SST39VF020
19:00:32braewoodsall arch devices i believe
19:01:52fs-bluebotBuild Server message: New build round started. Revision f1bfbb5, 293 builds, 8 clients.
19:02:04_bilgusthere ya go
19:02:55braewoodsspeachy: i found some more SH references. decompressor/ and apps/plugins/chessbox/chessbox.make
19:03:10braewoodsi mean
19:04:11braewoods_bilgus: i was reading in the m68k docs... apparently they do tolerate misaligned instructions but there's a performance penalty.
19:04:27braewoodsbut i can't see that being a problem in RB. GCC is supposed to take care of that.
19:04:37braewoodsonly maybe in raw ASM
19:04:48_bilguswe run into it on occasion
19:05:06_bilgusmy last one was arm in the buflib
19:05:15braewoodswhat's ARM d?
19:05:21 Join prof_wolfff [0] (
19:05:26braewoodssome architectures have no tolerance for it
19:05:36braewoodsothers just suffer performance penalty
19:05:46_bilgustalk about a hard to find bug, arm has none I think its on 4b
19:06:03braewoodsinteresting thing i found when i was revising the flash code
19:06:16braewoodsthe structure had to introduce padding to align the 32 bit field
19:06:24braewoodsso my changes to it aren't using any more memory
19:06:30braewoodsjust using the space that used to go to padding
19:06:45_bilgusyeah I like wehn reordering structs get you free space
19:07:07braewoodsGCC does have -Wpadded but that's probably better in more recent versions
19:07:15braewoodsbut for some structs you're stuck with it
19:07:22_bilgusbut TBH plugins are memory constrained to a point but there is enough to afford to waste some on most targets
19:08:03braewoodsideally you would arrange fields by size
19:08:11braewoodsbut that's tricky in C at times due to platform differences
19:08:55speachybraewoods: arm<v5 can't handle unaligned instructions or data.
19:09:09braewoodsprobably for the best
19:09:10speachyarmv6 can handle it (via OS-level trap handler)
19:09:17braewoodsin general you don't want that.
19:09:23speachyarmv7 can handle it fine (with a penalty)
19:09:36_bilgusI don't think you'll run into differing sizes for the data types in this codebase
19:09:48braewoodsi mainly ran into it when writing code for desktop Linux
19:09:51_bilgusor at least I haven't yet
19:10:18_bilgusI must say I prefer arm ASM over x86 and mips
19:10:25braewoods_bilgus: another random trivia. is the signedness of char always the same?
19:11:00speachybraewoods: wrt sh references, make a note of 'em please, I don't have the bandwdith to deal with them tonight.
19:11:02_bilguson everything I have touched yes but its no guarantee AFAIK
19:11:07braewoodsspeachy: ok
19:11:26braewoods_bilgus: correct. the standard says this is implementation defined.
19:11:33braewoodsx86 linux? it's signed. arm Linux? It's unsigned.
19:12:26braewoodsit's why you should use cast to unsigned at times if you really intend it to be treated as an array of bytes
19:12:39braewoodsthere's only a few cases i can think of where the signedness is irrelevant
19:13:13braewoodse.g., copying the bytes as is
19:13:40braewoodsmost bitwise operations (shifts...)
19:14:00braewoodsjust another trivia i've learned
19:14:09braewoodsi was surprised it isn't defined
19:14:19braewoodswhile all other integer types default to signed
19:14:34_bilgusok so the crash for test_viewports.rock is due to the small buffer I bet the font size is larger than the vp
19:18:22fs-bluebotBuild Server message: Build round completed after 990 seconds.
19:18:25fs-bluebotBuild Server message: Revision f1bfbb5 result: All green
19:27:32 Quit prof_wolfff (Ping timeout: 272 seconds)
19:27:41_bilgushey hey worked a treat
19:29:49braewoodsnext i'm going to consolidate the checksum algorithms.
19:29:57braewoodsthe same algorithm is used 3 times in this program.
19:35:11 Quit pamaury (Ping timeout: 268 seconds)
19:36:53braewoods_bilgus: does RB implement memcmp?
19:37:06braewoodsand yes it does
19:37:34braewoodson second thought
19:37:47braewoodsdirect memory comparison is better than checksums... but the firmware loader still needs that
19:38:15braewoodsok. different approach.
19:39:50_bilgusbraewoods, have a look at plugins.h it doesn't have everything but most of what is implemented
19:40:02braewoods_bilgus: yea i see it.
19:40:13braewoodsi just realize the people who wrote this originally reinvented memcmp in a few places
19:40:19_bilgusI pretty much have it open any time I'm doing a plugin
19:40:41braewoodsif you're just doing byte by byte comparisons
19:40:48braewoodsthen memcmp is usually more optimized
19:43:18Airwave_bilgus: No problem, thanks for fixing!
19:44:26AirwaveOnly remaining UI issue I have that's popped up recently is that the top bar shows 10x the dB value that the settings menu does, e.g. if the settings menu says 40.5 dB, then top bar says 405 dB. Minor issue though.
19:52:10_bilgusI thought speachy fixed that?
19:56:57speachyyeah.. thought I fixed that.
19:58:44speachywill double-check
20:00:35_bilgushmm puts_scroll will happily overflow buffers I should probably make it aware of the new fb stuff
20:03:15 Quit genevino (Quit: Great minds discuss ideas. Average minds discuss events. Small minds discuss people.)
20:03:29speachyit appears to work on the x3ii (which has the same volume config key crap as the rocker)
20:10:34fs-bluebotBuild Server message: New build round started. Revision 44023eb, 293 builds, 8 clients.
20:11:40speachyAirwave: it seems to work for me, but the build going now fixes the volume adjustment from within list context to respect to the hw step size.
20:24:58Airwavespeachy: Okay, I'll try it out when it finishes building
20:26:28fs-bluebotBuild Server message: Build round completed after 953 seconds.
20:26:30fs-bluebotBuild Server message: Revision 44023eb result: All green
20:26:54fs-bluebotBuild Server message: New build round started. Revision 07fcced, 293 builds, 8 clients.
20:36:16braewoods g#2937
20:36:18fs-bluebotGerrit review #2937 at : iriver_flash: revise load_firmware_file function by James Buren
20:36:40braewoodstested as well
20:39:13Airwavespeachy: Issue is still present in 44023eb
20:39:44 Join fs-bluebot_ [0] (
20:40:28 Quit bluebrother (Disconnected by services)
20:40:33 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother)
20:40:37***Saving seen data "./dancer.seen"
20:40:57 Quit rogeliodh (Quit: The Lounge -
20:41:37 Join rogeliodh [0] (
20:41:45_bilguscan't see it in cabbie but can in that theme from lebellium
20:41:52 Quit fs-bluebot (Ping timeout: 246 seconds)
20:55:45_bilgusprobably just a spacing issue
20:56:05_bilgusits probably set up for 2 digits
20:57:54_bilgusnope that was just a straight bug in the scrolling function
20:58:56_bilgusit just got covered up because it just wrote outside the vp to the framebuffer I imagine scrolling lines at end of screen would have crashed in the old code
20:59:25_bilgusProbably still a few more of these lurking
21:01:08AirwaveHuh interesting
21:07:25speachyAirwave: I was able to recreate it on the X3ii, which led to my original fix. I don't know why it's not displaying correctly on the Rocker.
21:09:33AirwaveHow odd
21:11:07speachyyeah, uisim does its own thing wrt sound settings, can't use that.
21:29:26 Quit MrZeus_ (Ping timeout: 264 seconds)
21:33:34speachy_bilgus: are you able to trigger the volume wonkiness?
21:50:33 Quit Tsesarevich (Write error: Connection reset by peer)
21:50:57 Join Tsesarevich [0] (Tsesarevic@fluxbuntu/founder/joejaxx)
21:59:24_bilguson yesterdays version I've got something i'm working on atm but i'll investigate next
22:09:48 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156)
22:30:41braewoodsok. that's enough for now. i'll wait for review.
22:36:29 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
22:40:40***Saving seen data "./dancer.seen"
23:24:27 Quit Stanley00 (Read error: Connection reset by peer)
23:24:55 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
23:39:26 Quit Stanley00 (Read error: Connection reset by peer)
23:39:56 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
23:53:38 Join Stanley|00 [0] (~stanley00@unaffiliated/stanley00)
23:55:09 Join Stanley00_ [0] (~stanley00@unaffiliated/stanley00)
23:57:16 Quit Stanley00 (Ping timeout: 268 seconds)
23:58:24 Quit Stanley|00 (Ping timeout: 240 seconds)

Previous day | Next day