Cowon D2

[Dicky Dave]

EDIT: This version should work for you, it's v3.57 patched with a modified bootloader.

Thanks shotofadds I got it to boot now. I tried to play some OGG files but no matter what file I choose I keep getting "Error accessing playlist control file" which no one else seems to have reported. Looking at the code it seems like it is failing to create a file, perhaps the 'Now playing' playlist file? I know writing to the internal memory is not yet supported so I would expect this to fail. Perhaps my tracks are failing to play for some other reason.

[shotofadds]

Dave,

The "playlist control file" error will always come up at the moment - don't worry about it. There is currently a problem where music does not begin playing until the buffer is filled, wait up to 10 seconds and it should start.

[Dicky Dave]

I could have sworn I waited at least 10 seconds for it play. Perhaps I pressed some buttons or something. Thanks shotofadds, I now have sound and will have a play with RB.

I have also set up my dev environment. I would like to help out the cause but like all RB developers I am time poor so I cannot promise anything. What areas of the codebase would you suggest I start familiarising myself with to best lend a hand?

[shotofadds]

I have also set up my dev environment. I would like to help out the cause but like all RB developers I am time poor so I cannot promise anything. What areas of the codebase would you suggest I start familiarising myself with to best lend a hand?

That's actually quite a hard question to answer. The stock answer is usually "have a tinker with one of the plugins and see how you get on", but it all depends on what you want to do.

Bear in mind that the vast majority of Rockbox is common to all models, so it might be a good idea to familiarise yourself with things like the split between apps/ code and firmware/ or firmware/target code. The apps/keymaps files are useful things to understand as well, but really you just need to pick an area to look at and dive in...

If you're familiar with C it's generally not /too/ difficult to find your way around.

[shotofadds]

There's now a "Work To Be Done" section on the CowonD2Info wiki page, for anyone out there who wants to help but doesn't know which areas need effort.

I fully appreciate that it might scare off as many people as it attracts, though... 

[ThibG]

I'm looking how lcd_blit_yuv work. So far, I can see that the (0;0) point is supposed to be at the top right corner. I can also see that the ASM part (lcd-as-memframe.S) draws line vertically.
I'm trying to modify it, with my almost inexistant ASM understanding.

Edit: It "works". Er... If video playback is supposed to be half the size of the screen, it works...
Another thing is that I modified the file "lcd-as-memframe.S", common to all ARM targets instead of making a cowond2-only file.

[shotofadds]

I can also see that the ASM part (lcd-as-memframe.S) draws line vertically.

The existing code (both the C and the assembly) was written for players which have their screens in a portrait layout, eg. the Gigabeat F's 240x320 display. So the drawing code takes a 320x240 YUV image and rotates it to display in 240x320. Unfortunately the assembly code is misleading because it does not mention this rotation anywhere in its comments.

If you're going to look at fixing that function, I'd suggest starting with a simple C version (you could just include that in lcd-cowond2.c). This means you don't have to worry about breaking the code for other targets, and we can worry about optimising and/or genericising it later.

[ThibG]

I've now a working (extremly slow) basic C code. The YCbCr to RGB565 conversion is not optimised at all, as I didn't understand the ASM part.
However, don't the D2 support one byte per color?

[shotofadds]

I've now a working (extremly slow) basic C code. The YCbCr to RGB565 conversion is not optimised at all, as I didn't understand the ASM part.

Good stuff - could you post a patch to Flyspray containing your changes? Also maybe have a look at some of the other implementations for some tips (eg. iPod Video?)

I don't know if you're familiar with the test_fps plugin (add test_fps.c to apps/plugins/SOURCES), but it might come in handy while optimising your code...

However, don't the D2 support one byte per color?

Yes, the hardware does, but Rockbox only has a 16-bit LCD driver. The hardware should also support YUV blitting directly in hardware, which will be a nice avenue to explore one day when the basics are working correctly.

[ThibG]

I rewrote the patch with what I've read in the ASM files.
It's a bit slow, but much faster than the old patch.
It's available at http://www.rockbox.org/tracker/task/9178

[shotofadds]

Your patch is now in SVN (r18000... nice number ), and as a result MpegPlayer is now usable - within the confines of the broken NAND driver, of course.

As jhMikeS pointed out on the Flyspray task, the "proper" solution would be to fix the existing lcd-as-memframe.S to have a compile-time rotation switch, but I'll leave that as a task for another day.

[ThibG]

Okay, I'm trying to make the "proper" solution
I think the switch should be enabled when LCD_HEIGHT < LCD_WIDTH...

[El3ctroded]

I had an idea that may help you proceed with the NAND driver:
1) delete everything from the flash that is non-essential
2) set (or clear, your choice) all bytes in the unused memory
3) Write a file to the flash that is nothing but a file containing a sequential count 00-1Fh numerous times.
4) See how the data got written into the flash doing a memory dump.
5) Delete two or three of those files (randomly) and clear or set the memory where those files were.
6) Write a file to the flash that contains a sequential count of 20-FFh Once only.
7) See how that data was written.

Of course this would have to be done using the D2's firmware using some method. In any event, I think that would allow you to see how the original NAND driver stores data when memory is and is not fragmented quite easily.

If it's a bad idea, or has nothing to do with your NAND driver problem, feel free to tell me I'm not that fluent in file systems and NAND memory, just thought I'd share...

[ThibG]

I uploaded a patch which make the ASM code draws horizontally if LCD_HEIGHT < LCD_WIDTH.
Due to my limited understanding of ASM, it may not be very clean, but it works (at least on my D2).

[shotofadds]

I had an idea that may help you proceed with the NAND driver

That's essentially the kind of test I did originally (although it's better to write directly to the drive using something like 'dd', then we don't have to worry about how FAT arranges the data either).

I need to do more of these kind of tests, but there's a huge problem with the "see how that data was written" step. There's no way to get data back from the D2 to the PC, so the only way is to display raw data on the screen, a page at a time. This, combined with some code to search the NAND for particular occurences, is how the current driver was developed. When you're dealing with 4Gb+ of data, it's quite a painful experience.

Another idea that I've been meaning to try is this: from the PC, write every sector on the UMS volume with a unique identifier based on its LBA address. Then, using the current Rockbox driver, read every sector to find which ones are read incorrectly. If we then search the NAND for the correct identifier, it might give us some clues about how the scheme really works.

The only problem with that approach is that I use my D2 as my day-to-day music player and don't really want to leave it in an unusable state for an extended period of time. I've picked up a cheap Sansa M240 (1Gb) which hopefully uses a similar NAND scheme, but I haven't had time to port the necessary code to TCC77x yet.

I uploaded a patch which make the ASM code draws horizontally if LCD_HEIGHT < LCD_WIDTH.
Due to my limited understanding of ASM, it may not be very clean, but it works (at least on my D2).

Thanks. I'll take a look later and maybe see if there's a way to optimize that add/sub stuff. Out of interest, what fps do you get in test_fps (both at 48MHz and 192MHz)?