Re: [ECOS] Re: Romboot in i386 (continued) - comms. problems

[Jonathan Larmour <jlarmour@redhat.com>]

Alex Lennon wrote:
> 
> >>Why? Just enable the FIFOs and leave it at that. If interrupts are
> >>disabled, the HAL code won't notice any difference.
> 
> Right. Thanks - the 16550 I'm using for test downloads fine at 38400
> with FIFOs on (after a couple of initial packet timeouts ?)

You'd have to debug.
 
> I'd like to get the debug link going as quickly as possible eventually
> and I can't see 115200 working with this setup. I'd still like to put the
> ISR code together.

I wouldn't have thought 115200 would be a problem even with polled -
remember there is now no interrupt processing overhead, so that probably
makes up for any other overhead. Only one way to find out tho :).
 
> Also, as I'm using a 386EX I have two 16450's which I'd like the option
> to use for debugging purposes - again, I'd need interrupt driven comms.
> 
> I'm still trying to understand what the problem is here with an interrupt
> driven implementation. Is polled mode for Redboot a design decision?

Yes. The model eCos (and thus RedBoot) uses is that device drivers set up
their interrupt handlers, and unmask their interrupt.This happens even for
RedBoot. But no interrupts happen until interrupts are globally enabled in
the application (normally via starting the kernel scheduler). 

If global interrupts are enabled earlier, we may get spurious interrupts
for which there is no handler (yet).

> Further down the line we're looking to put together an Ethernet driver
> for the RTL8019, to eliminate all of the serial comms bottlenecking.
> I take it that there is some level of interrupt support in Redboot for
> this purpose ?

No, still polled. The only time interrupts come into play for RedBoot is if
there is an interrupt from the debug channel *after* the app has started.
In that case it is passed to RedBoot first to see if it's a GDB break.
 
> On a slightly different note, after the successful download of the
> 'hello' example the target seems to lock (I'm using Insight). I'd
> like to see where this happens but I can't see a way to make
> Insight/GDB breakpoint prior to execution of the first instruction.
> Is there an obvious way of doing this which I'm just missing ?

Debugging the startup code from the first insn could be risky - some code
simply can't be debugged. Try setting a bp at cyg_start, or
cyg_hal_invoke_constructors. Admittedly I would be surprised if setting a
breakpoint at _start didn't work at all.

> Registered Office: Unit 8, Clifton Road, Cambridge, UK  CB1 7EA. Tel No. 01223 411200.

Snap! Well, nearly :-).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine