Cowon D2

[FirleFanz]

Can you post what´s written in the background.bat, please!

[karashata]

Sure, it's "rockboxui.exe --background".

[FirleFanz]

for linux it is ./rockboxui --background

[FranzD2]

Hi!

I'm new to the Rockbox development and i'm trying to figure out how i can help.
My question is related to the lcd panel driver, i was investigating the "2 top lines cut and repeated at the bottom" issue. Looking into the driver code i saw that the power on sequence has been implemented almost exactly as the LTV250QV-F0B datasheet says, exept for three commands that are different,

[lcd-cowon.c : 162] lcd_write_reg(3,  0xE100);         // datasheet says 0x100

[lcd-cowon.c : 165] lcd_write_reg(6,  0x4);               // datasheet says 0xA
[lcd-cowon.c : 166] lcd_write_reg(7,  0x30);             // datasheet says 0x36

I tried to set them to the datasheet values but my screen goes blank.
Could someone please explain me why those command are different (maybe they comes from the OF?)

Thanks & keep on the good work!

[shotofadds]

Hi Franz, it's always nice to see new people getting interested!

The initialisation commands we use are the same as the original Cowon firmware, as the sequence given in the datasheet didn't work for me either (maybe the D2 LCD is a slightly different revision of the LTV250QV?).

I haven't looked into what the differences are, though. Maybe you could try changing individual bits within those register values to see which changes are important/relevant?

This "cut and repeated lines" problem only seems to happen when the bootloader is used to run the main Rockbox binary (it doesn't seem to happen if Rockbox is booted using tcctool). So it's likely to be provoked by the main Rockbox binary trying to initialise the LCD a 2nd time...

[FranzD2]

This "cut and repeated lines" problem only seems to happen when the bootloader is used to run the main Rockbox binary (it doesn't seem to happen if Rockbox is booted using tcctool). So it's likely to be provoked by the main Rockbox binary trying to initialise the LCD a 2nd time...

In my boot screen i even see the top two lines cut off so the problem is in the first LCD initialization, i'll try to test some bit configuration as you said, unfortunately the datasheet is very poor of infos on the meaning of each bit (what values can take R3???), however i'll do some trying, thanks for your reply!

[FranzD2]

I found the problem that was causing that "two lines cut and then repeated at the bottom",
first of all, i had to set the value of R06 (to be exact it is the value of the Vertical BachPorch) to 0x1 instead of 0x4 (Don't know why but let me know if this could cause problems, i don't think so) and then i inserted some sleep_ms() call into the spi command write routine ltv250qv_write(), right after the

GPIOA_CLEAR = LTV250QV_CS;

and just before the 

GPIOA_SET = LTV250QV_CS;

I put a "sleep_ms(20);"
I think that this problem was due to some timing stuff related to the spi hardware which has been resolved just by inserting a small delay.

If someone feels inspired, please try this fix and let me know...

[shotofadds]

Well, that makes perfect sense. It does indeed look like two distinct problems:

1. An incorrect "vertical back porch" value could certainly cause the missing lines. This would apply to the bootloader and main Rockbox equally.

2. In the bootloader, lcd_init() is called while the cpu is unboosted, but main.c first calls cpu_boost(true). This means the CPU is running 4x faster when lcd_init() is called the 2nd time.

I'll do some testing to find the optimum wait time necessary (20ms is likely to be several orders of magnitude more than necessary!) and then commit a fix.

Thanks for looking into this - if you let me know your real name I'll add you to the CREDITS file.

EDIT: Using a vertical back porch value of 0x1 fixed the missing lines at the top, but caused a missing line at the bottom. A value of 0x2 works better for me - does this work for you as well?

[wnmnkh]

shotofadds, I begin to suspect that the NAND read/writing driver for SD is broken even in the official firmware.

I used a lot of writing and deleting on my 8gb card using my D2, not a card reader. Currently, the card is corrupted and the firmware is unable to read the files correctly. Maybe this is my own, unique case only, but I just can't stop thinking about the connection between buggy file access and this problem.

[shotofadds]

@wnmnkh: I very much doubt these problems are related. The Rockbox file access is "buggy" because we dont understand enough about the NAND Flash Translation Layer (although I'm working on that right now...), so that won't affect SD at all.

[FranzD2]

1) I'll do some testing to find the optimum wait time necessary (20ms is likely to be several orders of magnitude more than necessary!) and then commit a fix.

2) EDIT: Using a vertical back porch value of 0x1 fixed the missing lines at the top, but caused a missing line at the bottom. A value of 0x2 works better for me - does this work for you as well?

1) Be careful, i tried a value of 10 ms and that worked several times for me, however the problem was still present; i think that the correct value should be as near as possible to 10 ms but to be really sure it needs several trying.

2) I'll try asap and i'll let yow know

EDIT: Yes you're right.

[ThibG]

Hm, I tried rockbox again today and... It won't boot (I tried 4 times, "file not found"...)
I have the same D2 as before (a 4Go one), but I have the 2.57 firmware now.

[shotofadds]

Don't worry, the different firmware version won't matter - it'll be the same old "unreliable NAND driver" problem. I'm working on a new version which should improve things, and I'll keep you posted when there's something to test (hopefully in the next week or two).

[man.dovvn]

I have also experienced file corruption using the supplied firmware.
Perhaps code could be written to calibrate file access based around an earlier thought. It was proposed here that Rockbox would write known unique data to all memory addresses, and then read back the data, in order to map the memory. If this is still a feasible solution, code could be written to do this, then save the map file and use it to access memory addresses correctly. It would be time consuming to map, and it'll slow down the whole firmware to use a memory look-up table, but it may be better than nothing.

[shotofadds]

That's not really an option, since the mapping between logical block (LBA) and physical NAND address is dynamic and changes as data is written to the NAND. This is how the OF implements wear levelling, by ensuring that data is written evenly across different physical blocks. Unfortunately it also makes our job rather more complicated...

But like I said, check back in a week or two as I'm hopefully not far off a breakthrough in this area.

I'll try to keep the TelechipsNAND wiki page updated with any findings, but at the moment that's a secondary concern, after making the damn thing work in the first place.