rearrangements in linuxppc_2_4_devel

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/

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/

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/

Paul Mackerras wrote:

Adrian Cox writes:

quoted

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.

quoted

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/

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/