This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Virtual Vector Table.


Fabrice Gautier <Fabrice_Gautier@sdesigns.com> writes:

> Currently I think the VSR table is at 0x0000. It requires 0x800 (in
> protected mode), and the Vector table require 64*8=0x200. So this could be:
> VSR Table: 0x0000
> Vector Table: 0x0800

Currently I think the VSR table is just allocated as part of the BSS
and goes into RAM at a linker-chosen address. I think it is the IDT
that is allocated at 0x0000 and thus takes 2k. The VSR table should
have space for 256 4byte entries, to match the IDT, taking 1k. And the
vector table should be at least 512 bytes.

> 
> And so you don't need to move the RedBoot load address.
> Is there anything else that should prevent me to put this table at the very
> beginning?
> 

There's no real reason at present. It's just that the BIOS puts useful
information in the bottom of RAM and in the future we might want to
get at this. By starting at 0x1000 we keep this data safe.


Having looked closer at the code I would suggest doing this:

0x00000  Preserved BIOS data
0x01000  IDT
0x01800  VSR table
0x01c00  vector table
0x02000  RedBoot/Monitor load address

0x10000  RAM executable load address. This may need to be 0x20000 or
         higher depending on the size of RedBoot. Perhaps we should
         even move to 0x100000 in extended RAM.


Of course in theory we could do away with the VSR table, and just use
the IDT. This was the original intention when adding the VSR table: to
convert all architectures into using an indirection table like the 68k
or i386. Since these architectures already use indirection tables,
there is no need to add an extra one. In theory all that is needed is
to change HAL_VSR_GET() and HAL_VSR_SET() to manipulate the IDT rather
than the VSR table. However, for now it is probably better to just
leave things as they are - if it works don't fix it.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]