[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Another gensh2 questions



Ralf Corsepius wrote:
> 
> Radzislaw Galler wrote:
> >
> > 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.

OK. I get the point. For your information writing 'gdbstubs' I was
meaning the package downloadable from Sourceforge.net. It consumes much
less  EVB RAM (about 70 bytes reported in *.map)

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

Another missunderstanding. I meant: scanf/printf never call it - not me.
When I debugged scanf/printf call it never hit console_read/write.
Instead it called sh_sci_read/write. I still don't understand why
console_* functions should be inserted after
BSP_CONSOLE_DRIVER_TABLE_ENTRY. If I put them in the exchanged order
scanf/printf call the right functions.

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

Which is almost exactly what I did - I put the console driver (with
standard names) in the begining of driver table.
Maybe it wasn't obvious that I also modified other console_* procedures
to work my way (i.e. use termios).

Radek