Hacked Archos desktop

Special Developer Edition Firmwares and Hacking on Archos 5 IT, 5/7 IMT, 605/705, with Android, ├àngstr├Âm and other Linux
Post Reply
serbor
Archos User
Archos User
Posts: 79
Joined: Thu Nov 27, 2008 11:39 am

Hacked Archos desktop

Post by serbor »

As we have the player hacked it is the time to think of further improvements.

The current "window manager" - avos - is built on Qt-embedded-2.3.10.
It uses directfb video driver from kernel and codecs from TI.

There is NO point to fool around avos besides of what guys have done to it - removing unneeded checks.
Basically what we need to do is to port an existing Qt-based window manager and desktop to the existing dev.kit.

It does not seem to be a difficult task.
I compiled Qt-4.5.3-embedded on Archos GPL SDK but this is a very first step.

Right now I do not really understand _where_ is a WM.
In earlier releases Qt was just a library, desktops and WM were built on top of it, like, say, KDE.
Or Qtopia in embedded world.
Now things changed and I have no clear understanding how. What does what?

Documentation seems to be written by market-oriented people - you all know this lovely "microsoft style" docs
adopted by opensorce community where you can't find simple words about the _purpose_ of this
particular software piece. They tell you of what an easy life you have just bought.

Anyways.
Qtopia has been renamed to Qt-extended and dropped as of 4.4.3. Trolltech was acquired by Nokia and they now provide a Qt-4.5.3 (which I compiled).

However, right now I don't understand if the new Qt includes "Qtopia" desktop. It seems that it should.

Any ideas?
serbor
Archos User
Archos User
Posts: 79
Joined: Thu Nov 27, 2008 11:39 am

Re: Hacked Archos desktop

Post by serbor »

Well, I found it - the WM is included in Qt-4.5.3-embedded and called qws.

Will try to compile demos and run it on the player.
2nafish
Archos Novice
Archos Novice
Posts: 18
Joined: Tue Oct 27, 2009 11:33 am

Re: Hacked Archos desktop

Post by 2nafish »

Man, that's awesome!

Do you think it would be possible to get Enlightenment running on top of that?

http://arstechnica.com/hardware/news/20 ... nd-e17.ars

http://www.youtube.com/watch?v=n-M3jorJEt4
serbor
Archos User
Archos User
Posts: 79
Joined: Thu Nov 27, 2008 11:39 am

Re: Hacked Archos desktop

Post by serbor »

Do you think it would be possible to get Enlightenment running on top of that?
I don't think so. At least the efforts to port the required libraries are worthless.

Have a look at http://dist.trolltech.com/video/qtembedded44video.mov

I would suggest, people, not to talk about your lovely linux distributions, "full blown linux" and astonishing window
managers.
We have an Archos GPL "sdk" and let's stick with it. SDK includes a framebuffer driver, which might mean that something using it can access the player's LCD.
Qt-embedded is built around the framebuffer and we might be successful in building an _included_ WM - qws.

SDK is almost complete linux system, some apps can be taken from sources and compiled,
it WILL however require tuning. Worth the effort - you decide for yourself.

I prefer not to forget about the purpose of this little shiny box - it is NOT a computer, itsa player.

I wouldn't even touch it coz it plays.
But I don't like the idea of Archos selling a development stage product which blows battery and forces me to
replace it myself. So I am sorta angry on Archos.
serbor
Archos User
Archos User
Posts: 79
Joined: Thu Nov 27, 2008 11:39 am

Re: Hacked Archos desktop

Post by serbor »

Another thing.

It is seems easy to make a normal filesystem on the player.
There is no point any more to have an inconvenient cramfs.

As I understand the whole thing is mounted in init script which people have modified to avoid "unnecessary" checks.
Thus if we change the HDD layout, for instance resizing a VFAT partition, make a couple of additional ex3s we
could mount them directly, have a writable filesystem and normal package management.
grond
Archos Guru
Archos Guru
Posts: 627
Joined: Thu Nov 23, 2006 10:37 pm
Location: Berlin
Contact:

Re: Hacked Archos desktop

Post by grond »

serbor wrote:Another thing.

