* Rameshmrm sent you a friend request on Tagged :)
From: Rameshmrm Mrm @ 2008-04-05 9:55 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 3106 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinx uart 16550.
From: Josh Boyer @ 2008-04-05 14:45 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus, John Linn, david
In-Reply-To: <200804030616.09825.arnd@arndb.de>
On Thu, 2008-04-03 at 06:16 +0200, Arnd Bergmann wrote:
> On Thursday 03 April 2008, Grant Likely wrote:
> > >
> > > Since it is not really compatible with ns16550, shouldn't you at least specify
> > > a different "compatible" property? That way, the driver won't do incorrect
> > > accesses when you try to use an old driver with a device tree that specifies
> > > one of these.
> >
> > Heh; we've gone back and forth on this issue. The problem is that we
> > have a common case of ns16550 like devices that require a little bit
> > of register address tweaking that spans a whole range of vendors (so
> > adding a compatible match with each of those vendor's prefixes is
> > probably non-scalable). So, if "ns16550" is not a good idea, then
> > what should be used? "sparse16550" has been suggested more than once.
>
> After another IRC discussion between Grant, Segher and myself, we concluded
> that we don't need to invent a new "compatible" value, as only new device
> trees with old kernels will have a problem with this, and they don't work
> in the first place.
>
> The devices will still have their specific "compatible" value, e.g.
> "xlnx,plb-uart16550-1.00.c", followed by "ns16550", and possibly
> "ns16450" and "i8250", although the last two do not have an effect
> on Linux.
>
> Josh, can you please forward all three patches in their latest version?
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
So is the discussion on reg-offset settled then? It seemed Paul and
David had some issues with that, and I'd like to make sure everyone is
agreed on that before I bring in patches 2 and 3.
josh
^ permalink raw reply
* Re: Booting Linux Kernel on MPC8560
From: Dale Farnsworth @ 2008-04-05 14:50 UTC (permalink / raw)
To: dgaur; +Cc: linuxppc-embedded
In-Reply-To: <20080405063151.M54613@cdotd.ernet.in>
Deepak Gaur wrote:
>
> I have a task to boot Mvista kernel on MPC8560 based board. The
> bootloader in U-boot.
> After decompression my final image is located at address 0x1fff0040 in
> SDRAM
That's your problem. This code only works when loaded at address 0.
Fix your bootloader configuration.
-Dale
^ permalink raw reply
* Re: [PATCH 3/4] PowerPC: Add PCI entry to 440EPx Sequoia DTS.
From: Sergei Shtylyov @ 2008-04-05 16:30 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071221162601.GA1700@ru.mvista.com>
Valentine Barshak wrote:
> This adds PCI entry to PowerPC 440EPx Sequoia DTS.
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> --- linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts 2007-12-21 17:14:17.000000000 +0300
> +++ linux-2.6/arch/powerpc/boot/dts/sequoia.dts 2007-12-21 17:18:32.000000000 +0300
> @@ -324,6 +324,33 @@
> has-new-stacr-staopc;
> };
> };
> +
> + PCI0: pci@1ec000000 {
> + device_type = "pci";
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + compatible = "ibm,plb440epx-pci", "ibm,plb-pci";
> + primary;
> + reg = <1 eec00000 8 /* Config space access */
> + 1 eed00000 4 /* IACK */
> + 1 eed00000 4 /* Special cycle */
> + 1 ef400000 40>; /* Internal registers */
> +
> + /* Outbound ranges, one memory and one IO,
> + * later cannot be changed. Chip supports a second
> + * IO range but we don't use it for now
> + */
> + ranges = <02000000 0 80000000 1 80000000 0 10000000
I wonder why the AMCC's Sequoia/Rainier manual has PCI memory mapped at
0x80000000-0xbfffffff? The 0x80000000-0x8fffffff mapping was assumed by
arch/ppc/ code. What/why changed here?
As we now both know, having PCI memory space mapped beyound 4 GB makes
some drivers misbehave as they use 'unsigned long' to store the result of
pci_resource_start() and later ioremap() this truncated value -- which is
64-bit on Sequoia due to CONFIG_RESOURCE_64BIT=y that is needed to store the
beyond-4GB addresses.
> + 01000000 0 00000000 1 e8000000 0 00100000>;
> +
> + /* Inbound 2GB range starting at 0 */
> + dma-ranges = <42000000 0 0 0 0 0 80000000>;
> +
> + /* All PCI interrupts are routed to IRQ 67 */
> + interrupt-map-mask = <0000 0 0 0>;
> + interrupt-map = < 0000 0 0 0 &UIC2 3 8 >;
> + };
> };
WBR, Sergei
^ permalink raw reply
* [PATCH RFC] tqm8560.dts: add local bus devices
From: Wolfgang Grandegger @ 2008-04-06 12:29 UTC (permalink / raw)
To: wg
Hello,
this is my first attempt to add local bus nodes to the DTS file
of the TQM8560 for the following devices:
CS1: 128 MB NOR FLASH at 0xf8000000
CS2: Two Intel 82527 CAN controller at 0xe3000000
CS3: 128 MB NAND FLASH at 0xe3010000
Index: linux-2.6-denx/arch/powerpc/boot/dts/tqm8560.dts
===================================================================
--- linux-2.6-denx.orig/arch/powerpc/boot/dts/tqm8560.dts
+++ linux-2.6-denx/arch/powerpc/boot/dts/tqm8560.dts
@@ -221,6 +221,77 @@
};
};
+ localbus@e0005000 {
+ compatible = "fsl,mpc8560-localbus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <0xe0005000 0x100>; // BRx, ORx, etc.
+
+ ranges = <
+ 0x0 0x0 0xfc000000 0x04000000 // NOR FLASH bank 1
+ 0x1 0x0 0xf8000000 0x08000000 // NOR FLASH bank 0
+ 0x2 0x0 0xe3000000 0x00008000 // CAN (2 x i82527)
+ 0x3 0x0 0xe3010000 0x00008000 // NAND FLASH
+ >;
+
+ flash@1,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x1 0x0 0x8000000>;
+ bank-width = <4>;
+ device-width = <1>;
+
+ partition@0 {
+ label = "kernel";
+ reg = <0x00000000 0x00300000>;
+ };
+ partition@300000 {
+ label = "fs";
+ reg = <0x00300000 0x07c00000>;
+ };
+ partition@7700000 {
+ label = "firmware";
+ reg = <0x07700000 0x00100000>;
+ read-only;
+ };
+
+ };
+
+ can@2,0 {
+ device_type = "can";
+ compatible = "i82527"; // Intel 82527 or Bosch CC770
+ reg = <0x2 0x0 0x100>;
+ interrupts = <0x9 0x2>;
+ interrupt-parent = <&mpic>;
+ }
+
+ can@2,100 {
+ device_type = "can";
+ compatible = "i82527"; // Intel 82527 or Bosch CC770
+ reg = <0x2 0x100 0x100>;
+ interrupts = <0x9 0x2>;
+ interrupt-parent = <&mpic>;
+ }
+
+ nand@3,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8560-fcm-nand",
+ "fsl,elbc-fcm-nand";
+ reg = <0x3 0x0 0x8000>;
+
+ kernel@0 {
+ label = "kernel";
+ reg = <0x000000 0x0300000>;
+ };
+ fs@300000 {
+ label = "fs";
+ reg = <0x300000 0x7d00000>;
+ };
+ };
+ };
+
pci0: pci@e0008000 {
cell-index = <0>;
#interrupt-cells = <1>;
Do these entries make sense?
TIA.
Wolfgang.
^ permalink raw reply
* Please pull 'for-2.6.26' branch of 4xx tree
From: Josh Boyer @ 2008-04-06 12:41 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.26
to pick up a handful of additional commits for 2.6.26. Most of these
are bug fixes. Grant adds a helpful make target for building dtb files,
which is quite useful for some newer 4xx boards as well as other
platforms in general.
josh
Grant Likely (2):
[POWERPC] add target for building .dtb files
[POWERPC] bootwrapper: Add a firmware-independent simpleboot target.
Josh Boyer (1):
[POWERPC] 4xx: Add Canyonlands and Yosemite to multi-board defconfig
Stefan Roese (5):
[POWERPC] 4xx: Only reset PCIe PHY on 405EX systems when no link is detect
[POWERPC] 4xx: Fix PESDRn_UTLSET1 register setup on 460EX/GT
[POWERPC] 4xx: Create common ppc4xx_reset_system() in ppc4xx_soc.c
[POWERPC] 4xx: Some EMAC related changes in Canyonlands & Glacier dts file
[POWERPC] 4xx: Change dts files to support jumbo frames
Stephen Neuendorffer (1):
[POWERPC] of_serial: Fix possible null dereference.
Valentine Barshak (1):
[POWERPC] 4xx: Use machine_device_initcall() for warp_nand
arch/powerpc/Makefile | 2 +-
arch/powerpc/boot/Makefile | 36 +++++++++----
arch/powerpc/boot/dts/canyonlands.dts | 19 +++++--
arch/powerpc/boot/dts/glacier.dts | 5 ++-
arch/powerpc/boot/dts/haleakala.dts | 2 +-
arch/powerpc/boot/dts/katmai.dts | 2 +-
arch/powerpc/boot/dts/kilauea.dts | 4 +-
arch/powerpc/boot/dts/makalu.dts | 4 +-
arch/powerpc/boot/dts/rainier.dts | 4 +-
arch/powerpc/boot/dts/sequoia.dts | 4 +-
arch/powerpc/boot/dts/taishan.dts | 4 +-
arch/powerpc/boot/simpleboot.c | 84 ++++++++++++++++++++++++++++++
arch/powerpc/boot/virtex405-head.S | 30 +++++++++++
arch/powerpc/boot/wrapper | 4 ++
arch/powerpc/configs/ppc44x_defconfig | 14 ++++--
arch/powerpc/platforms/40x/ep405.c | 2 +
arch/powerpc/platforms/40x/kilauea.c | 4 +-
arch/powerpc/platforms/40x/makalu.c | 2 +
arch/powerpc/platforms/40x/virtex.c | 2 +
arch/powerpc/platforms/40x/walnut.c | 4 +-
arch/powerpc/platforms/44x/44x.h | 1 -
arch/powerpc/platforms/44x/Kconfig | 1 -
arch/powerpc/platforms/44x/bamboo.c | 15 +++---
arch/powerpc/platforms/44x/canyonlands.c | 5 +-
arch/powerpc/platforms/44x/ebony.c | 5 +-
arch/powerpc/platforms/44x/katmai.c | 5 +-
arch/powerpc/platforms/44x/misc_44x.S | 11 ----
arch/powerpc/platforms/44x/rainier.c | 4 +-
arch/powerpc/platforms/44x/sequoia.c | 4 +-
arch/powerpc/platforms/44x/taishan.c | 5 +-
arch/powerpc/platforms/44x/warp-nand.c | 3 +-
arch/powerpc/platforms/44x/warp.c | 6 +--
arch/powerpc/platforms/Kconfig.cputype | 2 +
arch/powerpc/sysdev/ppc4xx_pci.c | 18 ++-----
arch/powerpc/sysdev/ppc4xx_soc.c | 11 ++++
drivers/serial/of_serial.c | 4 +-
include/asm-powerpc/ppc4xx.h | 18 ++++++
37 files changed, 257 insertions(+), 93 deletions(-)
^ permalink raw reply
* 4xx defconfig reorg
From: Josh Boyer @ 2008-04-06 13:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
Hi All,
Unless someone screams loudly and has reasons why this shouldn't go in,
the following commit should hit the 4xx next branch in the next day or
so.
josh
commit eaf997b847be3c351eb9d0107e0562035dc58095
Author: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Date: Sun Apr 6 08:01:21 2008 -0500
[POWERPC] 4xx: Reorganize 4xx defconfigs
Board specific defconfigs are useful, however with the ability to do
multi-board defconfigs they aren't needed in the top level configs directory
Move the 4xx board specific defconfigs to individual directories under
arch/powerpc/configs.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
arch/powerpc/configs/{ => 40x}/ep405_defconfig | 0
arch/powerpc/configs/{ => 40x}/kilauea_defconfig | 0
arch/powerpc/configs/{ => 40x}/makalu_defconfig | 0
arch/powerpc/configs/{ => 40x}/walnut_defconfig | 0
arch/powerpc/configs/{ => 44x}/bamboo_defconfig | 0
.../configs/{ => 44x}/canyonlands_defconfig | 0
arch/powerpc/configs/{ => 44x}/ebony_defconfig | 0
arch/powerpc/configs/{ => 44x}/katmai_defconfig | 0
arch/powerpc/configs/{ => 44x}/rainier_defconfig | 0
arch/powerpc/configs/{ => 44x}/sequoia_defconfig | 0
arch/powerpc/configs/{ => 44x}/taishan_defconfig | 0
arch/powerpc/configs/{ => 44x}/warp_defconfig | 0
12 files changed, 0 insertions(+), 0 deletions(-)
^ permalink raw reply
* Re: 4xx defconfig reorg
From: Segher Boessenkool @ 2008-04-06 15:32 UTC (permalink / raw)
To: jwboyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <1207487181.6809.18.camel@vader.jdub.homelinux.org>
> Unless someone screams loudly and has reasons why this shouldn't go in,
These configs won't show up for "make help" anymore, which of course is
nice because that list was too long, but we need a way to get that back
since it was useful. I'll see what I can do.
Segher
^ permalink raw reply
* Re: [PATCH RFC] tqm8560.dts: add local bus devices
From: Wolfgang Grandegger @ 2008-04-06 17:42 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppc-dev
In-Reply-To: <0d57d42da9d29cc240be9d38de29ed96@kernel.crashing.org>
Segher Boessenkool wrote:
>> + partition@300000 {
>> + label = "fs";
>> + reg = <0x00300000 0x07c00000>;
>> + };
>> + partition@7700000 {
>> + label = "firmware";
>> + reg = <0x07700000 0x00100000>;
>
> These two overlap; should the latter be @7f00000?
Yes, of course.
>
>> + can@2,0 {
>> + device_type = "can";
>
> No device_type please.
OK, but then I better use a more descriptive name for the compatible
property, e.g.:
compatible = "can-i82527"; // Intel 82527 or Bosch CC770
>
>> + nand@3,0 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "fsl,mpc8560-fcm-nand",
>> + "fsl,elbc-fcm-nand";
>> + reg = <0x3 0x0 0x8000>;
>> +
>> + kernel@0 {
>> + label = "kernel";
>> + reg = <0x000000 0x0300000>;
>> + };
>> + fs@300000 {
>> + label = "fs";
>> + reg = <0x300000 0x7d00000>;
>> + };
>> + };
>> + };
>
> There should be a node that describes the nand chip between the nand
> controller node and the partition nodes.
I took the mpc8378_*.dts files of 2.6.25-rc8 as example and there is no
such node. Could you point me please to a more appropriate example.
>
>> Do these entries make sense?
>
> Looks good otherwise :-)
Thanks.
Wolfgang.
^ permalink raw reply
* Re: [PATCH RFC] tqm8560.dts: add local bus devices
From: Wolfgang Grandegger @ 2008-04-06 18:45 UTC (permalink / raw)
Cc: ppc-dev
In-Reply-To: <47F90B97.4080904@grandegger.com>
Wolfgang Grandegger wrote:
> Segher Boessenkool wrote:
>>> + partition@300000 {
>>> + label = "fs";
>>> + reg = <0x00300000 0x07c00000>;
>>> + };
>>> + partition@7700000 {
>>> + label = "firmware";
>>> + reg = <0x07700000 0x00100000>;
>> These two overlap; should the latter be @7f00000?
>
> Yes, of course.
>
>>> + can@2,0 {
>>> + device_type = "can";
>> No device_type please.
>
> OK, but then I better use a more descriptive name for the compatible
> property, e.g.:
>
> compatible = "can-i82527"; // Intel 82527 or Bosch CC770
>
>>> + nand@3,0 {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + compatible = "fsl,mpc8560-fcm-nand",
>>> + "fsl,elbc-fcm-nand";
>>> + reg = <0x3 0x0 0x8000>;
>>> +
>>> + kernel@0 {
>>> + label = "kernel";
>>> + reg = <0x000000 0x0300000>;
>>> + };
>>> + fs@300000 {
>>> + label = "fs";
>>> + reg = <0x300000 0x7d00000>;
>>> + };
>>> + };
>>> + };
>> There should be a node that describes the nand chip between the nand
>> controller node and the partition nodes.
>
> I took the mpc8378_*.dts files of 2.6.25-rc8 as example and there is no
> such node. Could you point me please to a more appropriate example.
In the meantime I realized, that the upcoming FSL UPM driver seems to be
appropriate for that board:
http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052890.html
What is the status of this driver? Are there already some boards using
it (including DTS file)?
Wolfgang.
^ permalink raw reply
* [PATCH] make help: Show defconfig subdirs
From: Segher Boessenkool @ 2008-04-06 20:16 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev; +Cc: Sam Ravnborg
PowerPC will start moving board defconfigs into subarch-specific
subdirs soon. "make help" currently does not look in subdirs to
find the defconfigs to show. This is partially a good thing,
since there are way too many defconfigs for one list.
This patch makes the main "make help" display something like
help-40x - Show 40x-specific targets
help-44x - Show 44x-specific targets
help-boards - Show all of the above
and wires up stuff so those new help-* commands actually work.
Cc: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
---
Makefile | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index fec2a12..05d9fda 100644
--- a/Makefile
+++ b/Makefile
@@ -1172,6 +1172,8 @@ rpm: include/config/kernel.release FORCE
boards := $(wildcard $(srctree)/arch/$(ARCH)/configs/*_defconfig)
boards := $(notdir $(boards))
+board-dirs := $(dir $(wildcard $(srctree)/arch/$(ARCH)/configs/*/*_defconfig))
+board-dirs := $(sort $(notdir $(board-dirs:/=)))
help:
@echo 'Cleaning targets:'
@@ -1225,6 +1227,11 @@ help:
$(foreach b, $(boards), \
printf " %-24s - Build for %s\\n" $(b) $(subst _defconfig,,$(b));) \
echo '')
+ @$(if $(board-dirs), \
+ $(foreach b, $(board-dirs), \
+ printf " %-16s - Show %s-specific targets\\n" help-$(b) $(b);) \
+ printf " %-16s - Show all of the above\\n" help-boards; \
+ echo '')
@echo ' make V=0|1 [targets] 0 => quiet build (default), 1 => verbose build'
@echo ' make V=2 [targets] 2 => give reason for rebuild of target'
@@ -1236,6 +1243,20 @@ help:
@echo 'For further info see the ./README file'
+help-board-dirs := $(addprefix help-,$(board-dirs))
+
+help-boards: $(help-board-dirs)
+
+boards-per-dir = $(notdir $(wildcard $(srctree)/arch/$(ARCH)/configs/$*/*_defconfig))
+
+$(help-board-dirs): help-%:
+ @echo 'Architecture specific targets ($(ARCH) $*):'
+ @$(if $(boards-per-dir), \
+ $(foreach b, $(boards-per-dir), \
+ printf " %-24s - Build for %s\\n" $*/$(b) $(subst _defconfig,,$(b));) \
+ echo '')
+
+
# Documentation targets
# ---------------------------------------------------------------------------
%docs: scripts_basic FORCE
--
1.5.3.4.208.g805a
^ permalink raw reply related
* Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
From: Paul Mackerras @ 2008-04-06 23:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, hollisb
In-Reply-To: <Pine.LNX.4.64.0804030144460.15974@blarg.am.freescale.net>
Kumar Gala writes:
> Wanted to get any feedback on this initial port of the fixmap support over
> from x86. There are a few TODOs:
I have no objection in principle, but your patch below imports a few
things that aren't (and won't be) needed on powerpc AFAICS -- for
example, we don't need FIX_VDSO, since our VDSO is mapped into user
space at the 1MB point (by default).
You have FIX_PCIE_MCFG in there too (keyed off CONFIG_PCI_MMCONFIG
which we don't have and don't want to have). If you need to map in
PCIe config space, what's wrong with just using ioremap? Why do you
need to have a fixed virtual address for it?
More generally, I think we need to take an overall look at what things
we are using fixed virtual addresses for, and why they need to be
fixed. If there are indeed several such things then we can introduce
the fixmap stuff.
Paul.
^ permalink raw reply
* Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
From: Benjamin Herrenschmidt @ 2008-04-07 0:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, hollisb
In-Reply-To: <18425.24938.332852.315571@cargo.ozlabs.ibm.com>
> You have FIX_PCIE_MCFG in there too (keyed off CONFIG_PCI_MMCONFIG
> which we don't have and don't want to have). If you need to map in
> PCIe config space, what's wrong with just using ioremap? Why do you
> need to have a fixed virtual address for it?
Well, that was the whole point for doing the fixmap stuff actually, to
be able to have a non-HIGHMEM version of a quick kmap_atomic for ...
PCIe config space :-)
On some PCIe host brigdes like the ones used on 4xx or FSL chips, the
config space is physically mapped as a large linear space, too large to
ioremap permanently, and we can't ioremap from within the low level
config ops.
So the idea is to use a fixmap as a "window" to the config space,
possibly per-cpu. Ultimately, we should even be able to directly insert
TLB entries in kmap_atomic/fixmap to make it even faster.
> More generally, I think we need to take an overall look at what things
> we are using fixed virtual addresses for, and why they need to be
> fixed. If there are indeed several such things then we can introduce
> the fixmap stuff.
The virtual address doesn't _need_ to be fixed in our case. It's more
like x86 builds kmap on top of fixmap and we were thinking about doing
the same, having it fixed makes it slightly easier to whack things but I
agree it's not necessarily the best option.
We could instead have something allocated a chunk of virtual space at
boot and provide a quick map/unmap.
But by using fixmap, we can use common code with kmap_atomic quickly and
easily.
Ben.
^ permalink raw reply
* a question about use dtb to bootting linux kernel on MPC83xx platform
From: 旭 罗 @ 2008-04-07 1:35 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]
I am Linux software engineer. These days I was debugging a MPC8313 system. In the debugging process, some source code in the kernel makes me puzzled. So I have find your email address in the source code. I think you can give me some advises to solve the problem.
My version is linux-2.6.23.9 and I use the device tree(dtb) to booting the kernel. In my bootloader I use the following code to jump to the kernel.
(*image)((bd_t *)dtb_entry, (unsigned int)image, 0, 0, 0);
The dtb_entry is the address of dtb file which in the SDRAM, the image is the kernel entry point. I flashed some LEDs in my board. So I can make sure the program run to the machine_init() which is defined in the /arch/powerpc/kernel/setup_32.c
In order to trace the problem I search the source code. I can find that these information is printed by the start function which is defined in the /arch/powerpc/boot/main.c.
Fourth more I have found that the kernel call the platform_init which is defined in the /arch/powerpc/boot/cuboot-83xx.c. looking the file head I have known you are the author for this file.
Could you told me how the kernel call the platform_init function and I hope you can show me the booting process of the MPC83xx linux or you could give me some document about it.
---------------------------------
雅虎邮箱，您的终生邮箱！
[-- Attachment #2: Type: text/html, Size: 2892 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc - Use KBUILD_CFLAGS and similar
From: Paul Mackerras @ 2008-04-07 3:27 UTC (permalink / raw)
To: Bastian Blank; +Cc: linuxppc-dev
In-Reply-To: <20080302190632.GA9898@wavehammer.waldi.eu.org>
Bastian Blank writes:
> The attached patch changes the powerpc main Makefile from using the override
> make directive to KBUILD_CFLAGS and similar.
I get build failures on all 64-bit targets with this patch. It ends
up using both -m32 and -m64 on the gcc command line for assembling .S
files.
Paul.
^ permalink raw reply
* Re: [PATCH v2] powerpc: Add irqtrace support for 32-bit powerpc
From: Benjamin Herrenschmidt @ 2008-04-07 4:49 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <20080404213932.GA15847@farnsworth.org>
I think I found one:
.../...
> - mr r6,r3
> rlwinm r12,r1,0,0,(31-THREAD_SHIFT) /* current_thread_info() */
> /* disable interrupts so current_thread_info()->flags can't change */
> LOAD_MSR_KERNEL(r10,MSR_KERNEL) /* doesn't include MSR_EE */
> SYNC
> MTMSRD(r10)
> +#ifdef CONFIG_TRACE_IRQFLAGS
> + stwu r1,-16(r1)
> + stw r3,12(r1)
> + bl trace_hardirqs_off
> + lwz r3,12(r1)
> + addi r1,r1,16
> + LOAD_MSR_KERNEL(r10,MSR_KERNEL)
> +#endif
Here, r12 is clobbered, though it's used two lines later:
> + mr r6,r3
> lwz r9,TI_FLAGS(r12)
Here.
You can probably just move the rlwinm down as you moved the mr.
Note that I've been wondering wether we should attempt to trace all
those IRQ state change internally to the exception code. I've looked at
not doing it, which simplifies things a bit.
Unfortunately, that will make us occasionally trace redundant
enable/disable (which isn't a big problem per-se, just counters).
The idea is that I only kept the trace of disable in transfer_to_handler
and I modified the enable tracing in restore: moved it lower down, and
made it test for _MSR(r1):MSR_EE. I added a trace_irq_off just before
the preempt_schedule_irq() as well.
Anyway, let me know what you think.
Cheers,
Ben.
^ permalink raw reply
* Patches added to powerpc.git powerpc-next and master branches
From: Paul Mackerras @ 2008-04-07 5:52 UTC (permalink / raw)
To: linuxppc-dev
The following patches have been added to the master and powerpc-next
branches of the powerpc.git repository. There is a bunch that I
pulled from Josh Boyer's tree plus others that I have committed.
Paul.
Grant Likely (2):
[POWERPC] add target for building .dtb files
[POWERPC] bootwrapper: Add a firmware-independent simpleboot target.
Ionut Nicu (1):
[POWERPC] Fix kernel panic in arch_arm_kprobe
Josh Boyer (2):
[POWERPC] 4xx: Add Canyonlands and Yosemite to multi-board defconfig
[POWERPC] Add of_device_is_available function
Nathan Lynch (1):
[POWERPC] Convert pci and eeh code to of_device_is_available
Robert P. J. Day (1):
[POWERPC] Use __SPIN_LOCK_UNLOCKED macro in mpc52xx_set_psc_clkdiv
Roel Kluin (1):
[POWERPC] Replace logical-AND by bit-AND in pci_process_ISA_OF_ranges()
Stefan Roese (5):
[POWERPC] 4xx: Only reset PCIe PHY on 405EX systems when no link is detected
[POWERPC] 4xx: Fix PESDRn_UTLSET1 register setup on 460EX/GT
[POWERPC] 4xx: Create common ppc4xx_reset_system() in ppc4xx_soc.c
[POWERPC] 4xx: Some EMAC related changes in Canyonlands & Glacier dts files
[POWERPC] 4xx: Change dts files to support jumbo frames
Stephen Neuendorffer (1):
[POWERPC] of_serial: Fix possible null dereference.
Stephen Rothwell (2):
[POWERPC] htab_remove_mapping is only used by MEMORY_HOTPLUG
[POWERPC] Remove CONFIG_PCI_LEGACY from some configs
Steven Rostedt (1):
[POWERPC] Add hand-coded assembly strcmp
Timur Tabi (1):
[POWERPC] Enable CONFIG_FORCE_MAX_ZONEORDER for all PowerPC, and make selectable
Valentine Barshak (1):
[POWERPC] 4xx: Use machine_device_initcall() for warp_nand
^ permalink raw reply
* Re: [PATCH] [POWERPC] Update linker script to properly set physical addresses
From: Paul Mackerras @ 2008-04-07 6:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0804030128170.15263@blarg.am.freescale.net>
Kumar Gala writes:
> We can set LOAD_OFFSET and use the AT attribute on sections and the
> linker will properly set the physical address of the LOAD program
> header for us.
Nice...
> #define KERNELBASE ASM_CONST(CONFIG_KERNEL_START)
> #define PAGE_OFFSET ASM_CONST(CONFIG_PAGE_OFFSET)
> +#define LOAD_OFFSET ASM_CONST((CONFIG_KERNEL_START-CONFIG_PHYSICAL_START))
I think this should be CONFIG_PAGE_OFFSET - CONFIG_PHYSICAL_START
though.
Paul.
^ permalink raw reply
* Re: Patches added to powerpc.git powerpc-next and master branches
From: David Miller @ 2008-04-07 6:22 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <18425.46732.651483.504040@cargo.ozlabs.ibm.com>
From: Paul Mackerras <paulus@samba.org>
Date: Mon, 7 Apr 2008 15:52:12 +1000
> The following patches have been added to the master and powerpc-next
> branches of the powerpc.git repository. There is a bunch that I
> pulled from Josh Boyer's tree plus others that I have committed.
Please let me know if you're going to require that I fix a bug that
already exists in the LMB code just to get my NUMA node LMB allocation
support patch in.
Please be straightforward and don't just drop the patch quietly in
situations like this, let me know what you want to happen in order to
add the change.
^ permalink raw reply
* Re:Boot freezes at memset_io in early_init
From: Deepak Gaur @ 2008-04-07 6:37 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]
Hi all,
While booting MVL linux on MPC8560 based board the kernel goes into a
infinite loop in setup.c
arch/ppc/kernel/head_fsl_booke.S
------------------------------------
bl early_init
arch/ppc/kernel/setup.c
----------------------------------------
unsigned long
early_init(int r3, int r4, int r5)
{
unsigned long phys;
unsigned long offset = reloc_offset();
/* Default */
phys = offset + KERNELBASE;
/* First zero the BSS -- use memset, some arches don't have
* caches on yet */
memset_io(PTRRELOC(&__bss_start), 0, _end - __bss_start);
__bss_start is 0xc039b00 and __bss_stop = _end =c03c7d90 _end
Please anyone give me some pointers to understand this i.e use of
PTRRELOC and REASON BEHIND clearing area from __bss_start to _end -
__bss_start even though lot of symbols and functions are defined here(as per
System.map)
System.map
---------------------
c039b000 A __bss_start
c039b000 A __chrp_begin
c039b000 A __chrp_end
c039b000 A __init_end
c039b000 A __openfirmware_begin
c039b000 A __openfirmware_end
c039b000 A __pmac_begin
c039b000 A __pmac_end
c039b000 A __prep_begin
c039b000 A __prep_end
c039b000 B system_state
c039b004 B late_time_init
c039b008 b execute_command
c039b00c b panic_later
c039b010 b panic_param
c039b014 B Version_132618
.....
.....
c03c4458 B ic_nameservers
c03c4464 B unix_socket_table
c03c4464 B unix_table_lock
c03c4868 b auth_domain_table
c03c4868 b authtab_lock
c03c4868 b packet_sklist_lock
c03c4868 b rpc_credcache_lock
c03c4868 b rpc_queue_lock
c03c4868 b rpc_sched_lock
c03c4968 b ip_table
c03c4d68 b pmap_lock
c03c4d68 b pmap_stats
c03c4d90 b cache_defer_hash
c03c4d90 b cache_defer_lock
c03c4d90 b cache_list_lock
c03c4d90 b queue_lock
c03c5d90 b write_buf
c03c7d90 A __bss_stop
c03c7d90 A _end
Thanks,
Deepak Gaur
[-- Attachment #2: Type: text/html, Size: 2446 bytes --]
^ permalink raw reply
* MVL Linux on MPC8560 Booting goes into infinite loop in early_init memset_io ( )
From: Deepak Gaur @ 2008-04-07 6:49 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
While booting MVL linux on MPC8560 based board the kernel goes into a infinite loop in
setup.c. The uncompressed image is located at 0x00000000 and is booted from 0x00000000
arch/ppc/kernel/head_fsl_booke.S
------------------------------------
bl early_init
arch/ppc/kernel/setup.c
----------------------------------------
unsigned long
early_init(int r3, int r4, int r5)
{
unsigned long phys;
unsigned long offset = reloc_offset();
/* Default */
phys = offset + KERNELBASE;
/* First zero the BSS -- use memset, some arches don't have
* caches on yet */
memset_io(PTRRELOC(&__bss_start), 0, _end - __bss_start);
__bss_start is 0xc039b00 and __bss_stop = _end =c03c7d90 _end
Please anyone give me some pointers to understand this i.e use of PTRRELOC and
REASON BEHIND clearing area from __bss_start to _end - __bss_start even though lot of
symbols and functions are defined here(as per System.map)
System.map
---------------------
c039b000 A __bss_start
c039b000 A __chrp_begin
c039b000 A __chrp_end
c039b000 A __init_end
c039b000 A __openfirmware_begin
c039b000 A __openfirmware_end
c039b000 A __pmac_begin
c039b000 A __pmac_end
c039b000 A __prep_begin
c039b000 A __prep_end
c039b000 B system_state
c039b004 B late_time_init
c039b008 b execute_command
c039b00c b panic_later
c039b010 b panic_param
c039b014 B Version_132618
.....
.....
c03c4458 B ic_nameservers
c03c4464 B unix_socket_table
c03c4464 B unix_table_lock
c03c4868 b auth_domain_table
c03c4868 b authtab_lock
c03c4868 b packet_sklist_lock
c03c4868 b rpc_credcache_lock
c03c4868 b rpc_queue_lock
c03c4868 b rpc_sched_lock
c03c4968 b ip_table
c03c4d68 b pmap_lock
c03c4d68 b pmap_stats
c03c4d90 b cache_defer_hash
c03c4d90 b cache_defer_lock
c03c4d90 b cache_list_lock
c03c4d90 b queue_lock
c03c5d90 b write_buf
c03c7d90 A __bss_stop
c03c7d90 A _end
Thanks,
Deepak Gaur
^ permalink raw reply
* Kilauea: kernel hangs when using ARCH=powerpc
From: Bernhard Weirich @ 2008-04-07 10:03 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 534 bytes --]
Hello!
When I build the kernel for my kilauea board using ARCH=ppc everything
works fine.
Since ppc is deprecated I'd like to switch to powerpc, but if I do so
the kernel does not produce any output.
There is just the last line of the prompt from the bootloader.
In both cases I built with kilauea_defconfig
I tried the Denx ELDK (4.2) compiler 4.2.2, the toolchain generated by
Buildroot and different kernel versions from the denx repository.
The Kilauea board is Version 1.11b.
Any ideas what is going wrong?
Thanks!
Bernhard
[-- Attachment #2: Type: text/html, Size: 823 bytes --]
^ permalink raw reply
* Re: Patches added to powerpc.git powerpc-next and master branches
From: Paul Mackerras @ 2008-04-07 12:25 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20080406.232220.69225114.davem@davemloft.net>
David Miller writes:
> Please let me know if you're going to require that I fix a bug that
> already exists in the LMB code just to get my NUMA node LMB allocation
> support patch in.
My thought was to put your patch in as-is with another patch to fix
the existing bug either immediately before it or immediately after
it. I started reading through lmb.c again today but got distracted by
some other things. It looks like lmb.c could use a bit of a coding
style cleanup, if nothing else.
> Please be straightforward and don't just drop the patch quietly in
> situations like this, let me know what you want to happen in order to
> add the change.
I haven't dropped it, it's just that I haven't got through all of the
patches for .26 yet.
Paul.
^ permalink raw reply
* [PATCH] IB/ehca: extend query_device() and query_port() to support all values for ibv_devinfo
From: Stefan Roscher @ 2008-04-07 12:57 UTC (permalink / raw)
To: ewg, general, linux-kernel, linuxppc-dev, rolandd; +Cc: fenkes, raisch
Also, introduce a few inline helper functions to make the code more readable.
Signed-off-by: Stefan Roscher <stefan.roscher@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_hca.c | 128 ++++++++++++++++++++------------
1 files changed, 80 insertions(+), 48 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_hca.c b/drivers/infiniband/hw/ehca/ehca_hca.c
index 8832123..f89c5f8 100644
--- a/drivers/infiniband/hw/ehca/ehca_hca.c
+++ b/drivers/infiniband/hw/ehca/ehca_hca.c
@@ -43,6 +43,11 @@
#include "ehca_iverbs.h"
#include "hcp_if.h"
+static inline unsigned int limit_uint(unsigned int value)
+{
+ return min_t(unsigned int, value, INT_MAX);
+}
+
int ehca_query_device(struct ib_device *ibdev, struct ib_device_attr *props)
{
int i, ret = 0;
@@ -83,37 +88,40 @@ int ehca_query_device(struct ib_device *ibdev, struct ib_device_attr *props)
props->vendor_id = rblock->vendor_id >> 8;
props->vendor_part_id = rblock->vendor_part_id >> 16;
props->hw_ver = rblock->hw_ver;
- props->max_qp = min_t(unsigned, rblock->max_qp, INT_MAX);
- props->max_qp_wr = min_t(unsigned, rblock->max_wqes_wq, INT_MAX);
- props->max_sge = min_t(unsigned, rblock->max_sge, INT_MAX);
- props->max_sge_rd = min_t(unsigned, rblock->max_sge_rd, INT_MAX);
- props->max_cq = min_t(unsigned, rblock->max_cq, INT_MAX);
- props->max_cqe = min_t(unsigned, rblock->max_cqe, INT_MAX);
- props->max_mr = min_t(unsigned, rblock->max_mr, INT_MAX);
- props->max_mw = min_t(unsigned, rblock->max_mw, INT_MAX);
- props->max_pd = min_t(unsigned, rblock->max_pd, INT_MAX);
- props->max_ah = min_t(unsigned, rblock->max_ah, INT_MAX);
- props->max_fmr = min_t(unsigned, rblock->max_mr, INT_MAX);
+ props->max_qp = limit_uint(rblock->max_qp);
+ props->max_qp_wr = limit_uint(rblock->max_wqes_wq);
+ props->max_sge = limit_uint(rblock->max_sge);
+ props->max_sge_rd = limit_uint(rblock->max_sge_rd);
+ props->max_cq = limit_uint(rblock->max_cq);
+ props->max_cqe = limit_uint(rblock->max_cqe);
+ props->max_mr = limit_uint(rblock->max_mr);
+ props->max_mw = limit_uint(rblock->max_mw);
+ props->max_pd = limit_uint(rblock->max_pd);
+ props->max_ah = limit_uint(rblock->max_ah);
+ props->max_ee = limit_uint(rblock->max_rd_ee_context);
+ props->max_rdd = limit_uint(rblock->max_rd_domain);
+ props->max_fmr = limit_uint(rblock->max_mr);
+ props->local_ca_ack_delay = limit_uint(rblock->local_ca_ack_delay);
+ props->max_qp_rd_atom = limit_uint(rblock->max_rr_qp);
+ props->max_ee_rd_atom = limit_uint(rblock->max_rr_ee_context);
+ props->max_res_rd_atom = limit_uint(rblock->max_rr_hca);
+ props->max_qp_init_rd_atom = limit_uint(rblock->max_act_wqs_qp);
+ props->max_ee_init_rd_atom = limit_uint(rblock->max_act_wqs_ee_context);
if (EHCA_BMASK_GET(HCA_CAP_SRQ, shca->hca_cap)) {
- props->max_srq = props->max_qp;
- props->max_srq_wr = props->max_qp_wr;
+ props->max_srq = limit_uint(props->max_qp);
+ props->max_srq_wr = limit_uint(props->max_qp_wr);
props->max_srq_sge = 3;
}
- props->max_pkeys = 16;
- props->local_ca_ack_delay
- = rblock->local_ca_ack_delay;
- props->max_raw_ipv6_qp
- = min_t(unsigned, rblock->max_raw_ipv6_qp, INT_MAX);
- props->max_raw_ethy_qp
- = min_t(unsigned, rblock->max_raw_ethy_qp, INT_MAX);
- props->max_mcast_grp
- = min_t(unsigned, rblock->max_mcast_grp, INT_MAX);
- props->max_mcast_qp_attach
- = min_t(unsigned, rblock->max_mcast_qp_attach, INT_MAX);
+ props->max_pkeys = 16;
+ props->local_ca_ack_delay = limit_uint(rblock->local_ca_ack_delay);
+ props->max_raw_ipv6_qp = limit_uint(rblock->max_raw_ipv6_qp);
+ props->max_raw_ethy_qp = limit_uint(rblock->max_raw_ethy_qp);
+ props->max_mcast_grp = limit_uint(rblock->max_mcast_grp);
+ props->max_mcast_qp_attach = limit_uint(rblock->max_mcast_qp_attach);
props->max_total_mcast_qp_attach
- = min_t(unsigned, rblock->max_total_mcast_qp_attach, INT_MAX);
+ = limit_uint(rblock->max_total_mcast_qp_attach);
/* translate device capabilities */
props->device_cap_flags = IB_DEVICE_SYS_IMAGE_GUID |
@@ -128,6 +136,46 @@ query_device1:
return ret;
}
+static inline int map_mtu(struct ehca_shca *shca, u32 fw_mtu)
+{
+ switch (fw_mtu) {
+ case 0x1:
+ return IB_MTU_256;
+ case 0x2:
+ return IB_MTU_512;
+ case 0x3:
+ return IB_MTU_1024;
+ case 0x4:
+ return IB_MTU_2048;
+ case 0x5:
+ return IB_MTU_4096;
+ default:
+ ehca_err(&shca->ib_device, "Unknown MTU size: %x.",
+ fw_mtu);
+ return 0;
+ }
+}
+
+static inline int map_number_of_vls(struct ehca_shca *shca, u32 vl_cap)
+{
+ switch (vl_cap) {
+ case 0x1:
+ return 1;
+ case 0x2:
+ return 2;
+ case 0x3:
+ return 4;
+ case 0x4:
+ return 8;
+ case 0x5:
+ return 15;
+ default:
+ ehca_err(&shca->ib_device, "invalid Vl Capability: %x.",
+ vl_cap);
+ return 0;
+ }
+}
+
int ehca_query_port(struct ib_device *ibdev,
u8 port, struct ib_port_attr *props)
{
@@ -152,31 +200,14 @@ int ehca_query_port(struct ib_device *ibdev,
memset(props, 0, sizeof(struct ib_port_attr));
- switch (rblock->max_mtu) {
- case 0x1:
- props->active_mtu = props->max_mtu = IB_MTU_256;
- break;
- case 0x2:
- props->active_mtu = props->max_mtu = IB_MTU_512;
- break;
- case 0x3:
- props->active_mtu = props->max_mtu = IB_MTU_1024;
- break;
- case 0x4:
- props->active_mtu = props->max_mtu = IB_MTU_2048;
- break;
- case 0x5:
- props->active_mtu = props->max_mtu = IB_MTU_4096;
- break;
- default:
- ehca_err(&shca->ib_device, "Unknown MTU size: %x.",
- rblock->max_mtu);
- break;
- }
-
+ props->active_mtu = props->max_mtu = map_mtu(shca, rblock->max_mtu);
props->port_cap_flags = rblock->capability_mask;
props->gid_tbl_len = rblock->gid_tbl_len;
- props->max_msg_sz = rblock->max_msg_sz;
+ if (rblock->max_msg_sz) {
+ props->max_msg_sz = rblock->max_msg_sz;
+ } else {
+ props->max_msg_sz = 0x1 << 31;
+ }
props->bad_pkey_cntr = rblock->bad_pkey_cntr;
props->qkey_viol_cntr = rblock->qkey_viol_cntr;
props->pkey_tbl_len = rblock->pkey_tbl_len;
@@ -186,6 +217,7 @@ int ehca_query_port(struct ib_device *ibdev,
props->sm_sl = rblock->sm_sl;
props->subnet_timeout = rblock->subnet_timeout;
props->init_type_reply = rblock->init_type_reply;
+ props->max_vl_num = map_number_of_vls(shca, rblock->vl_cap);
if (rblock->state && rblock->phys_width) {
props->phys_state = rblock->phys_pstate;
--
1.5.2
^ permalink raw reply related
* Re: [PATCH] [POWERPC] Update linker script to properly set physical addresses
From: Kumar Gala @ 2008-04-07 13:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18425.47270.756180.55444@cargo.ozlabs.ibm.com>
On Apr 7, 2008, at 1:01 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> We can set LOAD_OFFSET and use the AT attribute on sections and the
>> linker will properly set the physical address of the LOAD program
>> header for us.
>
> Nice...
>
>> #define KERNELBASE ASM_CONST(CONFIG_KERNEL_START)
>> #define PAGE_OFFSET ASM_CONST(CONFIG_PAGE_OFFSET)
>> +#define LOAD_OFFSET ASM_CONST((CONFIG_KERNEL_START-
>> CONFIG_PHYSICAL_START))
>
> I think this should be CONFIG_PAGE_OFFSET - CONFIG_PHYSICAL_START
> though.
Disagree (assuming I'm thinking straight first thing in the morning).
PAGE_OFFSET is virt address of the beginning of memory, where
KERNEL_START is virt address of start of kernel text.
PHYSICAL_START is physical address of KERNEL_START.
(I tried to match x86's definitions here as per Milton's request to be
consistent).
- k
^ 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