(Semi)-Official response from Rockbox:

I've actually removed that post on the basis that our New Ports forum is *not* for requesting help. It's for people when they decide to start their own port. As far as I can see there's no effort going on here to get Rockbox running on this device.

As an aside - we were already aware of this work prior to the post showing up, and yes, it has gathered some interest - but so far no-one in the "core" team owns the device, and so unless someone new shows up and starts doing the work detailed in our NewPort wiki page, there isn't going to be a Rockbox port for it.

Quick note : as stated before, Rockbox is audio oriented and would be of less use when running on a PMP.

It still has games (there's a NES and GB emulator too) and lots of other tricks. I run it on my Sansa e280 and it's great. Plus a lot of other people here are looking to improve audio quality and improved codec support (Rockbox is known for both).

New codec support is unlikely, Davinci board only supports what Archos already has available.. Without a Davinci SDK it'd be tough to just come up with one, with one, it'd be more work than someone would likely care to do for free. Sorry if this bums people out. Been reading up on the Davinci stuff on TI's site

sorry for my english...

it's possible to change the boot image? or the text below the image in the Home ?

thanks

Hi!!!
We're from ARCHOSLOUNGE's forum (napster and I)
We're very interested about your discoveries and can you tell us what can we do with your process ?
http://www.archoslounge.net/forum/showt ... #post27717

Thanks

I was taking a look at it too... I have just joined the forum, got the SSHD running on my 605 and started looking around. Depending on the chipset, there seems to be code available for FLAC and Ogg Vorbis from VINJEY Software Systems in India supporting the TMS320DM643x, TMS320DM644x and TMS320DM64X DSPs. Do we know what the 605 is based on?

But I think you are right, the community would need access to the TI development suite and then there is the whole problem of trying to get AVOS to understand the new format. A replacement OS is possible, but I don't know if RockBox would make such a great PMP.

Update
Looking around a bit more at "dmesg" and a few other commands. It seems that the "USB" host, when you connect it is MUSB HDRC and FSG to share up the /mnt/data.

Also reading another post, the problem is that the "fstab" entry for "optfs.cramfs.secure" seems to be a standard cramfs filesystem, that means Archos had to modify the cramfs to make it encrypted, which means they are in violation of the GPL for not releasing it, correct? Which maybe a way to move this forward.

Mffffh. I hate when it happens. :D
Anyone can tell me if Im wrong

Status update

Fiat (the one, the great one) found a way to hack into the player and execute shell commands.

What it means for the moment is we're able to dig further in understanding the way the player works.
Hacking into this way requires some Linux and coding knowledge.

It is not actually question of GUI modification or feature adding (user sense I mean).

More update later...

Would this be of any relevance?

http://focus.ti.com/docs/toolsw/folders/print/tmdxevm6467.html

EDIT: I'll take a look when I get home and see what I can find.

Ok, dissecting the modules, here are my guesses (with updated information supplied by others):

g_file_storeused used to "share" the /mnt/data volume via USB
musb_hdrc used to "share" the /mnt/data volume via USB
sd8xxx wireless chipset support
sdio Secure Digital IO Support
davinci_imgdma Part of the DaVinci DSP Support
fuse Filesystem in User Space module. To allow a full filesystem in the user space, allowing control for non-privileged users.
af_packet Part of network support
av5604ts Module for touchscreen support
tsdev Touchscreen Support
sdio_host_davinci Part of the SDIO and Da Vinci DSP Support
sdio_dma_davinci Part of the SDIO and Da Vinci DSP Support
hx5078 LCD Panel Support
hx5078_spi Serial Peripheral Interface Support for LCD Panel
spi_davinci SPI Support for Da Vinci
spi_core SPI Suport for ARM Processors (uses av5604ts)
hdpwrd Hard Disk Power Deamon (thanks grond)
davinci_vpfe Part of the Da Vinci Video Playpack
video_buf Video Buffer
v4l2_common Video For Linux
videodev Part of the Video subsystem
davinci_audio_wm8985 Support for the WM8985 Audio Codec
wm87xx Part of the WM Codec????
davinci_audio Part of the Da Vinci Audio Subsystem
davinci_audio_dma_intfc Part of the Da Vinci Audio Subsystem
soundcore Sound Subsystem
usbcore USB Subsystem
ocvc part of the wireless???
lpm part of the wireless???
dsplinkk Allows loading of code from the ARM processor into the Da Vinci based DSP (thanks grond)
davinci_resz Part of the Da Vinci Sub System that allows offloading of resizing of rectangular images (thanks grond)
dmalloc Debug Memory Allocation to replace malloc

Any further thoughts on what might be running there...

Hi,
I've a question. I'm assuming there is 64M ram in the 605 and that the free command is reporting 100M because the 605 is using some virtual memory technique. If this is true, what are the implications for the 605 4G?

Doesn't this configuration mean that the flash memory is being written to more often than is healthy for flash?

Nice, kitsonk. I google'd some to see if I could find anything of use:

sd8xxx - Wireless support for the Marvell SD8686 chipset.
sdio - SecureDigital card support? (info)
af_packet - TCP/IP for linux (info)
tsdev - Compaq touchscreen protocol driver (info)
wm87xx - Some form of audio codec driver (more info)
dsplinkk - Related to TI DaVinci (info)

I'll update this and see what I can find later.

UPDATE: It's probably worth looking around on the TI DaVinci wiki for related information:

http://wiki.davincidsp.com/

Interesting stuff:

TI Supported Codecs
Code composer studio IDE
TI Development kits

Ok, I found the problem with the mount command, the filesystem has to be ext3 not ext2.

So summarizing again the (correct) steps to mount /opt with write permissions:

On a linux machine create an ext3 file and copy to the Archos (via usb connection):

(Option -j creates the journal (ext3), option -m 0 ensures whole partition is reserved for use)

UPDATE: Increased count to 40000 since 30mb is a bit tight, note that /opt partition can be as big as we like, we can add as many apps as there is space available on the archos hardrive. (actually, it's vfat, so the limit is 2gb)

ssh to the Archos and copy the /opt directory into the "partition":


Shutdown opera or apdf, umount /opt and remount on the file:


Note that this enables us to safely alter /opt, eg we could alter the apdf app to be a command which tests for a button press at time of launch and then opens an 'alternative' menu, otherwise apdf launches as normal.

One strange point - /opt can't be umounted if opera is running, but opera still starts when /opt is umounted? (apdf does not)

Before:


After:


EDIT
To return to original /opt, just 'umount /opt' (shutdown opera or apdf first) and then 'mount /opt', this latter command will pickup the default mount options in /etc/fstab

The commands we have access to in /opt




opera fonts seem to be in /opt/usr/share/fonts/opera:

hmm
i just wanna have some alternative firmware
sth like opie or mobile windows or sth
is it possible yet?

thx
EvilKnebl

Check back in about a century, or when hell freezes over, whichever happens first:-)

Also... Someone mentioned "dc.dat"... My opinion right now is that this is the certificates for the WMA DRM for files moved to the Archos from a XP/Vista box. I don't think it is the public or private keys for the secure fs.

I guess the question is /opt is great step forward. I guess we need to figure out how the cramfs is read from the images... Is it decoded at the hardware level and I wonder if there is anyway of dd'ing out the /opt and doing some sort of compare to the optfs.cramfs.secure to find out how the two interrelate... I am going to explore dd'ing that out to see if we can find any clues into how the acturally formulate the .secure files.

Any good wiki out there for this, because this is going to get a bit strange using a forum or a mailing list for our collective wisdom.

Any other thoughts appreciated.

Update

HOLY COW... I first dd'ed out the mount for the /opt into opt.img and then I also copied the optfs.cramfs.secure as well as copied /opt into /mnt/data/Data/opt. Once I got it there, I looked at both the opt.img and the optfs.cramfs.secure and they were exactly the same byte size which seemed a bit odd. Also the headers for the files seem to be unencrypted and both of them seemed to be "standard" cramfs files. So I did a cramfsck on both of them and used the -x option to extract them and sure enough, everything is in both in a totally unencrypted fashion. I did a mkcramfs on the /opt directory I copied and I got something close the the original. It might be just a byte size difference between them or something. Either way, I am going to check the other *.secure files to see if they are actually un-encrypted or not.

I guess they might be encrypted at the hardware level and as long as you have root access you might be able to create new .secure files. Since I can't physically see the .secure files except through the root account, I can't eliminate that right now. Does anyone agree I am thinking along the right lines here?

Update - Update
Ok, copied out the .secure files. All of the cramfs.secure files seem to be normal cramfs files once copied to /mnt/data/Data. The problem is while the rootfs.cramfs.secure "looks" like a cramfs, my cramfsck tool is complaining about the superblock magic number not being right. I am looking into that now, but other parts of the file "look" like cramfs.

Next step for me is to try and re-create the optfs.cramfs.secure, unmount the one that is there and replace it with my own cramfs, copy it to the /mnt/system and re-mount, as well as figure out what is different about the rootfs.

Update 3
Ok... taking a look at the hexdump of the files, it seems that the cramfs is "slightly" modified. The first 192 bytes seem to be some sort of digest hash that must "validate" the file before being allowed. It starts off with "d5 84 c2 d2 00 04 00 00" in the first 8 bytes in all of them. For some reason the cramfs ignores this except for the rootfs, which means there is something in that hash digest that makes it think the file is starting earlier and then can't find the right superblock magic number for it. The cpio.secure file is a little different. The first 192 bytes seem to be the same signature, but it starts of with "f0 89 e5 da 00 04 00 00".

So it looks like the *.secure files are encrypted, just signed.

Actually, I was assuming there's 128MB RAM and that ~32MB of it is being allocated for the ramdisk that the root filesystem is running in.

There already exists one in the ArcWelder space of google code.
This way...

This should be enough as long as we talk of exploit things.

Also, dm8tbr suggested the OpenPMA wiki and Gen4 section.
Google code wiki seems very limited.
Over there

I guess I need to pm fiat to add me to the project then... ;)