This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Serial Driver in Redboot vs HAL


"Doris, Thomas" wrote:
> 
> I'm working on a port of the iq80310 HAL to an Xscale based processor,
> primarily to provide RedBoot functionality, but I want to ensure that we
> provide a correct HAL for general use. Currently I'm running the code on a
> s/w simulated model of the processor, which supports UART I/O but no other
> external devices. My confusion is this: the hal_diag.c implements a UART
> driver through the cyg_plf_serial_* functions, which seems to be all that
> RedBoot requires for console I/O. However there is a directory
> packages/devs/serial/arm/iq80310 which contains cdl stuff which states that
> the iq80310 serial driver is to be based on the generic 16X5X serial driver.
> I am assuming that the hal_diag serial code is used for redboot and
> diagnostic code, while the "proper" driver under packages/devs/serial is
> used by the real i/o library in real eCos applications. Any
> information/clarification on the official position on this would be
> appreciated.

Correct. The main difference is polled with hal_diag (and the potential to
leave interrupts disabled for a while - but the intention is only for
diagnostic debug output, not _real_ output), and interrupt driven with the
stuff in devs/serial, where eCos is allowed to run more smoothly because
interrupts are left enabled and other threads can run.

> Secondly, my simulator does not support any external devices such as flash
> or network. When running RedBoot, it is the case that the code in
> packages/redboot/current/src/flash does not handle this well - a brief
> inspection of the function do_flash_init will reveal that the way it sets
> the variable __flash_init is not very useful, it sets it to true even when
> the flash initialisation fails, it seems that there should be a similar
> variable which indicates whether the initialization has been successful or
> not - if flash init fails it would make sense to prevent the subsequent
> invokation of flash related functions.

Fair enough, although a patch speaks a thousand words :-).

> Similarly, the edb7xxx cs8900 ethernet driver will hang forever waiting for
> an "initialization OK" message from the CS8900 device.

This was changed just recently - update your CVS if you want the fix.

> It would seem that
> the right thing to do here is to have an upper limit timeout so that failure
> to initialise could be detected and booting continue - however I am not sure
> what the policy is on having a dependency between an ethernet driver and a
> hal timer. Any advice on this would be appreciated.

Typically we would use techniques like polling it and usnig
CYGACC_CALL_IF_DELAY_US(some time) in a loop for a number of iterations. Or
even just a loop with a fixed number of iterations with no delay since
exact time isn't important, just "some time".

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]