Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #8370 > unrolled thread

OS startup goals and steps

Back to article view | Back to alt.os.development

Contents

  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

#8370 — OS startup goals and steps

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
  - Set up temporary memory management, if required
  - Identify a small buffer to log to, say 8k
  - Capture whatever is already on the screen
  - Identify a basic upcounter and a time-of-day clock, if any
  - Set up somewhere to write debugging output, e.g. VGA
  - Set up logging and a console
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)
  - 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)
  - Set up memory management (mode-specific C)
  - Set up new logging and copy from prior buffer (C)
  - Interrupt controller and interrupt receipt (architecture-specific C)
  - A ticker (C)
  - Real-time clock
  - A scheduler and multitasking (C)
  - Jump to idle task stub
2. Achieved goal to start multitasking

  - Launch tasks for concurrent hardware discovery (C)
  - Once enough of the machine is ready start the shell (C)
3. Achieved goal to start interacting with user

You will likely see some familiar things in there and maybe some 
differences.

I have marked some steps as to be carried out in asm or C but I think it 
is heading for having most of the initial steps in asm and the later 
steps in C. The asm modules are there primarily because they need to do 
some things that C cannot.

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.

James

[toc] | [next] | [standalone]

#8383

On Tue, 14 Jul 2015 05:35:10 -0400, James Harris  
<james.harris.1@gmail.com> 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

Well, Ben and you are logging to files.  My OS only went as far as
displaying output to the screen.  You can pack quite a bit of info
onto the screen as long as you don't need the screen for user display,
i.e., during development.

> Goal 2. Start multitasking so that other init can be concurrent

So, just jump right into it? ...

> Goal 3. Interact with the user (i.e. the OS is ready for use)

So, is this minimal, i.e., just keyboard and console, maybe mouse,
or everything available?

> 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
>   - Set up temporary memory management, if required
>   - Identify a small buffer to log to, say 8k
>   - Capture whatever is already on the screen
>   - Identify a basic upcounter and a time-of-day clock, if any
>   - Set up somewhere to write debugging output, e.g. VGA
>   - Set up logging and a console
> 1. Achieved goal to start logging

Why "temporary" memory management?  You've loaded the OS into memory.
Or, is this part of the bootloader?  I see these as being part of
the OS proper.

Why do you need to save what is already on the screen? ...

You have BIOS calls below.  Any BIOS calls here for VGA or VESA modes?

>   - 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)
>   - 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)
>   - Set up memory management (mode-specific C)
>   - Set up new logging and copy from prior buffer (C)
>   - Interrupt controller and interrupt receipt (architecture-specific C)
>   - A ticker (C)
>   - Real-time clock
>   - A scheduler and multitasking (C)
>   - Jump to idle task stub
> 2. Achieved goal to start multitasking

With one exception, I expect the bootloader to do the steps from
"PC arch..." through to and including "Enter OS mode...".  I expect
the OS to do memory management and thereafter to 2.

Also, I'd expect the OS to access the RTC for date and time,
not what I view as the "bootloader."

I'm not sure what info you'd really need from Int 15h, AH=C0h.
AIR, it was mostly for obsoleted machines.

Hide the text mode cursor? ...

Clear screen?

>   - Launch tasks for concurrent hardware discovery (C)
>   - Once enough of the machine is ready start the shell (C)
> 3. Achieved goal to start interacting with user

OS stuff.

So, ISTM, you have OS stuff to 1, bootloader stuff to
non-temporary C memory management, OS stuff to 2, and
more OS stuff to 3, except for the RTC in the "bootloader"
section.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#8387

On Wed, 15 Jul 2015 10:45:36 -0400, James Harris  
<james.harris.1@gmail.com> wrote:

> "Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message  
> news:op.x1s1vregyfako5@localhost...

>> Why do you need to save what is already on the screen? ...
>
> I don't have to but sometimes the screen will have useful info from  
> before the OS started and I would therefore like to include it in the  
> log.

This computer actually scrolls the BIOS output.  I.e., a portion of the
BIOS info display page is lost because it is so long.

>> You have BIOS calls below.  Any BIOS calls here for VGA or VESA modes?
>
> No, for two reasons.
>
> 1. I am considering using an 8086 emulator to control the screen from PM  
> or LM.
>
> 2. I really have no idea what to do about the screen...!

Are you going to at least set a text mode?

>> Hide the text mode cursor? ...
>
> OK.
>
>> Clear screen?
>
> If going into a GUI, yes. Otherwise, why would you do that?
>

IDK.  Why would you hide the cursor? ...  ;-)


Rod Pemberton

-- 
Scientist now say we'll experience a mini-ice in 2030.
So, I guess we need more global warming today ...

[toc] | [prev] | [next] | [standalone]

#8392

"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
news:op.x1ug7niuyfako5@localhost...
> On Wed, 15 Jul 2015 10:45:36 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>> "Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
>> news:op.x1s1vregyfako5@localhost...
>
>>> Why do you need to save what is already on the screen? ...
>>
>> I don't have to but sometimes the screen will have useful info from 
>> before the OS started and I would therefore like to include it in the 
>> log.
>
> This computer actually scrolls the BIOS output.  I.e., a portion of 
> the
> BIOS info display page is lost because it is so long.

Many machines do lose some content prior to OS boot. I have one machine 
with some extension ROMs which get called at startup. Each ROM, it 
seems, clears all previous info from the screen before writing its own 
messages. No spirit of harmony and cooperation there. :-(

Still, whatever the case the OS can at least capture what is there when 
the OS boots. Even if it is not complete, information which is left on 
the screen may still be useful to someone reviewing the logs.

Incidentally, the BIOS provides a routine to read characters from the 
screen, int 0x10-08, which is supposed to work even in graphics modes 
(allegedly some machines boot in graphics mode but I have never seen 
one) by comparing the screen bit pattern against the font bit pattern.

I don't have my code immediately available but if I used that BIOS call, 
which reads from the cursor position, it looks as though I would have 
had to combine it with int 0x10-02 to set the cursor position. IIRC I 
removed trailing blanks from each line. I may have gone only as far down 
the screen as the cursor at the time that the OS booted or I may have 
omitted only trailing blank lines. Either way, it is possible to use the 
BIOS to capture screen content in a portable way.

>>> You have BIOS calls below.  Any BIOS calls here for VGA or VESA 
>>> modes?
>>
>> No, for two reasons.
>>
>> 1. I am considering using an 8086 emulator to control the screen from 
>> PM  or LM.
>>
>> 2. I really have no idea what to do about the screen...!
>
> Are you going to at least set a text mode?

I don't know if that would help in any way. Notwithstanding what I said 
above won't the screen already be in a text mode? And if the OS sets a 
different mode without checking what the monitor can do isn't there a 
chance that the new mode won't display on the monitor?

>>> Hide the text mode cursor? ...
>>
>> OK.
>>
>>> Clear screen?
>>
>> If going into a GUI, yes. Otherwise, why would you do that?
>>
>
> IDK.  Why would you hide the cursor? ...  ;-)

Partly because in Pmode I don't know yet how to move it! In the current 
Rmode code I write to the screen directly assuming it is VGA and don't 
yet show a cursor.

James

[toc] | [prev] | [next] | [standalone]

#8399

"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
news:op.x1ux2fybyfako5@localhost...
> On Thu, 16 Jul 2015 03:00:10 -0400, James Harris
> <james.harris.1@gmail.com> wrote:

...

> RP> Are you going to at least set a text mode?
>>
>> I don't know if that would help in any way. Notwithstanding what I 
>> said  above won't the screen already be in a text mode? And if the OS 
>> sets a  different mode without checking what the monitor can do isn't 
>> there a  chance that the new mode won't display on the monitor?
>
> So, the plan is to leave text/video mode in the default mode for 
> safety?
>
> Ok.

Well, insofar as I have any kind of plan wrt to the video, yes, I was 
thinking, for now, just to leave the video as the BIOS set it. I will 
need to spend a lot more time researching this before coming up with a 
real plan.

> So, how do you know the rows and columns of the text mode?
> Do you plan to call the BIOS to determine the text resolution?
> e.g. 40x25, 80x25, 80x50, 132x25.

Yes. At one point I didn't think it was possible to get both those 
pieces of info but from looking at the code I have, I use the following.

  int 0x10-0f to get no. of columns and other things
  int 0x10-1130(bh=0) to derive the number of rows

> I looked at this the opposite way around.  I figured that old early
> resolutions for CGA, EGA, and VGA would be universally supported and
> safe to use.

It's a bit of a minefield. I think you pointed out that modern machines 
might not even be compatible with VGA.

> For text, I figured 80x25 text mode, such as mode 2 or 3
> for VGA controllers would be universal.  Well, at least where the 
> machine
> *has* VGA and not CGA or EGA.  EGA and CGA support the modes also, but
> I'm not sure if the CRTC programming is the same for them.

