Patch Preview for MVME2100

Patch Preview for MVME2100

[Oliver Korpilla]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 805 bytes --]

Hello!

I tried to port the available patch for MVME2100 from linux-2.4.2 HHL2.0
to vanilla 2.4.25, and I'd like someone to have a look at it, to say if it
makes sense, because this is a first-timer.

It is not yet verified, because I cannot compile or test it before
tomorrow, but if someone could comment on it still yet, it'd be very much
appreciated.

You can download both the original patches and my tries at new patchs
here:

http://www.fh-landshut.de/~okorpil/mvme2100-linux-2.4.25.patch.bz2
http://www.fh-landshut.de/~okorpil/mvme2100-linux-2.4.25.patch.gz
http://www.fh-landshut.de/~okorpil/mvme2100-linux-2.4.2_hhl20.patch.bz2
http://www.fh-landshut.de/~okorpil/mvme2100-linux-2.4.2_hhl20.patch.gz

The changes I made in detail are attached to this message.

Thanks in advance,
Oliver Korpilla

[-- Attachment #2: Type: TEXT/PLAIN, Size: 3163 bytes --]

I'll try to document what I did for every code snippet in the original patch
so someone else can try to verify that my changes seem to make sense (or not!).

Each of the items below is one of the diff changes to a file in the original
patch and what I did with it.

1)
arch/ppc/Makefile:

originally -> include mvme2100_defconfig target
now -> no longer needed (generic Makefile template in place)

2)
arch/ppc/boot/Makefile:

added entry for tools mkprep, mkbugboot

3)
arch/ppc/boot/include/mvme2100_serial.h

dropped it - why have that info twice?

4)
arch/ppc/boot/include/ns16550.h

put it into include/asm-ppc/serial.h

5) 
arch/ppc/boot/mvme2100/Makefile

dropped it -  I hope I have found the right places for putting that
information instead. I stuck to the places where the CONFIG_LOPEC and
CONFIG_SANDPOINT added modifications to the Makefiles.

6)
arch/ppc/boot/mvme2100/head.S

included it, put a reference to it where head objects are mapped in Makefiles

7)
arch/ppc/boot/mvme2100/head.S.anj

included it, but will not be built by now, head.S from 6) instead

8)
arch/ppc/config.in

included it, and added a configuration dependency for the MPC10x store gathering
where SANDPOINT has one.

9)
arch/ppc/configs/mvme2100_defconfig

included without modification
(may need a make oldconfig first, I guess and removal of targets not in
the mainstream 2.4.x kernels)

10)
arch/ppc/kernel/Makefile

added objects, put platform object mvme2100.o in platforms Makefile

11)
arch/ppc/kernel/mvme2100.h

put it into platforms instead

12)
arch/ppc/kernel/mvme2100_pci.c

put it into platforms as mvme2100.c

13)
arch/ppc/kernel/mvme2100_setup.c

put it into platforms as mvme2100.c

unified 12 and 13 into one file, adapted 
the set_bat calls into calls to io_block_mapping,
commented debug stuff out

14)
arch/ppc/kernel/open_pic.c

tried to match functionality by conditionalizing the code for the interrupt cascade
by disabling it when CONFIG_MVME2100 is present

15)
arch/ppc/kernel/setup.c

instead of referencing a mvme2100_init and conditionally calling it on the right macro
I renamed the init function to platform_init (I guess this is now the way to do things,
with Makefile magic instead of macro clutter, or am I wrong?)

16)
arch/ppc/mm/init.c

There are no longer conditional calls for set_bat in here -> see 13) io_block_mapping

I'm not sure whether the change of the ioremap_base is necessary, since now all platforms with
no HIGH_MEM seem to share the same value, so I dropped that value. What consequences does
this have?

17)
include/asm-ppc/mvme2100_serial.h

only that one in platforms is left

18)
include/asm-ppc/processor.h

Comments in this file suggested this is no longer necessary, so I left it out.

19)
include/asm-ppc/serial.h

already points to platforms


Most changes in my patch that don't directly match with these mentioned are changes distributed
across a set of Makefiles - I guess that's because now a greater deal of Makefile stuff is
handled more uniformly and I tried to stick with that logic.

Re: Patch Preview for MVME2100

[Tom Rini]

On Sun, Apr 04, 2004 at 01:27:58PM +0200, Oliver Korpilla wrote:

