From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13498 invoked by alias); 17 Sep 2004 16:47:04 -0000 Mailing-List: contact ecos-maintainers-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@sources.redhat.com Received: (qmail 13486 invoked from network); 17 Sep 2004 16:47:02 -0000 Message-ID: <06c801c49cd6$948bc9a0$0b0110ac@ipitec.it> From: "Andrea Michelotti" To: "Andrew Lunn" Cc: References: <20040917115657.246B365C110@smtp.ecoscentric.com> Subject: Re: [Bug 1000096] new AT91 platform: JTST Date: Fri, 17 Sep 2004 16:47:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-SW-Source: 2004-09/txt/msg00015.txt.bz2 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. >