* [PATCH4/4] [POWERPC] Fix cpm_uart driver
From: Jochen Friedrich @ 2007-09-23 20:17 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 424 bytes --]
In cpm_uart_core, functions cpm_uart_init_bd and cpm_uart_init_scc
an offset into DP RAM is calculated by substracting a physical
memory constant from an virtual address. This patch fixes the
problem by converting the virtual address into a physical
first.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
drivers/serial/cpm_uart/cpm_uart_core.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
[-- Attachment #2: 2c5cf6868e9aa6eadea285e524d88859cc5e54fb.diff --]
[-- Type: text/x-patch, Size: 1298 bytes --]
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
index cefde58..7f5db7c 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -752,8 +752,10 @@ static void cpm_uart_init_scc(struct uart_cpm_port *pinfo)
sup = pinfo->sccup;
/* Store address */
- pinfo->sccup->scc_genscc.scc_rbase = (unsigned char *)pinfo->rx_bd_base - DPRAM_BASE;
- pinfo->sccup->scc_genscc.scc_tbase = (unsigned char *)pinfo->tx_bd_base - DPRAM_BASE;
+ pinfo->sccup->scc_genscc.scc_rbase =
+ (u_char *)cpm_dpram_phys((u8 *)pinfo->rx_bd_base) - DPRAM_BASE;
+ pinfo->sccup->scc_genscc.scc_tbase =
+ (u_char *)cpm_dpram_phys((u8 *)pinfo->tx_bd_base) - DPRAM_BASE;
/* Set up the uart parameters in the
* parameter ram.
@@ -813,8 +815,10 @@ static void cpm_uart_init_smc(struct uart_cpm_port *pinfo)
up = pinfo->smcup;
/* Store address */
- pinfo->smcup->smc_rbase = (u_char *)pinfo->rx_bd_base - DPRAM_BASE;
- pinfo->smcup->smc_tbase = (u_char *)pinfo->tx_bd_base - DPRAM_BASE;
+ pinfo->smcup->smc_rbase =
+ (u_char *)cpm_dpram_phys((u8 *)pinfo->rx_bd_base) - DPRAM_BASE;
+ pinfo->smcup->smc_tbase =
+ (u_char *)cpm_dpram_phys((u8 *)pinfo->tx_bd_base) - DPRAM_BASE;
/*
* In case SMC1 is being relocated...
^ permalink raw reply related
* [PATCH3/4] [PPC] Compile fix for 8xx CPM Ehernet driver
From: Jochen Friedrich @ 2007-09-23 20:17 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 492 bytes --]
Add #include <asm/cacheflush.h> for flush_dcache_range
to make the driver compile again.
CC arch/ppc/8xx_io/enet.o
arch/ppc/8xx_io/enet.c: In function 'scc_enet_start_xmit':
arch/ppc/8xx_io/enet.c:240: error: implicit declaration of function
'flush_dcache_range'
make[1]: *** [arch/ppc/8xx_io/enet.o] Error 1
make: *** [arch/ppc/8xx_io] Error 2
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/ppc/8xx_io/enet.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
[-- Attachment #2: c10ab471b95ac13c93b0ae36d169756ae694a77d.diff --]
[-- Type: text/x-patch, Size: 308 bytes --]
diff --git a/arch/ppc/8xx_io/enet.c b/arch/ppc/8xx_io/enet.c
index 703d47e..eace3bc 100644
--- a/arch/ppc/8xx_io/enet.c
+++ b/arch/ppc/8xx_io/enet.c
@@ -44,6 +44,7 @@
#include <asm/mpc8xx.h>
#include <asm/uaccess.h>
#include <asm/commproc.h>
+#include <asm/cacheflush.h>
/*
* Theory of Operation
^ permalink raw reply related
* [PATCH2/4] [PPC] Fix cpm_dpram_addr returning phys mem instead of virt mem
From: Jochen Friedrich @ 2007-09-23 20:17 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 515 bytes --]
cpm_dpram_addr returns physical memory of the DP RAM instead of
iomapped virtual memory. As there usually is a 1:1 MMU map of
the IMMR area, this is often not noticed. However, cpm_dpram_phys
assumes this iomapped virtual memory and returns garbage on the
1:1 mapped memory causing CPM1 uart console to fail.
This patch fixes the problem (copied from the powerpc tree).
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/ppc/8xx_io/commproc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
[-- Attachment #2: 7a0161f68ca0e487c0119bbc7ee09189b87c1b06.diff --]
[-- Type: text/x-patch, Size: 399 bytes --]
diff --git a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
index 7088428..9da880b 100644
--- a/arch/ppc/8xx_io/commproc.c
+++ b/arch/ppc/8xx_io/commproc.c
@@ -459,7 +459,7 @@ EXPORT_SYMBOL(cpm_dpdump);
void *cpm_dpram_addr(unsigned long offset)
{
- return ((immap_t *)IMAP_ADDR)->im_cpm.cp_dpmem + offset;
+ return (void *)(dpram_vbase + offset);
}
EXPORT_SYMBOL(cpm_dpram_addr);
^ permalink raw reply related
* [PATCH1/4] [POWERPC] Fix copy'n'paste typo in commproc.c
From: Jochen Friedrich @ 2007-09-23 20:17 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 992 bytes --]
The powerpc version of commproc.c doesn't export cpm_dpram_addr twice
and cpm_dpram_phys not at all due to a typo. This patch fixes this
problem.
CC arch/powerpc/sysdev/commproc.o
arch/powerpc/sysdev/commproc.c:398: error: redefinition of '__kcrctab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of '__kcrctab_cpm_dpram_addr' was here
arch/powerpc/sysdev/commproc.c:398: error: redefinition of '__kstrtab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of '__kstrtab_cpm_dpram_addr' was here
arch/powerpc/sysdev/commproc.c:398: error: redefinition of '__ksymtab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of '__ksymtab_cpm_dpram_addr' was here
make[1]: *** [arch/powerpc/sysdev/commproc.o] Error 1
make: *** [arch/powerpc/sysdev] Error 2
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/powerpc/sysdev/commproc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
[-- Attachment #2: 828fc894599eb4bb5a015277687adbb75bb94cc0.diff --]
[-- Type: text/x-patch, Size: 355 bytes --]
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index 4f67b89..dd5417a 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -395,4 +395,4 @@ uint cpm_dpram_phys(u8* addr)
{
return (dpram_pbase + (uint)(addr - dpram_vbase));
}
-EXPORT_SYMBOL(cpm_dpram_addr);
+EXPORT_SYMBOL(cpm_dpram_phys);
^ permalink raw reply related
* [PATCH0/4] Various bug fixes
From: Jochen Friedrich @ 2007-09-23 20:16 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linux-kernel
Here is a series fixing some bugs for 8xx powerpc CPUs.
1. [POWERPC] Fix copy'n'paste typo in commproc.c
2. [PPC] Fix cpm_dpram_addr returning phys mem instead of virt mem
3. [PPC] Compile fix for 8xx CPM Ehernet driver
4. [POWERPC] Fix cpm_uart driver
This series can be pulled from git://git.bocc.de/dbox2.git ppc-fixes
Thanks,
Jochen
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Grant Likely @ 2007-09-23 15:32 UTC (permalink / raw)
To: Miroslaw Dach; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0709231519510.25165-100000@slslc02.psi.ch>
On 9/23/07, Miroslaw Dach <miroslaw.dach@psi.ch> wrote:
> Hi Grant,
>
> Thank you very much for your advices which were very valuable for me.
>
> Recently I have followed your advice to move from kernel 2.6.21 to the
> higher one in order to have the possibility to boot the kernel from
> u-boot. I have copied across from you git tree the latest version of linux
> kernel 2.6.23 rc-2.
>
> It compiles successfully with some warnings like below:
> MODPOST vmlinux.o
> WARNING: vmlinux.o(.text+0x223c): Section mismatch: reference to .init.text:early_init (between 'start_here' and 'initial_mmu')
> WARNING: vmlinux.o(.text+0x2254): Section mismatch: reference to .init.text:machine_init (between 'start_here' and 'initial_mmu')
> WARNING: vmlinux.o(.text+0x2258): Section mismatch: reference to .init.text:MMU_init (between 'start_here' and 'initial_mmu')
> WARNING: vmlinux.o(.text+0x22b2): Section mismatch: reference to .init.text:start_kernel (between 'start_here' and 'initial_mmu')
> WARNING: vmlinux.o(.text+0x22b6): Section mismatch: reference to .init.text:start_kernel (between 'start_here' and 'initial_mmu')
> LD vmlinux
Yes, I see this warning too. I haven't had a chance to debug it.
>
>
> My observation is that the linux 2.6.23 rc-2 is not that stable as 2.6.21.
> In most cases It boots successfully (ie. zImage.elf) but occasionally it
> fails during booting. It has never occurred with 2.6.21 which I also
> copied from your side.
Hmm, what failure mode are you seeing? I haven't experienced that
problem. However, -rc7 is now out, so I'd recommend moving up to it.
(Hint: use git to make it easy to pull the latest version and either
'quilt' or 'stgit' to manage your changes on top of the mainline tree;
it will make up/downgrading to different kernel version much easier)
> Second question:
>
> In addition I wanted to ask you about u-boot tree which you have mentioned
> in the post on u-boot mailing list. This post was about uart lite for
> ml403 in u-boot.
>
> I was not able to find the project which you have mentioned there:
> git://git.secretlab.ca/git/u-boot.git
That's because there is not such tree. :-) I retired that tree a
while ago because it's no longer current. You can use the mainline
u-boot tree:
git://www.denx.de/git/u-boot.git
>
> This what interests me in particular concerning u-boot is the uart lite
> and temac interfaces from ml403.
:-( I don't think either uartlite or temac drivers has been ported to u-boot.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Miroslaw Dach @ 2007-09-23 13:27 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
Hi Grant,
Thank you very much for your advices which were very valuable for me.
Recently I have followed your advice to move from kernel 2.6.21 to the
higher one in order to have the possibility to boot the kernel from
u-boot. I have copied across from you git tree the latest version of linux
kernel 2.6.23 rc-2.
It compiles successfully with some warnings like below:
MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x223c): Section mismatch: reference to .init.text:early_init (between 'start_here' and 'initial_mmu')
WARNING: vmlinux.o(.text+0x2254): Section mismatch: reference to .init.text:machine_init (between 'start_here' and 'initial_mmu')
WARNING: vmlinux.o(.text+0x2258): Section mismatch: reference to .init.text:MMU_init (between 'start_here' and 'initial_mmu')
WARNING: vmlinux.o(.text+0x22b2): Section mismatch: reference to .init.text:start_kernel (between 'start_here' and 'initial_mmu')
WARNING: vmlinux.o(.text+0x22b6): Section mismatch: reference to .init.text:start_kernel (between 'start_here' and 'initial_mmu')
LD vmlinux
My observation is that the linux 2.6.23 rc-2 is not that stable as 2.6.21.
In most cases It boots successfully (ie. zImage.elf) but occasionally it
fails during booting. It has never occurred with 2.6.21 which I also
copied from your side.
For both kernels I use the same xparamerets_ml403.h file and very similar
.config file
Do you have some idea if it is known problem with booting in 2.6.23 rc-2?
It of course could be something wrong with my ml403 board but I just
wanted to get your opinion about the stability issue. Maybe it is better
to use 2.6.22?
Second question:
In addition I wanted to ask you about u-boot tree which you have mentioned
in the post on u-boot mailing list. This post was about uart lite for
ml403 in u-boot.
I was not able to find the project which you have mentioned there:
git://git.secretlab.ca/git/u-boot.git
This what interests me in particular concerning u-boot is the uart lite
and temac interfaces from ml403.
Thank you very much in advance for any hint
Best Regards
Mirek
^ permalink raw reply
* Downtime
From: Stephen Rothwell @ 2007-09-23 13:02 UTC (permalink / raw)
To: ppc-dev; +Cc: ppc-embedded
[-- Attachment #1: Type: text/plain, Size: 337 bytes --]
Hi all,
Just letting you all know that ozlabs.org will be down for about 5 hours from 1:54 am Canberra time (UTC+10) Monday morning (i.e. about 2 hours 40 minutes from now) due to electrical work in our hosting data centre.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Sequoia kernel crash workaround.
From: Benjamin Herrenschmidt @ 2007-09-23 8:21 UTC (permalink / raw)
To: Josh Boyer
Cc: linuxppc-dev, Olof Johansson, Josh Boyer, Stefan Roese,
David Gibson
In-Reply-To: <20070920122919.32dd8061@weaponx.rchland.ibm.com>
On Thu, 2007-09-20 at 12:29 -0500, Josh Boyer wrote:
> On Thu, 20 Sep 2007 12:25:06 -0500
> Olof Johansson <olof@lixom.net> wrote:
>
> > On Thu, Sep 20, 2007 at 08:56:32PM +0400, Valentine Barshak wrote:
> > >
> > > I was thinking about it. Looks like it's the best place, but the code that
> > > actually calls setup_cpu is under ifdef CONFIG_PPC64, while lots of
> > > cpu_setup functions are defined for ppc32 processors.
> > > Is it OK to remove this ifdef, or should I do CONFIG_PPC64 || CONFIG_44x?
> >
> > Sounds like something that went wrong at the merge of ppc and ppc64.
> >
> > Take out the ifdef, even if there's fallout we should deal with it
> > instead of adding more complex ifdefs.
>
> Yeah. Looks like BenH did this in commit:
>
> 42c4aaadb737e0e672b3fb86b2c41ff59f0fb8bc
>
> Ben, any reason you ifdef'd it for ppc64?
I'll have to check on monday what's up there, but isn't setup_cpu called
from a different place on 32 bits? There are some subtle difference with
the way the cpu feature stuff is initialized /done between 32 and 64
bits that we haven't fully reconciled yet.
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] qemu platform, v2
From: Paul Mackerras @ 2007-09-23 4:27 UTC (permalink / raw)
To: Rob Landley; +Cc: linuxppc-dev, Christoph Hellwig, Milton Miller, David Gibson
In-Reply-To: <200709221416.21580.rob@landley.net>
Rob Landley writes:
Just to correct a few misconceptions:
> 2) PowerPC uses a device tree supplied by the hardware to identify the
> available hardware, even for stuff living on PCI busses which it could
> theoretically probe for but doesn't.
The device tree doesn't have to include anything that can be probed
for. On some platforms (e.g. pSeries) we choose to use the device
tree rather than probing, but on most other platforms we probe.
> I'd be following this more closely if compiling a device tree didn't currently
> require an external utility (dtc or some such) that doesn't come with the
> Linux kernel. No other target platform I've built kernels for requires such
> an environmental dependency.
No? You haven't built kernels for other platforms that have external
dependencies such as perl, gcc, make, binutils, etc.? :)
> (This is a problem both for hardwiring the
> device tree into the kernel and for building a new boot rom from the linux
> kernel's ppc boot wrapper that would contain such a device tree to feed to
> the kernel.)
It's only really been a problem for ps3 so far, since the embedded
guys don't seem to have any difficulty with installing dtc. We are
looking at what to do for ps3 and prep, and the answer may well
involve bundling dtc in the kernel source (it's not too big, around
3400 lines).
Paul.
^ permalink raw reply
* Re: [PATCH 0/3] usb: ehci ppc device-tree-aware driver
From: Hollis Blanchard @ 2007-09-22 23:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-usb-devel
In-Reply-To: <20070917125039.GA29525@ru.mvista.com>
On Mon, 17 Sep 2007 16:50:39 +0400, Valentine Barshak wrote:
> Some PowerPC systems have a built-in EHCI controller.
> This is a device tree aware version of the EHCI controller driver.
> Currently it's been tested on the PowerPC 440EPx Sequoia board.
> Other platforms can be added later.
> The code is based on the ehci-ppc-soc driver by Stefan Roese <sr@denx.de>.
We're having a strange issue on our Sequoia where the network stops
functioning when USB is active. Jerone can supply more detail...
Have you seen anything like that?
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 1/2] qemu platform, v2
From: Rob Landley @ 2007-09-22 19:16 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linuxppc-dev, Paul Mackerras, Milton Miller, David Gibson
In-Reply-To: <20070922095546.GA14185@lst.de>
On Saturday 22 September 2007 4:55:46 am Christoph Hellwig wrote:
> On Fri, Sep 21, 2007 at 06:08:31PM -0500, Milton Miller wrote:
> > Here is the second rev of patches to boot a arch powerpc kernel on
> > qemu with the prep architecture.
>
> So if this is supposed to be prep why do you need additional kernel
> support? And if you really needed why isn't it under platforms/prep?
The device tree provided by qemu's open hackware violates some of the
assumptions the Linux kernel is making? (Although things like "the cpu cache
size is zero" are, technically speaking, probably correct. :)
There are three different problems here:
1) porting prep from arch=ppc to arch=powerpc so you can build it on an arch
that also supports make headers_install.
2) PowerPC uses a device tree supplied by the hardware to identify the
available hardware, even for stuff living on PCI busses which it could
theoretically probe for but doesn't.
3) The PPC firmware qemu comes with ("Open Hackware") sucks rocks, is hard to
modify, isn't quite being maintained. As mentioned above, the device tree it
passes in (including "prep residual data" from which more nodes in the device
tree can be constructed, and here my understanding goes all fuzzy) does not
make for a happy Linux kernel.
Proposed solutions to all this involve various combinations of creating a
target platform aimed directly at qemu and not pretending to be prep at all
(so it doesn't have to parse residual data), creating our own boot rom image
out of some of the wrapper code the linux kernel's already got and feeding
that to qemu instead of using open hackware at all, hard wiring a device tree
into the kernel and not looking at the one open hackware passes in...)
I'd be following this more closely if compiling a device tree didn't currently
require an external utility (dtc or some such) that doesn't come with the
Linux kernel. No other target platform I've built kernels for requires such
an environmental dependency. (This is a problem both for hardwiring the
device tree into the kernel and for building a new boot rom from the linux
kernel's ppc boot wrapper that would contain such a device tree to feed to
the kernel.)
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: [PATCH v2] pcmcia: Convert io_req_t to use kio_addr_t
From: Olof Johansson @ 2007-09-22 15:11 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-pcmcia, linux-kernel, linuxppc-dev, Andrew Morton, hch,
Alan Cox
In-Reply-To: <20070922062551.GE10625@parisc-linux.org>
On Sat, Sep 22, 2007 at 12:25:51AM -0600, Matthew Wilcox wrote:
> On Fri, Sep 21, 2007 at 11:39:36PM +0100, Alan Cox wrote:
> > On Fri, 21 Sep 2007 17:15:16 -0500
> > Olof Johansson <olof@lixom.net> wrote:
> >
> > > Convert the io_req_t members to kio_addr_t, to allow use on machines with
> > > more than 16 bits worth of IO ports (i.e. secondary busses on ppc64, etc).
> >
> > What about the formatting and field widths ?
> >
> > ulong would probably be a lot saner than kio_addr_t and yet more type
> > obfuscation.
>
> I don't think anyone uses ioports > 32bit. Certainly i386 takes an int
> port as parameter to {in,out}[bwl] (and it really only uses 16-bits).
> parisc uses 24 bits. I don't know what the various ppcs do, but pci
> bars can only be 32-bit for ioports. So my opinion is that ioports
> should be uint, not ulong.
PPC would do just fine with 32-bit as well, which is what I wanted in
the first place. I just went with the local coding standard of pcmcia
and switched to kio_addr_t.
I suppose it's a janitorial todo item but with the maintainer MIA I
don't want to mess around with it too much, since I can't really test
much besides the PPC stuff I have.
As for the formatting/padding widths: Some platforms had ioaddr_t's
that were 32 bit already, so it was already broken on those, and the
only drawback is missing 0-padding. It'd look a bit silly to pad to 16
0:s anyway at the moment, so I think I'd prefer to keep it the way it is.
-Olof
^ permalink raw reply
* Re: [patch 04/28] Add cmpxchg64 and cmpxchg64_local to powerpc
From: Mathieu Desnoyers @ 2007-09-22 14:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, akpm, linux-kernel
In-Reply-To: <18164.40462.991761.909735@cargo.ozlabs.ibm.com>
* Paul Mackerras (paulus@samba.org) wrote:
> Mathieu Desnoyers writes:
>
> > Make sure that at least cmpxchg64_local is available on all architectures to use
> > for unsigned long long values.
> >
> > Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
>
> Acked-by: Paul Mackerras <paulus@samba.org>
Thanks Paul,
Just make sure add-cmpxchg-local-to-generic-for-up.patch gets merged
before this one, since it needs asm-generic/cmpxchg-local.h.
Mathieu
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* Re: [PATCH 1/2] qemu platform, v2
From: Christoph Hellwig @ 2007-09-22 9:55 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, Paul Mackerras, Rob Landley, David Gibson
In-Reply-To: <qemu-8-01.miltonm@bga.com>
On Fri, Sep 21, 2007 at 06:08:31PM -0500, Milton Miller wrote:
> Here is the second rev of patches to boot a arch powerpc kernel on
> qemu with the prep architecture.
So if this is supposed to be prep why do you need additional kernel
support? And if you really needed why isn't it under platforms/prep?
^ permalink raw reply
* Re: [PATCH v2] pcmcia: Convert io_req_t to use kio_addr_t
From: Christoph Hellwig @ 2007-09-22 9:13 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-pcmcia, linux-kernel, linuxppc-dev, Olof Johansson,
Andrew Morton, hch, Alan Cox
In-Reply-To: <20070922062551.GE10625@parisc-linux.org>
On Sat, Sep 22, 2007 at 12:25:51AM -0600, Matthew Wilcox wrote:
> > What about the formatting and field widths ?
> >
> > ulong would probably be a lot saner than kio_addr_t and yet more type
> > obfuscation.
>
> I don't think anyone uses ioports > 32bit. Certainly i386 takes an int
> port as parameter to {in,out}[bwl] (and it really only uses 16-bits).
> parisc uses 24 bits. I don't know what the various ppcs do, but pci
> bars can only be 32-bit for ioports. So my opinion is that ioports
> should be uint, not ulong.
The kernel seems to mostly use int, sometimes uint. I never quite got
why pcmcia had to have it's own strange typedef for them.
^ permalink raw reply
* Re: 2.6.23-rc6-mm1: Build failures on ppc64_defconfig
From: Satyam Sharma @ 2007-09-22 7:25 UTC (permalink / raw)
To: Mel Gorman
Cc: linuxppc-dev, Andrew Morton, Linux Kernel Mailing List,
Jeff Garzik, Linux Netdev Mailing List
In-Reply-To: <alpine.LFD.0.999.0709201903180.17093@enigma.security.iitk.ac.in>
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/net/spider_net.c
Fixing the above showed up another problem in another file of the
same driver (drivers/net/spider_net_ethtool.c)
[PATCH -mm] spider_net_ethtool: Keep up with recent netdev stats changes
Unbreak the following:
drivers/net/spider_net_ethtool.c: In function 'spider_net_get_ethtool_stats':
drivers/net/spider_net_ethtool.c:160: error: structure has no member named 'netdev_stats'
drivers/net/spider_net_ethtool.c:161: error: structure has no member named 'netdev_stats'
drivers/net/spider_net_ethtool.c:162: error: structure has no member named 'netdev_stats'
drivers/net/spider_net_ethtool.c:163: error: structure has no member named 'netdev_stats'
drivers/net/spider_net_ethtool.c:164: error: structure has no member named 'netdev_stats'
drivers/net/spider_net_ethtool.c:165: error: structure has no member named 'netdev_stats'
drivers/net/spider_net_ethtool.c:166: error: structure has no member named 'netdev_stats'
make[2]: *** [drivers/net/spider_net_ethtool.o] Error 1
Also do another ARRAY_SIZE() cleanup while at it.
Signed-off-by: Satyam Sharma <satyam@infradead.org>
---
drivers/net/spider_net_ethtool.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff -ruNp a/drivers/net/spider_net_ethtool.c b/drivers/net/spider_net_ethtool.c
--- a/drivers/net/spider_net_ethtool.c 2007-09-22 06:26:39.000000000 +0530
+++ b/drivers/net/spider_net_ethtool.c 2007-09-22 12:43:51.000000000 +0530
@@ -28,8 +28,6 @@
#include "spider_net.h"
-#define SPIDER_NET_NUM_STATS 13
-
static struct {
const char str[ETH_GSTRING_LEN];
} ethtool_stats_keys[] = {
@@ -149,7 +147,7 @@ spider_net_ethtool_get_ringparam(struct
static int spider_net_get_stats_count(struct net_device *netdev)
{
- return SPIDER_NET_NUM_STATS;
+ return ARRAY_SIZE(ethtool_stats_keys);
}
static void spider_net_get_ethtool_stats(struct net_device *netdev,
@@ -157,13 +155,13 @@ static void spider_net_get_ethtool_stats
{
struct spider_net_card *card = netdev->priv;
- data[0] = card->netdev_stats.tx_packets;
- data[1] = card->netdev_stats.tx_bytes;
- data[2] = card->netdev_stats.rx_packets;
- data[3] = card->netdev_stats.rx_bytes;
- data[4] = card->netdev_stats.tx_errors;
- data[5] = card->netdev_stats.tx_dropped;
- data[6] = card->netdev_stats.rx_dropped;
+ data[0] = netdev->stats.tx_packets;
+ data[1] = netdev->stats.tx_bytes;
+ data[2] = netdev->stats.rx_packets;
+ data[3] = netdev->stats.rx_bytes;
+ data[4] = netdev->stats.tx_errors;
+ data[5] = netdev->stats.tx_dropped;
+ data[6] = netdev->stats.rx_dropped;
data[7] = card->spider_stats.rx_desc_error;
data[8] = card->spider_stats.tx_timeouts;
data[9] = card->spider_stats.alloc_rx_skb_error;
^ permalink raw reply
* Re: [PATCH v2] pcmcia: Convert io_req_t to use kio_addr_t
From: Matthew Wilcox @ 2007-09-22 6:25 UTC (permalink / raw)
To: Alan Cox
Cc: linux-pcmcia, linux-kernel, linuxppc-dev, Olof Johansson,
Andrew Morton, hch
In-Reply-To: <20070921233936.2aeb2504@the-village.bc.nu>
On Fri, Sep 21, 2007 at 11:39:36PM +0100, Alan Cox wrote:
> On Fri, 21 Sep 2007 17:15:16 -0500
> Olof Johansson <olof@lixom.net> wrote:
>
> > Convert the io_req_t members to kio_addr_t, to allow use on machines with
> > more than 16 bits worth of IO ports (i.e. secondary busses on ppc64, etc).
>
> What about the formatting and field widths ?
>
> ulong would probably be a lot saner than kio_addr_t and yet more type
> obfuscation.
I don't think anyone uses ioports > 32bit. Certainly i386 takes an int
port as parameter to {in,out}[bwl] (and it really only uses 16-bits).
parisc uses 24 bits. I don't know what the various ppcs do, but pci
bars can only be 32-bit for ioports. So my opinion is that ioports
should be uint, not ulong.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* Re: 2.6.23-rc6-mm1: Build failures on ppc64_defconfig
From: Satyam Sharma @ 2007-09-22 6:54 UTC (permalink / raw)
To: Mel Gorman
Cc: linuxppc-dev, Andrew Morton, Linux Kernel Mailing List, jeff,
Linux Netdev Mailing List
In-Reply-To: <alpine.LFD.0.999.0709201903180.17093@enigma.security.iitk.ac.in>
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/net/spider_net.c
[PATCH -mm] spider_net: Misc build fixes after recent netdev stats changes
Unbreak the following:
drivers/net/spider_net.c: In function 'spider_net_release_tx_chain':
drivers/net/spider_net.c:818: error: 'dev' undeclared (first use in this function)
drivers/net/spider_net.c:818: error: (Each undeclared identifier is reported only once
drivers/net/spider_net.c:818: error: for each function it appears in.)
drivers/net/spider_net.c: In function 'spider_net_xmit':
drivers/net/spider_net.c:922: error: 'dev' undeclared (first use in this function)
drivers/net/spider_net.c: In function 'spider_net_pass_skb_up':
drivers/net/spider_net.c:1018: error: 'dev' undeclared (first use in this function)
drivers/net/spider_net.c: In function 'spider_net_decode_one_descr':
drivers/net/spider_net.c:1215: error: 'dev' undeclared (first use in this function)
make[2]: *** [drivers/net/spider_net.o] Error 1
Signed-off-by: Satyam Sharma <satyam@infradead.org>
---
drivers/net/spider_net.c | 24 +++++++++++-------------
1 file changed, 11 insertions(+), 13 deletions(-)
diff -ruNp a/drivers/net/spider_net.c b/drivers/net/spider_net.c
--- a/drivers/net/spider_net.c 2007-09-22 06:26:39.000000000 +0530
+++ b/drivers/net/spider_net.c 2007-09-22 12:12:23.000000000 +0530
@@ -795,6 +795,7 @@ spider_net_set_low_watermark(struct spid
static int
spider_net_release_tx_chain(struct spider_net_card *card, int brutal)
{
+ struct net_device *dev = card->netdev;
struct spider_net_descr_chain *chain = &card->tx_chain;
struct spider_net_descr *descr;
struct spider_net_hw_descr *hwdescr;
@@ -919,7 +920,7 @@ spider_net_xmit(struct sk_buff *skb, str
spider_net_release_tx_chain(card, 0);
if (spider_net_prepare_tx_descr(card, skb) != 0) {
- dev->stats.tx_dropped++;
+ netdev->stats.tx_dropped++;
netif_stop_queue(netdev);
return NETDEV_TX_BUSY;
}
@@ -979,16 +980,12 @@ static void
spider_net_pass_skb_up(struct spider_net_descr *descr,
struct spider_net_card *card)
{
- struct spider_net_hw_descr *hwdescr= descr->hwdescr;
- struct sk_buff *skb;
- struct net_device *netdev;
- u32 data_status, data_error;
-
- data_status = hwdescr->data_status;
- data_error = hwdescr->data_error;
- netdev = card->netdev;
+ struct spider_net_hw_descr *hwdescr = descr->hwdescr;
+ struct sk_buff *skb = descr->skb;
+ struct net_device *netdev = card->netdev;
+ u32 data_status = hwdescr->data_status;
+ u32 data_error = hwdescr->data_error;
- skb = descr->skb;
skb_put(skb, hwdescr->valid_size);
/* the card seems to add 2 bytes of junk in front
@@ -1015,8 +1012,8 @@ spider_net_pass_skb_up(struct spider_net
}
/* update netdevice statistics */
- dev->stats.rx_packets++;
- dev->stats.rx_bytes += skb->len;
+ netdev->stats.rx_packets++;
+ netdev->stats.rx_bytes += skb->len;
/* pass skb up to stack */
netif_receive_skb(skb);
@@ -1184,6 +1181,7 @@ static int spider_net_resync_tail_ptr(st
static int
spider_net_decode_one_descr(struct spider_net_card *card)
{
+ struct net_device *dev = card->netdev;
struct spider_net_descr_chain *chain = &card->rx_chain;
struct spider_net_descr *descr = chain->tail;
struct spider_net_hw_descr *hwdescr = descr->hwdescr;
@@ -1210,7 +1208,7 @@ spider_net_decode_one_descr(struct spide
(status == SPIDER_NET_DESCR_PROTECTION_ERROR) ||
(status == SPIDER_NET_DESCR_FORCE_END) ) {
if (netif_msg_rx_err(card))
- dev_err(&card->netdev->dev,
+ dev_err(&dev->dev,
"dropping RX descriptor with state %d\n", status);
dev->stats.rx_dropped++;
goto bad_desc;
^ permalink raw reply
* Re: 2.6.23-rc6-mm1: Build failures on ppc64_defconfig
From: Satyam Sharma @ 2007-09-22 6:51 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, Andrew Morton, Linux Kernel Mailing List
In-Reply-To: <alpine.LFD.0.999.0709201903180.17093@enigma.security.iitk.ac.in>
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/md/raid6int8.c
This turned out to be a gcc bug -- I was using an old cross-compiler.
^ permalink raw reply
* Re: 2.6.23-rc6-mm1: Build failures on ppc64_defconfig
From: Satyam Sharma @ 2007-09-22 6:50 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, Andrew Morton, Linux Kernel Mailing List, jeff
In-Reply-To: <alpine.LFD.0.999.0709201903180.17093@enigma.security.iitk.ac.in>
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/ata/pata_scc.c
http://lkml.org/lkml/2007/9/21/557
^ permalink raw reply
* Re: [patch 04/28] Add cmpxchg64 and cmpxchg64_local to powerpc
From: Paul Mackerras @ 2007-09-22 4:46 UTC (permalink / raw)
To: Mathieu Desnoyers; +Cc: linuxppc-dev, akpm, linux-kernel
In-Reply-To: <20070827155524.827591009@polymtl.ca>
Mathieu Desnoyers writes:
> Make sure that at least cmpxchg64_local is available on all architectures to use
> for unsigned long long values.
>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: 2.6.23-rc6-mm1: Build failure on ppc64 drivers/ata/pata_scc.c
From: Satyam Sharma @ 2007-09-22 2:50 UTC (permalink / raw)
To: Alan Cox
Cc: jeff, linuxppc-dev, Linux Kernel Mailing List, kamalesh,
linux-ide, Mel Gorman, Andrew Morton
In-Reply-To: <20070920150925.0caf3aef@the-village.bc.nu>
Hi,
On Thu, 20 Sep 2007, Alan Cox wrote:
>
> On Thu, 20 Sep 2007 14:13:15 +0100
> mel@skynet.ie (Mel Gorman) wrote:
>
> > PPC64 building allmodconfig fails to compile drivers/ata/pata_scc.c . It
> > doesn't show up on other arches because this driver is specific to the
> > architecture.
> >
> > drivers/ata/pata_scc.c: In function `scc_bmdma_status'
>
> Its not been updated to match the libata core changes. Try something like
> this. Whoever is maintaining it should also remove the prereset cable handling
> code and use the proper cable detect method.
It appears you forgot to fix scc_std_softreset() and one of its callsites
in scc_bdma_stop(). A complete patch is attempted below -- please review.
[PATCH -mm] pata_scc: Keep up with libata core API changes
Little fixlets, that the build started erroring / warning about:
drivers/ata/pata_scc.c: In function 'scc_bmdma_status':
drivers/ata/pata_scc.c:734: error: structure has no member named 'active_tag'
drivers/ata/pata_scc.c: In function 'scc_pata_prereset':
drivers/ata/pata_scc.c:866: warning: passing arg 1 of 'ata_std_prereset' from incompatible pointer type
drivers/ata/pata_scc.c: In function 'scc_error_handler':
drivers/ata/pata_scc.c:908: warning: passing arg 2 of 'ata_bmdma_drive_eh' from incompatible pointer type
drivers/ata/pata_scc.c:908: warning: passing arg 3 of 'ata_bmdma_drive_eh' from incompatible pointer type
drivers/ata/pata_scc.c:908: warning: passing arg 5 of 'ata_bmdma_drive_eh' from incompatible pointer type
make[2]: *** [drivers/ata/pata_scc.o] Error 1
Signed-off-by: Satyam Sharma <satyam@infradead.org>
Cc: Alan Cox <alan@redhat.com>
Cc: Mel Gorman <mel@skynet.ie>
---
Andrew, this includes (supercedes) the previous two ones from Mel / Alan.
drivers/ata/pata_scc.c | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
diff -ruNp a/drivers/ata/pata_scc.c b/drivers/ata/pata_scc.c
--- a/drivers/ata/pata_scc.c 2007-09-22 06:26:37.000000000 +0530
+++ b/drivers/ata/pata_scc.c 2007-09-22 08:04:42.000000000 +0530
@@ -594,16 +594,17 @@ static unsigned int scc_bus_softreset(st
* Note: Original code is ata_std_softreset().
*/
-static int scc_std_softreset (struct ata_port *ap, unsigned int *classes,
- unsigned long deadline)
+static int scc_std_softreset(struct ata_link *link, unsigned int *classes,
+ unsigned long deadline)
{
+ struct ata_port *ap = link->ap;
unsigned int slave_possible = ap->flags & ATA_FLAG_SLAVE_POSS;
unsigned int devmask = 0, err_mask;
u8 err;
DPRINTK("ENTER\n");
- if (ata_link_offline(&ap->link)) {
+ if (ata_link_offline(link)) {
classes[0] = ATA_DEV_NONE;
goto out;
}
@@ -692,7 +693,7 @@ static void scc_bmdma_stop (struct ata_q
printk(KERN_WARNING "%s: Internal Bus Error\n", DRV_NAME);
out_be32(bmid_base + SCC_DMA_INTST, INTSTS_BMSINT);
/* TBD: SW reset */
- scc_std_softreset(ap, &classes, deadline);
+ scc_std_softreset(&ap->link, &classes, deadline);
continue;
}
@@ -731,7 +732,7 @@ static u8 scc_bmdma_status (struct ata_p
void __iomem *mmio = ap->ioaddr.bmdma_addr;
u8 host_stat = in_be32(mmio + SCC_DMA_STATUS);
u32 int_status = in_be32(mmio + SCC_DMA_INTST);
- struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->active_tag);
+ struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->link.active_tag);
static int retry = 0;
/* return if IOS_SS is cleared */
@@ -860,10 +861,10 @@ static void scc_bmdma_freeze (struct ata
* @deadline: deadline jiffies for the operation
*/
-static int scc_pata_prereset(struct ata_port *ap, unsigned long deadline)
+static int scc_pata_prereset(struct ata_link *link, unsigned long deadline)
{
- ap->cbl = ATA_CBL_PATA80;
- return ata_std_prereset(ap, deadline);
+ link->ap->cbl = ATA_CBL_PATA80;
+ return ata_std_prereset(link, deadline);
}
/**
@@ -874,8 +875,10 @@ static int scc_pata_prereset(struct ata_
* Note: Original code is ata_std_postreset().
*/
-static void scc_std_postreset (struct ata_port *ap, unsigned int *classes)
+static void scc_std_postreset(struct ata_link *link, unsigned int *classes)
{
+ struct ata_port *ap = link->ap;
+
DPRINTK("ENTER\n");
/* is double-select really necessary? */
^ permalink raw reply
* Re: DTC Patch for Cygwin
From: David Gibson @ 2007-09-22 0:19 UTC (permalink / raw)
To: Matt Tyrlik; +Cc: linuxppc-dev
In-Reply-To: <OFF6527B59.0D9695D8-ON8525735D.006AC05C-8525735D.006C3903@us.ibm.com>
On Fri, Sep 21, 2007 at 03:42:04PM -0400, Matt Tyrlik wrote:
> >Scott Wood <scottwood@freescale.com> wrote on 09/21/2007 02:46:39 PM:
> > On Fri, Sep 21, 2007 at 11:26:04AM -0400, Matt Tyrlik wrote:
> > >
> > > Changes required to compile DTC under Cygwin
A S-o-b line will be needed before this can be applied.
> > >
> > > ===================================================================
> > > --- dtc-org.orig/tests/supernode_atdepth_offset.c
> > > +++ dtc-org/tests/supernode_atdepth_offset.c
> > > @@ -63,8 +63,11 @@ int path_prefix(const char *path, int de
> > > return 1;
> > >
> > > p = path;
> > > - for (i = 0; i < depth; i++)
> > > - p = strchrnul(p+1, '/');
> > > + for (i = 0; i < depth; i++) {
> > > + p = strchr(p+1, '/');
> > > + if (!p)
> > > + p = path + strlen(path);
> > > + }
> > >
> > > return p - path;
> > > }
> >
> > Maybe we should define strchrnul under #ifndef GLIBC, similar to
> > strndupa?
> Since this is used only in one place David Gibson suggested that the
> change should be done in code.
Yeah, I don't actually particularly care which way we go with this one.
> > > Index: dtc-org/tests/testutils.c
> > > ===================================================================
> > > --- dtc-org.orig/tests/testutils.c
> > > +++ dtc-org/tests/testutils.c
> > > @@ -52,10 +52,9 @@ static void sigint_handler(int signum, s
> > > void test_init(int argc, char *argv[])
> > > {
> > > int err;
> > > - struct sigaction sa_int = {
> > > - .sa_sigaction = sigint_handler,
> > > - };
> > > + struct sigaction sa_int;
> > >
> > > + sa_int.sa_sigaction = sigint_handler,
> > > test_name = argv[0];
> >
> > What version of GCC does cygwin use? That doesn't seem like something
> > that should break due to OS differences.
> >
> > -Scott
> Currently 3.4.4. The compiler can't handle unnamed union in an
> initializer.
Or at least that's my surmise, I can't see why else it would be
breaking.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH 2/2] qemu platform rom, v2
From: Milton Miller @ 2007-09-21 23:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Rob Landley, David Gibson
In-Reply-To: <boot-8-00.miltonm@bga.com>
Here is the second rev of patches to boot a powerpc port kernel on
qemu with the prep architecture.
The goal is to provide a environment for use with the existing qemu
hardware suppplied hardware, as oposed to changing the qemu
machine description.
This patch has the changes to the boot wrapper and the device tree.
It applies to the additon of my kexec series to the for-2.6.24 branch
as of 2007/09/21.
The wrapper code zBoot is packaged as ppc_rom.bin, provding a replacement
for OpenHackware. [OpenHackware requires the kernel boot device to
have a partition table, even if its laoded in memory (which prep sort
of provides). It also only gueses the execution of boot sripts and any
forth, and has noot seen any development in 3 years].
This rom copies its contents to ram where it then invokes the normal
wrapper starup path, using the serial port for the console. It proceeds
to locate the commandline, kernel, and initrd using nvram. It supports
only nvram at the prep location of 0x8000074 indicating a boot from
"memory" aka qemu -kernel or drive "m". The loaded image can be a
kernel or a zImage (in this mode it will ignore any attached device
tree preferring the one supplied via r3), but the contianed kernel and
optionally a initrd as per the normal build process will be used.
Specifically, the patch requrires (1) external vmlinux hook and wrapper
(2) check loader_info command line after fixups, and (3) obtain initrd
from device-tree, (4) several patches committed to the for-2.6.24 branch.
When building the rom, configure the device tree as "qemu.dts". When
building the vmlinux or zImage -kernel, you can use the empty string
("") to suppress the call to dtc as the code will ignore any attached dtb.
When invoking qemu, use the -L flag to specify the directory with the
ppc_rom.bin file.
Index: kernel/arch/powerpc/boot/qemu.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ kernel/arch/powerpc/boot/qemu.c 2007-09-21 04:53:32.000000000 -0500
@@ -0,0 +1,235 @@
+/*
+ * QEMU PReP-specific stuff for the zImage boot wrapper.
+ *
+ * Copyright (C) 2007 Milton Miller, IBM Corp. <miltonm@bga.com>
+ * Copyright (C) 2006 Paul Mackerras, IBM Corp. <paulus@samba.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License.
+ *
+ * nvram format obtained from OpenHackWare 0.4
+ * Copyright (C) 2004-2005 Jocelyn Mayer (l_indien@magic.fr)
+ *
+ */
+
+asm(
+/*
+ * gcc 4.1.2 seems to place this first, even with the block at the end of
+ * the file. Put it first for good measure. If the branch ends up at the
+ * beginning of the image then it can be started like a kernel.
+ */
+" b _zimage_start\n" /* gcc 4.1.2 places this first */
+
+/*
+ * This code will be loaded by qemu as a rom at the end of memory, and
+ * execution will start at address -4. Since the rom is read only, we
+ * and the zImage code wants to run where loaded, we must copy it to ram.
+ *
+ * move to linked place
+ * end with a branch to this code
+ * this code will be copied with dd to the end of the rom image
+ */
+
+" .globl copy_rom_start\n"
+"copy_rom_start:\n"
+" bl 1f\n"
+"1: mflr 4\n"
+" clrrwi 4,4,19\n" /* ROM_BITS -- get beginning of rom */
+" lis 5,_end@ha\n"
+" addi 5,5,_end@l\n"
+" lis 3,_start@ha\n"
+" addi 3,3,_start@l\n"
+" subf 5,3,5\n"
+" addi 5,5,0x1f\n"
+" srwi 5,5,5\n"
+" mtctr 5\n"
+"2: lwz 24,0(4)\n" /* copy to linked addresss */
+" lwz 25,4(4)\n"
+" lwz 26,8(4)\n"
+" lwz 27,12(4)\n"
+" lwz 28,16(4)\n"
+" lwz 29,20(4)\n"
+" lwz 30,24(4)\n"
+" lwz 31,28(4)\n"
+" stw 24,0(3)\n"
+" stw 25,4(3)\n"
+" stw 26,8(3)\n"
+" stw 27,12(3)\n"
+" stw 28,16(3)\n"
+" stw 29,20(3)\n"
+" stw 30,24(3)\n"
+" stw 31,28(3)\n"
+" dcbf 0,3\n"
+" sync\n"
+" icbi 0,3\n"
+" addi 3,3,32\n"
+" addi 4,4,32\n"
+" bdnz 2b\n"
+" sync\n"
+" isync\n"
+
+ /*
+ * Put a branch to self on a few vectors in case we get an unexpected
+ * interrupt. At least you can dump regs in the qemu monitor.
+ */
+" lis 0,0x48000000@h\n"
+" stw 0,0x700(0)\n"
+" stw 0,0x300(0)\n"
+" stw 0,0x400(0)\n"
+" stw 0,0x900(0)\n"
+" stw 0,0x800(0)\n"
+" stw 0,0x200(0)\n"
+
+ /* branch to linked address */
+" lis 0,_zimage_start@h\n"
+" ori 0,0,_zimage_start@l\n"
+" mtctr 0\n"
+" li 3,0\n"
+" bctrl\n"
+
+ /* must be last word before copy_rom_end */
+" b copy_rom_start\n"
+" .globl copy_rom_end\n"
+"copy_rom_end:\n"
+);
+
+
+#include <stddef.h>
+#include "string.h"
+#include "stdio.h"
+#include "ops.h"
+#include "page.h"
+#include "io.h"
+#include "gunzip_util.h"
+#include "flatdevtree.h"
+
+BSS_STACK(16*1024);
+
+unsigned char *nvram = (void *)0x80000074; /* address of nvram on PReP */
+
+static void qemu_nvram_write(unsigned short addr, char data)
+{
+ out_8(nvram + 0, addr & 0xff);
+ out_8(nvram + 1, addr >> 8);
+ out_8(nvram + 3, data);
+}
+
+static char qemu_nvram_read(unsigned short addr)
+{
+ char data;
+ out_8(nvram + 0, addr & 0xff);
+ out_8(nvram + 1, addr >> 8);
+ data = in_8(nvram + 3);
+
+ return data;
+}
+
+static void qemu_nvram_fetch(unsigned short addr, unsigned short len, void *p)
+{
+ char *buf = p;
+ int i;
+
+ for (i = 0; i < len; i ++)
+ buf[i] = qemu_nvram_read(addr + i); /* big endian */
+}
+
+static char arch[17];
+static void * image_start;
+static unsigned int image_len;
+
+void qemu_find_vmlinuz(struct gunzip_state *state, void **srcp,
+ unsigned long *lenp)
+{
+ *srcp = image_start;
+ *lenp = image_len;
+ gunzip_start(state, image_start, image_len);
+}
+
+/* if no device tree, read the nvram to find out about our system */
+/* based on openhackware 0.4 nvram.c get_nvram_config */
+static void qemu_fixups(void)
+{
+ char buf[32];
+ int word;
+
+ printf("qemu_fixups\n\r");
+
+ qemu_nvram_fetch(0, 16, buf);
+ printf("sig: %s", buf);
+ if (strcmp(buf, "QEMU_BIOS"))
+ fatal("no qemu sig found");
+ qemu_nvram_fetch(0x10, 16, &word);
+ if (word != 2)
+ fatal("wrong qemu nvram version");
+ /* compute crc over 0-0xfc, compare to crc in 0xfc */
+ /* size at 0x14, mult 256 0x400-0x2000 */
+ qemu_nvram_fetch(0x20, 16, buf);
+ strncpy(arch, buf, sizeof(arch)-1);
+ if (strcmp(arch,"PREP"))
+ fatal("don't understand arch %s", arch);
+
+ /* XXX: put the model in the device tree */
+
+ qemu_nvram_fetch(0x30, 16, &word);
+ printf("memory: %x\n\r", word);
+ dt_fixup_memory(0, word);
+ printf("boot device %c\n\r", qemu_nvram_read(0x34));
+ qemu_nvram_fetch(0x38, 16, &word);
+ image_start = (void *)word;
+ qemu_nvram_fetch(0x3c, 16, &word);
+ image_len = word;
+ printf("kernel %p %x\n\r", image_start, image_len);
+ qemu_nvram_fetch(0x40, 16, &word);
+ loader_info.cmdline = (void *)word;
+ qemu_nvram_fetch(0x44, 16, &word);
+ loader_info.cmdline_len = word;
+ printf("cmdline %p %x\n\r", loader_info.cmdline,
+ loader_info.cmdline_len);
+ printf("cmdline is %s\n\r", loader_info.cmdline);
+ qemu_nvram_fetch(0x48, 16, &word);
+ loader_info.initrd_addr = word;
+ qemu_nvram_fetch(0x4c, 16, &word);
+ loader_info.initrd_size = word;
+ printf("initrd %lx %lx\n\r", loader_info.initrd_addr,
+ loader_info.initrd_size);
+ /* XXX: nvram image addr at 50 */
+ /* XXX: vga width, height, depth = shorts at 54, 56, 58 */
+}
+
+/* If loaded with a device tree, then just read the tree */
+static void tree_fixups(void)
+{
+ /* get initrd from tree */
+ dt_find_initrd();
+
+ /* we must have an attached image for boot with supplied device-tree */
+}
+
+static void *heap_end; /* set in platform_init */
+
+static void *qemu_vmlinux_alloc(unsigned long size)
+{
+ if (size < (unsigned long)_start)
+ return 0;
+
+ return (void *)_ALIGN_UP((unsigned long) heap_end, 4096);
+}
+
+void platform_init(void *r3)
+{
+ struct boot_param_header *bph = r3;
+
+ heap_end = simple_alloc_init(_end, 4096*1024, 4096, 512);
+
+ if (bph) {
+ ft_init(bph, bph->totalsize, 128);
+ platform_ops.fixups = tree_fixups;
+ } else {
+ ft_init(_dtb_start, _dtb_end - _dtb_start, 128);
+ platform_ops.fixups = qemu_fixups;
+ platform_ops.find_vmlinuz = qemu_find_vmlinuz;
+ }
+ platform_ops.vmlinux_alloc = qemu_vmlinux_alloc;
+
+ serial_console_init();
+}
Index: kernel/arch/powerpc/boot/dts/qemu.dts
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ kernel/arch/powerpc/boot/dts/qemu.dts 2007-09-21 04:53:32.000000000 -0500
@@ -0,0 +1,132 @@
+/*
+ * QEMU PReP skeleton device tree
+ * from PReP skeleton device tree
+ * and qemu source
+ *
+ * Milton Miller
+ */
+
+/ {
+ device_type = "qemu";
+ model = "QEMU,PReP";
+ compatible = "qemu-prep";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ reg = <0>;
+ clock-frequency =<d#200000000>;
+ bus-frequency = <d#100000000>;
+ timebase-frequency = <d#100000000>;
+ i-cache-line-size = <d#32>;
+ d-cache-line-size = <d#32>;
+ d-cache-size = <0>;
+ i-cache-size = <0>;
+
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ // dummy range here, zImage wrapper will fill in the actual
+ // amount of memory from the nvram
+ reg = <00000000 01000000>;
+ };
+
+ pci@80800000 {
+ device_type = "pci";
+ compatible = "prep-pci";
+ clock-frequency = <01fca055>;
+ reg = <80800000 00400000>; /* pci config space */
+ 8259-interrupt-acknowledge = <bffffff0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges=<01000000 00000000 00000000 80000000 00000000 00800000
+ 02000000 00000000 00000000 c0000000 00000000 01000000>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0800 0 0 0>;
+ interrupt-map = <0800 0 0 0 &PIC8259 b 3
+ 0000 0 0 0 &PIC8259 9 3>;
+
+ isa {
+ device_type = "isa";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ ranges = <00000001 00000000
+ 01005800 00000000 00000000 00010000
+ 00000000 00000000
+ 02005800 00000000 00000000 01000000>;
+
+ parallel {
+ device_type = "parallel";
+ compatible = "pnpPNP,401", "pnpPNP,400";
+ reg = <00000001 000003bc 00000008
+ 00000001 000007bc 00000006>;
+ interrupts = <00000007 00000003>;
+ interrupt-parent = <&PIC8259>;
+ };
+
+ serial@3f8 {
+ device_type = "serial";
+ compatible = "pnpPNP,501", "pnpPNP,500",
+ "ns16550";
+ virtual-reg = <800003f8>;
+ clock-frequency = <001c2000>;
+ reg = <00000001 000003f8 00000008>;
+ interrupts = <00000004 00000003>;
+ interrupt-parent = <&PIC8259>;
+ };
+ PIC8259: interrupt-controller {
+ #interrupt-cells = <2>;
+ device_type = "i8259";
+ compatible = "prep,iic";
+ interrupt-controller;
+ reg = < 00000001 00000020 00000002
+ 00000001 000000a0 00000002
+ 00000001 000004d0 00000002>;
+ };
+ ne2000@300 {
+ reg = <00000001 00000300 00000020>;
+ interrupt-parent = <&PIC8259>;
+ interrupts=<9 3>;
+ };
+ ne2000@320 {
+ reg = <00000001 00000320 00000020>;
+ interrupt-parent = <&PIC8259>;
+ interrupts=<a 3>;
+ };
+ ne2000@340 {
+ reg = <00000001 00000340 00000020>;
+ interrupt-parent = <&PIC8259>;
+ interrupts=<b 3>;
+ };
+ ne2000@360 {
+ reg = <00000001 00000360 00000020>;
+ interrupt-parent = <&PIC8259>;
+ interrupts=<3 3>;
+ };
+ ne2000@280 {
+ reg = <00000001 00000280 00000020>;
+ interrupt-parent = <&PIC8259>;
+ interrupts=<4 3>;
+ };
+ ne2000@380 {
+ reg = <00000001 00000380 00000020>;
+ interrupt-parent = <&PIC8259>;
+ interrupts=<5 3>;
+ };
+
+ };
+ };
+
+ chosen {
+ linux,stdout-path = "/pci/isa/serial@3f8";
+ };
+};
+
Index: kernel/arch/powerpc/boot/wrapper
===================================================================
--- kernel.orig/arch/powerpc/boot/wrapper 2007-09-21 04:52:59.000000000 -0500
+++ kernel/arch/powerpc/boot/wrapper 2007-09-21 04:53:32.000000000 -0500
@@ -310,4 +310,53 @@ ps3)
gzip --force -9 --stdout "$ofile.bin" > "$object/otheros.bld"
;;
+qemu)
+ # this part makes the zBoot.qemu a bootrom for qemu.
+ #
+ # the qemu bootrom is 512k , located at the top of the 32 bit address
+ # space. The fixed entrypoint is address -4.
+
+ copy_rom_start=0x`${CROSS}nm "$ofile" \
+ | grep ' copy_rom_start$' \
+ | cut -d' ' -f1`
+ copy_rom_start=`printf "%d" $copy_rom_start`
+ copy_rom_end=0x`${CROSS}nm "$ofile" \
+ | grep ' copy_rom_end$' \
+ | cut -d' ' -f1`
+ copy_rom_end=`printf "%d" $copy_rom_end`
+ rom_start=0x`${CROSS}nm "$ofile" \
+ | grep ' _start$' \
+ | cut -d' ' -f1`
+
+ rom_start=`printf "%d" $rom_start`
+ rom_size=$((1<<19))
+ copy_rom_len=$(($copy_rom_end-$copy_rom_start))
+ copy_rom_dst=$(($rom_size-$copy_rom_len))
+ copy_rom_src=$(($copy_rom_start-$rom_start))
+
+ img_size=`${CROSS}size "$ofile" | tail -n1 | cut -f4`
+ if [ $img_size -gt $copy_rom_dst ]
+ then
+ echo Image "${ofile##*/}" too big to fit in rom, skipping rom build.
+ else
+ romfile="$object/ppc_rom.bin"
+ tmpfile="$object/ppc_rom.$$"
+
+ rm -f "$tmpfile"
+ ${CROSS}objcopy -O binary --pad-to=$(($rom_size+$rom_start)) \
+ --gap-fill=0xff "$ofile" "$tmpfile"
+
+ msg=$(dd if="$tmpfile" of="$tmpfile" conv=notrunc \
+ skip=$copy_rom_src seek=$copy_rom_dst \
+ count=$copy_rom_len bs=1 2>&1)
+
+ if [ $? -ne "0" ]; then
+ echo $msg
+ rm -f "$tmpfile"
+ exit 2
+ fi
+
+ mv "$tmpfile" "$romfile"
+ fi
+ ;;
esac
Index: kernel/arch/powerpc/boot/.gitignore
===================================================================
--- kernel.orig/arch/powerpc/boot/.gitignore 2007-09-21 04:51:30.000000000 -0500
+++ kernel/arch/powerpc/boot/.gitignore 2007-09-21 04:53:32.000000000 -0500
@@ -17,6 +17,7 @@ infutil.h
kernel-vmlinux.strip.c
kernel-vmlinux.strip.gz
mktree
+ppc_rom.bin
uImage
cuImage.*
zImage
Index: kernel/arch/powerpc/boot/Makefile
===================================================================
--- kernel.orig/arch/powerpc/boot/Makefile 2007-09-21 04:52:59.000000000 -0500
+++ kernel/arch/powerpc/boot/Makefile 2007-09-21 04:53:32.000000000 -0500
@@ -48,7 +48,7 @@ src-wlib := string.S crt0.S stdio.c main
4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
cpm-serial.c stdlib.c
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c crt0_kexec.S \
- cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
+ cuboot-ebony.c treeboot-ebony.c prpmc2800.c qemu.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c
src-boot := $(src-wlib) $(src-plat) empty.c
@@ -143,6 +143,7 @@ image-$(CONFIG_PPC_PMAC) += zImage.pmac
image-$(CONFIG_PPC_HOLLY) += zImage.holly
image-$(CONFIG_PPC_PRPMC2800) += zImage.prpmc2800
image-$(CONFIG_PPC_ISERIES) += zImage.iseries
+image-$(CONFIG_PPC_QEMU) += zImage.qemu zBoot.qemu
image-$(CONFIG_DEFAULT_UIMAGE) += uImage
image-$(CONFIG_KEXEC) += $(kexec-y)
image-$(CONFIG_KEXEC) += $(patsubst zImage%,zBoot%,$(kexec-y))
@@ -202,6 +203,9 @@ $(obj)/zImage.iseries: vmlinux
$(obj)/zBoot.%: $(wrapperbits) $(dts)
$(call if_changed,wrap,$*,$(dts),,,$(obj)/empty.o)
+# horrible hack to avoid overlapping calls to wrapper script clobbering dtb.
+$(obj)/zImage.qemu: $(obj)/zBoot.qemu
+
$(obj)/zImage.ps3: vmlinux $(wrapper) $(wrapperbits) $(srctree)/$(src)/dts/ps3.dts
$(STRIP) -s -R .comment $< -o vmlinux.strip
$(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,)
@@ -235,8 +239,8 @@ install: $(CONFIGURE) $(addprefix $(obj)
sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux System.map "$(INSTALL_PATH)" $<
# anything not in $(targets)
-clean-files += $(image-) $(initrd-) zImage zImage.initrd cuImage.* treeImage.* \
- otheros.bld $(kexec-)
+clean-files += $(image-) $(initrd-) zImage zImage.initrd cuImage.* treeImage.*
+clean-files += otheros.bld ppc_rom.bin $(kexec-)
# clean up files cached by wrapper
clean-kernel := vmlinux.strip vmlinux.bin empty.o.bin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox