Another gensh2 questions

[Joel Sherrill]

Ralf Corsepius wrote:
> 
> Radzislaw Galler wrote:
> >
> > Hi,
> >
> > I have some questions:
> >
> > 1. What are sections 'monvects' and 'monram' and why they need so much
> > space?
> These are related to CMON:
> 
> .monvects is the section used for the initial vector table of the
> monitor. CMONs ROM'ed code copies its vector table into this section
> at startup.
> 
> .monram is the section reserved for the monitor (aka "monitor play
> area"), before starting RTEMS.
> 
> > Looking into *.map file of an application there is nothing in
> > these sections.
> Yes, this gets initialized from the ROM'ed code.
> 
> > 2. I am hacking the console driver in gensh2 to use termios (with
> > success - thanks Fernando!). The question is about registering files in
> > system. The console driver should be the first entry in drivers table
> > (otherwise it doesn't work - don't know why; system uses driver with
> > major=0 which is simple SCI driver in current snapshot). When I want to
> > link /dev/console to /dev/sci0 (serial port) it has to exist. If I
> > register it in console_initialize() it will have major number 0. It
> > makes no difference to driver routines because the use only minor number
> > but right now I have /dev/sci0 with major=0 and minor=0 and /dev/sci1
> > with major=1 and minor=1. Does it make sense?
> No, it doesn't.

If the devices are handled by the same device driver, then they
should have the same major number.

Minor numbers are used within a device driver to distinguish individual
devices.

The console has to be first could be the result of some initialization
order dependencies.  Or it could be that since it is the first driver,
the major of all devices it controls is 0 and thus it must be first.
The driver may simply need to be more correct in registering the
major number as the correct value -- not a hard-coded 0.

> > Is it dangerous?
> Yes. The simple solution is to give your new driver different names.
> And to edit the driver tables to your demands (One way to do so is
> hidden in bsp.h).
> 
> > I did not
> > look into another bsp's but maybe there is no sense to make separate
> > drivers for console and serial ports.
> Forget about console devices.
> 
> /dev/console is just an alias for a device with certain
> capabilities. It doesn't even need to be a serial tty, it could be
> everything (Eg. we had /dev/console linked to a can-bus or
> transputer links on our sh1 board.)

Good description. 

> > This wouldn't be an issue if the
> > console worked independently from the location in the driver table.
> Cf. how the driver table entries are handled in bsp.h
>
> Ralf
> 
> --
> Ralf Corsepius
> Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
> (FAW)
> Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
> mailto:corsepiu at faw.uni-ulm.de           FAX: +49/731/501-999
> http://www.faw.uni-ulm.de

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985