From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Larmour To: Alex Lennon Cc: Gary Thomas , ecos-discuss@sources.redhat.com Subject: Re: [ECOS] Re: Romboot in i386 (continued) - comms. problems Date: Tue, 14 Aug 2001 05:32:00 -0000 Message-id: <3B791A77.A3A22764@redhat.com> References: X-SW-Source: 2001-08/msg00455.html 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