headers
Giovanni Visciano | 1 May 2007 20:10
Picon
Favicon

page mapping


PC config.

Introduction:
*************
- mmu_init() [sys/arch/i386/i386/mmu.c]:
1) We get the number of pages that the installed RAM can contain:
nr_page = boot_info->main_mem.size / PAGE_SIZE;

2) and the number of Page Table (2^ level paging) needed to
address "nr_page" pages:
nr_pte = (nr_page + 1023) / 1024;

3) Then the Page Directory (1^ level paging) index, this is the entry for
the virtual address 2G.
pgd_index = PAGE_DIR(PAGE_OFFSET)     (=512)

Question/problem:
*****************
- Build kernel page tables for WHOLE physical pages:
If the installed RAM size is >2GB, how can we cover all the physical pages?

A) Number of Page Directory Entries problem.
For example, with 3GB of RAM we have: nr_page=786432, nr_pte=768.
Starting from kernel_pgd[512] and going up to kernel_pgd[1023] there is  
only
space for 512 Page Directory Entries, thereby for 2GB of RAM covered by
4KB pages.

B) 4GB RAM problem.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kohsuke Ohtani | 2 May 2007 03:28
Picon

Re: struct desc_p - packing

Giovanni Visciano wrote:
> If we use the "packed attribute" for the
> struct desc_p (sys/arch/i386/i386/cpu.h)
> no padding is introduced by the compiler.
> So, there is no need to pad the structure fields to
> long boundary.

Patch is applied.
Thanks.

- Kohsuke

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Permalink | Reply | 0 comments |
headers
Kohsuke Ohtani | 2 May 2007 03:40
Picon

Re: page mapping

Giovanni Visciano wrote:
> If the installed RAM size is >2GB, how can we cover all the physical pages?

You have to use PSE (page size extension) in such case. But, I believe 
almost embedded systems don't have memory over 2G bytes.

- Kohsuke

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Permalink | Reply | 1 comment |
headers
Giovanni Visciano | 2 May 2007 08:07
Picon
Favicon

Re: page mapping

Kohsuke Ohtani wrote:

> You have to use PSE (page size extension) in such case. But, I believe  
> almost embedded systems don't have memory over 2G bytes.

I think PSE can't solve the problem.
Page_Size_Extension can be used to select a larger page size of 4MB
(vs 4KB standard size).
But with 4MB page size (PSE bit set), page tables (2^ level paging)
are not used. The entries in the page directory point to 4-MByte pages
in PHYSICAL memory. This paging method can be used to map UP TO 1024
pages into a 4-GByte linear address space.

So, with this scheme, is PREX DESIGNED to support at most 2GB of memory?
(Note: if this is what we want, we would have to limit the memory size
detected via BIOS call, setting the size to 2GB if greater than this limit)

Thanks.
Giovanni

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Permalink | Reply | 0 comments |
headers
Rob Wehrli | 2 May 2007 20:32

Re: struct desc_p - packing

On Mon, 30 Apr 2007 03:23:23 -0400, Giovanni Visciano  
<giovanni_visciano <at> yahoo.it> wrote:

>   /*
>    * Linear memory description for lgdt and lidt instructions.
> - * The compiler tries to put l_addr on a long boundary, so you
> - * must use &l.limit as the argument to lgdt() and friends.
>    */
>   struct desc_p {
> -       u_short pad;
>          u_short limit;
>          u_long base;
>   } __attribute__ ((packed));
>

I'm just wondering if this creates a dependency on GCC within Prex?   
Compilers who do not understand the directive may make compilation under  
different compilers/toolchains more difficult.  (Not that anyone is  
considering it, but just a point-of-order.)

Is the expectation that Prex will always be compiled for whatever platform  
using a GCC compiler (or compatible) variant?

Take Care.

Rob!

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
(Continue reading)

Permalink | Reply | 3 comments |
headers
Andrew Dennison | 4 May 2007 14:01
Picon

Re: struct desc_p - packing

