Adding machine types to the kernel tree...

Hi!

Are there any certain policys or religious issues about adding machine types to the (ppc40x) kernel tree, and who's responsible for kicking stuff like this up the main tree?

Specifically, I would like to replace the PowerPC405 support for the Xilinx ML 300 (development board) with generic Xilinx Virtex-II Pro and Virtex4 support (FPGAs). In my opinion, the end target isn't the development boards, but the custom configuration it all will run on in the end, and so things would benefit from a more general support. Do anyone have any insightful views/opinions on this or comments of any kind?

Clearly, there seem to be some demand for this lately according to traffic on the list...

Cheers!

	/Jakob

On Thu, 2005-03-03 at 12:46 +0100, Jakob Viketoft wrote:

Hi!

Are there any certain policys or religious issues about adding machine 
types to the (ppc40x) kernel tree, and who's responsible for kicking 
stuff like this up the main tree?

Well I don't know about that, but what really makes it hard for me to
work on things is that I only have a few custom boards to test on.
So any time I make changes that could make things more general I can't
test to make sure I don't break a vanilla eval board.

Specifically, I would like to replace the PowerPC405 support for the 
Xilinx ML 300 (development board) with generic Xilinx Virtex-II Pro and 
Virtex4 support (FPGAs). In my opinion, the end target isn't the 
development boards, but the custom configuration it all will run on in 
the end, and so things would benefit from a more general support. Do 
anyone have any insightful views/opinions on this or comments of any kind?

I think a huge first step would be to banish xparameters.h from all the
kernel code.
Our HW guys just seem to do the strangest things without checking.
So I have 2 spins of a board with 2 Virtex-II pro's each.
The 2 spins have a small refrence clock change and the 2 CPU's have
different IRQ mappings.

There is no way I wanted to build 4 kernels to handle these.
I don't have the code with me, but the basic thing I did was fixup
the compiled in arrays like rs_table in the board_io_mapping.

So the quick way to start tracking things down may be to just
replace all the constants in xparmaters.h with function calls
that got the info from the boot loader if possible.
You will get plenty of compile errors for the arrays, but then
just this type of code needs to be fixed up to setup the arrary
at run time rather than just get the pointer to it at run time.

=========================================
XEmac_Config *
XEmac_GetConfig(int Instance)
{
	if (Instance < 0 || Instance >= XPAR_XEMAC_NUM_INSTANCES) {
		return NULL;
	}

	return &XEmac_ConfigTable[Instance];
}
============================================

Thanks for the comments!

Andrew May wrote:

I think a huge first step would be to banish xparameters.h from all the
kernel code.
Our HW guys just seem to do the strangest things without checking.
So I have 2 spins of a board with 2 Virtex-II pro's each.
The 2 spins have a small refrence clock change and the 2 CPU's have
different IRQ mappings.

I understand that there is numerous resentment against having this file in the kernel and I've been thinking of a solution without it. One such path would be serving the kernel with a OCP list of the devices used, but I'm unsure about the current status of OCP. Is this The Right Way to do it, or are OCP likely to be abandoned further along the 2.6 road?

Matt (Porter), I've seen that you've "ported" this to the 2.6 kernel, what do you say?

There is no way I wanted to build 4 kernels to handle these.
I don't have the code with me, but the basic thing I did was fixup
the compiled in arrays like rs_table in the board_io_mapping.

So the quick way to start tracking things down may be to just
replace all the constants in xparmaters.h with function calls
that got the info from the boot loader if possible.
You will get plenty of compile errors for the arrays, but then
just this type of code needs to be fixed up to setup the arrary
at run time rather than just get the pointer to it at run time.

The question is, do you want to have a bootloader (as U-boot) on a small embedded system? In the FPGA case, you might need something that puts the bitstream in the right place, but I'm not quite sure it would constitute a bootloader. Maybe just having a static OCP list at a certain location in flash and let the little bitstream prog send the pointer to it as a kernel parameter at startup?

Reactions appreciated!

Cheers!

	/Jakob

On Mar 7, 2005, at 4:07 AM, Jakob Viketoft wrote:

Thanks for the comments!

Andrew May wrote:
 > I think a huge first step would be to banish xparameters.h from all the
 > kernel code.
 > Our HW guys just seem to do the strangest things without checking.
 > So I have 2 spins of a board with 2 Virtex-II pro's each.
 > The 2 spins have a small refrence clock change and the 2 CPU's have
 > different IRQ mappings.

I understand that there is numerous resentment against having this file
in the kernel and I've been thinking of a solution without it. One such
path would be serving the kernel with a OCP list of the devices used,
but I'm unsure about the current status of OCP. Is this The Right Way to
do it, or are OCP likely to be abandoned further along the 2.6 road?

If you are talking about 2.6, dont use OCP.  Use the driver model and platform devices.  You can take a look at the arch/ppc/syslib/ppc_sys.c and arch/ppc/platforms/85xx for examples.

- kumar