It is seems easy to make a normal filesystem on the player.
There is no point any more to have an inconvenient cramfs.
The rootfs is stored in a cramfs because it will be copied to a ramdisk before it gets mounted. The idea is to minimise harddisk accesses and spin-ups and thus to improve system response times because most of the code is already in RAM (and eXecute-In-Place, if I'm not mistaken).
openAOS
serbor
Archos User
Archos User
Posts: 79
Joined: Thu Nov 27, 2008 11:39 am

Re: Hacked Archos desktop

Post by serbor »

The rootfs is stored in a cramfs because it will be copied to a ramdisk before it gets mounted.
Yes, I noticed this when examined the init script.

But it still does not make a lot of sense because avos itself is a statically linked several executables
(opera included) and I wouldn't mind waiting another 5 sec to load such a thing from the hard disk.
I don't even think that it would be a noticeable difference, because with cramfs you'd have to copy
the whole thing into RAM, but when you load "avos" from the HDD, you copy slightly smaller piece,
and you get more free RAM this way.
grond
Archos Guru
Archos Guru
Posts: 627
Joined: Thu Nov 23, 2006 10:37 pm
Location: Berlin
Contact:

Re: Hacked Archos desktop

Post by grond »

serbor wrote:But it still does not make a lot of sense because avos itself is a statically linked several executables
(opera included) and I wouldn't mind waiting another 5 sec to load such a thing from the hard disk.
I don't even think that it would be a noticeable difference, because with cramfs you'd have to copy
the whole thing into RAM, but when you load "avos" from the HDD, you copy slightly smaller piece,
and you get more free RAM this way.
I'm not sure whether all of avos would be loaded to RAM on first start. If the program flow branches to some place it hadn't gone to before, the harddisk would have to spin up, the part would have to be loaded and then executed. All this will take seconds rather than milliseconds. In addition, if avos and other programs are executed-in-place, memory consumption could even be lower than in the normal approach as the code would be compressed.
openAOS
Sychophantom
Archos Novice
Archos Novice
Posts: 28
Joined: Thu Nov 05, 2009 3:56 pm

Re: Hacked Archos desktop

Post by Sychophantom »

Wow. This is the first thread that I understood almost nothing in.
edembowski
Archos User
Archos User
Posts: 98
Joined: Mon Oct 26, 2009 8:11 pm

Re: Hacked Archos desktop

Post by edembowski »

grond wrote:...If the program flow branches to some place it hadn't gone to before, the harddisk would have to spin up, the part would have to be loaded and then executed. ...
This matches my understanding of how executables are loaded. On load, the file is mmape'd to where it needs to be, and only read from disk when those areas are actually accessed.

- Ed
serbor
Archos User
Archos User
Posts: 79
Joined: Thu Nov 27, 2008 11:39 am

Re: Hacked Archos desktop

Post by serbor »

I'm not sure whether all of avos would be loaded to RAM on first start. If the program flow branches to some place it hadn't gone to before, the harddisk would have to spin up, the part would have to be loaded and then executed.
XIP makes sense when executes from flash, in that case you can speed up things avoiding program load and
conserve RAM, because the only thing needed is a bss segment for dynamic data.
However, if the image is compressed the data segment also needs place in RAM, besides when paging occurs,
decompression takes time.
But all this occurs when a system has nothing to store programs but flash and a small piece of RAM.

In our case the first thing init does it copies the whole root.cramfs into RAM, and then mounts /dev/ram0
as a cramfs filesystem to /new-root.
I think, I am not sure, that this mount decompresses the cramfs.
So we have an inflated image in RAM which occupies RAM by all the unneeded at the moment parts of
root.crams.

But even if mounted cramfs gets inflated on demand I doubt that occupying valuable RAM by unnecessary programs speed up the program execution.

My wild guess is that Archos did this to increase "security", rather than speed up the program load.

They wanted a way to "secure" the whole filesystem, avoiding the necessity to secure each file.
They could have used zip archive for instance (as Sony-Ericsson did), but then they would face a problem of
where to decompress etc.
In their concept the root.cramfs is "secured" by an added key.

They do not do XIP, because of copy from HDD to RAM. But the whole file system.
Same thing as you would load a _static_ binary. But in this case you have _more_ RAM and less paging.
generic_username
Archos Expert
Archos Expert
Posts: 194
Joined: Mon Jan 14, 2008 9:18 pm

Re: Hacked Archos desktop

Post by generic_username »

i think you hit on something earlier without realizing it. Whether we stay with an avos based approach, look to a new codebase or something inbetween, the key is package management.

package management is what makes apple jailbreak so cool

with iphone/ipod touch jailbreak a full APT system was implemented. now that we have boot access, with apt+kernel+command line the opportunities for development and easy deployment are incredible!
serbor
Archos User
Archos User
Posts: 79
Joined: Thu Nov 27, 2008 11:39 am

Re: Hacked Archos desktop

Post by serbor »

Well, I wrote about package management in some other posts.

Here we discuss the avos desktop and file system.
As I think the idea of cramfsing the file system came from the "security" rather than from the intent
to "increase customer satisfaction by providing fast program loading".

It seems even possible to mount a usb stick containing a linux distribution, that is because the
init checks and waits for the sd driver to load.
If we modify the init that it checks a usb connected at boot time it should mount the usb ext3 fs,
if not - goes the normal way.

There is no need to boot from usb. Mount would be enough, I think.
I will try it when I get to my test bench.
nz
Archos Staff
Archos Staff
Posts: 712
Joined: Thu Jul 26, 2007 6:17 pm
Location: Archos SA, France
Contact:

Re: Hacked Archos desktop

Post by nz »

grond wrote:
serbor wrote:But it still does not make a lot of sense because avos itself is a statically linked several executables
(opera included) and I wouldn't mind waiting another 5 sec to load such a thing from the hard disk.
I don't even think that it would be a noticeable difference, because with cramfs you'd have to copy
the whole thing into RAM, but when you load "avos" from the HDD, you copy slightly smaller piece,
and you get more free RAM this way.
I'm not sure whether all of avos would be loaded to RAM on first start. If the program flow branches to some place it hadn't gone to before, the harddisk would have to spin up, the part would have to be loaded and then executed. All this will take seconds rather than milliseconds. In addition, if avos and other programs are executed-in-place, memory consumption could even be lower than in the normal approach as the code would be compressed.
right!
Post Reply

Return to “Open Development”