James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> ebiederm@xmission.com said:
> > Yes. I'm totally for the ability to select from config.in. But at
> > the same time having being able to build a kernel that works in all
> > kinds of configurations comes in quite handy. I know the alpha does
> > this I'm not quite certain about ARM.
>
> The alpha uses a machine type function table switch to achieve this. It's
> certainly possible, just slightly more than I bargained for.
>
> The issue will become more interesting with Patrick's cpu/bus/mtrr switch,
> where self configuration does become more of an issue. Can I just wait to see
> what he comes up with and then copy it?
Sounds reasonable. What I care about is that we have the goals straight at least.
> > Do you have boot problems on the NCR voyagers? If so I'd be
> > interested in hearing what the issues are.
>
> 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.
It sounds like we may have been getting lucky on that one. I guess an explicit
align directive fixes that.
> Not all boot managers work on voyager: grub and syslinux don't, lilo does (for
> now) but complains that EBDA is too big.
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.
What was the gate a20 issue, you fixed in setup.S?
> I think it's because they actually have a larger than 384k hole (low memory
> seems to end at 588k instead of 640k), but I was just so relieved to get them
> to boot finally that I've never explored the problems in detail.
That could be it. But there have been enough systems with that
problem I would have thought the various bootloaders would have
already handled it. syslinux especially.
> This is the actual memory map:
>
> BIOS-provided physical RAM map:
> Voyager-SUS: 0000000000000000 - 0000000000093000 (usable)
> ^^^^^ usually around 9fffff
> Voyager-SUS: 0000000000100000 - 000000003ffff000 (usable)
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 :)
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Apr 23 2002 - 22:00:17 EST