[ECOS] The 640k barrier

[ECOS] The 640k barrier

[Leandro Fanzone]

I already wrote about this in another thread, but as I didn't receive an 
answer, I try to create a dedicated thread for this. I'm doing some 
testing on eCos, and I'm trying to figure out if it fits our needs. I 
wanted to quickly find out how much heap I have, so I made a floppy test 
that mallocs memory until malloc returns NULL: some 140k of heap, and 
that's it. We're planning a 2M i386 board, and though I declare through 
the mlt_i386_pc_floppy files such thing, malloc always stops when the 
pointer reaches the 640k barrier. It's also a concern for us that the 
code can't be moved to the upper meg, because the linker complains 
"relocation truncated to fit", something related to vectors.o, so I 
assume that the interrupt vectors drag the code to the lower meg, and 
therefore can't be moved that high. Our code will be large enough to 
exceed the 640k, so the best for us would be to map the code in the 
upper meg, and let data and heap in the lower 640k. Can someone help me 
with this? I already modified the mlt_i386_pc_floppy.* files, but with 
no success so far. Either I have linker errors, or it doesn't boot at 
all. The documentation isn't much explicit about the this.
Thank you in advance,

Leandro Fanzone.


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] The 640k barrier

[Andrew Lunn]

On Mon, Dec 29, 2003 at 03:49:59PM -0300, Leandro Fanzone wrote:
> I already wrote about this in another thread, but as I didn't receive an 
> answer, I try to create a dedicated thread for this. I'm doing some 
> testing on eCos, and I'm trying to figure out if it fits our needs. I 
> wanted to quickly find out how much heap I have, so I made a floppy test 
> that mallocs memory until malloc returns NULL: some 140k of heap, and 
> that's it. We're planning a 2M i386 board, and though I declare through 
> the mlt_i386_pc_floppy files such thing, malloc always stops when the 
> pointer reaches the 640k barrier. It's also a concern for us that the 
> code can't be moved to the upper meg, because the linker complains 
> "relocation truncated to fit", something related to vectors.o, so I 
> assume that the interrupt vectors drag the code to the lower meg, and 
> therefore can't be moved that high. Our code will be large enough to 
> exceed the 640k, so the best for us would be to map the code in the 
> upper meg, and let data and heap in the lower 640k. Can someone help me 
> with this? I already modified the mlt_i386_pc_floppy.* files, but with 
> no success so far. Either I have linker errors, or it doesn't boot at 
> all. The documentation isn't much explicit about the this.

Floppy startup uses the bias to load the application into memory and
this limits it to the lower 640K. 

What you want to do is use a bootloader which can access all
memory. Redboot can do this. So make a floppy redboot image. Boot that
and then use it to load your application via the serial port/ethernet
etc.

        Andrew

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] The 640k barrier

[David N. Welton]

Leandro Fanzone <leandro@hasar.com> writes:

> We're planning a 2M i386 board, and though I declare through the
> mlt_i386_pc_floppy files such thing, malloc always stops when the
> pointer reaches the 640k barrier.

You might try recompiling... a few times, or running the 'ecosconfig
tree' command.  I always found that getting this to work was a little
bit fiddly.

If you want, you can download and look at the "Scivoli" code on my
free software page (link below).  That definitely uses more than the
base 640K.

> It's also a concern for us that the code can't be moved to the upper
> meg, because the linker complains "relocation truncated to fit",
> something related to vectors.o, so I assume that the interrupt
> vectors drag the code to the lower meg, and therefore can't be moved
> that high. Our code will be large enough to exceed the 640k, so the
> best for us would be to map the code in the upper meg, and let data
> and heap in the lower 640k. Can someone help me with this?

That is a question for the real experts:-)

Good luck,
-- 
David N. Welton
   Consulting: http://www.dedasys.com/
     Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
   Apache Tcl: http://tcl.apache.org/

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] The 640k barrier

[Nick Garnett]

Leandro Fanzone <leandro@hasar.com> writes:

> I already wrote about this in another thread, but as I didn't receive
> an answer, I try to create a dedicated thread for this. I'm doing some
> testing on eCos, and I'm trying to figure out if it fits our needs. I
> wanted to quickly find out how much heap I have, so I made a floppy
> test that mallocs memory until malloc returns NULL: some 140k of heap,
> and that's it. We're planning a 2M i386 board, and though I declare
> through the mlt_i386_pc_floppy files such thing, malloc always stops
> when the pointer reaches the 640k barrier. It's also a concern for us
> that the code can't be moved to the upper meg, because the linker
> complains "relocation truncated to fit", something related to
> vectors.o, so I assume that the interrupt vectors drag the code to the
> lower meg, and therefore can't be moved that high. Our code will be
> large enough to exceed the 640k, so the best for us would be to map
> the code in the upper meg, and let data and heap in the lower
> 640k. Can someone help me with this? I already modified the
> mlt_i386_pc_floppy.* files, but with no success so far. Either I have
> linker errors, or it doesn't boot at all. The documentation isn't much
> explicit about the this.
> Thank you in advance,

The 640k limit on FLOPPY startups is there because the BIOS calls used
to access the floppy device can only load sectors into the bottom
640k. So, even if you moved the link address of the code to above the
1M barrier, it would still not load.

If it is not possible to load your program using RedBoot then take a
look at the support for using GRUB. This will load programs into the
upper memory. Take a look at the following documentation:

http://ecos.sourceware.org/docs-latest/user-guide/setup-i386-pc.html

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss