rearrangements in linuxppc_2_4_devel

rearrangements in linuxppc_2_4_devel

[Paul Mackerras]

I just checked in a change into linuxppc_2_4_devel that changes the
way we deal with the large and increasing variety of platforms that
PPC/Linux supports.  The aim with these changes is to reduce the
number of places where we have to change stuff to add support for a
new platform.

When I say "platform" I'm talking about a class of machines that can
all run a single vmlinux binary.  So the CONFIG_ALL_PPC machines count
as a single platform, and each of the choices under the various
'Machine type' questions also count as a platform.

The first change is to make each platform export a procedure called
platform_init.  This is called from machine_init (which used to be
called identify_machine) early on.  So for example I renamed
m8xx_setup to platform_setup.  That removed a whole pile of #ifdefs in
setup.c.

The second change is to make MMU_init call a platform-specific
function to set up any I/O mappings that the platform needs, namely
ppc_md.setup_io_mappings().  This will typically call
io_block_mapping(), which is like setbat except that it will add ptes
instead of setting a BAT if there is no BAT available.  I have moved
the code from MMU_init into the various xxx_setup.c files and made it
call io_block_mapping instead of setbat or ioremap.

That means that ioremap now doesn't need to do virtual = physical
mappings any more AFAICS.  If there are other places where you call
ioremap and you need virtual == physical, please either change the
code so it doesn't assume that or else use io_block_mapping.

The next thing I would like to do, which I haven't done yet, is to
avoid the need to have a separate _MACH_xxx define for each platform.
I would see _machine as distinguishing between different types of
machine that count as a single platform, rather than distinguishing
between platforms.  (We distinguish between platforms by their config
options.)  Thus I don't see any need for anything more than
_MACH_prep, _MACH_Pmac and _MACH_chrp.

With those changes, I think that adding a new platform should only
require adding stuff to arch/ppc/config.in, arch/ppc/kernel/Makefile,
and adding a new xxx_setup.c file.

Comments?

Paul.

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

Re: rearrangements in linuxppc_2_4_devel

[Adrian Cox]

Paul Mackerras wrote:
[...]

> The next thing I would like to do, which I haven't done yet, is to
> avoid the need to have a separate _MACH_xxx define for each platform.
> I would see _machine as distinguishing between different types of
> machine that count as a single platform, rather than distinguishing
> between platforms.  (We distinguish between platforms by their config
> options.)  Thus I don't see any need for anything more than
> _MACH_prep, _MACH_Pmac and _MACH_chrp.


I've not bothered to create new _MACH_xxx defines for my boards. The
only boards in the tree that will require any code changes to eliminate
are Gemini and APUS.


> With those changes, I think that adding a new platform should only
> require adding stuff to arch/ppc/config.in, arch/ppc/kernel/Makefile,
> and adding a new xxx_setup.c file.
>
> Comments?


I just ported one of my boards to this - the code is now a lot more
readable.

APUS is probably broken, because it believes that it can call
parse_bootinfo with a pointer to the boot records. From apus_setup.c:

void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
		   unsigned long r6, unsigned long r7)
{
	extern int parse_bootinfo(const struct bi_record *);
	extern char _end[];

	/* Parse bootinfo. The bootinfo is located right after
            the kernel bss */
	parse_bootinfo((const struct bi_record *)&_end);

Why do people keep sticking function declarations into each C file,
rather than in headers where they belong? I keep finding consistency
problems like this.

Paul: would you take patches that moved some of this stuff into header
files, and if so, which header file would you like all the miscellaneous
setup functions to move into?


--
Adrian Cox   http://www.humboldt.co.uk/


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

Re: rearrangements in linuxppc_2_4_devel

[Paul Mackerras]

Adrian Cox writes:

> APUS is probably broken, because it believes that it can call
> parse_bootinfo with a pointer to the boot records. From apus_setup.c:

APUS uses the m68k bootinfo format anyway, which ours is gratuitously
different from.  The apus booter probably does pass the address in a
register, which would actually be the sensible thing to do. :)

> Paul: would you take patches that moved some of this stuff into header
> files, and if so, which header file would you like all the miscellaneous
> setup functions to move into?

Ummm, it would depend which functions you're talking about.  There is
certainly an argument for having a couple more .h files in
arch/ppc/kernel to declare functions that are used only in
arch/ppc/kernel/*.c.

Paul.

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

Re: rearrangements in linuxppc_2_4_devel

[Adrian Cox]

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

Paul Mackerras wrote:

> Adrian Cox writes:
>>APUS is probably broken, because it believes that it can call
>>parse_bootinfo with a pointer to the boot records. From apus_setup.c:
> APUS uses the m68k bootinfo format anyway, which ours is gratuitously
> different from.  The apus booter probably does pass the address in a
> register, which would actually be the sensible thing to do. :)


Looking at the makefile, APUS links with setup.c. So it's going to link
with our standard parse_bootinfo, which doesn't take any arguments. I
suspect APUS needs a bit more work to integrate it into the 2_4_devel tree.


>>Paul: would you take patches that moved some of this stuff into header
>>files, and if so, which header file would you like all the miscellaneous
>>setup functions to move into?


> Ummm, it would depend which functions you're talking about.  There is
> certainly an argument for having a couple more .h files in
> arch/ppc/kernel to declare functions that are used only in
> arch/ppc/kernel/*.c.


That's what I'm thinking of - I just want to cut down the number of
extern declarations in the C files in arch/ppc/kernel.

Candidate functions include things like xmon functions, and various
platform specific functions on the platforms I'm interested in. In some
cases we have declarations in header files, so I may remove the
duplication. I've been doing this since I started working on machine
check, as I found clashing uses of bad_page_fault(), fixed by the
attached patch.

--
Adrian Cox   http://www.humboldt.co.uk/

[-- Attachment #2: badpage.patch --]
[-- Type: text/plain, Size: 596 bytes --]

===== arch/ppc/kernel/traps.c 1.14 vs edited =====
--- 1.14/arch/ppc/kernel/traps.c	Fri Jun 15 05:11:42 2001
+++ edited/arch/ppc/kernel/traps.c	Wed Jun 27 14:46:32 2001
@@ -40,7 +40,6 @@
 #include <asm/processor.h>

 extern int fix_alignment(struct pt_regs *);
-extern void bad_page_fault(struct pt_regs *, unsigned long);

 #ifdef CONFIG_XMON
 extern void xmon(struct pt_regs *regs);
@@ -317,7 +316,7 @@
 		if (user_mode(regs))
 			force_sig(SIGSEGV, current);
 		else
-			bad_page_fault(regs, regs->dar);
+			bad_page_fault(regs, regs->dar, SIGSEGV);
 		return;
 	}
 	_exception(SIGBUS, regs);

Re: rearrangements in linuxppc_2_4_devel

[Roman Zippel]

Hi,

Adrian Cox wrote:

> Looking at the makefile, APUS links with setup.c. So it's going to link
> with our standard parse_bootinfo, which doesn't take any arguments. I
> suspect APUS needs a bit more work to integrate it into the 2_4_devel tree.

Yes, APUS currently calls its own parse_bootinfo() (amiga/bootinfo.c) in
apus_init().

bye, Roman

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