[ECOS] i386 Memory Size Problem

[ECOS] i386 Memory Size Problem

[kevin_lemay]

There appears to be an issue with the pcmb_misc.c file where it determines to actual amount of extended memory available.

It is reading bytes 0x17 and 0x18 from the CMOS which limits the RAM size to 64MB.

I was trying to find the proper way to find out the memory size, and found the following on the web.

Use BIOS calls: 
INT 15h AX=E820h (32-bit CPU only). If this fails... 
...use INT 15h AX=E801h. If this fails... 
...use INT 15h AH=88h. 
Read the extended memory size from CMOS only if all of the BIOS calls listed above fail. 

How do I do this with eCos?

I have a large application that I am porting that allocates lots of ram. I need more than 64MB.

Kevin

-- 
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] i386 Memory Size Problem

[Nick Garnett]

kevin_lemay@agilent.com writes:

> There appears to be an issue with the pcmb_misc.c file where it determines to actual amount of extended memory available.
> 
> It is reading bytes 0x17 and 0x18 from the CMOS which limits the RAM size to 64MB.
> 
> I was trying to find the proper way to find out the memory size, and found the following on the web.
> 
> Use BIOS calls: 
> INT 15h AX=E820h (32-bit CPU only). If this fails... 
> ...use INT 15h AX=E801h. If this fails... 
> ...use INT 15h AH=88h. 
> Read the extended memory size from CMOS only if all of the BIOS calls listed above fail. 
> 
> How do I do this with eCos?
> 
> I have a large application that I am porting that allocates lots of ram. I need more than 64MB.
> 

You would need to put this code into the real mode startup code in
pcmb.inc or platform.inc. There's already calls to INT 15h AX=0x88 and
INT 12h there which just push the results, but then does nothing with
them -- I think this must be obsolete code. So the right thing to do is
probably to pull the pushed values after the switch to protected mode
and store them in cyg_hal_pcmb_memsize_base and
cyg_hal_pcmb_memsize_extended. Then just disable the options that
control the code in hal_pcmb_init().

-- 
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

Re: [ECOS] i386 Memory Size Problem

[Nick Garnett]

<kevin_lemay@agilent.com> writes:

> It appears that Linux uses hard coded memory addresses to store the
> memory map and size, switches to protected mode and then accesses
> the saved data in ram.
> 
> I attempted to use this same method, but it does not appear to be
> running. I added new character outputs to the display during boot
> which do not appear. Any ideas on what I am doing wrong?

Maybe you have chosen some inconvenient addresses. Does the
application work if it does not access the saved memory sizes, just
uses the CMOS values? You mentioned previously that you were putting
the sizes at 1Mb and that it worked, what have you changed since then?
Make sure that your debug outputs are not corrupting things
themselves.

I'm not sure what else I can suggest.

-- 
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

RE: [ECOS] i386 Memory Size Problem

[kevin_lemay]

[-- Attachment #1: Type: text/plain, Size: 2215 bytes --]

It appears that Linux uses hard coded memory addresses to store the memory map and size, switches to protected mode and then accesses the saved data in ram.

I attempted to use this same method, but it does not appear to be running. I added new character outputs to the display during boot which do not appear. Any ideas on what I am doing wrong?

Kevin

-----Original Message-----
From: Nick Garnett [mailto:nickg@ecoscentric.com]
Sent: Wednesday, November 26, 2003 2:49 AM
To: kevin_lemay@agilent.com
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] i386 Memory Size Problem


kevin_lemay@agilent.com writes:

> It appears to not be that easy.....
> 
> The BIOS calls may only be made in real mode. Redboot initializes
> the CPU, makes the required BIOS calls and switches to protected
> mode. Then thru TFTP, GDB, etc, loads an application and executes
> it.
> 
> So I would be able to perform the operations in RedBoot.
>

Good point, I hadn't realized that this is what you wanted to do.


> How do redboot and the loaded application work together? I know that
> portions of redboot continue to run. It appears that redboot owns
> the lower 640K of space and applications are always loaded starting
> at the 1MB boundary. I know that the pcmb_misc.c file is run, at
> least, by the application.
> 
> I do not know where to look for a way to pass data between them, but
> it must already been done for them to share CPU for debugging.

The ususal mechanism is via the virtual vectors. The application can
make calls back into RedBoot to do things like serial IO and fetch
things from the flash.

The virtual vector interface is implemented in the hal/common files:
hal_if.h and hal_if.c. 

> 
> I modified pcmb_misc to poke values at the 1Mb boundaries and read
> it back that appear to work correctly. I am having trouble
> envisioning what the proper solution looks like.
> 

The proper solution is probably to add a new virtual vector entry that
allows an eCos app to call the HAL_MEM_REAL_REGION_TOP() macro in
RedBoot.


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

[-- Attachment #2: pcmb.inc --]
[-- Type: application/octet-stream, Size: 14165 bytes --]

#ifndef CYGONCE_HAL_PCMB_INC
#define CYGONCE_HAL_PCMB_INC
##=============================================================================
##
##      pcmb.inc
##
##      PC platform support
##
##=============================================================================
#####ECOSGPLCOPYRIGHTBEGIN####
## -------------------------------------------
## This file is part of eCos, the Embedded Configurable Operating System.
## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
##
## eCos is free software; you can redistribute it and/or modify it under
## the terms of the GNU General Public License as published by the Free
## Software Foundation; either version 2 or (at your option) any later version.
##
## eCos is distributed in the hope that it will be useful, but WITHOUT ANY
## WARRANTY; without even the implied warranty of MERCHANTABILITY or
## FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
## for more details.
##
## You should have received a copy of the GNU General Public License along
## with eCos; if not, write to the Free Software Foundation, Inc.,
## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
##
## As a special exception, if other files instantiate templates or use macros
## or inline functions from this file, or you compile this file and link it
## with other works to produce a work based on this file, this file does not
## by itself cause the resulting work to be covered by the GNU General Public
## License. However the source code for this file must still be made available
## in accordance with section (3) of the GNU General Public License.
##
## This exception does not invalidate any other reasons why a work based on
## this file might be covered by the GNU General Public License.
##
## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc.
## at http://sources.redhat.com/ecos/ecos-license/
## -------------------------------------------
#####ECOSGPLCOPYRIGHTEND####
##=============================================================================
#######DESCRIPTIONBEGIN####
##
## Author(s):   jskov
## Contributors:jskov, pjo, nickg
## Date:        1999-01-07
## Purpose:     PC platform support
## Description: This file contains any PC specific assembler macros needed to
##		run eCos on a standard i386 PC.
##
##
######DESCRIPTIONEND####
##
##=============================================================================


##=============================================================================
## CPU initialization

#ifndef CYGPKG_HAL_I386_CPU_INIT_DEFINED
	
#ifdef CYG_HAL_STARTUP_FLOPPY

#define CYGPKG_HAL_I386_CPU_INIT_DEFINED

	.macro 	hal_cpu_init

	/* This code is loaded from a floppy disk when the PC powers up.  */

	.code16

	.extern _end

	sectorsPerTrack = 18
	bytesPerSector = 512
	esPerSector = 32	/* = 512/16 */

	cld				/* always count up. */

	/* Configure a stack that we can use. */
	
	movl 	$_start, %eax
	movw 	%ax, %sp
	shr 	$4, %eax
	andl 	$0xF000, %eax
	movw 	%ax, %ss

# Get memory size (extended mem, kB)
	movw	$(0x0E*256+'M'), %ax	/* print a 2 */
	int	$0x10

#define E820MAP	0x2d0		/* our map */
#define E820MAX	32		/* number of entries in E820MAP */
#define E820NR	0x1e8		/* # entries in E820MAP */

	xorl	%eax, %eax
	movl	%eax, (0x1e0)
	movb	%al, (E820NR)
# Try three different memory detection schemes.  First, try
# e820h, which lets us assemble a memory map, then try e801h,
# which returns a 32-bit memory size, and finally 88h, which
# returns 0-64m

# method E820H:
# the memory map from hell.  e820h returns memory classified into
# a whole bunch of different types, and allows memory holes and
# everything.  We scan through this memory map and build a list
# of the first 32 memory areas, which we return at [E820MAP].
# This is documented at http://www.teleport.com/~acpi/acpihtml/topic245.htm

#define SMAP  0x534d4150

meme820:
	xorl	%ebx, %ebx			# continuation counter
	movw	$E820MAP, %di			# point into the whitelist
						# so we can have the bios
						# directly write into it.

jmpe820:
	movl	$0x0000e820, %eax		# e820, upper word zeroed
	movl	$SMAP, %edx			# ascii 'SMAP'
	movl	$20, %ecx			# size of the e820rec
	pushw	%ds				# data record.
	popw	%es
	int	$0x15				# make the call
	jc	bail820				# fall to e801 if it fails

	cmpl	$SMAP, %eax			# check the return is `SMAP'
	jne	bail820				# fall to e801 if it fails

#	cmpl	$1, 16(%di)			# is this usable memory?
#	jne	again820

	# If this is usable memory, we save it by simply advancing %di by
	# sizeof(e820rec).
	#
good820:
	movb	(E820NR), %al			# up to 32 entries
	cmpb	$E820MAX, %al
	jnl	bail820

	incb	(E820NR)
	movw	%di, %ax
	addw	$20, %ax
	movw	%ax, %di

	movw	$(0x0E*256+'G'), %ax	/* print a G */
	int	$0x10
again820:
	cmpl	$0, %ebx			# check to see if
	jne	jmpe820				# %ebx is set to EOF
bail820:

	movw	$(0x0E*256+'B'), %ax	/* print a B */
	int	$0x10



# method E801H:
# memory size is in 1k chunksizes, to avoid confusing loadlin.
# we store the 0xe801 memory size in a completely different place,
# because it will most likely be longer than 16 bits.
# (use 1e0 because that's what Larry Augustine uses in his
# alternative new memory detection scheme, and it's sensible
# to write everything into the same place.)

meme801:
	stc					# fix to work around buggy
	xorw	%cx,%cx				# BIOSes which dont clear/set
	xorw	%dx,%dx				# carry on pass/error of
						# e801h memory size call
						# or merely pass cx,dx though
						# without changing them.
	movw	$0xe801, %ax
	int	$0x15
	jc	mem88

	cmpw	$0x0, %cx			# Kludge to handle BIOSes
	jne	e801usecxdx			# which report their extended
	cmpw	$0x0, %dx			# memory in AX/BX rather than
	jne	e801usecxdx			# CX/DX.  The spec I have read
	movw	%ax, %cx			# seems to indicate AX/BX 
	movw	%bx, %dx			# are more reasonable anyway...

e801usecxdx:
	andl	$0xffff, %edx			# clear sign extend
	shll	$6, %edx			# and go from 64k to 1k chunks
	movl	%edx, (0x1e0)			# store extended memory size
	andl	$0xffff, %ecx			# clear sign extend
 	addl	%ecx, (0x1e0)			# and add lower memory into
						# total size.
	movw	$(0x0E*256+'1'), %ax	/* print a 1 */
	int	$0x10

# Ye Olde Traditional Methode.  Returns the memory size (up to 16mb or
# 64mb, depending on the bios) in ax.
mem88:

	/* Ask the BIOS for info about the amount of RAM available.  We push
         * these onto the stack for later use.
	 */
	
	xorl 	%eax, %eax
	movb 	$0x88, %ah		/* Get the amount of extended memory. */
	int 	$0x15
	shl 	$10, %eax

	pushl 	%eax

	xorl	%eax, %eax
	int	$0x12			/* Get the amount of standard memory. */
	shl	$10, %eax
	pushl	%eax

	/* reset floppy */
	movb $0,%ah
	movb $0,%dl
	int $0x13
	jc _error1
	
	/* Read the rest of the image to _start.  This code works by reading
	   only one sector at a time to avoid "buffer cross 64k boundary" fatal
	   problem... This is slow but should work in almost all situations.
	   _start should be aligned on a 512 bytes boundary to be sure.
	*/
	
	/* destination pointer es:bx */
	/* With correct alignement, bx should be 0 and es should be a multiple
         * of 32. If not it may cause the "buffer cross 64k boundary" problem
         * (cf above)
	 */  
	movl	$_start,%eax
	movw	%ax,%bx
	andw	$0xF,%bx
	shrl	$4,%eax
	movw	%ax, %es

	/* initials head/track/sector */
	movw	$0,%dx
	movw	$1,%cx

	movl	$_edata,%edi
	addl	$(bytesPerSector-1),%edi
	shrl	$4,%edi
	
	jmp	_loadsector

_nextsector:
	movw	%es,%ax
	cmpw	%di,%ax
	jge	_endload
	addw	$esPerSector,%ax
	movw	%ax,%es
	incb	%cl
        cmpb	$sectorsPerTrack, %cl 
        jbe	_loadsector	/* next head ?*/
	movb	$1, %cl
        incb	%dh    
        cmpb	$1, %dh
        je	_loadsector	/* next track ? */
        movb	$0, %dh
        incb	%ch    

_loadsector:

	pushw	%es
	pushw	%di
	movw	$0x0201, %ax
	clc
	int	$0x13
	popw	%di
	popw	%es
	jc _error2

	movw	$(0x0E*256+'.'), %ax	/* print a dot */
	int	$0x10

	/* So go ahead and resume execution at the real starting address.  This
	only serves to move us quickly to the real starting location; and has
	no effect after reading additional tracks.  If we didn't jump after
	reading the first track, then we limit ourselves to reading images of
	30k bytes max before overwriting ourselves at 0x7C00.
	*/

	ljmp $0,$_nextsector	

_error1:
	movw	$(0x0E*256+'1'), %ax	/* print a ! */
	int	$0x10	
	jmp	_error

_error2:
	mov	%ah,%al
	pushw	%ax
	shrw	$4,%ax
	andw	$15,%ax
	addw	$0x0E41,%ax
	int	$0x10
	popw	%ax
	andw	$15,%ax
	addw	$0x0E41,%ax
	int	$0x10
	
	movw	$(0x0E*256+'2'), %ax	/* print a ! */
	int	$0x10
	jmp	_error
		
_error:		/* halt on error */
	movw	$(0x0E*256+'!'), %ax	/* print a ! */
	int	$0x10

	cli
	hlt
	jmp _start


        /* Write the 0x55/0xAA signature at the end of the first
	block.  Without this signature the BIOS won't consider this
	block to be bootable.  
	*/
	
	. = _start + 510
	.byte	0x55
	.byte	0xAA

_endload:
1:

	/* Lets be nice and wait for the diskette drive motor to go off
         * before continuing. */
	
	movw	$0x40, %ax
	movw	%ax, %es
	movl	$0x40, %ebx
2:	es
	movb	(%bx), %al
	cmpb	$0, %al
	jne	2b

	/* Now we're all loaded up in memory. */

	/* Optionally switch to a high-res video before entering	*/
	/* protected mode. The mode is controlled by an option in	*/
	/* the RedBoot configuration, which is not readily visible	*/
	/* in the application configuration. Therefore RedBoot also	*/
	/* performs some information-related BIOS calls, getting the	*/
	/* main SVGA BIOS information and the mode-specific		*/
	/* information. These are placed in video memory, because	*/
	/* nothing else should be touching that and it avoids having	*/
	/* some other special buffer shared between RedBoot and the	*/
	/* application. The disadvantage is possibly some strange junk	*/
	/* visible on the screen after RedBoot has started.		*/
#ifdef CYGNUM_HAL_I386_PC_STARTUP_VIDEO_MODE
	movw	$0x4f02, %ax
	movw	$ CYGNUM_HAL_I386_PC_STARTUP_VIDEO_MODE, %bx
	int	$0x10

	/* SVGA information @ 0x000A0000 */
	/* Placing VBE2 at this location before the int10 gives more information */
	movw	$0xA000, %ax
	movw	%ax, %es
	movw	$0x0, %di
	movb	$('V'), %es:0(%di)
	movb	$('B'), %es:1(%di)
	movb	$('E'), %es:2(%di)
	movb	$('2'), %es:3(%di)
	movw	$0x4f00, %ax
	int 	$0x10

	/* Information about all supported modes starting @ 0x000A0400	*/
	/* ds:si is used to index the main mode table, offset 14	*/
	movw	%es:14(%di),%si
	movw	%es:16(%di),%ax
	movw	%ax,%ds

	/* es:di is used for the destination.				*/
	movw	$0xA000,%ax
	movw	%ax,%es
	movw	$0x0400,%di

modes_loop:
	/* The mode table is terminated by a -1 entry			*/
	movw	%ds:0(%si), %cx
	cmpw	$0xffff,%cx
	je	modes_done
	movw	$0x4f01, %ax
	int	$0x10
	addw	$0x0100, %di
	addw	$2,%si
	jmp	modes_loop
modes_done:

	/* Information about the current mode @ 0x000A0200	*/
	movw	$0xA000, %ax
	movw	%ax, %es
	movw	$0x0200, %di
	movw	$0x4f01, %ax
	movw	$ CYGNUM_HAL_I386_PC_STARTUP_VIDEO_MODE, %cx
	int	$0x10
#endif

	/* Disable interrupt handling. */
	cli

	/* Load GDTR and IDTR. */

	lgdt	%cs:gdt
	lidt	%cs:idt

	/* Switch to protected mode. */
	movl	%cr0,%eax
	orb	$1, %al
	movl	%eax,%cr0
	ljmp	$8, $3f

	hlt

	.align	4, 0xFF
gdt:
	.word	gdtEnd - gdtStart
	.long	gdtStart

	.align	4, 0xFF
idt:
	.extern idtStart
	.word	0x07FF		# space for 256 entries
	.long	idtStart

gdtStart:
	/* Selector 0x00 == invalid. */
	.word	0x0000
	.word	0x0000
	.byte	0x00
	.byte	0x00
	.byte	0x00
	.byte	0x00

	/* Selector 0x08 == code. */
	.word	0xFFFF
	.word	0x0000
	.byte	0x00
	.byte	0x9B
	.byte	0xCF
	.byte	0x00

	/* Selector 0x10 == data. */
	.word	0xFFFF
	.word	0x0000
	.byte	0x00
	.byte	0x93
	.byte	0xCF
	.byte	0x00

	/* Selector 0x18 == shorter code: faults any code 
         * access 0xF0000000-0xFFFFFFFF.
         */
	.word	0xFFFF
	.word	0x0000
	.byte	0x00
	.byte	0x9B
	.byte	0xC7
	.byte	0x00

	/* Selector 0x20 == data; faults any access 0xF0000000-0xFFFFFFFF. */
	.word	0xFFFF
	.word	0x0000
	.byte	0x00
	.byte	0x93
	.byte	0xC7
	.byte	0x00

	.align	4, 0xFF
gdtEnd:

	.code32
3:

	movw	$0x10, %ax
	movw	%ax, %ds
	movw	%ax, %es
	movw	%ax, %fs
	movw	%ax, %gs

	/* Make our new stack point to the same place as the old one. */
	xorl	%ebx, %ebx
	movw	%ss, %bx
	shl	$4, %ebx
	addl	%esp, %ebx
	movw	%ax, %ss
	movl	%ebx, %esp
	movl	$0, %ebp

	/* Reset the flags register. */
	pushl	$0
	popfl

hal_cpu_init_end:
        nop

	.endm /* hal_cpu_init */
	
#endif /* CYG_HAL_STARTUP_FLOPPY */

#endif // CYGPKG_HAL_I386_CPU_INIT_DEFINED

##=============================================================================
## Interrupt controller support
	
#define CYGPKG_HAL_I386_INTC_INIT_DEFINED

#ifndef CYG_HAL_STARTUP_RAM
			
	.macro	hal_intc_init
	
	# The interrupt controller is configured so that IRQ levels 0-7 trigger
	#  interrupt vector 32-39; levels 8-15 trigger 40-47.
	movb	$0x11, %al
	outb	%al, $0x20
	movb	$0x20, %al
	outb	%al, $0x21
	movb	$0x04, %al
	outb	%al, $0x21
	movb	$0x01, %al
	outb	%al, $0x21
	movb	$0xFB, %al			/* Mask off all interrupts except 2. */
	outb	%al, $0x21

	movb	$0x11, %al
	outb	%al, $0xA0
	movb	$0x28, %al
	outb	%al, $0xA1
	movb	$0x02, %al
	outb	%al, $0xA1
	movb	$0x01, %al
	outb	%al, $0xA1
	movb	$0xFF, %al			/* Mask off all interrupts. */
	outb	%al, $0xA1

	.endm /* hal_intc_init */

#else

	# No need to do any initialization in RAM startup
	.macro	hal_intc_init
	.endm	

#endif	
	
	.macro hal_intc_ack vector
	# Use any registers you like.
	movl	\vector, %edx
	movb	$0x20, %al
	cmpl	$0x20, %edx
	jl	8f
	cmpl	$0x28, %edx
	jl	9f
	outb	%al, $0xA0
9:	outb	%al, $0x20
8:	nop
	.endm
	
##=============================================================================
#endif // ifndef CYGONCE_HAL_PCMB_INC	
## end of pcmb.inc

[-- Attachment #3: Type: text/plain, Size: 146 bytes --]

-- 
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] i386 Memory Size Problem

[Nick Garnett]

kevin_lemay@agilent.com writes:

> It appears to not be that easy.....
> 
> The BIOS calls may only be made in real mode. Redboot initializes
> the CPU, makes the required BIOS calls and switches to protected
> mode. Then thru TFTP, GDB, etc, loads an application and executes
> it.
> 
> So I would be able to perform the operations in RedBoot.
>

Good point, I hadn't realized that this is what you wanted to do.


> How do redboot and the loaded application work together? I know that
> portions of redboot continue to run. It appears that redboot owns
> the lower 640K of space and applications are always loaded starting
> at the 1MB boundary. I know that the pcmb_misc.c file is run, at
> least, by the application.
> 
> I do not know where to look for a way to pass data between them, but
> it must already been done for them to share CPU for debugging.

The ususal mechanism is via the virtual vectors. The application can
make calls back into RedBoot to do things like serial IO and fetch
things from the flash.

The virtual vector interface is implemented in the hal/common files:
hal_if.h and hal_if.c. 

> 
> I modified pcmb_misc to poke values at the 1Mb boundaries and read
> it back that appear to work correctly. I am having trouble
> envisioning what the proper solution looks like.
> 

The proper solution is probably to add a new virtual vector entry that
allows an eCos app to call the HAL_MEM_REAL_REGION_TOP() macro in
RedBoot.


-- 
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

RE: [ECOS] i386 Memory Size Problem

[kevin_lemay]

It appears to not be that easy.....

The BIOS calls may only be made in real mode. Redboot initializes the CPU, makes the required BIOS calls and switches to protected mode. Then thru TFTP, GDB, etc, loads an application and executes it.

So I would be able to perform the operations in RedBoot.

How do redboot and the loaded application work together? I know that portions of redboot continue to run. It appears that redboot owns the lower 640K of space and applications are always loaded starting at the 1MB boundary. I know that the pcmb_misc.c file is run, at least, by the application.

I do not know where to look for a way to pass data between them, but it must already been done for them to share CPU for debugging.

I modified pcmb_misc to poke values at the 1Mb boundaries and read it back that appear to work correctly. I am having trouble envisioning what the proper solution looks like.

Kevin

-----Original Message-----
From: Nick Garnett [mailto:nickg@ecoscentric.com]
Sent: Tuesday, November 25, 2003 9:30 AM
To: kevin_lemay@agilent.com
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] i386 Memory Size Problem


kevin_lemay@agilent.com writes:

> Nick,
> 
> I found some sample code that makes the calls that I need.
> 
> Are there any examples of storing to the c/C++ variables that would
> help me to do the port?

Writing to C++ variables is slightly hard since you need to handle the
name mangling. So it's best to always use C variables from assembler.
A straighforward movl will do the trick.


-- 
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

Re: [ECOS] i386 Memory Size Problem

[Nick Garnett]

kevin_lemay@agilent.com writes:

> Nick,
> 
> I found some sample code that makes the calls that I need.
> 
> Are there any examples of storing to the c/C++ variables that would
> help me to do the port?

Writing to C++ variables is slightly hard since you need to handle the
name mangling. So it's best to always use C variables from assembler.
A straighforward movl will do the trick.


-- 
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

RE: [ECOS] i386 Memory Size Problem

[kevin_lemay]

Nick,

I found some sample code that makes the calls that I need.

Are there any examples of storing to the c/C++ variables that would help me to do the port?

Kevin 

-----Original Message-----
From: nickg@miso.calivar.com [mailto:nickg@miso.calivar.com]On Behalf Of
Nick Garnett
Sent: Tuesday, November 25, 2003 2:58 AM
To: LEMAY,KEVIN (A-Roseville,ex1)
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] i386 Memory Size Problem


kevin_lemay@agilent.com writes:

> There appears to be an issue with the pcmb_misc.c file where it determines to actual amount of extended memory available.
> 
> It is reading bytes 0x17 and 0x18 from the CMOS which limits the RAM size to 64MB.
> 
> I was trying to find the proper way to find out the memory size, and found the following on the web.
> 
> Use BIOS calls: 
> INT 15h AX=E820h (32-bit CPU only). If this fails... 
> ...use INT 15h AX=E801h. If this fails... 
> ...use INT 15h AH=88h. 
> Read the extended memory size from CMOS only if all of the BIOS calls listed above fail. 
> 
> How do I do this with eCos?
> 
> I have a large application that I am porting that allocates lots of ram. I need more than 64MB.
> 

You would need to put this code into the real mode startup code in
pcmb.inc or platform.inc. There's already calls to INT 15h AX=0x88 and
INT 12h there which just push the results, but then does nothing with
them -- I think this must be obsolete code. So the right thing to do is
probably to pull the pushed values after the switch to protected mode
and store them in cyg_hal_pcmb_memsize_base and
cyg_hal_pcmb_memsize_extended. Then just disable the options that
control the code in hal_pcmb_init().

-- 
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