mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: ebiederm@xmission.com (Eric W. Biederman)
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i386 arch subdivision into machine types for 2.5.8
Date: Wed, 17 Apr 2002 11:31:44 -0500	[thread overview]
Message-ID: <200204171631.g3HGViA02265@localhost.localdomain> (raw)
In-Reply-To: Message from ebiederm@xmission.com (Eric W. Biederman)  of "17 Apr 2002 01:00:10 MDT." <m1it6qizd1.fsf@frodo.biederman.org>

> The 8 byte GDT alignment requirement in boot/setup.S was the biggest problem 
> (until I found it empirically), if that's not done, they crash when jumping to 
> protected mode.

ebiederm@xmission.com said:
> It sounds like we may have been getting lucky on that one.  I guess an
> explicit align directive fixes that. 

No, most CPUs don't require this alignment.  It was only a requirement of the 
voyager quad processor cards.  I can boot the system on 6 cpus (3 dyads) 
perfectly happily with the gdt anywhere.  I suspect it's because the Quad 
cards use a clever memory cache line invalidation scheme to exchange 
interprocessor interrupts, but I've never investigated.

> Interesting, so reading this and skimming your patch the voyager BIOS
> is a descendant of the XT & AT BIOS.  But it is a very weird one.

Yes, it tries to use the basic AT BIOS sequence.  It's wierd because the 
initial BIOS (actually called SUS) setup is done by a small i386 that's part 
of the baseboard (voyagers can actually boot up and tell you they don't have 
any CPUs).  This CPU does all the peripheral configuration too, so the BIOS 
that the real CPUs see is very hacked down.

The only reason they have that much BIOS functionality is because the OS they 
boot for reference disc configuration is an ancient version of DOS.

> What was the gate a20 issue, you fixed in setup.S?

Well, the a20 stuff worked pretty much OK until someone re-did the way we 
started setting and checking it.  All the #defines really do is ignore all the 
fancy a20 gate setting stuff and just use the standard one (after all, if I'm 
never going to use the code, there's not much point having it in the boot 
sequence).


> BIOS-provided physical RAM map:
>  Voyager-SUS: 0000000000000000 - 0000000000093000 (usable)
>                                             ^^^^^ usually around 9fffff
>  Voyager-SUS: 0000000000100000 - 000000003ffff000 (usable) 

ebiederm@xmission.com said:
> Certainly a different one.  I find it interesting how none of these
> maps reserve the bios interrupt table, or the BIOS data area.
> Basically the first 1280 bytes of memory...  And they just assume
> everyone will know better and not touch them :) 

Well, technically the BIOS interrupt table isn't "reserved" memory because you 
can and do relocate it and reuse the memory.  There's no e820 classification 
for "don't mess with this if you want BIOS to work but otherwise you're free 
to trash it".  "reserved" at least as far as voyager is concerned means "never 
ever treat this as ordinary memory".

The missing 0xfff at the top is the memory used to send IPIs (it actually 
overlays real memory and you can read and write it as normal memory, it will 
just cause havoc with SMP).

James



      reply	other threads:[~2002-04-17 16:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-16 15:55 James Bottomley
2002-04-16 16:46 ` Patrick Mochel
2002-04-17  0:55   ` Keith Owens
2002-04-16 19:30 ` Eric W. Biederman
2002-04-16 20:51   ` James Bottomley
2002-04-16 21:06     ` Dave Jones
2002-04-16 21:44     ` Eric W. Biederman
2002-04-16 23:27       ` James Bottomley
2002-04-16 23:43         ` H. Peter Anvin
2002-04-17  7:00         ` Eric W. Biederman
2002-04-17 16:31           ` James Bottomley [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200204171631.g3HGViA02265@localhost.localdomain \
    --to=james.bottomley@hansenpartnership.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®