[ECOS] i386 / pc virtual vectors (RedBoot)

[ECOS] i386 / pc virtual vectors (RedBoot)

[Jesper Skov]

Hi

I think I'll try to find some time next week to add virtual vectors to
the i386/PC target - after that is in place, getting RedBoot up and
running should be simple.

However, since I never played with PCs when assembly was The Thing to
use, I basically have no clue of how it all fits together.

So I was hoping I might find some help here. For starters just where
to put the VSR table and virtual vector table, since these need to be
at an absolutely (and static regardless of startup type) addressed
location. 

I see that the lower 4kB are untouched in the memory map - can the VSR
table (0x100 bytes) and virtual vector table (0x100) fit in there, or
is it all used up by magic Intel vector tables and CPU bug fixes? :)

I'll also need some help with testing when I'm done, but more about
that when I get there.

Thanks,
Jesper

RE: [ECOS] i386 / pc virtual vectors (RedBoot)

[Gary Thomas]

Be sure and look at the patches from Fabrice.  I'm pretty sure he's
already tackled many of these "mountains."

On 05-Jan-2001 Jesper Skov wrote:
> Hi
> 
> I think I'll try to find some time next week to add virtual vectors to
> the i386/PC target - after that is in place, getting RedBoot up and
> running should be simple.
> 
> However, since I never played with PCs when assembly was The Thing to
> use, I basically have no clue of how it all fits together.
> 
> So I was hoping I might find some help here. For starters just where
> to put the VSR table and virtual vector table, since these need to be
> at an absolutely (and static regardless of startup type) addressed
> location. 
> 
> I see that the lower 4kB are untouched in the memory map - can the VSR
> table (0x100 bytes) and virtual vector table (0x100) fit in there, or
> is it all used up by magic Intel vector tables and CPU bug fixes? :)
> 
> I'll also need some help with testing when I'm done, but more about
> that when I get there.
> 
> Thanks,
> Jesper

Re: [ECOS] i386 / pc virtual vectors (RedBoot)

[Jonathan Larmour]

Jesper Skov wrote:
> I think I'll try to find some time next week to add virtual vectors to
> the i386/PC target - after that is in place, getting RedBoot up and
> running should be simple.

As Gary has already pointed out, Fabrice has already done it all. And as of
yesterday we are now in a position to legally use his patches (finally!).
 
> However, since I never played with PCs when assembly was The Thing to
> use, I basically have no clue of how it all fits together.
> 
> So I was hoping I might find some help here. For starters just where
> to put the VSR table and virtual vector table, since these need to be
> at an absolutely (and static regardless of startup type) addressed
> location.
> 
> I see that the lower 4kB are untouched in the memory map - can the VSR
> table (0x100 bytes) and virtual vector table (0x100) fit in there, or
> is it all used up by magic Intel vector tables and CPU bug fixes? :)

Yes it's the interrupt/exception vector table location.

We should be integrating Fabrice's patches really, and I was intending to
do so soon[1]. If you want to do it instead, feel free, but I believe that
Fabrice's patches may break the linux synthetic target.

Just in general, IMHO we should move the linux synthetic target out of the
i386 HAL. There isn't enough commonality to cause all the fudging and
potential for breaking that there is now. But that's for later...

Jifl

[1] "Free" time permitting, sigh.
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: [ECOS] i386 / pc virtual vectors (RedBoot)

[Jesper Skov]

>>>>> "Jonathan" == Jonathan Larmour <jlarmour@redhat.com> writes:
Jonathan> We should be integrating Fabrice's patches really, and I was
Jonathan> intending to do so soon[1]. If you want to do it instead,
Jonathan> feel free, but I believe that Fabrice's patches may break
Jonathan> the linux synthetic target.

I'll leave it to you then. Thanks.

Jonathan> Just in general, IMHO we should move the linux synthetic
Jonathan> target out of the i386 HAL. There isn't enough commonality
Jonathan> to cause all the fudging and potential for breaking that
Jonathan> there is now. But that's for later...

Hmm... I think I agree. It is very different from our other
HALs. 

Maybe we should (at some time) add a 'linux' architecture which should
have platforms that are really support for various linux
architectures. The system level/signal code should be generic enough
to be used on all linux architectures.

Similar, when someone eventually writes a windows virtual HAL, it
should go in 'windows' architecture.

Jesper