On 5/3/07, Rob Wehrli <rwehrli <at> azpower.com> wrote:
> On Mon, 30 Apr 2007 03:23:23 -0400, <giovanni_visciano <at> yahoo.it> wrote:
>
>
> >   /*
> >    * Linear memory description for lgdt and lidt instructions.
> > - * The compiler tries to put l_addr on a long boundary, so you
> > - * must use &l.limit as the argument to lgdt() and friends.
> >    */
> >   struct desc_p {
> > -       u_short pad;
> >          u_short limit;
> >          u_long base;
> >   } __attribute__ ((packed));
> >
>
> I'm just wondering if this creates a dependency on GCC within Prex?
> Compilers who do not understand the directive may make compilation under
> different compilers/toolchains more difficult.

__attribute__(()) wasn't added by the patch ;)

You can write a macro to effectively remove this directive when using
an alternate compiler. There is some info in the gcc help on this, but
this does the trick:

#define __attribute__()

There would be a bit more work required to use an alternate compiler,
but this only makes sense to me if you are using a processor not
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kohsuke Ohtani | 5 May 2007 02:06
Picon

Re: struct desc_p - packing

Andrew Dennison wrote:
> On 5/3/07, Rob Wehrli <rwehrli <at> azpower.com> wrote:
>> On Mon, 30 Apr 2007 03:23:23 -0400, <giovanni_visciano <at> yahoo.it> wrote:
>>
>>
>>>   /*
>>>    * Linear memory description for lgdt and lidt instructions.
>>> - * The compiler tries to put l_addr on a long boundary, so you
>>> - * must use &l.limit as the argument to lgdt() and friends.
>>>    */
>>>   struct desc_p {
>>> -       u_short pad;
>>>          u_short limit;
>>>          u_long base;
>>>   } __attribute__ ((packed));
>>>
>> I'm just wondering if this creates a dependency on GCC within Prex?
>> Compilers who do not understand the directive may make compilation under
>> different compilers/toolchains more difficult.
> 
> __attribute__(()) wasn't added by the patch ;)

The patch removes a pad data which is required for non-gcc compiler. So, 
this change may increase gcc dependency.

> There would be a bit more work required to use an alternate compiler,
> but this only makes sense to me if you are using a processor not
> supported by gcc.

There is strong requirement to support non-gcc compiler in embedded
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Dennison | 6 May 2007 00:07
Picon

Re: struct desc_p - packing

On 5/5/07, Kohsuke Ohtani <kohtani <at> users.sourceforge.net> wrote:
> There is strong requirement to support non-gcc compiler in embedded
> development. It seems many developers prefer native compiler provided by
> processor vendors even if gcc supports that processor architecture.

I've had to worrkaround bugs / quirks / limitations in most of the
embedded compilers I've used, and find gcc a step forward, but there
are some good alternate compilers around. The Intel compiler has some
nice benchmarks vs gcc if your target is x86.

However it is preferable to write vanilla C99 code where possible.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Permalink | Reply | 0 comments |
headers
Rob Wehrli | 15 May 2007 01:55

Multiple definitions?

Don't definitions like:

sys/arch/i386/nommu/platform.h:#define IMODE_EDGE       0               /*  
Edge trigger */
sys/arch/i386/nommu/platform.h:#define IMODE_LEVEL      1               /*  
Level trigger */
sys/arch/i386/pc/platform.h:#define IMODE_EDGE  0               /* Edge  
trigger */
sys/arch/i386/pc/platform.h:#define IMODE_LEVEL 1               /* Level  
trigger */
sys/arch/arm/gba/platform.h:#define IMODE_EDGE  0               /* Edge  
trigger */
sys/arch/arm/gba/platform.h:#define IMODE_LEVEL 1               /* Level  
trigger */

...belong in a single file or is there some greater purpose for defining  
these in each platform-specific header?  Perhaps a platform-common.h is in  
order?

Take Care.

Rob!

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Permalink | Reply | 0 comments |
headers
Rob Wehrli | 16 May 2007 20:01

Multiple interrupt types?

I see the ability to distinguish from IMODE_EDGE and IMODE_LEVEL but what  
about situations where one may trigger an interrupt on both the rising and  
falling edge of an external signal, for example?

Take Care.

Rob!

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Permalink | Reply | 0 comments |

Gmane