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

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

[Alex Lennon]

>> >It's the first stage in providing some way for a PC to directly boot
from
>> >ROM/Flash. It's not been made to work on any particular platform yet
>>
>> Is the thrust of this code attempting to boot the PC off an add-in BIOS
>> (e.g. at C800:0) or as a complete mainboard BIOS replacement to take over
>> at power-on?

>The latter. See romboot.S. But it's not been tested with a live platform so
>take it with a pinch of salt for now.

Hi - I've been taking a look at porting Redboot to at Arcom Merlin board
(25Mhz 386ex, 1Mb flash, 2Mb DRAM).

I'm happy enough with a modified romboot.S entering PM and jumping to
the Redboot code. I get the signons and can enter commands etc. etc.

However I'm getting a lot of funnies downloading images over a serial
link (they are the correct .srec format now, I think) and connecting with
GDB.

At the 38K4 baud default I seem to be dropping lots of chars. When I
go right down to 1200 I can do an Xmodem image download OK.

The i386 port seems to be using serial drivers in
~/ecos/packages/hal/i386/pcmb/current/src/pcmb_serial.c

Looking at these serial drivers it seems to me that somebody has implemented
a polled mode schema on both Rx and Tx. Could somebody tell me if this is
correct ?

If so, then before I dive straight in and rewrite the code, is there any
reason
I shouldn't just use the 16x5x drivers already in eCos ?

TIA,

	Alex Lennon



_____________________________________________________________________
This message has been checked for all known viruses by UUNET delivered 
through the MessageLabs Virus Control Centre. For further information visit
http://www.uk.uu.net/products/security/virus/

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

[Gary Thomas]

On 13-Aug-2001 Alex Lennon wrote:
> Looking at these serial drivers it seems to me that somebody has implemented
> a polled mode schema on both Rx and Tx. Could somebody tell me if this is
> correct ?
> 
> If so, then before I dive straight in and rewrite the code, is there any
> reason
> I shouldn't just use the 16x5x drivers already in eCos ?
> 

RedBoot can only use polled drivers and is not set up to use the "normal"
serial I/O in eCos.

Perhaps it's just a matter of not using the FIFOs appropriately in the
HAL [diag] polled routines?

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

[Alex Lennon]

>>RedBoot can only use polled drivers and is not set up to use the "normal"
>>serial I/O in eCos.
>>
>>Perhaps it's just a matter of not using the FIFOs appropriately in the
>>HAL [diag] polled routines?

Yes - they don't seem to be switched on by default. I decided that if I'm
going to have to implement ring buffers to handle the FIFOs I might
as well go the whole hog and try to provide hooks to the 16x5x code.

Is this likely to turn into a time consuming operation do you think? One
thing I'm concerned about is that IDTs are a bit of at unknown at the
moment to me. I kind of assumed eCos got these set up correctly 
so that I wouldn't have to ?

Regards,

-Alex


_____________________________________________________________________
This message has been checked for all known viruses by UUNET delivered 
through the MessageLabs Virus Control Centre. For further information visit
http://www.uk.uu.net/products/security/virus/

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

[Gary Thomas]

On 13-Aug-2001 Alex Lennon wrote:
>>>RedBoot can only use polled drivers and is not set up to use the "normal"
>>>serial I/O in eCos.
>>>
>>>Perhaps it's just a matter of not using the FIFOs appropriately in the
>>>HAL [diag] polled routines?
> 
> Yes - they don't seem to be switched on by default. I decided that if I'm
> going to have to implement ring buffers to handle the FIFOs I might
> as well go the whole hog and try to provide hooks to the 16x5x code.
> 
> Is this likely to turn into a time consuming operation do you think? One
> thing I'm concerned about is that IDTs are a bit of at unknown at the
> moment to me. I kind of assumed eCos got these set up correctly 
> so that I wouldn't have to ?
> 

Try looking in the file ".../hal/i386/pcmb/current/src/pcmb_serial.c"
You'll see that the FIFOs are explicitly *not* turned on.  You can experiment
with that code a bit and see what works for you.

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

[Alex Lennon]

>>Try looking in the file ".../hal/i386/pcmb/current/src/pcmb_serial.c"
>>You'll see that the FIFOs are explicitly *not* turned on.  You
>>can experiment
>>with that code a bit and see what works for you.
>>

Yes - that's what I've been referring to. Apologies for my lack of clarity.

What I was trying to say was that the FIFOs are not enabled in the
following code snippet (from pcmb_serial.c)