There is a note of what was intended for Linux and startup video 
handling at

  http://lwn.net/2001/0628/a/bios.php3

> My OS doesn't use the BIOS.

Not at all?

> So, I implemented 80x25 text for VGA by directly programming
> CRTC.  I figured the same for 320x200 in 256 colors, but never got to
> around to that.  After using VESA modes and some higher resolution 
> modes
> in DOS, I really wouldn't mind using them in my OS.

OK.

> However, I'll probably
> let the BIOS do the mode setting work, if I ever get around to it. 
> I'm
> not sure how that will go over with my code ...

Ditto.

James

[toc] | [prev] | [next] | [standalone]

#8407

On Thu, 16 Jul 2015 06:01:49 -0400, James Harris <james.harris.1@gmail.com> wrote:

>> My OS doesn't use the BIOS.
>
> Not at all?
>

No.  If it were more complete, it ... might.  I'm not sure, maybe needs
E820h in the future, etc.  PCI - which wasn't planned - might need it too.
VESA and higher resolution video modes would probably need BIOS.   But,
currently, any BIOS use is expected to be done by the bootloader (or my
DOS TSR startup).  I completely program everything I implemented.


Rod Pemberton

-- 
Scientist now say we'll experience a mini-ice in 2030.
So, I guess we need more global warming today ...

[toc] | [prev] | [next] | [standalone]

#8413

Rod Pemberton wrote:

>>> My OS doesn't use the BIOS.
>>
>> Not at all?


> No.  If it were more complete, it ... might.  I'm not sure, maybe needs
> E820h in the future, etc.  PCI - which wasn't planned - might need it too.
> VESA and higher resolution video modes would probably need BIOS.   But,
> currently, any BIOS use is expected to be done by the bootloader (or my
> DOS TSR startup).  I completely program everything I implemented.

You don't need the BIOS for PCI (just use the IO-port pair).
But there is no available bypass for INT_104Fxx and also INT15_E820
is easier than a check on all MTTRs and TOMs.
__
wolfgang

[toc] | [prev] | [next] | [standalone]

#8400

On Thursday, July 16, 2015 at 1:33:28 AM UTC-7, Rod Pemberton wrote:
...
> I saw a Hewlett-Packard PC which had a special partition for the BIOS
> on the hard disk.  My understanding was that if this partition was
> corrupted or destroyed, then the PC was unuseable.  Somehow, the BIOS
> used and accessed software on it.

I had a Compaq laptop like that, except it was still usable, it just
didn't provide some of the additional "BIOS" functionality/tools, which
lived on the disk.

Alex

[toc] | [prev] | [next] | [standalone]

#8398

"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

[toc] | [prev] | [next] | [standalone]

#8402

 James Harris wrote:

...

>> 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.

I do this later and use 0x8c to read the status. An NMI during boot 
and startup could mean that something in hardware went bad.  
 
> 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.)

Only the BIOS may know what's connected to the NMI-pin. So I disable 
it with bit7 set during all CMOS-port access except for the last one.
My debug/exception-handeler would report an NMI and pass it to BIOS.  
 
>>>  - 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.

Yeah not implemented yet, but I think of multiboot options in future.
 
>> 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.

I'm not sure for monitors and graphic-cards survive hot-plug ? 
 
>> 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"? 

I only use the latter now, but once gathered the brand-name as well.
CPUID_01 and _8000_0001 show enough info about CPU-family. 

> Or are you picking a CPU name from a small set?

No, AMD got three CPUIDs 8000_0002/3/4 which contain the 'brand name'.
Haven't checked if and where Intel may have stored it.
But I dont use nor display this non-talking funny names anyway.
 
...

>> 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.... 

The target for my OS was/is to run a mix of RM,PM and soon also LM.
Some jobs perform much faster in trueRM while huge data needs LM.      

> And I don't know much about the ARM, yet. :-(

me neither, what a saw so far is that ARM is totally different to x86.
 
...

>> 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.

I agree with you view, but I think one OS flexible enough to cover 
several different platforms will end up bloated. 

__
wolfgang

[toc] | [prev] | [next] | [standalone]

#8406

"wolfgang kern" <nowhere@never.at> wrote in message 
news:mo8fov$vi5$2@speranza.aioe.org...
> James Harris wrote:

...

> Only the BIOS may know what's connected to the NMI-pin.

According to RBIL there are these standard-ish sources of information:

  port 0x0061 reports RAM or IO parity errors
  port 0x0461 (EISA) reports NMI status

And port 0x0462 (EISA) apparently allows software to trigger an NMI.

Of course, they may or may not be present on a given PC. And some 
chipsets have other sources of information about NMI.

...

>>> VESA-modelist, INT15_E820, EDID,

I've just looked up EDID. As I have complained about many other 
standards made up in this industry EDID is similarly awful. For example, 
depending on the version if you want to find out the display's 
resolution you can look at the following.

  Byte 38: x resolution
  Byte 39: aspect ratio (2 bits)

The x resolution is just one byte so is coded: You add 31 to it and 
multiply by 8 to get the real x resolution - and just hope it is really 
a multiple of 8.

The y resolution cannot be read. It must be estimated from the x 
resolution and one of the only four possible aspect ratios.

  https://en.wikipedia.org/wiki/Extended_Display_Identification_Data#Limitations

Nevertheless, despite EDID's limitations, where present it looks as 
though it should be able to detect if a new monitor has been added 
allowing the OS to adjust the display accordingly.

>> 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.
>
> I'm not sure for monitors and graphic-cards survive hot-plug ?

IME they are OK. I have had enough monitor leads fall out in my time.

...

>>> 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.
>
> I agree with you view, but I think one OS flexible enough to cover 
> several different platforms will end up bloated.

No need for bloat. You can have multiple images built from the same and 
different sources. You don't have to have the code for all of them in 
one image. Each image can contain just what is needed for the target 
hardware.

James

[toc] | [prev] | [next] | [standalone]

#8412

 James Harris wrote:


>> Only the BIOS may know what's connected to the NMI-pin.
>
> According to RBIL there are these standard-ish sources of information:
>
>  port 0x0061 reports RAM or IO parity errors
>  port 0x0461 (EISA) reports NMI status
>
> And port 0x0462 (EISA) apparently allows software to trigger an NMI.
>
> Of course, they may or may not be present on a given PC. And some chipsets 
> have other sources of information about NMI.

Can't confirm this, perhaps EISA became a dead horse already.

> ...

>>>> VESA-modelist, INT15_E820, EDID,

> I've just looked up EDID. As I have complained about many other standards 
> made up in this industry EDID is similarly awful. For example, depending 
> on the version if you want to find out the display's resolution you can 
> look at the following.
>
>  Byte 38: x resolution
>  Byte 39: aspect ratio (2 bits)
>
> The x resolution is just one byte so is coded: You add 31 to it and 
> multiply by 8 to get the real x resolution - and just hope it is really a 
> multiple of 8.
>
> The y resolution cannot be read. It must be estimated from the x 
> resolution and one of the only four possible aspect ratios.

  https://en.wikipedia.org/wiki/Extended_Display_Identification_Data#Limitations

couldn't read that.

> Nevertheless, despite EDID's limitations, where present it looks as though 
> it should be able to detect if a new monitor has been added allowing the 
> OS to adjust the display accordingly.

The main interesting things on EDID are maximum timing limits, we
can set any combination with VESA-VBE mode_7f as long the connected
monitor(s) will work on it.

>>> 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.
>>
>> I'm not sure for monitors and graphic-cards survive hot-plug ?

> IME they are OK. I have had enough monitor leads fall out in my time.

No. Neither Graphic adapters nor monitors are hot-plug devices.


>>>> 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.
>>
>> I agree with you view, but I think one OS flexible enough to cover 
>> several different platforms will end up bloated.
>
> No need for bloat. You can have multiple images built from the same and 
> different sources. You don't have to have the code for all of them in one 
> image. Each image can contain just what is needed for the target hardware.

Ok, but then I just see several different OSes :)
You know, my 'sources' are machine-code only!

__
wolfgang

[toc] | [prev] | [next] | [standalone]

#8409

On Thu, 16 Jul 2015 05:32:36 -0400, James Harris <james.harris.1@gmail.com> wrote:

> OK. Someone may (unwisely? or because the monitor has died) unplug
> one monitor and plug in another one while the OS is running [...]

IMO, bad idea.  Very bad. :-(

Even if it is working afterwards, it may fail later on,
or may work but not work correctly.

One damaged circuit can cause cascade failures in others.
I.e., what typically happens to electronics after static
electric shock or a power surge.  Circuit starts acting
"wierd" then they fail or go up in smoke.

*ONLY*  do this if your company could lose millions of
dollars by turning off the machine after the monitor fails.
Hot swapping parts should be left for emergencies, or in
rare instances for electronic repair technicians who know
what they're doing.

USB is the only thing I'll hot-plug.

If you seriously think you'll have a user, e.g., co-worker
or child, that would do that, then I'd recommend screwing
down the connector screws real tight and use some thread
locker and/or epoxy.

Otherwise, you risk all the time and money re-building a
new computer.  As someone who has experienced too much
electronics failure, both at home and as part of a past
job, this is a small nightmare I'd willingly avoid.


Rod Pemberton

-- 
Scientist now say we'll experience a mini-ice in 2030.
So, I guess we need more global warming today ...

[toc] | [prev] | [next] | [standalone]

#8414

"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
news:op.x1ww75aiyfako5@localhost...
> On Thu, 16 Jul 2015 05:32:36 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>
>> OK. Someone may (unwisely? or because the monitor has died) unplug
>> one monitor and plug in another one while the OS is running [...]
>
> IMO, bad idea.  Very bad. :-(
>
> Even if it is working afterwards, it may fail later on,
> or may work but not work correctly.
>
> One damaged circuit can cause cascade failures in others.
> I.e., what typically happens to electronics after static
> electric shock or a power surge.  Circuit starts acting
> "wierd" then they fail or go up in smoke.
>
> *ONLY*  do this if your company could lose millions of
> dollars by turning off the machine after the monitor fails.
> Hot swapping parts should be left for emergencies, or in
> rare instances for electronic repair technicians who know
> what they're doing.
>
> USB is the only thing I'll hot-plug.
>
> If you seriously think you'll have a user, e.g., co-worker
> or child, that would do that, then I'd recommend screwing
> down the connector screws real tight and use some thread
> locker and/or epoxy.
>
> Otherwise, you risk all the time and money re-building a
> new computer.  As someone who has experienced too much
> electronics failure, both at home and as part of a past
> job, this is a small nightmare I'd willingly avoid.

Marvellously extreme view, Rod ... up in smoke, millions of dollars, and 
epoxy!

If anyone is seeking a more balanced view see

  https://en.wikipedia.org/wiki/VGA_connector

Besides, the point is moot from the viewpoint of an OS writer because, 
in the absence of epoxy ... ;-), the monitor could change whether it is 
a good idea or not, or even under safely controlled conditions via a KVM 
network, so there is value in having an OS check from time to time.

Microsoft have an API for things like this.

https://msdn.microsoft.com/en-us/library/windows/hardware/ff568431%28v=vs.85%29.aspx

James

[toc] | [prev] | [next] | [standalone]

#8416

On Fri, 17 Jul 2015 13:07:53 -0400, James Harris <james.harris.1@gmail.com> wrote:
> "Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message
> news:op.x1ww75aiyfako5@localhost...
>> On Thu, 16 Jul 2015 05:32:36 -0400, James Harris
>> <james.harris.1@gmail.com> wrote:

>>> OK. Someone may (unwisely? or because the monitor has died) unplug
>>> one monitor and plug in another one while the OS is running [...]
>>
>> IMO, bad idea.  Very bad. :-(
>>
>> Even if it is working afterwards, it may fail later on,
>> or may work but not work correctly.
>>
>> One damaged circuit can cause cascade failures in others.
>> I.e., what typically happens to electronics after static
>> electric shock or a power surge.  Circuit starts acting
>> "wierd" then they fail or go up in smoke.
>>
>> *ONLY*  do this if your company could lose millions of
>> dollars by turning off the machine after the monitor fails.
>> Hot swapping parts should be left for emergencies, or in
>> rare instances for electronic repair technicians who know
>> what they're doing.
>>
>> USB is the only thing I'll hot-plug.
>>
>> If you seriously think you'll have a user, e.g., co-worker
>> or child, that would do that, then I'd recommend screwing
>> down the connector screws real tight and use some thread
>> locker and/or epoxy.
>>
>> Otherwise, you risk all the time and money re-building a
>> new computer.  As someone who has experienced too much
>> electronics failure, both at home and as part of a past
>> job, this is a small nightmare I'd willingly avoid.
>
> Marvellously extreme view, Rod ... up in smoke, millions
> of dollars, and epoxy!
>
> If anyone is seeking a more balanced view see
>
>   https://en.wikipedia.org/wiki/VGA_connector

That's definately not a "balanced" view ...  I'd say a novice wrote
that.  Clearly, not one electrical engineer, nor any electronic
technicians contributed to that paragraph.  That's the opinion of
some guy who said, "Let's try it!", then unplugged a monitor at home
and plugged it back in without anything failing, immediately.  That
article definately needs a "Please Cite" tag on that speculative
description.

The important words are this, with emphasis added:

"The VGA interface is NOT ENGINEERED to be hotpluggable ..."

So, it's a complete crap shoot at that point as to whether it works
for you or not.

Even if a newer standard said it's hot plugable, I still wouldn't
do it.  E.g., apparently, HDMI and DVI-D are hot swappable per
specification.  I'm very hesistant even with USB.  The reasons why
I wouldn't use hot plugable capability are straightforward:

1) the monitor and video card are two of the most expensive components
2) the monitor and video care use a bunch of shock sensitive electronics
3) sometimes hot pluggable requirements aren't implemented correctly or
fail to work as expected or only have limited protection
4) if a port fails on the monitor and video card, you're out of ports,
unlike USB where you have many more or you can expand them
5) I have plenty of past experience hot plugging electronics

So, no, Wikipedia's lame and ignorant comment didn't change my opinion.


Rod Pemberton

-- 
Scientist now say we'll experience a mini-ice in 2030.
So, I guess we need more global warming today ...

[toc] | [prev] | [next] | [standalone]

#8401

Rod Pemberton wrote:
 
>> I use 0:0600..0:7bff to store data including BIOS-returned structs:
>>
>> origin IVT, (only needed for reboot)
>> A20-mode,   (set by BIOS or port92 or keybd)
>> VESA-modelist, INT15_E820, EDID, 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,..)
>> and all PCI-configuration (needed to detect SATA-ports)
> ...
 
>> INT15_C2 (to enable USB to PS/2 mouse emulation)
> 
> Could you explain this one? ...

My BIOSes (all AMI) will not emulate an USB-mouse without setting 
up a far-pointer by 15C207 to a (dummy RETF anyway) routine 
followed by a 15C200BH01 (enable). Perhaps because my keybords 
are still PS/2.
After this I can use PM/RM port60 mouse routines and ignore BIOS.
 
>> INT13_41 flags,  (check if 64-bit address supported)
 
> Is this just an EDD 3.0 check?
 
Yes, is AH=030? but I check if bit3 of CX is set in addition.
__
wolfgang

[toc] | [prev] | [next] | [standalone]

#8408

On Thu, 16 Jul 2015 08:42:46 -0400, wolfgang kern <nowhere@never.at> wrote:
> Rod Pemberton wrote:

>>> I use 0:0600..0:7bff to store data including BIOS-returned structs:
>>>
>>> origin IVT, (only needed for reboot)
>>> A20-mode,   (set by BIOS or port92 or keybd)
>>> VESA-modelist, INT15_E820, EDID, 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,..)
>>> and all PCI-configuration (needed to detect SATA-ports)
>> ...
>
>>> INT15_C2 (to enable USB to PS/2 mouse emulation)
>>
>> Could you explain this one? ...
>
> My BIOSes (all AMI) will not emulate an USB-mouse without setting
> up a far-pointer by 15C207 to a (dummy RETF anyway) routine
> followed by a 15C200BH01 (enable). Perhaps because my keybords
> are still PS/2.
> After this I can use PM/RM port60 mouse routines and ignore BIOS.
>

I would not figure that out from RBIL.

Is this custom for your motherboard and BIOS?

Or, is this something in one of the many specifications?


Rod Pemberton

-- 
Scientist now say we'll experience a mini-ice in 2030.
So, I guess we need more global warming today ...

[toc] | [prev] | [next] | [standalone]

#8411

Rod Pemberton wrote:
... 
>>>> INT15_C2 (to enable USB to PS/2 mouse emulation)
>>>
>>> Could you explain this one? ...

>> My BIOSes (all AMI) will not emulate an USB-mouse without setting
>> up a far-pointer by 15C207 to a (dummy RETF anyway) routine
>> followed by a 15C200BH01 (enable). Perhaps because my keybords
>> are still PS/2.
>> After this I can use PM/RM port60 mouse routines and ignore BIOS.

> I would not figure that out from RBIL.
 
> Is this custom for your motherboard and BIOS?
> 
> Or, is this something in one of the many specifications?
 
I stumbled over it and figured it by coincidence, it may be 
board-specific or just a sideeffect of AMI-BIOS behaviour.

__
wolfgang

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.development

csiph-web