Thread (87 messages) flat view 87 messages, 8 authors, 2007-05-07

Re: [PATCH 3/13] powerpc: Add bootwrapper support for Marvell/mv64x60 hostbridge

From: Mark A. Greer <hidden>
Date: 2007-05-03 18:44:02

On Thu, May 03, 2007 at 03:25:06PM +1000, Paul Mackerras wrote:
Mark A. Greer writes:
quoted
Well, the firmware just doesn't do all the init that's required.  And,
some of the init that it does do is wrong.  For example, the window for
the MPSC (serial ctlr) to access main memory isn't set up so the kernel
mpsc driver can't dma.  There are several other examles.

All of this init should be in the firmware but its Motorola/ECC's
firmware and I/we have no control over it.  Given that, I/we have to do
the init somewhere.  Either in the kernel or the bootwrapper.
I vote for the bootwrapper but then your vote is the only one that actually
counts.  :)
How much of the setup is actually necessary for the bootwrapper to
run, and how much could be deferred to setup_arch() time in the
kernel?
Actually, none of the config code should be needed by the bootwrapper
itself because the bootwrapper mpsc and i2c drivers use PIO (so accessing
memory isn't an issue).  The "get info" type routines are still needed.
If nothing else, doing it in the kernel means that the code
and data for it exist in compressed form in the zImage rather than
uncompressed form. :)
mv64x60.o is 4804 bytes, .text is 2188 bytes, .data 64 bytes, .bss 0
bytes.  So we're probably only saving ~1-2KB by compressing.
Also, how many lines of code (including definitions) would we avoid
having in the kernel by having this stuff in the bootwrapper?
Its pretty much 1:1.  Whatever is in the bootwrapper (including
#define's) isn't needed in the kernel.
Another question - is this setup something that will need to be done
differently for different boards using the mv64x60, or is the same
setup needed for all applications of the mv64x60?
I expect that the setup will be done the same for all of the boards
that need it.  Not all of the boards will need it, though.  It depends
on their firmware.  The config code is filling the gap between what the
firmware should have done and what the kernel drivers require (i.e.,
allowing the ctlrs to access system memory and pci mem/io space).

Paul, I'm a little perplexed by you wanting this code pushed back into
the kernel.  A while back there was a definite desire to push stuff like
this out of the kernel (mainly by Ben).  I tend to agree with Ben on
this.  Either way, it would good to have everyone pushing in the same
direction. :)

Mark
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help