Another gensh2 questions

[Radzislaw Galler]

Joel Sherrill wrote:
> 
> 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.
> >

So if I use gdbstubs instead of CMON can I remove these sections? I want
to be sure that it will not disturb RTEMS application structure.

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

OK. That's clear.

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

It is hardcoded somewhere. I have just simply exchanged the order of
driver entries in bsp.h
back to the official:

#define CONSOLE_DRIVER_TABLE_ENTRY \
  BSP_CONSOLE_DRIVER_TABLE_ENTRY,\
  { console_initialize, console_open, console_close, \
      console_read, console_write, console_control }\

And  now read/write to /dev/console calls  procedures defined by
BSP_CONSOLE_DRIVER_ENTRY. console_open, console_read etc. are never
called. Changing it back to my current initialization fixes the problem:

#define CONSOLE_DRIVER_TABLE_ENTRY \
  { console_initialize, console_open, console_close, \
      console_read, console_write, console_control },\
  BSP_CONSOLE_DRIVER_TABLE_ENTRY

here is my current console_initialize() implementation:
-----------------
rtems_device_driver console_initialize(
  rtems_device_major_number  major,
  rtems_device_minor_number  minor,
  void                      *arg
)
{
  rtems_driver_name_t *low_level_device_info = NULL ;
  rtems_device_driver status ;
  

  rtems_termios_initialize();

  /* Register the necessary device before it's done in its own driver.
*/
  /* The SCI driver should disable registering it again. */

  /* Just to be sure. */
  status = rtems_io_lookup_name( BSP_CONSOLE_DEVNAME, 
    &low_level_device_info );
  if (status != RTEMS_SUCCESSFUL){
      status = rtems_io_register_name( BSP_CONSOLE_DEVNAME,
                                       major, 
                                       BSP_CONSOLE_MINOR_NUMBER);
      if (status != RTEMS_SUCCESSFUL)
          rtems_fatal_error_occurred(status);
  }

  /* Need to include at least IMFS in application */
  status = link( BSP_CONSOLE_DEVNAME, "/dev/console");
  if ( status != RTEMS_SUCCESSFUL ) 
    rtems_fatal_error_occurred(status);

  return RTEMS_SUCCESSFUL;
}
-------------------

> > > 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 it, but why printf/scanf doesn't want to use my device?

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

So if I link it like I did, then it should work, but it doesn't.