Rockbox Development > New Ports
Creative Zen Vision:M
iSE:
First off, congrats, its bin a while since I've checked up on this and it seems like I've missed out on a lot! :D
If the source code were modified, for arguments sake so that rockbox handles the player controls correctly, would the compilation be required to take place onboard the Zen itself, or would an easier way be to compile it using the correct tool chain and then transferring it?
Second, I cannot recall if anyone has managed to dump the flash memory data. If this were altered causing it to brick the player, could this be flashed with the original dump? I ask this as a precaution for testing purposes giving us another avenue.
As I understand, its not a simple matter of uploading the firmware using the correct checksum. If the bootloader calls upon different files on the HDD, each encrypted and compressed in a different way, I am assuming that the bootloader has become the main focus in order to configure it to correctly load the rockbox firmware (once properly modified for the Zen)? Is it also correct that this bootloader (located at FBOOT) is ARM code?
Also, in your opinion, what is the next step?
mcuelenaere:
--- Quote from: iSE on November 20, 2007, 12:21:33 PM ---First off, congrats, its bin a while since I've checked up on this and it seems like I've missed out on a lot! :D
If the source code were modified, for arguments sake so that rockbox handles the player controls correctly, would the compilation be required to take place onboard the Zen itself, or would an easier way be to compile it using the correct tool chain and then transferring it?
--- End quote ---
Are you saying that Rockbox should get compiled on the player itself? Because I don't think this is needed, ARM compilers are available everywhere and just recently Creative released a free-of-charge C54x compiler; so there shouldn't be any toolchain problems.
--- Quote ---Second, I cannot recall if anyone has managed to dump the flash memory data. If this were altered causing it to brick the player, could this be flashed with the original dump? I ask this as a precaution for testing purposes giving us another avenue.
--- End quote ---
To do this, we should know a way of accessing the flash chip, reading its contents and writing to it. I don't think this is really necessary, but it could be a precaution we could take.
--- Quote ---As I understand, its not a simple matter of uploading the firmware using the correct checksum. If the bootloader calls upon different files on the HDD, each encrypted and compressed in a different way, I am assuming that the bootloader has become the main focus in order to configure it to correctly load the rockbox firmware (once properly modified for the Zen)? Is it also correct that this bootloader (located at FBOOT) is ARM code?
Also, in your opinion, what is the next step?
--- End quote ---
I think we should decode the CENC block, analyze it (figure out LCD driver code, button driver, etc...) and rebuild the CENC block with our own code so the flash data isn't harmed (and the player couldn't get screwed up). I think this is the best (current) solution for running our own code on the player.
linuxstb:
--- Quote from: mcuelenaere on November 20, 2007, 12:30:21 PM ---just recently Creative released an open-source C54x compiler;
--- End quote ---
Not quite - Texas Instruments released a closed-source C54x compiler which can be used free-of-charge for developing open source software:
http://open.neurostechnology.com/node/1020
iSE:
--- Quote from: mcuelenaere on November 20, 2007, 12:30:21 PM ---I think we should decode the CENC block, analyze it (figure out LCD driver code, button driver, etc...) and rebuild the CENC block with our own code so the flash data isn't harmed (and the player couldn't get screwed up). I think this is the best (current) solution for running our own code on the player.
--- End quote ---
Ok so (i apologise for my lack of understanding if I am incorrect, I am trying to get my head round the whole thing again lol), the CENC block within nk.bin is the actual player software. This is ecrypted and compressed, and is accessible by the rescue mode (FRESC).
Now as I understand it, both FBOOT and FRESC are contained in nk.bin, and so the flash memory is altered at every upgrade? I read a few posts back that Zook said the earlier firmware had less ecryption (my apologies if this is incorrect), and so assuming that to be true, should we not use the FBOOT and FRESC from an earlier firmware model in order to decrypt that archives CENC block?
I understand the need for being able to understand the CENC block, how the components interact etc, however, rebuilding and coding our own is the part I am confused on. It was my understanding that could we properly configure the Rockbox firmware, and get FRESC to load it correctly, that the Jukebox2.jrm file would become obsolete?
NicolasP:
Hello,
I committed a custom firmware update utility for the Gigabeat S, based on the sendfile.c file that mcuelenaere posted earlier. I've only tested it on the Gigabeat and it works fine. However, mcuelenaere told me it has the same update process as the ZVM, so I'm hoping my tool will work on the ZVM too... Could someone confirm? The tool is in the utils/MTP directory of the SVN repository.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version