Creative Zen Vision:M

[mcuelenaere]

What's FRESC? Excuse me for the dumb question! I'm wondering if CW checks the correspondence between the checksum and the checksum stored in the NULL block and, if the check fails, doesn't go on with uploading the firmware... I think it could be a useful check but I don't know if you've included it: that's why I'm just guessing.
Maybe even the hacked updater makes that check... I don't know.

FRESC is the code which contains Rescue Mode (this is all documented on the wiki page).

CreativeWizard doesn't do any checksum verification whilst uploading; nor does the original/hacked firmware updater.

[GuybrushThreepwood]

FRESC is the code which contains Rescue Mode (this is all documented on the wiki page).

Thanks for telling me!

CreativeWizard doesn't do any checksum verification whilst uploading; nor does the original/hacked firmware updater.

If so, I don't know why I can't upload the 1.30.02 firmware...

[mcuelenaere]

CreativeWizard doesn't do any checksum verification whilst uploading; nor does the original/hacked firmware updater.

If so, I don't know why I can't upload the 1.30.02 firmware...

Well, the player itself does...

Have you tried updating the checksum to what CW reports it should be?

[GuybrushThreepwood]

Have you tried updating the checksum to what CW reports it should be?

It was my first tought but CW doesn't let me modify the checksum value in the NULL block...

---EDIT---

I've extracted the firmware files from the updater packages v1.30.02, v1.41.01 and v1.51.01 downloadable at the address that you also know.
The extraction process went fine but the checksum check between the one calculated by CW and the one in the NULL block fails for all of them and I can't upload them by CW nor the hacked updater. All the other firmwares (which passed the checksum check) can be uploaded with no issues.
It seems to me that there is some kind of connection between the checksum issue and the upload issue...

[Transience]

010 editor will open the device if i put it into removable disk mode, but it will only show the removable disk partition. The device is capable of formatting itself into FAT32. Perhaps the creative firmware could be modified to begin formatting at the root of the drive instead of the default location? just a thought...

[mcuelenaere]

Have you tried updating the checksum to what CW reports it should be?

It was my first tought but CW doesn't let me modify the checksum value in the NULL block...

---EDIT---

I've extracted the firmware files from the updater packages v1.30.02, v1.41.01 and v1.51.01 downloadable at the address that you also know.
The extraction process went fine but the checksum check between the one calculated by CW and the one in the NULL block fails for all of them and I can't upload them by CW nor the hacked updater. All the other firmwares (which passed the checksum check) can be uploaded with no issues.
It seems to me that there is some kind of connection between the checksum issue and the upload issue...

Try using the ZenUtils (zen_crypt has the ability to (re-)sign a firmware and other stuff).

010 editor will open the device if i put it into removable disk mode, but it will only show the removable disk partition. The device is capable of formatting itself into FAT32. Perhaps the creative firmware could be modified to begin formatting at the root of the drive instead of the default location? just a thought...

Even if we would do that, what's the benefit? The OF and recovery mode won't be able to read it so the device will just give a HDD HW error..

And 'The device is capable of formatting itself into FAT32' statement is correct; but that's all there is.
Only formatting, so no read/write/... FAT32 capabilities.

The current idea is to use the Virtual File System image (=Removable Disk Mode) and to get Rockbox to locate and read from this.

This would mean dual-boot capability and access to Rockbox's files without taking your HDD out.

[GuybrushThreepwood]

Try using the ZenUtils (zen_crypt has the ability to (re-)sign a firmware and other stuff).

The only zen_crypt function I can take advantage of seems to be the signature function. I've used the -s switch and tried to resign the firmwares but it didn't help. The checksum stored in the null block is still the same and is wrong. Perhaps the -s switch affects other informations stored in the file...
I've noticed another thing (perhaps it could be interesting): all the firmwares with the right checksum are below the 21Mb barrier (they all are 20,7Mb worth) while the ones with the bad checksum are above that barrier (the file size is, respectively, 21,4Mb, 21,5Mb, 21,8Mb for fw v1.30.02, v1.41.01, v1.51.01).

p.s. I've forgotten to report that, when making the binaries, I get some warnings about, if I remember well, characters. Now I'm on a Windows machine and can't check what's the precise error... I don't think it's a problem but I've reported it for the sake of completeness.

[mcuelenaere]

I just committed the beginning of dual-boot capability to SVN and now you're able to run Rockbox (well not exactly) *without* taking your hard drive out

I've updated the installation instructions on the wiki.

Currently, the only thing the bootloader does is loading the original firmware. But whenever quetzalcoatl figures out the CFS file system, we should be able to run a FAT file system as a file on the CFS file system.

The only zen_crypt function I can take advantage of seems to be the signature function. I've used the -s switch and tried to resign the firmwares but it didn't help. The checksum stored in the null block is still the same and is wrong. Perhaps the -s switch affects other informations stored in the file...
I've noticed another thing (perhaps it could be interesting): all the firmwares with the right checksum are below the 21Mb barrier (they all are 20,7Mb worth) while the ones with the bad checksum are above that barrier (the file size is, respectively, 21,4Mb, 21,5Mb, 21,8Mb for fw v1.30.02, v1.41.01, v1.51.01).

p.s. I've forgotten to report that, when making the binaries, I get some warnings about, if I remember well, characters. Now I'm on a Windows machine and can't check what's the precise error... I don't think it's a problem but I've reported it for the sake of completeness.

Weird. But I'm pretty sure the file size increase doesn't really matter.

edit:
@quetzalcoatl:
For some reason, all numbers were little endian instead of big endian in my disk dumps and on the real device. Are you sure they should be big endian?
Solved

[GuybrushThreepwood]

I've tried with nullblockfixer too: it reads the checksum in the Null block and leaves it there (perhaps it finds it correct).

[grooveharder]

well, i've just tried the install instructions on the wiki, and it works like a charm... (well, after some playing with gentoo's cross-compile system!) it boots without a hitch. the sendfirm utility even works well with "font firmwares" created by creativewizard.

congratulations - this seems like a big milestone, no? i'd say being able to install some sort of Rockbox code on the Zen "*without* taking your hard drive out" is good progress!

thanks for everyone's work on the project. surely we are not far away from full Rockbox on the Zen now.

[quetzalcoatl]

@quetzalcoatl:
For some reason, all numbers were little endian instead of big endian in my disk dumps and on the real device. Are you sure they should be big endian?
Solved

i still wonder how i mistook them, i'll fix the notes asap, thanks for pointing it out.
taking current reallife thing into calculations, CFS will take at least next 2 weeks. i'm sorry, i just literally have no free time now. i'll post as soon as start comparing new and old volumes' images

[mcuelenaere]

Windows builds are now available for mkzenboot & sendfirm on the wiki page... (+ instructions on Windows)

+ now it's possible to use mkzenboot on the ZVM60GB & ZV

[saratoga]

Not sure if anyone has noticed this already, but theres a little bit about the TI TLV320AIC23BZ in the patch for the linux modifications used in the SansaConnect here:

http://www.rockbox.org/twiki/pub/Main/SansaConnect/sansaconnect-2.6.4.patch.bz2

[mcuelenaere]

@quetzalcoatl:
I made this small CFS parser..

Not sure if anyone has noticed this already, but theres a little bit about the TI TLV320AIC23BZ in the patch for the linux modifications used in the SansaConnect here:

http://www.rockbox.org/twiki/pub/Main/SansaConnect/sansaconnect-2.6.4.patch.bz2

I've seen it and it also contains TMS320DM320 info but I haven't had the time yet to look through it thoroughly..

[mcuelenaere]

I am very, very close to getting the VFAT thing to work.

Good news is that all the data is in sectors of 0x8000 (=64*512) and almost all sectors are next to each other so performance won't be that bad (I'll be using an array anyway to be safe though).

This is what I currently have (it's capable of extracting the VFAT files out of a disk dump, but not in the right order and/or with other problems.

This is a little description (for nomadrawexplore\notes\cfs) of the new structures not already described publicly.