new code for an mpc8xx board (dbox2)

new code for an mpc8xx board (dbox2)

[Andreas Oberritter]

Hi,

I'd like to get support for the dbox2, which is a DVB receiver with an
mpc823 cpu, into the linux kernel, to make it bootable without
further patching. Since I am new to submitting kernel patches, I don't
know who to ask best for inclusion. Benjamin Herrenschmidt pointed me to
this mailing list.

On which kernel tree shall patches be based to get into vanilla 2.4?

The current patchset against linux-2.4.22-pre6 can be viewed via webcvs
at http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/Patches/

I will create a new set as soon as I know which tree to use best.

I'd also like to know if there is a better way to handle edge triggered
interrupts on 8xx than it is done in
linux-2.4.22-pre6-dbox2-irq.diff. Should CONFIG_DBOX2 be removed in this
patch or maybe replaced by CONFIG_8xx?

I think linux-2.4.22-pre6-dbox2-board.diff is a trivial patch and will
not offend any other boards.

linux-2.4.22-pre6-dbox2-watchdog.diff is needed because the
bootloader of this board enables the watchdog. Since it is a generic
implementation for handling an 8xx watchdog, I'd add CONFIG_8xx_WATCHDOG
for it instead of CONFIG_DBOX2, if no one complains.

Regards,
Andreas


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

Re: new code for an mpc8xx board (dbox2)

[Tom Rini]

On Sun, Aug 03, 2003 at 04:42:09AM +0200, Andreas Oberritter wrote:

> Hi,
>
> I'd like to get support for the dbox2, which is a DVB receiver with an
> mpc823 cpu, into the linux kernel, to make it bootable without
> further patching. Since I am new to submitting kernel patches, I don't
> know who to ask best for inclusion. Benjamin Herrenschmidt pointed me to
> this mailing list.
>
> On which kernel tree shall patches be based to get into vanilla 2.4?
>
> The current patchset against linux-2.4.22-pre6 can be viewed via webcvs
> at http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/cdk/Patches/
>
> I will create a new set as soon as I know which tree to use best.

Patches against current 2.4 are the best way for 8xx changes.  However,
it's probably too late to get it into 2.4.22, but I can put these
changes into a tree for 2.4.23-pre1.

> I'd also like to know if there is a better way to handle edge triggered
> interrupts on 8xx than it is done in
> linux-2.4.22-pre6-dbox2-irq.diff. Should CONFIG_DBOX2 be removed in this
> patch or maybe replaced by CONFIG_8xx?

Which interrupt is being generated that requires this change?

> I think linux-2.4.22-pre6-dbox2-board.diff is a trivial patch and will
> not offend any other boards.

If you use PPCBoot / U-Boot, you do not need to fill out an embed_config
routine, and it's OK to let zImage fail.  Aside from that, the patch is
fine, and I can add it to a tree to get Marcelo to pull from for
2.4.23-pre1 if you like.

> linux-2.4.22-pre6-dbox2-watchdog.diff is needed because the
> bootloader of this board enables the watchdog. Since it is a generic
> implementation for handling an 8xx watchdog, I'd add CONFIG_8xx_WATCHDOG
> for it instead of CONFIG_DBOX2, if no one complains.

Since you have to define PITRTCLK, and there's magic numbers (and I
don't have time at the moment to dig into the watchdog docs, cursed
classes..) are you sure this is all generic 8xx code, and that those
numbers wouldn't be board-specific?

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

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

RE: new code for an mpc8xx board (dbox2)

[Florian Schirmer]

Hi,

>> I'd also like to know if there is a better way to handle edge
>> triggered interrupts on 8xx than it is done in
>> linux-2.4.22-pre6-dbox2-irq.diff. Should CONFIG_DBOX2 be removed in
>> this patch or maybe replaced by CONFIG_8xx?
>
>Which interrupt is being generated that requires this change?

IIRC it is an ugly hack for a broken hardware. The initial problem was that
there is some hardware we don't have any documentation for. It generates
interrupts, but we dont know how to properly acknowledge them. This is why
we "invented" the SA_ONESHOT hack. If there is any other way to work around
this please let us know...

>If you use PPCBoot / U-Boot, you do not need to fill out an
>embed_config routine, and it's OK to let zImage fail.

This will break scripts expecting "make zImage" to return successfully.

