Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.os.development > #8398
| From | "James Harris" <james.harris.1@gmail.com> |
|---|---|
| Newsgroups | alt.os.development |
| Subject | Re: OS startup goals and steps |
| Date | 2015-07-16 10:32 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <mo7tkt$f8r$1@dont-email.me> (permalink) |
| References | <mo2l1n$7o2$1@dont-email.me> <mo7nlc$5ej$1@speranza.aioe.org> |
"wolfgang kern" <nowhere@never.at> wrote in message
news:mo7nlc$5ej$1@speranza.aioe.org...
>
> James Harris wrote:
>
>> You guys may be interested in this and/or have some suggestions or
>> thoughts on it. I have worked up a set of goals and steps to get an
>> OS running, considering having the OS run on x86 (3 modes) and ARM so
>> there are to be four versions of the OS with a common startup
>> approach. There are only three primary goals:
>
>> Goal 1. Start logging so that info can be captured
>> Goal 2. Start multitasking so that other init can be concurrent
>> Goal 3. Interact with the user (i.e. the OS is ready for use)
>
>> The goals are intended to be achieved in order and they guide the set
>> of steps that the OS startup needs to follow. The steps are currently
>> as follows with the numbered goals shown at the points where they
>> will have been achieved.
>
>> - Set up initial register values
> ok.
> My first action is a check on CPU type.
Ah, yes, I did put a CPU check in similar code I wrote some years ago
but I completely forgot it in the current list, and it is something I do
need to do. Thanks for the reminder.
Speaking of first actions, my current startup begins with these four
instructions
cli ;Disable normal interrupts
mov al, SAFE_NMI_DISABLE ;Prepare to disable NMIs
out 0x70, al ;Disable NMIs
in al, 0x71 ;Complete the CMOS access
A bit of control freakery, perhaps, but it seemed the best way to avoid
any nasty surprises and, so far, I don't seem to need interrupts to run
in the background for anything. Those instructions run even before I
rebase CS:IP or set up a stack or save DL etc.
SAFE_NMI_DISABLE is 0x86. That's a value that I chose after long
discussions here on alt.os.development and which I think is the safest
possible.
The idea is that both regular and non-maskable interrupts are only
enabled when their subsystems are ready. So far I enable IRQs but leave
NMIs disabled. (There is a mask bit which is stored in the CMOSRTC
driver to keep NMIs disabled.)
>> - Set up temporary memory management, if required
>> - Identify a small buffer to log to, say 8k
>
> I use 0:0600..0:7bff to store data including BIOS-returned structs:
That's a good idea. I want to leave part of that area, 0x0600..0x07ff,
in place as it will often contain the MBR which might be useful for
info. And I am thinking to stash some other startup data in the low 4k
(0..0xfff). Even if I also left the boot record at 0x7c00 that would
still leave 0x1000..0x7bff or 31k - 4k = 27k for a log.
> origin IVT, (only needed for reboot)
My 16-bit startup copies the original IVT purely for info. If rebooting
I would think the BIOS would reset the IVT. Maybe you do some kind of
warm reboot.
> A20-mode, (set by BIOS or port92 or keybd)
> VESA-modelist, INT15_E820, EDID,
OK. Someone may (unwisely? or because the monitor has died) unplug one
monitor and plug in another one while the OS is running but I guess the
EDID info can be re-got as long as the OS notices.
> INT15_C2, (to enable USB to PS/2 mouse emulation)
> INT13_41 flags, (check if 64-bit address supported)
> CPUID0/1/.. (CPU-name and check for TSC,cmov,..)
IME the good-idea-gone-bad CPUID instruction makes the CPU name
extremely hard to determine unless it is known to be one from a small
set. Do you mean the brand string of about 48 bytes or so? Or do you
mean the manufacturer id such as "GenuineIntel"? Or are you picking a
CPU name from a small set?
BTW, you may know but some 80486s and/or Pentums had the CPUID
instruction but did not accept different values for EAX on input,
effectively assuming EAX was 1. I found it best to call CPUID with EAX =
1 first and then only use EAX = 0 if the initial values checked out. A
minor point, perhaps, but the history of CPUID is full of
idiosyncrasies.
> and all PCI-configuration (needed to detect SATA-ports)
>
>> - Capture whatever is already on the screen
>
> not much of use IMO, more than half is scrolled away.
It is limited but still potentially useful, depending on the machine.
>> - Identify a basic upcounter and a time-of-day clock, if any
>
> I have this later as part of the IRQ-handlers.
Understandable. I wanted those two pieces of info early for the system
log.
>> - Set up somewhere to write debugging output, e.g. VGA
>
> If you dont rely on BIOS-standard then you can use:
> mov ax,0003 int0x10 before using the common used INT10_0e.
OK.
>> - Set up logging and a console
>
> You mean your OS shall keep track of all user actions ?
Oh, yes, even if they sneeze it gets logged. ;-)
In reality the log is there just to keep a record of anything relevant.
>> 1. Achieved goal to start logging
>
>> - Carry out interactions that may not be possible in final OS mode
>> - PC architecture
>> - Get the century and the rest of the date and time
>> - Hide the text-mode cursor (int 0x10_12 bl=0x34 or int 0x10_01)
>> - Find out what memory we have available
>> - e820 or similar modified by 0x15_c1 etc
>> - Set ES=0 on entry or some BIOSes will set carry
>> - Get info about machine, possibly including MCA (int 0x15_c0)
>> - Ensure A20 is enabled (asm)
>
> Oh, you mean the above as 'logging'.
No, the steps I mentioned prior to "1" are the ones that would be there
to enable logging. Once logging is working then anything relevant can be
added to the log. For example, from the things above perhaps the e820
map and other things would be logged.
>> - Enter OS mode, as required
>> - Real mode:
>> - Save original interrupt vectors, for info
>> - Pmode:
>> - Enable Pmode (asm)
>> - Set up paging
>> - Long mode:
>> - Enable long mode (asm)
>> - Set up paging
>> - ARM:
>> - Save original interrupt vectors, for info
>> - Set up paging (possibly)
>
> paging with 8086 ? 8086 for ARM ?
Yes, and you wouldn't believe how hard it was to get that working. ;-)
If you asked because you know I write code for 8086 I should explain
that that's not the only CPU I write for!
Of the above, only the real mode version of the OS would run on the
8086. The Pmode version would only run on a 386 or later, and would
issue a polite refusal if started on an 8086 (real or emulator). The
Lmode OS would only run on a machine with 64-bit support.... And I don't
know much about the ARM, yet. :-(
...
> Main differences to my solution are:
>
> 1. as I mentioned above.
> 2.1 setup exception-handlers and debugger (incl. disassembler).
> 2.2 redirect legacy IRQs to 50..5F and set PIT to 1mS
> (RM+PM hardware-handlers are part of the OS anyway,
> and PIT&RTCL are assumed to be always present).
> 2.3 check on all hardware (detect which IRQs they may fire).
> 2.4 en/dis-able IRQ-creation as desired.
> 2.5 get date/time from RTCL.
OK.
> 2.6 initialise the Job-Queu and jump to "while-wait_main-idle".
That sounds similar to something of mine. I struggled for a while to
know how to get from the single-tasked startup code to multitasking and
ended up getting the initial code effectively to become the idle task,
or at least to jump to the idle task stub which starts the idle task.
...
>> I have some of the x86_16 stuff working but, before I write much more
>> I thought it was a good time to take stock and look at how my startup
>> would need to be modified to accommodate different architectures so
>> that there was a common approach.
>
> One OS for different architectures ?
Yes. At least that's the plan....
> I see an OS just as a link between hardware and human aka user-app. :)
That's a valid view. I see the OS, however, as an environment for apps
to run in. So the OS should provide the same services regardless of
hardware. IMO a given app which is written for the OS should run on the
OS irrespective of the machine it is running on. Just a different view.
James
Back to alt.os.development | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
OS startup goals and steps "James Harris" <james.harris.1@gmail.com> - 2015-07-14 10:35 +0100
Re: OS startup goals and steps "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-15 04:00 -0400
Re: OS startup goals and steps "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-15 22:29 -0400
Re: OS startup goals and steps "James Harris" <james.harris.1@gmail.com> - 2015-07-16 08:00 +0100
Re: OS startup goals and steps "James Harris" <james.harris.1@gmail.com> - 2015-07-16 11:01 +0100
Re: OS startup goals and steps "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-17 05:40 -0400
Re: OS startup goals and steps "wolfgang kern" <nowhere@never.at> - 2015-07-17 17:58 +0200
Re: OS startup goals and steps "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-16 03:24 -0700
Re: OS startup goals and steps "James Harris" <james.harris.1@gmail.com> - 2015-07-16 10:32 +0100
Re: OS startup goals and steps "wolfgang kern" <nowhere@never.at> - 2015-07-16 16:04 +0200
Re: OS startup goals and steps "James Harris" <james.harris.1@gmail.com> - 2015-07-17 06:44 +0100
Re: OS startup goals and steps "wolfgang kern" <nowhere@never.at> - 2015-07-17 17:50 +0200
Re: OS startup goals and steps "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-17 06:10 -0400
Re: OS startup goals and steps "James Harris" <james.harris.1@gmail.com> - 2015-07-17 18:07 +0100
Re: OS startup goals and steps "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-18 03:35 -0400
Re: OS startup goals and steps "wolfgang kern" <nowhere@never.at> - 2015-07-16 14:42 +0200
Re: OS startup goals and steps "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-17 05:48 -0400
Re: OS startup goals and steps "wolfgang kern" <nowhere@never.at> - 2015-07-17 17:29 +0200
csiph-web