Re: [Bug 1000096] new AT91 platform: JTST

Re: [Bug 1000096] new AT91 platform: JTST

[Andrea Michelotti]

Hi Andrew,
JTST has the same AIC controller as the other AT91 platforms, but jtst uses
both line 0 (FIQ, connected with dsp halt signal) and line 1 (IRQ).
In general atmel AIC has 1 FIQ +31 IRQs always available, depends on the
board/SOC if they are used.
In this simple at91 port I included the minimum to run eCos on diopsis and
to lunch dsp applications.
It exists supplemental DSP APIs for debbuging, user support and for system
service routines. The problem is
that I have to undestand the best way to plug them into eCos.
At the moment I have a package that is situated in my local tree in
package/devs/dsp/arm/magic.
I thought magic as a device. It works, but I'm absolutely not sure that is
the right thing to do.
We have developed (work done by atmel China) an ecos driver also for the USB
(philips isp1181) included in the JTST; but I must check if we can
distribute the sources..
At the moment all JTST in the world have Redboot installed in flash and run
obviously eCos applications.

Here two links to jtst datasheets:
http://www.atmel.com/dyn/general/tech_doc.asp?doc_id=9586
http://www.atmel.com/dyn/general/tech_doc.asp?doc_id=9889

thank you for your patience and attention.
best regards.
Andrea.


> ------- Additional Comments From andrew.lunn@ascom.ch  2004-17-09
12:56 -------
> #define RUNMAGIC
> HAL_WRITE_UINT32(AT91_MAARCSE+AT91_MAARCSE_CMD,AT91_MAARCSE_CMD_RUN);
> +#define WAITSYSTEM jtst_wait_magic();
> +
>
> RUNMAGIC should really be HAL_RUNMAGIC, and WAITSYSTEM should be
HAL_WAITSYSTEM.
> Also jtst_wait_magic() would be better as cyg_hal_jtst_wait_magic(). These
are
> all name space polution issues. Some comments to what these do would also
be good.
>
> +#define ISP1181_IRQ_USB_SERVICE_REQUEST 24
>
> Again, it does not fit the naming convention and its not clear what its
for. Its
> not used anywhere else in the code. Is it trying to say the USB is using
> interrupt 24? If do i would call this something like
>
> CYGNUM_HAL_INTERRUPT_ISP1181
>
> +.macro __todo
> +  ldr     r0,=AT91_PIO
> +  ldr     r1,=BIT21|BIT22|BIT23|BIT24|BIT25|BIT26|BIT27|BIT3
> +  str     r1,[r0,#AT91_PIO_SODR] // set this bit must be always 1,
otherwise resets
> +  ldr     r1,=BIT21|BIT22|BIT23|BIT24|BIT25|BIT26|BIT27|BIT3
> +  str     r1,[r0,#AT91_PIO_OER]   // set to output
>
> A better name for this macro would be good.
>
> +#define CYGNUM_HAL_INTERRUPT_MAGICHLT          0
> +
> +#define CYGNUM_HAL_INTERRUPT_TIMER0            1
> +#define CYGNUM_HAL_INTERRUPT_TIMER1            2
> +#define CYGNUM_HAL_INTERRUPT_TIMER2            3
>
> Does this use the same interrupt controller as the other at91 chips?
> From what i remember from reading a  data sheet yesterday, interrupt 0 is
for
> the FIQ, and 1 is reserved? Does this chip do something different?
>
> There are a few places where the white spacing looks wrong. Please could
you
> expand all tabs to spaces.
>
> Like i said before, overall it looks good, just some minor issues to tidy
up.
>
>
>
> ------- You are receiving this mail because: -------
> You are the QA contact for the bug, or are watching the QA contact.
>

Re: [Bug 1000096] new AT91 platform: JTST

[Jonathan Larmour]

Andrea Michelotti wrote:
> Hi Andrew,
> JTST has the same AIC controller as the other AT91 platforms, but jtst uses
> both line 0 (FIQ, connected with dsp halt signal) and line 1 (IRQ).
> In general atmel AIC has 1 FIQ +31 IRQs always available, depends on the
> board/SOC if they are used.
> In this simple at91 port I included the minimum to run eCos on diopsis and
> to lunch dsp applications.
> It exists supplemental DSP APIs for debbuging, user support and for system
> service routines. The problem is
> that I have to undestand the best way to plug them into eCos.
> At the moment I have a package that is situated in my local tree in
> package/devs/dsp/arm/magic.
> I thought magic as a device. It works, but I'm absolutely not sure that is
> the right thing to do.
> We have developed (work done by atmel China) an ecos driver also for the USB
> (philips isp1181) included in the JTST; but I must check if we can
> distribute the sources..
> At the moment all JTST in the world have Redboot installed in flash and run
> obviously eCos applications.
> 
> Here two links to jtst datasheets:
> http://www.atmel.com/dyn/general/tech_doc.asp?doc_id=9586
> http://www.atmel.com/dyn/general/tech_doc.asp?doc_id=9889

This is useful info, could you consider adding appropriate info containing 
useful info like this and some of the other things you've written as a 
README in the doc/ subdirectory of the platform HAL? SGML Docbook would be 
even better as it would mean it could be integrated into the full proper 
eCos documentation set (as at 
<http://ecos.sourceware.org/docs-latest/ref/ecos-ref.html>).

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: [Bug 1000096] new AT91 platform: JTST

[Andrew Lunn]

On Fri, Sep 17, 2004 at 06:51:26PM +0200, Andrea Michelotti wrote:

> It exists supplemental DSP APIs for debbuging, user support and for
> system service routines. The problem is that I have to undestand the
> best way to plug them into eCos.  At the moment I have a package
> that is situated in my local tree in package/devs/dsp/arm/magic.

Humm. As a starting point that is reasonable.

However we might want to think a bit about the long term. I can see
more silicon with a CPU and a DSP together comming along. eg there is
TI OMAP and im sure there are others. You should also think about your
own internal plans. Maybe you will release another chipset which has
the same DSP but a different processor. Or maybe you keep the same
processor but have a different DSP. You want to keep the API the same
to make it easy to port software between the different systems.

So you might want to split it up into multiple packages. Maybe one
package that implements the API. Another which implements the things
which are specific to the DSP and a third which is specific to the
processor? 

Now is the API generic enough that it could say be used for the OMAP
or some other manufactures CP+DSP chipset? Im guessing not, it would
be very difficult to have such a generic API.

So maybe you need something like the following structure

packages/devs/dsp/atmel/magic 
packages/devs/dsp/atmel/jtst  
packages/devs/dsp/atmel/api   

Since there is nothing like this at the moment we have much more
freedom for discussion, so if you have other ideas or requirements
please let us know.

> We have developed (work done by atmel China) an ecos driver also for the USB
> (philips isp1181) included in the JTST; but I must check if we can
> distribute the sources..

We would also need to look at the copyright assignment. Is it specifc
to you, Atmel Italy, or Atmel world wide?

   Andrew

Re: [Bug 1000096] new AT91 platform: JTST

[Andrea Michelotti]

The splitting you propose sounds good.
I agree with you to found the final good solution we need some discussion.
The copyright agreement I sent to you covers all the code written by me in
Atmel Rome (jtst port, patches... it was signed by our Atmel Rome CEO).
Diopsis (and all boards) is an Atmel Rome project that's responsible for all
the hardware and the software product.
For the usb driver (separate package from atmel Asia), at the moment I can't
include sources. The authors, have to ask permission to their local CEO.

thanks again

best regards.

Andrea.



> Humm. As a starting point that is reasonable.
>
> However we might want to think a bit about the long term. I can see
> more silicon with a CPU and a DSP together comming along. eg there is
> TI OMAP and im sure there are others. You should also think about your
> own internal plans. Maybe you will release another chipset which has
> the same DSP but a different processor. Or maybe you keep the same
> processor but have a different DSP. You want to keep the API the same
> to make it easy to port software between the different systems.
>
> So you might want to split it up into multiple packages. Maybe one
> package that implements the API. Another which implements the things
> which are specific to the DSP and a third which is specific to the
> processor?
>
> Now is the API generic enough that it could say be used for the OMAP
> or some other manufactures CP+DSP chipset? Im guessing not, it would
> be very difficult to have such a generic API.
>
> So maybe you need something like the following structure
>
> packages/devs/dsp/atmel/magic
> packages/devs/dsp/atmel/jtst
> packages/devs/dsp/atmel/api
>
> Since there is nothing like this at the moment we have much more
> freedom for discussion, so if you have other ideas or requirements
> please let us know.
>
> > We have developed (work done by atmel China) an ecos driver also for the
USB
> > (philips isp1181) included in the JTST; but I must check if we can
> > distribute the sources..
>
> We would also need to look at the copyright assignment. Is it specifc
> to you, Atmel Italy, or Atmel world wide?
>
>    Andrew
>

Re: [Bug 1000096] new AT91 platform: JTST

[Jonathan Larmour]

Andrew Lunn wrote:
> We would also need to look at the copyright assignment. Is it specifc
> to you, Atmel Italy, or Atmel world wide?

Out of interest, virtually all copyright assignments we do are with 
individuals, not companies as a whole.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine