* Re: mpc8248 SEC -- interrupt handler not invoked
From: Kim Phillips @ 2005-07-29 20:33 UTC (permalink / raw)
To: Vikas Aggarwal; +Cc: linuxppc-embedded
In-Reply-To: <32704.198.22.236.230.1122651627.squirrel@198.22.236.230>
On Fri, 29 Jul 2005 11:40:27 -0400 (EDT)
"Vikas Aggarwal" <va824363@albany.edu> wrote:
> Hi All,
> Will appreciate if someone can guide me how to debug this inside SEC
> (security co-processor) core.
>
> The linux driver is writing descriptor into the FETCH-Register(0x2048)
> for Random Number generation execution unit(RNG-EU). The request came
> through a test program from user space. The RNG generation request never
> seems to complete as my ISR is not invoked.
> I checked the CCPSR(Crypto Channel Pointer Status register = 0x2010) and
> it has value=0:7(0-31 : 32-63 bits). 7 means "channel_error". But its
> always there even before I write the RNG descriptor to Fetch-register.
a value of 7 in bits 56-63 (PAIR_PTR) can suggest processing has not begun.
can you verify you are writing the upper bits of the FR (i.e. 0x204c)?
Kim
^ permalink raw reply
* Re: [PATCH 00/14] ppc32: Remove board ports that are no longer maintained
From: Kumar Gala @ 2005-07-29 18:10 UTC (permalink / raw)
To: Esben Nielsen
Cc: Andrew Morton, linux-kernel, Gala Kumar K.-galak,
linuxppc-embedded
In-Reply-To: <Pine.OSF.4.05.10507291900320.26224-100000@da410.phys.au.dk>
On Jul 29, 2005, at 12:03 PM, Esben Nielsen wrote:
>
>
> On Wed, 27 Jul 2005, Matt Porter wrote:
>
>
>> On Wed, Jul 27, 2005 at 09:27:41AM -0700, Eugene Surovegin wrote:
>>
>>> On Wed, Jul 27, 2005 at 12:13:23PM -0400, Michael Richardson wrote:
>>>
>>>> Kumar, I thought that we had some volunteers to take care of some
>>>>
> of
>
>>>> those. I know that I still care about ep405, and I'm willing to
>>>>
> maintain
>
>>>> the code.
>>>>
>>>
>>> Well, it has been almost two months since Kumar asked about
>>>
> maintenance
>
>>> for this board. Nothing happened since then.
>>>
>>> Why is it not fixed yet? Please, send a patch which fixes it. This
>>>
> is
>
>>> the _best_ way to keep this board in the tree, not some empty
>>> maintenance _promises_.
>>>
>>
>> When we recover our history from the linuxppc-2.4/2.5 trees we can
>> show exactly how long it's been since anybody touched ep405.
>>
>> Quick googling shows that it's been almost 2 years since the last
>> mention of ep405 (exluding removal discussions) on linuxppc-embedded.
>> Last ep405-related commits are more than 2 years ago.
>>
>>
> I don't follow that reasoning. Even broken drivers(board support
> files,
> whateever) are better than non.
>
> Take ArcNet support forinstance. Clearly it hadn't been used in any
> 2.6
> kernel up until around 2.6.10. It was highly broken (call to
> uninitialized function pointer). But I needed it. I fixed it and send
> the
> patch so it works from 2.6.11 and up. If the driver had been
> dropped in
> the 2.6 series because nobody actively maintained it, I wouldn't have
> got
> around to fix it at all and was probably forced to use another OS
> for my
> perpose.
>
> But because the driver was still in there and somebody had made
> sure it
> was updated along the changes to the API in the 2.6 kernel, it was
> easy
> for me to fix it although I didn't know so much about the kernel
> internals
> at that time.
The code will still exist in older kernel releases so if someone
needs to bring it up to date they can. We are more than willing to
take patches to fix any issues.
Let's be clear. I posted a request several weeks ago in which anyone
was free to comment on the various board ports that existed and their
maintainership.
- kumar
^ permalink raw reply
* Re: request_8xxirq
From: Dan Malek @ 2005-07-29 17:43 UTC (permalink / raw)
To: Tiago Dall'Agnol; +Cc: linuxppc-embedded
In-Reply-To: <42EA60E1.7040804@parks.com.br>
On Jul 29, 2005, at 1:01 PM, Tiago Dall'Agnol wrote:
> Am I wrong? I didn't understand when that function request_irq is used.
At some point I don't remember and against all of my wishes, the code
was changed from using request_8xxirq to using request_irq using
an ugly hack to add some offset to the 8xx interrupt vector number.
I didn't see any bug that needed fixing, but people with the power to
ignore my maintainer status decided to change it anyway. So, now you
have to modify your drivers to call request_irq() with some nonsensical
interrupt number. No value added, just confusion.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH 00/14] ppc32: Remove board ports that are no longer maintained
From: Esben Nielsen @ 2005-07-29 17:03 UTC (permalink / raw)
To: Matt Porter; +Cc: Andrew Morton, linux-kernel, Kumar Gala, linuxppc-embedded
In-Reply-To: <20050727101502.B1114@cox.net>
On Wed, 27 Jul 2005, Matt Porter wrote:
> On Wed, Jul 27, 2005 at 09:27:41AM -0700, Eugene Surovegin wrote:
> > On Wed, Jul 27, 2005 at 12:13:23PM -0400, Michael Richardson wrote:
> > > Kumar, I thought that we had some volunteers to take care of some of
> > > those. I know that I still care about ep405, and I'm willing to maintain
> > > the code.
> >
> > Well, it has been almost two months since Kumar asked about maintenance
> > for this board. Nothing happened since then.
> >
> > Why is it not fixed yet? Please, send a patch which fixes it. This is
> > the _best_ way to keep this board in the tree, not some empty
> > maintenance _promises_.
>
> When we recover our history from the linuxppc-2.4/2.5 trees we can
> show exactly how long it's been since anybody touched ep405.
>
> Quick googling shows that it's been almost 2 years since the last
> mention of ep405 (exluding removal discussions) on linuxppc-embedded.
> Last ep405-related commits are more than 2 years ago.
>
I don't follow that reasoning. Even broken drivers(board support files,
whateever) are better than non.
Take ArcNet support forinstance. Clearly it hadn't been used in any 2.6
kernel up until around 2.6.10. It was highly broken (call to
uninitialized function pointer). But I needed it. I fixed it and send the
patch so it works from 2.6.11 and up. If the driver had been dropped in
the 2.6 series because nobody actively maintained it, I wouldn't have got
around to fix it at all and was probably forced to use another OS for my
perpose.
But because the driver was still in there and somebody had made sure it
was updated along the changes to the API in the 2.6 kernel, it was easy
for me to fix it although I didn't know so much about the kernel internals
at that time.
Esben
^ permalink raw reply
* Re: request_8xxirq
From: Tiago Dall'Agnol @ 2005-07-29 17:01 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <20050729154359.1ac8f488.ajz@cambridgebroadband.com>
I'm using kernel 2.4.18, and I can see the code you posted.
But this code doesn't help to find request_8xxirq. It just do the
opposite. This code defines request_irq to be request_8xxirq when
CONFIG_8xx is defined. But where is located the implementation of
request_8xxirq?
Am I wrong? I didn't understand when that function request_irq is used.
Thanks
Tiago
Alex Zeffertt wrote:
>Maybe you're using a really old kernel. In linux-2.4.4 it's in
>arch/ppc/kernel/irq.c:
>
>-- snip --
>#if (defined(CONFIG_8xx) || defined(CONFIG_8260))
>/* Name change so we can catch standard drivers that potentially mess up
> * the internal interrupt controller on 8xx and 8260. Just bear with me,
> * I don't like this either and I am searching a better solution. For
> * now, this is what I need. -- Dan
> */
>#define request_irq request_8xxirq
>
>...
>...
>...
>
>int request_irq(unsigned int irq, void (*handler)(int, void *, struct pt_regs *),
> unsigned long irqflags, const char * devname, void *dev_id)
>{
>--/snip --
>
>
>I don't know why it was done like this....
>
>Alex
>
>
>On Fri, 29 Jul 2005 10:52:33 -0300
>"Tiago Dall'Agnol" <tdallagnol@parks.com.br> wrote:
>
>
>
>>Thank you Alex.
>>
>>But in my linux, this is different.
>>What I have in that file is just
>>
>>extern int request_8xxirq(unsigned int irq,
>> void (*handler)(int, void *, struct pt_regs *),
>> unsigned long flags,
>> const char *device,
>> void *dev_id);
>>
>>And the request_8xxirq is declared as a
>>
>>EXPORT_SYMBOL(request_8xxirq);
>>
>>in arch/ppc/kernel/ppc_ksyms.c.
>>
>>I already tried to find out where the code that implements the function
>>is located, but it seems that it doesn't exist in my distribuction.
>>Maybe is it a "binary version"?
>>
>>Any other information will be apreciated ;-)
>>
>>Best Regards,
>>Tiago
>>
>>Alex Zeffertt wrote:
>>
>>
>>
>>>In linux-2.4 it's in
>>>
>>> include/asm-ppc/mpc8xx.h
>>>
>>>-- snip --
>>>#define request_8xxirq request_irq
>>>--/snip --
>>>
>>>And request_irq is in arch/ppc/kernel/irq.c
>>>
>>>Alex
>>>
>>>On Fri, 29 Jul 2005 10:07:58 -0300
>>>"Tiago Dall'Agnol" <tdallagnol@parks.com.br> wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Hi,
>>>>
>>>>I had some problems with irq in my embedded system. I'm interested in
>>>>this function source code, but I didn't find it in my linux distribuction?
>>>>
>>>>Does anyone know where I can find it?
>>>>
>>>>Thanks a lot
>>>>Tiago
>>>>
>>>>Manish Joshi wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>I am working on an old code which uses request_8xxirq() call which I
>>>>>can't find in latest kernel.
>>>>>Has this been replaced by something else ?
>>>>>
>>>>>I see the references on net about replacing request_8xxirq() with
>>>>>request_irq(). Can I do it ?
>>>>>
>>>>>TIA,
>>>>>Manish
>>>>>
>>>>>
>>>>>------------------------------------------------------------------------
>>>>>Start your day with Yahoo! - make it your home page
>>>>><http://us.rd.yahoo.com/evt=34442/*http://www.yahoo.com/r/hs>
>>>>>
>>>>>------------------------------------------------------------------------
>>>>>
>>>>>_______________________________________________
>>>>>Linuxppc-embedded mailing list
>>>>>Linuxppc-embedded@ozlabs.org
>>>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>--
>>>>Tiago Dall'Agnol
>>>>Pesquisa e Desenvolvimento
>>>>Tel.: +55.51.470.05.64
>>>>Fax.: +55.51.470.05.70
>>>>e-mail: tdallagnol@parks.com.br
>>>>www.parks.com.br
>>>>
>>>>_______________________________________________
>>>>Linuxppc-embedded mailing list
>>>>Linuxppc-embedded@ozlabs.org
>>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>--
>>
>>
>
>
>
--
Tiago Dall'Agnol
Pesquisa e Desenvolvimento
Tel.: +55.51.470.05.64
Fax.: +55.51.470.05.70
e-mail: tdallagnol@parks.com.br
Parks S.A. Comunicações Digitais
www.parks.com.br
^ permalink raw reply
* Re: [PATCH 00/14] ppc32: Remove board ports that are no longer maintained
From: Michael Richardson @ 2005-07-29 16:33 UTC (permalink / raw)
To: Kumar Gala
Cc: Andrew Morton, linux-kernel, kyle, Gala Kumar K.-galak,
linuxppc-embedded
In-Reply-To: <3965D4DD-1628-4463-890F-106DB5BC6931@freescale.com>
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Kumar" == Kumar Gala <kumar.gala@freescale.com> writes:
>> When we recover our history from the linuxppc-2.4/2.5 trees we
>> can show exactly how long it's been since anybody touched ep405.
>>
>> Quick googling shows that it's been almost 2 years since the last
>> mention of ep405 (exluding removal discussions) on
>> linuxppc-embedded. Last ep405-related commits are more than 2
>> years ago.
So, I'll bet I can find other parts of the kernel tree that haven't
been touched in 2 years. Maybe there isn't anything to fix?
Happens that in our case,
a) the board is the basis to our own board.
b) we only moved to 2.6 in May.
So, I just don't get removing board support files.
- --
] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [
] mcr @ xelerance.com Now doing IPsec training, see |net architect[
] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[
] I'm a dad: http://www.sandelman.ca/lrmr/ [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQupaXIqHRg3pndX9AQFnGQP+JXX0ZTKW35LljC/ighUPpmcdClRlmWP2
fsnofXYNi2v9QEkYpoS8pHMc3ClKHT8MFzK/nsDe1CFWPxxavK+365usf77DSGWB
bjZ8CZWjkvDt7IMjBxEnSlzCTVt39Gtjq1zM/DMY0SOi1ccB7TIZE+1Ol3zkYnW5
2X6+0SKgS6Q=
=kcQj
-----END PGP SIGNATURE-----
^ permalink raw reply
* mpc8248 SEC -- interrupt handler not invoked
From: Vikas Aggarwal @ 2005-07-29 15:40 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
Will appreciate if someone can guide me how to debug this inside SEC
(security co-processor) core.
The linux driver is writing descriptor into the FETCH-Register(0x2048)
for Random Number generation execution unit(RNG-EU). The request came
through a test program from user space. The RNG generation request never
seems to complete as my ISR is not invoked.
I checked the CCPSR(Crypto Channel Pointer Status register = 0x2010) and
it has value=0:7(0-31 : 32-63 bits). 7 means "channel_error". But its
always there even before I write the RNG descriptor to Fetch-register.
1. I can read the ID register and verified it is 0x09000000.
2. I can see my ISR is registered(0x47) under /proc/interrupts.
I don't see anything wrong with the descriptor which is very simple Random
Number Generation request.
regards
-vikas aggarwal
^ permalink raw reply
* Re: ATI Radeon with PPC 440 GX and kernel 2.6.12
From: Wolfgang Denk @ 2005-07-29 15:10 UTC (permalink / raw)
To: David Grab; +Cc: linuxppc-embedded
In-Reply-To: <001f01c59417$fe81b840$f201a8c0@SN7606>
In message <001f01c59417$fe81b840$f201a8c0@SN7606> you wrote:
>
> i´m using on my custom board a ATI M6 Mobility Radeon with kernel 2.6.12.
> Now i have to initialize the ati and configure the kernel to support it. Did
> someone use this combination (ppc + ati radeon)? It would be appreciating to
> get some help or tipps in configuring to get the ati functioning. Especially
> the BIOS of the ATI chip, because i have actually found only x86 binaries.
> Is it also possible to set up the bios settings for the ati chip without an
> bios eeprom attached via the radeon driver?
If you use U-Boot as boot loader you can enable and use the x86
emulator taht comes included with it. But don't expect to much help
with that - except for the Amiga One (where I was told this is
working) I don't know of any other board using this feature.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Two wrongs don't make a right, but three rights make a left.
^ permalink raw reply
* Re: request_8xxirq
From: Alex Zeffertt @ 2005-07-29 14:43 UTC (permalink / raw)
To: Tiago Dall'Agnol; +Cc: linuxppc-embedded
In-Reply-To: <42EA34A1.7060600@parks.com.br>
Maybe you're using a really old kernel. In linux-2.4.4 it's in
arch/ppc/kernel/irq.c:
-- snip --
#if (defined(CONFIG_8xx) || defined(CONFIG_8260))
/* Name change so we can catch standard drivers that potentially mess up
* the internal interrupt controller on 8xx and 8260. Just bear with me,
* I don't like this either and I am searching a better solution. For
* now, this is what I need. -- Dan
*/
#define request_irq request_8xxirq
...
...
...
int request_irq(unsigned int irq, void (*handler)(int, void *, struct pt_regs *),
unsigned long irqflags, const char * devname, void *dev_id)
{
--/snip --
I don't know why it was done like this....
Alex
On Fri, 29 Jul 2005 10:52:33 -0300
"Tiago Dall'Agnol" <tdallagnol@parks.com.br> wrote:
> Thank you Alex.
>
> But in my linux, this is different.
> What I have in that file is just
>
> extern int request_8xxirq(unsigned int irq,
> void (*handler)(int, void *, struct pt_regs *),
> unsigned long flags,
> const char *device,
> void *dev_id);
>
> And the request_8xxirq is declared as a
>
> EXPORT_SYMBOL(request_8xxirq);
>
> in arch/ppc/kernel/ppc_ksyms.c.
>
> I already tried to find out where the code that implements the function
> is located, but it seems that it doesn't exist in my distribuction.
> Maybe is it a "binary version"?
>
> Any other information will be apreciated ;-)
>
> Best Regards,
> Tiago
>
> Alex Zeffertt wrote:
>
> >In linux-2.4 it's in
> >
> > include/asm-ppc/mpc8xx.h
> >
> >-- snip --
> >#define request_8xxirq request_irq
> >--/snip --
> >
> >And request_irq is in arch/ppc/kernel/irq.c
> >
> >Alex
> >
> >On Fri, 29 Jul 2005 10:07:58 -0300
> >"Tiago Dall'Agnol" <tdallagnol@parks.com.br> wrote:
> >
> >
> >
> >>Hi,
> >>
> >>I had some problems with irq in my embedded system. I'm interested in
> >>this function source code, but I didn't find it in my linux distribuction?
> >>
> >>Does anyone know where I can find it?
> >>
> >>Thanks a lot
> >>Tiago
> >>
> >>Manish Joshi wrote:
> >>
> >>
> >>
> >>>Hi,
> >>>
> >>>I am working on an old code which uses request_8xxirq() call which I
> >>>can't find in latest kernel.
> >>>Has this been replaced by something else ?
> >>>
> >>>I see the references on net about replacing request_8xxirq() with
> >>>request_irq(). Can I do it ?
> >>>
> >>>TIA,
> >>>Manish
> >>>
> >>>
> >>>------------------------------------------------------------------------
> >>>Start your day with Yahoo! - make it your home page
> >>><http://us.rd.yahoo.com/evt=34442/*http://www.yahoo.com/r/hs>
> >>>
> >>>------------------------------------------------------------------------
> >>>
> >>>_______________________________________________
> >>>Linuxppc-embedded mailing list
> >>>Linuxppc-embedded@ozlabs.org
> >>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>>
> >>>
> >>>
> >>--
> >>Tiago Dall'Agnol
> >>Pesquisa e Desenvolvimento
> >>Tel.: +55.51.470.05.64
> >>Fax.: +55.51.470.05.70
> >>e-mail: tdallagnol@parks.com.br
> >>www.parks.com.br
> >>
> >>_______________________________________________
> >>Linuxppc-embedded mailing list
> >>Linuxppc-embedded@ozlabs.org
> >>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>
> >>
> >
> >
> >
>
> --
^ permalink raw reply
* Re: ATI Radeon with PPC 440 GX and kernel 2.6.12
From: Matt Porter @ 2005-07-29 14:29 UTC (permalink / raw)
To: David Grab; +Cc: linuxppc-embedded
In-Reply-To: <001f01c59417$fe81b840$f201a8c0@SN7606>
On Fri, Jul 29, 2005 at 10:32:01AM +0200, David Grab wrote:
> Hello,
>
> i´m using on my custom board a ATI M6 Mobility Radeon with kernel 2.6.12.
> Now i have to initialize the ati and configure the kernel to support it. Did
> someone use this combination (ppc + ati radeon)? It would be appreciating to
> get some help or tipps in configuring to get the ati functioning. Especially
> the BIOS of the ATI chip, because i have actually found only x86 binaries.
> Is it also possible to set up the bios settings for the ati chip without an
> bios eeprom attached via the radeon driver?
There is a x86 emulator that can execute x86 VGA BIOS code to initialize
your VGA core in U-Boot. It's part of the MAI port so you can look at
that code and port it to your board. It is actually some scitechsoft
code that's been ported to build within U-Boot.
Gabriel Paubert's preploader code also has an x86 real mode emulator
written in PPC assembly that does the same thing, but it may be more
convenient to work with the stuff in U-Boot. It doesn't help that I
can seem to find a current link to the preploader code. Maybe Gabriel
can appear and provide it.
-Matt
^ permalink raw reply
* Re: request_8xxirq
From: Tiago Dall'Agnol @ 2005-07-29 13:52 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <20050729144015.09fec9fe.ajz@cambridgebroadband.com>
Thank you Alex.
But in my linux, this is different.
What I have in that file is just
extern int request_8xxirq(unsigned int irq,
void (*handler)(int, void *, struct pt_regs *),
unsigned long flags,
const char *device,
void *dev_id);
And the request_8xxirq is declared as a
EXPORT_SYMBOL(request_8xxirq);
in arch/ppc/kernel/ppc_ksyms.c.
I already tried to find out where the code that implements the function
is located, but it seems that it doesn't exist in my distribuction.
Maybe is it a "binary version"?
Any other information will be apreciated ;-)
Best Regards,
Tiago
Alex Zeffertt wrote:
>In linux-2.4 it's in
>
> include/asm-ppc/mpc8xx.h
>
>-- snip --
>#define request_8xxirq request_irq
>--/snip --
>
>And request_irq is in arch/ppc/kernel/irq.c
>
>Alex
>
>On Fri, 29 Jul 2005 10:07:58 -0300
>"Tiago Dall'Agnol" <tdallagnol@parks.com.br> wrote:
>
>
>
>>Hi,
>>
>>I had some problems with irq in my embedded system. I'm interested in
>>this function source code, but I didn't find it in my linux distribuction?
>>
>>Does anyone know where I can find it?
>>
>>Thanks a lot
>>Tiago
>>
>>Manish Joshi wrote:
>>
>>
>>
>>>Hi,
>>>
>>>I am working on an old code which uses request_8xxirq() call which I
>>>can't find in latest kernel.
>>>Has this been replaced by something else ?
>>>
>>>I see the references on net about replacing request_8xxirq() with
>>>request_irq(). Can I do it ?
>>>
>>>TIA,
>>>Manish
>>>
>>>
>>>------------------------------------------------------------------------
>>>Start your day with Yahoo! - make it your home page
>>><http://us.rd.yahoo.com/evt=34442/*http://www.yahoo.com/r/hs>
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>Linuxppc-embedded mailing list
>>>Linuxppc-embedded@ozlabs.org
>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>>
>>>
>>--
>>Tiago Dall'Agnol
>>Pesquisa e Desenvolvimento
>>Tel.: +55.51.470.05.64
>>Fax.: +55.51.470.05.70
>>e-mail: tdallagnol@parks.com.br
>>www.parks.com.br
>>
>>_______________________________________________
>>Linuxppc-embedded mailing list
>>Linuxppc-embedded@ozlabs.org
>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>
>
>
--
^ permalink raw reply
* Re: request_8xxirq
From: Alex Zeffertt @ 2005-07-29 13:40 UTC (permalink / raw)
To: Tiago Dall'Agnol; +Cc: linuxppc-embedded
In-Reply-To: <42EA2A2E.5040708@parks.com.br>
In linux-2.4 it's in
include/asm-ppc/mpc8xx.h
-- snip --
#define request_8xxirq request_irq
--/snip --
And request_irq is in arch/ppc/kernel/irq.c
Alex
On Fri, 29 Jul 2005 10:07:58 -0300
"Tiago Dall'Agnol" <tdallagnol@parks.com.br> wrote:
> Hi,
>
> I had some problems with irq in my embedded system. I'm interested in
> this function source code, but I didn't find it in my linux distribuction?
>
> Does anyone know where I can find it?
>
> Thanks a lot
> Tiago
>
> Manish Joshi wrote:
>
> > Hi,
> >
> > I am working on an old code which uses request_8xxirq() call which I
> > can't find in latest kernel.
> > Has this been replaced by something else ?
> >
> > I see the references on net about replacing request_8xxirq() with
> > request_irq(). Can I do it ?
> >
> > TIA,
> > Manish
> >
> >
> > ------------------------------------------------------------------------
> > Start your day with Yahoo! - make it your home page
> > <http://us.rd.yahoo.com/evt=34442/*http://www.yahoo.com/r/hs>
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
> --
> Tiago Dall'Agnol
> Pesquisa e Desenvolvimento
> Tel.: +55.51.470.05.64
> Fax.: +55.51.470.05.70
> e-mail: tdallagnol@parks.com.br
> www.parks.com.br
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: request_8xxirq
From: Tiago Dall'Agnol @ 2005-07-29 13:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050729013303.33814.qmail@web40712.mail.yahoo.com>
Hi,
I had some problems with irq in my embedded system. I'm interested in
this function source code, but I didn't find it in my linux distribuction?
Does anyone know where I can find it?
Thanks a lot
Tiago
Manish Joshi wrote:
> Hi,
>
> I am working on an old code which uses request_8xxirq() call which I
> can't find in latest kernel.
> Has this been replaced by something else ?
>
> I see the references on net about replacing request_8xxirq() with
> request_irq(). Can I do it ?
>
> TIA,
> Manish
>
>
> ------------------------------------------------------------------------
> Start your day with Yahoo! - make it your home page
> <http://us.rd.yahoo.com/evt=34442/*http://www.yahoo.com/r/hs>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Tiago Dall'Agnol
Pesquisa e Desenvolvimento
Tel.: +55.51.470.05.64
Fax.: +55.51.470.05.70
e-mail: tdallagnol@parks.com.br
Parks S.A. Comunicações Digitais
www.parks.com.br
^ permalink raw reply
* mpc8245-300M MIPS
From: Debora Liu @ 2005-07-29 10:27 UTC (permalink / raw)
To: linuxppc-embedde
linuxppc-embeddeHi ALL,
I am porting MPC8245 kernel-2.4.25 from ELDK version 3.1.1.
This CPU(MPC8245) is 300MHz, kernel calibrate MIPS is 200.
Do anyone know this MIPS is right?
U-Boot 1.1.2 (Jan 25 2005 - 14:55:00) [svm]
CPU: MPC8245 Revision 1.1 at 299.999 MHz: 16 kB I-Cache 16 kB D-Cache
Board: SVM_SC8245 Local Bus at 99.999 MHz
I2C: ready
DRAM: Scan SDRAM memory........................
64 MB
Top of RAM usable for U-Boot at: 04000000
Reserving 460k for U-Boot at: 03f8c000
Reserving 128k for malloc() at: 03f6c000
Reserving 56 Bytes for Board Info at: 03f6bfc8
Reserving 48 Bytes for Global Data at: 03f6bf98
Stack Pointer at: 03f6bf78
New Stack Pointer is: 03f6bf78
Now running in RAM - U-Boot at: 03f8c000
FLASH: 512 kB
PCI Scan: Found Bus 0, Device 22, Function 0
PCI Config: I/O=0x80000000, Memory=0x80000000, Command=0x7
00 16 10ec 8139 0200 0b
PCI Scan: Found Bus 0, Device 23, Function 0
PCI Config: I/O=0x81000000, Memory=0x81000000, Command=0x7
00 17 8086 1209 0200 0c
PCI Scan: Found Bus 0, Device 24, Function 0
00 18 8086 1209 0200 0e
In: serial
Out: serial
Err: serial
U-Boot relocated to 03f8c000
DOC: No DiskOnChip found
Net: rtl8139: REALTEK RTL8139 @0x80000000(80000000)
i82559#0
Warning: i82559#0 MAC addresses don't match:
Address in SROM is 00:AA:00:91:6D:94
Address in environment is EE:CC:7C:7E:65:97
, i82559#1, RTL8139#0
### main_loop entered: bootdelay=2
### main_loop: bootcmd="tftpboot 0x210000 kernel-sc82xx-2.4.25-eldk;bootm 0x2100
00"
Hit any key to stop autoboot: 0
Trying i82559#0
Using i82559#0 device
TFTP from server 192.168.0.82; our IP address is 192.168.0.215
Filename 'kernel-sc82xx-2.4.25-eldk'.
Load address: 0x210000
Loading: #################################################################
#################################################################
###########
done
Bytes transferred = 718901 (af835 hex)
## Booting image at 00210000 ...
Image Name: Linux-2.4.25
Created: 2005-07-29 5:42:02 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 718837 Bytes = 702 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x03F6BBE8 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF7E
bd address = 0x03F6BFC8
memstart = 0x00000000
memsize = 0x04000000
flashstart = 0xFFF00000
flashsize = 0x00080000
flashoffset = 0x00068000
sramstart = 0x00000000
sramsize = 0x00000000
bootflags = 0x00000001
intfreq = 299.999 MHz
busfreq = 99.999 MHz
ethaddr = EE:CC:7C:7E:65:97
IP addr = 192.168.0.215
baudrate = 115200 bps
No initrd
## Transferring control to Linux (at address 00000000) ...
Memory BAT mapping: BAT2=64Mb, BAT3=0Mb, residual: 0Mb
Linux version 2.4.25 (liu@bighead) (gcc version 3.3.3 (DENX ELDK 3.1.1 3.3.3-9))
#2 ? 7? 29 13:41:52 CST 2005
sc82xx_setup_arch:Reserved 0x10000 memory at 0xc01b4000
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/nfs rw nfsroot=192.168.0.82:/prj/sc8245/root cons
ole=ttyS0,115200 ip=192.168.0.215:192.168.0.82:::itogether:eth0:off
OpenPIC Version 1.2 (1 CPUs and 7 IRQ sources) at fdfd0000
bi_intfreq:299999997 bi_busfreq:99999999
Calibrating delay loop... 199.88 BogoMIPS
Debora Liu
deboralh@fel.com.cn
2005-07-29
^ permalink raw reply
* ATI Radeon with PPC 440 GX and kernel 2.6.12
From: David Grab @ 2005-07-29 8:32 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
i´m using on my custom board a ATI M6 Mobility Radeon with kernel 2.6.12.
Now i have to initialize the ati and configure the kernel to support it. Did
someone use this combination (ppc + ati radeon)? It would be appreciating to
get some help or tipps in configuring to get the ati functioning. Especially
the BIOS of the ATI chip, because i have actually found only x86 binaries.
Is it also possible to set up the bios settings for the ati chip without an
bios eeprom attached via the radeon driver?
Thanks for any help,
David
^ permalink raw reply
* 答复: How to load a linux kernel under vxworks bootloader (PPC860 board)
From: FCG WANG Baohua @ 2005-07-29 8:27 UTC (permalink / raw)
To: John W. Linville; +Cc: linuxppc-embedded
Dear linville:
I found that the vxWorks bootrom is load to RAM 0x2800100 address, but =
different address with the different kernel file downloading to the RAM.
For example: the ppcboot ELF file is downloaded to the 0x2800000 and =
only 150256 bytes is downloaded (total file size is 989064 bytes)
the zImage kernel file is downloaded to the =
0x380000 and only 533004 bytes is downloaded (total file size is 591899 =
bytes)
What's the reason for explain it? Does the vxWorks bootloader =
uncompressed the file with its own algorithm?=20
How to download the U-Boot ELF file correctly? Thanks!=20
The right way is to find the right entry points of U-Boot, but =
whatever I change the configure of U-Boot, it doesn't work at all. That =
is, the entry point is=20
forever 0x2800000 for U-Boot and 0x380000 for zImage.=20
=20
-----=D4=AD=CA=BC=D3=CA=BC=FE-----
=B7=A2=BC=FE=C8=CB: John W. Linville [mailto:linville@tuxdriver.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA7=D4=C229=C8=D5 0:58
=CA=D5=BC=FE=C8=CB: FCG WANG Baohua
=D6=F7=CC=E2: Re: How to load a linux kernel under vxworks bootloader =
(PPC860
board)
On Thu, Jul 28, 2005 at 01:02:04PM +0800, FCG WANG Baohua wrote:
> Dear linville:
> I want to boot a linux 2.4.25 kernel under vxworks
> bootloader. When I using flat mode(0x200000 --> 0x10000)
> kernel uncompressed ELF format ( vmlinux ),
> and download it using TFTP of vxworks, it print the "starting
> at 0x1000 ...." and freeze. No input or output on serial port.
> The version of vxworks is 5.3.1.=20
> can you give me some detail advice or give me a tool to slove
> it? thanks !
It looks like Guy Streeter gave you as good advice as I could give.
Be sure to read his post on linuxppc-embedded.
In the past there was an issue in that the VxWorks boot loader only
loaded .text and .data sections from ELF images. At that time,
zImage files packed the "real" kernel image into an extra section
in the ELF file, and the VxWorks loader would not load it. The fix
then was to hack the ELF header to make the extra section appear to
be part of the .data section.
Thankfully, I recall that later kernel versions did not have that
problem. I think using a zImage (or zImage.initrd) file that has
been properly modified to support your board should be all that
is necessary. Using a zImage is necessary because it includes a
"shim" that knows how to communicate critical information to the
actual Linux kernel. The VxWorks boot loader does not provide this
information to Linux.
As someone else suggested, your best bet would be to use U-Boot or some
other loader that understands Linux. U-Boot ports are fairly simple.
If you don't want to do one, you probably could convince me to do
a U-Boot port if you wanted to send me a board (and possibly some
reasonably compensation)... :-)
Good luck!
John
--=20
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Unauthorized transactions on your account
From: security @ 2005-07-29 1:26 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 14005 bytes --]
^ permalink raw reply
* 答复: How to load a linux kernel under vxworks bootloader (PPC860 board)
From: FCG WANG Baohua @ 2005-07-29 2:13 UTC (permalink / raw)
To: John W. Linville; +Cc: linuxppc-embedded
Dear Linville:
I use the zImage to download to RAM from the vmlinux TFTP. The =
strange thins happened :=20
The serial console print the following message and halted :
"Starting at 0x380000... "
I want to ask:
I. I saw the System.map is starting at the address 0x00000, but why =
the zImage is starting at 0x380000 ?=20
2. "Thankfully, I recall that later kernel versions did not have that =
problem."
I use the ELDK3.1.1, kernel 2.4.25.tar.bz2, Which version had you =
revised the kernel ? 2.6.x ?
If I need the 2.4.25 (for its config file fits the PPC860 ADS), =
What can I do ?=20
3. In the vxworks BSP Makefile :
ROM_TEXT_ADRS =3D 02800100 # ROM entry address
ROM_SIZE =3D 00200000 # number of bytes of ROM space
RAM_LOW_ADRS =3D 00010000 # RAM text/data address
RAM_HIGH_ADRS =3D 00200000 # RAM text/data address
=20
How can I relocate to the right address if I download the linux =
kernel and excute it in RAM?=20
=20
Thanks a lot !
-----=D4=AD=CA=BC=D3=CA=BC=FE-----
=B7=A2=BC=FE=C8=CB: John W. Linville [mailto:linville@tuxdriver.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA7=D4=C229=C8=D5 0:58
=CA=D5=BC=FE=C8=CB: FCG WANG Baohua
=D6=F7=CC=E2: Re: How to load a linux kernel under vxworks bootloader =
(PPC860
board)
On Thu, Jul 28, 2005 at 01:02:04PM +0800, FCG WANG Baohua wrote:
> Dear linville:
> I want to boot a linux 2.4.25 kernel under vxworks
> bootloader. When I using flat mode(0x200000 --> 0x10000)
> kernel uncompressed ELF format ( vmlinux ),
> and download it using TFTP of vxworks, it print the "starting
> at 0x1000 ...." and freeze. No input or output on serial port.
> The version of vxworks is 5.3.1.=20
> can you give me some detail advice or give me a tool to slove
> it? thanks !
It looks like Guy Streeter gave you as good advice as I could give.
Be sure to read his post on linuxppc-embedded.
In the past there was an issue in that the VxWorks boot loader only
loaded .text and .data sections from ELF images. At that time,
zImage files packed the "real" kernel image into an extra section
in the ELF file, and the VxWorks loader would not load it. The fix
then was to hack the ELF header to make the extra section appear to
be part of the .data section.
Thankfully, I recall that later kernel versions did not have that
problem. I think using a zImage (or zImage.initrd) file that has
been properly modified to support your board should be all that
is necessary. Using a zImage is necessary because it includes a
"shim" that knows how to communicate critical information to the
actual Linux kernel. The VxWorks boot loader does not provide this
information to Linux.
As someone else suggested, your best bet would be to use U-Boot or some
other loader that understands Linux. U-Boot ports are fairly simple.
If you don't want to do one, you probably could convince me to do
a U-Boot port if you wanted to send me a board (and possibly some
reasonably compensation)... :-)
Good luck!
John
--=20
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* request_8xxirq
From: Manish Joshi @ 2005-07-29 1:33 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 353 bytes --]
Hi,
I am working on an old code which uses request_8xxirq() call which I can't find in latest kernel.
Has this been replaced by something else ?
I see the references on net about replacing request_8xxirq() with request_irq(). Can I do it ?
TIA,
Manish
---------------------------------
Start your day with Yahoo! - make it your home page
[-- Attachment #2: Type: text/html, Size: 545 bytes --]
^ permalink raw reply
* Re: eth1 on linux 2.4.25 from ELDK 3.1.1 becomes slowly when is pinged by great packets
From: Wolfgang Denk @ 2005-07-28 23:08 UTC (permalink / raw)
To: Igor Marnat; +Cc: linuxppc-embedded
In-Reply-To: <200507282018.17849.marny@rambler.ru>
In message <200507282018.17849.marny@rambler.ru> you wrote:
>
> Wolfgang, thank you!
You are welcome.
> I've renewed the kernel from CVS and it works much better now.
Fine.
> By the way, the driver for PPChameleonEVB is presented in linuxppc_2_4_devel
> module only and is not presented in linux-2.4 module of CVS (there miss the
Yes, this is intentional. The linux-2.4 module is a more or less
frozen version of linux kernel version 2.4.4 which we keep alife
because some of our customers continue to use this in their projects.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"In Christianity neither morality nor religion come into contact with
reality at any point." - Friedrich Nietzsche
^ permalink raw reply
* [PATCH] 8xx: using dma_alloc_coherent() instead consistent_alloc()
From: Marcelo Tosatti @ 2005-07-28 9:14 UTC (permalink / raw)
To: akpm; +Cc: linux-ppc-embedded
From: Aristeu Sergio Rozanski Filho <aris@conectiva.com.br>
8xx: using dma_alloc_coherent() instead consistent_alloc()
Signed-off-by: Aristeu Sergio Rozanski Filho <aris@conectiva.com.br>
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Index: 2.6-8xx/arch/ppc/8xx_io/fec.c
===================================================================
--- 2.6-8xx.orig/arch/ppc/8xx_io/fec.c 2005-07-04 11:45:57.000000000 -0300
+++ 2.6-8xx/arch/ppc/8xx_io/fec.c 2005-07-04 11:45:58.000000000 -0300
@@ -1580,7 +1580,7 @@
struct fec_enet_private *fep;
int i, j, k, err;
unsigned char *eap, *iap, *ba;
- unsigned long mem_addr;
+ dma_addr_t mem_addr;
volatile cbd_t *bdp;
cbd_t *cbd_base;
volatile immap_t *immap;
@@ -1645,7 +1645,8 @@
printk("FEC initialization failed.\n");
return 1;
}
- cbd_base = (cbd_t *)consistent_alloc(GFP_KERNEL, PAGE_SIZE, &mem_addr);
+ cbd_base = (cbd_t *)dma_alloc_coherent(dev->class_dev.dev, PAGE_SIZE,
+ &mem_addr, GFP_KERNEL);
/* Set receive and transmit descriptor base.
*/
@@ -1662,7 +1663,10 @@
/* Allocate a page.
*/
- ba = (unsigned char *)consistent_alloc(GFP_KERNEL, PAGE_SIZE, &mem_addr);
+ ba = (unsigned char *)dma_alloc_coherent(dev->class_dev.dev,
+ PAGE_SIZE,
+ &mem_addr,
+ GFP_KERNEL);
/* BUG: no check for failure */
/* Initialize the BD for every fragment in the page.
^ permalink raw reply
* [PATCH] 8xx: convert fec driver to use work_struct
From: Marcelo Tosatti @ 2005-07-28 9:13 UTC (permalink / raw)
To: akpm; +Cc: linux-ppc-embedded
From: Aristeu Sergio Rozanski Filho <aris@cathedrallabs.org>
8xx: convert fec driver to use work_struct
Signed-off-by: Aristeu Sergio Rozanski Filho <aris@conectiva.com.br>
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Index: 2.6-8xx/arch/ppc/8xx_io/fec.c
===================================================================
--- 2.6-8xx.orig/arch/ppc/8xx_io/fec.c 2005-07-04 11:40:54.000000000 -0300
+++ 2.6-8xx/arch/ppc/8xx_io/fec.c 2005-07-04 11:45:57.000000000 -0300
@@ -173,7 +173,7 @@
uint phy_status;
uint phy_speed;
phy_info_t *phy;
- struct tq_struct phy_task;
+ struct work_struct phy_task;
uint sequence_done;
@@ -1263,8 +1263,9 @@
printk(".\n");
}
-static void mii_display_config(struct net_device *dev)
+static void mii_display_config(void *priv)
{
+ struct net_device *dev = (struct net_device *)priv;
struct fec_enet_private *fep = dev->priv;
volatile uint *s = &(fep->phy_status);
@@ -1294,8 +1295,9 @@
fep->sequence_done = 1;
}
-static void mii_relink(struct net_device *dev)
+static void mii_relink(void *priv)
{
+ struct net_device *dev = (struct net_device *)priv;
struct fec_enet_private *fep = dev->priv;
int duplex;
@@ -1323,18 +1325,16 @@
{
struct fec_enet_private *fep = dev->priv;
- fep->phy_task.routine = (void *)mii_relink;
- fep->phy_task.data = dev;
- schedule_task(&fep->phy_task);
+ INIT_WORK(&fep->phy_task, mii_relink, (void *)dev);
+ schedule_work(&fep->phy_task);
}
static void mii_queue_config(uint mii_reg, struct net_device *dev)
{
struct fec_enet_private *fep = dev->priv;
- fep->phy_task.routine = (void *)mii_display_config;
- fep->phy_task.data = dev;
- schedule_task(&fep->phy_task);
+ INIT_WORK(&fep->phy_task, mii_display_config, (void *)dev);
+ schedule_work(&fep->phy_task);
}
^ permalink raw reply
* [PATCH] 8xx: fec: fix interrupt handler prototypes
From: Marcelo Tosatti @ 2005-07-28 9:16 UTC (permalink / raw)
To: akpm; +Cc: linux-ppc-embedded
From: Aristeu Sergio Rozanski Filho <aris@cathedrallabs.org>
8xx: fec: fix interrupt handler prototypes
Signed-off-by: Aristeu Sergio Rozanski Filho <aris@conectiva.com.br>
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Index: 2.6-8xx/arch/ppc/8xx_io/fec.c
===================================================================
--- 2.6-8xx.orig/arch/ppc/8xx_io/fec.c 2005-07-04 11:45:57.000000000 -0300
+++ 2.6-8xx/arch/ppc/8xx_io/fec.c 2005-07-04 11:45:57.000000000 -0300
@@ -199,7 +199,8 @@
#ifdef CONFIG_USE_MDIO
static void fec_enet_mii(struct net_device *dev);
#endif /* CONFIG_USE_MDIO */
-static void fec_enet_interrupt(int irq, void * dev_id, struct pt_regs * regs);
+static irqreturn_t fec_enet_interrupt(int irq, void * dev_id,
+ struct pt_regs * regs);
#ifdef CONFIG_FEC_PACKETHOOK
static void fec_enet_tx(struct net_device *dev, __u32 regval);
static void fec_enet_rx(struct net_device *dev, __u32 regval);
@@ -471,7 +472,7 @@
/* The interrupt handler.
* This is called from the MPC core interrupt.
*/
-static void
+static irqreturn_t
fec_enet_interrupt(int irq, void * dev_id, struct pt_regs * regs)
{
struct net_device *dev = dev_id;
@@ -525,6 +526,7 @@
}
}
+ return IRQ_RETVAL(IRQ_HANDLED);
}
@@ -1403,11 +1405,11 @@
/* This interrupt occurs when the PHY detects a link change.
*/
-static void
+static
#ifdef CONFIG_RPXCLASSIC
-mii_link_interrupt(void *dev_id)
+void mii_link_interrupt(void *dev_id)
#else
-mii_link_interrupt(int irq, void * dev_id, struct pt_regs * regs)
+irqreturn_t mii_link_interrupt(int irq, void * dev_id, struct pt_regs * regs)
#endif
{
#ifdef CONFIG_USE_MDIO
@@ -1440,6 +1442,9 @@
printk("%s[%d] %s: unexpected Link interrupt\n", __FILE__,__LINE__,__FUNCTION__);
#endif /* CONFIG_USE_MDIO */
+#ifndef CONFIG_RPXCLASSIC
+ return IRQ_RETVAL(IRQ_HANDLED);
+#endif /* CONFIG_RPXCLASSIC */
}
static int
^ permalink raw reply
* Linux 2.6.12.1 PowerPC 750FX Initialization Failures (Caching & MMU)
From: Goodman, Brad @ 2005-07-28 21:11 UTC (permalink / raw)
To: Linuxppc-dev
I am running the 2.6.12.1 Kernel with a Force CPCI-695 board.
(This board has a PPC 750FX, with a Marvell Disco II (MV64360) - although it uses a 8250, instead of the Disco II UART.)
Anyway…
This thing is hanging like a buffalo on bootup - in early Kernel initialization:
I setup_common_caches it gets to here:
mfspr r11,SPRN_HID0 ← HID0 is 0x800200a4
andi. r0,r11,HID0_DCE
ori r11,r11,HID0_ICE|HID0_DCE
ori r8,r11,HID0_ICFI
bne 1f /* don't invalidate the D-cache */
ori r8,r8,HID0_DCI /* unless it wasn't enabled */
1: sync
mtspr SPRN_HID0,r8 /* enable and invalidate caches */ ← r8 is now 0x8002cca4
### NEVER GETS HERE
sync
mtspr SPRN_HID0,r11 /* enable caches */
mr r3,r11
So it's hanging trying to enable and invalidate the caches.
So - trying to ditch that problem until later - I had it leave the caches off and continuing.
Now, it gets to the point where it tries to enable the MMU, and in the turn_on_mmu function it appears to go unresponsive right after the return-from-interrupt:
turn_on_mmu:
mfmsr r0
ori r0,r0,MSR_DR|MSR_IR
mtspr SPRN_SRR1,r0
lis r0,start_here@h
ori r0,r0,start_here@l
mtspr SPRN_SRR0,r0
SYNC
## GETS HERE
RFI /* enables MMU */
I put a check in start_here - and it never reaches it. The BATs should all be set up per-normal initialization, and I verified that it was mapping Physical address 0 to Effective Address 0xc0000000 - but still no luck.
BTW - I am loading my znetboot image (zImage with no ELF header) at 0x800000 - so it's not relocating on startup (and verified that this was happening correctly.)
I don't know if the caching issue is related to the MMU issue - or they are two totally separate things.
Any ideas????
Brad Goodman
Empirix, Inc.
bgoodman -et- empirix -dut- com
^ permalink raw reply
* Re: Musbhsfc USB gadget appears in latest 440EP/Bamboo patch
From: Wade Farnsworth @ 2005-07-28 20:43 UTC (permalink / raw)
To: John Otken; +Cc: linuxppc-embedded
In-Reply-To: <42E94288.7070509@softadvances.com>
On Thu, 2005-07-28 at 13:39, John Otken wrote:
> Hi Wade,
>
> In your most recent patch for the Bamboo board, you added an entry for the 440EP's "musbhsfc" USB device/gadget. I do not see a driver in the 2.6 tree for this device. Did I overlook something or perhaps you are working on it? Thanks in advances for any information.
>
> John Otken
Hi John,
I'm currently working on a driver for the on-board USB device.
-Wade
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox