Rockbox Development > New Ports
Creative Zen Vision:M
mcuelenaere:
--- Quote from: crzyboyster on February 17, 2008, 12:50:44 PM ---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.
--- End quote ---
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:
--- Quote from: Bagder on February 17, 2008, 02:01:11 PM ---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.
--- End quote ---
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 RGBYUV or something with x-bit), it works. (I'll attach the patch later)
edit: patch
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version