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
Quoted 5 lines · Jakob Viketoft
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.
Quoted 6 lines
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!
Quoted 6 lines · Andrew May
I think a huge first step would be to banish
xparameters.hfrom 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?
Quoted 10 lines
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_tablein theboard_io_mapping.So the quick way to start tracking things down may be to just replace all the constants in
xparmaters.hwith 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
Quoted 10 lines · Jakob Viketoft
Thanks for the comments!
Quoted 6 lines · Andrew May
I think a huge first step would be to banish
xparameters.hfrom 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.
Quoted 8 lines
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?
Don't tie anything permanently to OCP. :) Eventually, 4xx will convert to platform devices like other similar SoC type subarches in ppc32 have already done. The only reason it hasn't been done yet is that there are some other higher priority things on my plate at the moment.
That said, anything you do with OCP additions maps right into platform_data in the platform device world.
However, it seems you are talking about passing information to the kernel from some bootrom or full featured firmware. That is a separate issue from how information is passed from the arch-code into drivers (this is what OCP and platform devices accomplish). For now, you could define a birec type for xparameters and standardize around passing the info in that. In the future, birecs should be replaced by the "flattened OF device tree" method that has been discussed here a bit (I know Jon Masters is lurking around here, maybe with some code).
Quoted 11 lines
Quoted 10 lines
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_tablein theboard_io_mapping.So the quick way to start tracking things down may be to just replace all the constants in
xparmaters.hwith 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.
Quoted 6 lines
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?
Even the smallest bootloader rom could put the xparameters.h info in a location and point to it using the standard birec method when transferring control to the kernel.
I belive this would give Andrew the kind of flexibility he would like. We've even talked about moving (in many cases at least) the SoC device descriptions for other PPC SoCs out of the kernel so they are passed in via birecs or the future flattened OF device tree.
-Matt
Quoted 6 lines · Matt Porter
Quoted 5 lines · Jakob Viketoft
Thanks for the comments!
Quoted 2 lines · Andrew May
I think a huge first step would be to banish
xparameters.hfrom all the kernel code.
....
Quoted 6 lines
Quoted 6 lines
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?
Not so much resentment, as a realization that xparamters.h is where all the work is going to flow from.
Quoted 7 lines
Quoted 2 lines
Matt (Porter), I've seen that you've "ported" this to the 2.6 kernel, what do you say?
Don't tie anything permanently to OCP. :) Eventually, 4xx will convert to platform devices like other similar SoC type subarches in ppc32 have already done. The only reason it hasn't been done yet is that there are some other higher priority things on my plate at the moment.
I am still working with an old 2_4_devel kernel myself. The something better is comming has always held me back from working on things as well.
Even now OCP is being dropped for platform devices. And birecs is being dropped for OF.
The kernel I am working with is a step behind both of those.
Quoted 9 lines
However, it seems you are talking about passing information to the kernel from some bootrom or full featured firmware. That is a separate issue from how information is passed from the arch-code into drivers (this is what OCP and platform devices accomplish). For now, you could define a birec type for xparameters and standardize around passing the info in that. In the future, birecs should be replaced by the "flattened OF device tree" method that has been discussed here a bit (I know Jon Masters is lurking around here, maybe with some code).
A simple fucntion that would take the xparameters.h and create the birecs/OF data would be a nice way to go.
I would think the func could run on the host to generate a binary blob that could be attached to the kernel or dropped in flash, for simple bootloaders.
For a better bootloader it could run the func itself on the target and put the data in ram, and then fixup the data if needed.
Quoted 3 lines
Even the smallest bootloader rom could put the
xparameters.hinfo in a location and point to it using the standard birec method when transferring control to the kernel.
I am a U-boot person myself, but I think there will be a higher number of users that just stick with the standard loader providied by the vendor and do the wrapper thing in the kernel.
Quoted 1 line
I belive this would give Andrew the kind of flexibility he would like.
Yes, I think it would.
Sorry for the delay in answer, but I've been off sick most of last week. Anyway, I've contacted Jon Masters off the list about the OF device tree approach and hopefully there will be something coming of this soon enough.
Cheers!
/Jakob
Quoted 71 lines · Debian User
Quoted 8 lines · Matt Porter
Quoted 6 lines · Jakob Viketoft
Thanks for the comments!
Quoted 2 lines · Andrew May
I think a huge first step would be to banish
xparameters.hfrom all the kernel code.....
Quoted 1 line
Quoted 1 line
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?
Not so much resentment, as a realization that
xparamters.his where all the work is going to flow from.Quoted 6 lines
Quoted 1 line
Matt (Porter), I've seen that you've "ported" this to the 2.6 kernel, what do you say?
Don't tie anything permanently to OCP. :) Eventually, 4xx will convert to platform devices like other similar SoC type subarches in ppc32 have already done. The only reason it hasn't been done yet is that there are some other higher priority things on my plate at the moment.
I am still working with an old 2_4_devel kernel myself. The something better is comming has always held me back from working on things as well.
Even now OCP is being dropped for platform devices. And birecs is being dropped for OF.
The kernel I am working with is a step behind both of those.Quoted 9 lines
However, it seems you are talking about passing information to the kernel from some bootrom or full featured firmware. That is a separate issue from how information is passed from the arch-code into drivers (this is what OCP and platform devices accomplish). For now, you could define a birec type for xparameters and standardize around passing the info in that. In the future, birecs should be replaced by the "flattened OF device tree" method that has been discussed here a bit (I know Jon Masters is lurking around here, maybe with some code).
A simple fucntion that would take the
xparameters.hand create the birecs/OF data would be a nice way to go.
I would think the func could run on the host to generate a binary blob that could be attached to the kernel or dropped in flash, for simple bootloaders.
For a better bootloader it could run the func itself on the target and put the data in ram, and then fixup the data if needed.Quoted 3 lines
Even the smallest bootloader rom could put the
xparameters.hinfo in a location and point to it using the standard birec method when transferring control to the kernel.I am a U-boot person myself, but I think there will be a higher number of users that just stick with the standard loader providied by the vendor and do the wrapper thing in the kernel.
Quoted 1 line
I belive this would give Andrew the kind of flexibility he would like.
Yes, I think it would.
Quoted 11 lines · Jakob Viketoft
Thanks for the comments!
Quoted 1 line · Andrew May
I think a huge first step would be to banish
xparameters.hfrom allthe
Quoted 5 lines
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.
Quoted 5 lines
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