static void
cyg_hal_plf_serial_init_channel(void* __ch_data)
{
    cyg_uint16 base = ((channel_data_t*)__ch_data)->base;

    HAL_WRITE_UINT8(base+CYG_DEV_IER, 0);
    HAL_WRITE_UINT8(base+CYG_DEV_IER, 0);
    HAL_WRITE_UINT8(base+CYG_DEV_MCR, 0);

    HAL_WRITE_UINT8(base+CYG_DEV_LCR, SIO_LCR_DLAB);
    HAL_WRITE_UINT8(base+CYG_DEV_DLL, CYG_DEVICE_SERIAL_BAUD_LSB);
    HAL_WRITE_UINT8(base+CYG_DEV_DLM, CYG_DEVICE_SERIAL_BAUD_MSB);
    // 8-1-no parity.
    HAL_WRITE_UINT8(base+CYG_DEV_LCR, SIO_LCR_WLS0 | SIO_LCR_WLS1);

//    HAL_WRITE_UINT8(base+CYG_DEV_FCR, 0x07);  // Enable & clear FIFO
}

They aren't *disabled* either - so the FIFOs aren't necessarily disabled.
Only an issue
if you have a couple of different loader programs chaining each other as we
do here.

I take your point that I can enable the FIFOs and add code to the handler to
deal with this.
However, to support FIFOs I need to buffer up the incoming characters on
each
cyg_hal_plf_serial_getc_nonblock() call.

I'm happy enough to do this but I'd prefer to just reuse the existing eCos
16x5x code
rather than putting something new together. I just wondered if this was
likely to prove
a problem ? Particularly if there is something difficult about the i386
protected mode
setup of which I am unaware...

Regards,

 Alex




_____________________________________________________________________
This message has been checked for all known viruses by UUNET delivered 
through the MessageLabs Virus Control Centre. For further information visit
http://www.uk.uu.net/products/security/virus/

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

[Jonathan Larmour]

Alex Lennon wrote:
> 
> I take your point that I can enable the FIFOs and add code to the handler to
> deal with this.
> However, to support FIFOs I need to buffer up the incoming characters on
> each
> cyg_hal_plf_serial_getc_nonblock() call.

Why? Just enable the FIFOs and leave it at that. If interrupts are
disabled, the HAL code won't notice any difference.

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

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

[Alex Lennon]

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

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.

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? 
If so is there somewhere I can look for the background ?

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 ?

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 ?

Thanks,

 Alex



_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end.

All reasonable precautions have been taken to ensure no viruses are present in this e-mail by using MessageLabs Virus Control Centre. Arcom Control Systems Ltd cannot accept responsibility for loss or damage arising from the use of this e-mail.

Company registered in England No. 1608562.
Registered Office: Unit 8, Clifton Road, Cambridge, UK  CB1 7EA. Tel No. 01223 411200.

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

[Jonathan Larmour]

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

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

[Nick Garnett]

"Alex Lennon" <ajlennon@arcom.co.uk> writes:

> >>RedBoot can only use polled drivers and is not set up to use the "normal"
> >>serial I/O in eCos.
> >>
> >>Perhaps it's just a matter of not using the FIFOs appropriately in the
> >>HAL [diag] polled routines?
> 
> Yes - they don't seem to be switched on by default. I decided that if I'm
> going to have to implement ring buffers to handle the FIFOs I might
> as well go the whole hog and try to provide hooks to the 16x5x code.

You shouldn't have to add anything else to the implementation other
than turning on the FIFOs in the hardware in the serial init
routines.

> 
> Is this likely to turn into a time consuming operation do you think? One
> thing I'm concerned about is that IDTs are a bit of at unknown at the
> moment to me. I kind of assumed eCos got these set up correctly 
> so that I wouldn't have to ?
> 

Again, you should not have to worry about any of this. Redboot should
not be using interrupts, and the existing serial code will work fine,
and keep up with the baud rate, once the FIFOs are enabled.


-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

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

[Nick Garnett]

Gary Thomas <gthomas@redhat.com> writes:

> On 13-Aug-2001 Alex Lennon wrote:
> > Looking at these serial drivers it seems to me that somebody has implemented
> > a polled mode schema on both Rx and Tx. Could somebody tell me if this is
> > correct ?
> > 
> > If so, then before I dive straight in and rewrite the code, is there any
> > reason
> > I shouldn't just use the 16x5x drivers already in eCos ?
> > 
> 
> RedBoot can only use polled drivers and is not set up to use the "normal"
> serial I/O in eCos.
> 
> Perhaps it's just a matter of not using the FIFOs appropriately in the
> HAL [diag] polled routines?

Yep.

Alex, bear in mind that the rom boot stuff is very much a work in
progress. I only ever took it as far as entering ecos/Redboot before
being sidetracked onto something else. To be honest I'm surprised it
works at all in a real board, I only ever ran it on a simulator.

One part of the job that was never done is the setup of the on-board
devices from scratch. Much of this code still expects the devices to
have been initialized by the BIOS.

So I suspect that the serial devices are still in whatever mode they
come up in on reset. This almost certainly has the FIFOs
disabled. Adding code to fully initialize the devices, including
turning on the FIFOs, should make things work better.



-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK