patch

[qqi at world.std.com (qqi)]

> The only point, I find questionnable is the removal of 
> "void BSP_emergency_output_init()" by a inconditionnal call
> to "_IBMPC_initVideo()" in bsp_start.

The problem is that if you would like to trace early start, call to
BSP_emergency_output_init() will wipe out this trace. I am not sure though
whether 
doing it once in bsp_start() is a right idea, 

> However, we have board that are fully PC386 compatible
> but that may have no video at all (we use display for
> debugging sometime but we can remove it). In this case the 
> BIOS is adapted to survive but also do not of course
> put the expected data in the BIOS data area.
> 
> Thus calling _IBMPC_initVideo() would lead to a crash even
> if the console display has been set to COM2...

I think that if we have different board it may make sense to have separate 
BSP for this board, or to have ifdef and appropriate entry in pc386.cfg. 
In all cases it has to be done once and as early as possible.

> In my opinion _IBMPC_initVideo() should be called only if 
> the current display is video.
> 
> I would prefer to have something like that in bsp_start:
> 
>  if (PC386ConsolePort == PC386_CONSOLE_PORT_CONSOLE) {
> 	_IBMPC_initVideo();
>  }

Not necessary - I really like case when printk is on console and console is

on serial port.


> 2) Concerning the on, off functions, it depend wheter it is
> rwa interrupt or rtems managed interrupts. 
> 
> In the case of *raw* interrupt handling, they should in theory contain
call to 
> pc386_irq_(enable/disable_at_i8259s) (vector - PC386_IRQ_VECTOR_BASE)
> plus enabling/disabling on the external hardware interrupt control
register
> itself so that the kernel may call them to temporary disable interrupts 
> without knowing the devices themselves. This is very usefull if we want 
> to implement functionnalities like :
> 
> 	- ROM monitor. In this case when you hit a dedicated
> 	keyborad, key, you enter the monitor that immediately
> 	call all "off" function to froze the machine and re-enable
> 	them latter on,
> 	- Benchmarking (no pertubation by ethernet broadcast for
> 	example),
> 	- ..
> The initialization of the PIC interrupt mask is 0xb on the master
> PIC (cascading via line 2) and 0xf on the second one in order 
> to avoid spurious interrupts before the device hanlder is 
> actually connected. So you have to demask the relevant 
> "raw interrupt" interrupt mask at PIC level. Doing it directly 
> via PIC interrupt mask manipulation is an error as it breaks 
> the i8259s_cache variable used to optimize interrupt path
> by removing two IO access in the interrupt path (~2micros)
> 
> In case of "rtems managed interrupt", the call is done
> automatically by conexion routine and thus the "on/off"
> routine should only contain code to enable the interrupt 
> on the hardware itself (usually by writting relevant
> patterns in nn Interrupt Enable Register).
> 
> The rationale for the difference is the following :
> 	- raw interrupt code should be runnable
> 	on non PC386 harware eventually with a different
> 	external interrupt controller and thus it shall not
> 	manipulate PICs,
> 	- "rtems managed interrupt" are designed to help
> 	the programmer to concentrate on the board management
> 	without worring about PICs, software interrupt priorities,
> 	... while re-enabling interrupt at PIC and processor level 
> 	quicker than previous code. Old code can always be emulated
> 	using raw interrupt (I mean now that you have made them 
> 	work :)).
> 

Thanks, I got it.
 
> -- eric.

Thanks,

Aleksey