This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
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