Creative Zen Vision:M

[mcuelenaere]

Finally I'm able to run code on my ZVM!  

I haven't got a camera laying around here, so I can't proof anything, but I can upload the firmware I'm using (this is for a Creative ZVM 30GB).

After you've uploaded it, the player will hang on the ZEN screen, but it will display a green rectangle.

To delete the firmware, you'll have to boot in Rescue Mode and select Reload Firmware.


More will follow...

edit: question to Rockbox devs:
atm I'm not using the Rockbox source as base, but just my own C file; how is the printf() command implemented in Rockbox?

edit2: I'm trying to compile a bootloader, but I'm getting: 'ERROR: x uses FPA instructions, whereas y does not'
and other linker errors

edit3: found it, apparently -mcpu=arm926ej-s should be -mcpu=arm9 (or at least on my machine)

[mcuelenaere]

Current diff with Rockbox tree

[crzyboyster]

Can we get a picture? And congrats, mcuelenaere! This should pave the way for the entire Creative family of players!

[mcuelenaere]

I'll see if I can find a camera somewhere.

Problem is: I can perfectly change anything on the LCD screen, but whenever I try to put a Rockbox binary on the device, it just goes immediately to black screen. Neither the RAM is touched nor the OSD variables, and I can't seem to find what the problem is

Does someone have a clue?

(attached is my diff to current SVN)

[crzyboyster]

How exactly did you achieve this "phenomenon"? I want to try something similar on my Zen V 2gb just to see how far this has progressed and whether or not the same green rectangle shows up on the Zen V.

[mcuelenaere]

How exactly did you achieve this "phenomenon"? I want to try something similar on my Zen V 2gb just to see how far this has progressed and whether or not the same green rectangle shows up on the Zen V.

First of all, you certainly need to disassemble the original firmware (try using IDA if you use Windows, it's very helpful)
I don't know if this is totally the same on the Zen V (I think it is), but the OF reads jukebox2.jrm into certain memory parts (as described in its structure) and what I've done is (using the DM320 hardware OSD cursor) compiled a small program and tried getting it on my player; but this is getting a bit off topic

[crzyboyster]

I don't think I can do all that as I can't compile or read/write code  
I guess we should just wait for this to progress and then rockbox might get ported to the other Zen players...

[mcuelenaere]

I believe i've found the problem, but I can't (yet) solve it:
the OF loads the code at 0x000000, but Rockbox assumes it is somewhere in 0x900000.
It then loads the reset vectors from somewhere in SDRAM to 0x000000 and sets up stacks etc.
Then it jumps to main(), but it thinks this is (also) in 0x900000, so what I've got to do is figure out how to change the memory linking during compiling; I know it has something to do with boot.lds and apps.lds; but I can't figure out how.

Help?

[Bagder]

If you build the bootloader boot.lds is what tells on what physical addresses it should build the program to work on/with. That's a plain normal gnu ld script that's run through a C preprocessor first, thus the #ifdefs and #defines etc.

In your case it sems the boot.lds sets
#define DRAMORIG 0x00900000

... which I agree looks very weird and unlikely to match reality for any actual target.

[mcuelenaere]

If you build the bootloader boot.lds is what tells on what physical addresses it should build the program to work on/with. That's a plain normal gnu ld script that's run through a C preprocessor first, thus the #ifdefs and #defines etc.

In your case it sems the boot.lds sets
#define DRAMORIG 0x00900000

... which I agree looks very weird and unlikely to match reality for any actual target.

Funny you post this now, because about 2 min. ago I sort of solved the problem
I saw that DRAMORIG was set to 0x900000 and tried setting it to 0x0; but that didn't work.
But since the OF includes some sort of specific loading (i.e. you say: load block x to address y and block a to address b etc; something like ELF format I presume?) I tried loading the Rockbox code to 0x900000 and 0x0 containing a LDR PC, =0x900000 and ... it works!

Although the LCD is giving me garbage (probably due to RGB<->YUV or something with x-bit), it works. (I'll attach the patch later)

edit: patch

[Bagder]

Cool!

If you could take a photo of the LCD perhaps someone recognizes the sympthom.

The patch is however incomplete as it refers to several files that aren't included. Like config-creativezvm.h and the ones in target/arm/tms320dm320/creative-zvm/

Update: also, the scramble.c patch adds a be2int() function that isn't used. Why?

[mcuelenaere]

All LCD problems are solved, I'm currently working on figuring out the buttons (GPIO etc).

A diff will follow (I forgot to do 'svn add' on some files)

edit: added diff
If I forgot adding a file, please reply

edit2: nk.bin

edit3: currently only LCD driver is working; for compiling: use Bootloader and it will output a rockbox.zvmboot file which you'll have to put in a CIFF structure (use CreativeWizard) with filename Hjukebox2.jrm and type set to DATA.

edit4: about the be2int() in scramble: that was for testing purposes, can be removed now; it is indeed not used anymore

[shotofadds]

Congratulations on gettting the LCD code up and running! It's good to see this progressing finally - maybe I'll even get my ZVM out of the cupboard one day when I'm bored with the D2....

One thing though: in your patch it looks like there's a lot of TCC780x code left over from the D2 driver: anything referring to LCDC_* is specific to the 7801 LCD controller and needs to be removed, since writing to those addresses on another target is probably not a good idea and will almost certainly bear no relation to what is needed (the same applies to PORTCFG, BCLKCTR etc).

But I'm sure you knew that already.

[mcuelenaere]

Congratulations on gettting the LCD code up and running! It's good to see this progressing finally - maybe I'll even get my ZVM out of the cupboard one day when I'm bored with the D2....

One thing though: in your patch it looks like there's a lot of TCC780x code left over from the D2 driver: anything referring to LCDC_* is specific to the 7801 LCD controller and needs to be removed, since writing to those addresses on another target is probably not a good idea and will almost certainly bear no relation to what is needed (the same applies to PORTCFG, BCLKCTR etc).

But I'm sure you knew that already.

Thanks.

Yes I know, the code needs some cleanup. Actually I wasn't sure about the LCD Controller registers; I just left them there as something to base myself on.

About the pictures: I just made some (I know: most of them are bad quality and took with an unsteady hand), they're available here.

[Bagder]

I committed a small part of the patch now that seemed clean and not likely to cause troubles for anyone else.

Some parts of the remainder of the patch seems to modify stock dm320 code that isn't clean enough to commit. And then I'm not sure how valid the firmware/target/arm/tms320dm320/creative-zvm parts are.

Comments?

I just want to help getting the core vision:m stuff added so that more people can join in this effort and help easier.