>> linux-2.4.22-pre6-dbox2-watchdog.diff is needed because the
>> bootloader of this board enables the watchdog. Since it is a generic
>> implementation for handling an 8xx watchdog, I'd add CONFIG_8xx_WATCHDOG
>> for it instead of CONFIG_DBOX2, if no one complains.
>
>Since you have to define PITRTCLK, and there's magic numbers (and I don't
>have time at the moment to dig into the watchdog docs, cursed
>classes..) are you sure this is all generic 8xx code, and that
>those numbers wouldn't be board-specific?

It assumes there is a 32.768kHz crystal present on the board. Fix is simple:

if (RTCSC.38K)
  pitrtclk = 9600;
else
  pitrtclk = 8192;

I would like to see the userspace interface merged too
(http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/driver/wdt/mpc8xx_wdt.c).
I propose to drop the kernel watchdog patch and merge in the following
functions of the userspace interface instead:

mpc8xx_wdt_reset (needs to be exported to modules)
mpc8xx_wdt_interrupt
mpc8xx_wdt_handler_install (has to called during kernel init)

mpc8xx_wdt_handler_remove is dead and can be removed.

Regards,
   Florian


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

Re: new code for an mpc8xx board (dbox2)

[Tom Rini]

On Mon, Aug 04, 2003 at 11:36:34PM +0200, Florian Schirmer wrote:
> Hi,
>
> >> I'd also like to know if there is a better way to handle edge
> >> triggered interrupts on 8xx than it is done in
> >> linux-2.4.22-pre6-dbox2-irq.diff. Should CONFIG_DBOX2 be removed in
> >> this patch or maybe replaced by CONFIG_8xx?
> >
> >Which interrupt is being generated that requires this change?
>
> IIRC it is an ugly hack for a broken hardware. The initial problem was that
> there is some hardware we don't have any documentation for. It generates
> interrupts, but we dont know how to properly acknowledge them. This is why
> we "invented" the SA_ONESHOT hack. If there is any other way to work around
> this please let us know...

Well, in that case I'd be inclined to leave it as CONFIG_DBOX2 only,
with a comment describing what hardware this is for.

> >If you use PPCBoot / U-Boot, you do not need to fill out an
> >embed_config routine, and it's OK to let zImage fail.
>
> This will break scripts expecting "make zImage" to return successfully.

Yes, it does.  It's also how all of the other PPCBoot / U-Boot only
platforms work.  Now that I think about this again, would you mind
looking at the source and seeing if the following in embed_config.c
would break anything?
void __attribute__((weak))
embed_config(void)
{
}

(Or so, look at arch/ppc/boot/common/serial_stub.c for the proper usage
of 'weak').

[snip]
> I would like to see the userspace interface merged too
> (http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/driver/wdt/mpc8xx_wdt.c).
> I propose to drop the kernel watchdog patch and merge in the following
> functions of the userspace interface instead:
>
> mpc8xx_wdt_reset (needs to be exported to modules)
> mpc8xx_wdt_interrupt
> mpc8xx_wdt_handler_install (has to called during kernel init)
>
> mpc8xx_wdt_handler_remove is dead and can be removed.

I need a bit of time to think about this (and a 'new' patch would be
nice as well).  I'll get back to you.

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

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

Re: new code for an mpc8xx board (dbox2)

[Tom Rini]

On Mon, Aug 04, 2003 at 04:12:48PM -0700, Tom Rini wrote:

> On Mon, Aug 04, 2003 at 11:36:34PM +0200, Florian Schirmer wrote:
[snip]
> [snip]
> > I would like to see the userspace interface merged too
> > (http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/driver/wdt/mpc8xx_wdt.c).
> > I propose to drop the kernel watchdog patch and merge in the following
> > functions of the userspace interface instead:
> >
> > mpc8xx_wdt_reset (needs to be exported to modules)
> > mpc8xx_wdt_interrupt
> > mpc8xx_wdt_handler_install (has to called during kernel init)
> >
> > mpc8xx_wdt_handler_remove is dead and can be removed.
>
> I need a bit of time to think about this (and a 'new' patch would be
> nice as well).  I'll get back to you.

Okay.  After reading the driver above, I would be fine with you submitting
this to Marcelo once 2.4.23-pre1 opens, and submitting it to 2.6 as well
(yes, you won't be able to test it, but you can at least see if you
ported the driver 'up' right).

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

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