RE: Another try at the run-from-Flash issue for MPC8xx/MBX/custom

RE: Another try at the run-from-Flash issue for MPC8xx/MBX/custom

[Brown, David (dbrown03)]

I agree, 40 seconds is too long: he must be doing something wrong.
But even 5 seconds is annoyingly long for an embedded system.

I haven't found anything better than LZO for compressing flash.
It is wicked fast, takes very little code, and no dynamic memory for
decompression.
Compressing takes some memory, and can be slow at higher compression levels,
but that happens once on the host so it isn't an issue.

LZO is available under GPL.  Perhaps someone could investigate using this
for compressing the Linux kernel and initrd.  Alas, I don't have time right
now.
--
Dave Brown <dbrown03@harris.com>
Principal Software Engineer, Harris Corporation

http://wildsau.idv.uni-linz.ac.at/mfx/lzo.html

> -----Original Message-----
> From: Dan Malek [mailto:dan@netx4.com]
> Sent: Wednesday, March 29, 2000 8:26 PM
> To: Doug Rogers
> Cc: linuxppc-embedded@lists.linuxppc.org
> Subject: Re: Another try at the run-from-Flash issue for
> MPC8xx/MBX/custom
>
>
>
> Doug Rogers wrote:
>
> > ..... It is simply a matter of size.
>
> So, what methods are you planning to use for storing the applications,
> libraries and other files you need to use and update?
>
> > ....... I've timed the decompression of our smaller test image
> > and it takes over 40 seconds on a 40MHz MBX860 board.
> That's too slow.
>
> You are doing something very wrong.  I have worked on production
> set top boxes that uncompress a kernel and 16 Mbyte ram disk from an
> 8-bit flash rom that are executing in the application in
> under 5 seconds.
> This is a 50 Mhz 860......turn on some caches, align some data, use
> faster memory.....
>
>
> > I was hoping that Linux was to that point, but apparently not. Just
> > having the kernel run from ROM would be helpful for now,
>
> That saves only about 800K or so of memory.  If you are counting bytes
> at that level you are in trouble already.
>
>
> 	-- Dan
>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Another try at the run-from-Flash issue for MPC8xx/MBX/custom

[Dan Malek]

"Brown, David (dbrown03)" wrote:
>
> I agree, 40 seconds is too long: he must be doing something wrong.
> But even 5 seconds is annoyingly long for an embedded system.

That's for compressed kernel and initrd.  I wanted to compare apples
to apples.

You can put an uncompressed kernel and ROM file system in the Flash.
Just copy the kernel (or kernel data) to RAM and you are all set.  That
should boot pretty fast.

The trouble with using Linux is you have lots of choices.  You actually
have to _think_ about which is best for you and how you want to
implement the solution.  I don't particularly like other software
packages that proclaim "we did it for you", hide the code in a binary
somewhere, and you spend your time working around their rules.

With all of the GUIs and "click here to make it happen", people have
forgotten (or never learned) to think for themselves.  I have yet to
find a (reasonable) product requirement that can't be solved with Linux.

I implement what is useful to me and my customers.  If you want
something else, and it isn't there, just do it.  I'm not going to
guess at what you may want.  My challenges have been systems with
lots of RAM and not much Flash ROM.  If you can actually purchase
the flash ROM and are happy with the high prices, go ahead and load
it up.

(I am not picking on you David, this is just a summary of past
messages :-).




	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Another try at the run-from-Flash issue for MPC8xx/MBX/custom

[Doug Rogers]

I, too, would like to run from Flash. The question for me isn't speed,
isn't cost, nor EMI effects. It is simply a matter of size. We have a
very small area in which to squeeze the parts, and the best we could do
is 32M RAM and 16M ROM. Our application code is in the 10M range (text
only, even after chopping over half of it out!), but it is expected to
grow. So for us it's not really a matter of cost or (running) speed,
since the Flash runs fast enough for our purposes.

As another constraint, our card needs to be able to run very soon after
power-up. I've hacked the LynxOS startup monitor to detect either gzip'd
or bzip2'd KDI's. I've timed the decompression of our smaller test image
and it takes over 40 seconds on a 40MHz MBX860 board. That's too slow.
We could live with 20, perhaps, but not much more than that. For now I
boot my images over the network since our MBX board has only 4M Flash.
It's faster than decompressing!

With LynxOS, we're able to keep in Flash both the text sections of the
kernel AND of all binaries on the filesystem. Wow! That allows us to put
only the RAM disk and vector/data/bss sections into RAM. Shweet!

I was hoping that Linux was to that point, but apparently not. Just
having the kernel run from ROM would be helpful for now, so if anyone
out there has done so, I'd be very appreciative of any feedback.

Thanks!

Doug

