[PATCH] Hymod board support and related changes ...

[PATCH] Hymod board support and related changes ...

[Murray Jensen]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

Hymod board support and related changes ...

- Hymod board support
- 8260 fcc_enet: more flexible (or at least readable) approach to
  configuring i/o pins
- 8260 fcc_enet: support different PHY interrupt "vector"s for each FCC
- 8260 setup: fixed ppcboot jump address; should be 0x...110 not 0x...104
- 8260 setup: turn off interrupts before jumping to the boot rom

Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@csiro.au

Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/


[-- Attachment #2: hymod.patch.gz --]
[-- Type: application/x-gzip , Size: 11185 bytes --]

Re: [PATCH] Hymod board support and related changes ...

[Tom Rini]

On Tue, May 28, 2002 at 03:48:35PM +1000, Murray Jensen wrote:
> Hymod board support and related changes ...
>
> - Hymod board support
> - 8260 fcc_enet: more flexible (or at least readable) approach to
>   configuring i/o pins
> - 8260 fcc_enet: support different PHY interrupt "vector"s for each FCC
> - 8260 setup: fixed ppcboot jump address; should be 0x...110 not 0x...104
> - 8260 setup: turn off interrupts before jumping to the boot rom

Can you split this up into logical patches?  Also, instead of testing
TQM8260 || HYMOD for PPCBoot, why don't we just add in something like:
if [ "$CONFIG_TQM8260" = "y" -o  "$CONFIG_HYMOD" = "y" \
	-o "$CONFIG_TQM8xx" = "y" ] ;then
   define_bool CONFIG_PPCBOOT y
fi

And use that.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH] Hymod board support and related changes ...

[Murray Jensen]

On Tue, 28 May 2002 12:26:52 -0700, Tom Rini <trini@kernel.crashing.org> writes:
>On Tue, May 28, 2002 at 03:48:35PM +1000, Murray Jensen wrote:
>> Hymod board support and related changes ...
>>
>> - Hymod board support
>> - 8260 fcc_enet: more flexible (or at least readable) approach to
>>   configuring i/o pins
>> - 8260 fcc_enet: support different PHY interrupt "vector"s for each FCC
>> - 8260 setup: fixed ppcboot jump address; should be 0x...110 not 0x...104
>> - 8260 setup: turn off interrupts before jumping to the boot rom
>
>Can you split this up into logical patches?

OK

>Also, instead of testing
>TQM8260 || HYMOD for PPCBoot, why don't we just add in something like:
>if [ "$CONFIG_TQM8260" = "y" -o  "$CONFIG_HYMOD" = "y" \
>	-o "$CONFIG_TQM8xx" = "y" ] ;then
>   define_bool CONFIG_PPCBOOT y
>fi
>
>And use that.

Agreed. I will re-submit this patch. I will spend a bit of time on it, to see
if there are any other "generic" ppcboot configurations that could be rolled
into this. Cheers!
								Murray...


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH] Hymod board support and related changes ...

[Tom Rini]

On Tue, May 28, 2002 at 03:48:35PM +1000, Murray Jensen wrote:

> - Hymod board support

For the m8260_gorom() call, try using spin_lock_irqsave() instead of
save_flags();cli() ... restore_flags();

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH] Hymod board support and related changes ...

[Tom Rini]

On Tue, May 28, 2002 at 01:18:10PM -0700, Tom Rini wrote:
>
> On Tue, May 28, 2002 at 03:48:35PM +1000, Murray Jensen wrote:
>
> > - Hymod board support
>
> For the m8260_gorom() call, try using spin_lock_irqsave() instead of
> save_flags();cli() ... restore_flags();

Nevermind, spoke too soon here.  But did you really need to add in what
you did or is it just a cleanup?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH] Hymod board support and related changes ...

[Murray Jensen]

On Tue, 28 May 2002 13:19:57 -0700, Tom Rini <trini@kernel.crashing.org> writes:
>On Tue, May 28, 2002 at 01:18:10PM -0700, Tom Rini wrote:
>>
>> On Tue, May 28, 2002 at 03:48:35PM +1000, Murray Jensen wrote:
>>
>> > - Hymod board support
>>
>> For the m8260_gorom() call, try using spin_lock_irqsave() instead of
>> save_flags();cli() ... restore_flags();
>
>Nevermind, spoke too soon here.  But did you really need to add in what
>you did or is it just a cleanup?

I needed to add it. When I executed a "halt" on my Hymod board, at the point
where it jumped to the ROM (in my case, this is ppcboot) things went crazy -
it caught an exception and tried to print a message on the console, but it was
really wierd, with only a few of the characters legible, others being
substituted with wierd umlauts or punctuation etc. I couln't see any pattern,
but when I turned off interrupts before executing the "gorom" function it
stopped. Note that this only started happening recently, so something changed
somewhere else which caused this problem.

The idea behind this fix is "correct" anyway. We do not want to take any
exceptions once we have jumped to the boot ROM code. With the code the way it is,
it is possible for interrupts to be enabled at the time the "gorom" function is
executed.

Maybe the proper fix is for "gorom" to ensure interrupts are disabled? Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@csiro.au

Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH] Hymod board support and related changes ...

[Tom Rini]

On Wed, May 29, 2002 at 12:07:16PM +1000, Murray Jensen wrote:
>
> On Tue, 28 May 2002 13:19:57 -0700, Tom Rini <trini@kernel.crashing.org> writes:
> >On Tue, May 28, 2002 at 01:18:10PM -0700, Tom Rini wrote:
> >>
> >> On Tue, May 28, 2002 at 03:48:35PM +1000, Murray Jensen wrote:
> >>
> >> > - Hymod board support
> >>
> >> For the m8260_gorom() call, try using spin_lock_irqsave() instead of
> >> save_flags();cli() ... restore_flags();
> >
> >Nevermind, spoke too soon here.  But did you really need to add in what
> >you did or is it just a cleanup?
>
> I needed to add it. When I executed a "halt" on my Hymod board, at the point
> where it jumped to the ROM (in my case, this is ppcboot) things went crazy -
> it caught an exception and tried to print a message on the console, but it was
> really wierd, with only a few of the characters legible, others being
> substituted with wierd umlauts or punctuation etc. I couln't see any pattern,
> but when I turned off interrupts before executing the "gorom" function it
> stopped. Note that this only started happening recently, so something changed
> somewhere else which caused this problem.

Well, this is also at powerdown, yes?  Or can we actually power off the
board with the gorom call, rather than just exit Linux?  If so,
nevermind..

> Maybe the proper fix is for "gorom" to ensure interrupts are disabled? Cheers!

Nah.  It's an 8260-specific function, so I don't think it matters, so
why not just do it from the caller..  With a comment above that reminds
people grep'ing around that we're about to powerdown so it's OK to do
the save_flags();cli(); ... restore_flags();

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

[PATCH] misc compiler warn/err fixes, typo fixes and aesthetic changes

[Murray Jensen]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

misc compiler warn/err fixes, typo fixes and aesthetic changes

Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@csiro.au

Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/


[-- Attachment #2: misc.patch.gz --]
[-- Type: application/x-gzip , Size: 1825 bytes --]

Re: [PATCH] misc compiler warn/err fixes, typo fixes and aesthetic changes

[Tom Rini]

On Tue, May 28, 2002 at 03:45:58PM +1000, Murray Jensen wrote:

> misc compiler warn/err fixes, typo fixes and aesthetic changes

1) Why did you need to add in all of the 'volatile' keyword?  What
compiler are you using which is unhappy with this?  Part of why I ask is
I _think_ this was a problem with gcc-2.96/2.97 but not any actual
'release'.
2) Changes outside of arch/ppc and include/asm-ppc need to go onto
Marcelo (who will either take them or tell you to send them to the
appropriate maintainer).

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH] misc compiler warn/err fixes, typo fixes and aesthetic changes

[Murray Jensen]

On Tue, 28 May 2002 11:35:09 -0700, Tom Rini <trini@kernel.crashing.org> writes:
>> misc compiler warn/err fixes, typo fixes and aesthetic changes
>
>1) Why did you need to add in all of the 'volatile' keyword?  What
>compiler are you using which is unhappy with this?  Part of why I ask is
>I _think_ this was a problem with gcc-2.96/2.97 but not any actual
>'release'.

The volatiles for "cpmp" and "immr" fall into the "aesthetic changes" category.
These pointers are volatile and should be declared as such, so there is never
any confusion.

The volatiles in "include/asm-ppc/uaccess.h" worked around a compiler bug. I
looked at it, and the pattern was that it had a lot of problems with inline
functions calling inline functions - it messed up its register allocation and
aborted.

My compiler version is "gcc version 3.1 20011203 (experimental)". The problem
may have been fixed by now (I pulled this gcc from CVS in December). Other than
these two inlines, this compiler compiles the kernel fine (and it runs on our
MPC8260 based Hymod board).

>2) Changes outside of arch/ppc and include/asm-ppc need to go onto
>Marcelo (who will either take them or tell you to send them to the
>appropriate maintainer).

I didn't mean to include those two - anyone who tried to compile those modules
would get the same errors - they are simply typos (missing include, missing
commas). I expect they will be fixed in due course and will come through in the
normal merges. Do you think I should submit them anyway? Cheers!
								Murray...


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [PATCH] misc compiler warn/err fixes, typo fixes and aesthetic changes

[Tom Rini]

On Wed, May 29, 2002 at 11:42:15AM +1000, Murray Jensen wrote:
>
> On Tue, 28 May 2002 11:35:09 -0700, Tom Rini <trini@kernel.crashing.org> writes:
> >> misc compiler warn/err fixes, typo fixes and aesthetic changes
> >
> >1) Why did you need to add in all of the 'volatile' keyword?  What
> >compiler are you using which is unhappy with this?  Part of why I ask is
> >I _think_ this was a problem with gcc-2.96/2.97 but not any actual
> >'release'.
>
> The volatiles for "cpmp" and "immr" fall into the "aesthetic changes" category.
> These pointers are volatile and should be declared as such, so there is never
> any confusion.

Okay.

> The volatiles in "include/asm-ppc/uaccess.h" worked around a compiler bug. I
> looked at it, and the pattern was that it had a lot of problems with inline
> functions calling inline functions - it messed up its register allocation and
> aborted.

Well, talk to the gcc people. :)  Or maybe some of these inlines should
be #defines or actual functions..  I think I heard Dan Malek question
why we have so many inlines recently anyhow..

> My compiler version is "gcc version 3.1 20011203 (experimental)". The problem
> may have been fixed by now (I pulled this gcc from CVS in December). Other than
> these two inlines, this compiler compiles the kernel fine (and it runs on our
> MPC8260 based Hymod board).

Well, gcc-3.1.1 should be out soonish, so please try a newer compiler.

> >2) Changes outside of arch/ppc and include/asm-ppc need to go onto
> >Marcelo (who will either take them or tell you to send them to the
> >appropriate maintainer).
>
> I didn't mean to include those two - anyone who tried to compile those modules
> would get the same errors - they are simply typos (missing include, missing
> commas). I expect they will be fixed in due course and will come through in the
> normal merges. Do you think I should submit them anyway? Cheers!

You certainly should send them.  They don't get fixed until someone
does. :)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/