* Re: [PATCH add immr alias 1/4] powerpc: Teach get_immrbase to use immr alias if it exists.
From: Grant Likely @ 2008-08-05 21:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, devicetree-discuss, John Rigby, Arnd Bergmann
In-Reply-To: <4898BCD3.5050703@freescale.com>
On Tue, Aug 5, 2008 at 2:49 PM, Scott Wood <scottwood@freescale.com> wrote:
> Arnd Bergmann wrote:
>>
>> On Tuesday 05 August 2008, John Rigby wrote:
>>>
>>> This will allow the eventual removal of device_type = "soc"
>>> properties in soc nodes.
>>
>> Stupid question, but why not remove immrbase instead?
>>
>> It seems that all users can be converted to use a reg
>> property of some actual device instead of making assumptions
>> about the register layout of the whole SOC.
>
> That wouldn't eliminate the need for the alias, though -- u-boot needs to
> find the node to fill in properties.
(already made this comment on one of the later patches, but it is more
relevant here...)
I don't think that using aliases is the best solution. I'd rather see
U-Boot search for the appropriate compatible value for the IMMR node.
g.
>
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH add immr alias 2/4] powerpc: 5121: Add immr alias to MPC5121 ADS device tree.
From: Grant Likely @ 2008-08-05 21:05 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <fa686aa40808051405j7268c216j8e5b526d6ad526c9@mail.gmail.com>
Oops, forgot to add devicetree-discuss to the cc: list
g.
On Tue, Aug 5, 2008 at 3:05 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Tue, Aug 5, 2008 at 2:13 PM, John Rigby <jrigby@freescale.com> wrote:
>> So get_immrbase can function without a device_type = "soc"
>> property in the soc node.
>>
>> The "soc" node should really be named "immr"
>> because it does not include the entire soc, however
>> u-boot currently looks up this node by name for
>> a clock fixup so leave it "soc" for now. We will change
>> it later after 5121 u-boot uses the immr alias instead
>> of the node name.
>
> Is it not sufficient to search the tree for a node with the
> <chip>-immr compatible value? I don't think this is the intended use
> case of aliases.
>
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH add immr alias 2/4] powerpc: 5121: Add immr alias to MPC5121 ADS device tree.
From: Grant Likely @ 2008-08-05 21:05 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev
In-Reply-To: <1217967220-30557-2-git-send-email-jrigby@freescale.com>
On Tue, Aug 5, 2008 at 2:13 PM, John Rigby <jrigby@freescale.com> wrote:
> So get_immrbase can function without a device_type = "soc"
> property in the soc node.
>
> The "soc" node should really be named "immr"
> because it does not include the entire soc, however
> u-boot currently looks up this node by name for
> a clock fixup so leave it "soc" for now. We will change
> it later after 5121 u-boot uses the immr alias instead
> of the node name.
Is it not sufficient to search the tree for a node with the
<chip>-immr compatible value? I don't think this is the intended use
case of aliases.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH add immr alias 1/4] powerpc: Teach get_immrbase to use immr alias if it exists.
From: Kumar Gala @ 2008-08-05 20:50 UTC (permalink / raw)
To: John Rigby; +Cc: Scott Wood, linuxppc-dev list, Arnd Bergmann
In-Reply-To: <4898BCD3.5050703@freescale.com>
On Aug 5, 2008, at 3:49 PM, Scott Wood wrote:
> Arnd Bergmann wrote:
>> On Tuesday 05 August 2008, John Rigby wrote:
>>> This will allow the eventual removal of device_type = "soc"
>>> properties in soc nodes.
>> Stupid question, but why not remove immrbase instead?
>> It seems that all users can be converted to use a reg
>> property of some actual device instead of making assumptions
>> about the register layout of the whole SOC.
>
> That wouldn't eliminate the need for the alias, though -- u-boot
> needs to find the node to fill in properties.
While I have no issue with the change. I'm interested to see how John
plans on using this in u-boot.
- k
^ permalink raw reply
* Re: [PATCH add immr alias 1/4] powerpc: Teach get_immrbase to use immr alias if it exists.
From: Scott Wood @ 2008-08-05 20:49 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, John Rigby
In-Reply-To: <200808052243.24001.arnd@arndb.de>
Arnd Bergmann wrote:
> On Tuesday 05 August 2008, John Rigby wrote:
>> This will allow the eventual removal of device_type = "soc"
>> properties in soc nodes.
>
> Stupid question, but why not remove immrbase instead?
>
> It seems that all users can be converted to use a reg
> property of some actual device instead of making assumptions
> about the register layout of the whole SOC.
That wouldn't eliminate the need for the alias, though -- u-boot needs
to find the node to fill in properties.
-Scott
^ permalink raw reply
* Re: [PATCH add immr alias 1/4] powerpc: Teach get_immrbase to use immr alias if it exists.
From: Arnd Bergmann @ 2008-08-05 20:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: John Rigby
In-Reply-To: <1217967220-30557-1-git-send-email-jrigby@freescale.com>
On Tuesday 05 August 2008, John Rigby wrote:
> This will allow the eventual removal of device_type = "soc"
> properties in soc nodes.
Stupid question, but why not remove immrbase instead?
It seems that all users can be converted to use a reg
property of some actual device instead of making assumptions
about the register layout of the whole SOC.
Arnd <><
^ permalink raw reply
* [PATCH add immr alias 4/4] powerpc: 8[56]xx: Add immr aliases to 8[56]xx device trees
From: John Rigby @ 2008-08-05 20:13 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1217967220-30557-3-git-send-email-jrigby@freescale.com>
Now that get_immrbase knows about immr aliases.
Some chip docs call this ccsr for 8[56]xx platforms
but we stick with immr for consistency across 8xxx.
Signed-off-by: John Rigby <jrigby@freescale.com>
---
arch/powerpc/boot/dts/ksi8560.dts | 3 ++-
arch/powerpc/boot/dts/mpc8536ds.dts | 3 ++-
arch/powerpc/boot/dts/mpc8540ads.dts | 3 ++-
arch/powerpc/boot/dts/mpc8541cds.dts | 3 ++-
arch/powerpc/boot/dts/mpc8544ds.dts | 3 ++-
arch/powerpc/boot/dts/mpc8548cds.dts | 3 ++-
arch/powerpc/boot/dts/mpc8555cds.dts | 3 ++-
arch/powerpc/boot/dts/mpc8560ads.dts | 3 ++-
arch/powerpc/boot/dts/mpc8568mds.dts | 3 ++-
arch/powerpc/boot/dts/mpc8572ds.dts | 3 ++-
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 3 ++-
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 3 ++-
arch/powerpc/boot/dts/mpc866ads.dts | 6 +++++-
arch/powerpc/boot/dts/mpc885ads.dts | 6 +++++-
arch/powerpc/boot/dts/sbc8548.dts | 3 ++-
arch/powerpc/boot/dts/sbc8560.dts | 3 ++-
arch/powerpc/boot/dts/sbc8641d.dts | 3 ++-
arch/powerpc/boot/dts/stx_gp3_8560.dts | 3 ++-
arch/powerpc/boot/dts/tqm8540.dts | 3 ++-
arch/powerpc/boot/dts/tqm8541.dts | 3 ++-
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 4 +++-
arch/powerpc/boot/dts/tqm8548.dts | 4 +++-
arch/powerpc/boot/dts/tqm8555.dts | 3 ++-
arch/powerpc/boot/dts/tqm8560.dts | 3 ++-
24 files changed, 56 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/boot/dts/ksi8560.dts b/arch/powerpc/boot/dts/ksi8560.dts
index 4973758..9d3e560 100644
--- a/arch/powerpc/boot/dts/ksi8560.dts
+++ b/arch/powerpc/boot/dts/ksi8560.dts
@@ -24,6 +24,7 @@
ethernet0 = &enet0;
ethernet1 = &enet1;
ethernet2 = &enet2;
+ immr = &immr;
};
cpus {
@@ -49,7 +50,7 @@
reg = <0x00000000 0x10000000>; /* Fixed by bootwrapper */
};
- soc@fdf00000 {
+ immr: soc@fdf00000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8536ds.dts b/arch/powerpc/boot/dts/mpc8536ds.dts
index 1505d68..0d28ff4 100644
--- a/arch/powerpc/boot/dts/mpc8536ds.dts
+++ b/arch/powerpc/boot/dts/mpc8536ds.dts
@@ -26,6 +26,7 @@
pci1 = &pci1;
pci2 = &pci2;
pci3 = &pci3;
+ immr = &immr;
};
cpus {
@@ -45,7 +46,7 @@
reg = <00000000 00000000>; // Filled by U-Boot
};
- soc@ffe00000 {
+ immr: soc@ffe00000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8540ads.dts b/arch/powerpc/boot/dts/mpc8540ads.dts
index 9568bfa..1f32d2f 100644
--- a/arch/powerpc/boot/dts/mpc8540ads.dts
+++ b/arch/powerpc/boot/dts/mpc8540ads.dts
@@ -24,6 +24,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -49,7 +50,7 @@
reg = <0x0 0x8000000>; // 128M at 0x0
};
- soc8540@e0000000 {
+ immr: soc8540@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8541cds.dts b/arch/powerpc/boot/dts/mpc8541cds.dts
index 6480f4f..e5fb2d1 100644
--- a/arch/powerpc/boot/dts/mpc8541cds.dts
+++ b/arch/powerpc/boot/dts/mpc8541cds.dts
@@ -24,6 +24,7 @@
serial1 = &serial1;
pci0 = &pci0;
pci1 = &pci1;
+ immr = &immr;
};
cpus {
@@ -49,7 +50,7 @@
reg = <0x0 0x8000000>; // 128M at 0x0
};
- soc8541@e0000000 {
+ immr: soc8541@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts b/arch/powerpc/boot/dts/mpc8544ds.dts
index f1fb207..0814730 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
+++ b/arch/powerpc/boot/dts/mpc8544ds.dts
@@ -25,6 +25,7 @@
pci1 = &pci1;
pci2 = &pci2;
pci3 = &pci3;
+ immr = &immr;
};
cpus {
@@ -50,7 +51,7 @@
reg = <0x0 0x0>; // Filled by U-Boot
};
- soc8544@e0000000 {
+ immr: soc8544@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8548cds.dts b/arch/powerpc/boot/dts/mpc8548cds.dts
index 431b496..71ff390 100644
--- a/arch/powerpc/boot/dts/mpc8548cds.dts
+++ b/arch/powerpc/boot/dts/mpc8548cds.dts
@@ -29,6 +29,7 @@
pci0 = &pci0;
pci1 = &pci1;
pci2 = &pci2;
+ immr = &immr;
};
cpus {
@@ -54,7 +55,7 @@
reg = <0x0 0x8000000>; // 128M at 0x0
};
- soc8548@e0000000 {
+ immr: soc8548@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8555cds.dts b/arch/powerpc/boot/dts/mpc8555cds.dts
index d833a5c..6b2eaa1 100644
--- a/arch/powerpc/boot/dts/mpc8555cds.dts
+++ b/arch/powerpc/boot/dts/mpc8555cds.dts
@@ -24,6 +24,7 @@
serial1 = &serial1;
pci0 = &pci0;
pci1 = &pci1;
+ immr = &immr;
};
cpus {
@@ -49,7 +50,7 @@
reg = <0x0 0x8000000>; // 128M at 0x0
};
- soc8555@e0000000 {
+ immr: soc8555@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8560ads.dts b/arch/powerpc/boot/dts/mpc8560ads.dts
index 4d1f2f2..ff118e3 100644
--- a/arch/powerpc/boot/dts/mpc8560ads.dts
+++ b/arch/powerpc/boot/dts/mpc8560ads.dts
@@ -25,6 +25,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -49,7 +50,7 @@
reg = <0x0 0x10000000>;
};
- soc8560@e0000000 {
+ immr: soc8560@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index a15f103..83a2d36 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -26,6 +26,7 @@
serial1 = &serial1;
pci0 = &pci0;
pci1 = &pci1;
+ immr = &immr;
};
cpus {
@@ -56,7 +57,7 @@
reg = <0xf8000000 0x8000>;
};
- soc8568@e0000000 {
+ immr: soc8568@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8572ds.dts b/arch/powerpc/boot/dts/mpc8572ds.dts
index e124dd1..f97045a 100644
--- a/arch/powerpc/boot/dts/mpc8572ds.dts
+++ b/arch/powerpc/boot/dts/mpc8572ds.dts
@@ -26,6 +26,7 @@
pci0 = &pci0;
pci1 = &pci1;
pci2 = &pci2;
+ immr = &immr;
};
cpus {
@@ -64,7 +65,7 @@
reg = <0x0 0x0>; // Filled by U-Boot
};
- soc8572@ffe00000 {
+ immr: soc8572@ffe00000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 666185f..67f252f 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -22,6 +22,7 @@
pci0 = &pci0;
pci1 = &pci1;
pci2 = &pci2;
+ immr = &immr;
};
cpus {
@@ -46,7 +47,7 @@
reg = <0x00000000 0x20000000>; // 512M at 0x0
};
- localbus@e0005000 {
+ immr: localbus@e0005000 {
#address-cells = <2>;
#size-cells = <1>;
compatible = "fsl,mpc8610-elbc", "fsl,elbc", "simple-bus";
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
index ae08761..4287605 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -27,6 +27,7 @@
pci0 = &pci0;
pci1 = &pci1;
rapidio0 = &rapidio0;
+ immr = &immr;
};
cpus {
@@ -103,7 +104,7 @@
};
};
- soc8641@f8000000 {
+ immr: soc8641@f8000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc866ads.dts b/arch/powerpc/boot/dts/mpc866ads.dts
index bd70065..021068b 100644
--- a/arch/powerpc/boot/dts/mpc866ads.dts
+++ b/arch/powerpc/boot/dts/mpc866ads.dts
@@ -18,6 +18,10 @@
#address-cells = <1>;
#size-cells = <1>;
+ aliases {
+ immr = &immr;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -59,7 +63,7 @@
};
};
- soc@ff000000 {
+ immr: soc@ff000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc885ads.dts b/arch/powerpc/boot/dts/mpc885ads.dts
index b123e9f..daaa180 100644
--- a/arch/powerpc/boot/dts/mpc885ads.dts
+++ b/arch/powerpc/boot/dts/mpc885ads.dts
@@ -18,6 +18,10 @@
#address-cells = <1>;
#size-cells = <1>;
+ aliases {
+ immr = &immr;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -67,7 +71,7 @@
};
};
- soc@ff000000 {
+ immr: soc@ff000000 {
compatible = "fsl,mpc885", "fsl,pq1-soc";
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/powerpc/boot/dts/sbc8548.dts b/arch/powerpc/boot/dts/sbc8548.dts
index 333552b..6bbd50c 100644
--- a/arch/powerpc/boot/dts/sbc8548.dts
+++ b/arch/powerpc/boot/dts/sbc8548.dts
@@ -28,6 +28,7 @@
pci0 = &pci0;
/* pci1 doesn't have a corresponding physical connector */
pci2 = &pci2;
+ immr = &immr;
};
cpus {
@@ -146,7 +147,7 @@
};
};
- soc8548@e0000000 {
+ immr: soc8548@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/sbc8560.dts b/arch/powerpc/boot/dts/sbc8560.dts
index db3632e..f0e7db2 100644
--- a/arch/powerpc/boot/dts/sbc8560.dts
+++ b/arch/powerpc/boot/dts/sbc8560.dts
@@ -27,6 +27,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -52,7 +53,7 @@
reg = <0x00000000 0x20000000>;
};
- soc@ff700000 {
+ immr: soc@ff700000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/sbc8641d.dts b/arch/powerpc/boot/dts/sbc8641d.dts
index 9652456..f98e942 100644
--- a/arch/powerpc/boot/dts/sbc8641d.dts
+++ b/arch/powerpc/boot/dts/sbc8641d.dts
@@ -30,6 +30,7 @@
serial1 = &serial1;
pci0 = &pci0;
pci1 = &pci1;
+ immr = &immr;
};
cpus {
@@ -120,7 +121,7 @@
};
};
- soc@f8000000 {
+ immr: soc@f8000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/stx_gp3_8560.dts b/arch/powerpc/boot/dts/stx_gp3_8560.dts
index fcd1db6..15d1889 100644
--- a/arch/powerpc/boot/dts/stx_gp3_8560.dts
+++ b/arch/powerpc/boot/dts/stx_gp3_8560.dts
@@ -22,6 +22,7 @@
ethernet1 = &enet1;
serial0 = &serial0;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -47,7 +48,7 @@
reg = <0x00000000 0x10000000>;
};
- soc@fdf00000 {
+ immr: soc@fdf00000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/tqm8540.dts b/arch/powerpc/boot/dts/tqm8540.dts
index e1d260b..8f1fda7 100644
--- a/arch/powerpc/boot/dts/tqm8540.dts
+++ b/arch/powerpc/boot/dts/tqm8540.dts
@@ -24,6 +24,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -49,7 +50,7 @@
reg = <0x00000000 0x10000000>;
};
- soc@e0000000 {
+ immr: soc@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/tqm8541.dts b/arch/powerpc/boot/dts/tqm8541.dts
index d76441e..3905e7c 100644
--- a/arch/powerpc/boot/dts/tqm8541.dts
+++ b/arch/powerpc/boot/dts/tqm8541.dts
@@ -23,6 +23,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -48,7 +49,7 @@
reg = <0x00000000 0x10000000>;
};
- soc@e0000000 {
+ immr: soc@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/tqm8548-bigflash.dts b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
index 64d2d5b..f2e7cf8 100644
--- a/arch/powerpc/boot/dts/tqm8548-bigflash.dts
+++ b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
@@ -28,6 +28,8 @@
serial1 = &serial1;
pci0 = &pci0;
pci1 = &pci1;
+
+ immr = &immr;
};
cpus {
@@ -50,7 +52,7 @@
reg = <0x00000000 0x00000000>; // Filled in by U-Boot
};
- soc8548@a0000000 {
+ immr: soc8548@a0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/tqm8548.dts b/arch/powerpc/boot/dts/tqm8548.dts
index 2563112..42ab8b1 100644
--- a/arch/powerpc/boot/dts/tqm8548.dts
+++ b/arch/powerpc/boot/dts/tqm8548.dts
@@ -28,6 +28,8 @@
serial1 = &serial1;
pci0 = &pci0;
pci1 = &pci1;
+
+ immr = &immr;
};
cpus {
@@ -50,7 +52,7 @@
reg = <0x00000000 0x00000000>; // Filled in by U-Boot
};
- soc8548@e0000000 {
+ immr: soc8548@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/tqm8555.dts b/arch/powerpc/boot/dts/tqm8555.dts
index 6f7ea59..76de7bd 100644
--- a/arch/powerpc/boot/dts/tqm8555.dts
+++ b/arch/powerpc/boot/dts/tqm8555.dts
@@ -23,6 +23,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -48,7 +49,7 @@
reg = <0x00000000 0x10000000>;
};
- soc@e0000000 {
+ immr: soc@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/tqm8560.dts b/arch/powerpc/boot/dts/tqm8560.dts
index 3fe3520..1fd6b74 100644
--- a/arch/powerpc/boot/dts/tqm8560.dts
+++ b/arch/powerpc/boot/dts/tqm8560.dts
@@ -25,6 +25,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -50,7 +51,7 @@
reg = <0x00000000 0x10000000>;
};
- soc@e0000000 {
+ immr: soc@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
--
^ permalink raw reply related
* [PATCH add immr alias 3/4] powerpc: 83xx: Add immr aliases to 83xx device trees.
From: John Rigby @ 2008-08-05 20:13 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1217967220-30557-2-git-send-email-jrigby@freescale.com>
Now that get_immrbase knows about immr aliases.
Signed-off-by: John Rigby <jrigby@freescale.com>
---
arch/powerpc/boot/dts/mpc8313erdb.dts | 3 ++-
arch/powerpc/boot/dts/mpc8315erdb.dts | 3 ++-
arch/powerpc/boot/dts/mpc832x_mds.dts | 3 ++-
arch/powerpc/boot/dts/mpc832x_rdb.dts | 3 ++-
arch/powerpc/boot/dts/mpc8349emitx.dts | 3 ++-
arch/powerpc/boot/dts/mpc8349emitxgp.dts | 3 ++-
arch/powerpc/boot/dts/mpc834x_mds.dts | 3 ++-
arch/powerpc/boot/dts/mpc836x_mds.dts | 3 ++-
arch/powerpc/boot/dts/mpc836x_rdk.dts | 3 ++-
arch/powerpc/boot/dts/mpc8377_mds.dts | 3 ++-
arch/powerpc/boot/dts/mpc8377_rdb.dts | 3 ++-
arch/powerpc/boot/dts/mpc8378_mds.dts | 3 ++-
arch/powerpc/boot/dts/mpc8378_rdb.dts | 3 ++-
arch/powerpc/boot/dts/mpc8379_mds.dts | 3 ++-
arch/powerpc/boot/dts/mpc8379_rdb.dts | 3 ++-
arch/powerpc/boot/dts/sbc8349.dts | 3 ++-
16 files changed, 32 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts b/arch/powerpc/boot/dts/mpc8313erdb.dts
index 2a94ae0..3c04cd2 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -23,6 +23,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -94,7 +95,7 @@
};
};
- soc8313@e0000000 {
+ immr: soc8313@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8315erdb.dts b/arch/powerpc/boot/dts/mpc8315erdb.dts
index f704513..3327670 100644
--- a/arch/powerpc/boot/dts/mpc8315erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8315erdb.dts
@@ -22,6 +22,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -92,7 +93,7 @@
};
};
- immr@e0000000 {
+ immr: immr@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts b/arch/powerpc/boot/dts/mpc832x_mds.dts
index fbc9304..a2757b3 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -35,6 +35,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -64,7 +65,7 @@
reg = <0xf8000000 0x8000>;
};
- soc8323@e0000000 {
+ immr: soc8323@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index b157d18..50e0539 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -23,6 +23,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -47,7 +48,7 @@
reg = <0x00000000 0x04000000>;
};
- soc8323@e0000000 {
+ immr: soc8323@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 700e076..ed24c85 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -24,6 +24,7 @@
serial1 = &serial1;
pci0 = &pci0;
pci1 = &pci1;
+ immr = &immr;
};
cpus {
@@ -48,7 +49,7 @@
reg = <0x00000000 0x10000000>;
};
- soc8349@e0000000 {
+ immr: soc8349@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8349emitxgp.dts b/arch/powerpc/boot/dts/mpc8349emitxgp.dts
index cdd3063..24a696d 100644
--- a/arch/powerpc/boot/dts/mpc8349emitxgp.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitxgp.dts
@@ -22,6 +22,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -46,7 +47,7 @@
reg = <0x00000000 0x10000000>;
};
- soc8349@e0000000 {
+ immr: soc8349@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc834x_mds.dts b/arch/powerpc/boot/dts/mpc834x_mds.dts
index 783241c..aad88e1 100644
--- a/arch/powerpc/boot/dts/mpc834x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc834x_mds.dts
@@ -24,6 +24,7 @@
serial1 = &serial1;
pci0 = &pci0;
pci1 = &pci1;
+ immr = &immr;
};
cpus {
@@ -53,7 +54,7 @@
reg = <0xe2400000 0x8000>;
};
- soc8349@e0000000 {
+ immr: soc8349@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts b/arch/powerpc/boot/dts/mpc836x_mds.dts
index a3b76a7..664c371 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -28,6 +28,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -57,7 +58,7 @@
reg = <0xf8000000 0x8000>;
};
- soc8360@e0000000 {
+ immr: soc8360@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc836x_rdk.dts b/arch/powerpc/boot/dts/mpc836x_rdk.dts
index 89c9202..af22122 100644
--- a/arch/powerpc/boot/dts/mpc836x_rdk.dts
+++ b/arch/powerpc/boot/dts/mpc836x_rdk.dts
@@ -29,6 +29,7 @@
ethernet2 = &enet2;
ethernet3 = &enet3;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -55,7 +56,7 @@
reg = <0 0>;
};
- soc@e0000000 {
+ immr: soc@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts b/arch/powerpc/boot/dts/mpc8377_mds.dts
index 432782b..36c5ded 100644
--- a/arch/powerpc/boot/dts/mpc8377_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
@@ -23,6 +23,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -113,7 +114,7 @@
};
};
- soc@e0000000 {
+ immr: soc@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index ed137aa..49465da 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -22,6 +22,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -92,7 +93,7 @@
};
};
- immr@e0000000 {
+ immr: immr@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8378_mds.dts b/arch/powerpc/boot/dts/mpc8378_mds.dts
index ed32c8d..368cad1 100644
--- a/arch/powerpc/boot/dts/mpc8378_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8378_mds.dts
@@ -23,6 +23,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -113,7 +114,7 @@
};
};
- soc@e0000000 {
+ immr: soc@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts b/arch/powerpc/boot/dts/mpc8378_rdb.dts
index 34a7f2f..b6fa64e 100644
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -22,6 +22,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -92,7 +93,7 @@
};
};
- immr@e0000000 {
+ immr: immr@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8379_mds.dts b/arch/powerpc/boot/dts/mpc8379_mds.dts
index f4db9ed..e79d8e5 100644
--- a/arch/powerpc/boot/dts/mpc8379_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8379_mds.dts
@@ -23,6 +23,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -113,7 +114,7 @@
};
};
- soc@e0000000 {
+ immr: soc@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/mpc8379_rdb.dts b/arch/powerpc/boot/dts/mpc8379_rdb.dts
index e4d7030..830a254 100644
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -22,6 +22,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -92,7 +93,7 @@
};
};
- immr@e0000000 {
+ immr: immr@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
diff --git a/arch/powerpc/boot/dts/sbc8349.dts b/arch/powerpc/boot/dts/sbc8349.dts
index 45f789b..efbdd21 100644
--- a/arch/powerpc/boot/dts/sbc8349.dts
+++ b/arch/powerpc/boot/dts/sbc8349.dts
@@ -27,6 +27,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ immr = &immr;
};
cpus {
@@ -51,7 +52,7 @@
reg = <0x00000000 0x10000000>; // 256MB at 0
};
- soc8349@e0000000 {
+ immr: soc8349@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
--
^ permalink raw reply related
* [PATCH add immr alias 2/4] powerpc: 5121: Add immr alias to MPC5121 ADS device tree.
From: John Rigby @ 2008-08-05 20:13 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1217967220-30557-1-git-send-email-jrigby@freescale.com>
So get_immrbase can function without a device_type = "soc"
property in the soc node.
The "soc" node should really be named "immr"
because it does not include the entire soc, however
u-boot currently looks up this node by name for
a clock fixup so leave it "soc" for now. We will change
it later after 5121 u-boot uses the immr alias instead
of the node name.
Signed-off-by: John Rigby <jrigby@freescale.com>
---
arch/powerpc/boot/dts/mpc5121ads.dts | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts b/arch/powerpc/boot/dts/mpc5121ads.dts
index 1f9036c..c52c51d 100644
--- a/arch/powerpc/boot/dts/mpc5121ads.dts
+++ b/arch/powerpc/boot/dts/mpc5121ads.dts
@@ -19,6 +19,7 @@
aliases {
pci = &pci;
+ immr = &immr;
};
cpus {
@@ -135,7 +136,7 @@
};
};
- soc@80000000 {
+ immr: soc@80000000 {
compatible = "fsl,mpc5121-immr";
#address-cells = <1>;
#size-cells = <1>;
--
^ permalink raw reply related
* [PATCH add immr alias 1/4] powerpc: Teach get_immrbase to use immr alias if it exists.
From: John Rigby @ 2008-08-05 20:13 UTC (permalink / raw)
To: linuxppc-dev
This will allow the eventual removal of device_type = "soc"
properties in soc nodes.
Signed-off-by: John Rigby <jrigby@freescale.com>
---
arch/powerpc/sysdev/fsl_soc.c | 25 +++++++++++++++++++++++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 214388e..2643395 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -45,14 +45,35 @@ extern void init_fec_ioports(struct fs_platform_info*);
extern void init_smc_ioports(struct fs_uart_platform_info*);
static phys_addr_t immrbase = -1;
+/*
+ * Some chips call this immr some ccsr, we
+ * use the term immr for both.
+ */
phys_addr_t get_immrbase(void)
{
- struct device_node *soc;
+ struct device_node *soc = NULL;
+ struct device_node *np;
+ const char *path;
+
if (immrbase != -1)
return immrbase;
- soc = of_find_node_by_type(NULL, "soc");
+ /*
+ * First look for an immr alias
+ */
+ np = of_find_node_by_name(NULL, "/aliases");
+ if (np) {
+ path = of_get_property(np, "immr", NULL);
+ if (path)
+ soc = of_find_node_by_name(NULL, path);
+ }
+ /*
+ * If no immr alias then fall back to finding
+ * it by device_type
+ */
+ if (!soc)
+ soc = of_find_node_by_type(NULL, "soc");
if (soc) {
int size;
u32 naddr;
--
^ permalink raw reply related
* Re: to schedule() or not to schedule() ?
From: Kevin Diggs @ 2008-08-05 19:26 UTC (permalink / raw)
To: Chris Friesen; +Cc: linuxppc-dev
In-Reply-To: <48989DFE.7080506@nortel.com>
Chris Friesen wrote:
> Kevin Diggs wrote:
>
>> Hi,
>>
>>
>> I have the following near the top of my cpufreq driver target
>> routine:
>>
>> while(test_and_set_bit(cf750gxmCfgChangeBit,&cf750gxvStateBits)) {
>> /*
>> * Someone mucking with our cfg? (I hope it is ok to call
>> * schedule() here! - truth is I have no idea what I am doing
>> * ... my reasoning is I want to yeild the cpu so whoever is
>> * mucking around can finish)
>> */
>> schedule();
>> }
>>
>> This is to prevent bad things from happening if someone is trying to
>> change a parameter for the driver via sysfs while the target routine
>> is running. Fortunately, because I had a bug where this bit was not
>> getting cleared on one of the paths through the target routine ... I
>> now know it is not safe to call schedule (it got stuck in there -
>> knocked out my adb keyboard! - (I think target is called from a timer
>> that the governor sets up ... interrupt context?)).
>
>
> Is the issue that someone may be in the middle of a multi-stage
> procedure, and you've woken up partway through?
>
> If so, what about simply rescheduling the timer for some short time in
> the future and aborting the current call?
>
> Chris
>
Chris,
Thanks for taking the time to reply. The parameter in question modifies
the frequency table. It is used several times in the target routine.
I've addressed the issue by making a local copy of the frequency table
upon entry to the target routine and use that while there. I don't care
who wins the race.
kevin
^ permalink raw reply
* Re: PCI support on the ML310 (Linux 2.4/2.6)
From: Juliana Su @ 2008-08-05 19:09 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Thanks for your reply, Bin! I checked system.mhs and "C_BRIDGE_IDSEL_ADDR=
_BIT" was set to 16, but the code that was in pci_init( ) was the code fo=
r as if "C_BRIDGE_IDSEL_ADDR_BIT" was set to 24. After replacing the code=
in pci_init( ), the PCI now initializes. However, after the ML310 initia=
lization finishes, the system hangs at "Now booting the kernel". I rememb=
er encountering this problem when I was porting Linux 2.6. It had to do w=
ith a linker problem and after rolling back to gcc-4.0.2, I got past the =
problem. I'm using Linux 2.4, though, so that solution will not work here=
=2E.. I am using UART Lite and I made sure that it (and not UART 16550) w=
as selected in the kernel configuration and that "Console on UART Lite po=
rt" was selected as well. I also made sure that UART Lite was what was ch=
osen when I built the BSP. Oh, and there is a /dev/ttyUL0 device node in =
my root file system. I even did a "make mrproper" and re-did the kernel c=
onfiguration, but that did not solve my problem. Any suggestions? Thanks!=
-Juliana
Xilinx ML310 Board-Specific Initialization: =
=20
=
=20
ppb_init: dev =3D 9, id =3D ac23104c =
=20
pci_scan: bus 0, device 0, id 030010ee =
=20
pci_scan: bus 0, device 1, id 545110b9 =
=20
pci_scan: bus 0, device 2, id 153310b9 =
=20
pci_scan: bus 0, device 3, id 545710b9 =
=20
pci_scan: bus 0, device 7, id 12298086 =
=20
pci_scan: bus 0, device 9, id ac23104c =
=20
pci_scan: bus 0, device 12, id 710110b9 =
=20
pci_scan: bus 0, device 15, id 523710b9 =
=20
sio_init: Device ID =3D 53 15, Revision =3D f3. =
=20
sio_init: LPT1 base =3D 0x0378, irq =3D 5. =
=20
sio_init: COM1 base =3D 0x03f8, irq =3D 4. =
=20
sio_init: COM2 base =3D 0x02f8, irq =3D 3. =
=20
sio_init: KBC irq =3D 1, PS2 irq =3D 1. =
=20
sio_init: Super I/O initialization complete. =
=20
=
=20
loaded at: 00400000 004E91F4 =
=20
board data at: 004E613C 004E6154 =
=20
relocated to: 00406410 00406428 =
=20
zimage at: 00406BF9 004E5566 =
=20
avail ram: 004EA000 08000000 =
=20
=
=20
Linux/PPC load: console=3DttyUL0,9600 ip=3Doff root=3D/dev/xsysace/disc0/=
part2 rw =20
Uncompressing Linux...done. =
=20
Now booting the kernel =20
------------------------------
Message: 11
Date: Tue, 5 Aug 2008 12:48:29 -0400
From: "Huang, Bin" <bhuang2@uncc.edu>
Subject: re ?PCI support on the ML310 (Linux 2.4/2.6)
To: <linuxppc-embedded@ozlabs.org>
Message-ID:
<61B0EE7C247C1349881F63414448FC1F920F25@EXEVS06.its.uncc.edu>
Content-Type: text/plain; charset=3D"gb2312"
As far as I know, only MVista has complete PCI support for ML310. I have =
=20
been migrating their PCI stuff to 2.6 kernel for couple of months so I mi=
ght =20
understand what you are suffering here.=20
If your system hangs just after "Xilinx ML310 Board-Specific =20
Initialization:", then probably there is something wrong with your OPB-PC=
I =20
core on virtex-2 FPGA. I highly recommend you double check the value of =
"C_BRIDGE_IDSEL_ADDR_BIT" within your system.mhs file.=20
When the 2.4/2.6 kernel tries to initialize pci core, it has to do self- =
configuration first. If the wrong address is assigned in pci_init(), then=
=20
the kernel could not proceed any more.=20
Here is what you need to take care of:=20
for C_BRIDGE_IDSEL_ADDR_BIT =3D 24, use=20
pci_init()
{
/* self-configuration */
WR32(PCI_CONFIG_ADDR, htole32(0x80004004)); // address
WR32(PCI_CONFIG_DATA, htole32(0xffff0147)); // data
/* max latency timer on bridge */
WR32(PCI_CONFIG_ADDR, htole32(0x8000400c)); // address
WR32(PCI_CONFIG_DATA, htole32(0x0000ff00)); // data
/* max bus number */
WR32(PCI_CONFIG_ADDR+8, htole32(0xff000000));
};
for C_BRIDGE_IDSEL_ADDR_BIT =3D 16, use=20
pci_init()
{
/* self-configuration */
WR32(PCI_CONFIG_ADDR, htole32(0x80000004)); // address
WR32(PCI_CONFIG_DATA, htole32(0xffff0147)); // data
/* max latency timer on bridge */
WR32(PCI_CONFIG_ADDR, htole32(0x8000000c)); // address
WR32(PCI_CONFIG_DATA, htole32(0x0000ff00)); // data
/* max bus number */
WR32(PCI_CONFIG_ADDR+8, htole32(0xff000000));
};
You may check Xilinx's user guide 241 for more details.=20
Porting BSP from EDK9.1 to MVista 2.4 should be quite straightforward, bu=
t =20
porting them to 2.6 virtex is a little bit vague. If you are trying to us=
e IDE =20
southbridge, I could recommend you start from 2.6.10 rather than 2.6 virt=
ex =20
because driver/ide/pci/alim15x3.c has been updated a lot and I =20
hate to say that a none-disclosure agreement on alim15x3 makes it time co=
nsuming =20
to understand super I/O on ml310. If you just need PCI bus function, then=
life
will much more easier but you still need be care of about opb-pci core pa=
rameters
Bin
-----Original Message-----
From: linuxppc-embedded-bounces+bhuang2=3Duncc.edu@ozlabs.org ?? linuxppc=
-embedded-request@ozlabs.org
Sent: 8/4/2008 (???) 22:00
To: linuxppc-embedded@ozlabs.org
Subject: Linuxppc-embedded Digest, Vol 48, Issue 5
=20
Send Linuxppc-embedded mailing list submissions to
linuxppc-embedded@ozlabs.org
To subscribe or unsubscribe via the World Wide Web, visit
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
or, via email, send a message with subject or body 'help' to
linuxppc-embedded-request@ozlabs.org
You can reach the person managing the list at
linuxppc-embedded-owner@ozlabs.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Linuxppc-embedded digest..."
Today's Topics:
1. PCI support on the ML310 (Linux 2.4/2.6) (Juliana Su)
2. Re: Creating a wrapped zImage.initrd -- can't start the
trampoline? (Grant Likely)
3. Re: suffisant space for U-Boot, Linux and an initrd image ?
(4MB SDRAM) (Wolfgang Denk)
----------------------------------------------------------------------
Message: 1
Date: Mon, 04 Aug 2008 16:08:33 -0400
From: Juliana Su <js084@bucknell.edu>
Subject: PCI support on the ML310 (Linux 2.4/2.6)
To: linuxppc-embedded@ozlabs.org
Message-ID: <489761C1.8030805@bucknell.edu>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
Hi,
I am trying to get PCI support on the ML310. I was able to port Linux=20
2.6 (linux-2.6-virtex from Secret Lab) onto the board, but unfortunately =
there is no PCI support in the kernel. When I enabled PCI support, I got =
the same errors (see below) that were reported on the Secret Lab Wiki.
CC arch/ppc/syslib/ppc4xx_setup.o
arch/ppc/syslib/ppc4xx_setup.c: In function `ppc4xx_map_io':
arch/ppc/syslib/ppc4xx_setup.c:118: error: `PPC4xx_PCI_IO_VADDR'=20
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:118: error: (Each undeclared identifier=20
is reported only once
arch/ppc/syslib/ppc4xx_setup.c:118: error: for each function it appears i=
n.)
arch/ppc/syslib/ppc4xx_setup.c:119: error: `PPC4xx_PCI_IO_PADDR'=20
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:119: error: `PPC4xx_PCI_IO_SIZE'=20
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:120: error: `PPC4xx_PCI_CFG_VADDR'=20
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:121: error: `PPC4xx_PCI_CFG_PADDR'=20
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:121: error: `PPC4xx_PCI_CFG_SIZE'=20
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:122: error: `PPC4xx_PCI_LCFG_VADDR'=20
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:123: error: `PPC4xx_PCI_LCFG_PADDR'=20
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:123: error: `PPC4xx_PCI_LCFG_SIZE'=20
undeclared (first use in this function)
make[1]: *** [arch/ppc/syslib/ppc4xx_setup.o] Error 1
make: *** [arch/ppc/syslib] Error 2
I went back to Linux 2.4 (v2.4.20_mvl31-ml300), but the system hangs=20
during ml310_init( ), specifically when it gets to pci_init( ), in=20
ml310.c. I put some print statements in ml310.c to debug and found out=20
that it gets pass the first two lines in pci_init( ) before hanging.=20
Basically, all I get on my screen is:
Xilinx ML310 Board-Specific Initialization:
ml310_init( ) looks like this:
void
ml310_init()
{
prints("\n\n");
prints("Xilinx ML310 Board-Specific Initialization:\n");
prints("\n");
pci_init();
ppb_init(9);
pci_scan();
sio_init();
sbr_init();
};
and pci_init( ) looks like this:
void
pci_init()
{
/* self-configuration */
WR32(PCI_CONFIG_ADDR, htole32(0x80004004)); // address
WR32(PCI_CONFIG_DATA, htole32(0xffff0147)); // data
/* max latency timer on bridge */
WR32(PCI_CONFIG_ADDR, htole32(0x8000400c)); // address
WR32(PCI_CONFIG_DATA, htole32(0x0000ff00)); // data
/* max bus number */
WR32(PCI_CONFIG_ADDR+8, htole32(0xff000000));
};
ml310.c was generated when I made the BSP in Xilinx EDK 9.1. I copied=20
it, along with the other files from the BSP, into the kernel source. I=20
am using a Crosstool cross-compiler, gcc-3.4.1-glibc-2.3.3. I have also=20
tried the linuxppc-2.4 and mvistappc_2_4_devel kernels from=20
source.mvista.com, but those both crashed with similar (and several)=20
errors concerning ide-taskfile.c during compilation.
Is anybody aware of how to manually map the PCI constants in 2.6 and=20
willing to help me map them? Does anybody have an idea why pci_init( )=20
is getting stuck? Any suggestions, in general, would be greatly appreciat=
ed.
Let me know if I need to provide more information or code. Thanks!
-Juliana
^ permalink raw reply
* Re: to schedule() or not to schedule() ?
From: Chris Friesen @ 2008-08-05 18:37 UTC (permalink / raw)
To: Kevin Diggs; +Cc: linuxppc-dev
In-Reply-To: <4895F9EB.8050508@hypersurf.com>
Kevin Diggs wrote:
> Hi,
>
>
> I have the following near the top of my cpufreq driver target routine:
>
> while(test_and_set_bit(cf750gxmCfgChangeBit,&cf750gxvStateBits)) {
> /*
> * Someone mucking with our cfg? (I hope it is ok to call
> * schedule() here! - truth is I have no idea what I am doing
> * ... my reasoning is I want to yeild the cpu so whoever is
> * mucking around can finish)
> */
> schedule();
> }
>
> This is to prevent bad things from happening if someone is trying to
> change a parameter for the driver via sysfs while the target routine is
> running. Fortunately, because I had a bug where this bit was not getting
> cleared on one of the paths through the target routine ... I now know it
> is not safe to call schedule (it got stuck in there - knocked out my adb
> keyboard! - (I think target is called from a timer that the governor
> sets up ... interrupt context?)).
Is the issue that someone may be in the middle of a multi-stage
procedure, and you've woken up partway through?
If so, what about simply rescheduling the timer for some short time in
the future and aborting the current call?
Chris
^ permalink raw reply
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Dave Hansen @ 2008-08-05 17:53 UTC (permalink / raw)
To: Mel Gorman
Cc: linux-mm, libhugetlbfs-devel, linux-kernel, linuxppc-dev, abh,
ebmunson, Andrew Morton
In-Reply-To: <20080805162800.GJ20243@csn.ul.ie>
On Tue, 2008-08-05 at 17:28 +0100, Mel Gorman wrote:
> Ok sure, you could do direct inserts for MAP_PRIVATE as conceptually it
> suits this patch. However, I don't see what you gain. By reusing hugetlbfs,
> we get things like proper reservations which we can do for MAP_PRIVATE these
> days. Again, we could call that sort of thing directly if the reservation
> layer was split out separate from hugetlbfs but I still don't see the gain
> for all that churn.
>
> What am I missing?
This is good for getting us incremental functionality. It is probably
the smallest amount of code to get it functional.
My concern is that we're going down a path that all large page usage
should be through the one and only filesystem. Once we establish that
dependency, it is going to be awfully hard to undo it; just think of all
of the inherent behavior in hugetlbfs. So, we better be sure that the
filesystem really is the way to go, especially if we're going to start
having other areas of the kernel depend on it internally.
That said, this particular patch doesn't appear *too* bound to hugetlb
itself. But, some of its limitations *do* come from the filesystem,
like its inability to handle VM_GROWS...
-- Dave
^ permalink raw reply
* Re: floating point support in the driver.
From: David Hawkins @ 2008-08-05 16:53 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <18827857.post@talk.nabble.com>
Hi Misbah,
> I am running the algorithm on OMAP processor (arm-core)
> and i did tried the same on iMX processor which
> takes 1.7 times more than OMAP.
Ok, thats a 10,000ft benchmark. The observation being
that it fails your requirement.
How does that time compare to the operations
required, and their expected times?
> It is true that the algorithm is performing the vector
> operation which is blowing the cache.
Determined how? Obviously if your cache is 16K and your
data is 64K, there's no way it'll fit in there at once,
but the algorithm could be crafted such that 1K at a time
was processed, while another data packet was moved onto
the cache ... but this is very processor specific.
> But the question is How to lock the cache ? In driver
> how should we implement the same ?
>
> An example code or a document could be helpful in this regard.
Indeed :)
I have no idea how the OMAP works, so the following are
just random, and possibly incorrect ramblings ...
The MPC8349EA startup code uses a trick where it zeros
out sections of the cache while providing an address.
Once the addresses and zeros are in the cache, its locked.
From that point on, memory accesses to those addresses
result in cache 'hits'. This is the startup stack used
by the U-Boot bootloader.
If something similar was done under Linux, then *I guess*
you could implement mmap() and ioremap() the section of
addresses associated with the locked cache lines.
You could then DMA data to and from the cache area,
and run your algorithm there. That would provide you
'fast SRAM'.
However, you might be able to get the same effect by
setting up your processing algorithm such that it handled
smaller chunks of data.
Feel free to explain your data processing :)
Cheers,
Dave
^ permalink raw reply
* re ：PCI support on the ML310 (Linux 2.4/2.6)
From: Huang, Bin @ 2008-08-05 16:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.5.1217901608.24397.linuxppc-embedded@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 10546 bytes --]
As far as I know, only MVista has complete PCI support for ML310. I have
been migrating their PCI stuff to 2.6 kernel for couple of months so I might
understand what you are suffering here.
If your system hangs just after "Xilinx ML310 Board-Specific
Initialization:", then probably there is something wrong with your OPB-PCI
core on virtex-2 FPGA. I highly recommend you double check the value of
"C_BRIDGE_IDSEL_ADDR_BIT" within your system.mhs file.
When the 2.4/2.6 kernel tries to initialize pci core, it has to do self-
configuration first. If the wrong address is assigned in pci_init(), then
the kernel could not proceed any more.
Here is what you need to take care of:
for C_BRIDGE_IDSEL_ADDR_BIT = 24, use
pci_init()
{
/* self-configuration */
WR32(PCI_CONFIG_ADDR, htole32(0x80004004)); // address
WR32(PCI_CONFIG_DATA, htole32(0xffff0147)); // data
/* max latency timer on bridge */
WR32(PCI_CONFIG_ADDR, htole32(0x8000400c)); // address
WR32(PCI_CONFIG_DATA, htole32(0x0000ff00)); // data
/* max bus number */
WR32(PCI_CONFIG_ADDR+8, htole32(0xff000000));
};
for C_BRIDGE_IDSEL_ADDR_BIT = 16, use
pci_init()
{
/* self-configuration */
WR32(PCI_CONFIG_ADDR, htole32(0x80000004)); // address
WR32(PCI_CONFIG_DATA, htole32(0xffff0147)); // data
/* max latency timer on bridge */
WR32(PCI_CONFIG_ADDR, htole32(0x8000000c)); // address
WR32(PCI_CONFIG_DATA, htole32(0x0000ff00)); // data
/* max bus number */
WR32(PCI_CONFIG_ADDR+8, htole32(0xff000000));
};
You may check Xilinx's user guide 241 for more details.
Porting BSP from EDK9.1 to MVista 2.4 should be quite straightforward, but
porting them to 2.6 virtex is a little bit vague. If you are trying to use IDE
southbridge, I could recommend you start from 2.6.10 rather than 2.6 virtex
because driver/ide/pci/alim15x3.c has been updated a lot and I
hate to say that a none-disclosure agreement on alim15x3 makes it time consuming
to understand super I/O on ml310. If you just need PCI bus function, then life
will much more easier but you still need be care of about opb-pci core parameters
Bin
-----Original Message-----
From: linuxppc-embedded-bounces+bhuang2=uncc.edu@ozlabs.org 代表 linuxppc-embedded-request@ozlabs.org
Sent: 8/4/2008 (星期一) 22:00
To: linuxppc-embedded@ozlabs.org
Subject: Linuxppc-embedded Digest, Vol 48, Issue 5
Send Linuxppc-embedded mailing list submissions to
linuxppc-embedded@ozlabs.org
To subscribe or unsubscribe via the World Wide Web, visit
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
or, via email, send a message with subject or body 'help' to
linuxppc-embedded-request@ozlabs.org
You can reach the person managing the list at
linuxppc-embedded-owner@ozlabs.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Linuxppc-embedded digest..."
Today's Topics:
1. PCI support on the ML310 (Linux 2.4/2.6) (Juliana Su)
2. Re: Creating a wrapped zImage.initrd -- can't start the
trampoline? (Grant Likely)
3. Re: suffisant space for U-Boot, Linux and an initrd image ?
(4MB SDRAM) (Wolfgang Denk)
----------------------------------------------------------------------
Message: 1
Date: Mon, 04 Aug 2008 16:08:33 -0400
From: Juliana Su <js084@bucknell.edu>
Subject: PCI support on the ML310 (Linux 2.4/2.6)
To: linuxppc-embedded@ozlabs.org
Message-ID: <489761C1.8030805@bucknell.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
I am trying to get PCI support on the ML310. I was able to port Linux
2.6 (linux-2.6-virtex from Secret Lab) onto the board, but unfortunately
there is no PCI support in the kernel. When I enabled PCI support, I got
the same errors (see below) that were reported on the Secret Lab Wiki.
CC arch/ppc/syslib/ppc4xx_setup.o
arch/ppc/syslib/ppc4xx_setup.c: In function `ppc4xx_map_io':
arch/ppc/syslib/ppc4xx_setup.c:118: error: `PPC4xx_PCI_IO_VADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:118: error: (Each undeclared identifier
is reported only once
arch/ppc/syslib/ppc4xx_setup.c:118: error: for each function it appears in.)
arch/ppc/syslib/ppc4xx_setup.c:119: error: `PPC4xx_PCI_IO_PADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:119: error: `PPC4xx_PCI_IO_SIZE'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:120: error: `PPC4xx_PCI_CFG_VADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:121: error: `PPC4xx_PCI_CFG_PADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:121: error: `PPC4xx_PCI_CFG_SIZE'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:122: error: `PPC4xx_PCI_LCFG_VADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:123: error: `PPC4xx_PCI_LCFG_PADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:123: error: `PPC4xx_PCI_LCFG_SIZE'
undeclared (first use in this function)
make[1]: *** [arch/ppc/syslib/ppc4xx_setup.o] Error 1
make: *** [arch/ppc/syslib] Error 2
I went back to Linux 2.4 (v2.4.20_mvl31-ml300), but the system hangs
during ml310_init( ), specifically when it gets to pci_init( ), in
ml310.c. I put some print statements in ml310.c to debug and found out
that it gets pass the first two lines in pci_init( ) before hanging.
Basically, all I get on my screen is:
Xilinx ML310 Board-Specific Initialization:
ml310_init( ) looks like this:
void
ml310_init()
{
prints("\n\n");
prints("Xilinx ML310 Board-Specific Initialization:\n");
prints("\n");
pci_init();
ppb_init(9);
pci_scan();
sio_init();
sbr_init();
};
and pci_init( ) looks like this:
void
pci_init()
{
/* self-configuration */
WR32(PCI_CONFIG_ADDR, htole32(0x80004004)); // address
WR32(PCI_CONFIG_DATA, htole32(0xffff0147)); // data
/* max latency timer on bridge */
WR32(PCI_CONFIG_ADDR, htole32(0x8000400c)); // address
WR32(PCI_CONFIG_DATA, htole32(0x0000ff00)); // data
/* max bus number */
WR32(PCI_CONFIG_ADDR+8, htole32(0xff000000));
};
ml310.c was generated when I made the BSP in Xilinx EDK 9.1. I copied
it, along with the other files from the BSP, into the kernel source. I
am using a Crosstool cross-compiler, gcc-3.4.1-glibc-2.3.3. I have also
tried the linuxppc-2.4 and mvistappc_2_4_devel kernels from
source.mvista.com, but those both crashed with similar (and several)
errors concerning ide-taskfile.c during compilation.
Is anybody aware of how to manually map the PCI constants in 2.6 and
willing to help me map them? Does anybody have an idea why pci_init( )
is getting stuck? Any suggestions, in general, would be greatly appreciated.
Let me know if I need to provide more information or code. Thanks!
-Juliana
------------------------------
Message: 2
Date: Mon, 4 Aug 2008 15:30:07 -0600
From: "Grant Likely" <grant.likely@secretlab.ca>
Subject: Re: Creating a wrapped zImage.initrd -- can't start the
trampoline?
To: paul@mad-scientist.us
Cc: Linuxppc-embedded@ozlabs.org
Message-ID:
<fa686aa40808041430q2d81f2a9i600e9ae17f658d01@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Aug 4, 2008 at 1:43 PM, Paul Smith <paul@mad-scientist.us> wrote:
> On Mon, 2008-08-04 at 11:25 -0600, Grant Likely wrote:
>> Take a look at Documentation/powerpc/bootwrapper.txt
>> You probably want the 'simpleImage.%' target. It also binds in a copy
>> of the device tree blob.
>
> Hm. I'm using 2.6.25.14 and I don't see any bootwrapper.txt file in
> Documentation/powerpc (or anywhere else). I also can't see any target
> simpleImage in any makefile. Is this something new in 2.6.26? :-(
>
> Any help for folks still using 2.6.25?
It's new in .26, but it is relevant for .25 also.
Here's a link to it:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/powerpc/bootwrapper.txt;h=d60fced5e1cc69169d9bbf1b49faacb41ef8db9c;hb=8f616cd5249e03c9e1b371623d85e76d4b86bbc1
> I think I need some basic instruction on how bootloaders etc. work, with
> a concentration on embedded PPC if possible. Anyone have any pointers
> that would be worth investigating?
The document above should help.
Documentation/powerpc/booting-without-of.txt has some useful
information also.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
------------------------------
Message: 3
Date: Tue, 05 Aug 2008 00:59:57 +0200
From: Wolfgang Denk <wd@denx.de>
Subject: Re: suffisant space for U-Boot, Linux and an initrd image ?
(4MB SDRAM)
To: Fabien Oriede <fabien.oriede@yahoo.fr>
Cc: linuxppc-embedded@ozlabs.org
Message-ID: <20080804225958.0827524848@gemini.denx.de>
Content-Type: text/plain; charset=ISO-8859-1
In message <789365.58211.qm@web27401.mail.ukl.yahoo.com> you wrote:
>
> I would like to know if this is possible to port U-Boot, Linux and an initrd?image on a?board with 4MB of SDRAM ?
In Theory it may be possible, but just for very tiny demo
applications. Probably not for a useful device.
> When Linux try to boot, there is this line on the terminal :
> "Memory : 2036k available (1036k kernel code, 256k data, 80k init, 0k highmem)"
> So I have 2036k?memory available?for my initrd image?but I don't know if this is suffisant.
Note that a ramdisk is NOT an efficient way to use memory. See fro
example http://www.denx.de/wiki/view/DULG/RootFileSystemSelection
which shows that for example a cramfs image is not only faster to boot
but also needs less RAM.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Keep your head and your heart going in the right direction and you
will not have to worry about your feet.
------------------------------
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
End of Linuxppc-embedded Digest, Vol 48, Issue 5
************************************************
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 8457 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: EOI spurious irqs during boot so they can be reenabled later
From: Segher Boessenkool @ 2008-08-05 16:48 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras, Milton Miller
In-Reply-To: <3d6dc055c5b18a641a5467b7331d935ede87efb2.1217943634.git.michael@ellerman.id.au>
> So when we receive a spurious irq, EOI it, and then mask it.
What happens when a new IRQ arrives on the interrupt controller
between these EOI and mask calls? Should you instead first mask
it, and only then EOI it? Or doesn't that work on XICS?
Segher
^ permalink raw reply
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Mel Gorman @ 2008-08-05 16:28 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-mm, libhugetlbfs-devel, linux-kernel, linuxppc-dev, abh,
ebmunson, Andrew Morton
In-Reply-To: <1217952748.10907.18.camel@nimitz>
On (05/08/08 09:12), Dave Hansen didst pronounce:
> On Tue, 2008-08-05 at 12:11 +0100, Mel Gorman wrote:
> > See, that's great until you start dealing with MAP_SHARED|MAP_ANONYMOUS.
> > To get that right between children, you end up something very fs-like
> > when the child needs to fault in a page that is already populated by the
> > parent. I strongly suspect we end up back at hugetlbfs backing it :/
>
> Yeah, but the case I'm worried about is plain anonymous. We already
> have the fs to back SHARED|ANONYMOUS, and they're not really
> anonymous. :)
>
> This patch *really* needs anonymous pages, and it kinda shoehorns them
> in with the filesystem. Stacks aren't shared at all, so this is a
> perfect example of where we can forget the fs, right?
>
Ok sure, you could do direct inserts for MAP_PRIVATE as conceptually it
suits this patch. However, I don't see what you gain. By reusing hugetlbfs,
we get things like proper reservations which we can do for MAP_PRIVATE these
days. Again, we could call that sort of thing directly if the reservation
layer was split out separate from hugetlbfs but I still don't see the gain
for all that churn.
What am I missing?
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: linux kernel under psim (powerpc emulator)
From: Grant Likely @ 2008-08-05 16:13 UTC (permalink / raw)
To: Mihaela Grigore, linuxppc-embedded
In-Reply-To: <78ef7ce10808050856g110b8c07s99ef9758b6326bf5@mail.gmail.com>
On Tue, Aug 5, 2008 at 9:56 AM, Mihaela Grigore
<grigore.mihaela@gmail.com> wrote:
> what ?? Are you sure ? because i investigated qemu and pearpc a while
> ago and as far as i could find out neither could run a 2.6 kernel.
> Only 2.4.
Yes, Rob Landley has it working in his Firmware Linux tool:
http://www.landley.net/code/firmware/
g.
>
> Regards,
> Mihaela Grigore
>
> On Tue, Aug 5, 2008 at 4:22 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
>> On Tue, Aug 5, 2008 at 7:04 AM, Mihaela Grigore
>> <grigore.mihaela@gmail.com> wrote:
>>> Hello,
>>>
>>> Has anyone tried or knows if it is possible to run a 2.6 linux kernel
>>> under psim?
>>
>> I don't know about psim, but I do know that it will run under qemu.
>>
>> g.
>>
>> --
>> Grant Likely, B.Sc., P.Eng.
>> Secret Lab Technologies Ltd.
>>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Big include file move breaks user mode
From: Kumar Gala @ 2008-08-05 16:13 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080805120916.2f39307c@lappy.seanm.ca>
On Aug 5, 2008, at 11:09 AM, Sean MacLennan wrote:
> Almost all of the includes in include/asm-powerpc where moved to
> arch/powerpc/include/asm. This is breaking almost all of my user mode
> code... so I assume I am doing something very wrong.
>
> Here is a simple program that flushes stdout for no apparent reason ;)
>
> #include <stdio.h>
> #include <sys/ioctl.h>
>
> int main(int argc, char *argv[])
> {
> ioctl(1, TCFLSH, 1);
> return 0;
> }
>
> This builds and runs fine under x86 and ppc before the include file
> move. After the move, the compile fails because gcc can't find
> asm/ioctls.h which is needed by /usr/include/bits/ioctls.h (let's
> ignore the cross-compile path for now).
>
> The other big one I am hitting is that /usr/include/bits/errno.h
> includes linux/errno.h which includes asm/errno.h which no longer
> exists.
>
> Anybody know how to fix this? I am using the DENX 4.1 toolchain if
> that
> helps. Also, if there is a better place to post this, let me know. I
> posted here since it only affects powerpc cross compiles... x86 still
> has all the includes in "the right place".
>
> Should include/asm be a link to arch/powerpc/include/asm?
Are you using the headers_install option? or just point to a kernel
tree.
- k
^ permalink raw reply
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Dave Hansen @ 2008-08-05 16:12 UTC (permalink / raw)
To: Mel Gorman
Cc: linux-mm, libhugetlbfs-devel, linux-kernel, linuxppc-dev, abh,
ebmunson, Andrew Morton
In-Reply-To: <20080805111147.GD20243@csn.ul.ie>
On Tue, 2008-08-05 at 12:11 +0100, Mel Gorman wrote:
> See, that's great until you start dealing with MAP_SHARED|MAP_ANONYMOUS.
> To get that right between children, you end up something very fs-like
> when the child needs to fault in a page that is already populated by the
> parent. I strongly suspect we end up back at hugetlbfs backing it :/
Yeah, but the case I'm worried about is plain anonymous. We already
have the fs to back SHARED|ANONYMOUS, and they're not really
anonymous. :)
This patch *really* needs anonymous pages, and it kinda shoehorns them
in with the filesystem. Stacks aren't shared at all, so this is a
perfect example of where we can forget the fs, right?
-- Dave
^ permalink raw reply
* Big include file move breaks user mode
From: Sean MacLennan @ 2008-08-05 16:09 UTC (permalink / raw)
To: linuxppc-dev
Almost all of the includes in include/asm-powerpc where moved to
arch/powerpc/include/asm. This is breaking almost all of my user mode
code... so I assume I am doing something very wrong.
Here is a simple program that flushes stdout for no apparent reason ;)
#include <stdio.h>
#include <sys/ioctl.h>
int main(int argc, char *argv[])
{
ioctl(1, TCFLSH, 1);
return 0;
}
This builds and runs fine under x86 and ppc before the include file
move. After the move, the compile fails because gcc can't find
asm/ioctls.h which is needed by /usr/include/bits/ioctls.h (let's
ignore the cross-compile path for now).
The other big one I am hitting is that /usr/include/bits/errno.h
includes linux/errno.h which includes asm/errno.h which no longer
exists.
Anybody know how to fix this? I am using the DENX 4.1 toolchain if that
helps. Also, if there is a better place to post this, let me know. I
posted here since it only affects powerpc cross compiles... x86 still
has all the includes in "the right place".
Should include/asm be a link to arch/powerpc/include/asm?
Cheers,
Sean
^ permalink raw reply
* Re: linux kernel under psim (powerpc emulator)
From: Grant Likely @ 2008-08-05 15:22 UTC (permalink / raw)
To: Mihaela Grigore; +Cc: linuxppc-embedded
In-Reply-To: <78ef7ce10808050604h54b9b627r69e98c82c2cb464@mail.gmail.com>
On Tue, Aug 5, 2008 at 7:04 AM, Mihaela Grigore
<grigore.mihaela@gmail.com> wrote:
> Hello,
>
> Has anyone tried or knows if it is possible to run a 2.6 linux kernel
> under psim?
I don't know about psim, but I do know that it will run under qemu.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Quick question about dts
From: Warner Losh @ 2008-08-05 14:41 UTC (permalink / raw)
To: marco.stornelli; +Cc: linuxppc-embedded
In-Reply-To: <489802B3.805@coritel.it>
From: Marco Stornelli <marco.stornelli@coritel.it>
Subject: Re: Quick question about dts
Date: Tue, 05 Aug 2008 09:35:15 +0200
> M. Warner Losh ha scritto:
> > I have a .dts file that works with 2.6.18 (MV Pro 5.0). I encode it
> > directly into the kernel image. However, when I try to use it with my
> > 2.6.23, 2.6.24 or 2.6.25 kernel trees, it doesn't work at all. In the
> > MV Pro 5.0 kernel, I hacked the startup sequence to store a pointer to
> > this blob in r3 so that it is moved in. I've done something similar
> > in -current (for reasons that are too complicated to really explain
> > well, we can't do this via the normal boot loader mechanisms). The
> > dtc complains that the interrupt-controller property is obsolete on
> > the chosen device.
> >
> > Does any documentation exist for how dts has evolved? I'd like to
> > forward port what I have without examining the .dts files from both
> > versions and guessing...
> >
> > Warner
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
> Check out the kernel documentation booting-without-of.txt of your version.
Thanks. I've already read this for both versions of the kernel. It
doesn't tell me how dts has evolved. It just tells me, mostly, what
is current for each version.
I've poked a little at the diffs between different versions. But
these diffs are only what, not why.
Warner
^ permalink raw reply
* [PATCH] ibmebus/of_platform: Move "name" sysfs attribute into generic OF devices
From: Joachim Fenkes @ 2008-08-05 14:30 UTC (permalink / raw)
To: Paul Mackerras, LinuxPPC-Dev, LKML, David S. Miller
Cc: Stephen Rothwell, Olaf Hering, Paul Mackerras, Christoph Raisch,
Alexander Schmidt, Stefan Roscher
Recent of_platform changes made of_bus_type_init() overwrite the bus type's
.dev_attrs list, so move ibmebus' "name" attribute (which is needed by eHCA
userspace support) into generic OF device code. Tested on POWER.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
arch/powerpc/kernel/ibmebus.c | 12 ------------
drivers/of/device.c | 10 ++++++++++
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index 9d42eb5..a063622 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -233,17 +233,6 @@ void ibmebus_free_irq(u32 ist, void *dev_id)
}
EXPORT_SYMBOL(ibmebus_free_irq);
-static ssize_t name_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- return sprintf(buf, "%s\n", to_of_device(dev)->node->name);
-}
-
-static struct device_attribute ibmebus_dev_attrs[] = {
- __ATTR_RO(name),
- __ATTR_NULL
-};
-
static char *ibmebus_chomp(const char *in, size_t count)
{
char *out = kmalloc(count + 1, GFP_KERNEL);
@@ -327,7 +316,6 @@ static struct bus_attribute ibmebus_bus_attrs[] = {
struct bus_type ibmebus_bus_type = {
.uevent = of_device_uevent,
- .dev_attrs = ibmebus_dev_attrs,
.bus_attrs = ibmebus_bus_attrs
};
EXPORT_SYMBOL(ibmebus_bus_type);
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 8a1d93a..51e5214 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -57,6 +57,15 @@ static ssize_t devspec_show(struct device *dev,
return sprintf(buf, "%s\n", ofdev->node->full_name);
}
+static ssize_t name_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct of_device *ofdev;
+
+ ofdev = to_of_device(dev);
+ return sprintf(buf, "%s\n", ofdev->node->name);
+}
+
static ssize_t modalias_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -71,6 +80,7 @@ static ssize_t modalias_show(struct device *dev,
struct device_attribute of_platform_device_attrs[] = {
__ATTR_RO(devspec),
+ __ATTR_RO(name),
__ATTR_RO(modalias),
__ATTR_NULL
};
--
1.5.5
^ permalink raw reply related
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