Rockbox mail archiveSubject: Re: Code size?
Re: Code size?
From: Paul Louden <paulthenerd_at_gmail.com>
Date: Mon, 20 Nov 2006 20:53:07 -0600
One minor correction (unless I've misunderstood this): Rombox isn't just
loaded from ROM, it's executed from ROM. We can put Rockbox in ROM as a
compressed image, and load it to RAM for execution still, leading to a
faster boot time, but executing from ROM results in better battery life
since that increases the audio buffer available on the Archoses by a good
bit. (Is this right? Did I get something switche? Am I completely wrong and
hallucinating 'knowledge' again?)
On 11/20/06, Jonathan Gordon <jdgordy_at_gmail.com> wrote:
> On 21/11/06, Tim Gilbert <timgilbert_at_gmail.com> wrote:
> > Hi...
> > I'm just starting to poke around in the rockbox code, and I'd like to
> > start contributing some features / fixes / etc. Recent messages about
> > shaving 300 bytes off of the code size make me kind of nervous, though.
> > Can someone provide me with a brief summary of what the code size issues
> > are? Is there a lowest-common denominator player whose limits we're
> > running up against?
> > Also, just curious if there's been any attempt to make any of the larger
> > chunks of code into compile-time options? (Say, the voice options or
> > crossfade? I do realize voice is essential for an important Rockbox
> > user base, but for my own personal builds I'd just as soon have other
> > features enabled instead of voice, since I don't use it.)
> > Finally, does anyone have any opinion about whether it would be
> > worthwhile to pursue some sort of VM type arrangement where the entire
> > firmware wouldn't need to be loaded at once? (Or does Rockbox already
> > do this for anything besides plugins?) I'm not nearly familiar enough
> > with the code and the various platforms to know whether this would be
> > feasible or not, but it does seem like one obvious way to work around
> > code-size limitations, and one thing most of the hardware does have in
> > spades is storage space.
> > Thanks
> > Tim
> The problem with compiled binary size is that the archos models only
> have 2mb of RAM and ~200kb (or 400kb) of flash which can be used for
> rombox (rockbox but it boots from flash instead of the hard disk). as
> you can see on the cvs page, 2 targets are already too big for rombox
> and ideally we would like it to work.
> some code pieces can be #ifdefed out with compiler options, but there
> is no plans to make official builds with missing pieces.
Received on 2006-11-21