linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Andrew May <acmay@acmay.homeip.net>
To: Jakob Viketoft <jakob.viketoft@bitsim.se>
Cc: Linux PPC Embedded list <linuxppc-embedded@ozlabs.org>
Subject: Re: Adding machine types to the kernel tree...
Date: Thu, 03 Mar 2005 10:50:09 -0800	[thread overview]
Message-ID: <1109875809.25252.24.camel@mud> (raw)
In-Reply-To: <4226F904.5010104@bitsim.se>

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];
}
============================================

  reply	other threads:[~2005-03-03 19:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-03 11:46 Adding machine types to the kernel tree Jakob Viketoft
2005-03-03 18:50 ` Andrew May [this message]
2005-03-07 10:07   ` Jakob Viketoft
2005-03-07 12:27     ` Matt Porter
2005-03-08 18:01       ` Debian User
2005-03-14  9:43         ` Jakob Viketoft
2005-03-07 17:38     ` Kumar Gala

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1109875809.25252.24.camel@mud \
    --to=acmay@acmay.homeip.net \
    --cc=jakob.viketoft@bitsim.se \
    --cc=linuxppc-embedded@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).