On Thu, 28 Oct 1999, Grant Erickson wrote:
Great news! Linux fully boots on the IBM 403GCX evaluation board! It's
time to load up a root file system via NFS and see what happens...
Great! I'll have time next week to work on the IBM thin client I have, if
you're interested. Fair warning: I may need a bit of hand-holding at first, but get my sea legs quickly. Should I compile a kernel with NFS for my PMac hardware?
Cheers,
Jason
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
As more PowerPC processor variants get added and as more board types are
supported by the stock Linux/PPC distribution the current state of affairs
in the asm-ppc directory is going to get a little unruly.
The real ugliness comes with the large number of ifdef's sprinkled all
over the place. As I add in the 4xx stuff, it's going to only get worse.
I'd like to propose a solution, the first is a new file and the second is
a change to processor.h.
Dan has a nice solution to board-specific information with the mpc8xx.h
file and it's associated files (rpxlite.h, mbx.h, etc.). I'd like to go
one further and define a new file "board.h". Any other C file or other
include file which needs board-specific (NOT processor specific)
information includes board.h and ONLY board.h. Based on the configuration
stuff, board.h then pulls in the more specific files. For example:
#ifndef __BOARD_H__
#define __BOARD_H__
#if defined(CONFIG_RPXLITE)
#include <asm/rpxlite.h>
#endif
#if defined(CONFIG_OAK)
#include <asm/oak.h>
#endif
#if defined(CONFIG_WALNUT)
#include <asm/walnut.h>
#endif
#ifdef __cplusplus
extern "C" {
#endif
#ifdef __cplusplus
}
#endif
#endif /* __BOARD_H__ */
Also, processor.h has a smattering of all sorts of information. Some of it
processor related, some of it board related, and almost all of it specific
to the 6xx/7xx processor cores. I'd like to define several new files,
which include information of varying levels of generality:
ppc.h - Included by anyone needed basic PowerPC processor stuff
(this would be included by processor.h).
6xx.h - 6xx core-generic stuff
603.h - 603-specific stuff
604.h - 604-specific stuff
7xx.h - 7xx core-generic stuff (it's really a 603+604, so it might
include 6xx, 603, and 604 as well).
750.h - 740/750-specific stuff
8xx.h - 8xx core-generic stuff
821.h - 821-specific stuff
823.h - "
850.h - "
855.h - "
860.h - "
4xx.h - 4xx core-generic stuff
403.h - 403 core-generic stuff
403gcx.h - 403GCX-specific stuff
405gp.h - 405GP-specific stuff
Maybe the right thing to do is have board.h reference some board-specific
file and then that file in turn pulls in the right processor files for
that particular board. I'm open to suggestions and debate on the subject.
I'm got all of the above processor files implemented in my build tree and
working for 6xx and 8xx builds. In addition, the stuff that's in
processor.h is defined on stuff in the processor-specific files for
compatibility. For example:
/* Special Purpose Registers */
/*
* Most of these are already defined in "ppc.h" and other processor-specific
* header files are contained here for code compatibility. NOTE: Just because
* they are defined here does NOT mean they are guaranteed to exist in all
* PowerPC implementations.
*/
#define CTR SPRN_CTR /* Counter Register */
#define DAR SPRN_DAR /* Data Address Register */
#define DABR SPRN_DABR /* Data Address Breakpoint Register */
#define DBAT0L SPRN_DBAT0L /* Data BAT 0 Lower Register */
#define DBAT0U SPRN_DBAT0U /* Data BAT 0 Upper Register */
#define DBAT1L SPRN_DBAT1L /* Data BAT 1 Lower Register */
#define DBAT1U SPRN_DBAT1U /* Data BAT 1 Upper Register */
Grant M. Erickson University of Minnesota
o mail:grant@lcse.umn.edu 1996 BSEE
o http://www.tc.umn.edu/nlhome/g496/eric0139/ 1998 MSEE
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
I read this, thought about it, slept for a while, read it again.....
Here are some comments :-).
Grant Erickson wrote:
As more PowerPC processor variants get added and as more board types are
supported by the stock Linux/PPC distribution the current state of affairs
in the asm-ppc directory is going to get a little unruly.
It isn't only the include directory, it is the entire structure
of the generic software we all want to utilize, plus the ability
(especially for embedded stuff) to remove any configuration items
we really don't want.
The real ugliness comes with the large number of ifdef's sprinkled all
over the place.
Beauty is in the eye of the beholder :-). I don't really think
it is that bad. There are a few nasty spots, but overall it is
much neater than some commercial projects I have seen in the past.
Dan has a nice solution to board-specific information with the mpc8xx.h
Perhaps this is where we start with your 4xx stuff. Although I
have currently stretched the "mpc8xx.h" to include some of the
new 82xx stuff, you could just add your 4xx into it as well.
Change the name if you like, but make it work first.
....... Any other C file or other
include file which needs board-specific (NOT processor specific)
information includes board.h and ONLY board.h.
Although it is logical and certainly appropriate to separate
this information, from my experience this is getting harder to
do because of the integration of the processors. Processors
either dictate a certain board configuration, or are so flexible
the board configuration describes a processor configuration.
Your "generic" processor definitions become very few.
Also, processor.h has a smattering of all sorts of information. Some of it
processor related, some of it board related, and almost all of it specific
to the 6xx/7xx processor cores.
This is where Linux/PPC started and most of the work continues.
..... I'd like to define several new files,
Here is where I have a _real_ opinion. I don't like lots of
files that basically describe the same thing. The problem lies
in the update of generic software. When I make a kernel modification
that affects everyone, I have to update several different files
in a similar manner and hope I don't break something for someone
else. As I have said in a previous e-mail, my goal is to remove
all of these 8xx board specific files by reprogramming the 8xx
to a generic Linux/PPC address space.
When all of this is in a single place, it forces you to think about
how your unique changes are going to affect everyone else. It
should also make you try to find a more generic solution to your
new addition. In the end, it will make it easier for everyone
to maintain.
I tend to find processor.h rather convenient. There are others
in this list as well, like pgtable.h and mmu.h. When you start
changing things for a new processor or board type, you have
all of the current information described there.
We recently split head.S into head.S and head_8xx.S. I don't
think that was such a good idea......Now, generic changes to
the VM or task subsystem have to be applied in both files. It
actually makes it harder for me because I now have to track
6xx/7xx changes more carefully to make sure 8xx still works.
.... I'm open to suggestions and debate on the subject.
My suggestion is to simply add your 4xx along the path of the
8xx and let's try to sort out some kind of "embedded" solution.
There is a long history of Prep/CHRP/PMac and 6xx/7xx software
that has defined the structure of the Linux/PPC kernel, and I
would rather not change that. I have been working on the kernel
almost daily for many years now, and there are few others that
do the same. When you get old like me, it helps to have some
consistency in your life :-). I know what is in all of the
files and where to go and change something.
As I said in the beginning, I don't find the confusion or
challenge in the include/asm directory. The challenge is in
the source code itself, trying to sort out all of the configuration
options and utilizing the generic software.
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/