> Hello!
>
> I tried to port the available patch for MVME2100 from linux-2.4.2 HHL2.0
> to vanilla 2.4.25, and I'd like someone to have a look at it, to say if it
> makes sense, because this is a first-timer.
>
> It is not yet verified, because I cannot compile or test it before
> tomorrow, but if someone could comment on it still yet, it'd be very much
> appreciated.
>
> You can download both the original patches and my tries at new patchs
> here:
>
> http://www.fh-landshut.de/~okorpil/mvme2100-linux-2.4.25.patch.bz2
> http://www.fh-landshut.de/~okorpil/mvme2100-linux-2.4.25.patch.gz
> http://www.fh-landshut.de/~okorpil/mvme2100-linux-2.4.2_hhl20.patch.bz2
> http://www.fh-landshut.de/~okorpil/mvme2100-linux-2.4.2_hhl20.patch.gz
>
> The changes I made in detail are attached to this message.

- The stuff in arch/ppc/boot/mvme2100 can go.
- The open_pic.c change shouldn't be needed either.
- Your openpic_initsenses table looks wrong, and is probably the cause
  of the uart slowness you found.  What you do is only list the IRQs for
  which you have something, and use openpic_set_sources calls to skip
  over the gaps.  Look at lopec_init_IRQ and ask if you still have
  problems.  I hoped to have documented that one well the first time
  around. :)
- In mvme2100_set_bat, try something along the lines of:
{
	mb();
	mtspr(DBAT1U, 0xf8000ffe);
	mtspr(DBAT1L, 0xf800002a);
	mb();
}

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

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

Re: Patch Preview for MVME2100

[Oliver Korpilla]

- The stuff in arch/ppc/boot/mvme2100 can go.

Figured that out today, too. It won't compile anyway. Thanks.

>- The open_pic.c change shouldn't be needed either.
>
>
Maybe the CONFIG_EPIC_SERIAL_MODE should be set, shouldn't it? Will add
it tomorrow. Should I add that cascade hookup stuff even if there is no
cascaded 8259?

>- Your openpic_initsenses table looks wrong, and is probably the cause
>  of the uart slowness you found.  What you do is only list the IRQs for
>  which you have something, and use openpic_set_sources calls to skip
>  over the gaps.  Look at lopec_init_IRQ and ask if you still have
>  problems.  I hoped to have documented that one well the first time
>  around. :)
>
>
There is one problem - in the LoPEC manual all interrupts are documented
- even if marked unused (I refer to polarity and level/edge). In the
MVME2100 information about that interrupts is N/A. So should I leave
those to 0 still in the initsenses struct?

Thanks for the help,
Oliver Korpilla

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

Re: Patch Preview for MVME2100

[Tom Rini]

On Mon, Apr 05, 2004 at 08:06:28PM +0200, Oliver Korpilla wrote:

> - The stuff in arch/ppc/boot/mvme2100 can go.
>
> Figured that out today, too. It won't compile anyway. Thanks.
>
> >- The open_pic.c change shouldn't be needed either.
>
> Maybe the CONFIG_EPIC_SERIAL_MODE should be set, shouldn't it? Will add
> it tomorrow. Should I add that cascade hookup stuff even if there is no
> cascaded 8259?

You don't need to call openpic_hookup_cascade, if there is no cascade.
You only want to set EPIC_SERIAL_MODE if the controller really is in
serial mode.

> >- Your openpic_initsenses table looks wrong, and is probably the cause
> > of the uart slowness you found.  What you do is only list the IRQs for
> > which you have something, and use openpic_set_sources calls to skip
> > over the gaps.  Look at lopec_init_IRQ and ask if you still have
> > problems.  I hoped to have documented that one well the first time
> > around. :)
> >
> >
> There is one problem - in the LoPEC manual all interrupts are documented
> - even if marked unused (I refer to polarity and level/edge). In the
> MVME2100 information about that interrupts is N/A. So should I leave
> those to 0 still in the initsenses struct?

No.  The '0's are wrong.  You only need to describe, in terms of
level/edge, documented interrupts.  You then make multiple calls to
openpic_set_sources(), to skip over the non-existant interrupts.

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

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

Re: Patch Preview for MVME2100

[Oliver Korpilla]

Tom Rini wrote:

Applied changes today, and the serial console is coming along nicely,
can log into my board, use ethernet, boot off NFS. :)

I'm very happy and very grateful. Thank you!

>>Maybe the CONFIG_EPIC_SERIAL_MODE should be set, shouldn't it? Will add
>>it tomorrow. Should I add that cascade hookup stuff even if there is no
>>cascaded 8259?
>>
>>
>
>You don't need to call openpic_hookup_cascade, if there is no cascade.
>You only want to set EPIC_SERIAL_MODE if the controller really is in
>serial mode.
>
>
>
As far as I can see from the (sometimes very unspecific) documentation
for the MVME2100 and from the probing in the Linux kernel there doesn't
seem to be an external interrupt (= no 8259) on-board. So I guess I
could drop CONFIG_EPIC_SERIAL_MODE, because I don't need to probe for
interrupts on that source, do I? (I'm a bit confused about that, because
I delved a bit in the MPC107, the LoPEC board, the MPC8240 and the
MVME2100 manuals without very clear info about that)

Can I drop

       /* Map serial interrupts 0-15 */
       openpic_set_sources(0, 16, OpenPIC_Addr + 0x10200);

too? No connected 8259 should mean no interrupt sources there, I guess.

>No.  The '0's are wrong.  You only need to describe, in terms of
>level/edge, documented interrupts.  You then make multiple calls to
>openpic_set_sources(), to skip over the non-existant interrupts.
>
>
>
For initial testing I have still 0s in there - for the unused interrupts
within the range after the external interrupts. I get a bad interrupt at
1 - this would be the first interrupt in the cascade I guess, but
interrupts of the ethernet and the UART serial (17  - 2nd internal
interrupt and 29 - 13th internal interrupt) work just fine - console is
responsive, ethernet is stable and fine.

A very big "Thank" You! indeed. Your advice was indispensable for my
work and it was to the point, too.

I will try to clean up that patch, with an eye to the Sandpoint and
LoPEC platforms for guidelines, and I hope I can find the time to port
it to 2.6.x, too. Unfortunately this is a very tightly scheduled project
with very ambitious goals (evaluating VME bus with realtime Linux at
minimum on the MVME2100, and possibly on the MVME5500 and VMIVME7050 as
well), so this could be some time in the future. But cleaning up my
current patch is certainly necessary and is already my task for the next
time, so that I'll do for sure.

With kind regards,
Oliver Korpilla


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

Re: Patch Preview for MVME2100

[Tom Rini]

On Tue, Apr 06, 2004 at 07:29:40PM +0200, Oliver Korpilla wrote:

>
> Tom Rini wrote:
>
> Applied changes today, and the serial console is coming along nicely,
> can log into my board, use ethernet, boot off NFS. :)
>
> I'm very happy and very grateful. Thank you!
>
> >>Maybe the CONFIG_EPIC_SERIAL_MODE should be set, shouldn't it? Will add
> >>it tomorrow. Should I add that cascade hookup stuff even if there is no
> >>cascaded 8259?
> >>
> >>
> >
> >You don't need to call openpic_hookup_cascade, if there is no cascade.
> >You only want to set EPIC_SERIAL_MODE if the controller really is in
> >serial mode.
>
> As far as I can see from the (sometimes very unspecific) documentation
> for the MVME2100 and from the probing in the Linux kernel there doesn't
> seem to be an external interrupt (= no 8259) on-board. So I guess I
> could drop CONFIG_EPIC_SERIAL_MODE, because I don't need to probe for
> interrupts on that source, do I? (I'm a bit confused about that, because
> I delved a bit in the MPC107, the LoPEC board, the MPC8240 and the
> MVME2100 manuals without very clear info about that)

This is all from memory, but..
EPIC_SERIAL_MODE means that the OpenPIC is put into serial mode.  This
means that the OpenPIC is wired for a number of interrupt, as opposed to
4.  Looking at the old patch, this is something you can turn off for the
MVME2100.

> Can I drop
>
>       /* Map serial interrupts 0-15 */
>       openpic_set_sources(0, 16, OpenPIC_Addr + 0x10200);
>
> too? No connected 8259 should mean no interrupt sources there, I guess.

Looking at the old table, yes.

> >No.  The '0's are wrong.  You only need to describe, in terms of
> >level/edge, documented interrupts.  You then make multiple calls to
> >openpic_set_sources(), to skip over the non-existant interrupts.
>
> For initial testing I have still 0s in there - for the unused interrupts
> within the range after the external interrupts. I get a bad interrupt at
> 1 - this would be the first interrupt in the cascade I guess, but
> interrupts of the ethernet and the UART serial (17  - 2nd internal
> interrupt and 29 - 13th internal interrupt) work just fine - console is
> responsive, ethernet is stable and fine.

If you drop the openpic_set_sources() call for 0-15, you need to drop
these from the table as well, FWIW.  Similarly for any other '0's you've
had.

> A very big "Thank" You! indeed. Your advice was indispensable for my
> work and it was to the point, too.

You're welcome.

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

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