new code for an mpc8xx board (dbox2)

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/

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.

Which interrupt is being generated that requires this change?

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.

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/

Hi,

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...

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

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/

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

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 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/

[snip]

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/