Another gensh2 questions

[Ralf Corsepius]

Radzislaw Galler wrote:
> 
> 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?
CMON contains a gdbstub :) When entering the gdb-stub, these
sections are also used by the gdb-stub.

Whether you can remove these section, depends on how the gdb stub is
set up, how it interacts with other ROM'ed boot code and where RAM
sections used by such code is located in memory. 

> I want
> to be sure that it will not disturb RTEMS application structure.
Normally you will have to reserve some memory for the stub and for
the boot-code (automatic variables etc.).
Of cause the addresses and names can vary, but I would expect you to
need at least something similar.

Even worse, you normally also need to keep gdb and RTEMS memory
sections separate (They doen't know anything of each other).

> > > > 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.
They are called, if you use sh/shared/console.c. You must not call
your console functions/entry points console_* for this to remain
functional. Also the console_* functions must be inserted after the
BSP_CONSOLE_DRIVER_TABLE_ENTRY.

> 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
This will break sh/shared/console.


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

Something like
#define BSP_MY_DRIVER_TABLE_ENTRY \
{ my_init, my_open, ... }

and 
#define BSP_CONSOLE_DRIVER_TABLE_ENTRY \
BSP_MY_DRIVER_TABLE_ENTRY

should do.
 
(cf. how to switch between sci and devnull 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