* Re: [PATCH 2/5] powerpc/85xx/86xx: Add suspend/resume support
From: Anton Vorontsov @ 2009-08-31 18:47 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: Wood Scott-B07421, linuxppc-dev
In-Reply-To: <5610599F537DD74A8D1F5CC946A7507301DCCC8B@az33exm25.fsl.freescale.net>
On Sun, Aug 30, 2009 at 05:38:05PM -0700, Tabi Timur-B04825 wrote:
>
> What about the 8610?
Yes, it is supported. The bindings decribe that 8641d should
be used as a base match, so 8610-pmc is 8641d-compatible.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: ECC & Magic bitmask errors with JFFS2 file system on 6.23 kernel for powerpc
From: Louise.Yeung @ 2009-08-31 20:39 UTC (permalink / raw)
To: linuxppc-dev, louise, Ravinder Kumar
In-Reply-To: <OF4DA6695F.B8912DE2-ON652575F5.004F0DE0-652575F5.00519736@lntemsys.com>
[-- Attachment #1: Type: text/plain, Size: 4189 bytes --]
*Hi Rupesh,
We are using a Freescale processor similar to yours with NAND flash
supporting 2KB page size .
We wonder if you were able to get any further with this problem that you
posted.
Thanks
Louise and Ravinder
Sun embedded systems group
Rupesh Kumar* Rupesh.Kumar at Lntemsys.com
<mailto:linuxppc-dev%40lists.ozlabs.org?Subject=Re%3A%20ECC%20%26%20Magic%20bitmask%20errors%20with%20JFFS2%20file%20system%20on%206.23%20kernel%20for%0A%09powerpc&In-Reply-To=%3COF4DA6695F.B8912DE2-ON652575F5.004F0DE0-652575F5.00519736%40lntemsys.com%3E>
/Fri Jul 17 01:03:11 EST 2009/
* Previous message: rtas instantiation when commandline contains mem
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-July/074168.html>
* Next message: [PATCH] mpc83xx/usb.c: fix usb mux setup for mpc834x
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-July/074147.html>
* *Messages sorted by:* [ date ]
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-July/date.html#74140>
[ thread ]
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-July/thread.html#74140>
[ subject ]
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-July/subject.html#74140>
[ author ]
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-July/author.html#74140>
------------------------------------------------------------------------
Hi
We are using Linux kernel 2.6.23 from freescale LTIB
(MPC8313E_RDB_K26_20081226-LTIB.iso) on our custom board.
JFFS2 is used as RFS and nand write.jffs2 utility in the u-boot is used
to burn the image on to the nand flash.
When we boot for the first time everything seems to be OK. On subsequent
reboots we are seeing following error messages reported by kernel on
bootup.
In addition we also see Magic bitmask errors being reported.
///////////////////////////
mtd->read(0x400 bytes from 0x1b00000) returned ECC error
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01b001d0:
0xfffe instead
mtd->read(0x400 bytes from 0x2500000) returned ECC error
mtd->read(0x400 bytes from 0x27c0000) returned ECC error
mtd->read(0x400 bytes from 0x2c20000) returned ECC error
mtd->read(0x400 bytes from 0x2cc0000) returned ECC error
mtd->read(0x400 bytes from 0x2d00000) returned ECC error
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x02d00074:
0xfffe instead
Empty flash at 0x02d00078 ends at 0x02d003e4
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x02d003e4:
0xffef instead
Empty flash at 0x02d003e8 ends at 0x02d00780
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x02d00780:
0xfffb instead
mtd->read(0x400 bytes from 0x3320000) returned ECC error
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x03320190:
0xffff instead
Empty flash at 0x03320194 ends at 0x0332047c
////////////////////////////
We verified erase size passed as an argument for creating jffs2 file
system (initial googling on the issue).
After contacting freescale we came to know that, it is a known issue and
they dont have planned to work on this in near future. :(
Please give your valuable suggestions so that we can fix this problem and
make our board running properly.
Thanks
Rupesh
------------------------------------------------------------------------
* Previous message: rtas instantiation when commandline contains mem
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-July/074168.html>
* Next message: [PATCH] mpc83xx/usb.c: fix usb mux setup for mpc834x
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-July/074147.html>
* *Messages sorted by:* [ date ]
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-July/date.html#74140>
[ thread ]
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-July/thread.html#74140>
[ subject ]
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-July/subject.html#74140>
[ author ]
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-July/author.html#74140>
------------------------------------------------------------------------
More information about the Linuxppc-dev mailing list
<https://lists.ozlabs.org/listinfo/linuxppc-dev>
[-- Attachment #2: Type: text/html, Size: 4504 bytes --]
^ permalink raw reply
* Re: [PATCH] IB/ehca: Construct MAD redirect replies from request MAD
From: Roland Dreier @ 2009-08-31 21:25 UTC (permalink / raw)
To: Joachim Fenkes
Cc: Hal Rosenstock, LKML, OF-EWG, Jason Gunthorpe, LinuxPPC-Dev,
Christoph Raisch, OF-General, Stefan Roscher
In-Reply-To: <200908261337.56128.fenkes@de.ibm.com>
this seems reasonable to me, applied, thanks.
^ permalink raw reply
* time jumps forward/backwards
From: Ben Gamsa @ 2009-08-31 21:53 UTC (permalink / raw)
To: linuxppc-dev
Our project is currently using 2.6.27.4 with a patch from Paul Mackerras
("powerpc: Improve resolution of VDSO clock_gettime") running on a
MPC8555. We picked up the patch on the hope that it would fix an
earlier problem we had with time jumping forwards and backwards shortly
after boot-up. It seemed to fix that problem, but it seems we have
another, similar problem.
It appears to be the case that when the time on the system is around the
epoch (1970), that time will occasionally jump forward and then backward
by about 17592 seconds. When it jumps forward, it always jumps back a
few milliseconds later. However, it's not always easy to catch these
occurrences. The delta is more specifically about 17592186059 usec,
give or take a few 10s of microseconds (most of the time), despite the
fact that the user-level program I have that is testing it only checks
every 10 milliseconds.
The number seems suspiciously close to 2^44 nanoseconds, which suggests
some sort of overflow error, perhaps caused by the time being set to
around time 0.
I'm not really sure where to begin looking (I know that the time code is
one of the more sensitive bits in the system so I definitely don't want
to go blindly mucking around), so I was hoping to get some suggestions
from the list.
Thanks for any help.
--
Ben Gamsa ben@somanetworks.com
SOMA Networks 312 Adelaide St. W. Suite 600 Toronto, Ontario, M5V1R2
^ permalink raw reply
* GPIOs 49-63 on 460EX
From: Jeff Hane @ 2009-08-31 22:01 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Hello,
We are having a problem trying to use gpio 49-63 on our amcc
canyonlands board. I'm aware these pins are shared with the trace port,
so wrote 0x7ff to SDR0_PFC0 register to make sure they were all in gpio
mode.
I set the gpio to output and then try to drive a 1 out but I can never
see it. I doubled checked the pin with the value reported by the SW and
it never toggles. If I set the value to 1, I can see a 1 in the gpio OR
register, but the IR stays 0(IR is what is read by get_value)
I can change the direction and value the first 16 gpios in gpio
controller 1 but not the upper 16 bits. So this means that gpio 48
doesn't work either; thus 16 of the gpio don't work(for out, I haven't
tried in)
I am running 2.6.30. Has anybody seen this? Am I missing a register
somewhere?
thanks,
jeff
^ permalink raw reply
* Re: time jumps forward/backwards
From: Paul Mackerras @ 2009-08-31 23:45 UTC (permalink / raw)
To: Ben Gamsa; +Cc: linuxppc-dev
In-Reply-To: <4A9C465D.4010801@somanetworks.com>
Ben Gamsa writes:
> It appears to be the case that when the time on the system is around the
> epoch (1970), that time will occasionally jump forward and then backward
> by about 17592 seconds. When it jumps forward, it always jumps back a
> few milliseconds later. However, it's not always easy to catch these
> occurrences. The delta is more specifically about 17592186059 usec,
> give or take a few 10s of microseconds (most of the time), despite the
> fact that the user-level program I have that is testing it only checks
> every 10 milliseconds.
I don't think the time code in the kernel is designed to handle
negative values, i.e., times before the epoch. If you want it to do
that you'll have to check places like arch/powerpc/kernel/time.c,
kernel/time/timekeeping.c, arch/powerpc/include/asm/time.h, etc., and
make sure that it uses signed types where necessary and that the
arithmetic is correct.
Paul.
^ permalink raw reply
* Re: time jumps forward/backwards
From: Benjamin Gamsa @ 2009-09-01 0:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <19100.24755.889091.412993@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Ben Gamsa writes:
>
>> It appears to be the case that when the time on the system is around the
>> epoch (1970), that time will occasionally jump forward and then backward
>> by about 17592 seconds. When it jumps forward, it always jumps back a
>> few milliseconds later. However, it's not always easy to catch these
>> occurrences. The delta is more specifically about 17592186059 usec,
>> give or take a few 10s of microseconds (most of the time), despite the
>> fact that the user-level program I have that is testing it only checks
>> every 10 milliseconds.
>
> I don't think the time code in the kernel is designed to handle
> negative values, i.e., times before the epoch. If you want it to do
> that you'll have to check places like arch/powerpc/kernel/time.c,
> kernel/time/timekeeping.c, arch/powerpc/include/asm/time.h, etc., and
> make sure that it uses signed types where necessary and that the
> arithmetic is correct.
>
The time never goes negative. It starts off at the epoch and moves
forward, but sometimes it jumps forward by 17952 seconds, and then
immediately jumps back. But it never goes negative (or prior to 1970).
ben
^ permalink raw reply
* Re: ECC & Magic bitmask errors with JFFS2 file system on 6.23 kernel for powerpc
From: Anton Vorontsov @ 2009-08-31 23:47 UTC (permalink / raw)
To: Louise.Yeung; +Cc: louise, Ravinder Kumar, linuxppc-dev, Rupesh Kumar
In-Reply-To: <4A9C34EE.4040606@Sun.COM>
On Mon, Aug 31, 2009 at 01:39:10PM -0700, Louise.Yeung@Sun.COM wrote:
> *Hi Rupesh,
>
> We are using a Freescale processor similar to yours with NAND flash
> supporting 2KB page size .
What kernel version and NAND driver you use? I don't think that old
BSP kernels include fsl_elbc_nand driver, which is a much improved
version of the fsl_fcm driver.
So you might want to swith to a newer kernel or back-port the
fsl_elbc_nand driver[1] and a few fixes to your kernel.
[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/mtd/nand/fsl_elbc_nand.c
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: time jumps forward/backwards
From: Benjamin Gamsa @ 2009-09-01 0:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <4A9C6446.2000202@somanetworks.com>
Benjamin Gamsa wrote:
> Paul Mackerras wrote:
>> Ben Gamsa writes:
>>
>>> It appears to be the case that when the time on the system is around
>>> the epoch (1970), that time will occasionally jump forward and then
>>> backward by about 17592 seconds. When it jumps forward, it always
>>> jumps back a few milliseconds later. However, it's not always easy
>>> to catch these occurrences. The delta is more specifically about
>>> 17592186059 usec, give or take a few 10s of microseconds (most of the
>>> time), despite the fact that the user-level program I have that is
>>> testing it only checks every 10 milliseconds.
>>
>> I don't think the time code in the kernel is designed to handle
>> negative values, i.e., times before the epoch. If you want it to do
>> that you'll have to check places like arch/powerpc/kernel/time.c,
>> kernel/time/timekeeping.c, arch/powerpc/include/asm/time.h, etc., and
>> make sure that it uses signed types where necessary and that the
>> arithmetic is correct.
>>
>
> The time never goes negative. It starts off at the epoch and moves
> forward, but sometimes it jumps forward by 17952 seconds, and then
> immediately jumps back. But it never goes negative (or prior to 1970).
>
One important thing I forgot to add is that ntpd is running on this
system, but the ntp servers are not available. I suspect the problem
may be related to ntpd, even though I've seen the time jump even when I
had ntpd stopped within gdb. I've not yet been able to confirm if the
problem still occurs when ntpd is never even started, although I will be
testing that soon (the tests often require many hours to establish if
there are no jumps).
ben
^ permalink raw reply
* linux-next: manual merge of the pci tree with the powerpc tree
From: Stephen Rothwell @ 2009-09-01 2:05 UTC (permalink / raw)
To: Jesse Barnes
Cc: linux-kernel, linuxppc-dev, linux-next, Paul Mackerras,
Richard Lary
Hi Jesse,
Today's linux-next merge of the pci tree got a conflict in
arch/powerpc/kernel/pci_64.c between commit
fbe65447197789a3ccccc27755956f6a4c445089 ("powerpc/pci: move pci_64.c
device tree scanning code into pci-common.c") from the powerpc tree and
commit ced66a36d35607c60d18bb531527acd2083c0523 ("PCI/powerpc: support
PCIe fundamental reset") from the pci tree.
The former moved the code that is modified by the latter into another
file. I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
index 72c31bc..7311fdf 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -139,6 +139,7 @@ struct pci_dev *of_create_pci_dev(struct device_node *node,
dev->dev.bus = &pci_bus_type;
dev->devfn = devfn;
dev->multifunction = 0; /* maybe a lie? */
+ dev->needs_freset = 0; /* pcie fundamental reset required */
dev->vendor = get_int_prop(node, "vendor-id", 0xffff);
dev->device = get_int_prop(node, "device-id", 0xffff);
^ permalink raw reply related
* Re: time jumps forward/backwards
From: Benjamin Gamsa @ 2009-09-01 2:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <4A9C664D.6010504@somanetworks.com>
Benjamin Gamsa wrote:
> Benjamin Gamsa wrote:
>> Paul Mackerras wrote:
>>> Ben Gamsa writes:
>>>
>>>> It appears to be the case that when the time on the system is around
>>>> the epoch (1970), that time will occasionally jump forward and then
>>>> backward by about 17592 seconds. When it jumps forward, it always
>>>> jumps back a few milliseconds later. However, it's not always easy
>>>> to catch these occurrences. The delta is more specifically about
>>>> 17592186059 usec, give or take a few 10s of microseconds (most of
>>>> the time), despite the fact that the user-level program I have that
>>>> is testing it only checks every 10 milliseconds.
>>>
>>> I don't think the time code in the kernel is designed to handle
>>> negative values, i.e., times before the epoch. If you want it to do
>>> that you'll have to check places like arch/powerpc/kernel/time.c,
>>> kernel/time/timekeeping.c, arch/powerpc/include/asm/time.h, etc., and
>>> make sure that it uses signed types where necessary and that the
>>> arithmetic is correct.
>>>
>>
>> The time never goes negative. It starts off at the epoch and moves
>> forward, but sometimes it jumps forward by 17952 seconds, and then
>> immediately jumps back. But it never goes negative (or prior to 1970).
>>
>
> One important thing I forgot to add is that ntpd is running on this
> system, but the ntp servers are not available. I suspect the problem
> may be related to ntpd, even though I've seen the time jump even when I
> had ntpd stopped within gdb. I've not yet been able to confirm if the
> problem still occurs when ntpd is never even started, although I will be
> testing that soon (the tests often require many hours to establish if
> there are no jumps).
For what it's worth, the problem occurs even when ntp is not even started.
ben
^ permalink raw reply
* Re: time jumps forward/backwards
From: Sean MacLennan @ 2009-09-01 2:31 UTC (permalink / raw)
To: Benjamin Gamsa; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4A9C84D0.8040200@somanetworks.com>
On Mon, 31 Aug 2009 22:20:00 -0400
Benjamin Gamsa <ben@somanetworks.com> wrote:
> For what it's worth, the problem occurs even when ntp is not even
> started.
This is grasping, but could it have anything to do with the jiffies
wrapping near startup?
Cheers,
Sean
^ permalink raw reply
* Re: time jumps forward/backwards
From: Benjamin Gamsa @ 2009-09-01 3:57 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20090831223111.7b2dc95d@lappy.seanm.ca>
Sean MacLennan wrote:
> On Mon, 31 Aug 2009 22:20:00 -0400
> Benjamin Gamsa <ben@somanetworks.com> wrote:
>
>> For what it's worth, the problem occurs even when ntp is not even
>> started.
>
> This is grasping, but could it have anything to do with the jiffies
> wrapping near startup?
>
I don't know how to test it, but I don't think so, since there are
multiple of these glitches over an extended period of time.
ben
^ permalink raw reply
* PPC405 RTC not working
From: Jake Magee @ 2009-09-01 4:09 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]
I am currently trying to get a M41T65 sensor to work on a PPC405 based
board. I am using the 2.6.26 kernel with a backported version of
rtc-m41t80.c (from 2.6.30). Everything compiles and loads fine. However,
there is no /dev/rtc node created. "/proc/devices" returns "254 rtc" (which
I feel isn't correct). And "/sys/bus/i2c/devices/" list nothing for the
RTC. I do see the information from the device tree in
"/proc/device-tree/plb/opb/i2c@ef600400/rtc@68/"
Here is my dts information:
IIC0: i2c@ef600400 {
compatible = "ibm,iic-405exr", "ibm,iic";
reg = <ef600400 14>;
interrupt-parent = <&UIC0>;
interrupts = <2 4>;
index = <0>;
rtc@68 {
compatible = "m41t65";
reg = <68>;
};
};
Thanks!
Jake Magee
[-- Attachment #2: Type: text/html, Size: 1211 bytes --]
^ permalink raw reply
* [PATCH] Fix fake numa on ppc
From: Ankita Garg @ 2009-09-01 5:03 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, Balbir Singh; +Cc: ankita
Hello,
Below is a patch to fix a couple of issues with fake numa node creation
on ppc:
1) Presently, fake nodes could be created such that real numa node
boundaries are not respected. So a node could have lmbs that belong to
different real nodes.
2) The cpu association is broken. On a JS22 blade for example, which is
a 2-node numa machine, I get the following:
# cat /proc/cmdline
root=/dev/sda6 numa=fake=2G,4G,,6G,8G,10G,12G,14G,16G
# cat /sys/devices/system/node/node0/cpulist
0-3
# cat /sys/devices/system/node/node1/cpulist
4-7
# cat /sys/devices/system/node/node4/cpulist
#
So, though the cpus 4-7 should have been associated with node4, they
still belong to node1. The patch works by recording a real numa node
boundary and incrementing the fake node count. At the same time, a
mapping is stored from the real numa node to the first fake node that
gets created on it.
Any suggestions on improving the patch are most welcome!
Signed-off-by: Ankita Garg <ankita@in.ibm.com>
Index: linux-2.6.31-rc5/arch/powerpc/mm/numa.c
===================================================================
--- linux-2.6.31-rc5.orig/arch/powerpc/mm/numa.c
+++ linux-2.6.31-rc5/arch/powerpc/mm/numa.c
@@ -26,6 +26,11 @@
#include <asm/smp.h>
static int numa_enabled = 1;
+static int fake_enabled = 1;
+
+/* The array maps a real numa node to the first fake node that gets
+created on it */
+int fake_numa_node_mapping[MAX_NUMNODES];
static char *cmdline __initdata;
@@ -49,14 +54,24 @@ static int __cpuinit fake_numa_create_ne
unsigned long long mem;
char *p = cmdline;
static unsigned int fake_nid;
+ static unsigned int orig_nid = 0;
static unsigned long long curr_boundary;
/*
* Modify node id, iff we started creating NUMA nodes
* We want to continue from where we left of the last time
*/
- if (fake_nid)
+ if (fake_nid) {
+ if (orig_nid != *nid) {
+ fake_nid++;
+ fake_numa_node_mapping[*nid] = fake_nid;
+ orig_nid = *nid;
+ *nid = fake_nid;
+ return 0;
+ }
*nid = fake_nid;
+ }
+
/*
* In case there are no more arguments to parse, the
* node_id should be the same as the last fake node id
@@ -440,7 +455,7 @@ static int of_drconf_to_nid_single(struc
*/
static int __cpuinit numa_setup_cpu(unsigned long lcpu)
{
- int nid = 0;
+ int nid = 0, new_nid;
struct device_node *cpu = of_get_cpu_node(lcpu, NULL);
if (!cpu) {
@@ -450,8 +465,15 @@ static int __cpuinit numa_setup_cpu(unsi
nid = of_node_to_nid_single(cpu);
+ if (fake_enabled && nid) {
+ new_nid = fake_numa_node_mapping[nid];
+ if (new_nid > 0)
+ nid = new_nid;
+ }
+
if (nid < 0 || !node_online(nid))
nid = any_online_node(NODE_MASK_ALL);
+
out:
map_cpu_to_node(lcpu, nid);
@@ -1005,8 +1027,11 @@ static int __init early_numa(char *p)
numa_debug = 1;
p = strstr(p, "fake=");
- if (p)
+ if (p) {
cmdline = p + strlen("fake=");
+ if (numa_enabled)
+ fake_enabled = 1;
+ }
return 0;
}
--
Regards,
Ankita Garg (ankita@in.ibm.com)
Linux Technology Center
IBM India Systems & Technology Labs,
Bangalore, India
^ permalink raw reply
* Re: ECC & Magic bitmask errors with JFFS2 file system on 6.23 kernel for powerpc
From: Rupesh Kumar @ 2009-09-01 5:23 UTC (permalink / raw)
To: avorontsov; +Cc: louise, Ravinder Kumar, linuxppc-dev, Louise.Yeung
In-Reply-To: <20090831234713.GA6767@oksana.dev.rtsoft.ru>
Hi Louise,
Earlier we were using kernel 2.6.20(released with LTIB for REVA board of
MPC8313E) and we were not seeing this problem in that kernel. Since, We
had time constraint for our project, best thing we did was ported 2.6.20
kernel on rev 2.1 silicon of MPC8313E. This is working fine.
However, We did try to dig this problem further and found that the problem
occurs because of the ECC alignment mismatch in read & write on NAND
flash.
You can look into following points :-
1) NAND initialization :- Page size mentioned correctly in BR/OR
register Settings.
2) rfs is made with correct erase size.
3) ECC placement used in u-boot & Kernel nand driver is same.
4) Try using different ECC alignments and see if it makes some
difference.
Regards
Rupesh
Anton Vorontsov <avorontsov@ru.mvista.com>
09/01/2009 05:17 AM
Please respond to
avorontsov@ru.mvista.com
To
Louise.Yeung@Sun.COM
cc
linuxppc-dev@lists.ozlabs.org, louise <louise@Sun.COM>, Ravinder Kumar
<Ravinder.Kumar@Sun.COM>, Rupesh Kumar <Rupesh.Kumar@Lntemsys.com>
Subject
Re: ECC & Magic bitmask errors with JFFS2 file system on 6.23 kernel for
powerpc
On Mon, Aug 31, 2009 at 01:39:10PM -0700, Louise.Yeung@Sun.COM wrote:
> *Hi Rupesh,
>
> We are using a Freescale processor similar to yours with NAND flash
> supporting 2KB page size .
What kernel version and NAND driver you use? I don't think that old
BSP kernels include fsl_elbc_nand driver, which is a much improved
version of the fsl_fcm driver.
So you might want to swith to a newer kernel or back-port the
fsl_elbc_nand driver[1] and a few fixes to your kernel.
[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/mtd/nand/fsl_elbc_nand.c
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] Fix fake numa on ppc
From: Balbir Singh @ 2009-09-01 5:57 UTC (permalink / raw)
To: Ankita Garg; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090901050316.GA4076@in.ibm.com>
* Ankita Garg <ankita@in.ibm.com> [2009-09-01 10:33:16]:
> Hello,
>
> Below is a patch to fix a couple of issues with fake numa node creation
> on ppc:
>
> 1) Presently, fake nodes could be created such that real numa node
> boundaries are not respected. So a node could have lmbs that belong to
> different real nodes.
>
> 2) The cpu association is broken. On a JS22 blade for example, which is
> a 2-node numa machine, I get the following:
>
> # cat /proc/cmdline
> root=/dev/sda6 numa=fake=2G,4G,,6G,8G,10G,12G,14G,16G
> # cat /sys/devices/system/node/node0/cpulist
> 0-3
> # cat /sys/devices/system/node/node1/cpulist
> 4-7
> # cat /sys/devices/system/node/node4/cpulist
>
> #
>
> So, though the cpus 4-7 should have been associated with node4, they
> still belong to node1. The patch works by recording a real numa node
> boundary and incrementing the fake node count. At the same time, a
> mapping is stored from the real numa node to the first fake node that
> gets created on it.
>
Some details on how you tested it and results before and after would
be nice. Please see git commit 1daa6d08d1257aa61f376c3cc4795660877fb9e3
for example
> Any suggestions on improving the patch are most welcome!
>
> Signed-off-by: Ankita Garg <ankita@in.ibm.com>
>
> Index: linux-2.6.31-rc5/arch/powerpc/mm/numa.c
> ===================================================================
> --- linux-2.6.31-rc5.orig/arch/powerpc/mm/numa.c
> +++ linux-2.6.31-rc5/arch/powerpc/mm/numa.c
> @@ -26,6 +26,11 @@
> #include <asm/smp.h>
>
> static int numa_enabled = 1;
> +static int fake_enabled = 1;
> +
> +/* The array maps a real numa node to the first fake node that gets
> +created on it */
Coding style is broken
> +int fake_numa_node_mapping[MAX_NUMNODES];
>
> static char *cmdline __initdata;
>
> @@ -49,14 +54,24 @@ static int __cpuinit fake_numa_create_ne
> unsigned long long mem;
> char *p = cmdline;
> static unsigned int fake_nid;
> + static unsigned int orig_nid = 0;
Should we call this prev_nid?
> static unsigned long long curr_boundary;
>
> /*
> * Modify node id, iff we started creating NUMA nodes
> * We want to continue from where we left of the last time
> */
> - if (fake_nid)
> + if (fake_nid) {
> + if (orig_nid != *nid) {
OK, so this is called when the real NUMA node changes - comments would
be nice
> + fake_nid++;
> + fake_numa_node_mapping[*nid] = fake_nid;
> + orig_nid = *nid;
> + *nid = fake_nid;
> + return 0;
> + }
> *nid = fake_nid;
> + }
> +
> /*
> * In case there are no more arguments to parse, the
> * node_id should be the same as the last fake node id
> @@ -440,7 +455,7 @@ static int of_drconf_to_nid_single(struc
> */
> static int __cpuinit numa_setup_cpu(unsigned long lcpu)
> {
> - int nid = 0;
> + int nid = 0, new_nid;
> struct device_node *cpu = of_get_cpu_node(lcpu, NULL);
>
> if (!cpu) {
> @@ -450,8 +465,15 @@ static int __cpuinit numa_setup_cpu(unsi
>
> nid = of_node_to_nid_single(cpu);
>
> + if (fake_enabled && nid) {
> + new_nid = fake_numa_node_mapping[nid];
> + if (new_nid > 0)
> + nid = new_nid;
> + }
> +
> if (nid < 0 || !node_online(nid))
> nid = any_online_node(NODE_MASK_ALL);
> +
> out:
> map_cpu_to_node(lcpu, nid);
>
> @@ -1005,8 +1027,11 @@ static int __init early_numa(char *p)
> numa_debug = 1;
>
> p = strstr(p, "fake=");
> - if (p)
> + if (p) {
> cmdline = p + strlen("fake=");
> + if (numa_enabled)
> + fake_enabled = 1;
Have you tried passing just numa=fake= without any commandline?
That should enable fake_enabled, but I wonder if that negatively
impacts numa_setup_cpu(). I wonder if you should look at cmdline
to decide on fake_enabled.
> + }
>
> return 0;
> }
>
Overall, I think this is the right thing to do, we need to move in
this direction.
--
Balbir
^ permalink raw reply
* Re: ECC & Magic bitmask errors with JFFS2 file system on 6.23 kernel for powerpc
From: Ravinder Kumar @ 2009-09-01 6:46 UTC (permalink / raw)
To: avorontsov; +Cc: louise, Rupesh Kumar, linuxppc-dev, Louise.Yeung
In-Reply-To: <20090831234713.GA6767@oksana.dev.rtsoft.ru>
On Aug 31, 2009, at 4:47 PM, Anton Vorontsov wrote:
> On Mon, Aug 31, 2009 at 01:39:10PM -0700, Louise.Yeung@Sun.COM wrote:
>> *Hi Rupesh,
>>
>> We are using a Freescale processor similar to yours with NAND flash
>> supporting 2KB page size .
>
> What kernel version and NAND driver you use? I don't think that old
> BSP kernels include fsl_elbc_nand driver, which is a much improved
> version of the fsl_fcm driver.
We are using 2.6.23 kernel with freescale patches. The sources have
fsl_elbc driver.
I think the newer BSP kernels have fsl_elbc_nand driver. Will look at
it.
Thanks
Ravinder
>
> So you might want to swith to a newer kernel or back-port the
> fsl_elbc_nand driver[1] and a few fixes to your kernel.
>
> [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/mtd/nand/fsl_elbc_nand.c
>
> --
> Anton Vorontsov
> email: cbouatmailru@gmail.com
> irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH v2] powerpc: Fix some late PowerMac G5 with PCIe ATI graphics
From: Benjamin Herrenschmidt @ 2009-09-01 7:34 UTC (permalink / raw)
To: linuxppc-dev list
A misconfiguration by the firmware of the U4 PCIe bridge on PowerMac G5
with the U4 bridge (latest generations, may also affect the iMac G5
"iSight") is causing us to re-assign the PCI BARs of the video card,
which can get it out of sync with the firmware, thus breaking offb.
This works around it by fixing up the bridge configuration properly
at boot time. It also fixes a bug where the firmware provides us with
an incorrect set of accessible regions in the device-tree.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
diff --git a/arch/powerpc/platforms/powermac/pci.c b/arch/powerpc/platforms/powermac/pci.c
index 04cdd32..e81403b 100644
--- a/arch/powerpc/platforms/powermac/pci.c
+++ b/arch/powerpc/platforms/powermac/pci.c
@@ -1286,3 +1286,64 @@ static void fixup_k2_sata(struct pci_dev* dev)
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SERVERWORKS, 0x0240, fixup_k2_sata);
+/*
+ * On U4 (aka CPC945) the PCIe root complex "P2P" bridge resource ranges aren't
+ * configured by the firmware. The bridge itself seems to ignore them but it
+ * causes problems with Linux which then re-assigns devices below the bridge,
+ * thus changing addresses of those devices from what was in the device-tree,
+ * which sucks when those are video cards using offb
+ *
+ * We could just mark it transparent but I prefer fixing up the resources to
+ * properly show what's going on here, as I have some doubts about having them
+ * badly configured potentially being an issue for DMA.
+ *
+ * We leave PIO alone, it seems to be fine
+ *
+ * Oh and there's another funny bug. The OF properties advertize the region
+ * 0xf1000000..0xf1ffffff as being forwarded as memory space. But that's
+ * actually not true, this region is the memory mapped config space. So we
+ * also need to filter it out or we'll map things in the wrong place.
+ */
+static void fixup_u4_pcie(struct pci_dev* dev)
+{
+ struct pci_controller *host = pci_bus_to_host(dev->bus);
+ struct resource *region = NULL;
+ u32 reg;
+ int i;
+
+ /* Only do that on PowerMac */
+ if (!machine_is(powermac))
+ return;
+
+ /* Find the largest MMIO region */
+ for (i = 0; i < 3; i++) {
+ struct resource *r = &host->mem_resources[i];
+ if (!(r->flags & IORESOURCE_MEM))
+ continue;
+ /* Skip the 0xf0xxxxxx..f2xxxxxx regions, we know they
+ * are reserved by HW for other things
+ */
+ if (r->start >= 0xf0000000 && r->start < 0xf3000000)
+ continue;
+ if (!region || (r->end - r->start) >
+ (region->end - region->start))
+ region = r;
+ }
+ /* Nothing found, bail */
+ if (region == 0)
+ return;
+
+ /* Print things out */
+ printk(KERN_INFO "PCI: Fixup U4 PCIe bridge range: %pR\n", region);
+
+ /* Fixup bridge config space. We know it's a Mac, resource aren't
+ * offset so let's just blast them as-is. We also know that they
+ * fit in 32 bits
+ */
+ reg = ((region->start >> 16) & 0xfff0) | (region->end & 0xfff00000);
+ pci_write_config_dword(dev, PCI_MEMORY_BASE, reg);
+ pci_write_config_dword(dev, PCI_PREF_BASE_UPPER32, 0);
+ pci_write_config_dword(dev, PCI_PREF_LIMIT_UPPER32, 0);
+ pci_write_config_dword(dev, PCI_PREF_MEMORY_BASE, 0);
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_U4_PCIE, fixup_u4_pcie);
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 0f71812..148d742 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -876,6 +876,7 @@
#define PCI_DEVICE_ID_APPLE_SH_SUNGEM 0x0051
#define PCI_DEVICE_ID_APPLE_U3L_AGP 0x0058
#define PCI_DEVICE_ID_APPLE_U3H_AGP 0x0059
+#define PCI_DEVICE_ID_APPLE_U4_PCIE 0x005b
#define PCI_DEVICE_ID_APPLE_IPID2_AGP 0x0066
#define PCI_DEVICE_ID_APPLE_IPID2_ATA 0x0069
#define PCI_DEVICE_ID_APPLE_IPID2_FW 0x006a
--
1.6.1.2.14.gf26b5
^ permalink raw reply related
* Re: [PATCH] Fix fake numa on ppc
From: Ankita Garg @ 2009-09-01 9:24 UTC (permalink / raw)
To: Balbir Singh; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090901055753.GB5563@balbir.in.ibm.com>
Hi Balbir,
On Tue, Sep 01, 2009 at 11:27:53AM +0530, Balbir Singh wrote:
> * Ankita Garg <ankita@in.ibm.com> [2009-09-01 10:33:16]:
>
> > Hello,
> >
> > Below is a patch to fix a couple of issues with fake numa node creation
> > on ppc:
> >
> > 1) Presently, fake nodes could be created such that real numa node
> > boundaries are not respected. So a node could have lmbs that belong to
> > different real nodes.
> >
> > 2) The cpu association is broken. On a JS22 blade for example, which is
> > a 2-node numa machine, I get the following:
> >
> > # cat /proc/cmdline
> > root=/dev/sda6 numa=fake=2G,4G,,6G,8G,10G,12G,14G,16G
> > # cat /sys/devices/system/node/node0/cpulist
> > 0-3
> > # cat /sys/devices/system/node/node1/cpulist
> > 4-7
> > # cat /sys/devices/system/node/node4/cpulist
> >
> > #
> >
> > So, though the cpus 4-7 should have been associated with node4, they
> > still belong to node1. The patch works by recording a real numa node
> > boundary and incrementing the fake node count. At the same time, a
> > mapping is stored from the real numa node to the first fake node that
> > gets created on it.
> >
>
> Some details on how you tested it and results before and after would
> be nice. Please see git commit 1daa6d08d1257aa61f376c3cc4795660877fb9e3
> for example
>
>
Thanks for the quick review of the patch. Here is some information on
the testing:
Tested the patch with the following commandlines:
numa=fake=2G,4G,6G,8G,10G,12G,14G,16G
numa=fake=3G,6G,10G,16G
numa=fake=4G
numa=fake=
For testing if the fake nodes respect the real node boundaries, I added
some debug printks in the node creation path. Without the patch, for the
commandline numa=fake=2G,4G,6G,8G,10G,12G,14G,16G, this is what I got:
fake id: 1 nid: 0
fake id: 1 nid: 0
...
fake id: 2 nid: 0
fake id: 2 nid: 0
...
fake id: 2 nid: 0
created new fake_node with id 3
fake id: 3 nid: 0
fake id: 3 nid: 0
...
fake id: 3 nid: 0
fake id: 3 nid: 0
fake id: 3 nid: 1
fake id: 3 nid: 1
...
created new fake_node with id 4
fake id: 4 nid: 1
fake id: 4 nid: 1
...
and so on. So, fake node 3 encompasses real node 0 & 1. Also,
# cat /sys/devices/system/node/node3/meminfo
Node 0 MemTotal: 2097152 kB
...
# # cat /sys/devices/system/node/node4/meminfo
Node 0 MemTotal: 2097152 kB
...
With the patch, I get:
fake id: 1 nid: 0
fake id: 1 nid: 0
...
fake id: 2 nid: 0
fake id: 2 nid: 0
...
fake id: 2 nid: 0
created new fake_node with id 3
fake id: 3 nid: 0
fake id: 3 nid: 0
...
fake id: 3 nid: 0
fake id: 3 nid: 0
created new fake_node with id 4
fake id: 4 nid: 1
fake id: 4 nid: 1
...
and so on. With the patch, the fake node sizes are slightly different
from that specified by the user.
# cat /sys/devices/system/node/node3/meminfo
Node 3 MemTotal: 1638400 kB
...
# cat /sys/devices/system/node/node4/meminfo
Node 4 MemTotal: 458752 kB
...
CPU association was tested as mentioned in the previous mail:
Without the patch,
# cat /proc/cmdline
root=/dev/sda6 numa=fake=2G,4G,,6G,8G,10G,12G,14G,16G
# cat /sys/devices/system/node/node0/cpulist
0-3
# cat /sys/devices/system/node/node1/cpulist
4-7
# cat /sys/devices/system/node/node4/cpulist
#
With the patch,
# cat /proc/cmdline
root=/dev/sda6 numa=fake=2G,4G,,6G,8G,10G,12G,14G,16G
# cat /sys/devices/system/node/node0/cpulist
0-3
# cat /sys/devices/system/node/node1/cpulist
# cat /sys/devices/system/node/node4/cpulist
4-7
> >
> > Signed-off-by: Ankita Garg <ankita@in.ibm.com>
> >
> > Index: linux-2.6.31-rc5/arch/powerpc/mm/numa.c
> > ===================================================================
> > --- linux-2.6.31-rc5.orig/arch/powerpc/mm/numa.c
> > +++ linux-2.6.31-rc5/arch/powerpc/mm/numa.c
> > @@ -26,6 +26,11 @@
> > #include <asm/smp.h>
> >
> > static int numa_enabled = 1;
> > +static int fake_enabled = 1;
> > +
> > +/* The array maps a real numa node to the first fake node that gets
> > +created on it */
>
> Coding style is broken
>
Fixed.
> > +int fake_numa_node_mapping[MAX_NUMNODES];
> >
> > static char *cmdline __initdata;
> >
> > @@ -49,14 +54,24 @@ static int __cpuinit fake_numa_create_ne
> > unsigned long long mem;
> > char *p = cmdline;
> > static unsigned int fake_nid;
> > + static unsigned int orig_nid = 0;
>
> Should we call this prev_nid?
>
Yes, makes sense.
> > static unsigned long long curr_boundary;
> >
> > /*
> > * Modify node id, iff we started creating NUMA nodes
> > * We want to continue from where we left of the last time
> > */
> > - if (fake_nid)
> > + if (fake_nid) {
> > + if (orig_nid != *nid) {
>
> OK, so this is called when the real NUMA node changes - comments would
> be nice
>
Thanks, have added the comment.
> > + fake_nid++;
> > + fake_numa_node_mapping[*nid] = fake_nid;
> > + orig_nid = *nid;
> > + *nid = fake_nid;
> > + return 0;
> > + }
> > *nid = fake_nid;
> > + }
> > +
> > /*
> > * In case there are no more arguments to parse, the
> > * node_id should be the same as the last fake node id
> > @@ -440,7 +455,7 @@ static int of_drconf_to_nid_single(struc
> > */
> > static int __cpuinit numa_setup_cpu(unsigned long lcpu)
> > {
> > - int nid = 0;
> > + int nid = 0, new_nid;
> > struct device_node *cpu = of_get_cpu_node(lcpu, NULL);
> >
> > if (!cpu) {
> > @@ -450,8 +465,15 @@ static int __cpuinit numa_setup_cpu(unsi
> >
> > nid = of_node_to_nid_single(cpu);
> >
> > + if (fake_enabled && nid) {
> > + new_nid = fake_numa_node_mapping[nid];
> > + if (new_nid > 0)
> > + nid = new_nid;
> > + }
> > +
> > if (nid < 0 || !node_online(nid))
> > nid = any_online_node(NODE_MASK_ALL);
> > +
> > out:
> > map_cpu_to_node(lcpu, nid);
> >
> > @@ -1005,8 +1027,11 @@ static int __init early_numa(char *p)
> > numa_debug = 1;
> >
> > p = strstr(p, "fake=");
> > - if (p)
> > + if (p) {
> > cmdline = p + strlen("fake=");
> > + if (numa_enabled)
> > + fake_enabled = 1;
>
> Have you tried passing just numa=fake= without any commandline?
> That should enable fake_enabled, but I wonder if that negatively
> impacts numa_setup_cpu(). I wonder if you should look at cmdline
> to decide on fake_enabled.
>
fake_enabled does get set even for numa=fake=. However, it does not
impact numa_setup_cpu, since fake_numa_node_mapping array would have no
mapping stored and there is a condition there already to check for the
value of the mapping. I confirmed this by booting with the above
parameter as well.
> > + }
> >
> > return 0;
> > }
> >
>
> Overall, I think this is the right thing to do, we need to move in
> this direction.
>
Heres the updated patch:
Signed-off-by: Ankita Garg <ankita@in.ibm.com>
Index: linux-2.6.31-rc5/arch/powerpc/mm/numa.c
===================================================================
--- linux-2.6.31-rc5.orig/arch/powerpc/mm/numa.c
+++ linux-2.6.31-rc5/arch/powerpc/mm/numa.c
@@ -26,6 +26,13 @@
#include <asm/smp.h>
static int numa_enabled = 1;
+static int fake_enabled = 1;
+
+/*
+ * The array maps a real numa node to the first fake node that gets
+ * created on it
+ */
+int fake_numa_node_mapping[MAX_NUMNODES];
static char *cmdline __initdata;
@@ -49,14 +56,29 @@ static int __cpuinit fake_numa_create_ne
unsigned long long mem;
char *p = cmdline;
static unsigned int fake_nid;
+ static unsigned int prev_nid = 0;
static unsigned long long curr_boundary;
/*
* Modify node id, iff we started creating NUMA nodes
* We want to continue from where we left of the last time
*/
- if (fake_nid)
+ if (fake_nid) {
+ /*
+ * Moved over to the next real numa node, increment fake
+ * node number and store the mapping of the real node to
+ * the fake node
+ */
+ if (prev_nid != *nid) {
+ fake_nid++;
+ fake_numa_node_mapping[*nid] = fake_nid;
+ prev_nid = *nid;
+ *nid = fake_nid;
+ return 0;
+ }
*nid = fake_nid;
+ }
+
/*
* In case there are no more arguments to parse, the
* node_id should be the same as the last fake node id
@@ -440,7 +462,7 @@ static int of_drconf_to_nid_single(struc
*/
static int __cpuinit numa_setup_cpu(unsigned long lcpu)
{
- int nid = 0;
+ int nid = 0, new_nid;
struct device_node *cpu = of_get_cpu_node(lcpu, NULL);
if (!cpu) {
@@ -450,8 +472,15 @@ static int __cpuinit numa_setup_cpu(unsi
nid = of_node_to_nid_single(cpu);
+ if (fake_enabled && nid) {
+ new_nid = fake_numa_node_mapping[nid];
+ if (new_nid > 0)
+ nid = new_nid;
+ }
+
if (nid < 0 || !node_online(nid))
nid = any_online_node(NODE_MASK_ALL);
+
out:
map_cpu_to_node(lcpu, nid);
@@ -1005,8 +1034,12 @@ static int __init early_numa(char *p)
numa_debug = 1;
p = strstr(p, "fake=");
- if (p)
+ if (p) {
cmdline = p + strlen("fake=");
+ if (numa_enabled) {
+ fake_enabled = 1;
+ }
+ }
return 0;
}
--
Regards,
Ankita Garg (ankita@in.ibm.com)
Linux Technology Center
IBM India Systems & Technology Labs,
Bangalore, India
^ permalink raw reply
* Re: time jumps forward/backwards
From: Benjamin Herrenschmidt @ 2009-09-01 10:49 UTC (permalink / raw)
To: Benjamin Gamsa; +Cc: Paul Mackerras, linuxppc-dev, Sean MacLennan
In-Reply-To: <4A9C9BA3.6020105@somanetworks.com>
On Mon, 2009-08-31 at 23:57 -0400, Benjamin Gamsa wrote:
> Sean MacLennan wrote:
> > On Mon, 31 Aug 2009 22:20:00 -0400
> > Benjamin Gamsa <ben@somanetworks.com> wrote:
> >
> >> For what it's worth, the problem occurs even when ntp is not even
> >> started.
> >
> > This is grasping, but could it have anything to do with the jiffies
> > wrapping near startup?
> >
>
> I don't know how to test it, but I don't think so, since there are
> multiple of these glitches over an extended period of time.
I'm not familiar with all the FSL processor variants, but is this
an UP or an SMP platform ? In the later case, are all the core timebases
properly synchronized ?
Cheers,
Ben.
^ permalink raw reply
* Question about linux boot procedure (head_64.S)
From: Lee HongWoo @ 2009-09-01 10:58 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 515 bytes --]
Hi ~
This is a boot flow of linux kernel under the arch/powerpc/kernel and I'm
using pasemi cpu.
__start (in head_64.S)
---> __start_initialization_multiplatform (in head_64.S)
---> __boot_from_prom (in head_64.S)
---> prom_init ( in prom_init.c)
---> __start ???
And I don't understand where __start is called, because I can find __start
only in head_64.S.
If it calls __start in head_64.S, it's a recursive call.
Can anybody explain about this precedure ?
Thanks in advance.
HongWoo.
[-- Attachment #2: Type: text/html, Size: 630 bytes --]
^ permalink raw reply
* Re: time jumps forward/backwards
From: Benjamin Gamsa @ 2009-09-01 11:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Paul Mackerras, linuxppc-dev, Sean MacLennan
In-Reply-To: <1251802154.14675.346.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Mon, 2009-08-31 at 23:57 -0400, Benjamin Gamsa wrote:
>> Sean MacLennan wrote:
>>> On Mon, 31 Aug 2009 22:20:00 -0400
>>> Benjamin Gamsa <ben@somanetworks.com> wrote:
>>>
>>>> For what it's worth, the problem occurs even when ntp is not even
>>>> started.
>>> This is grasping, but could it have anything to do with the jiffies
>>> wrapping near startup?
>>>
>> I don't know how to test it, but I don't think so, since there are
>> multiple of these glitches over an extended period of time.
>
> I'm not familiar with all the FSL processor variants, but is this
> an UP or an SMP platform ? In the later case, are all the core timebases
> properly synchronized ?
>
This a UP with a single e500 core.
ben
^ permalink raw reply
* Question about linux boot procedure (head_64.S)
From: Lee HongWoo @ 2009-09-01 11:27 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 515 bytes --]
Hi ~
This is a boot flow of linux kernel under the arch/powerpc/kernel and I'm
using pasemi cpu.
__start (in head_64.S)
---> __start_initialization_multiplatform (in head_64.S)
---> __boot_from_prom (in head_64.S)
---> prom_init ( in prom_init.c)
---> __start ???
And I don't understand where __start is called, because I can find __start
only in head_64.S.
If it calls __start in head_64.S, it's a recursive call.
Can anybody explain about this precedure ?
Thanks in advance.
HongWoo.
[-- Attachment #2: Type: text/html, Size: 658 bytes --]
^ permalink raw reply
* [v4 PATCH 0/5]: cpuidle/POWER (REDISIGN): Introducing cpuidle to POWER.
From: Arun R Bharadwaj @ 2009-09-01 11:37 UTC (permalink / raw)
To: Joel Schopp, Benjamin Herrenschmidt, Paul Mackerras,
Peter Zijlstra, Ingo Molnar, Vaidyanathan Srinivasan,
Dipankar Sarma, Balbir Singh, Gautham R Shenoy, Arun R Bharadwaj
Cc: linuxppc-dev, linux-kernel
Hi,
******** This is an RFC, not for inclusion **********
This patchset introduces cpuidle infrastructure to POWER, prototyping
for pseries and currently in the process of porting to x86 and hence
will *not* build on x86/other POWER platforms.
This is to get initial comments on the redesign of my earlier implementation
which can be found at http://lkml.org/lkml/2009/8/27/124
Major changes from last iteration:
----------------------------------
* Cleanup drivers/cpuidle/cpuidle.c
Currently, the cpuidle implementation has weakness in the
framework where an exported pm_idle function pointer is
manipulated by various subsystem. The proposed framework has
a registration architecture to cleanly add and remove new idle
routines from different subsystems.
* Introduce [un]register_idle_function() routines
Implement a LIFO based approach for registering architecture
dependent idle routines.
* Sample implementation of register_idle_function for pSeries
TODO:
-----
* Extend this prototype to cover x86 and other archs that use cpuidle.
Currently, in x86, the cpu_idle() idle loop doesn't have a
default idle loop to fall back to if pm_idle is NULL, unlike
the corresponding implementation in pseries, where
ppc_md.power_save can be NULL and there is a fallback.
So we need to create a similar fork in cpu_idle() idle loop of
x86.
Patches included in this series:
--------------------------------
1/5 - Cleanup drivers/cpuidle/cpuidle.c
2/5 - Implement routines to register and unregister idle function.
3/5 - Incorporate registering of idle loop for pSeries.
4/5 - Add Kconfig entry to enable cpuidle for POWER.
5/5 - Implement pSeries processor idle module.
Any comments on the design is welcome.
--arun
^ 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