--
--_._-__-____------_--_-_-_-___-___-____-_--_-___--____-___--_-__--___-_
Doug Rogers, ICI   | The strongest reason for the people to retain the
V:703.893.2007x220 | right to keep and bear arms is, as a last resort,
www.innocon.com    | to protect themselves against tyranny in
___________________| Government. [Thomas Jefferson]


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Another try at the run-from-Flash issue for MPC8xx/MBX/custom

[Dan Malek]

Doug Rogers wrote:

> ..... It is simply a matter of size.

So, what methods are you planning to use for storing the applications,
libraries and other files you need to use and update?

> ....... I've timed the decompression of our smaller test image
> and it takes over 40 seconds on a 40MHz MBX860 board. That's too slow.

You are doing something very wrong.  I have worked on production
set top boxes that uncompress a kernel and 16 Mbyte ram disk from an
8-bit flash rom that are executing in the application in under 5 seconds.
This is a 50 Mhz 860......turn on some caches, align some data, use
faster memory.....


> I was hoping that Linux was to that point, but apparently not. Just
> having the kernel run from ROM would be helpful for now,

That saves only about 800K or so of memory.  If you are counting bytes
at that level you are in trouble already.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Another try at the run-from-Flash issue for MPC8xx/MBX/custom

[Markus Sundberg]

Doug Rogers <rogers@innocon.com> writes:

> I, too, would like to run from Flash. The question for me isn't speed,
> isn't cost, nor EMI effects. It is simply a matter of size. We have a
> very small area in which to squeeze the parts, and the best we could do
> is 32M RAM and 16M ROM. Our application code is in the 10M range (text
> only, even after chopping over half of it out!), but it is expected to
> grow. So for us it's not really a matter of cost or (running) speed,
> since the Flash runs fast enough for our purposes.
>
> As another constraint, our card needs to be able to run very soon after
> power-up. I've hacked the LynxOS startup monitor to detect either gzip'd
> or bzip2'd KDI's. I've timed the decompression of our smaller test image
> and it takes over 40 seconds on a 40MHz MBX860 board. That's too slow.
> We could live with 20, perhaps, but not much more than that. For now I
> boot my images over the network since our MBX board has only 4M Flash.
> It's faster than decompressing!
>
> With LynxOS, we're able to keep in Flash both the text sections of the
> kernel AND of all binaries on the filesystem. Wow! That allows us to put
> only the RAM disk and vector/data/bss sections into RAM. Shweet!
>
> I was hoping that Linux was to that point, but apparently not.

I haven't seen anyone say it couldn't be done. I wrote:

  Well, I see no reason why it shouldn't be possible, but not without
  modifying things.

  You'd need to link the .data, .data.cacheline_aligned, .data.init
  and .bss sections so they are located in RAM, and the former
  three plus the exception vectors would have to be copied from flash
  to their linked location.

I haven't tried it myself though.

//Marcus
--
Signature under construction, please come back later.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Another try at the run-from-Flash issue for MPC8xx/MBX/custom

[Richard Hendricks]

Doug,
  Do you have the I-Cache enabled when decompressing?  What about
disabling serialization? (Set ICTRL to 0x7)

Doug Rogers wrote:
>
> I, too, would like to run from Flash. The question for me isn't speed,
> isn't cost, nor EMI effects. It is simply a matter of size. We have a
> very small area in which to squeeze the parts, and the best we could do
> is 32M RAM and 16M ROM. Our application code is in the 10M range (text
> only, even after chopping over half of it out!), but it is expected to
> grow. So for us it's not really a matter of cost or (running) speed,
> since the Flash runs fast enough for our purposes.
>
> As another constraint, our card needs to be able to run very soon after
> power-up. I've hacked the LynxOS startup monitor to detect either gzip'd
> or bzip2'd KDI's. I've timed the decompression of our smaller test image
> and it takes over 40 seconds on a 40MHz MBX860 board. That's too slow.
> We could live with 20, perhaps, but not much more than that. For now I
> boot my images over the network since our MBX board has only 4M Flash.
> It's faster than decompressing!
>
> With LynxOS, we're able to keep in Flash both the text sections of the
> kernel AND of all binaries on the filesystem. Wow! That allows us to put
> only the RAM disk and vector/data/bss sections into RAM. Shweet!
>
> I was hoping that Linux was to that point, but apparently not. Just
> having the kernel run from ROM would be helpful for now, so if anyone
> out there has done so, I'd be very appreciative of any feedback.
>
> Thanks!
>
> Doug
>
> --
> --_._-__-____------_--_-_-_-___-___-____-_--_-___--____-___--_-__--___-_
> Doug Rogers, ICI   | The strongest reason for the people to retain the
> V:703.893.2007x220 | right to keep and bear arms is, as a last resort,
> www.innocon.com    | to protect themselves against tyranny in
> ___________________| Government. [Thomas Jefferson]
>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/