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

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

Torne: i don't suppose any new ideas have occurred to you? is there some way we could just disable exception handling in libgcc entirely? gcc's configure doesn't really list much in the way of options...

soap, it is similiar to the LZMA algorithm, but is limited to a dictioary (max individual file size) of 4MB. This is ok, since .spc files are only 65KB. solid archiving first compares and compressed any identical data among a set of files as a master chunk, then any small differential data for each file and references to reconstitute it during extraction... I think?

Torne: it looks like non-EABI gcc uses a different relocation type for function calls than EABI. this is how binutils "knows" to only generate veneers for EABI. i wonder if just patching binutils to use the same handling for R_ARM_PC24 would suffice to get the stub calls without the other EABI baggage?

it looks like it's the gcc side that would need to change. there are actually two different relocations replacing R_ARM_PC24, depending on whether it's a jump or a function call, so binutils has to have gcc issue the correct one... i'm digging throught what -eabi changes now :/

Say I connect a c200 to the computer while running Rockbox - are there any files that get used that wouldn't be inside a rockbox.zip from a "normal" build? Like a bootloader or something? (I said e200 earlier, but meant c200)

hrm... is there a way to build structures in asm wich will use the packing and alignment specified by the ABI used by the C compiler? it would be nice if while i'm fixing asm broken by EABI packing changes i could arrange things so that we won't have such a problem the *next* time something like that changes...

uwill: Well the only recent commit that looks relevant is this one: 2009-07-01 00:34 r21582: Use the USB pid normally used by the OF when in UMS mode. This might make misbehaving pc software play nice. firmware/export/config-c200.h [diff]

4.3 is the oldest revision that can build EABI for arm9e... is there a reason we should be using arm9e rather than arm946e-s? it looks like all of the targets that use arm9e are actually arm946e-s, and i can't really see why more specific would not be better.

I'm not sure, but I think it is possible to compile C code into asm files with gcc. Now use it in a .c file that contains nothing but a global asm() block with the needed offsetof() values as parameters

core jpeg is as well. not offsets, so much, but both the C and asm versions of jpeg_idct*h write directly to the output buffer as an array of bytes, and pass it on as an array of uint8_rgb, so the size of that struct is important on color targets.

amiconn: how would you suggest going about creating a rule to build compile, but not assemble, a C file for later inclusion by an asm file? i guess we'd want to treat the output pretty much the same as a generated header file, like the bitmaps and such?

with Llorean stepped down, scorche|sh, Zagor, and LinusN are the only forum admins. scorche|sh you're the only one outside Llorean here - can we talk about why people's post counts don't increase depending on where they post?

amiconn: yes, gcc appears to forbid global asm statements from taking parameters... in fact, it appears to do so in a rather confusing and silly way, by having a different syntax for asm if used outside an expression, so you don't get a helpful error message like "global asm can't have inputs or outpus", just "expected ‘)’ before ‘:’ token"

kugel: but i'm thinking that a more general solution might be worthwhile, which would not require that we manually determine sizes and offsets for each abi for each struct or member where it's relevant.

i think that using gcc -S as a preprocessor is an acceptable solution, and the most flexible as well. and it should let us do the equivalent of strb r4, [r0, #(sizeof(pixel) )] ; strb r5 [r0, #(sizeof(pixel)*2)]; etc

so, we could do something like this: http://pastie.org/542255 but with the defines all included from a file that includes some headers, and defines a bunch of globals initialized to sizeof() and offsetof() various things.

will .equ assignments that are never used cause any trouble? one benefit of #define is that we *know* it won't cause a problem if the macro is never used, so we could conceivable put all of these definitions in one file if we wanted to...

yo guys. I just wanted to say thanks before I went to bed for how hopefull rockbox's site is and how much that everyone puts in it.. I'm downloading the datasheet and a toolchain I found for the STMP35XX. Hopefully get something running on my GoGear 3020 tommorow. Peace Out

the only thing is, I sometimes have to change my backlight brightness on my gigabeat depeding on the lightening conditions around me. Would be a bit silly to have to change the 2nd stage brightness as well.

What I'm thinking is basically to add the concept of a slow client (maybe initially defined as the 20% lowest bogomips clients, or maybe just a setting that's passed to the server?), and for slow clients start allocating from the other end of the build list

Sorting takes the number of times a build has been handed out into account, but the handoutbuilds function loops over all clients handing out builds doesn't re-sort the list in between, so the handed-out count will often be wrong near the end of the round

so I think it needs to be re-sorted for every client, and if we do that we could conceivably even have a totally different sorting order per client. That means we could do things like having a slow client class, a slowly-networked client class, and a fast class

You could extend the scheme to give priority to builds that are mentioned in the commit message, so if the real-time table updating gets done, you'll see results the targets you're especially interested in faster :)

funman: no. Download http://rockbox.hostname.be/pp.zip and use the bootloaders from there (those are the exact binaries that were tested). You need e200/PP5022.mi4 and c200/firmware.mi4 from that. sansapatcher versions are in the source, and are correct anyway

gevaerts: speaking of Macs... I couldn't connect my c250 recently to it in Rockbox USB while OF worked (went by "it appears automatically on the screen" since I don't know much about Macs and nobody was willing to help me find out more)

hrrmmm... there is a problem with the WPS context menu on long select when select is also used for a lot of button combos - you can make sure that it isn't triggered when holding select for too long if someone tries the combo by adding a BUTTON_REL but then you don't know if you already held sekect long enough for the context menu until you release the button... :\

kugel: am I right that the changes in that hunk mean "use actions from pluginlib_actions.h except for the 3rd gen Ipod" and the patch was just from before the addition of the Fuze pad etc. which now define their own? If those shall use the lib actions now too, I only need the IPOD_3G_exceptions, right?

Quick patch question... I want to create a patch for the SA9200 plugin keymap work I've done so far. What's a quick way of creating a diff of all of the files in apps/plugins without having to enter each and every single filename at the command line?

is one of the build system folks around? i think i need a bit of help with a rule for generated headers. they'd be generated from c source files, but the files in question will not be compiled and linked into rockbox. i guess i'd run a mkdepfile for these files, and there'd need to be some new expressions in mkdepfile to fix up the targets and dependcies for them?

kugel: People (even sansa users) can still find their music in the database. Maybe simply changing the default value for the existing setting to "all" on targets where the OF hides music is sensible though.

Also, I suspect that there might be a cleaner way to do some of the bits, but that needs more perl knowledge than I have. Can you put function pointers (or something like them) in one of those struct lookalikes?

Bagder: last night we had this big discussion about what to do with clients that are so slow that if they don't get a bootloader, they don't finish a build at all. Those were mostly what I had in mind. Upgrading them to "fast" isn't going to help much if a really fast build disappears

Zagor: Can you have a look at http://pastie.org/542424.txt? It's an attempt to support slow build clients usefully by having them get easy builds first, by sorting builds differently for different classes of clients

another "cracy" idea for the buildserver, would be to send the complete commands for all buildsteps (prepare="configure.." build="make" .. finish="make zip") from the server to the client. The it would be easy to adapt to build other things.. (ie rbutil for example).

gevaerts: true, it might be a bit dangerious. But maybe we could seperate the build steps into functions in the client, and just use another build function when the target is something like: "rbutil-w32" :-)

no, and I'm not sure about the best way to add it. A fixed list is not a good idea at all, just adding client names to a list whenever they don't finish a build despite being connected during the entire round works to build the list, but it risks having all clients in the list after a while...