| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Celso Labinaz <labinaz@tin.it> pointed to me thatthe console on serial
line was not working. After spending quite a time to find the right
cable and software, I confirm this.
I'm going to debug this in the next days because I want to use the
serial line for debugging. In the meantime, in order to be sure that
this was a driver initialization/bug, I made printk work on the serial
line in order to be sure the receiver part and configuration was OK.
Here is the for printk on serial line. BTW, does anyone else use the
serial line facilities for PC? printf seems to output nothing (hello.exe
output everything that has a printk but application printf seems to be
broken).
|
| |
|
|
| |
when building the executive source.
|
| | |
|
| | |
|
| |
|
|
| |
file to switch out to CPU specific implementations.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
via the user api.
|
| |
|
|
|
|
|
|
|
|
| |
Here is a patch that enables to catch exception
and get message before crashing RTEMS :)
It should be generic to any Intel port although enabled
only for pc386 BSP...
[Joel] I fixed the bug I introduced in irq_asm.s...
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Thomas Doerfler" <td@imd.m.isar.de> wrote:
>
> While implementing/testing the console/termios support for
> PPC403 in RTEMS-4.0.0-beta3, I am stuck at a certain location in
> termios.c:
>
> During "rtems_termios_initialize", the main control data structure
> "*tty" is allocated using malloc(). (Note, that malloc does not
> clear the allocated memory and my BSP does not clear memory during
> startup). Furtheron, a lot of fields of that structure are
> initialized, but the field "rawOutBufState" is not, and therefore
> keeps an arbitrary contents.
>
> When "osend()" is called the first time(with the serial device
> driver working in interrupt mode), termios gets stuck and will not
> call the device drivers output function.
>
> My questions now are:
>
> - anybody already experienced this bug?
> - is it a bug at all or did I do anything fundamentally wrong?
> - is there already a common bugfix for that?
>
> I don't like poking around in other people code, as long as I am
> not absolutely sure, what I do...
Yes, there's a bug there.
I thought that Joel had patched this already, but here's a patch to
fix this. This patch also addresses a concern that many others have
raised regarding enabling and disabling of transmitter interrupts.
First, here's the example I've been using of a simple UART-style
interrupt-driven driver:
===============================================================
void
device_write_routine (int minor, char *buf, int count)
{
UART->control_register &= ~UART_TRANSMITTER_READY;
UART->output_register = *buf;
UART->control_register |= UART_TRANSMIT_INTERRUPT_ENABLE;
}
void
device_transmit_interrupt_routine (int vector)
{
UART->control_register &= ~UART_TRANSMIT_INTERRUPT_ENABLE;
rtems_termios_dequeue_characters (device_ttyp, 1);
}
==============================================================
Several people have expressed their concern about the disable/enable
of transmitter interrupts for every character. On some machines
this disable/enable is an expensive operation. With the attached
patch applied you can write the two routines as:
==============================================================
void
device_write_routine (int minor, char *buf, int count)
{
code_to_clear_transmitter_ready_status ();
if (device_ttyp->rawOutBufState == rob_idle)
code_to_enable_transmitter_interrupts ();
code_to_send_one_character_to_transmitter (*buf);
}
void
device_transmit_interrupt_routine (int vector)
{
rtems_termios_dequeue_characters (device_ttyp, 1);
if (device_ttyp->rawOutBufState == rob_idle)
code_to_disable_transmitter_interrupts ();
}
===============================================================
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
a missed "&" on a write.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
- Use the "hlt" instruction for the Idle thread,
- Optimise interrupt PATH leadding to thread wakeup,
- Preparation for Intel exception management that should
come before the end of the week...
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch has same changes as one I sent to you earlier plus
it fixes _heap_size problem for pc386 we had discussed earlier.
Now, _heap_size is defined and set to 0 in pc386/startup/bspstart.c
It can be patched to desireable value in binary image. If it is
left unpatched, then startup code will determine size of memory
(on the assumption that at least 2MB are present) and use
max possible heap.
|
| |
|
|
|
|
| |
It fixes netboot build problem, KA9Q configuration
for pc386, some compiler wardning, it also removed some stuff
ifdef'ed with '#if 0'.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
make solaris target buildable.
> 1. The ipc check fails since solaris does not define union semun.
> The unix port code actually defines this type itself on solaris. Doing
> the same thing lets it get configured. Then...
> 2. It looks like BSDINSTALL is not defined properly.
BSDINSTALL is defined in make/host.cfg.in as
BSDINSTALL=@INSTALL@
@INSTALL@ is generated by autoconf's standard macro AC_PROG_INSTALL, which
is widely used in almost any autoconf/automake configured package. In case
there is really something wrong with it, then it must be considered a bug
in autoconf.
I can see a doubious fragment in AC_PROG_INSTALL, which is used when no
appropriate bsd-install is found.
Finally Ralf saw a problem with the find on solaris which I also saw and
fixed.
|
| | |
|
| |
|
|
| |
a giant packet.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
