Its the samsung open source kernel for the r0. Which is version 2.6.24 build with arm-none-liinux-gnueabi gcc 4.2.0. Flags are
-Mcpu=arm1176jzf-s -march=armv6z -mfpu=vfp

we can recompile the kernel and i will make a rom with new kernel but i need to get standby issue solved first. I'll prolly contact samsung again in case i dont get it to work.but i got it working before. This is so frustrating :-(

I hope slade and I can clean up the wiki of our project server during the next days and make it public so you guys can contribute more easily.

When will you open the wiki? I'm very curious about the various issues you had to face, and how you worked around them. And will you create a step-by-step guide about how to create a custom firmware (without bricking the device like I did) ?

I think I understood why I bricked my R0 (I mixed the Samsung open-source firmware and the 1.24 that I downloaded previously), but I need to be sure not to brick my device again on my next try...

The thing is in France we are lazy and we often twiddle our thumbs but bear in mind in Germany they are more serious and work harder. Yet, Slade has a lot of work to do at school and that's probably why he doesn't keep us updated everyday

well advantages custom kernel is a bit faster, but as the screen goes off the player hangs and needs to be reset to boot it again. It works fine and doesnt have the bug when connected to external power supply.
another advantage would be already set up libsdl video support in the kernel.

well advantages custom kernel is a bit faster, but as the screen goes off the player hangs and needs to be reset to boot it again. It works fine and doesnt have the bug when connected to external power supply.

uhm which bug? The one that when you plug out the power source it'll reset itself (at least completely turn off)...or that it seems that the charging doesn't happen while playing?

First of all I want to thank you all for your efforts of making the world a better place... Er... For making our device even better.

Now to the ground... What I need is to change player configuration so it is represented as a single removable drive instead of two (1st - internal flash; 2nd - micro-sd). Is it possible with what we already know about the device?

Pavel.

P.S. (Rationale) My in-car multimedia can't "see" devices which export two or more partitions. It can't see non-fat partitions either but it's another story...
P.P.S. (Complete off-topic) Speaking of cars - does anyone by any chance know what software is used in modern Nissan vehicles?

Now to the ground... What I need is to change player configuration so it is represented as a single removable drive instead of two (1st - internal flash; 2nd - micro-sd). Is it possible with what we already know about the device?

Yes, I imagine it would be possible, using AUFS or UnionFS... But I don't dare to modify my firmware since I last bricked it. I watched in the firmware sources, and the USB mount seems to be done using a simple script, which seems easy to modify to add AUFS support. But I don't know how difficult/dangerous it is to compile a new kernel module.

Slade, do you think it would be easy to add AUFS/unionFS support to the current firmware?

EDIT: Hmm... I watched the USB script again, and it seems that it is not the one we should modify. It uses gadgetfs, and I don't think gadgetfs can be used in combination with aufs. But maybe we should try to change the boot scripts so that the microSD is seen as being part of the main memory at boot. The library updater would automatically add the music files from the microSD to the library, and these files would directly be playable on the device's "Music" application. It would be more difficult to implement, but very useful: it is very boring that the microSD acts as a standalone mass storage unit...

we were trying that already but it seems samsung rfs nand layer blocks the microsd until a magic code unlocks it which is currently done by the r0 app.
the issue we have is the rfs layer inbetween kernel und filesystem blocking mounting. i am currently trying to switch the entire player to ext2 and hope to get the images mounting.

for the port we are still trying to figure out how to enable the vpu and ipu of the device to get access to framebuffer without r0 app unlocking it.

I'm already thinking about upgrading the radio/cd-player in my car for the glorious YP-R0... Probably gonna solder an audio cable to it as soon as I can get that damn thing out of my car's dashboard.

By the way... GO, GUYS! *shakes pompons made out of cables*

__________________
In my experience, guys like tech-savvy girls. At least till the girl finds their fantasy-named account in a social network, just having known one of the guy's interests. Then it's suddenly considered stalking....

another option would be to block micro-sd from mounting - at least i could live with that for now

What would this do ? (sorry I'm not techy). I suppose that what we want is that the micro SD card library be merged with the main library and that when we turn the player back on that it continues from the last song played - be it from the card or the main library (which is not the case with the card.)

yes it would be possible to integrate the micro sd once we get it working (at least i hope so).

i am also doing some work to get rid of the player bricking if library update doesnt work. the only solution i have found so far is to delete the entire music folder if it hangs. so you will lose you music but hey at least not bricked right ? if lebellium still has some bricking mp3's i'll be happy to try to write the script in order to check if library does not update and then delete the music.