* Re: [PATCH] PPC440EPx SDRAM width
From: Josh Boyer @ 2009-04-23 14:59 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <49F07DF0.5020207@ru.mvista.com>
On Thu, Apr 23, 2009 at 06:40:48PM +0400, Valentine Barshak wrote:
> Stefan Roese wrote:
>> On Thursday 23 April 2009, Josh Boyer wrote:
>>> On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
>>>> There is an error in the way ibm4xx_denali_fixup_memsize calculates
>>>> memory size. When testing the DDR_REDUC bit, the polarity is
>>>> backwards. A "1" implies 32-bit wide memory while a "0" implies
>>>> 64-bit wide memory.
>>>>
>>>> For a 32-bit wide system, this bug causes twice the memory to be
>>>> reported, leading to boot failure.
>>>>
>>>> Signed-off-by: Steven A. Falco <sfalco@harris.com>
>>> So we had a previous patch for this, and a very long discussion on what the
>>> right solution was. Either we never came to a resolution, or I have just
>>> forgotten what it was.
>>>
>>> Stefan, Valentine, do either of you remember?
>>
>
> The patch will break sequia/rainier since u-boot doesn't set the number
> of chipselects correctly for them. IIRC, the last conversation didn't
> come to any conclusion. We sort of wanted to fix that regardless of
> whether we had corrected u-boot or not.
>
> Could we use a "model" property to distinguish between the "real"
> sequoia/rainier and other custom boards?
> If yes, we could add a workaround the ibm4xx_denali_fixup_memsize to
> hardcode the chipselect number to 1 for sequoia/rainier.
We could do that perhaps, yes. In cases where the board has a newer U-Boot
with the fix already, it shouldn't really cause any harm, correct?
josh
^ permalink raw reply
* Re: [PATCH] PPC440EPx SDRAM width
From: Valentine Barshak @ 2009-04-23 15:16 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20090423145915.GC3825@zod.rchland.ibm.com>
Josh Boyer wrote:
> On Thu, Apr 23, 2009 at 06:40:48PM +0400, Valentine Barshak wrote:
>> Stefan Roese wrote:
>>> On Thursday 23 April 2009, Josh Boyer wrote:
>>>> On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
>>>>> There is an error in the way ibm4xx_denali_fixup_memsize calculates
>>>>> memory size. When testing the DDR_REDUC bit, the polarity is
>>>>> backwards. A "1" implies 32-bit wide memory while a "0" implies
>>>>> 64-bit wide memory.
>>>>>
>>>>> For a 32-bit wide system, this bug causes twice the memory to be
>>>>> reported, leading to boot failure.
>>>>>
>>>>> Signed-off-by: Steven A. Falco <sfalco@harris.com>
>>>> So we had a previous patch for this, and a very long discussion on what the
>>>> right solution was. Either we never came to a resolution, or I have just
>>>> forgotten what it was.
>>>>
>>>> Stefan, Valentine, do either of you remember?
>> The patch will break sequia/rainier since u-boot doesn't set the number
>> of chipselects correctly for them. IIRC, the last conversation didn't
>> come to any conclusion. We sort of wanted to fix that regardless of
>> whether we had corrected u-boot or not.
>>
>> Could we use a "model" property to distinguish between the "real"
>> sequoia/rainier and other custom boards?
>> If yes, we could add a workaround the ibm4xx_denali_fixup_memsize to
>> hardcode the chipselect number to 1 for sequoia/rainier.
>
> We could do that perhaps, yes. In cases where the board has a newer U-Boot
> with the fix already, it shouldn't really cause any harm, correct?
Yes, that's correct.
Thanks,
Val
>
> josh
^ permalink raw reply
* Re: [PATCH] PPC440EPx SDRAM width
From: Valentine Barshak @ 2009-04-23 14:40 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <200904231605.22912.sr@denx.de>
Stefan Roese wrote:
> On Thursday 23 April 2009, Josh Boyer wrote:
>> On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
>>> There is an error in the way ibm4xx_denali_fixup_memsize calculates
>>> memory size. When testing the DDR_REDUC bit, the polarity is
>>> backwards. A "1" implies 32-bit wide memory while a "0" implies
>>> 64-bit wide memory.
>>>
>>> For a 32-bit wide system, this bug causes twice the memory to be
>>> reported, leading to boot failure.
>>>
>>> Signed-off-by: Steven A. Falco <sfalco@harris.com>
>> So we had a previous patch for this, and a very long discussion on what the
>> right solution was. Either we never came to a resolution, or I have just
>> forgotten what it was.
>>
>> Stefan, Valentine, do either of you remember?
>
The patch will break sequia/rainier since u-boot doesn't set the number
of chipselects correctly for them. IIRC, the last conversation didn't
come to any conclusion. We sort of wanted to fix that regardless of
whether we had corrected u-boot or not.
Could we use a "model" property to distinguish between the "real"
sequoia/rainier and other custom boards?
If yes, we could add a workaround the ibm4xx_denali_fixup_memsize to
hardcode the chipselect number to 1 for sequoia/rainier.
Thanks,
Val.
> Not really, sorry. Must be longer than 2 weeks ago, so it's already flushed
> from my cache. :)
>
>> IIRC, it wasn't something
>> that effected Sequoia or Rainier, but it could (and obviously does) effect
>> custom boards. I don't remember what we agreed on for the proper fix.
>
> It would effect all 32-bit wide 440EPx/GRx boards using the boot wrapper. I
> never used the wrapper on those platforms though. Sorry, I don't remember the
> outcome of the discussion either.
>
> Thanks,
> Stefan
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] 83xx: add support for the kmeter1 board.
From: Heiko Schocher @ 2009-04-23 14:50 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <6B76A454-649E-408C-A8DF-AAEEE6011929@kernel.crashing.org>
Hello Kumar,
Kumar Gala wrote:
>> diff --git a/arch/powerpc/boot/dts/kmeter1.dts
>> b/arch/powerpc/boot/dts/kmeter1.dts
>> new file mode 100644
>> index 0000000..4f343ca
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/kmeter1.dts
>> @@ -0,0 +1,518 @@
>> +/*
>> + * Keymile KMETER1 Device Tree Source
>> + *
[...]
>> +
>> +
>> +/*
>> +/memreserve/ 00000000 1000000;
>> +*/
>
> is this needed for something?
No, I delete it.
>>
>> +
>> +/dts-v1/;
>> +
>> +/ {
>> + model = "KMETER1";
[...]
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + PowerPC,8360@0 {
>> + device_type = "cpu";
>> + reg = <0x0>;
>> + d-cache-line-size = <32>; // 32 bytes
>> + i-cache-line-size = <32>; // 32 bytes
>> + d-cache-size = <32768>; // L1, 32K
>> + i-cache-size = <32768>; // L1, 32K
>> + timebase-frequency = <66000000>;
>> + bus-frequency = <264000000>;
>> + clock-frequency = <528000000>;
>
> is the board running at a fixed frequency that isn't possible to change?
No, u-boot updates this. I fix this.
>> + };
>> + };
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0x00000000 0x10000000>;
>> + };
>
> does u-boot not set this? Also is the amount of memory fixed?
No, u-boot updates this. I fix this too. (and all other places)
>> +
>> + soc8360@e0000000 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + device_type = "soc";
>> + compatible = "simple-bus";
[...]
>> + };
>> + };
>> +
>> + qe@e0100000 {
>
> why isn't this under the SOC?
No reason for that, you are right, I fix this too.
>>
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + device_type = "qe";
>> + compatible = "fsl,qe";
>> + ranges = <0x0 0xe0100000 0x00100000>;
>> + reg = <0xe0100000 0x480>;
>> + brg-frequency = <0>;
>> + bus-frequency = <396000000>;
>> +
[...]
>> +
>> + qeic: interrupt-controller@80 {
>> + interrupt-controller;
>> + compatible = "fsl,qe-ic";
>> + #address-cells = <0>;
>> + #interrupt-cells = <1>;
>> + reg = <0x80 0x80>;
>> + big-endian;
>
> seems unnecessary .. the qe is only big-endian.
OK.
>> + interrupts = <32 8 33 8>;
>> + interrupt-parent = <&ipic>;
>> + };
>> + };
>
>
>> diff --git a/arch/powerpc/platforms/83xx/kmeter1.c
>> b/arch/powerpc/platforms/83xx/kmeter1.c
>> new file mode 100644
>> index 0000000..99cf5c6
>> --- /dev/null
>> +++ b/arch/powerpc/platforms/83xx/kmeter1.c
>> @@ -0,0 +1,170 @@
>> +/*
>> + * Copyright 2008 DENX Software Engineering GmbH
>> + * Author: Heiko Schocher <hs@denx.de>
[...]
>> +
>> + np = of_find_compatible_node(NULL, "network", "ucc_geth");
>> + if (np != NULL) {
>> + uint svid;
>> +
>> + /* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
>> + svid = mfspr(SPRN_SVR);
>> + if (svid == 0x80480021) {
>> + void __iomem *immap;
>> +
>> + immap = ioremap(get_immrbase() + 0x14a8, 8);
>
> we should add a proper device node to cover whatever register space this
> is.
Hmm... in the MPC8360ERM.pdf this is a "reserved" register ... This
"register" is mentioned in the MPC8360ECE.pdf for this CPU in
Table 4. RGMII Programmable I/O Delay Work Arounds in the QE_ENET10
section.
So this is a MPC8360E, MPC8358E specific errata, so shouldn;t
we add this fix in the drivers/net/ucc_geth.c driver so all
boards have this fix?
thanks for commenting
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: removing get_immrbase()??
From: Scott Wood @ 2009-04-23 15:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev Development, Timur Tabi, David Gibson
In-Reply-To: <80CA86D4-3DA5-4C28-AE7A-C03CE5758774@kernel.crashing.org>
On Wed, Apr 22, 2009 at 10:36:36PM -0500, Kumar Gala wrote:
> I think this all sounds great in theory but in reality the vast
> majority (I'd say over 80-90%) we are talking about embedded reference
> boards.
I've handled plenty of support e-mails from people using custom 82xx
boards with device trees that have already forked from what's in the
kernel. I'm not looking forward to another round of "why doesn't this
work?" unless there's something significant to be gained from it.
-Scott
^ permalink raw reply
* Re: [PATCH] PPC440EPx SDRAM width
From: Steven A. Falco @ 2009-04-23 16:00 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <49F08636.3080007@ru.mvista.com>
Valentine Barshak wrote:
>
> Josh Boyer wrote:
>> On Thu, Apr 23, 2009 at 06:40:48PM +0400, Valentine Barshak wrote:
>>> Stefan Roese wrote:
>>>> On Thursday 23 April 2009, Josh Boyer wrote:
>>>>> On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
>>>>>> There is an error in the way ibm4xx_denali_fixup_memsize calculates
>>>>>> memory size. When testing the DDR_REDUC bit, the polarity is
>>>>>> backwards. A "1" implies 32-bit wide memory while a "0" implies
>>>>>> 64-bit wide memory.
>>>>>>
>>>>>> For a 32-bit wide system, this bug causes twice the memory to be
>>>>>> reported, leading to boot failure.
>>>>>>
>>>>>> Signed-off-by: Steven A. Falco <sfalco@harris.com>
>>>>> So we had a previous patch for this, and a very long discussion on
>>>>> what the
>>>>> right solution was. Either we never came to a resolution, or I
>>>>> have just
>>>>> forgotten what it was.
>>>>>
>>>>> Stefan, Valentine, do either of you remember?
>>> The patch will break sequia/rainier since u-boot doesn't set the
>>> number of chipselects correctly for them.
I had wondered about that. I was surprised that sequoia uboot
enabled both cs bits - now I know why it worked. Two wrongs
sometimes do make a right. :-)
>>> IIRC, the last
>>> conversation didn't come to any conclusion. We sort of wanted to fix
>>> that regardless of whether we had corrected u-boot or not.
That would have saved me a bit of grief. It will probably
help someone else someday too.
>>> Could we use a "model" property to distinguish between the "real"
>>> sequoia/rainier and other custom boards?
>>> If yes, we could add a workaround the ibm4xx_denali_fixup_memsize to
>>> hardcode the chipselect number to 1 for sequoia/rainier.
>>
>> We could do that perhaps, yes. In cases where the board has a newer
>> U-Boot
>> with the fix already, it shouldn't really cause any harm, correct?
>
> Yes, that's correct.
Not sure if you want me to do something further in my patch.
Are you suggesting testing for model = "amcc,sequoia" and
forcing cs to 1, or is there more to it?
Steve
>
> Thanks,
> Val
>
>>
>> josh
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: removing get_immrbase()??
From: Scott Wood @ 2009-04-23 16:00 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: Linuxppc-dev Development, Timur Tabi
In-Reply-To: <20090423135005.GA18462@oksana.dev.rtsoft.ru>
On Thu, Apr 23, 2009 at 05:50:05PM +0400, Anton Vorontsov wrote:
> As for Freescale parts, all the reference board I've seen were
> very friendly wrt upgrading their device-trees, i.e. none of
> the boards were shipping with device-tree soldered into the
> firmware.
But many of them have broken when a dtb that u-boot didn't like was
inserted.
> And note that most developers are using up-to-date firmwares
> (U-Boots), device trees, and kernels.
So then why did we have to make cuImage?
> And that means that old device-tree + new kernel combination is left
> untested for years. And untested stuff is broken stuff, by definition.
There's a difference between risking that something may be broken, and
gratuitously making it broken.
> Sure, there is a completely different story wrt device-tree
> changes that might break firmwares. And that I believe we'd
> better avoid. For example device_type = "soc", if removed,
> most firmwares would not fix-up {clock,bus}-frequency properties.
Even if the given change may not break the firmware, it could force an
update in which a prior change breaks the firmware.
-Scott
^ permalink raw reply
* Re: [PATCH 1/6] powerpc: Move #ifdef'ed body of do_IRQ() into a separate function
From: Scott Wood @ 2009-04-23 16:49 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <c3e0e417a708c5d76d9f4130e5f2b0398a1e0c3e.1240450296.git.michael@ellerman.id.au>
On Thu, Apr 23, 2009 at 11:31:37AM +1000, Michael Ellerman wrote:
> + handler = desc->handler;
Should be desc->handle_irq. It's fixed in a later patch, but this breaks
bisect.
-Scott
^ permalink raw reply
* Re: removing get_immrbase()??
From: Anton Vorontsov @ 2009-04-23 16:54 UTC (permalink / raw)
To: Scott Wood; +Cc: Linuxppc-dev Development, Timur Tabi
In-Reply-To: <20090423160048.GC19717@ld0162-tx32.am.freescale.net>
On Thu, Apr 23, 2009 at 11:00:48AM -0500, Scott Wood wrote:
> On Thu, Apr 23, 2009 at 05:50:05PM +0400, Anton Vorontsov wrote:
> > As for Freescale parts, all the reference board I've seen were
> > very friendly wrt upgrading their device-trees, i.e. none of
> > the boards were shipping with device-tree soldered into the
> > firmware.
>
> But many of them have broken when a dtb that u-boot didn't like was
> inserted.
Yes, I agree here. And I'm not going to contradict on this
matter. If we stick with these two rules, I think we should always
be OK:
(1) We should avoid any changes that might break compatibility with
an officially supported firmware;
(2) Breaking "new Linux" <-> "old device tree" compatibility should
be OK if (1) is satisfied.
Note that this applies only for targets that have no problem w/
device-tree upgrades.
> > And note that most developers are using up-to-date firmwares
> > (U-Boots), device trees, and kernels.
>
> So then why did we have to make cuImage?
I don't know. I've never used them. ;-) Honestly. But I believe
it's a great stuff for those who use really old and now unsupported
firmwares.
It has nothing to do with device-tree changes though. We can easily
maintain device-tree compatibility w/ firmwares, but what is the
point in maintaining Linux' compatibility for older device trees
when you can easily upgrade it?
That is, I still don't get why somebody don't want to upgrade
device tree along with Linux (assuming it won't cause breakages in
the firmware)?
[...]
> > Sure, there is a completely different story wrt device-tree
> > changes that might break firmwares. And that I believe we'd
> > better avoid. For example device_type = "soc", if removed,
> > most firmwares would not fix-up {clock,bus}-frequency properties.
>
> Even if the given change may not break the firmware, it could force an
> update in which a prior change breaks the firmware.
I'm not sure I'm following here. Could you give an example?
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: removing get_immrbase()??
From: Scott Wood @ 2009-04-23 17:03 UTC (permalink / raw)
To: avorontsov; +Cc: Linuxppc-dev Development, Timur Tabi
In-Reply-To: <20090423165430.GA8355@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> On Thu, Apr 23, 2009 at 11:00:48AM -0500, Scott Wood wrote:
>> Even if the given change may not break the firmware, it could force an
>> update in which a prior change breaks the firmware.
>
> I'm not sure I'm following here. Could you give an example?
1. U-boot X1 is used with kernel Y1 and device tree Z1. All is well.
2. U-boot X2 needs device tree Z2. Device tree Z2 goes in kernel Y2.
It will break when used with u-boot X1, so users of u-boot X1 do not
upgrade their device trees. All is well.
3. Kernel Y3 makes a change to the device tree (now Z3) that it needs.
This change does not have u-boot compatibility issues by itself, so the
kernel developer feels confident saying "go ahead and upgrade your tree,
it should be fine". Users of U-boot X1 pull in the latest device tree,
which includes the changes made in device tree Z2. Breakage.
-Scott
^ permalink raw reply
* [PATCH] PowerPC: 440EPx/GRx Sequoia/Rainier U-Boot incorrect chipselect number workaround
From: Valentine Barshak @ 2009-04-23 17:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sr
In-Reply-To: <49F09082.1040505@harris.com>
Some U-Boot versions incorrectly set the number of chipselects to two
for Sequoia/Rainier boards while they only have one chipselect hardwired.
This patch adds a workaround for this, hardcoding the number of chipselects
to one for sequioa/rainer board models and reading the actual value from
the memory controller register DDR0_10 otherwise.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/boot/4xx.c | 52 +++++++++++++++++++++++++++++++++++++----------
1 files changed, 41 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
index 5c87843..6196067 100644
--- a/arch/powerpc/boot/4xx.c
+++ b/arch/powerpc/boot/4xx.c
@@ -158,21 +158,33 @@ void ibm440spe_fixup_memsize(void)
#define DDR_GET_VAL(val, mask, shift) (((val) >> (shift)) & (mask))
-void ibm4xx_denali_fixup_memsize(void)
+/*
+ * Some U-Boot versions set the number of chipselects to two
+ * for Sequoia/Rainier boards while they only have one chipselect
+ * hardwired. Hardcode the number of chipselects to one
+ * for sequioa/rainer board models or read the actual value
+ * from the memory controller register DDR0_10 otherwise.
+ */
+static inline u32 ibm4xx_denali_get_cs(void)
{
- u32 val, max_cs, max_col, max_row;
- u32 cs, col, row, bank, dpath;
- unsigned long memsize;
+ void *devp;
+ char model[64];
+ u32 val, cs;
- val = SDRAM0_READ(DDR0_02);
- if (!DDR_GET_VAL(val, DDR_START, DDR_START_SHIFT))
- fatal("DDR controller is not initialized\n");
+ devp = finddevice("/");
+ if (!devp)
+ goto read_cs;
- /* get maximum cs col and row values */
- max_cs = DDR_GET_VAL(val, DDR_MAX_CS_REG, DDR_MAX_CS_REG_SHIFT);
- max_col = DDR_GET_VAL(val, DDR_MAX_COL_REG, DDR_MAX_COL_REG_SHIFT);
- max_row = DDR_GET_VAL(val, DDR_MAX_ROW_REG, DDR_MAX_ROW_REG_SHIFT);
+ if (getprop(devp, "model", model, sizeof(model)) <= 0)
+ goto read_cs;
+ model[sizeof(model)-1] = 0;
+
+ if (!strcmp(model, "amcc,sequoia") ||
+ !strcmp(model, "amcc,rainier"))
+ return 1;
+
+read_cs:
/* get CS value */
val = SDRAM0_READ(DDR0_10);
@@ -183,7 +195,25 @@ void ibm4xx_denali_fixup_memsize(void)
cs++;
val = val >> 1;
}
+ return cs;
+}
+
+void ibm4xx_denali_fixup_memsize(void)
+{
+ u32 val, max_cs, max_col, max_row;
+ u32 cs, col, row, bank, dpath;
+ unsigned long memsize;
+
+ val = SDRAM0_READ(DDR0_02);
+ if (!DDR_GET_VAL(val, DDR_START, DDR_START_SHIFT))
+ fatal("DDR controller is not initialized\n");
+
+ /* get maximum cs col and row values */
+ max_cs = DDR_GET_VAL(val, DDR_MAX_CS_REG, DDR_MAX_CS_REG_SHIFT);
+ max_col = DDR_GET_VAL(val, DDR_MAX_COL_REG, DDR_MAX_COL_REG_SHIFT);
+ max_row = DDR_GET_VAL(val, DDR_MAX_ROW_REG, DDR_MAX_ROW_REG_SHIFT);
+ cs = ibm4xx_denali_get_cs();
if (!cs)
fatal("No memory installed\n");
if (cs > max_cs)
^ permalink raw reply related
* Re: [OT] Lite5200B w/ nfs root hangs after some time
From: Albrecht Dreß @ 2009-04-23 17:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <fa686aa40904221705r24f8093bn74d336ddc2b8edaf@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 392 bytes --]
Am 23.04.09 02:05 schrieb(en) Grant Likely:
>> http://patchwork.ozlabs.org/patch/24487/
That patch is already included in 2.6.29...
> No, that's not the problem in this case. 2.6.29 networking is broken
> for a lot of platforms, not just mpc5200. Use 2.6.29.1 instead.
...and with 2.6.29.1, everything works flawlessly again!
Thanks a lot for your help,
Cheers, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: removing get_immrbase()??
From: Anton Vorontsov @ 2009-04-23 17:26 UTC (permalink / raw)
To: Scott Wood; +Cc: Linuxppc-dev Development, Timur Tabi
In-Reply-To: <49F09F4A.8090506@freescale.com>
On Thu, Apr 23, 2009 at 12:03:06PM -0500, Scott Wood wrote:
> Anton Vorontsov wrote:
>> On Thu, Apr 23, 2009 at 11:00:48AM -0500, Scott Wood wrote:
>>> Even if the given change may not break the firmware, it could force an
>>> update in which a prior change breaks the firmware.
>>
>> I'm not sure I'm following here. Could you give an example?
>
[...]
> Device tree Z2 goes in kernel Y2. It
> will break when used with u-boot X1,
This is exactly what we should try to avoid. We should not accept
any changes that might break older firmwares. That is, keep the
device tree workable with X1 and X2, by any means.
For example, if X1 looks for "/soc8323@..." name instead of
compatible entry, we'll have to live with the name forever,
but we should be free to switch Linux so that it'll use only the
"compatible" property matching.
If X1 looks for "/soc8323@..." and X2 looks for "/soc@...", so that
Z1 and Z2 aren't compatible at all, then we're in trouble. But we're
in trouble regardless of what Linux is doing, no?
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] PowerPC: 440EPx/GRx Sequoia/Rainier U-Boot incorrect chipselect number workaround
From: Steven A. Falco @ 2009-04-23 17:45 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, sr
In-Reply-To: <20090423171222.GA32326@ru.mvista.com>
Valentine Barshak wrote:
> Some U-Boot versions incorrectly set the number of chipselects to two
> for Sequoia/Rainier boards while they only have one chipselect hardwired.
> This patch adds a workaround for this, hardcoding the number of chipselects
> to one for sequioa/rainer board models and reading the actual value from
> the memory controller register DDR0_10 otherwise.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
> arch/powerpc/boot/4xx.c | 52 +++++++++++++++++++++++++++++++++++++----------
> 1 files changed, 41 insertions(+), 11 deletions(-)
>
> diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
> index 5c87843..6196067 100644
> --- a/arch/powerpc/boot/4xx.c
> +++ b/arch/powerpc/boot/4xx.c
> @@ -158,21 +158,33 @@ void ibm440spe_fixup_memsize(void)
>
> #define DDR_GET_VAL(val, mask, shift) (((val) >> (shift)) & (mask))
>
> -void ibm4xx_denali_fixup_memsize(void)
> +/*
> + * Some U-Boot versions set the number of chipselects to two
> + * for Sequoia/Rainier boards while they only have one chipselect
> + * hardwired. Hardcode the number of chipselects to one
> + * for sequioa/rainer board models or read the actual value
> + * from the memory controller register DDR0_10 otherwise.
> + */
> +static inline u32 ibm4xx_denali_get_cs(void)
> {
> - u32 val, max_cs, max_col, max_row;
> - u32 cs, col, row, bank, dpath;
> - unsigned long memsize;
> + void *devp;
> + char model[64];
> + u32 val, cs;
>
> - val = SDRAM0_READ(DDR0_02);
> - if (!DDR_GET_VAL(val, DDR_START, DDR_START_SHIFT))
> - fatal("DDR controller is not initialized\n");
> + devp = finddevice("/");
> + if (!devp)
> + goto read_cs;
>
> - /* get maximum cs col and row values */
> - max_cs = DDR_GET_VAL(val, DDR_MAX_CS_REG, DDR_MAX_CS_REG_SHIFT);
> - max_col = DDR_GET_VAL(val, DDR_MAX_COL_REG, DDR_MAX_COL_REG_SHIFT);
> - max_row = DDR_GET_VAL(val, DDR_MAX_ROW_REG, DDR_MAX_ROW_REG_SHIFT);
> + if (getprop(devp, "model", model, sizeof(model)) <= 0)
> + goto read_cs;
>
> + model[sizeof(model)-1] = 0;
> +
> + if (!strcmp(model, "amcc,sequoia") ||
> + !strcmp(model, "amcc,rainier"))
> + return 1;
> +
> +read_cs:
> /* get CS value */
> val = SDRAM0_READ(DDR0_10);
>
> @@ -183,7 +195,25 @@ void ibm4xx_denali_fixup_memsize(void)
> cs++;
> val = val >> 1;
> }
> + return cs;
> +}
> +
> +void ibm4xx_denali_fixup_memsize(void)
> +{
> + u32 val, max_cs, max_col, max_row;
> + u32 cs, col, row, bank, dpath;
> + unsigned long memsize;
> +
> + val = SDRAM0_READ(DDR0_02);
> + if (!DDR_GET_VAL(val, DDR_START, DDR_START_SHIFT))
> + fatal("DDR controller is not initialized\n");
> +
> + /* get maximum cs col and row values */
> + max_cs = DDR_GET_VAL(val, DDR_MAX_CS_REG, DDR_MAX_CS_REG_SHIFT);
> + max_col = DDR_GET_VAL(val, DDR_MAX_COL_REG, DDR_MAX_COL_REG_SHIFT);
> + max_row = DDR_GET_VAL(val, DDR_MAX_ROW_REG, DDR_MAX_ROW_REG_SHIFT);
>
> + cs = ibm4xx_denali_get_cs();
> if (!cs)
> fatal("No memory installed\n");
> if (cs > max_cs)
>
Thanks for doing this so quickly!
I applied your patch plus my patch - my custom board reports
the correct memory size. Therefore,
Acked-by: Steven A. Falco <sfalco@harris.com>
Clearly, both your and my patches must be applied together or
"bad things will happen".
BTW, I got a whitespace warning when applying your patch:
Applying: PowerPC: 440EPx/GRx Sequoia/Rainier U-Boot incorrect chipselect number workaround
/proj/hydra/sw/sfalco/linux-2.6-denx/.git/rebase-apply/patch:17: trailing whitespace.
* hardwired. Hardcode the number of chipselects to one
warning: 1 line adds whitespace errors.
Steve
^ permalink raw reply
* Re: [PATCH] powerpc: adjust oprofile_cpu_type
From: Olof Johansson @ 2009-04-23 17:52 UTC (permalink / raw)
To: Mike Wolf; +Cc: linuxppc-dev
In-Reply-To: <1240443612.27209.2.camel@mx3>
On Wed, Apr 22, 2009 at 06:40:12PM -0500, Mike Wolf wrote:
> Resending. the patch was munged last time.
>
>
> Oprofile is changing the naming it is using for the compatibility modes.
> Instead of having compat-power<x>, oprofile will go to family naming
> convention and use compat-v<x>. Currently only compat-v1 will be
> defined.
Compat V1 of what? powerpc64? IBM powerpc64 PMC? The performance
monitors are not architected, to give them a version number without
vendor information seems weird.
Also, doesn't this break compatibility with existing userspace tools?
-Olof
^ permalink raw reply
* Re: removing get_immrbase()??
From: Scott Wood @ 2009-04-23 17:59 UTC (permalink / raw)
To: avorontsov; +Cc: Linuxppc-dev Development, Timur Tabi
In-Reply-To: <20090423172633.GA16375@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> This is exactly what we should try to avoid. We should not accept
> any changes that might break older firmwares. That is, keep the
> device tree workable with X1 and X2, by any means.
I think that's a much bigger restriction than trying to keep the kernel
compatible with older device trees. Consider changes in the physical
memory map, etc.
> If X1 looks for "/soc8323@..." and X2 looks for "/soc@...", so that
> Z1 and Z2 aren't compatible at all, then we're in trouble. But we're
> in trouble regardless of what Linux is doing, no?
Not if Linux can continue to deal with X1 and Z1.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/86xx: clean up smp init code
From: Kumar Gala @ 2009-04-23 18:42 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev
In-Reply-To: <49F064EB.5030109@gefanuc.com>
On Apr 23, 2009, at 7:54 AM, Martyn Welch wrote:
> Kumar Gala wrote:
>> Removed the need for asm/mpc86xx.h as it was only used in
>> mpc86xx_smp.c
>> and just moved the defines it cared about into there. Also fixed up
>> the ioremap to only map the one 4k page we need access to and to
>> iounmap
>> when we are done.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>> arch/powerpc/include/asm/mpc86xx.h | 33
>> ----------------------------
>> arch/powerpc/platforms/86xx/gef_ppc9a.c | 1 -
>> arch/powerpc/platforms/86xx/gef_sbc310.c | 1 -
>> arch/powerpc/platforms/86xx/gef_sbc610.c | 1 -
>> arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 1 -
>> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 1 -
>> arch/powerpc/platforms/86xx/mpc86xx_smp.c | 8 ++++++-
>> arch/powerpc/platforms/86xx/sbc8641d.c | 1 -
>> 8 files changed, 7 insertions(+), 40 deletions(-)
>> delete mode 100644 arch/powerpc/include/asm/mpc86xx.h
>>
>>
> I assume this patch relies on one of the other patches posted?
>
> Just applying this patch to my development tree (based on your main
> branch) resulted in the following on a PPC9A:
Darn, this should have been a simple change. I'll try it out on
mpc8641 to see if its happening there.
- k
^ permalink raw reply
* Re: PCI changes 2.6.26 => 2.6.28
From: Kumar Gala @ 2009-04-23 18:47 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc-dev
In-Reply-To: <49F07A15.9010006@mlbassoc.com>
On Apr 23, 2009, at 9:24 AM, Gary Thomas wrote:
> I have found the culprit - in arch/powerpc/kernel/pci_32.c
>
> static void
> fixup_hide_host_resource_fsl(struct pci_dev *dev)
> {
> int i, class = dev->class >> 8;
>
> #if 0
> if ((class == PCI_CLASS_PROCESSOR_POWERPC ||
> class == PCI_CLASS_BRIDGE_OTHER) &&
> #else
> if ((class == PCI_CLASS_PROCESSOR_POWERPC) &&
> #endif
> (dev->hdr_type == PCI_HEADER_TYPE_NORMAL) &&
> (dev->bus->parent == NULL)) {
> for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> dev->resource[i].start = 0;
> dev->resource[i].end = 0;
> dev->resource[i].flags = 0;
> }
> }
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MOTOROLA, PCI_ANY_ID,
> fixup_hide_host_resource_fsl);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
> fixup_hide_host_resource_fsl);
>
> This function is now (the #if 0 case is in 2.6.28) tossing out
> the memory resources used by the PCI bridge itself. This makes
> everything fall over, at least on my 834x platform.
>
> This change was applied 2008-10-08, but it seems incorrect on the
> 834x.
Its not. The PCI subsystem shouldn't be allocating or seeing the PHBs
resources.
>> Are you using u-boot to boot? If so is the board port public?
>
> My systems use RedBoot (I'm the original author of RedBoot, so one
> would
> expect that). At this moment, the code isn't public, sorry.
Ok. Not sure if RedBoot has a simple memory dump command, but if you
can dump the IMMR registers for PCI (0x8400 - IOS and 0x8500 - PCI1).
(I'm assuming PCI1 is the one you are using). From IOS I wanted the
outbound registers, for PCI1 the inbound ATU registers.
- k
^ permalink raw reply
* Re: [PATCH] PowerPC: 440EPx/GRx Sequoia/Rainier U-Boot incorrect chipselect number workaround
From: Valentine @ 2009-04-23 20:04 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev, sr
In-Reply-To: <49F0A957.5080508@harris.com>
Thanks Steven,
Yes, both patches have to be applied.
Sorry, I missed a trailing space in the comment.
I'll resubmit another one in a bit.
Thanks,
Val.
Steven A. Falco wrote:
>
> Thanks for doing this so quickly!
>
> I applied your patch plus my patch - my custom board reports
> the correct memory size. Therefore,
>
> Acked-by: Steven A. Falco <sfalco@harris.com>
>
> Clearly, both your and my patches must be applied together or
> "bad things will happen".
>
> BTW, I got a whitespace warning when applying your patch:
>
> Applying: PowerPC: 440EPx/GRx Sequoia/Rainier U-Boot incorrect chipselect number workaround
> /proj/hydra/sw/sfalco/linux-2.6-denx/.git/rebase-apply/patch:17: trailing whitespace.
> * hardwired. Hardcode the number of chipselects to one
> warning: 1 line adds whitespace errors.
>
> Steve
>
^ permalink raw reply
* Re: [PATCH] PowerPC: 440EPx/GRx Sequoia/Rainier U-Boot incorrect chipselect number workaround
From: Josh Boyer @ 2009-04-23 20:07 UTC (permalink / raw)
To: Valentine; +Cc: sr, linuxppc-dev
In-Reply-To: <49F0C9D7.1070707@ru.mvista.com>
On Fri, Apr 24, 2009 at 12:04:39AM +0400, Valentine wrote:
> Thanks Steven,
> Yes, both patches have to be applied.
> Sorry, I missed a trailing space in the comment.
> I'll resubmit another one in a bit.
> Thanks,
> Val.
Could you roll both patches into one, and include Steven's signed-off-by? That
way I only have a single patch to apply.
josh
^ permalink raw reply
* Re: [PATCH] PowerPC: 440EPx/GRx Sequoia/Rainier U-Boot incorrect chipselect number workaround
From: Steven A. Falco @ 2009-04-23 20:12 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, sr
In-Reply-To: <20090423200749.GJ3825@zod.rchland.ibm.com>
Josh Boyer wrote:
> On Fri, Apr 24, 2009 at 12:04:39AM +0400, Valentine wrote:
>> Thanks Steven,
>> Yes, both patches have to be applied.
>> Sorry, I missed a trailing space in the comment.
>> I'll resubmit another one in a bit.
>> Thanks,
>> Val.
>
> Could you roll both patches into one, and include Steven's signed-off-by? That
> way I only have a single patch to apply.
>
> josh
>
That would certainly be safer. Please let's combine them.
Steve
^ permalink raw reply
* [PATCH] PowerPC 44x: ibm4xx_denali_fixup_memsize fix
From: Valentine Barshak @ 2009-04-23 20:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sr
In-Reply-To: <49F0CBC6.4050805@harris.com>
Some U-Boot versions incorrectly set the number of chipselects to two
for Sequoia/Rainier boards while they only have one chipselect hardwired.
This patch adds a workaround for this, hardcoding the number of chipselects
to one for sequioa/rainer board models and reading the actual value from
the memory controller register DDR0_10 otherwise.
It also fixes another error in the way ibm4xx_denali_fixup_memsize
calculates memory size. When testing the DDR_REDUC bit, the polarity is
backwards. A "1" implies 32-bit wide memory while a "0" implies 64-bit
wide memory.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Signed-off-by: Steven A. Falco <sfalco@harris.com>
---
arch/powerpc/boot/4xx.c | 56 ++++++++++++++++++++++++++++++++++++-----------
1 files changed, 43 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
index 5c87843..325b310 100644
--- a/arch/powerpc/boot/4xx.c
+++ b/arch/powerpc/boot/4xx.c
@@ -158,21 +158,33 @@ void ibm440spe_fixup_memsize(void)
#define DDR_GET_VAL(val, mask, shift) (((val) >> (shift)) & (mask))
-void ibm4xx_denali_fixup_memsize(void)
+/*
+ * Some U-Boot versions set the number of chipselects to two
+ * for Sequoia/Rainier boards while they only have one chipselect
+ * hardwired. Hardcode the number of chipselects to one
+ * for sequioa/rainer board models or read the actual value
+ * from the memory controller register DDR0_10 otherwise.
+ */
+static inline u32 ibm4xx_denali_get_cs(void)
{
- u32 val, max_cs, max_col, max_row;
- u32 cs, col, row, bank, dpath;
- unsigned long memsize;
+ void *devp;
+ char model[64];
+ u32 val, cs;
- val = SDRAM0_READ(DDR0_02);
- if (!DDR_GET_VAL(val, DDR_START, DDR_START_SHIFT))
- fatal("DDR controller is not initialized\n");
+ devp = finddevice("/");
+ if (!devp)
+ goto read_cs;
- /* get maximum cs col and row values */
- max_cs = DDR_GET_VAL(val, DDR_MAX_CS_REG, DDR_MAX_CS_REG_SHIFT);
- max_col = DDR_GET_VAL(val, DDR_MAX_COL_REG, DDR_MAX_COL_REG_SHIFT);
- max_row = DDR_GET_VAL(val, DDR_MAX_ROW_REG, DDR_MAX_ROW_REG_SHIFT);
+ if (getprop(devp, "model", model, sizeof(model)) <= 0)
+ goto read_cs;
+ model[sizeof(model)-1] = 0;
+
+ if (!strcmp(model, "amcc,sequoia") ||
+ !strcmp(model, "amcc,rainier"))
+ return 1;
+
+read_cs:
/* get CS value */
val = SDRAM0_READ(DDR0_10);
@@ -183,7 +195,25 @@ void ibm4xx_denali_fixup_memsize(void)
cs++;
val = val >> 1;
}
+ return cs;
+}
+
+void ibm4xx_denali_fixup_memsize(void)
+{
+ u32 val, max_cs, max_col, max_row;
+ u32 cs, col, row, bank, dpath;
+ unsigned long memsize;
+
+ val = SDRAM0_READ(DDR0_02);
+ if (!DDR_GET_VAL(val, DDR_START, DDR_START_SHIFT))
+ fatal("DDR controller is not initialized\n");
+ /* get maximum cs col and row values */
+ max_cs = DDR_GET_VAL(val, DDR_MAX_CS_REG, DDR_MAX_CS_REG_SHIFT);
+ max_col = DDR_GET_VAL(val, DDR_MAX_COL_REG, DDR_MAX_COL_REG_SHIFT);
+ max_row = DDR_GET_VAL(val, DDR_MAX_ROW_REG, DDR_MAX_ROW_REG_SHIFT);
+
+ cs = ibm4xx_denali_get_cs();
if (!cs)
fatal("No memory installed\n");
if (cs > max_cs)
@@ -193,9 +223,9 @@ void ibm4xx_denali_fixup_memsize(void)
val = SDRAM0_READ(DDR0_14);
if (DDR_GET_VAL(val, DDR_REDUC, DDR_REDUC_SHIFT))
- dpath = 8; /* 64 bits */
- else
dpath = 4; /* 32 bits */
+ else
+ dpath = 8; /* 64 bits */
/* get address pins (rows) */
val = SDRAM0_READ(DDR0_42);
^ permalink raw reply related
* Re: [PATCH] powerpc: adjust oprofile_cpu_type
From: Mike Wolf @ 2009-04-23 21:56 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20090423175210.GB4732@lixom.net>
On Thu, 2009-04-23 at 12:52 -0500, Olof Johansson wrote:
> On Wed, Apr 22, 2009 at 06:40:12PM -0500, Mike Wolf wrote:
> > Resending. the patch was munged last time.
> >
> >
> > Oprofile is changing the naming it is using for the compatibility modes.
> > Instead of having compat-power<x>, oprofile will go to family naming
> > convention and use compat-v<x>. Currently only compat-v1 will be
> > defined.
>
> Compat V1 of what? powerpc64? IBM powerpc64 PMC?
IBM powerpc PMC
> The performance
> monitors are not architected, to give them a version number without
> vendor information seems weird.
The current ones all fall into one family and they may be architected in
the future.
>
> Also, doesn't this break compatibility with existing userspace tools?
AFAIK there is nothing else that uses these. Oprofile patch was
rejected and this new naming was suggested from that community.
Mike
^ permalink raw reply
* Re: [PATCH] powerpc: adjust oprofile_cpu_type
From: Olof Johansson @ 2009-04-23 22:09 UTC (permalink / raw)
To: Mike Wolf; +Cc: linuxppc-dev
In-Reply-To: <1240523816.12000.2.camel@mx3>
On Thu, Apr 23, 2009 at 04:56:56PM -0500, Mike Wolf wrote:
> On Thu, 2009-04-23 at 12:52 -0500, Olof Johansson wrote:
> > On Wed, Apr 22, 2009 at 06:40:12PM -0500, Mike Wolf wrote:
> > > Resending. the patch was munged last time.
> > >
> > >
> > > Oprofile is changing the naming it is using for the compatibility modes.
> > > Instead of having compat-power<x>, oprofile will go to family naming
> > > convention and use compat-v<x>. Currently only compat-v1 will be
> > > defined.
> >
> > Compat V1 of what? powerpc64? IBM powerpc64 PMC?
>
> IBM powerpc PMC
Sounds like it'd be appropriate to have an ibm somewhere in the version
string then.
> > The performance
> > monitors are not architected, to give them a version number without
> > vendor information seems weird.
> The current ones all fall into one family and they may be architected in
> the future.
Not all powerpc PMC implementations do, not even all ppc64 ones --
PA6T implements a completely different performance monitor.
The current IBM PMC is included in the appendix of the architecture as
a suggestion on how to implement it, but it is explicitly specified
as being implementation dependent in the architecture.
> > Also, doesn't this break compatibility with existing userspace tools?
> AFAIK there is nothing else that uses these. Oprofile patch was
> rejected and this new naming was suggested from that community.
Ok, as long as you are 100% sure there are no proprietary users either.
-Olof
^ permalink raw reply
* Re: PCI changes 2.6.26 => 2.6.28
From: Gary Thomas @ 2009-04-23 22:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <97DF2A19-563D-404A-AD3D-039D5989E489@kernel.crashing.org>
Kumar Gala wrote:
>
> On Apr 23, 2009, at 9:24 AM, Gary Thomas wrote:
>
>> I have found the culprit - in arch/powerpc/kernel/pci_32.c
>>
>> static void
>> fixup_hide_host_resource_fsl(struct pci_dev *dev)
>> {
>> int i, class = dev->class >> 8;
>>
>> #if 0
>> if ((class == PCI_CLASS_PROCESSOR_POWERPC ||
>> class == PCI_CLASS_BRIDGE_OTHER) &&
>> #else
>> if ((class == PCI_CLASS_PROCESSOR_POWERPC) &&
>> #endif
>> (dev->hdr_type == PCI_HEADER_TYPE_NORMAL) &&
>> (dev->bus->parent == NULL)) {
>> for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
>> dev->resource[i].start = 0;
>> dev->resource[i].end = 0;
>> dev->resource[i].flags = 0;
>> }
>> }
>> }
>> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MOTOROLA, PCI_ANY_ID,
>> fixup_hide_host_resource_fsl);
>> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
>> fixup_hide_host_resource_fsl);
>>
>> This function is now (the #if 0 case is in 2.6.28) tossing out
>> the memory resources used by the PCI bridge itself. This makes
>> everything fall over, at least on my 834x platform.
>>
>> This change was applied 2008-10-08, but it seems incorrect on the 834x.
>
> Its not. The PCI subsystem shouldn't be allocating or seeing the PHBs
> resources.
>
>>> Are you using u-boot to boot? If so is the board port public?
>>
>> My systems use RedBoot (I'm the original author of RedBoot, so one would
>> expect that). At this moment, the code isn't public, sorry.
>
> Ok. Not sure if RedBoot has a simple memory dump command, but if you
> can dump the IMMR registers for PCI (0x8400 - IOS and 0x8500 - PCI1).
> (I'm assuming PCI1 is the one you are using). From IOS I wanted the
I don't think any of this matters. It turns out that even
the 2.6.26 kernel fails on an identical board with a newer
revision of the 8347 chip. I'm sure that the problem is
that the Coral-P fails when mapped to 0 (PCI relative).
I couldn't find another reliable way to get the Coral-P assigned
an address other than 0, so I'm happy accepting the work around
of allowing the kernel to map those windows, even if it's not
necessary.
For completeness, here are the values you asked for:
pcilawbar0 : 0xc0000000 -1073741824
pcilawar : 0x8000001b -2147483621
pcilawbar1 : 0xb8000000 -1207959552
pcilawar1 : 0x80000013 -2147483629
8347>md 0xff008400
ff008400 : 00000000 00000000 000c0000 00000000 ................
ff008410 : 800f0000 00000000 00000000 00000000 ................
ff008420 : 000b8000 00000000 c00fff00 00000000 ................
ff008430 : 00000000 00000000 00000000 00000000 ................
ff008440 : 00000000 00000000 00000000 00000000 ................
ff008450 : 00000000 00000000 00000000 00000000 ................
ff008460 : 00000000 00000000 00000000 00000000 ................
ff008470 : 00000000 00000000 00000000 00000000 ................
ff008480 : 00000000 00000000 00000000 00000000 ................
ff008490 : 00000000 00000000 00000000 00000000 ................
ff0084a0 : 00000000 00000000 00000000 00000000 ................
ff0084b0 : 00000000 00000000 00000000 00000000 ................
ff0084c0 : 00000000 00000000 00000000 00000000 ................
ff0084d0 : 00000000 00000000 00000000 00000000 ................
ff0084e0 : 00000000 00000000 00000000 00000000 ................
ff0084f0 : 00000001 00010006 00000000 00000000 ................
8347>md 0xff008500
ff008500 : 00000000 00000000 00000000 00000000 ................
ff008510 : 00000000 00000000 00000000 00000000 ................
ff008520 : 00000001 00000000 00000001 00000000 ................
ff008530 : 00000000 00000000 00000000 00000000 ................
ff008540 : 00000000 00000000 00000000 00000000 ................
ff008550 : 00000000 00000000 00000000 00000000 ................
ff008560 : a005501a 00000000 00000000 00000000 ..P.............
ff008570 : 00000000 00000000 00000000 00000000 ................
ff008580 : 00000000 00000000 00000000 00000000 ................
ff008590 : 00000000 00000000 00000000 00000000 ................
ff0085a0 : 00000000 00000000 00000000 00000000 ................
ff0085b0 : 00000000 00000000 00000000 00000000 ................
ff0085c0 : 00000000 00000000 00000000 00000000 ................
ff0085d0 : 00000000 00000000 00000000 00000000 ................
ff0085e0 : 00000000 00000000 00000000 00000000 ................
ff0085f0 : 00000000 00000000 00000000 00000000 ................
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ 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